GDPR data processing agreement: what to check

What a GDPR data processing agreement must contain before a customer signs

When a customer, contract or regulator requires a GDPR data processing agreement, the answer starts with Article 28: processing by a processor must be governed by a binding written contract, including one in electronic form. That contract must set out the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subjects, and the controller's rights and obligations. The required elements are fixed by law, so the contract cannot be negotiated away, but the detail is negotiated. Security measures, sub-processor handling, audit mechanics and breach timelines differ by service and by who actually holds the data, and generic wording that only restates the GDPR is a weak position to sign from. The EDPB's guidance on processors expects the agreement to say how the requirements will be met and what level of security applies.

Responsibilities split cleanly. The controller owns its obligations to data subjects and regulators and decides whether the processor's guarantees are adequate. The processor signs, performs and must follow documented instructions, including for transfers. Where an implementation partner deploys and hardens a self-hosted platform, it prepares systems, controls and evidence, but the organization that runs the platform remains the controller or processor of record and must be named accordingly in the contract. Only an independent auditor or certification body can issue an audit report or certificate, so a contract that promises a certificate has to specify which independent party issues it and when. Ask the prospective processor to confirm the scope of any report it can share, not just that one exists.

Before signing, check the points where the contract is most often vague: the list of sub-processors and whether you have general or specific authorization, the notice period for changes so you can object, the flow-down of the same data protection obligations to each sub-processor, the processor's duty to notify you of a personal data breach without undue delay, the process for audits and inspections, and what happens to data at the end of the contract, including deletion or return. The Commission's standard clauses in Implementing Decision (EU) 2021/915 fulfil the Article 28 requirements and can be used in whole or in part, which gives both sides a reference text to compare against. Confirm the current sub-processor list and the contact details of each processor in writing, because you must be able to name them at any time.

How a processing agreement moves from draft to signature

The sequence turns a vague idea of what a processor will do with personal data into a signed contract whose annexes describe the processing and security measures in enough detail to hold up to a customer audit or a supervisory authority inquiry.

Scope the processing in writing
The controller's business owner and privacy lead describe what personal data the processor will handle, which categories of people it concerns, the purpose, and how long the processing will run. Engineering confirms which systems, environments and locations are involved. The output is a scoped processing description that both parties accept as the factual basis for the contract. You know this step is done when every system in scope is named and the purpose can be traced to a documented use.
Choose the contract basis
The controller decides whether to negotiate a bespoke data processing agreement or use the Commission's standard clauses under Implementing Decision (EU) 2021/915, which may be used in whole or in part. Legal teams on both sides confirm which route fits the relationship and whether any transfer outside the EEA needs the transfer clauses under Implementing Decision (EU) 2021/914 added. The output is a chosen contract basis and a first draft. Confirm the drafting approach and any review timelines with the processor and your own legal team, since this document does not give durations.
Complete the annexes with actual measures
The processor's security and operations staff fill in the annexes with the technical and organizational measures actually in place, not generic wording, and the controller checks them against its own risk assessment. The sub-processor list is completed with each name, address, contact person and the service it provides, and the processor states how changes will be notified so the controller can object. The output is completed annexes. You know this step is done when each measure can point to a control or document the processor can produce on request.
Review with security and privacy staff
Security, privacy and legal staff on both sides go through the draft clause by clause, focusing on instructions, confidentiality, breach notice, assistance with rights requests and Article 32 to 36 duties, audit rights, and deletion or return at the end. The controller asks for evidence behind claims made in the annexes and records any open points. The output is an agreed draft with a list of resolved and outstanding issues. You know this step is done when no clause restates the GDPR without saying how it will be met.
Sign and file the agreement
Authorized signatories on both sides sign the agreement, which may be executed electronically because the GDPR allows a written contract in electronic form. The controller stores the signed agreement with its annexes, the scoped processing description and the review record, and sets a date to revisit the annexes when systems or sub-processors change. The output is a signed agreement on file. You know this step is done when the controller can produce the complete set within its own records of processing.

Which Article 28 clauses a customer checks first

Article 28(3) groups a processor's duties into a handful of clusters that a customer can test one at a time. Each card below names one cluster, explains what the clause has to do in practice, and lists the evidence a customer should request before signing. Read together, they show whether the contract describes a working control environment or only restates the regulation.

Processing only on documented instructions

The processor may act only on the controller's documented instructions, including instructions about transfers outside the EEA. The clause should say which processing the customer has authorized and how changes to instructions are recorded. Check whether the instructions are listed in an annex and whether the processor has a route to flag instructions it considers unlawful. Ask for the written instruction set and the change process for it.

Staff confidentiality

Everyone who handles the personal data must be bound by a duty of confidentiality, whether by contract or statute. The clause should cover employees, contractors and temporary staff, and it should continue after the engagement ends. Ask how confidentiality undertakings are signed, how access is limited to staff who need it, and whether the processor trains staff on handling personal data.

Article 32 security measures

The processor must take the security measures required by Article 32, and the contract should specify them rather than repeat the regulation. A customer should expect a technical and organizational measures annex that describes encryption, access control, logging, backup and restore, and testing in concrete terms. Ask for the current annex, the date it was last reviewed, and the evidence behind each measure, such as configuration baselines or independent test reports.

Sub-processor conditions

A processor may use a sub-processor only with the controller's authorization, either specific or general. Under general authorization, the processor must notify the controller of changes in time for the controller to object, and it must impose the same data protection obligations on the sub-processor. Ask for the current sub-processor list with names, addresses and contact persons, the notice period for changes, and the objection procedure. Confirm that the processor can produce the sub-processor contracts on request.

Assistance with rights and Articles 32 to 36

The processor must help the controller answer data subject requests and meet its own duties under Articles 32 to 36, which cover security, breach notification, impact assessments and prior consultation. The contract should state response times for forwarded requests and how the processor supports breach notices and impact assessments. Ask for a named escalation path, the format in which the processor delivers data for access requests, and the information it will provide for a DPIA.

Deletion or return at the end

When the services end, the processor must delete or return all personal data at the controller's choice, unless EU or Member State law requires storage. The clause should set a deadline, cover backups and copies held by sub-processors, and require written confirmation of deletion. Ask how backups are purged on a rolling basis, what format the data is returned in, and who verifies that deletion happened.

Why the Commission's standard clauses shorten the negotiation

The Commission's standard contractual clauses between controllers and processors, set out in Implementing Decision (EU) 2021/915 of 4 June 2021, fulfil the Article 28(3) and (4) requirements, and the Article 28(6) and (7) provisions allow them to be used in whole or in part. For most customers, the practical effect is that the core terms are already drafted, so the negotiation shifts from debating whether the contract covers the required elements to filling in the parts that only the parties can supply. Using the clauses unchanged does not, by itself, make the arrangement compliant, because the annexes still have to describe your actual processing, your sub-processors and your security measures.

That is where most of the remaining effort sits. The EDPB's Guidelines 07/2020 caution that an agreement should not merely restate the GDPR but should specify how the requirements will be met and the level of security required. A reviewer will look for a concrete description of the systems, data categories, access paths and encryption and logging arrangements, and for a sub-processor list that names each entity and its location. Before signing, confirm that the annex on security measures reflects what the platform does in your environment, and ask who maintains the sub-processor list and how changes are notified.

If the processor is located in a third country, the controller-to-processor and processor-to-processor modules of Decision (EU) 2021/914 can also carry the Article 28 terms. Whether those modules fit a given engagement, and how they interact with the transfer assessment, is a legal question. Confirm the approach with counsel before relying on it, and make sure the chosen clauses and any additional terms are consistent with each other.

Specific versus general sub-processor authorisation

Under prior specific written authorisation, the controller approves each named sub-processor before the processor uses it. The processor must name the sub-processor and the processing it will perform, and the controller decides whether to accept it. This gives the controller direct control over every entity that touches its personal data, at the cost of slower change management: a new hosting provider, support vendor or analytics tool cannot be introduced until the controller signs off.

Named approvals: The contract or an annex records each approved sub-processor, its location and the processing it performs.
Change requests: Any addition or replacement goes back to the controller as a formal request before the sub-processor is engaged.
Sub-processor list: The list should give the legal name, registered address, the contact person for data protection matters, the processing activity and processing locations for each entity.
Flow-down terms: The processor must impose the same data protection obligations on each approved sub-processor by written contract, and remains liable to the controller for their performance.
Operational cost: Product, procurement and security teams must review each request, which slows vendor onboarding.

Before signing, confirm how long the controller has to respond to a change request, whether silence counts as approval, and what happens if the controller refuses.

Clause-by-clause checklist before signing

This table lists the clause areas an Article 28 processor contract must address, what the customer should confirm in each, and the evidence to request before signing. Read each row against the draft contract and its annexes, not against the processor's general terms alone. Vague wording in any row is a reason to ask for specifics before signature.

Clause area	What to confirm	Evidence to request
Subject matter and duration	The contract states the service, the processing activity and how long processing lasts, tied to the service term	Service description or order form referenced by the DPA, with the term and end-of-service date
Nature and purpose	Purposes are specific to the service, not open-ended, and the processor is limited to them	Annex describing processing operations and purposes, matched to the platform actually deployed
Data types and data subject categories	Named categories of personal data and of individuals, including any special category data	Annex listing data types and subject groups, reviewed against your records of processing
Documented instructions, including transfers	Processing only on documented instructions, with transfers to third countries covered by those instructions	Written instruction procedure, list of permitted transfer locations and the transfer mechanism used
Staff confidentiality	Personnel with access are bound by confidentiality, whether by contract or statute	Confirmation of staff confidentiality terms and access restriction to personal data
Security measures (annex)	A dedicated annex sets the Article 32 measures in specific terms, not a restatement of the law	Current technical and organizational measures document, with encryption, access control, logging and backup details
Sub-processor authorisation and list	Whether authorisation is specific or general, the notice period for changes and your right to object	Current sub-processor list with name, location and processing role, plus the change notification process
Rights request assistance	Processor passes requests to you and helps you meet your deadlines using defined technical means	Description of tools or procedures for locating and returning or deleting individual data
Breach assistance	Notice to you without undue delay after awareness, with the information needed for your notification duties	Incident notification procedure, named contact route and breach notice template
Deletion or return at end	Choice of deletion or return at contract end, with a stated timeline and certification of deletion	Deletion procedure covering production, backups and replicas, and a written deletion confirmation
Audit and inspection rights	Information rights and audits, including inspections by you or a mandated auditor, with cost and notice terms stated	Available audit reports or independent assessment summaries, and the process for requesting an audit

Breach notice, audit rights and liability terms to test

The breach clause is where a processor agreement either works in a real incident or fails. Under Article 33(2), a processor must notify the controller of a personal data breach without undue delay, and Article 28(3)(f) requires the processor to assist the controller with its own duties under Articles 32 to 36, including the 72-hour notification to the supervisory authority. The contract should state a notice channel, a named contact, the information the processor will provide in its first notice and the form of follow-up updates. Ask the processor how it detects breaches in its own estate and in each sub-processor's, because the controller's clock starts when it becomes aware of the breach, and a vague notice term can leave the controller with little time to act. Confirm each term with counsel and the processor before signing.

The audit clause implements Article 28(3)(h), which requires the processor to make available all information needed to show compliance and to allow and contribute to audits, including inspections, by the controller or an auditor it mandates. Check how audits are scheduled, how much notice is required, whether the controller can run a for-cause audit after an incident, and what evidence is shared first. Many processors offer independent reports where they hold them, but a report does not replace the controller's right to inspect the systems that process its data, so the contract should say how the two interact. Also confirm who pays for audits and for remediation work they uncover. These are points to negotiate and confirm with the processor, not standard outcomes.

Liability terms decide who bears the loss when things go wrong. Under Article 82(2), a processor is liable for damage caused by processing where it has not complied with processor obligations or has acted outside the controller's lawful instructions, so the contract's instruction and indemnity language should match that allocation. Article 28(10) adds a separate risk: a processor that decides the purposes and means of processing is treated as a controller for that processing. Ask whether the processor's roadmap, analytics or product improvement uses could trigger this, and confirm in writing that data is used only on documented instructions. Review caps, carve-outs and indemnities with counsel, and record what the processor has agreed to in writing.

Where agreement negotiations stall and how to avoid them

Most data processing agreements stall on the same few points: annexes that say little, sub-processor lists that are stale, audit terms that stop short of inspection, and roles nobody has pinned down. Each card names one delay, why it matters under Article 28, and the step that clears it before signature.

Generic annexes that restate the GDPR

An annex that repeats Article 32 in general terms gives the controller nothing to test. Article 28 requires the contract to set out the subject matter, duration, nature, purpose, data types and data subject categories, and EDPB Guidelines 07/2020 say the agreement should specify how requirements will be met and the level of security required. Ask the processor to describe each measure, the systems it covers and who operates it before signing.

Sub-processor lists missing or out of date

Article 28(2) requires prior written authorisation for sub-processors, either specific or general, and EDPB Opinion 22/2024 says the controller should have the name, address and contact person of every processor and sub-processor available at all times. A list dated at signing and never updated leaves the controller unable to object to new providers. Require a current list with names, addresses and contacts, plus a notice period for changes that allows an objection.

Audit clauses that exclude inspections

Article 28(3)(h) requires the processor to provide information and allow audits, including inspections, conducted by the controller or an auditor it mandates. Clauses that offer only a summary report or a third-party certificate leave out the on-site or remote inspection the article names. Confirm who may audit, how much notice applies, who pays, and whether the processor will support inspections of its sub-processors.

Breach notice terms without deadline mechanics

Article 33(2) requires a processor to notify the controller of a personal data breach without undue delay, and Article 28(3)(f) requires help with the controller's own notifications. A clause that says only prompt notice gives no clock to hold the processor to. Agree a fixed outer limit for first notice, the content of that notice, a named contact, and the cooperation duties that follow, so the controller can meet its own 72-hour window under Article 33(1).

Transfer terms left open for support staff

Remote support from outside the EEA is a transfer even when the data stays in an EU data centre. Where the processor is in a third country, the controller-to-processor and processor-to-processor modules of the transfer clauses in Decision (EU) 2021/914 set out the Article 28 duties, so they must be chosen and completed. Ask where every support location sits, which entities can access data, and which transfer mechanism covers each one.

Controller and processor roles in dispute

Under Article 28(10), a processor that decides the purposes and means of processing becomes a controller for that processing, and Article 82(2) makes it liable for acting outside lawful instructions. Disputes arise when a processor wants to reuse data for its own product analytics or model training. Write the documented instructions into the contract, list permitted uses in the annex, and state that any other use requires the processor to take on controller duties for it.

Who owns each part of the agreement

The controller is the organization that decides why and how personal data is processed. It remains responsible for choosing a processor with sufficient guarantees, for signing a contract that meets Article 28 and for overseeing the processor throughout the relationship. The controller also sets the documented instructions the processor must follow, including instructions on transfers, and decides whether a proposed sub-processor is acceptable.

Instructions: The controller defines the subject matter, duration, nature, purpose, data types and data subject categories that the processor works within.
Sub-processor approval: Under specific authorisation, the controller approves each sub-processor. Under general authorisation, it receives notice of changes and can object.
Guarantees: The controller assesses the processor's expertise, reliability and resources before signing, and keeps that assessment on file.
Ongoing oversight: The controller reviews processor information, exercises audit rights and checks that breach notices arrive in time.
Records: The controller keeps its own record of processing and the processor contract as evidence.

Before signing, check that the instructions match what your teams actually ask the processor to do, and that you can name every sub-processor.

Questions buyers ask about GDPR processing agreements

Is a data processing agreement legally required under the GDPR?

Yes, when a processor handles personal data for a controller. Article 28(3) requires that processing be governed by a contract or other legal act that binds the processor and is in writing, and Article 28(9) confirms that electronic form is acceptable. The contract must set out the subject matter and duration of processing, its nature and purpose, the types of personal data and categories of data subjects, and the controller's obligations and rights. Without it, the arrangement fails Article 28 even if the provider's security is strong. Check whether your organization is the controller or the processor for each system before drafting, because the answer determines which side owes the contract.

Can we use the Commission's standard contractual clauses as they are?

Yes. Commission Implementing Decision (EU) 2021/915 sets standard contractual clauses between controllers and processors, and Article 28(6) and (7) state that they may be used in whole or in part. Using them as a base saves drafting effort, but the EDPB Guidelines 07/2020 say a contract should not merely restate the GDPR. It should specify how each requirement is met and the level of security required. Expect to complete the annexes with the processing details, the technical and organizational measures, and the approved sub-processors. Where the processor sits outside the EEA, the transfer clauses in Decision (EU) 2021/914 also contain the Article 28(3) and (4) terms, so legal review of the transfer route is needed as well.

How are sub-processor changes approved and tracked?

Sub-processors need the controller's prior authorization, either specific for each engagement or general with a notice process. Under Article 28(2) and (4), a general authorization means the processor must tell the controller about planned changes so the controller can object, and the same data protection obligations must be imposed on each sub-processor. Under EDPB Opinion 22/2024, the controller should hold the name, address and contact person of every processor and sub-processor at all times, though it need not systematically request each sub-processing contract. Effort depends on how many suppliers sit in the chain, how often they change, and whether your procurement team can review notices within the objection window written into the contract.

Can a customer audit a processor, and how does that work?

Yes. Article 28(3)(h) requires the contract to make available all information needed to show compliance and to allow audits, including inspections, by the controller or an auditor it mandates. The contract should define who may audit, how much notice applies, what scope is covered, how the processor's own third-party reports are used, and who pays. Many processors meet routine requests by sharing documentation and questionnaires, then reserve on-site or technical inspections for cause. An independent report, where one exists, does not replace the contractual audit right. Confirm these terms with your legal team and the provider before signing, because the GDPR itself does not set audit frequency or cost allocation.

What should breach notice terms say?

The contract should require the processor to notify the controller of a personal data breach without undue delay, as Article 33(2) requires, and to assist with the controller's duties under Articles 32 to 36 under Article 28(3)(f). Good terms name a notice channel and contact, set what information the first notice must carry, and state how updates and forensic cooperation will work. Because the controller's 72-hour clock under Article 33 runs from awareness, the notice window in the contract should be short enough to leave time for assessment. Also confirm who pays for notifying individuals and for forensic support. Those costs, and the liability position under Article 82(2), are often where negotiations take longest.

Can a data processing agreement be signed electronically?

Yes. Article 28(9) states that the contract must be in writing, including in electronic form. An electronic signature, a click-through acceptance of online terms, or a countersigned PDF can all satisfy the form requirement if they bind both parties and the record is kept. Check that the version you accept is the one that includes your annexes, the sub-processor list and the security description, because a standard online addendum without those details may not meet Article 28(3). Keep a dated, retrievable copy with the record of processing so you can produce it during a customer audit or a supervisory authority inquiry.

What must we do ourselves, and what can an implementation partner prepare?

Your organization owns the decisions. You must define the processing purposes, classify the data, decide the controller and processor roles, approve sub-processors, negotiate liability and sign the contract. An implementation partner such as DeployOpen can prepare the technical inputs: a description of the self-hosted platform's security measures, the architecture and hosting locations for the annexes, access and logging configuration, backup and deletion procedures, and the evidence that supports audit requests. The partner does not issue audit reports or certificates, and it does not replace your legal review. Ask for the deliverables in writing and confirm which annex items each one feeds before work starts.

Does a GDPR certificate replace the processing agreement?

No. Article 42 certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the responsibility of the controller or processor. A certificate may support the processor's guarantees under the EDPB Guidelines 07/2020, which list adherence to codes or certification as one factor, but it does not satisfy Article 28(3). The contract must still set out the processing details, instructions, sub-processor terms, audit rights, deletion or return duties and breach terms. Treat any certificate as supporting evidence you request, not as a substitute for the agreement itself.

How DeployOpen prepares the systems and evidence behind a processing agreement

DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure. For a processing agreement, we help the organization make the systems, configuration and records match what the contract promises, while the organization keeps ownership of its controller and processor roles and the contract terms.

How we scope

Written scope lists the platforms, hosting environments and data flows the processing agreement will describe.
We map which processing activities, data categories and sub-processors appear in the contract annexes and systems.
Scope names who owns each decision, including legal review of the contract and approval of sub-processors.

How we build

We configure access control, logging, encryption and backup settings so the Article 32 measures named in the contract are in place.
Sub-processor and hosting details are recorded in configuration and documentation that can be shared on request.
Deletion and return of data at contract end is built as a tested procedure, not only a clause.

How we hand over

Deliverables include configuration records, security measure descriptions and a register of systems and data flows.
Breach notification steps are documented so the organization can meet processor notice duties to its controller.
Handover includes a walkthrough so the client's team can show auditors and customers how each contract commitment is evidenced.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
We help update system records when sub-processors, hosting locations or contract annexes change.
Confirm with your legal counsel and the independent auditor who will assess the evidence before engagement starts.

GDPR data processing agreement: what to check before signing