Security
Education software security at Inclusion Studio: how learner support records are protected, what is built so far and what still needs independent testing.
Platform · Foundations
Permissions and roles: the right people see the right things
How Inclusion Studio will enforce who can see and do what by organisation, relationship and field on the server, so hiding a button is never the safeguard.
In short
Inclusion Studio permissions are enforced on the server by organisation, relationship and field. Roles include inclusion lead, tutor or assessor, learner, employer contact and organisation admin. This is in development for the pilot.
Learner support records are sensitive. They can include health information, family circumstances and what a learner finds hard. Who sees what is not a side issue. This page explains how Inclusion Studio is designed to control access, and what exists today.
Why do permissions matter so much for learner support?
A support record is useful only if the right people see it, and harmful if the wrong people do. A tutor needs to know the learner needs written instructions. They may not need to know why. An employer needs to know about a workplace adjustment. They should not see the learner’s full history.
Providers also have legal duties. Health information is special category data under UK GDPR and needs extra care. See our guide to special category data in education.
How will permissions work, step by step?
Every request, whether it opens a record, searches, downloads a file or runs an export, goes through the same checks on the server:
- Who is asking? The person signs in. Their identity is checked. Privileged accounts will need multi-factor authentication.
- Which organisation do they belong to? The server looks up their membership. A client-supplied organisation is never trusted.
- What is their relationship to this learner? For example the tutor of this group, the assessor of this apprentice, the inclusion lead for this campus, or the learner themselves.
- Which fields may they see? Even if they can open the record, sensitive fields may be hidden or removed.
- The server answers or refuses. If the answer is no, the data is not sent. It is not just hidden on the page.
- Access is logged. Sensitive actions leave an audit record.
Revoked access should take effect immediately and not wait for a delayed sync.
Which roles are planned?
| Role | What they are for | Typical access |
|---|---|---|
| Inclusion lead (or ALS / learning support manager) | Runs support across the organisation | Plans, requests, reviews, exports within remit |
| Tutor or assessor | Delivers day-to-day support | Plans and delivery items for their learners, relevant fields |
| Learner | The person the support is for | Their own voice, plan, delivery record and reviews |
| Apprenticeship employer contact | Delivers workplace adjustments | Only workplace adjustments and their own actions |
| Organisation admin | Manages accounts and settings | Configuration, not learner content by default |
| Senior leader or governor | Oversight of the support process | Aggregate views by default, with small groups protected; no case narratives |
| Parent, carer or representative | Supports a learner where they have that role | Only approved fields and actions, once their authority is checked and recorded |
Can one person hold more than one role?
Yes, this is planned. In a smaller provider the same person may be the director, the organisation admin and a tutor. Inclusion Studio is being designed so one account can hold several roles, and each role brings only its own permissions: being an admin does not open learner content, and being a tutor opens only that person’s own learners. Their home screen is planned as a set of cards, one group for each role they hold, so a director who also teaches sees oversight cards and their own teaching tasks side by side. Access is still checked on the server for each action, against the role that action needs.
Role pages explain how each group will use the product: inclusion leads, tutors and assessors, learners, employers, IT and systems.
How are employers kept apart from the full record?
Employer contacts never see a learner’s full history. They see the agreed workplace adjustments and the actions assigned to them. The learner’s voice, reviews and other support are not shown to them unless the learner agrees and the provider shares a specific item. See employer collaboration.
What else is covered?
- Documents: uploads are checked on the server before release. See documents.
- Search and exports: results are filtered by the same rules, not by the interface.
- AI drafts: a draft can use only what the requester may see. See AI drafts.
- Separate environments: development and preview use synthetic data, not real learner records.
- Inspectors and auditors: access is through an approved export or time-limited, read-only access that names the recipient, purpose and expiry. Revoking it stops future access but cannot recall a copy already downloaded.
- Our own support staff: access to a provider’s records needs a stated reason, approval, an expiry and an audit record.
Read more on our security and data protection pages. The primary application database is hosted in London; some supporting services may process data elsewhere and will be documented and assessed before real learner data is used.
What is in the prototype today, and what is being built?
In the prototype: the tutor’s view of five fictional learners. A demo workspace label and a profile show the signed-in role. There is no login, no real access control, no audit history and no data persistence. Everything resets on refresh.
Being built for the pilot:
- Sign-in with multi-factor authentication for privileged accounts.
- Organisation, relationship and field permissions enforced on the server.
- Tests that try to cross organisations and fetch records by guessing identifiers.
- Audit records for sensitive actions.
- Role-based views.
Not claimed: no security certification (such as Cyber Essentials or ISO 27001) is held. Independent security and privacy review is required before any real learner data is used.
Who is this for?
IT and systems teams and data protection officers who need to understand the model. Inclusion leads who need to explain to staff and learners who can see what. See IT and systems and data protection officers.
What does this look like in practice? (fictional example)
A fictional tutor tries to open a learner they do not teach by changing the identifier in the address bar. The server checks the tutor’s organisation, finds no relationship to that learner and refuses the request, without sending any of the record. The attempt is logged. The same tutor can open the learners in their group and see the support relevant to teaching them. An employer contact for one apprentice can see that apprentice’s workplace adjustments and nothing else. Tests that repeat attempts like this one are part of the build, so that the rules are checked and not assumed. This is a fictional example.
Related guides and next steps
- Security and data protection
- DPIA for learner support software
- Join the pilot.
Frequently asked questions
Is hiding a button enough to protect data?
No. A hidden button only changes what a person sees. Inclusion Studio is being built to check every request on the server, so someone who guesses a link or alters a request is still refused.
Can one organisation see another's data?
It should not. Every record belongs to an organisation and the server checks it on every request. Tests that try to cross organisations are part of the build.
Does the prototype enforce permissions?
No. The prototype has no login and no access control. It is a clickable demo with fictional records and shows the tutor's view only.
Can one person be both an admin and a tutor?
That is planned. One account will be able to hold several roles, such as director, admin and tutor in a small provider, with each role adding only its own permissions and its own cards on the home screen.
Can a provider change who sees what?
Some settings will be configurable, but the defaults are narrow and the system will not let a provider give employers a learner's full history.
Sources and further reading
Official guidance changes. Check the source before relying on any detail, and take professional advice for individual cases.
Help shape the pilot
We are working with a small number of England FE colleges and apprenticeship providers first. Tell us about your learner support and we will be in touch.