Data processing agreement

The rule: Article 28 of the UK GDPR

Article 28(3) of the UK General Data Protection Regulation (UK GDPR) requires that processing by a processor “shall be governed by a contract or other legal act under domestic law, that is binding on the processor with regard to the controller”. The same paragraph says what the contract must describe – “the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller” – and then lists the terms it must contain, set out in section 03 below. The text is on Article 28 of the UK GDPR on legislation.gov.uk.

The duty starts before the contract. Article 28(1) says a controller “shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject”. Choosing the supplier is part of the controller's accountability; the agreement records the choice, it does not hand the accountability over.

The ICO's guidance When is a contract needed and why is it important? puts it without qualification: “every time a controller uses a processor to process personal data, there must be a written contract that binds the processor to the controller in respect of its processing activities.” The law allows “other legal act”, but the ICO adds that “in practice, in the UK, contracts are likely to be the appropriate means of complying with Article 28(3).” The same applies one level down: under Article 28(4), when a processor uses another processor, “the same data protection obligations” must be imposed on that sub-processor by contract.

Article 28(9) requires the contract to “be in writing, including in electronic form”, so a data processing addendum built into a supplier's online terms can meet it. What matters is who the parties are. The ICO says “The controller and processor must be party to the contract” – the school, trust, nursery, charity or care provider, not the member of staff who clicked to accept.

Two things changed in 2026, and both touch this contract. On 30 September 2026 the Information Commissioner was replaced by the Information Commission (still known as the ICO), and Article 28(8) now reads “The Commission may adopt standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article”. The ICO's guidance does not offer UK clauses of its own; it points instead to the clauses adopted by the Danish Data Protection Agency and approved by the EDPB, saying that if you use them “(without amendment) the contract should comply with the requirements in Article 28.” And on 5 February 2026 the test for sending personal data abroad changed (section 04). Every page of the ICO's contracts guidance now carries the banner: “Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change.”

Processor, controller or neither: which suppliers need one

The agreement is needed only where the supplier is a data processor. Article 4 of the UK GDPR defines both roles by who decides, and the ICO guidance quotes the definitions: a controller “determines the purposes and means of the processing of personal data”, and a processor “processes personal data on behalf of the controller”. Most suppliers to schools, nurseries, charities and care providers are processors for the service the organisation buys, but the test is applied feature by feature, not supplier by supplier.

The ICO's own example is a school's: “A specialist company provides software and data analysis to process the daily pupil attendance records of a state-maintained school for an annual fee. For the software provision the company is not a processor, but for the data analysis it is a processor for the school.” Another of its examples covers most online storage: “An organisation uses a cloud service to store and analyse its data. The organisation remains the controller and the cloud service provider is its processor.”

A supplier can also become a controller. The Department for Education's chapter on Data protection in schools: procuring educational technology (EdTech) (added on 9 July 2026) gives two cases: “If the tool has additional features outside of the school's requirements that parents can sign up for, you will need to consider that the supplier is likely to be the data controller”, and where a tool “processes personal data for its own purposes to develop the AI functionality, the supplier would be considered an independent data controller for that activity.” Article 28(10) makes the same point from the other side: a processor that “infringes this Regulation by determining the purposes and means of processing” is “considered to be a controller in respect of that processing.”

Typical suppliers, and the questions to ask of each:

• Schools and trusts: the management information system, payroll and HR, cloud email and storage, a parent communication or payments app, a trip and consent app, homework and assessment platforms. Usually processors for the service bought; check every feature parents or pupils can switch on for themselves.
• Nurseries and childminders: the learning journal app, nursery management and invoicing software, an online photo gallery. A childminder decides how their own records are used and needs the same agreement as a nursery group.
• Charities: the supporter database, the mailing house (the ICO's example of a company handling a publisher's subscriptions and mailings is a processor), an online giving platform – read its terms, because a platform with its own relationship with the donor may hold that data as a controller.
• Care providers: care planning and electronic medicines records, rostering and time-recording, the payroll bureau, the contractor who maintains CCTV or the network, the confidential waste company.

Where two organisations decide the purposes together they are joint controllers, and Article 26 requires “an arrangement between them” setting out their responsibilities, not an Article 28 contract. Where each decides its own purposes – a school passing information to children's social care, a care provider to the GP – they are separate controllers, and the ICO's data sharing code calls a data sharing agreement “good practice”. That is the territory of information sharing between agencies, not this guide.

What the contract must say: the details and the eight terms

The ICO's page What needs to be included in the contract? (dated 8 September 2026, and under review) starts with the details of the processing – its subject matter and duration, nature and purpose, the types of personal data and categories of people, and the controller's obligations and rights – and warns that “The controller therefore needs to be very clear from the outset about the extent of the processing it is contracting out.” A schedule that says “customer data” and nothing else does not do that.

Article 28(3)(a) to (h) then require eight terms. The processor must:

1. Act only on documented instructions from the controller, “including with regard to transfers of personal data to a third country”, unless domestic law requires otherwise, and say so first if it does (28(3)(a)). The ICO accepts that “An instruction can be documented by using any written form, including email”, provided it “must be capable of being saved”. Look for the service description doubling as the instruction, and for a way to give further instructions in writing.
2. Bind its people to confidentiality (28(3)(b)). The ICO says the term should cover the processor's employees “as well as any temporary workers and agency workers who have access to the personal data.”
3. Take all the security measures Article 32 requires (28(3)(c)). The ICO lists what those may include: encryption and pseudonymisation, the ongoing “confidentiality, integrity, availability and resilience of processing systems and services”, the ability to restore access after an incident, and regular testing. Look for an annex that describes the measures, not a promise of “industry standard” security.
4. Follow the rules on sub-processors (28(3)(d)): none without the controller's “prior specific or general written authorisation”; under a general authorisation, notice of “any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object”; the same obligations passed down by contract; and, under Article 28(4), the processor stays “fully liable” to the controller for a sub-processor's failures. Look for a published list, a notice route that reaches a named person, and a period in which you can object.
5. Help the controller respond to people exercising their rights (28(3)(e)) – subject access, rectification, erasure and objection requests. Look for a turnaround time that leaves you room to answer within your own deadline.
6. Help the controller meet Articles 32 to 36 (28(3)(f)): security, notifying breaches to the ICO and to the people affected, data protection impact assessments and prior consultation. The ICO recommends “that the contract is as clear as possible about how the processor will help”.
7. End-of-contract provisions: delete or return the data, at the controller's choice, “after the end of the provision of services relating to processing”, and delete existing copies unless domestic law requires storage (28(3)(g)). The ICO accepts that backups may not go at once: “Provided appropriate safeguards are in place, such as the data being put immediately beyond use, it may be acceptable that the data is not deleted immediately if the retention period is appropriate and the data is subsequently deleted as soon as possible, eg on the processor's next deletion/destruction cycle.”
8. Make available the information needed to demonstrate compliance, and allow for and contribute to audits, “including inspections, conducted by the controller or another auditor mandated by the controller” (28(3)(h)). The ICO says a processor can meet this by “giving the controller the necessary information or by submitting to an audit or inspection”, so a current independent audit report may be the practical answer for a small organisation.

A ninth duty closes Article 28(3): “the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other domestic law relating to data protection.” Expect a clause that says so. The ICO adds that the eight “are the minimum required, but the controller and processor may agree to supplement them with their own terms.”

The agreement does not make the processor's own duties disappear, and it does not take the controller's away. The ICO's page on responsibilities and liabilities for processors in their own right says a processor is subject to the ICO's investigative and corrective powers and fines, and that “An individual can also bring a claim directly against a processor in court” where it has failed in a processor's own obligations or acted outside the controller's lawful instructions. A processor also keeps its own record of processing under Article 30(2).

The gaps in a supplier's standard terms

Few suppliers to a school, nursery, charity or care provider will rewrite their terms, but most will answer questions, and the DfE tells schools to “check all clauses to ensure they meet your requirements and challenge any that you are unhappy with”. These are the places a standard data processing agreement most often falls short.

• No sub-processor list, or one “available on request”. Without the list and a notice route, the authorisation in Article 28(2) is a blank cheque and the objection right cannot be used.
• Breach notice with no clock. Article 33 of the UK GDPR sets the clocks. Article 33(2) says “The processor shall notify the controller without undue delay after becoming aware of a personal data breach.” The controller must then notify the ICO “without undue delay and, where feasible, not later than 72 hours after having become aware of it” (Article 33(1)), unless the breach is unlikely to result in a risk. The law sets no hour count for the supplier; a fixed figure, and a list of what the notice will contain, is something to negotiate so your own 72 hours are not spent waiting. Every breach, reported or not, belongs in your data breach log.
• Data used to “improve the service”. Product development is the supplier's purpose, not yours, and the DfE's AI example makes the supplier a controller for it. The DfE also suggests agreeing that “any updates that involved further processing of additional personal data are not automatically switched ‘on’”.
• Deletion with no timescale or proof. The DfE says: “Ensure that clear timescales are agreed for data transfer and deletion, including how backups and archives will be handled. The supplier should provide confirmation once deletion has taken place.”
• Liability that leaves data protection out. The ICO notes that a processor “may be contractually liable to the controller for any failure to meet the terms of their agreed contract. This will of course depend on the exact terms of that contract.” Read where data protection sits in the liability clause and any cap.

International transfers need the most care, because the UK rules changed on 5 February 2026 and many templates still describe the old regime or the EU's. A transfer to a country approved by regulations under Article 45A of the UK GDPR (what used to be called adequacy) needs no further safeguard. Otherwise, unless one of the derogations for specific situations in Article 49 of the UK GDPR applies, Article 46 of the UK GDPR, as amended by the Data (Use and Access) Act 2025, requires both a safeguard – such as standard data protection clauses – and that the controller or processor making the transfer – the data exporter – “acting reasonably and proportionately, considers that the data protection test is met”. The test in Article 46(6) is whether protection after the transfer “would not be materially lower” than the protection given by the UK GDPR and the relevant parts of the Data Protection Act 2018. The International Data Transfer Agreement and the UK Addendum to the EU clauses, issued by the ICO before that date and not withdrawn, still count as the safeguard under Article 46(2)(d) (see the ICO's guidance on the IDTA and the Addendum), though for a new transfer the exporter must still consider the test; arrangements already in place before 5 February 2026 continue (Schedule 9, paragraph 27, to the Data (Use and Access) Act 2025). For a transfer, the EU's own instruments are not the UK safeguard: the ICO says “The EU SCCs are not valid on their own for restricted transfers under the UK GDPR”, so they need the UK Addendum, and a European Commission adequacy decision is not approval by UK regulations. In practice ask three things: where the data is stored, where support staff can reach it from, and which sub-processors outside the United Kingdom receive it as data importers. The DfE puts it plainly for schools: “The supplier must have adequate safeguards in place for transfers outside the UK”.

Filing, reviewing and the sector rules

A signed agreement nobody can find is little better than none. File each one against the matching entry in the organisation's record of processing activities, which already names the recipients and transfers the agreement governs, and keep a simple supplier register beside it: the supplier, the service, processor or controller, the date the agreement was accepted, the version, the sub-processor notice route, the renewal date and the date of the last review.

Review an agreement when the supplier notifies a new sub-processor, adds a feature that uses personal data differently, changes where it stores data, or comes up for renewal. Where the processing is likely to result in a high risk – new technology, special category data at scale, children's data used in new ways – the impact assessment should come before the contract, not after it.

• Schools and trusts. The DfE's chapter Data protection in schools: responsibilities says “For most of the personal data you collect, store and use, the school or the multi-academy trust is the data controller”, and the EdTech chapter tells schools to “consult with your Data Protection Officer (DPO) at the very start” of buying any tool and to make sure responsibilities are “clearly assigned in a contract or data processing agreement” covering “security measures, sub-processors, deletion and return of data, breach notification, and staff access control.”
• Nurseries and childminders. The UK GDPR and the ICO guidance apply as written, to a single childminder as much as to a nursery group; our guide to GDPR for nurseries and childminders covers the rest of the law.
• Care providers. Data Security Standard 10 of the National Data Guardian's Review of Data Security, Consent and Opt-Outs (2016) reads: “IT suppliers are held accountable via contracts for protecting the personal confidential data they process and meeting the National Data Guardian's Data Security Standards.” The Data Security and Protection Toolkit is built on those standards, and says “All organisations that have access to NHS patient data and systems must use this toolkit”; for other providers it is often a condition of a local authority or NHS contract, so check yours.
• Charities. An incorporated charity – a charitable company or a CIO – contracts in its own name. For an unincorporated association, the ICO says to review the governing document, which “should set out which individual(s) manage the organisation on behalf of its members and are likely to act as the controller or joint controllers, and how contracts may be entered into on behalf of the organisation.”

The supplier nobody signed with

Ask a school business manager, a nursery owner, a charity's operations lead or a registered manager to list the suppliers that hold their people's data, and the list will be of systems someone chose and paid for. It will rarely include the app the staff group chat runs on. Yet that is often where a pupil's absence and the reason for it, a resident's fall, a volunteer's home visits or a family's circumstances are discussed first, and where it is a personal consumer app, its terms are an agreement with each member of staff as an individual, not with the organisation. There is no Article 28 contract to file, no sub-processor list, no notice route and no commitment to delete or return the data at the end. Our guide to GDPR compliant messaging apps sets out that argument in full.

ComplyChat is a messaging service built so that the organisation is the party. Its data processing agreement and sub-processor list are published, with what each sub-processor does, where it processes data and the safeguard for any transfer outside the UK; messages are stored and processed in the UK; everyone added to a channel is told it is on the record; and on paid plans, once the organisation's tenant is connected, conversations are kept under the retention schedules within its own Microsoft 365 subscription. Use those pages as an example of what to ask any supplier for, ours included. ComplyChat is not a contract management or supplier register tool, and it does not make anyone compliant on its own.

A question for the next leadership, governors' or board meeting: can we list every supplier that holds our pupils', residents', service users' or staff's personal data and produce the signed agreement for each – including for the app our staff group chat runs on?

Questions people ask

What is a data processing agreement?

A data processing agreement is the written contract that Article 28(3) of the UK GDPR requires whenever a controller uses a processor. It binds the processor to the controller and sets out the subject matter, duration, nature and purpose of the processing, the types of personal data and data subjects, the controller's obligations and rights, and the eight minimum terms listed in section 03.

Is a DPA mandatory?

Yes, whenever a supplier processes personal data on your behalf. The ICO says “every time a controller uses a processor to process personal data, there must be a written contract”, and Article 28(9) says it must be “in writing, including in electronic form”. It is not the document for sharing data with another controller, where the ICO's data sharing code calls a data sharing agreement “good practice” (Data sharing: a code of practice – data sharing agreements) rather than a legal requirement.

What should be included in a data processing agreement?

The details of the processing and eight minimum terms under Article 28(3): processing only on the controller's documented instructions, confidentiality, Article 32 security, conditions for sub-processors, help with individuals' rights, help with security, breach notification and impact assessments, deletion or return at the end, and information and audits to demonstrate compliance. The processor must also tell the controller immediately if it thinks an instruction breaks data protection law.

Who signs a data processing agreement in a school?

The agreement is made in the name of the controller, and the DfE says that for most personal data “the school or the multi-academy trust is the data controller” (for a maintained school, the governing body); the ICO says the controller and processor “must be party to the contract”. In practice it is signed or accepted by whoever holds delegated authority to sign contracts for the school or trust, after the data protection officer has advised – the DfE says to consult the DPO “at the very start” of buying any tool. The DfE makes senior leaders accountable for “making sure any contracts with third-party data processors cover the relevant areas of data protection”, and says “The responsibility and accountability for compliance sits with governors and trustees.” Our guide to the data protection officer for schools covers who the controller is in more detail.

What is the difference between a data processing agreement and a data sharing agreement?

A data processing agreement is the contract Article 28 requires between a controller and a processor acting on its behalf. A data sharing agreement sets the terms between separate controllers and is good practice rather than a legal requirement, while joint controllers must have an arrangement under Article 26 of the UK GDPR setting out their respective responsibilities.

Official guidance and your next step

The primary sources are Articles 26, 28, 33, 45A, 46 and 49 of the UK GDPR as amended by the Data (Use and Access) Act 2025, and Schedule 9 to that Act; the ICO's guidance on contracts and liabilities between controllers and processors, its guidance on the IDTA and the Addendum, and its data sharing code; for schools, the DfE's Data protection in schools chapters on responsibilities and on procuring educational technology; and, for care providers, the National Data Guardian's data security standards and the Data Security and Protection Toolkit. Quotations are from those pages as read on 28 October 2026. The ICO's contracts guidance and data sharing code carry a notice that they are under review following the Data (Use and Access) Act, so check the date on the page you use.

This guide is a practical summary for schools, early years providers, charities and care providers in the UK, and is not legal advice. A large or high-risk contract, a transfer outside the UK on terms you cannot assess, or a supplier who will not move on a term that matters to you are reasons to involve your data protection officer or take professional advice.

Then do one thing: take the three suppliers that hold the most sensitive personal data you have – usually the MIS or care planning system, payroll and cloud storage – find the data processing agreement for each, and check it against the eight terms in section 03. Any agreement you cannot find is the first gap to close.