Skip to main content
Trust, data & AI

Data sovereignty and responsible AI, built for national inspectorates.

National inspectorates carry statutory data responsibilities a standard SaaS procurement checklist doesn't cover. This page sets out, plainly, how EDUINSPECT360 is designed to handle data residency, tenant segregation, AI governance and security — including where I stand on the ICO's June 2026 findings on the edtech sector.

Data residency & segregation

Where your data lives, and who can reach it.

For a national inspectorate, "where is the data, and who can touch it" isn't a technical footnote — it's a governance question, agreed before a single record is imported.

Data residency

Agreed in writing, before deployment

Hosting region and data residency are agreed and documented in writing before any client deployment begins — not discovered afterwards. Where a jurisdiction expects in-country hosting, that requirement is scoped at contract stage.

Tenant segregation

Segregation is architectural, not procedural

Multi-tenant segregation is built into the platform, not layered on as policy. Tenant identity is resolved server-side on every read and every write — a query has no code path that could cross a tenant boundary.

Data export

Full export, on request

Your inspection data is exportable in full. It's your data — I don't design the platform to make it harder to take it with you.

No lock-in

Designed to be left, not just joined

No proprietary format is used to trap your records. If you decide to move on, you leave with everything you brought and everything the platform generated on your behalf.

AI governance

AI drafts. A named human approves.

AI has a role in EDUINSPECT360, but it doesn't get the final word. Every AI-generated output requires named human approval before it can affect any published outcome. No AI feature writes directly to a report, a judgement, or a school-facing record.

Every AI invocation — the prompt, the model, the output, and the human who approved or rejected it — is written to an append-only audit log. Nothing in that log can be edited or removed after the fact, so the record of who approved what, and when, is permanent.

AI-drafted content is never presented as though a person wrote it unreviewed — it carries a visible draft marker until a named reviewer has approved it. Personal data is minimised before anything is passed to an AI model for processing.

Named human approval
Append-only audit log
AI drafts clearly marked
PII minimised before AI

Human sign-off, every time

An AI draft becomes part of the record only once a named, accountable person has reviewed and approved it — for every AI-assisted output the platform produces.

Permanent audit trail

Every AI call is logged — input, output, model used, and the approving user — to an append-only table that is never modified after the write.

Clearly marked drafts

AI-generated content carries a visible marker until it has been reviewed, so nobody reading a published output is left guessing which parts were AI-assisted.

Minimisation before processing

Personal data — names, identifying references — is minimised or scrubbed before any content reaches an AI model, and only the data needed for the task is included.

Security posture

Built to the standard, honestly stated.

EDUINSPECT360 is being built to meet Cyber Essentials Plus, SOC 2 Type II and ISO 27001. I would rather tell a procurement or DPO team exactly where that work stands than claim a certification I don't yet hold.

Cyber Essentials Plus

Being built to meet the Cyber Essentials Plus technical control set. Certification status is confirmed in writing before any client deployment.

SOC 2 Type II

Architected with SOC 2 Type II's trust service criteria in mind from the outset, rather than retrofitted later. Status confirmed in writing before deployment.

ISO 27001

Information security management is being aligned to ISO 27001 principles as the platform matures. Status confirmed in writing before deployment.

No certification is claimed until it has actually been achieved and can be evidenced to your procurement or DPO team on request. Where a client requires a specific standard as a deployment condition, that's agreed and confirmed in writing before go-live.

ICO · Edtech examined, June 2026

The ICO's June 2026 audit — and how I'm designing against it.

On 24 June 2026 the ICO published the findings of its audit of the edtech sector. The headline conclusion was reassuring in one respect and pointed in another: information security across the sector was generally strong — the failings the ICO found were governance failings. Six of those are set out below, alongside how EDUINSPECT360 is designed to address each one. These are design commitments, not a claim that every element has already been independently audited.

1 of 6 — Controller / processor confusion

Who is the controller, who is the processor

The ICO found confusion across the sector about who holds controller responsibilities for pupil and staff data, and who is merely processing it on instruction.

How EDUINSPECT360 responds: my role is defined explicitly in the contract — I act as a data processor, processing data only on the documented instructions of the inspectorate as data controller. That distinction is stated in writing, not left implicit.

2 of 6 — Thin or weak contracts

Contracts without clear processing terms

Many edtech contracts the ICO reviewed lacked clear, specific data processing terms.

How EDUINSPECT360 responds: a proper data processing agreement, with clear processing instructions, is available for procurement review before any deployment — it states what is processed, why, and under whose instruction.

3 of 6 — Incomplete data-flow mapping

Not knowing where data actually goes

Providers examined by the ICO often couldn't fully account for where data travelled once it entered their system.

How EDUINSPECT360 responds: what is collected, where it is processed, where it is stored, and who can access it is documented and mappable for your own records — so your DPO isn't taking my word for it.

4 of 6 — Weak data minimisation

Collecting or keeping more than needed

The ICO found data being collected or retained beyond what the stated purpose required.

How EDUINSPECT360 responds: only the data needed for the inspection lifecycle is collected in the first place, and personal data is minimised before it reaches any AI process — minimisation by design, not an afterthought.

5 of 6 — Outdated privacy information

Privacy notices that don't reflect reality

Privacy information across the sector was often stale, or didn't reflect current processing activity.

How EDUINSPECT360 responds: privacy information is maintained and reviewed, and provided to you directly so you can meet your own transparency obligations to schools, staff and pupils.

6 of 6 — DPIA gaps

Missing or incomplete impact assessments

Data protection impact assessments were frequently missing or incomplete for the tools the ICO examined.

How EDUINSPECT360 responds: I support your DPIA with documented processing detail rather than leaving you to reverse-engineer it from a product demo. A DPIA is expected before any deployment, and I provide what's needed to complete it properly.

Looking ahead: the ICO has said it is discussing a statutory code of practice for edtech with the Department for Education. No such code exists yet. I intend to track its development and align EDUINSPECT360 to it as it takes shape, rather than wait for it to become mandatory.

Want the documentation before you talk to your DPO?

I can share the data processing agreement, the data-flow documentation, and the AI governance detail your procurement team will ask for — directly, and before you commit to anything.