A GDPR data processing agreement (DPA) checklist is the set of terms a controller-processor contract must contain to satisfy Article 28(3) of the GDPR. It has eight mandatory clauses, lettered (a) through (h): documented instructions, staff confidentiality, Article 32 security, sub-processor conditions, data-subject-rights assistance, breach and DPIA assistance, deletion or return of data, and audit rights. The contract must be in writing, which Article 28(9) confirms can be electronic.
When personal data also leaves the EEA, the DPA is paired with a separate transfer safeguard, usually the 2021 EU Standard Contractual Clauses or, for UK data, the ICO's IDTA.
Key takeaways
- Eight clauses are mandatory. Article 28(3)(a)–(h) are not optional; a DPA missing any of them is non-compliant, and Article 28(9) requires it in writing (electronic form counts).
- A DPA and SCCs do different jobs. The DPA is an Article 28 governance instrument; the SCCs (Commission Implementing Decision (EU) 2021/914) are an Article 46 transfer safeguard added only when data leaves the EEA.
- Article 28 breaches sit in the lower fine tier. They fall under Article 83(4) — up to EUR 10 million or 2% of worldwide turnover — not the EUR 20 million / 4% Article 83(5) tier that applies to core-principle breaches.
- The security annex is where controls become contractual. Annex II is where buyers verify that a processor's SOC 2 report and security controls back the Article 28(3)(c) and 28(3)(h) obligations, not just a marketing claim.
What a GDPR data processing agreement is (and when Article 28 requires one)
A data processing agreement is the written contract that governs the relationship between a controller — the party that determines the purposes and means of processing personal data (Article 4(7)) — and a processor that processes that data on the controller's behalf (Article 4(8)). Whenever a controller hands personal data to a processor, GDPR Article 28(3) requires a contract binding the processor to the controller and setting out the terms of processing. For a B2B SaaS vendor, you are almost always the processor for your customer's data; when you engage your own vendors, you become the controller in that relationship. Understanding which hat you wear in each flow is the first step, and it connects directly to your lawful basis for processing as the controlling party.
Before it even lists the eight clauses, Article 28(3) opens with a chapeau: the contract must set out the subject-matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. This descriptive block is not filler — it is the same processing description that feeds both parties' Article 30 records of processing activities, including the processor's own record under Article 30(2). A vague chapeau ("customer data, for the term of the agreement") is a common weakness that undermines every downstream clause.
The writing requirement itself lives in a distinct paragraph. Article 28(9) states that the contract "shall be in writing, including in electronic form." A frequent citation error — worth avoiding on a legal page — is attributing the electronic-form language to the 28(3) chapeau; it is Article 28(9). Article 28(1) sits above all of this: a controller may only use processors that provide "sufficient guarantees" to implement appropriate technical and organisational measures. Vendor due diligence, and the assurance reports that support it, exist to evidence those guarantees.
Is a DPA legally mandatory? Yes. There is no processing-volume threshold and no small-business carve-out: if a processor handles personal data for a controller, Article 28(3) requires the contract. Getting it wrong carries real exposure. Administrative fines for infringing the processor obligations in Article 28 fall under Article 83(4) — up to EUR 10 million, or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. That is the lower of the two tiers; the higher EUR 20 million / 4% tier in Article 83(5) is reserved for breaches of core principles, data-subject rights, and transfer rules. It is a common mistake to quote the headline EUR 20 million figure for a DPA failure — accurate framing matters when you are advising a board.
| Role | GDPR definition | Typical SaaS example | DPA obligation |
|---|---|---|---|
| Controller | Determines purposes and means of processing (Art. 4(7)) | Your enterprise customer | Must put a compliant DPA in place; carries Art. 24 accountability |
| Processor | Processes on the controller's behalf (Art. 4(8)) | Your SaaS platform | Bound by all Art. 28(3)(a)–(h) terms; must give sufficient guarantees (Art. 28(1)) |
| Sub-processor | Processor engaged by another processor | Your cloud host, email or analytics vendor | Must accept the same terms via flow-down (Art. 28(4)); needs authorisation (Art. 28(2)) |
One terminology note that trips up buyers: "DPA" is used loosely for a Data Processing Agreement, a Data Processing Addendum, and sometimes a Data Protection Agreement. In practice these are the same instrument — a Data Processing Addendum is simply the DPA bolted onto a master services agreement rather than signed as a standalone contract. The legal content Article 28 requires is identical whichever label is on the cover page. If you are new to the regime overall, start with our primer on GDPR for US-based SaaS companies.
The Article 28(3) mandatory clause checklist (a)–(h)
The heart of any DPA review is walking the contract against the eight lettered obligations. Below is the statutory text, lightly abridged, followed by a plain-English mapping table you can use as a redline checklist. The authoritative source is GDPR Article 28 (consolidated on EUR-Lex).
The contract shall stipulate, in particular, that the processor: (a) processes the personal data only on documented instructions from the controller, including with regard to transfers to a third country; (b) ensures that persons authorised to process the personal data have committed themselves to confidentiality; (c) takes all measures required pursuant to Article 32; (d) respects the conditions referred to in paragraphs 2 and 4 for engaging another processor; (e) assists the controller by appropriate technical and organisational measures for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights; (f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36; (g) at the choice of the controller, deletes or returns all the personal data after the end of the provision of services; (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allows for and contributes to audits, including inspections.
— GDPR Article 28(3), Commission consolidated text
The chapeau also carries a second subparagraph that is easy to miss: with regard to point (h), the processor must immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other EU/Member State data protection law. That "flag infringing instructions" duty is a distinct obligation, not part of the audit clause, and a good DPA states it explicitly.
| GDPR clause | Plain-English requirement | What to verify in the DPA | Common vendor gap |
|---|---|---|---|
| Chapeau | Describe subject-matter, duration, nature, purpose, data types, and data-subject categories | A specific processing description (often Annex I), not "customer data for the term" | Generic, non-specific description that fails Art. 30(2) too |
| 28(3)(a) | Process only on documented instructions, including for transfers | Instructions defined; a route to issue new ones; carve-out only for legal compulsion | Broad "as needed for the service" language that reads as processor self-authorisation |
| 28(3)(b) | Bind authorised staff to confidentiality | Confidentiality obligation on personnel with access | Silent, or relies solely on a general employee handbook |
| 28(3)(c) | Implement Article 32 security measures | Cross-reference to a populated Annex II / TOMs schedule | Empty or "available on request" security annex |
| 28(3)(d) | Respect Art. 28(2) & (4) for sub-processors | Authorisation model, notice/objection rights, flow-down, liability | No notice window; no flow-down obligation stated |
| 28(3)(e) | Assist with data-subject rights (Chapter III) | Assistance mechanism and turnaround; cost basis | Uncapped fees or no defined response time |
| 28(3)(f) | Assist with security, breach notice (Arts. 33–34) and DPIAs (Art. 35) | Breach-notification SLA; DPIA support; "taking into account information available" | Only "without undue delay" with no concrete hour target |
| 28(3)(g) | Delete or return data at end of services | Controller's choice honoured; deletion of copies; certificate on request | Processor-chosen default; silent on backups |
| 28(3)(h) | Make information available; allow and contribute to audits/inspections | Audit right defined; SOC 2 / ISO 27001 report acceptable but not the only option | Audits capped to annual report review, high fees, or on-site barred outright |
(a) Documented instructions only
The processor may act only on the controller's documented instructions — including for any transfer to a third country or international organisation — unless required to do otherwise by EU or Member State law, in which case it must inform the controller of that legal requirement before processing (unless the law prohibits such notice on public-interest grounds). Watch for DPAs that grant the processor latitude to process "as necessary to provide the services," which can quietly convert instruction-bound processing into processor discretion.
(b) Confidentiality of authorised personnel
Anyone the processor authorises to touch the personal data must be committed to confidentiality or be under an appropriate statutory obligation of confidentiality. In an audit, we look for the mechanism (contract clauses, onboarding NDAs) rather than a mere assertion.
(c) Article 32 security measures
The processor must take all measures required under Article 32 — the security-of-processing article covering pseudonymisation, encryption, confidentiality/integrity/availability/resilience, restoration, and regular testing. In the DPA this is where the security annex (Annex II) is cross-referenced; the substance belongs in that annex, discussed below.
(d) Sub-processor conditions
The processor must respect the conditions in Article 28(2) and 28(4) before engaging any sub-processor. This is the single most negotiated clause in most SaaS DPAs and gets its own section below.
(e) Assistance with data-subject rights (Chapter III)
By appropriate technical and organisational measures, and insofar as possible, the processor assists the controller in fulfilling its duty to respond to data-subject requests under Chapter III (Articles 12–23) — access, rectification, erasure, restriction, portability, and objection. The practical negotiation is over turnaround and cost.
| Right (Chapter III) | Data-subject action | Required processor assistance | Contractual SLA to specify |
|---|---|---|---|
| Access (Art. 15) | Requests a copy of their data (DSAR) | Locate and export data in the processor's systems | Turnaround well inside the controller's one-month deadline |
| Erasure (Art. 17) | Requests deletion | Delete on instruction, including from backups on a defined cycle | Deletion window and backup-expiry handling |
| Rectification (Art. 16) | Requests correction | Update records on instruction | Same-cycle propagation to sub-processors |
| Portability (Art. 20) | Requests machine-readable export | Provide structured, commonly used format | Supported export formats; any fee basis |
| Objection / restriction (Arts. 18, 21) | Objects to or restricts processing | Flag, suspend, or restrict processing | Mechanism to apply and lift restriction |
(f) Assistance with security, breach notification (Arts. 33–34) and DPIAs (Art. 35)
The processor assists the controller in complying with Articles 32 to 36 — security of processing, breach notification to the supervisory authority (Art. 33) and to data subjects (Art. 34), data protection impact assessments (Art. 35), and prior consultation (Art. 36) — taking into account the nature of processing and the information available to the processor. Because the controller itself must notify the authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach (Art. 33(1)), while the processor need only notify the controller "without undue delay" (Art. 33(2)), the DPA should convert that vague standard into a concrete processor SLA — commonly 24 to 72 hours — so the controller can meet its own clock.
(g) Deletion or return of data at end of services
At the controller's choice, the processor deletes or returns all personal data after the provision of services ends and deletes existing copies, unless EU or Member State law requires storage. Verify the choice genuinely rests with the controller, that backups are addressed, and that a deletion certificate is available on request.
(h) Audit rights and compliance information
The processor makes available all information necessary to demonstrate compliance with Article 28 and allows for and contributes to audits, including inspections, conducted by the controller or an auditor it mandates. In practice, vendors satisfy this by providing an independent assurance report; a current SOC 2 Type II or ISO 27001 certificate is the usual currency. The negotiation is over whether report review fully replaces the right to inspect — more on that in the negotiation section.
Sub-processor terms explained
Sub-processing is where DPAs most often fail on the details. Article 28(2) prohibits a processor from engaging another processor without the controller's prior specific or general written authorisation. Under specific authorisation, the controller approves each named sub-processor individually. Under general authorisation — the model almost every SaaS vendor uses — the controller pre-approves a category of sub-processors, but the processor must inform the controller of any intended additions or replacements and give the controller the opportunity to object.
The mechanics of that objection right are what to negotiate: how much advance notice (commonly 30 days), how notice is delivered (a subscribable sub-processor page is best practice), and what happens if the controller objects — typically a good-faith discussion and, failing resolution, a right to terminate the affected service. A processor should therefore maintain an accurate, current sub-processor list (sub-processor register) as a living document, not a point-in-time annex.
Article 28(4) supplies the flow-down: when a processor engages a sub-processor, it must impose the same data-protection obligations set out in the controller-processor contract, in particular the sufficient-guarantees standard. Critically, the initial processor remains fully liable to the controller for the sub-processor's performance of those obligations. There is no liability "hand-off" down the chain.
| Requirement | Specific authorisation | General authorisation | Flow-down / liability |
|---|---|---|---|
| Basis (Art. 28(2)) | Controller approves each named sub-processor | Controller pre-approves a category | — |
| Notice of changes | Fresh approval per addition | Advance notice of additions/replacements (commonly 30 days) | — |
| Objection window | Implicit (no approval, no engagement) | Defined objection period; termination right if unresolved | — |
| Same obligations (Art. 28(4)) | Same data-protection terms imposed on the sub-processor by contract | Yes — mirror the Art. 28(3) terms downstream | |
| Liability | Initial processor stays fully liable to the controller | No hand-off of liability down the chain | |
When you also need SCCs or the UK IDTA
A DPA and a transfer mechanism are two different instruments doing two different jobs, and conflating them is one of the most common mistakes we see. The DPA is an Article 28 governance contract that applies to any processing of EU personal data, transfer or not. A transfer mechanism is an Article 46 safeguard that becomes necessary only when personal data is exported outside the EEA to a country without an adequacy decision. A US SaaS vendor processing an EU customer's data needs both: a DPA for the Article 28 terms and a transfer safeguard because the data lands in the US.
For most companies the transfer safeguard is the EU Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914 of 4 June 2021. These are structured in four modules: Module 1 (Controller-to-Controller), Module 2 (Controller-to-Processor), Module 3 (Processor-to-Processor), and Module 4 (Processor-to-Controller). The 2021 SCCs became the only valid form for new EU/EEA-to-third-country transfer agreements from 27 September 2021, and contracts still relying on the pre-2021 SCCs had to be repapered by 27 December 2022.
A point of genuine confusion worth flagging: there are actually two distinct 2021 SCC instruments. Decision 2021/914 is the international-transfer set (the four modules above). A separate Commission Implementing Decision (EU) 2021/915 provides a template set of standard contractual clauses between controllers and processors under Article 28 for intra-EEA use — an optional Article 28 drafting aid, not a transfer tool. When Module 2 or Module 3 of 2021/914 is used, its processing terms are designed so they can also meet Article 28(3)–(4), which is why some DPAs lean on the SCCs for their Article 28 substance; even so, many contracts keep the Article 28 terms and the SCCs as separate schedules, and the precise overlap should be reviewed per contract.
| Instrument | Legal basis | When required | What it covers | Who signs |
|---|---|---|---|---|
| Data Processing Agreement | Article 28 | Any controller-to-processor processing of EU data | Processing governance terms | Controller & processor |
| EU SCCs (2021/914) | Article 46 | EEA-to-third-country transfer without adequacy | Cross-border transfer safeguard | Data exporter & importer |
| UK IDTA / UK Addendum | UK GDPR (DPA 2018) | UK-to-third-country transfer without adequacy | Transfer safeguard for UK data | UK exporter & importer |
Picking the right SCC module
| Data flow (exporter → importer) | SCC module | Typical scenario | Also need a DPA? | UK Addendum / IDTA? |
|---|---|---|---|---|
| EU controller → non-EU processor | Module 2 | EU customer using a US SaaS platform | Yes | If UK data is involved |
| Non-EU processor → non-EU sub-processor | Module 3 | US SaaS using a US cloud/analytics sub-processor | Yes (flow-down) | If UK data is involved |
| EU controller → non-EU controller | Module 1 | Joint marketing / independent controllers | Not an Art. 28 case | If UK data is involved |
| Non-EU processor → EU controller | Module 4 | Non-EU processor returning data to an EU controller | Yes | Rarely |
The 2021 SCCs include a docking clause (Clause 7) that lets additional parties join an existing SCC set over time — useful in multi-entity groups. For UK personal data, the ICO's International Data Transfer Agreement (IDTA) and the UK Addendum to the EU SCCs came into force on 21 March 2022 (laid before Parliament under s.119A of the Data Protection Act 2018); they became mandatory for new agreements from 21 September 2022, with existing contracts to be repapered by 21 March 2024. (Because the ICO periodically updates this guidance, confirm the current position on the ICO international transfers page before signing.)
Schrems II, the DPF, and the Swiss position in 2026
Signing SCCs is not the end of the analysis. Following Schrems II (CJEU Case C-311/18, 16 July 2020), parties relying on SCCs must assess the destination country's laws and, where those laws undermine the SCC protections, adopt supplementary measures — documented in a Transfer Impact Assessment (TIA). The EU-US Data Privacy Framework (DPF), adopted by Commission adequacy decision on 10 July 2023, offers an alternative route for transfers to self-certified US organisations, removing the SCC/TIA burden for those specific flows.
Treat the DPF as usable but not settled. As of mid-2026 it remains contested: the EU General Court dismissed the Latombe challenge on 3 September 2025, but an appeal is pending before the CJEU (Case C-703/25 P) with no hearing date announced, and the US Data Protection Review Court — a pillar of the DPF's redress mechanism — was left without a quorum after member removals in January 2025, with further challenges signalled by privacy advocates. Prudent programs keep SCCs plus a TIA in place as a fallback even when relying on the DPF, and cover the mechanics in depth in our guide to international data transfers under SCCs and the UK IDTA.
For a Swiss-nexus firm this matters directly. The revised Swiss Federal Act on Data Protection (revFADP) has been in force since 1 September 2023 and recognises the EU SCCs (with Swiss-specific amendments) as a valid transfer mechanism. The Swiss-US Data Privacy Framework extension took effect on 15 September 2024, so Swiss transfers to DPF-certified US organisations can rely on it — but Swiss transfers to US firms not certified under the DPF still require SCCs plus a transfer risk assessment, exactly as under EU law.
The security annex (Annex II / TOMs): what to specify under Article 32
Article 28(3)(c) points to Article 32, and Article 32 is given effect in the DPA through the security annex — usually labelled Annex II in an SCC-aligned DPA and listing the technical and organisational measures (TOMs). An "available on request" placeholder does not satisfy the clause; buyers increasingly reject DPAs whose Annex II is empty. The annex should describe the concrete controls the processor commits to maintain, and it is precisely where an assurance report earns its keep: a current SOC 2 report becomes the evidence for the Article 28(3)(h) audit right and the security annex, letting a buyer verify the controls are real rather than aspirational.
| TOM category | Article 32 reference | What buyers expect to see | Evidence tie-in |
|---|---|---|---|
| Access control | Art. 32(1)(b) — confidentiality | RBAC, least privilege, MFA, periodic access reviews | SOC 2 CC6 / ISO 27001 A.5, A.8 |
| Encryption | Art. 32(1)(a) | Encryption in transit and at rest; key management | SOC 2 CC6 / ISO 27001 A.8.24 |
| Logging & monitoring | Art. 32(1)(b) | Audit logs, alerting, retention | SOC 2 CC7 / ISO 27001 A.8.15–16 |
| Backup & resilience | Art. 32(1)(c)–(d) | Backups, restoration testing, availability targets | SOC 2 A1 / ISO 27001 A.8.13 |
| Testing | Art. 32(1)(d) | Vulnerability scanning and penetration testing as a TOM referenced in Annex II | Pen-test report / SOC 2 CC4 |
| Incident response | Art. 32(1)(b) | Documented IR plan; breach-notification workflow | SOC 2 CC7.3–7.5 / ISO 27001 A.5.24–28 |
US teams sometimes ask how this compares to the healthcare regime they already know. It is a useful analogy: the DPA is to GDPR roughly what a HIPAA Business Associate Agreement (BAA) is to protected health information — a mandatory contract flowing security and use obligations down to the party handling regulated data. The instruments differ in detail, but the accountability logic is the same.
DPA negotiation guide for SaaS buyers and vendors
In practice the processor (the SaaS vendor) usually offers a standard DPA as an addendum to its master services agreement, and the controller (the customer) reviews and redlines it. Either side can propose the paper, but because the controller carries Article 24 accountability, it should confirm the DPA satisfies every Article 28(3) clause before signing. Beyond the mandatory clauses, several commercial terms sit alongside the statutory ones and are where most real negotiation happens.
Cost allocation is the quiet battleground. Article 28(3)(e), (f), and (h) all require the processor to "assist," but the GDPR is silent on who pays. Vendors commonly cap or charge for DSAR assistance, breach support, and — most contentiously — restrict the audit right to an annual review of the SOC 2 report in lieu of on-site inspection. A controller with regulatory exposure should preserve a genuine inspection right (even if rarely exercised) rather than accept report-review-only. Breach-notification timing is the second: pin the processor to a concrete window (24–72 hours) so you can meet your own 72-hour Article 33 deadline. Then come the standard commercial terms — liability caps and carve-outs (data-protection claims are frequently carved out of the general cap), indemnities, governing law and jurisdiction, insurance requirements, and term, termination, and a post-termination deletion certificate under clause (g).
| Vendor DPA clause | Why it's a problem | Buyer redline / fallback |
|---|---|---|
| "Audits limited to reviewing our SOC 2 report once per year" | May not satisfy the full Art. 28(3)(h) inspection right for regulated buyers | Accept report review as default but preserve inspection on cause or after an incident |
| "We notify you of breaches without undue delay" | Too vague to support your 72-hour Art. 33 deadline | Fixed SLA of 24–72 hours from processor awareness |
| "Sub-processors may be added at our discretion" | Defeats the Art. 28(2) notice and objection right | Advance notice (e.g. 30 days) plus a documented objection process |
| Data-protection claims inside a low general liability cap | Under-compensates for a serious breach | Super-cap or carve-out for data-protection and confidentiality breaches |
| "Fees apply to all data-subject-request assistance" | Uncapped costs for routine Art. 28(3)(e) support | Reasonable, capped fees; a bundle of free requests |
| Empty or "on request" security annex | Fails Art. 28(3)(c) — nothing is contractually committed | Require a populated Annex II mapped to Article 32 |
“The two gaps we flag most often in vendor DPAs are an empty security annex and a breach clause that says only 'without undue delay.' Both look fine at signature and fail the day you actually need them — the annex when a buyer's security team asks for evidence, the breach clause when the 72-hour clock is running.”
— Sébastien Ruosch, CPA, Director of Audits at Auditsuisse
The Article 28 DPA checklist, ready to use
Use the clause-by-clause table above as your working checklist — every mandatory Article 28(3) item is enumerated inline so it renders for both people and machines. When reviewing a vendor DPA, walk it top to bottom: confirm the chapeau describes the processing specifically, then tick each of (a) through (h), then confirm the sub-processor terms, the transfer mechanism (SCCs / IDTA where data leaves the EEA), and a populated security annex. Flag any clause that is silent, vague, or shifts a mandatory obligation onto the controller. That single pass catches the large majority of non-compliant agreements before they reach signature.
This checklist is general guidance, not legal advice; a data-protection lawyer should review any DPA against your specific processing and jurisdiction before you rely on it.
How Auditsuisse helps
Auditsuisse is a US and Swiss licensed CPA firm. When enterprise buyers ask a processor to prove the security and audit commitments in its DPA, we produce the independent assurance — SOC 2, ISO 27001-aligned examinations, and GDPR compliance audits — that backs Annex II and the Article 28(3)(h) audit right. Our approach to how we test processor controls is built to map cleanly onto the technical and organisational measures a DPA commits you to, so your security annex is evidenced rather than aspirational. If you are scoping a GDPR assessment or need a processor-side report your customers will accept, we can help you sequence it.
Frequently asked questions
What must a GDPR data processing agreement include?
Under GDPR Article 28(3), a DPA must be in writing and cover eight mandatory terms: (a) processing only on documented instructions, (b) staff confidentiality, (c) Article 32 security measures, (d) sub-processor controls, (e) help with data-subject requests, (f) help with breach notice and DPIAs, (g) deletion or return of data, and (h) audit rights and compliance information.
Is a data processing agreement legally required under GDPR?
Yes. GDPR Article 28(3) requires a written contract whenever a controller uses a processor to handle personal data, and Article 28(9) allows that writing to be electronic. Without a compliant DPA, both parties breach GDPR; Article 28 infringements sit in the Article 83(4) tier, up to EUR 10 million or 2% of global annual turnover.
What is the difference between a DPA and Standard Contractual Clauses (SCCs)?
A DPA governs the controller-processor relationship under Article 28 and applies to any EU personal-data processing. SCCs (Commission Implementing Decision (EU) 2021/914) are a separate Article 46 safeguard that legalises transfers of that data to a third country. A DPA is often needed even with no transfer; SCCs are added, usually as an annex, only when data leaves the EEA.
Which SCC module applies to a US SaaS vendor?
A US SaaS company acting as a processor for an EU customer uses Module 2 (Controller-to-Processor) of the 2021 EU SCCs. If it engages a US sub-processor, that onward flow uses Module 3 (Processor-to-Processor). UK personal data also needs the UK Addendum or the ICO's IDTA.
Do you need controller approval to add a sub-processor under GDPR?
Yes. Article 28(2) requires prior specific or general written authorisation before a processor engages a sub-processor. Most DPAs use general authorisation with a notice-and-objection window. Under Article 28(4) the sub-processor must accept the same data-protection terms, and the original processor stays fully liable for its failures.
What is a security annex (Annex II) in a DPA?
The security annex documents the technical and organisational measures required by Article 32: access control, encryption, logging, backup, incident response, and testing. It is referenced by Article 28(3)(c) and is where buyers verify a processor's SOC 2 or ISO 27001 controls are contractually committed, not just claimed.
Who provides the DPA, the controller or the processor?
In practice the processor (the SaaS vendor) usually supplies a standard DPA as an addendum to its master services agreement, and the controller (the customer) reviews and redlines it. Either party can propose the terms, but the controller carries the Article 24 accountability, so it should confirm the DPA satisfies every Article 28(3) clause before signing.
How fast must a processor notify the controller of a data breach?
Article 33(2) says a processor must notify the controller "without undue delay" after becoming aware of a breach. Because the controller has its own 72-hour deadline to notify the supervisory authority under Article 33(1), buyers negotiate a concrete processor SLA, commonly 24 to 72 hours, into the DPA.
Sources & further reading
- European Union — GDPR Article 28 (Processor), including the 28(3)(a)–(h) mandatory terms and the Article 28(9) written-form requirement.
- European Commission — Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for third-country transfers (Modules 1–4).
- European Union — GDPR Article 83 on administrative fines; Article 28 infringements fall under Article 83(4).
- Information Commissioner's Office (UK) — International transfers: the IDTA and UK Addendum.
Reviewed by Sébastien Ruosch, CPA (US & Swiss licensed), Director of Audits at Auditsuisse. Last reviewed July 1, 2026.
Need a processor report your buyers will accept?
Auditsuisse is a US & Swiss licensed CPA firm. We produce the independent assurance that backs your DPA's security annex and Article 28(3)(h) audit right — see our GDPR audit services or book a call to scope a GDPR assessment.
Request Consultation