Where data is processed
Where is learner data stored? The main database is in London, UK. Sign-in, hosting, files, AI, email and telemetry may run elsewhere. Mapped layer by layer.
Trust centre
Inclusion Studio subprocessors (draft, pre-pilot)
Inclusion Studio subprocessors: the providers we intend to use for learner support data, what each would do, where it runs, and its contract status.
In short
This is a draft list of the providers we intend to use for the Inclusion Studio service. None is processing real learner data, and no subprocessor contract is in place yet. Google Cloud Vertex AI is selected for AI drafting and tested with synthetic data only. Providers for malware scanning, email and monitoring are not chosen.
A subprocessor is a company we would use to help provide the Inclusion Studio service, which may process personal data on behalf of the colleges and training providers who use it. Under UK GDPR Article 28, a processor needs its controller’s authorisation before engaging another processor, and the controller should know who they are. This page is our draft list. We publish it now, before any real data, so that you can assess the plan early.
Is any subprocessor processing learner data now?
No. Inclusion Studio is pre-pilot and holds no real learner data. The production application uses synthetic data only. We have not signed subprocessor agreements for the service yet, and no row below has a service contract in place yet. Vertex AI has been tested with synthetic data only.
Which Inclusion Studio subprocessors do we intend to use?
| Provider | What it would do | Data it would process | Location | Status | Provider’s own information |
|---|---|---|---|---|---|
| Neon (managed PostgreSQL) | Main application database | Learner support records, plans, actions, permissions, audit metadata, file references | AWS Europe (London), aws-eu-west-2 | Intended, contract not yet in place | Security, subprocessors (Databricks list linked by Neon) |
| Clerk | Sign-in, sessions, MFA and account recovery | Minimal identity data, such as name, email and sign-in details. No diagnoses, SEND details or case notes | Clerk describes its service as US-hosted | Intended, contract not yet in place | Security, DPA, privacy |
| Vercel (hosting and functions) | Hosts the application and runs server functions | Requests and responses passing through the application, operational logs | London (lhr1) preferred for supported functions; static files served from a global network | Intended, contract not yet in place | Security, Trust Center, DPA, privacy |
| Vercel Blob (private store) | Stores uploaded documents and generated exports | File contents, such as evidence documents and exports | Region to be selected | Intended, contract not yet in place | As for Vercel above |
| Google Cloud Vertex AI (Gemini models) | Optional AI drafting, reviewed by a person before saving | Today, synthetic test data only. No real learner data has been sent | Preview testing uses an EU multi-region endpoint; the location for real learner data is not decided | Selected; tested with synthetic data in a preview environment only. The live application uses a mock | Vertex AI data governance |
Each provider publishes its own security and privacy information. Their certifications and terms belong to them; they are not certifications held by Inclusion Studio. Each provider also uses its own subprocessors, which we will review as part of our assessment.
Which providers are not chosen yet?
- Malware scanning for uploads: none chosen. Uploads will stay quarantined until a scan passes.
- Transactional email: none chosen for application notifications beyond sign-in emails.
- Monitoring and telemetry: none chosen. Logs are designed to be redacted.
- Background job execution: to be selected after checking runtime limits.
When we select any of these, we will add it here with the same detail.
What about tools that should never hold learner data?
We use GitHub to hold our source code and run automated checks. Our rules say real learner records, production credentials and copies of production databases must never go into the code repository, preview environments or coding tools. GitHub is therefore not intended to process learner data and is not listed as a subprocessor for the service.
What will we check before a provider goes live?
Before any provider processes real learner data, we will:
- sign a data processing agreement that meets UK GDPR Article 28;
- confirm where data is processed, including logs, backups and support access;
- document the transfer mechanism and assess any transfer outside the UK;
- review the provider’s security evidence, retention and deletion terms;
- confirm the provider’s own subprocessors;
- record the outcome in our assessment and update this page.
These steps are part of our assurance roadmap.
How will you be told about changes?
For pilot providers, the contract will set out how we give notice of a new or replacement subprocessor and how you can object. For everyone else, this page will show the date it was last updated. If you have a question about a provider, contact us. For a layer-by-layer view, see where data is processed.
Frequently asked questions
Are any Inclusion Studio subprocessors processing learner data now?
No. Inclusion Studio is pre-pilot, holds no real learner data and has not signed subprocessor agreements for the service yet.
Which subprocessors are intended?
Neon for the main database in London, Clerk for sign-in, Vercel for hosting and private file storage, and Google Cloud Vertex AI for optional AI drafting. None has a contract in place for the service yet.
Which providers have not been chosen?
No provider has been chosen yet for malware scanning, transactional email, monitoring or background jobs. Each will be added here when it is selected. Google Cloud Vertex AI is selected for AI drafting and is listed in the table.
Do provider certifications apply to Inclusion Studio?
No. Each provider's certifications and terms belong to that provider. Inclusion Studio holds no certifications of its own.
Sources and further reading
- Neon security and compliance (Neon)
- Neon regions (Neon documentation)
- Databricks subprocessors list (linked from Neon's security page)
- Clerk security and compliance (Clerk)
- Clerk data processing addendum (Clerk)
- Clerk privacy policy (Clerk)
- Vercel security (Vercel)
- Vercel Trust Center (Vercel)
- Vercel data processing addendum (Vercel)
- Vercel privacy notice (Vercel)
- Generative AI on Vertex AI data governance (Google Cloud)
- Controllers and processors (ICO)
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.