Data Processing Agreements — Article 28, Clause by Clause
The eight clauses every controller-processor contract must contain under Article 28(3) GDPR — what they actually mean, what counsel looks for, the sub-processor approval mechanic, and the post-Schrems II transfer language that makes a US vendor DPA defensible.
Article 28 GDPR 8 mandatory clauses Schrems II transfer language
Bilingual EN + DE / PL / LT, counsel-redlinable Word + PDF, with schedule, TOM annex, and sub-processor list pre-structured.
The DPA in five sentences
Article 28 GDPR requires every controller to govern its processor relationships by a written contract that binds the processor to the controller and contains the eight clauses listed in Article 28(3).
Sub-processorsare permitted only with the controller's prior written authorisation — general (with notice and a right to object) or specific (case by case).
International transfers need a separate transfer mechanism on top of the DPA — the EU-US Data Privacy Framework where applicable, or 2021 SCCs with a documented Schrems II transfer impact assessment.
Audit rights work in three layers: an annual third-party report, written follow-up questions, and on-site audit on demonstrated cause. Less than that fails Art. 28(3)(h).
End-of-contract the controller chooses return or deletion, the processor certifies it in writing, and the backup-and-archive lifecycle is stated up-front so nobody is surprised at termination.
1. Why Article 28 exists and what it solves
The GDPR draws a hard line between two roles. The controller decides why personal data is processed and what is done with it. The processor processes personal data on the controller's behalf, on instructions, without setting the purposes itself. A modern small business runs on processors — the email sender, the payments provider, the hosting platform, the analytics tool, the customer-support inbox — and each one of those vendors holds personal data the controller is legally responsible for.
Article 28 governs that delegation. It says: where you (the controller) entrust personal data to someone else (the processor), the relationship must be governed by a written contract that satisfies eight specific requirements, and the processor must offer sufficient guarantees that they can meet the controller's GDPR obligations. The contract is the controller's primary instrument for evidencing accountability under Article 5(2) — the principle that the controller must be able to demonstrate compliance.
That is why the DPA matters in practice. It is the single document that converts a vendor relationship into a defensible processor relationship — and the absence of one converts the same data flow into an unlawful processing chain.
2. Controller, processor, joint-controller — get this right first
The first thing counsel checks when reviewing a DPA is whether Article 28 is even the right instrument. Three classifications, three different contracts:
Controller-to-processor (Art. 28).The processor processes personal data on the controller's instructions, for the controller's purposes, without determining its own purposes. A payroll provider running the controller's monthly payroll. A hosting platform serving the controller's application. A DPA is the right instrument.
Joint controllers (Art. 26). Two organisations jointly determine the purposes and means of processing. A loyalty programme run jointly by a retailer and an issuing bank. The right instrument is a joint-controller arrangement that allocates Art. 13/14 transparency duties and rights handling between them. The Article 28 DPA is the wrong shape.
Independent controllers. Two organisations both process the same personal data, each for their own independent purposes. A controller that hands over data to a tax authority by statutory obligation. No Art. 28 contract is needed; the data flow itself needs a separate lawful basis.
The most common misclassification is treating a joint-controller relationship as a processor relationship. The symptom: the "processor" uses the data for its own analytics, its own product improvement, or its own customer-acquisition modelling. The moment a vendor is determining purposes for the data — even on top of the controller's purposes — Article 28 no longer fits, and a joint-controller arrangement is what counsel will steer you to.
3. "Sufficient guarantees" under Article 28(1)
Before the contract clauses, Article 28(1) requires the controller to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of the Regulation and ensure the protection of the rights of the data subject. The phrasing is regulatory shorthand for due diligence — and the controller has to be able to evidence it.
EDPB Guidelines 07/2020 on the concepts of controller and processor frame the assessment around five practical inputs. None of them is a checkbox; together they are what a supervisory authority will ask to see when probing how a processor was selected:
Expert knowledge — does the processor have demonstrable expertise in the type of processing being entrusted (e.g. payroll providers in payroll, payment processors in payments).
Reliability — track record, customer base, public security incidents, regulatory history.
Resources — financial and operational capacity to maintain the controls and respond to incidents.
Adherence to a code of conduct or certification mechanism — Article 40/42 codes and certifications are explicitly singled out by Article 28(5) as evidence of sufficient guarantees.
Reputation on the market — particularly relevant where independent third-party reports (SOC 2 Type II, ISO 27001, ISO 27018, the EU Cloud Code of Conduct) make the controls publicly verifiable.
Operationally, evidence the assessment with three artefacts on file before you sign: a security questionnaire response from the processor, the most recent third-party report or certification, and a short internal note explaining why the controls are appropriate to the risk of the data being processed. The note is the difference between an audit answer of "we accepted their published DPA" and an audit answer of "we assessed three vendors against these criteria and selected this one for these reasons".
4. The 8 mandatory clauses — clause-by-clause checklist
Article 28(3) lists eight clauses every DPA must contain. For each one, the regulation tells you what the clause must say — what counsel reviews is whether the wording you actually have on file gives the controller the rights it needs in practice. Run any vendor DPA against this list; if a row has nothing matching, the contract is incomplete.
1
Documented instructions
Art. 28(3)(a)
What the clause must say
The processor processes personal data only on the documented instructions of the controller, including transfers to third countries — unless required to do so by EU or member-state law, in which case the processor informs the controller of that legal requirement before processing (unless the law prohibits the disclosure on important grounds of public interest).
Common red flag
Open-ended language permitting the processor to use the data for its own purposes (analytics, model training, product improvement) without explicit controller authorisation. This converts the relationship into joint-controller and breaks the Art. 28 framing.
2
Confidentiality
Art. 28(3)(b)
What the clause must say
Persons authorised to process the personal data have committed themselves to confidentiality or are under a statutory obligation of confidentiality.
Common red flag
Reliance on a generic NDA without a clause that follows the data through the processor's own employees, contractors, and sub-processor chain. Each link in the chain needs the equivalent confidentiality binding.
3
Article 32 security measures
Art. 28(3)(c)
What the clause must say
The processor takes all measures required pursuant to Article 32 — appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including pseudonymisation and encryption where applicable, ongoing confidentiality, integrity, availability, and resilience of processing systems, and a process for regularly testing the effectiveness of those measures.
Common red flag
A bare reference to "industry-standard security" without a TOM annex listing the specific controls. The controller cannot evidence Art. 28(1) sufficient guarantees from a sentence; the technical and organisational measures schedule is what the supervisory authority will read.
4
Sub-processor conditions
Art. 28(3)(d)
What the clause must say
The processor respects the conditions in Articles 28(2) and 28(4) for engaging another processor — prior written authorisation (general or specific), the same data-protection obligations flowed down by contract, and the original processor remaining fully liable to the controller for the sub-processor's performance.
Common red flag
A right for the processor to engage sub-processors freely and without notification, or a sub-processor list that exists at signature but is never updated. Either failure mode breaks Art. 28(2) and the controller's right to object.
5
Assistance with data subject rights
Art. 28(3)(e)
What the clause must say
Taking into account the nature of the processing, the processor assists the controller by appropriate technical and organisational measures, insofar as possible, in fulfilling the controller's obligation to respond to requests for exercising data subject rights under Chapter III.
Common red flag
Charging per-request fees for routine DSAR support, or refusing to provide direct access tooling and forcing every retrieval to go through ticketed support. The clause must oblige cooperation that scales with normal request volumes.
6
Assistance with Articles 32–36
Art. 28(3)(f)
What the clause must say
The processor assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 — security, breach notification (Art. 33(2) processor-side), breach communication, data protection impact assessments (DPIA), and prior consultation — taking into account the nature of processing and information available to the processor.
Common red flag
A breach-notification clause that says "as soon as practicable" without a defined window. The downstream Art. 33(1) controller window is 72 hours — the processor's notification needs to land early enough that the controller still has time to assess and file. "Without undue delay, and in any event within 24 hours" is the surviving standard.
7
Return or deletion at end of services
Art. 28(3)(g)
What the clause must say
At the choice of the controller, the processor deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless EU or member-state law requires storage of the personal data.
Common red flag
Silence on the choice mechanic, on the format of returned data, or on backup-and-archive lifecycle. "Deleted in accordance with our retention policy" is not enough; the controller needs the option, the timeline, and a written certification of deletion.
8
Information & audit rights
Art. 28(3)(h)
What the clause must say
The processor makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in Article 28, and allows for and contributes to audits, including inspections, conducted by the controller or another auditor mandated by the controller.
Common red flag
An audit-rights clause structured as "refer to our SOC 2 report on request" with no escalation path. The surviving pattern layers the third-party report with the right to ask written questions and the right to on-site audit on demonstrated cause; flat refusal of on-site is non-compliant.
5. Sub-processors and the right to object
Article 28(2) governs sub-processing. The processor may not engage another processor without the prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor must inform the controller of any intended changes concerning the addition or replacement of other processors, giving the controller the opportunity to object. Article 28(4) closes the loop: where another processor is engaged, the same data-protection obligations as set out in the original contract must be imposed on that other processor by way of a contract, and the original processor remains fully liable to the controller for the performance of its sub-processor.
General versus specific authorisation
Modern SaaS runs on general written authorisation. The processor publishes a list of current sub-processors at a stable URL, commits in the DPA to give the controller advance notice of new additions or replacements, and the controller has a contractual window in which to object. Thirty days is the surviving market standard for the notice and objection window.
Specific authorisation is appropriate where data is highly sensitive (special-category data under Article 9, criminal-data under Article 10), where regulated industries impose jurisdictional constraints, or where the controller has a specific concern about a category of sub-processor (e.g. a financial-services controller restricting US cloud regions for certain workloads). Specific authorisation is operationally heavier; build a process for it before signing the DPA, not after.
What "objecting" actually does
Objection is the controller's only practical lever to stop a sub-processor change. The DPA needs to spell out what happens on a successful objection — typically, the processor either agrees not to engage the sub-processor for the controller's data, offers the controller a right to terminate the underlying service for cause without penalty, or both. A general-authorisation clause that gives the controller a right to object but no consequence on objection is window-dressing.
6. International transfers post-Schrems II
Personal data leaving the EEA needs a transfer mechanism under Chapter V GDPR — and since the CJEU's 2020 Schrems II decision, the mechanism alone is not enough. Three layers, in order:
Adequacy or a transfer mechanism. Article 45 adequacy decisions cover the UK, Switzerland, Japan, South Korea, the Channel Islands, the Faroe Islands, Argentina, Israel, New Zealand, Uruguay, Andorra, and Canada (commercial). For the United States, the EU-US Data Privacy Framework (DPF) operates as a partial adequacy where the recipient is self-certified and on the active list. Where no adequacy applies, the standard fallback is the 2021 Standard Contractual Clauses (SCCs) — Module 2 controller-to-processor, Module 3 processor-to-processor, with the docking-clause option boxes correctly completed.
A transfer impact assessment (TIA).Schrems II requires the controller to assess, on a case-by-case basis, whether the law of the recipient country provides essentially equivalent protection. EDPB Recommendations 01/2020 provide the methodology. The output is a written assessment that identifies the laws of concern (US: FISA 702, Executive Order 12333; other jurisdictions vary), the practical likelihood of public-authority access, and the controls in place. The TIA is part of the controller's Article 5(2) accountability file — it is not optional.
Supplementary measures where the TIA finds residual risk. Encryption with EU-held keys, pseudonymisation that the recipient cannot reverse, contractual challenge obligations on government access requests. The DPA is the instrument that operationalises the supplementary measures — the TIA writes them down, the DPA binds the processor to them.
What the DPA itself needs to say about transfers
The transfer-related language in a defensible DPA reads like three short clauses bolted onto the eight Article 28(3) clauses: a clause identifying the transfer mechanism in use (DPF / SCCs / adequacy), a clause obliging the processor to support the controller's TIA with information about onward transfers, sub-processor jurisdictions, and any binding requests received from public authorities, and a clause committing the processor to challenge unlawful access requests where legally able.
Skip the drafting
A counsel-redlinable DPA in ten minutes — schedule, TOM annex, sub-processor list, all pre-structured.
CookieSentry generates the controller-side DPA with the eight Art. 28(3) clauses verbatim, the schedule of processing purposes and categories ready to fill, the technical and organisational measures annex, and bilingual EN + DE / PL / LT — alongside Privacy Policy, Cookie Policy, ROPA, Data Retention, and Breach Procedure.
Article 28(3)(h) requires the processor to make available all information necessary to demonstrate compliance with Article 28 and to allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. The clause is necessary and the wording is broad — and therein lies the negotiating problem.
A literal reading would let any controller turn up at any time. For a SaaS processor with thousands of customers, that is unworkable; for most controllers, it is also unwarranted (a small business has neither the expertise nor the standing to conduct a meaningful on-site audit of a hyperscale cloud). The language that survives counsel review on both sides is structured in three layers:
Layer 1 · Annual report
Independent third-party report (SOC 2 Type II, ISO 27001, ISO 27018 for personal data in cloud, the EU Cloud Code of Conduct, or equivalent) made available on request, on a cadence of at least once per year.
Layer 2 · Written follow-up
The right to ask reasonable written questions on top of the third-party report, with a defined response window (commonly 30 days). Used to clarify scope, exclusions, and control deviations identified in the report.
Layer 3 · On-site on cause
On-site audit on demonstrated cause and reasonable notice (commonly 30 days), with the controller bearing reasonable costs unless material non-compliance is found, in which case the processor bears them.
What is not acceptable:a clause that closes off on-site audit entirely (it fails Art. 28(3)(h) on its face), a clause that grants on-site audit at any time without notice (no processor will sign it and the controller does not need it), and a clause that limits audit to "the most recent SOC 2 report" with no escalation path. Each of those three failure modes is what a supervisory authority will surface during enforcement.
8. Six common DPA situations, walked through
Standard SaaS vendor — published DPA at stable URL
Standard
Google Workspace, Microsoft 365, Stripe, Atlassian, the major email senders all publish a current DPA at a permanent URL with a version date. The controller's job is to accept the current version (electronically or by counter-signature where offered), store the executed PDF with the version date in the vendor file, and add the vendor to the ROPA. The published DPA already covers the eight Art. 28(3) clauses, the sub-processor list with general authorisation, and the SCC modules where transfers apply. Re-drafting is wasted effort.
Niche EU vendor — no published DPA, accepts the controller's template
Standard
Smaller European processors frequently do not maintain their own DPA and will counter-sign one the controller provides. The CookieSentry-generated DPA is drafted as exactly this — controller-side, ready to send. Fill in the parties, the purposes and categories of processing on the schedule, the TOM annex (the processor's response on technical and organisational measures), the sub-processor list, and execute. Counsel review of the parties block and the schedule is recommended; the body of the agreement is built from the Art. 28(3) clauses verbatim.
US vendor — published DPA, references the EU-US DPF
Negotiate
Vendor self-certifies under the EU-US Data Privacy Framework and the published DPA points to that as the transfer mechanism. The controller's job: verify the certification is current on dataprivacyframework.gov, store the verification screenshot and date in the vendor file, and ensure the DPA also offers SCCs as a fallback in case the DPF certification lapses or is withdrawn. A DPF-only clause without SCC fallback is a single point of failure that leaves the transfer unlawful from the day certification ends — a 24-hour gap can become a notifiable issue.
US vendor — no DPF, transfers under SCCs only
Negotiate
The published DPA references the 2021 Standard Contractual Clauses, typically Module 2 (controller-to-processor) for direct engagement. Two checkpoints: first, that the right module is selected and the docking-clause and option boxes are completed correctly; second, that the controller has performed a transfer impact assessment under Schrems II considering US surveillance law (FISA 702, EO 12333), and that supplementary measures are documented where the assessment finds residual risk. Encryption with EU-held keys is the most common surviving supplementary measure for SaaS.
Sub-processor change announced — controller has 30 days to object
Negotiate
The processor sends an Art. 28(2) notification of a new sub-processor — typically a hyperscale cloud, sometimes a regional CDN. The controller's response: assess the new sub-processor against the same Art. 28(1) standard (where is it located, what categories of data will it touch, is a transfer mechanism in place), update the ROPA processor entry, and either accept or formally object within the contractual window. Silence is acceptance under most general-authorisation clauses; document the assessment either way.
Vendor refuses any audit beyond "refer to our SOC 2 report"
Block
An Art. 28(3)(h) clause that closes off any escalation beyond a third-party report is non-compliant. The surviving language layers the report (annual, on request) with written follow-up questions (reasonable scope, defined response window) and on-site audit on demonstrated cause and reasonable notice. A flat refusal of all three layers is a contracting blocker — either negotiate the layered language in or move the workload to a vendor that offers it. The supervisory authority will not accept that the controller could not get the rights into the contract.
9. Country notes — DE, PL, LT
Germany — BfDI and Landesdatenschutzbehörden
There is no statutory requirement that an Art. 28 DPA be in German to be enforceable. Inspections by the Landesdatenschutzbehörden routinely review English-language DPAs from international vendors. Where the controller's wider documentation is in German, a parallel German translation removes friction during an audit but is operational rather than legal. Bavarian data protection authority (BayLDA) and the Berlin BlnBDI publish enforcement summaries that consistently identify missing or outdated sub-processor lists as a top finding category — the maintenance discipline matters more than the language.
Poland — UODO
UODO accepts English-language DPAs and has issued multiple administrative decisions where the underlying Art. 28 instrument was in English. The recurring weakness UODO flags is the schedule — categories of personal data and processing purposes specified at a level so abstract that the supervisory authority cannot tell what is actually being processed. The schedule is where most controller-side audit findings land.
Lithuania — VDAI
VDAI follows the same posture as the German and Polish authorities on language. VDAI's audit experience emphasises the breach-notification chain: the processor-to-controller window in the DPA must be tight enough (24 hours is the surviving standard) that the controller's downstream Art. 33(1) 72-hour window is realistic. A processor clause of "as soon as practicable" effectively forces the controller to file late or with incomplete information.
10. Penalties under Article 83
Failure to have a compliant Article 28 instrument falls under the lower fining tier of Article 83(4): up to €10 million or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. The higher Article 83(5) tier (€20 million or 4%) applies to failures of the lawfulness and rights provisions and is rarely the basis for DPA-only enforcement.
For SMBs the bigger commercial risk is procurement, not the fine. Enterprise customers, certified buyers (ISO 27001, SOC 2 Type II, public-sector frameworks), and any controller doing its own Article 28(1) due diligence will not contract without seeing the processor DPAs in place — and the absence of a single DPA routinely blocks a B2B sales cycle until the gap is closed. The DPA pack is the cheap insurance against that specific friction, and the document itself is the artefact a customer will ask for in the third email of the procurement thread.
11. Frequently asked questions
Do we actually need a separate DPA, or is a clause in the main contract enough?+
A clause inside a service agreement is sufficient if it satisfies all of Article 28(3). The reason most companies attach a separate Data Processing Agreement instead is operational: the privacy terms change on a different cadence than commercial terms (sub-processor lists move, transfer mechanisms get updated post-Schrems II, audit windows get refined), and a separable annex makes those updates a one-page exchange rather than a renegotiation of the master agreement. The legal effect is identical; the maintenance cost is not.
Does Article 28 apply between two controllers, or only controller-to-processor?+
Article 28 governs the controller-to-processor relationship only. Where two organisations independently determine the purposes and means of processing, they are joint controllers under Article 26 and need a different instrument — a joint-controller arrangement that allocates responsibility for transparency and rights handling between them. Mis-classifying a joint-controller relationship as a processor relationship is one of the most expensive mistakes counsel sees, because the wrong contract is in place from day one.
Who drafts the DPA — the controller or the processor?+
Either party can draft, and in practice processors that serve many controllers (cloud platforms, payments providers, email senders) publish a standard DPA the controller is asked to accept. Article 28(7) and (8) explicitly contemplate the European Commission and supervisory authorities issuing standard contractual clauses to streamline this. What matters is not who drafts but that the eight Article 28(3) requirements are satisfied and that the controller can evidence the processor's sufficient guarantees under Article 28(1).
Are we allowed to refuse a sub-processor the controller wants to use?+
Article 28(2) gives the controller the right to object to new sub-processors. The two common patterns are general written authorisation (the processor can engage any sub-processor on a published list, must give prior notice of changes, and the controller has a window to object) and specific authorisation (each engagement requires an explicit yes). General authorisation is operationally normal for SaaS; specific authorisation is appropriate where data is highly sensitive or jurisdictionally constrained. Either is compliant — silence on which one applies is not.
What does post-Schrems II compliance actually require for transfers to the United States?+
Three layers, in order. First, a transfer mechanism — for the US, the EU-US Data Privacy Framework (DPF) where the recipient is self-certified, or Standard Contractual Clauses (Module 2 controller-to-processor, Module 3 processor-to-processor). Second, a transfer impact assessment that documents the legal landscape of the recipient country and any access risk from public authorities. Third, supplementary measures where the assessment finds the SCCs alone are insufficient — encryption with EU-held keys, pseudonymisation, contractual challenge obligations. The DPA must reference the mechanism in use and oblige the processor to support the impact assessment with information about its sub-processors and access requests.
How wide should the audit-rights clause be?+
Article 28(3)(h) requires the processor to make available all information necessary to demonstrate compliance and allow for and contribute to audits. In practice, full on-site audits at any time are unworkable for SaaS processors and unwarranted for most controllers, so the surviving compromise is layered: an annual right to receive an independent third-party report (SOC 2 Type II, ISO 27001, or equivalent), the right to ask reasonable written questions on top, and an on-site audit only on demonstrated cause and reasonable notice (commonly 30 days, with cost-sharing). This pattern survives counsel review on both sides because it gives the controller real assurance without giving every customer the keys to the building.
What happens to the data when the contract ends?+
Article 28(3)(g) requires the processor to delete or return all the personal data after the end of services, at the choice of the controller, and to delete existing copies unless EU or member-state law requires retention. The DPA should make the choice mechanic explicit (a written request from the controller within a defined window — 30 days is normal — selecting return or deletion), define the format for return where applicable, and require the processor to certify deletion in writing. Backup and archive copies need a stated lifecycle so the controller is not surprised when the processor explains they will not actually be wiped for ninety days.
Does our payroll provider, our email sender, our hosting partner each need their own DPA?+
Yes — every processor that handles personal data on your behalf is in scope. The common shortcut of one master DPA covering all vendors is a documentation problem disguised as a simplification: when a supervisory authority asks who processes what for which purpose, you need a per-vendor record (the ROPA), and the per-vendor DPA is the contractual underpinning. Modern tooling reduces the cost — most major SaaS vendors publish a current DPA at a stable URL — but the contracts must each exist and be on file.
Are there penalties for not having a DPA in place?+
Yes. Failure to have a compliant Article 28 instrument falls under the lower fining tier of Article 83(4) — up to €10 million or 2% of total worldwide annual turnover, whichever is higher. In practice the bigger commercial risk for SMBs is procurement and audit failure: enterprise customers and certified buyers (ISO 27001, SOC 2, public-sector frameworks) will not contract without seeing the processor DPAs in place, and the absence of a single one routinely blocks a B2B sales cycle until the gap is closed.
Where does the DPA live in our document set, and who has to sign it?+
The DPA is signed by an authorised representative of each party — typically the same signatory as the underlying service agreement. It lives alongside the service contract in the controller's vendor file, and a reference to its existence belongs in the ROPA entry for that processor. CookieSentry's generated DPA is drafted as a standalone document the controller can either annex to a vendor's master agreement or use as the controller-side template when a processor does not publish their own.
Do the German, Polish, and Lithuanian supervisory authorities expect the DPA in the local language?+
There is no member-state requirement that a DPA be in the local language to be valid. In Germany the BfDI and the Landesdatenschutzbehörden routinely review English-language DPAs from international vendors. UODO in Poland and VDAI in Lithuania take the same posture. Practical exception: where the controller's documentation is otherwise fully in the local language and an inspection is conducted by local-language officials, a German or Polish or Lithuanian translation alongside the English original removes friction. CookieSentry generates the DPA bilingually so the controller has both versions on file without further effort.
We're a small business — do we need this if we only use a couple of standard SaaS tools?+
Yes. The Article 28 obligation does not scale with company size; it scales with the existence of a processor relationship. Two SaaS vendors that hold customer or employee personal data is two processor relationships, each of which needs a compliant DPA. The good news is that for standard SaaS the DPAs already exist — Google Workspace, Microsoft 365, Stripe, the major email senders all publish them — and the controller's job is to accept the current version and store the executed copy with the dated counterpart in the vendor file.
The DPA your customers and counsel will both accept
CookieSentry generates the controller-side Data Processing Agreement with the eight Article 28(3) clauses verbatim, the schedule of processing, the technical and organisational measures annex, the sub-processor list pattern, and bilingual EN + DE / PL / LT — alongside Privacy Policy, Cookie Policy, ROPA, Data Retention, and Breach Procedure. Generate, redline with counsel where you want, ship.
Pay only after you preview every document. No subscription.
This guide summarises GDPR Articles 4, 5, 26, 28, 32, 44–46, 83 and EDPB Guidelines 07/2020 and Recommendations 01/2020 for orientation. It is a practical reference, not legal advice; the application of these provisions to a specific vendor relationship depends on facts only counsel familiar with your jurisdiction can assess. CookieSentry templates are drafted to current EU and national law and are intended for review by qualified counsel before publication.