Data protection

The short version

If you only read one section, read this one.

• We ask for a pupil's first name only. No surname, date of birth, address, UPN, photograph or contact detail is requested anywhere in the product, and there is nowhere to attach one.
• The application and its database are hosted in Google Cloud's London region (europe-west2).
• Report text is generated by OpenAI in the United States under Standard Contractual Clauses. Content sent through the API is not used to train their models.
• A teacher can switch on pseudonymised generation, after which no pupil name is sent to OpenAI at all — placeholders go out, and the real name is restored on our own servers.
• Pupil records are deleted automatically on a retention period the account holder sets, defaulting to 24 months after a pupil was last written about.
• Any teacher can erase one pupil, export everything we hold, or delete the account entirely, from inside the product, without contacting us.
• We do not sell data, show advertising to pupils, profile children, or make automated decisions with legal or similarly significant effects.

1. Who is responsible for what

1.1. Where a school buys or authorises Report Alchemy, the school is the data controller and Sagwa Limited is a data processor acting on the school's documented instructions. Those instructions are the ones set out in the Data Processing Agreement.

1.2. Where an individual teacher signs up with a personal account and enters pupil data, the school remains the controller of that pupil data. The teacher is responsible for having their school's authorisation to use a third-party tool for this purpose, and our terms require it.

1.3. For the teacher's own account data — their name, email address, billing record and usage — Sagwa Limited is the controller. That processing is described in the Privacy Policy.

2. What we actually hold

2.1. The table below is exhaustive for pupil data. It is short because the product deliberately collects very little.

2.2. A caution about example reports. The most powerful feature in Report Alchemy learns your format from a report you have already written. If you paste in a real past report, it will contain whatever that report contained, including a child's name. It is stored as your format's example and is sent with each generation. If that matters to you, replace the name in the example with a placeholder before saving it — the format is copied from the structure, not the name.

2.3. We do not request, and the product provides no field for: surnames, dates of birth, addresses, contact details, UPNs or other pupil identifiers, SEN or medical records, photographs, attendance data, or safeguarding records. A teacher could of course type such things into a free-text notes box; nothing prompts them to and we recommend they do not.

3. Where it is processed

3.1. The application, the database and all stored report content are hosted on Google Cloud Platform in the London region (europe-west2).

3.2. Generating a report requires sending the teacher's notes to an AI provider. That provider is OpenAI, L.L.C., in the United States. The transfer relies on Standard Contractual Clauses together with the UK International Data Transfer Addendum. Content submitted through OpenAI's API is not used to train their models.

3.3. The full sub-processor list, including payment and sign-in providers, with the data each receives and where, is maintained at Privacy Policy §4.5. We will give 30 days' notice before adding or replacing a sub-processor that processes pupil data, and a school may object.

3.4. We do not claim that pupil data never leaves the UK. Some competitors do. For that claim to be true of an AI report writer, generation itself must happen on UK infrastructure, which is not the case here. Pseudonymised generation is our answer to the same concern, and it is a stronger one than a location claim: with it on, there is no pupil name in the request at all.

4. Pseudonymised generation

4.1. Any account holder can turn this on from My Pupils. It applies immediately and to every generation afterwards.

4.2. With it on, before anything is sent to OpenAI we replace the pupil's name with a placeholder such as "Pupil A" in:

• the name field itself;
• the teacher's notes for that report;
• the example report attached to the format, for any name matching a pupil on that teacher's list;
• any previous reports used for continuity; and
• the request for AI suggestions, which sends the same form.

4.3. The generated text comes back naming "Pupil A", and the real name is substituted back in on our servers before the teacher sees it. The finished report reads exactly as it would have. The prompt we retain for audit holds the placeholder, not the name.

4.4. What it does not cover. Free text is free text: if a teacher writes a different child's name in a notes box and that child is not on their pupil list, we have no way to know it is a name. The setting removes names we know about, which is every pupil the teacher has written about in this account.

5. Retention and deletion

5.1. Every account has a retention period covering pupil records, teachers' notes and generated reports. The options are 12, 24 or 36 months from the last time a pupil was written about, or deletion at the end of each academic year (31 August). The default is 24 months.

5.2. Writing a new report about a pupil restarts their clock. A child a teacher still teaches is live data; a child not mentioned for two years is not.

5.3. Deletion removes the pupil record, every report generated for them, the teacher's notes behind those reports and any saved AI suggestions. It is immediate and irreversible; there is no soft-delete or recycle bin.

5.4. A school can require a shorter period than the teacher has set, or a specific deletion date for a specific child. A per-pupil deletion date can be set in the product, and we will honour a school-wide instruction sent to admin@report-alchemy.com.

5.5. Automatic deletion begins on 6 September 2026. Accounts created before this policy was published are given notice first rather than having records removed the day the policy appeared. The sweep runs on a schedule from that date.

5.6. Our hosting provider keeps seven automated daily backups of the database, so an erased record can survive in a backup for up to a week before ageing out. Backups are encrypted, are not reachable from the product, and are never used to restore an individual record.

6. Individual rights and requests

6.1. A parent asks the school to delete their child's data. The teacher can do it themselves, immediately: My Pupils → the pupil → delete. They are shown exactly what will be removed before confirming. No request to us and no waiting period.

6.2. A subject access request. A teacher can download everything held on their account as a single JSON file from the same screen. If a school needs this collated across several teachers, write to admin@report-alchemy.com and we will respond within the statutory month.

6.3. Rectification. Pupil names, pronouns, year groups and notes are editable, and duplicate records for the same child can be merged.

6.4. We will notify the school without undue delay, and in any case within 24 hours of becoming aware, of any personal data breach affecting their data, with the detail required for the school to meet its own 72-hour obligation.

7. Security, described honestly

7.1. What is in place:

• All traffic is served over TLS. Plain HTTP is redirected, and we send Strict-Transport-Security with a one-year max-age so a browser will not try HTTP again.
• Authentication is Google sign-in only. We never receive, store or could disclose a password, because there is no password.
• Sessions are server-side: the browser cookie is an opaque identifier pointing at a row in our database, not a payload of user data.
• The database is a managed Cloud SQL instance in London, encrypted at rest. No public network is authorised to connect to it, and unencrypted connections are refused outright — the instance is set to accept encrypted connections only.
• Access to production is limited to named Google accounts belonging to the company's operator; there are no shared logins and no third-party contractors.
• Report data is scoped to the account that created it in every query; there is no cross-account view.

7.2. What is not in place, stated plainly because you would find out anyway: Report Alchemy is a small company and holds no ISO 27001 or Cyber Essentials certification, has not commissioned an external penetration test, and does not offer a bespoke security schedule. If your procurement requires any of these, we would rather tell you now than at the end of a term's trial.

7.3. There is no advertising in the product, no third-party tracking of pupil data, and no pupil-facing surface at all — children never log in and never see the product.

8. The AI, and what it does not do

8.1. Report Alchemy drafts text from notes a teacher has already written. It does not score, rank, predict or profile children, and it makes no decision about a child. The teacher writes the notes, reads the draft, edits it and decides what goes to parents.

8.2. There is therefore no automated decision-making producing legal or similarly significant effects under Article 22 UK GDPR, and no special category data is required by the product.

8.3. Generated text can be wrong. Our own testing measures how often the model asserts something the teacher did not write, and the product is designed around the assumption that a teacher reads every word before it leaves them. The DPIA treats this as the principal risk and sets out the mitigations.

9. Getting an agreement in place

9.1. Our Article 28 Data Processing Agreement is published in full and can be accepted online by someone authorised to bind the school. Acceptance is recorded with the signatory's name, role, organisation and timestamp, and both parties are bound by it from that moment.

9.2. If your school requires its own paper, send it to admin@report-alchemy.com. We will review and sign a standard local-authority or MAT processor agreement.

10. Contact

Data protection enquiries are handled by the company's director; we are below the threshold at which a statutory Data Protection Officer must be appointed.

If you are not satisfied with how we have handled a data protection matter, you can complain to the Information Commissioner's Office at ico.org.uk.