Education software security: designed controls and status

Learner support records can hold disability, health and family information. That is some of the most sensitive data a college or training provider keeps. Good education software security starts from that fact. This page sets out how we are designing Inclusion Studio to protect it, and it separates two things clearly: what is designed (decided and being built) and what is evidenced (tested and checked by someone independent). Today, almost everything is in the first column.

What stage is Inclusion Studio at?

Inclusion Studio is pre-pilot. A clickable prototype with five fictional learners exists. It keeps changes in browser memory, uses a labelled sample AI draft and has no real sign-in, database or access control. The production application is in development and uses synthetic data only. No real learner data has been loaded, and none will be until the gates on our assurance roadmap are met.

We hold no security certifications. We have not yet had a penetration test or an independent security review. If your procurement process needs a specific standard, tell us early so we can be straight with you about where we are.

How are permissions enforced?

Permissions are checked on the server for every request, by organisation, by the person’s relationship to the learner and by field. Hiding a button in the interface is never treated as the safeguard. In practice that means:

• every record belongs to one organisation (tenant), and the server checks the tenant on every read and write;
• the organisation a browser says it belongs to is never trusted without server-side verification;
• a tutor sees learners they work with, not the whole college;
• an apprenticeship employer contact sees only the workplace adjustments and their own actions, never the learner’s full history;
• the same checks apply to files, search, exports, background jobs and any AI feature, not just to screens.

See permissions and roles for the role model.

How do people sign in?

Sign-in, sessions, multi-factor authentication (MFA) and account recovery are planned to run on Clerk, an identity service. Our design rules are:

• Clerk holds only minimal identity data (such as name, email and sign-in details). Diagnoses, SEND details, support histories and case notes are never stored there.
• MFA is required for privileged accounts and for staff with access to sensitive records, with an accessible recovery route.
• Removing someone’s access must take effect straight away. It must not depend on a delayed message from the identity service.
• Messages from the identity service are signature-checked and safe to replay.

Learner sign-in will be proportionate and accessible. That design is still being worked out with providers.

How are uploaded documents protected?

Uploaded documents are designed to go to a private file store (Vercel Blob in private mode), where every read requires authentication. They are released only through our own server, after it has checked who is asking and whether they are allowed to see that learner’s file.

• File names and learner details are kept out of storage paths.
• Untrusted uploads are quarantined. They are hidden from other users and from AI until a malware scan passes. The scanning provider has not been chosen yet, so this is a pre-live dependency.
• Sensitive downloads are sent with headers that tell browsers not to store them (Cache-Control: private, no-store).
• We will test that one organisation cannot fetch another’s document by guessing an ID, copying a link or changing a parameter.

More detail is on the documents page.

How are environments and test data separated?

Development, preview and production each have their own database, sign-in configuration, file store and secrets. Real learner records will never be copied into development or preview environments, and coding tools never receive production records or credentials. Operational logs are designed to be redacted so that personal data stays out of logs and code history.

What about backups and recovery?

The database and the file store are separate recovery domains, so we will back up and restore them separately. A database backup is not a document backup, and neither is our code repository. Before real data, we will run actual restore tests for both and record the results. Until then, recovery is designed, not proven.

What should you ask about any education software security, and what has been verified here?

Whichever education software you are assessing, ask the same question: what is designed, and what has someone independent checked? Our own automated tests will cover cross-tenant denial and sensitive-field access as features are built. We do not treat our own tests as a substitute for independent review.

How do I report a security problem?

If you think you have found a vulnerability in this website or in anything we have published, please read our responsible disclosure policy and contact us through the contact page. Please do not test against real people’s data or accounts.