Security and data protection

Security your IT lead
can sign off in one read.

Most school platforms make an IT lead extract this from a sales call and a questionnaire. Here it is on one page, in the order a data protection officer actually asks.

The short version Hosted in the UK, on your own instance and your own database

Your school’s data is held in the United Kingdom. Not a shared table with a school identifier in it either: separate application instance, separate database, separate encryption key. Nothing your school stores is co-mingled with another school’s rows.

Architecture and access

Security built into
the architecture, not bolted on.

Everything in this section is implemented and running in the product today. None of it is a policy document; all of it is enforced by the platform itself.

01

UK-hosted and single-tenant

Your instance is hosted in the United Kingdom, and each school runs as its own application instance against its own database with its own instance key. Isolation is structural rather than a filter applied at query time, which is the failure mode behind most cross-tenant data incidents.

02

Fifty-two permissions, each a sentence

Rights are individually assignable across eight named areas, each written in language a governor could read, such as “manage medical records” or “safeguarding exports and disclosure”. Schools compose their own roles. The whole map can be printed for an auditor.

03

An access review that takes two people

Performing a rights review and approving one are separate permissions. The review screen enumerates every member of staff, every role and every right, and distinguishes rights granted directly from rights inherited through a role. If you have ever had an access-recertification finding, this is the screen that closes it.

04

Two-step sign-in, enforced by permission

“Everyone who can open a safeguarding record must use two-step sign-in” is a setting, not a policy document. Enforce by user type, by permission held, or per named person, with a device-trust window you choose. Time-based codes and email one-time codes are both supported.

05

Sign-in with the accounts you already run

Microsoft and Google sign-in are supported and handled centrally, so there is no application to register in your own tenant. Passwords, where used, sit behind the same multi-factor rules.

06

Audit that survives an argument

Changes are recorded with the object, the action, the user, the time and the version. Safeguarding goes further: nothing is deleted, every edit writes a new version with a reason, versions are cryptographically chained, viewing case content is itself logged, and an administrator can re-verify the whole chain on screen.

The AI question

AI with hard boundaries,
set at the database.

Ask Your Data runs as a database login that is granted read access to a set of purpose-built reporting views and is explicitly denied everything else. Safeguarding records, medical records, stored credentials, message contents and survey free text have no view in that catalogue, so they cannot be reached at all. Not restricted: absent. Writing is not blocked by a rule; the login cannot do it.

On what leaves your instance, the precise answer has two halves. When the assistant shows you a table or a chart, our server runs the query and sends those rows straight to your browser: the AI model never sees them. Where the assistant needs to reason over data to write an answer in words, a capped and minimised result set is sent to the model, and every such exchange is logged so your DPO can see exactly what moved and when.

Read-only at the database, not by policy Safeguarding and medical excluded by omission Every question and generated query logged
Biometrics Optional, and never the only way in

Fingerprint readers are optional and cards or PINs are always available. Where a school uses biometrics with pupils, UK law requires notice to each parent, the written consent of at least one, and it gives the pupil their own effective veto with a reasonable alternative. We help you design that consent process as part of deployment, so the paperwork is settled before the first reader is enrolled.

Before anything goes live

Four things you get
in writing.

Every deployment starts with a set of written positions your DPO can file, so the procurement questionnaire answers itself.

A data processing agreement before go-live

Controller and processor roles, the processing description, data categories, retention positions and the named sub-processors, agreed and signed before a single record moves. Your DPIA gets real answers, and we expect follow-up questions rather than sending a brochure.

UK hosting, named in the agreement

Your instance is hosted in the United Kingdom, and the hosting arrangement is written into your data processing agreement rather than left as a website claim. If your governors want it on paper, it already is.

Exit terms you can read before you sign

Data export in open formats, the notice period and the deletion timetable are contract terms, not a support ticket at the end. A supplier confident in its product has no reason to lock the door, and putting the exit in writing on day one is the clearest way to say so.

Support access, governed and logged

Who at our company can access what, under which circumstances, and what gets logged is set out in the data processing agreement. Safeguarding case content goes further: an impersonated support session is refused by the system itself, so our own staff are locked out of your most sensitive records by architecture, not by policy.

For the DPO

The questions that
usually come by email.

If yours is not here, send it. A technical call with no sales content in it is often the fastest route through a procurement.

[email protected]
Who is the controller and who is the processor?

In a customer deployment the school or trust normally determines why and how personal data is used and acts as controller; ISA Education Technologies normally acts as processor under the customer agreement and data processing terms. The precise roles depend on the services taken and are set out in writing.

Will you support our DPIA?

Yes. We provide the processing description, data categories, retention positions, sub-processor list and security measures your DPO needs to complete one, and we expect to answer follow-up questions rather than send a brochure.

What happens to our data if we leave?

You get it out in open formats, and the notice period, export window and deletion timetable are contract terms agreed before you sign rather than a conversation you have at the end. Ask us for the exit terms at the first meeting.

How do you verify the safeguarding record has not been tampered with?

Every version of a safeguarding record is cryptographically chained to the one before it, and an administrator can re-verify the entire chain on screen at any time. A change made outside the system fails the check and shows exactly which row. It is the difference between an audit log you trust and one you can test.

Do you train AI models on our school’s data?

Our own systems do not. For the third-party model used by Ask Your Data, the retention and training position is confirmed in writing for your deployment as part of the data processing agreement, so your DPIA cites a document rather than a verbal assurance.

How is the physical hardware secured?

Door controllers sit on your own network rather than being exposed to the internet, and continue operating during an outage. Reader estate health is monitored and outages are reported. Placement, network segmentation and remote-management arrangements are agreed as part of the site survey.

Book the technical call before the demo.

Thirty minutes, your IT lead and your DPO, no sales content. In our experience that call decides more procurements than the product demonstration does, and it is better to have it early.

Book a technical call