The Data Processing Agreement (DPA) is the contract a school signs when it adopts any third-party ed-tech tool that handles pupil data. Under UK GDPR — specifically Article 28 — a DPA is legally required whenever a data controller (the school) engages a data processor (the ed-tech provider). Signing one is not optional.
In practice, most schools sign DPAs without reading them in any meaningful way. The document is long (typically 15–25 pages), written in legal language, and arrives at the end of a sales process when the decision has effectively already been made. The school's Data Protection Officer, if they have one, may review it — but many primary schools don't have a dedicated DPO, and the review is done by a headteacher or business manager who may not know what to look for.
This is a problem. Ed-tech DPAs vary dramatically in the protections they offer schools and pupils. A poorly drafted DPA can expose a school to liability, allow a vendor to use pupil data for purposes the school hasn't consented to, and create gaps in the school's own compliance obligations. Here are the five clauses that matter most.
Clause 1: Purpose Limitation — What Is the Data Actually Used For?
UK GDPR Article 5(1)(b) requires that personal data be collected for specified, explicit, and legitimate purposes, and not used in ways incompatible with those purposes. In a DPA, this appears as the purpose limitation clause: a description of what the processor will and won't do with the data you give them.
The critical question is whether the clause is specific enough. A DPA that says "we will use data to provide educational services" is meaningless. A DPA that says "we will use data solely to deliver the contracted platform functionality to registered pupils within your school, and will not use it for product improvement, model training, research, or marketing without a separate written agreement" is useful.
Watch out specifically for: the use of "improvement of our services" as a stated purpose. This phrase, common in US-originating DPAs, is often interpreted by vendors to include using pupil response data to train machine learning models. If your provider processes UK pupil data and trains models on it, those models constitute a new processing of data — which requires its own legal basis. Ask explicitly whether pupil data is used for model training. If the DPA doesn't prohibit it, assume it happens.
Clause 2: Sub-Processor Lists — Who Else Is Touching the Data?
Most ed-tech platforms don't store or process all data themselves. They use sub-processors: cloud hosting providers (AWS, Google Cloud, Azure), analytics tools (Mixpanel, Amplitude), error tracking tools (Sentry, Datadog), email services (Sendgrid), and more. Under UK GDPR Article 28(2), a processor must get written authorisation from the controller before engaging sub-processors.
The DPA should either name sub-processors specifically or reference a publicly accessible sub-processor list maintained by the vendor. Clauses that simply say "we may engage sub-processors who meet adequate data protection standards" without naming them provide no meaningful control. You're signing away your ability to know who has access to your pupils' data.
For UK-based schools, an additional consideration is sub-processor location. Post-Brexit, transfers of personal data to countries outside the UK require either adequacy regulations or appropriate safeguards. If your ed-tech provider's sub-processors include companies in the US, India, or other non-adequate countries, the DPA should specify the transfer mechanism (Standard Contractual Clauses, binding corporate rules, or another Article 46 mechanism). If it doesn't, you may be in breach of UK GDPR by using the service.
Clause 3: Retention and Deletion — What Happens When You Leave?
Schools change ed-tech providers. Students leave. DPAs must specify how long data is retained and what happens to it when the contract ends or a school terminates its account.
The clause to look for: "Upon termination of the agreement, processor will either return all personal data to the controller in a portable format within 30 days, or delete all personal data, at the controller's election." Any DPA that doesn't specify a deletion or return timeline is a risk — if the vendor retains data indefinitely post-termination, you have no way to fulfil your own retention obligations or respond to a subject access request from a former pupil.
Also check: backup retention. Some providers commit to deleting live data promptly but retain backups for 90 or 180 days. The DPA should specify whether the deletion commitment includes backups and if not, what the backup retention schedule is. It's reasonable for a vendor to retain backups for 30 days; it's less reasonable (and harder to justify under UK GDPR) to retain backup copies of pupil data for six months after account closure.
Clause 4: Security Measures — What Does "Appropriate" Actually Mean?
UK GDPR Article 32 requires both controllers and processors to implement "appropriate technical and organisational measures" to secure personal data. DPAs typically include a security clause that lists these measures. The clause is often close to useless because it lists measures without specifying the standard to which they're implemented.
Phrases like "we implement industry-standard encryption" and "we use secure development practices" mean nothing. Encryption of what, at rest or in transit, with what algorithm? What does "secure development practices" mean in practice — do you do penetration testing? How often? By whom?
The things that actually matter: Is data encrypted at rest (not just in transit)? At what standard? (AES-256 is the current minimum acceptable for sensitive data.) Is the encryption key managed by the vendor or by the customer? Is access to pupil data restricted by role, and is access logged? Has the platform been penetration-tested by a third party, and is a summary report available on request? Does the vendor have ISO 27001 certification or equivalent?
A vendor that can answer all of these questions specifically is a vendor that has thought seriously about security. A vendor that can only provide generic assurances probably hasn't. The DPA is where these specifics should be anchored.
Clause 5: Breach Notification — How Fast Will You Know?
Under UK GDPR Article 33, controllers must notify the ICO of a personal data breach within 72 hours of becoming aware of it. To do that, the controller needs to know about the breach. The DPA must specify how quickly the processor will notify the controller of a breach.
The standard clause is "without undue delay, and no later than 48 hours after becoming aware of a breach." This is what the ICO's guidance recommends and what schools should insist on. Some DPAs say "within 72 hours" — which barely leaves enough time for the school to assess the breach and make its own ICO notification. Some say "within a commercially reasonable period," which is meaningless.
The notification clause should also specify what the notification must include: the nature of the breach, the categories and approximate number of data subjects affected, the categories and approximate number of records affected, the contact details of the DPO or relevant contact at the processor, the likely consequences of the breach, and the measures taken or proposed to address it. A DPA that requires only notification without specifying content is insufficient.
What Everybody Counts Does
We publish our DPA template on our website before any school signs it. The document names all sub-processors, specifies AES-256 encryption at rest with HTTPS in transit, commits to deletion within 30 days of contract termination (including backups within 60 days), and includes a 48-hour breach notification commitment with full incident details.
We do not use pupil data for model training without explicit written consent. Our sub-processors are all either UK-based or EU/EEA-based companies covered by UK adequacy regulations; we don't use US-based sub-processors that would require SCCs.
We're sharing this because we think transparency about data handling should be normal for ed-tech providers who work with schools, not an exception. If you're evaluating any platform — including ours — ask for the DPA before the sales conversation is over, and use the five clauses above as your checklist. Any vendor who objects to that request is telling you something important.