Data Processing Agreement

1. Definitions

"UK GDPR" means Regulation (EU) 2016/679 as it forms part of UK law by virtue of the European Union (Withdrawal) Act 2018. "Data Protection Law" means the UK GDPR and the Data Protection Act 2018, as amended (including by the Data (Use and Access) Act 2025). "Personal Data", "Process", "Controller", "Processor", "Sub-processor", "Data Subject" and "Personal Data Breach" bear the meaning given in the UK GDPR. "Service" means the Digital Shields Schools Portal. "Licence Terms" means the School Licence Terms at /schools/terms. "Annexes" means the three Annexes attached to and forming part of this DPA.

2. Subject matter and duration

The Processor will Process Personal Data on behalf of the Controller for the sole purpose of providing the Service. Processing lasts for the Controller's licence and ends when the Controller's data is deleted at its end: the Controller's school is cancelled 30 days after its licence end date unless the licence is renewed, and all Personal Data is permanently deleted 30 days after that, by the Processor's automated retention job (Annex I, H). Until deletion the Controller can download all its data (section 4.9).

3. Nature and purpose of Processing

Hosting, storage, transmission, retrieval, organisation, structuring, consultation and erasure of staff personal data and the records the Controller keeps in the Service (such as CPD records, policy reviews and filtering logs) for the purposes set out in the Controller's DPIA (a starter template is available to school admins at /api/schools/procurement/dpia). Full details of categories, retention and recipients appear in Annex I.

4. Obligations of the Processor

The Processor will:

1. Instructions. Process Personal Data only on the documented instructions of the Controller, including with regard to transfers to third countries, unless required to do so by UK law, in which case it will tell the Controller of that legal requirement before Processing unless that law prohibits it. The Controller's instructions are this DPA, the Licence Terms, the Controller's use and settings of the Service, and anything it asks in writing to dpo@digitalshields.co.
2. Unlawful instructions. Tell the Controller immediately if, in its opinion, an instruction infringes Data Protection Law.
3. Confidentiality. Ensure that everyone it authorises to Process the Personal Data is bound by a written duty of confidentiality (or an appropriate statutory one), and has access only as far as their work needs.
4. Security. Implement the technical and organisational measures in Annex II, as Article 32 UK GDPR requires.
5. Sub-processors. Engage Sub-processors only with the Controller's general authorisation as in section 7; impose on each, by written contract, data protection obligations equivalent to those in this DPA (in particular sufficient guarantees of appropriate technical and organisational measures); and remain fully liable to the Controller for each Sub-processor's performance of those obligations.
6. Data Subject rights. Assist the Controller, taking into account the nature of the Processing, by appropriate technical and organisational measures, in responding to requests from Data Subjects to exercise their rights (Articles 12 to 22): through the Service's self-serve tools (the Controller's full data export; one pupil's records as a file or a print page for a subject access request; correction and deletion of records) and, where those aren't enough, on request. If a Data Subject contacts the Processor directly about the Controller's data, the Processor will pass the request to the Controller without undue delay and will not answer it except on the Controller's instructions.
7. Security, breaches and DPIAs. Assist the Controller in complying with Articles 32 to 36 (security, notifying Personal Data Breaches, data protection impact assessments and prior consultation with the ICO), taking into account the nature of the Processing and the information available to the Processor, including by providing the DPIA template, this DPA's Annexes and answers to reasonable questions.
8. Personal Data Breaches. Notify the Controller as in section 8.
9. End of the Service. At the end of the licence, at the Controller's choice, return the Personal Data (the Controller's full data export, available to its school admins in the Service until the school is cancelled and then on request to dpo@digitalshields.co until deletion) and delete it as in section 2, and delete existing copies, unless UK law requires the Processor to keep them. Copies in the encrypted backups expire within 30 days of deletion.
10. Information and audits. Make available to the Controller all information necessary to demonstrate compliance with Article 28 UK GDPR and this DPA, and allow for and contribute to audits, including inspections, by the Controller or an auditor it mandates. The Processor will answer a written questionnaire (the usual way) and provide evidence of its certifications; an inspection is on at least 30 days' notice, at most once a year unless a Personal Data Breach or a regulator requires otherwise, during working hours, under a duty of confidentiality, and at the Controller's cost unless it shows a material breach of this DPA. The Processor will tell the Controller if it believes an audit request infringes Data Protection Law.
11. Requests from public authorities. If a government body, regulator or law enforcement agency asks the Processor for the Controller's Personal Data, the Processor will refer it to the Controller where possible, tell the Controller promptly unless the law prohibits it, challenge any request it reasonably believes unlawful or too broad, and disclose only the minimum the law requires.
12. No other use. Not sell the Personal Data, or use it for its own purposes, for marketing, for profiling Data Subjects, or to train any AI model.

Careers

The Processor does not use pupils' personal data for its own purposes, including analytics about individual pupils, product development, training any model, marketing or sharing with any third party.

Where the Controller turns on sign-in with Google or Microsoft, those providers act as the Controller's own identity providers under the Controller's agreements with them; the Processor receives only the provider's account identifier and the school domain or tenant needed to check it.

The Controller's data export leaves out what only the pupil sees (answers to the interests questions, and CVs while teacher comments are off); each pupil can download their own from their Account page.

5. Obligations of the Controller

1. Ensure that there is a valid lawful basis for the Processing under Article 6 UK GDPR (and Article 9 where special category data is concerned) before submitting Personal Data to the Service, and give Data Subjects the information Articles 13 and 14 require.
2. Issue clear instructions to its staff regarding the use of free-text fields and filtering imports (pupil usernames or initials only — no full pupil names). Pupils' names may be entered in pupil lists and assessment records; notes and comments are about learning only.
3. Maintain accurate records of staff who have access to the Service and remove access promptly when a staff member leaves the school.
4. Keep its school admins' email addresses in the Service up to date: notices under this DPA (including of Personal Data Breaches and Sub-processor changes) go to them.
5. Comply with its own information-security obligations on the Controller side of the trust boundary (device security, password hygiene, network access).

6. Where the data is, and international transfers

The Service and its database are hosted by Railway Corporation in the United States (Railway, US West) (transfer safeguard: UK International Data Transfer Addendum to EU SCCs). The encrypted daily backups are held by GitHub Inc in the USA. Each Sub-processor's location and transfer safeguard is in Annex III: for transfers to the USA, the ICO's UK International Data Transfer Addendum to the EU Standard Contractual Clauses (section 119A of the Data Protection Act 2018) or, where the provider is certified, the UK Extension to the EU-US Data Privacy Framework, with the technical measures in Annex II (encryption in transit and at rest, minimisation). The Controller authorises these transfers. The Processor will tell the Controller at least 30 days before the hosting location changes, as for a Sub-processor change (section 7).

7. Sub-processors

The Controller gives the Processor general authorisation to engage the Sub-processors listed in Annex III. For any addition, replacement or change of location, the Processor will give the Controller at least 30 days' prior written notice, by email to its school admins and under Compliance in the Service, and no Personal Data will go to a new Sub-processor before then. If the Controller objects on reasonable data protection grounds before the change takes effect, the parties will discuss it in good faith; if they can't resolve it, the Controller may end the affected part of the Service on notice, with a refund of the fees for the unused part of the licence year.

8. Personal Data Breach

The Processor will notify the Controller of any Personal Data Breach affecting the Controller's Personal Data without undue delay, and in any event within 72 hours of becoming aware of it, by email to the Controller's school admins. The notice will give, as far as known, the information Article 33(3) UK GDPR requires (what happened, the categories and approximate numbers of Data Subjects and records, the likely consequences, and the measures taken or proposed), with further information as it becomes available. The Processor will take reasonable steps to contain and remedy the breach, and will cooperate with the Controller on any notification to the ICO or to Data Subjects, which is the Controller's decision.

9. Liability

Each party's liability under this DPA is subject to the limits in section 17 of the Licence Terms, including the separate limit there for data protection claims. Nothing in this DPA limits either party's liability for its own breach of Data Protection Law to the extent it cannot be limited by law, or for death or personal injury caused by negligence, or fraud.

10. Precedence

If anything in the Licence Terms, or in any other agreement between the parties, conflicts with this DPA on the Processing of Personal Data, this DPA prevails.

11. Changes to this DPA

The Processor may update this DPA by giving the Controller's school admins at least 30 days' notice; a school admin is then asked to accept the new version. If the Controller doesn't accept, it may end the licence before the change takes effect, with a refund of the fees for the unused part of the licence year. Changes required by law may take effect sooner.

12. Governing law

This DPA is governed by the laws of England and Wales. The Parties submit to the jurisdiction of the courts of England and Wales, save that a Controller in Scotland or Northern Ireland may bring proceedings in its own courts, and a Controller that is a public body retains any statutory right to a different forum.

13. Acceptance

A school admin accepts this agreement on the school's behalf with the School Licence Terms, when buying online or when they next sign in to the schools portal. The record is shown here and under Compliance in the portal.

For a signed copy only (optional):

Annex I — Description of the Processing

A. Parties

B. Subject matter of the Processing

Provision of the Digital Shields Schools Portal: a UK online-safety teaching and safeguarding resource library, plus optional features for CPD tracking, PSHE curriculum delivery tracking, assessment and reporting across the curriculum, a careers area for pupils and careers records for the school, threat-alert acknowledgement, policy review and filtering-event logging.

C. Duration of the Processing

For the Controller's licence, and until its data is deleted at the end (section 2): the school is cancelled 30 days after its licence end date unless renewed, and everything is deleted 30 days after that.

D. Nature and purpose of the Processing

Collection, hosting, storage, organisation, structuring, retrieval, consultation, transmission and erasure of Personal Data for the purposes of: enabling staff to authenticate; recording CPD progress; recording which PSHE lessons each class has been taught, the PSHE lead's monitoring and pupils withdrawn from sex education; recording teachers' PSHE assessments for the pupils in each class; assessment and reporting across the curriculum (curriculum maps, pupils' groups and moves, teachers' assessments and notes about learning in every subject, and report comments); providing a careers area for pupils and careers records for the school (careers programme, encounters, workplace experiences, personal guidance and destinations); recording staff acknowledgement of threat alerts; recording policy reviews; keeping the school's filtering and monitoring records; transmitting service emails and summary digests.

E. Categories of Data Subjects

• School staff (Designated Safeguarding Lead, Head, Senior Leadership, teachers, support staff).
• Pupils — in filtering records only as a device or user code or a keyed pseudonym, and by initials alone in records of withdrawal from sex education; and by name in the class lists the Controller adds for PSHE teacher assessment. The Controller is instructed not to enter pupil full names or other direct identifiers into free-text fields.
• Pupils — by name across subjects, for assessment and reporting across the curriculum: the Controller's pupil list, with an optional MIS internal id, and the pupils' groups, teachers' assessments, notes about learning and report comments.
• Pupils in Years 7 to 11 (and Years 12 and 13 in schools with a sixth form) as users of the careers area.

F. Categories of Personal Data

• Staff identifiers: full name, work email address, role designation.
• Authentication data: bcrypt-hashed password, two-step verification secrets and hashed backup codes (required for school admins, optional for other staff unless the school requires it for everyone), session tokens (HttpOnly cookies).
• Activity data: last-active timestamp and resource access logs (which member of staff opened a resource, and when each last used the Service, are recorded and shown to the Controller only while the Controller has turned on staff activity tracking, and only from the date it was turned on), CPD completion records, CPD library quiz attempts and certificate codes, required modules, CPD topic requests, alert acknowledgements, policy review timestamps, failed sign-ins (email address, reason, IP address).
• Notes: Controller-authored free text on threat-alert and policy reviews, and suggestions staff send the Processor.
• PSHE curriculum records: class names and year groups, the staff who teach each class, lessons ticked as delivered (date and who recorded it), book looks, and pupils withdrawn from sex education (initials only, per class).
• PSHE teacher assessment: pupils' names in each class list, and the teacher's assessment for each pupil in each PSHE unit on the Controller's own scale, with who recorded it and when.
• Filtering records: the user as a device or user code (kept as imported) or a pseudonym made with a key unique to the Controller (names and logins are replaced on import), the site and page visited (no query string) or the search term (cut to 80 characters, email addresses masked), event type, the action taken, the time and any note. An import that looks like it names a pupil next to a year group is refused.
• Assessment and reporting across the curriculum: Pupils' names, an optional MIS internal id, current year group, group memberships and moves with dates, teacher assessments in each subject over the years (unit, termly and data-drop grades, targets, and grades of 1 to 4 against each statement of the curriculum, with who recorded each and when), teachers' notes about learning, report comments, and, only if the school turns them on, pupil premium, SEND and EAL flags (yes or no, no detail of need). No UPNs, dates of birth, addresses, ethnicity or religion.
• Careers: pupils' sign-in details (a username made by the platform and a password stored only as a one-way hash, or, if the school turns it on, a link to the pupil's school Google or Microsoft account held as that provider's opaque account id; no email address), one-time claim codes stored only as a one-way hash, the pupil's answers to an interests questionnaire and the interest areas it suggests, careers they save, their CV (what they choose to write: an 'about me', education, skills, experience, achievements and interests; contact details only if the pupil ticks Remember), their action plan (goals, routes they are considering, Year 9 options thinking, Year 11 intended destination and applications), staff comments on CVs when the school turns comments on, personal guidance records (date, adviser, agreed next steps), workplace experience entries naming pupils, and destination records. No dates of birth, addresses, photos or special category data are asked for.
• The Controller's acceptance of this DPA and the Licence Terms: the accepting school admin's name, role and job title, the versions and the time.

G. Special categories of Personal Data

Where the Controller turns on pupil flags, a yes/no SEND indicator, which may reveal health information. The Controller determines the Article 9 condition; the Processor processes it only to show the Controller's senior leaders anonymised group comparisons, and to show the senior leader importing a flags file the matches before they are saved.

Otherwise none expected. The Processor instructs the Controller not to enter special-category data (Article 9) into free-text fields. If a Controller wishes to record special-category data, it must perform its own DPIA and identify a separate Article 9(2) lawful basis.

H. Frequency and retention

Continuous during the licence. These periods are enforced by an automated job that runs every night:

• Everything: deleted 30 days after the school is cancelled. A school is cancelled 30 days after its licence end date unless renewed, when a school admin closes the account, or after 11 months' suspension. Every school admin is emailed 30 and 7 days before deletion.
• Pupils' records: Pupils' records are deleted 365 days after the Controller marks them as left (the Controller sets this period, between 30 and 1,095 days; never sooner than 14 days after).
• Filtering records: 12 months from the event (the Controller's setting, 3 to 24 months).
• Resource access log: 24 months. Failed sign-ins: 90 days. Audit trail: 6 years; entries about the security of the Service (accounts, two-step verification, exports and deletions of personal data) are kept after that with names, email addresses and free text removed. When the school is deleted, its staff's entries are pseudonymised at once.
• Careers: A pupil's careers account and the work in it are deleted 30 days after the Controller marks the pupil as left; destination records are deleted with the pupil's record and kept after that only as counts; all Careers data 30 days after the Careers add-on ends (pupils' work) or with everything else at the end of the licence.
• AI drafting counts: 400 days. MIS sync logs: 180 days.
• Backups: encrypted daily database backups are kept for 30 days, then deleted.

Annex II — Technical and Organisational Measures (TOMs)

The Processor implements the following measures in compliance with Article 32 UK GDPR:

1. Access control and authentication

• Role-based access control: school_admin vs staff roles with route-level authorisation checks server-side; no school can see another's data, except a trust's view of schools that choose to share with it.
• Passwords are stored as bcrypt hashes (cost factor 12); plaintext passwords are never written to disk or logs.
• Session tokens are signed, carried in HttpOnly + Secure + SameSite=Lax cookies, checked against the database on every request, and ended everywhere when a password changes.
• CSRF protection via double-submit cookie pattern on every state-changing endpoint.
• Rate limiting on authentication endpoints and across the API, with a lockout after repeated failed sign-ins, to mitigate automated abuse and credential stuffing.
• TOTP two-factor authentication (RFC 6238) for staff accounts, with single-use backup codes issued at enrolment.
• Role-based access by subject for pupils' records. Teachers see the pupils they teach this year, in the subjects they teach, with those pupils' earlier records made in groups the teacher taught and last year's summary level; a teacher whose pupil moved out of their group this year keeps that group's records. For subjects with statements, a pupil's current teacher in that subject sees the pupil's whole statement passport for the key stage, including grades from earlier years, so it can be carried forward. Form tutors, and primary class teachers, see the whole profile of the pupils currently in their group, across subjects and years, and staff who manage a group's members can add pupils to it. PSHE class teachers keep their own past classes' PSHE lists and assessments. Subject leads see their subject, and senior leaders and admins see everything.
• Small-number suppression: any group comparison with fewer than 6 pupils is hidden, and pupil flags are shown only as anonymised group comparisons to senior leaders.
• Careers: pupils' passwords (bcrypt, cost factor 12) and one-time claim codes stored only as one-way hashes; pupils' sessions signed with their own key, separate from staff sessions; a lockout after 5 wrong passwords and a new card after 3 lockouts in a day; no third-party scripts in the pupil area.

2. Encryption

• All traffic to and from the Service is encrypted with TLS (Cloudflare at the edge, then to the hosting provider), with HTTP Strict Transport Security.
• Connections from the application to the database use TLS.
• The database is stored on the hosting provider's (Railway) infrastructure, which encrypts data at rest.
• Daily database backups are encrypted with age (public-key encryption) before they leave the build server; only the encrypted file is stored, with GitHub, for 30 days; the private key is held offline by the Processor.
• Any MIS access token issued for the Controller is encrypted with AES-256-GCM, bound to the Controller's account, and never shown again once saved.
• Filtering records' pupil identifiers are pseudonymised with HMAC-SHA256 and a key unique to the Controller, which is never shown or exported.

3. Application security

• HTTP security headers via Helmet (Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) and a strict Content-Security-Policy on the portal.
• Parameterised SQL queries throughout — no string concatenation into the database driver.
• Dependencies are checked on every change: the pull request checks fail on any high or critical advisory in a production dependency (npm audit), CodeQL static analysis runs on every pull request, and Dependabot proposes dependency and GitHub Actions updates weekly.
• Input validation server-side on every endpoint; output escaping on all user-supplied strings rendered to HTML.
• Stripe payment data is handled exclusively via Stripe-hosted Checkout / Customer Portal — no card data ever touches our servers.
• AI minimisation: report comment drafting is off unless the Controller turns it on, and then sends only a pupil's confirmed first name, year group, subject and assessments, and, for subjects with statements, the labels of the strengths and next steps a teacher ticked from the pupil's passport (no surname, notes, flags or group names); a teacher signs off every comment.
• No analytics or third-party scripts in the schools portal.

4. Logging and audit

• An audit trail of administrative actions in the admin_audit table (who, what action, on what, when), kept as in Annex I, H. Each entry is linked to the one before it by a hash, so a changed or deleted entry is detectable, and a signed fingerprint of the trail is emailed to the Processor's owners daily.
• Failed sign-ins logged to login_issues (email address, reason, IP address) for security monitoring, kept 90 days.
• Server logs, held by the hosting provider, carry record ids only: never names, email addresses, passwords, tokens or request bodies.

5. Resilience and recovery

• Daily automated database backups, encrypted, kept 30 days.
• Stateless application servers, redeployed and restarted by the hosting provider's managed platform.
• Sub-processors selected for compliance with the same data-protection standards (see Annex III).

6. Personnel

• The Processor is operated by a small founder-led team (fewer than 5 staff at the date of this DPA).
• All staff with access to production systems are subject to written confidentiality obligations, and have access only as far as their work needs, with two-step verification on team accounts.
• Secrets (database URLs, API keys, signing keys) are held as environment variables with the hosting provider and as GitHub Actions secrets — never committed to source control.

7. Sub-processor management

• Each Sub-processor is bound to written terms providing equivalent data-protection obligations (see Annex III for the legal-basis-for-transfer column).
• The list is kept in the Service's code and versioned; changes are notified to every school admin by email at least 30 days in advance and shown under Compliance, and the Service sends nothing to a new Sub-processor before its notice period ends.

8. Incident response

• Personal Data Breach notification without undue delay, and within 72 hours at the latest, to the Controller's school admins (section 8).
• Source-code change-tracking via Git; production changes are deployed only through pull requests into a protected branch.

9. Data deletion

• An automated job runs every night and enforces the retention periods in Annex I, H, deleting a cancelled school and everything that belongs to it 30 days after cancellation.
• Self-serve account closure (DELETE /api/schools/account) for school admins; it cancels the school at once and starts the same 30-day window.

10. Independent security certifications and monitoring

Cyber Essentials certified — issued by IASME Consortium Ltd (the NCSC-appointed certification body) confirming that the Processor meets the five technical controls required by the UK government's Cyber Essentials scheme (firewalls, secure configuration, user access control, malware protection, security update management). Certificate number 455d8005-7a64-4e20-99e2-1ae94d37d797, certified 3 June 2026, valid until 3 June 2027.

The Processor is also enrolled in the UK National Cyber Security Centre's free Active Cyber Defence programme, providing independent monitoring over and above our own controls:

• NCSC Early Warning — receives alerts when threats are detected against our domain or IP addresses on public threat-intelligence feeds.

A copy of the Cyber Essentials certificate and assessor's feedback report is available to school DPOs on request via support@digitalshields.co.

Annex III — Authorised Sub-processors

Effective 2 November 2026 (list version 1). The Processor will give not less than 30 days' written notice of any change to this list (section 7).

The "International transfer safeguard" column states the ICO-approved instrument relied upon for each transfer to a country outside the UK. Anthropic PBC deletes the inputs and outputs it receives within 30 days under its commercial terms (or up to 2 years for content its automated systems flag for a breach of its usage policy), and does not use them to train its models. The Processor keeps each Sub-processor's data protection terms and will make them available to the Controller on reasonable request.