For school leaders and data protection officers

Controller and processor

The school is the data controller for pupil personal data. Ribn is the processor, and acts only on the school’s documented instructions. That is the standard position for a schools platform, and it is the one we have designed to rather than one we have argued our way into.

A data processing agreement on those terms is being finalised, and it will be published on this page before the first pupil account exists. We would rather say that than publish a document we would have to withdraw.

What we hold about a pupil

A pupil record holds an identifier, a name, a username, a year group and a password hash. There is no date of birth, no email address, no photograph, no postcode and no free text profile. Every additional field has to be argued for, and there is a database constraint rather than a policy stopping one being added quietly.

Beyond that we hold the work: a pupil’s responses, the marks the engine produced and the record of who approved what. Those exist because they are the homework.

Where the data lives

Pupil data is held in the United Kingdom, in a Postgres database hosted in the London region. Tenant isolation is enforced by Row Level Security in the database itself rather than by application code, which means a request carrying a valid session for one school cannot read another school’s rows even if the application asks it to.

Sub-processors

The current list is short, and it will be published in full with the data processing agreement. Today it consists of our database and application hosting, and our payment processor. Two rules constrain it:

• Pupil personal data is never sent to a third-party model provider. A model may draft the wording of a question. It never sees a pupil, a response or a mark.
• Pupil personal data never touches the payment processor. Billing is on teacher seats, so no child is a line item on an invoice.

Marking, and what a model is allowed to do

A model never writes an answer key, a mark, a diagnosis or a release decision. It may draft the wording of a question, the plausible wrong answers and the explanation prose. The answer key is computed by a deterministic marking engine, checked against the question’s own tests, and approved by a teacher before a pupil sees it. That is a build rule with tests behind it, not a statement of intent.

Security posture

• Marking runs on the server. The browser is never trusted with a mark or a key.
• Approvals, mark overrides, exports and account changes are written to an append-only audit log.
• Secrets are held in a secret manager and never in the code or in the browser.
• Every change goes through automated checks for type errors, module boundaries, tenant isolation and accessibility before it can be merged.

We hold no security certification, and we are not going to imply one. If your procurement process needs a completed supplier questionnaire, ask and we will complete it.

Accessibility

We build to WCAG 2.2 AA, and a keyboard route ships in the same change as the pointer route or the component does not ship. The accessibility statement says what has been tested and what has not, accurately, per Government Digital Service guidance.

Integrations

Version 1 imports a class list from a CSV. Automatic roster synchronisation from a management information system, and single sign-on, are planned and are not in version 1. Saying so here is cheaper for both of us than finding out in week two of the autumn term.

Getting your data back

A school can export its own data at any time, in a documented format, without asking us. When a subscription ends, the school keeps the export and we delete the rest on a published schedule. The schedule will be published with the data processing agreement.

Pricing for a whole school or a trust

Departmental prices are on the pricing page. A whole school, or a multi-academy trust, is priced on the number of departments rather than on the number of pupils.