Documents: private storage for plans, letters and evidence

Support often depends on documents: an EHCP, an assessment report, a signed agreement, a letter from a GP or an employer. They are among the most sensitive files a provider holds. Inclusion Studio is being built to store them privately and release them only to the right people. This page describes the planned design. It is in development for the pilot and not yet available to try.

What problem do documents solve, and what risk do they create?

Documents add context a short plan cannot hold. They also tend to leak. They get emailed, saved on laptops and kept long after they are needed. A report written for one purpose can reach someone who should not see it.

The goal is a single, controlled place where a document is stored once, linked to the learner and shared by permission rather than by attachment.

How will documents work, step by step?

1. A permitted person uploads a file. The upload is tied to a learner and a purpose, such as “assessment report” or “signed agreement”.
2. Limits are checked. Allowed types and size are enforced on the server, not only in the browser.
3. The file is quarantined. Until it passes a malware scan, it is unavailable to other users and to any AI feature.
4. The file is stored privately. The file itself goes to private storage. The application database holds details such as owner, type, size, checksum, scan status, version and retention status. Names and sensitive details are kept out of storage paths.
5. Someone requests the file. The server checks who they are, their organisation and their relationship to the learner.
6. The file is streamed, not linked. An authorised download is delivered with headers that discourage caching. A copied link does not open it for someone else.
7. Every access is logged. Uploads, reads, replacements and deletions leave an audit record.
8. Retention is applied. Files follow a retention rule set with the provider and can be deleted or exported accordingly.

What happens when a file fails the scan?

It stays quarantined, nobody can open it, and the uploader is told it could not be accepted. It is not released and not passed to any AI feature. Which scanning provider will be used has not yet been decided, and it must be chosen and tested before any real learner document is accepted.

Who sees what?

Permissions are enforced on the server by organisation, relationship and field. The intended pattern:

See permissions and roles.

How is recovery handled?

The database and the document store are separate. Restoring one does not restore the other, so both need recovery tests. Before real learner data is used, restore procedures for both will be tested. Details will appear on our security and where data is processed pages as they are verified.

What is in the prototype today, and what is being built?

In the prototype: no documents. The “Evidence behind the draft” view lists sources such as the support plan and delivery record as text, not files.

Being built for the pilot:

• Private document store linked to learner records.
• Server-side permission checks on every upload, read, download, replacement and deletion.
• Quarantine of untrusted uploads until scanned.
• Retention, export and deletion rules.
• Tests that confirm one organisation cannot fetch another’s document by guessing an identifier.

Not yet chosen: the malware scanning provider. Not claimed: any certification or independent assurance. See assurance roadmap.

Who is this for?

IT and systems staff who want to understand where files go. Data protection officers who need to assess storage and processing. Inclusion leads who want to stop attachments travelling by email. See IT and systems and data protection officers.

What does this look like in practice? (fictional example)

An inclusion adviser at a fictional college uploads a learner’s assessment report. It is held in quarantine, and nobody else can open it, until a scan completes. Once it passes, the report is linked to the learner’s record. The learner’s tutor does not see it, because it was not marked as shareable with tutors. The adviser later shares a one-page summary instead, and the tutor sees only that. When the adviser downloads the original, the access is logged. A copied link sent to a colleague without access does not open the file. This is a fictional example, and the scanning step is still to be built.

Related guides and next steps

• Data protection and subprocessors
• DPIA for learner support software
• Join the pilot.