Data processing agreement: template and step-by-step checklist

A data processing agreement is a written contract required under GDPR Article 28 that documents processing scope, security commitments, sub-processor rules, and deletion obligations between a controller and a processor. The fastest path to a signed one is to start from a template built on Article 28's mandatory elements, then fill in Annex I (processing details), Annex II (security measures), and Annex III (sub-processors) with facts specific to your vendor relationship, not boilerplate language.

Skip the blank page. Two practical starting points exist: a static legal template you customize by hand, or a guided tool like Formable's DPA creator that turns questionnaire answers into a draft contract.

Before you send anything for signature, confirm you can check off the following:

• The contract names a specific legal basis for processing and describes the actual data categories involved, not a generic placeholder.
• Annex II lists real security controls, such as encryption in transit and at rest, rather than aspirational promises, with examples detailed on security and confidentiality obligations.
• A sub-processor list exists, either as a static annex or a maintained URL, with a defined notice period for changes.
• Breach notification timelines and deletion deadlines are stated in hours or days, not vague terms like "promptly."

Pro Tip: A DPA with blank brackets left in the security or deletion sections is worse than no DPA at all. It signals to auditors and counterparties that nobody actually reviewed the document before signing.

Table of Contents

• How to create a data processing agreement that meets Article 28
• What is the fastest way to draft a DPA from scratch?
• What should Annex I, Annex II, and Annex III actually say?
• Customization checklist and common mistakes to avoid
• Drafting a DPA with a guided tool instead of a blank template
• Signing, onboarding, and keeping a DPA current
• Legal basis and the controller processor relationship
• Aligning a DPA with laws beyond GDPR
• Sector-specific clauses worth adapting
• Sources
• FAQ

How to create a data processing agreement that meets Article 28

Every compliant DPA traces back to the same seven obligations under GDPR Article 28, and skipping any one of them is the most common reason DPAs bounce back during vendor security reviews. The regulation does not just require a contract to exist. It specifies what that contract has to say about subject matter, duration, the nature and purpose of processing, and the rights and obligations of both parties, according to GDPR.eu's breakdown of Article 28.

Here is what each mandatory clause needs to actually contain, not just gesture at.

1. Processing on documented instructions. The processor may only act on the controller's written instructions, including instructions about international transfers. Express this by referencing Annex I directly rather than a general phrase like "as directed by controller." Something like "Processor shall process Personal Data solely for the purposes described in Annex I and any subsequent written instructions" gives the clause teeth.
2. Confidentiality commitments. Personnel with data access must be under a confidentiality obligation, whether contractual or statutory. Strong drafting names the mechanism: "Processor shall ensure that persons authorized to process Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality." Vague references to "standard onboarding" don't hold up.
3. Security measures mapped to Article 32. This is where most templates get lazy. Instead of "processor maintains appropriate security," name the actual controls: TLS 1.2 or higher for data in transit, AES-256 for data at rest, multifamily authentication for administrative access, and centralized logging with defined retention. The UDT guide on drafting GDPR DPAs makes the point directly: annexes should list what's actually in place, not what sounds impressive.
4. Sub-processor authorization. You have two models. General authorization lets the processor add sub-processors freely as long as it notifies the controller and gives an objection window. Specific authorization requires sign-off before each new sub-processor goes live. General authorization with a real notice period, commonly 30 days, tends to work better operationally because it doesn't force a contract amendment every time a vendor swaps its email delivery provider.
5. Flow-down obligations. Whatever data protection terms bind the primary processor must also bind every sub-processor, under a contract that imposes the same standard. A DPA that authorizes sub-processing without requiring flow-down terms is effectively creating a gap in the chain of accountability.
6. Assistance obligations. The processor must help the controller respond to data subject requests, complete data protection impact assessments, and notify supervisory authorities of breaches. Put a number on the breach notification piece. Market practice ranges from 24 to 72 hours for the processor to notify the controller after becoming aware of an incident, per drafting guidance from GDPRScoreCheck. Silence on the exact window is one of the most common gaps counsel flags in vendor review.
7. Deletion or return, and audit rights. At contract termination, personal data must be deleted or returned, with any legally required retention period stated explicitly. Audit rights should specify what evidence satisfies them, typically SOC 2 or ISO 27001 reports, with a bilateral right to a targeted audit reserved for exceptional circumstances rather than routine use.

Miss any one of these seven and you don't have a DPA. You have a document that looks like one until someone tests it during an incident or a regulatory inquiry.

What is the fastest way to draft a DPA from scratch?

A DPA drafted in a single focused session, using a proper template and factual inputs gathered in advance, moves faster than one drafted clause by clause from a blank document. The bottleneck is almost never legal language. It's tracking down the factual details, like which encryption standard your infrastructure team actually uses, that stalls most drafts for days.

Work through these steps in order:

1. Classify the relationship. Confirm whether your organization is the controller, the processor, or a joint controller for this specific processing activity. A vendor processing customer support tickets on your behalf is your processor. A vendor that decides independently how to use aggregated data for its own analytics may be a joint controller or a separate controller entirely. Get this wrong and the entire contract structure is wrong.
2. Fill the parties block and Annex I. Capture the legal entity names, the categories of data subjects (employees, customers, website visitors), the categories of personal data (contact details, payment information, health data), the purpose of processing, and the duration. Avoid catch-all phrases like "any data the controller may provide." Name what's actually being shared.
3. Populate Annex II with real controls. List only measures currently in place. If your infrastructure runs quarterly restore tests, say quarterly restore tests. If it doesn't, don't write it in. Reserve the right to substitute measures with "functionally equivalent" alternatives so you're not locked into naming a specific vendor forever.
4. Decide the sub-processor model. Choose general or specific authorization, then either attach a static Annex III list or link to a maintained URL. A live URL avoids re-signing the whole agreement every time a sub-processor changes, an approach the UDT drafting guide recommends specifically to cut negotiation friction.
5. Select transfer mechanisms if data crosses borders. If personal data moves outside the jurisdiction where the controller operates, attach Standard Contractual Clauses or the applicable transfer mechanism, and complete a transfer impact assessment scaffold covering the destination country's legal environment.
6. Set the operational numbers. Breach notification window (commonly 24 to 72 hours), audit evidence type (SOC 2, ISO 27001, or both), and deletion timeline post termination (30 to 90 days is typical, though regulated industries often run longer).

The step people skip is gathering facts before they open the template. Pull your security team into a 20 minute call, get the actual list of technical controls and sub-processors, and the drafting itself takes a fraction of the time.

What should Annex I, Annex II, and Annex III actually say?

Annexes are where most DPAs fail, not the main body text. A generic main contract paired with three blank or aspirational annexes is functionally worthless in an audit, because the annexes are what a regulator or a customer's security team actually reads first.

Annex I (processing details) needs specificity, not categories borrowed from a template. Instead of "personal data as required for services," write something like: "Contact information (name, email, phone), account credentials, and usage logs, collected from Controller's employees and end customers, processed for the purpose of providing customer support ticketing services, for the duration of the underlying Master Service Agreement." Avoid phrases like "any and all data" or "as needed" since they give a supervisory authority nothing to evaluate.

Annex II (technical and organizational measures) should read like a systems inventory, not a marketing page. A workable example: "Encryption in transit via TLS 1.2 or higher; encryption at rest via AES-256; multifactor authentication required for all administrative access; access logs retained for 90 days; disaster recovery testing performed quarterly with documented restore results." That level of specificity matches what a worked review of data transfer agreements in health research found to be common among stronger agreements: annex-level detail on mechanics, not general assurances.

Annex III (sub-processors) works best as either a table with legal name, service provided, and processing location, or a maintained public URL the processor commits to updating. Either way, pair it with a defined notification and objection window.

A dispute resolution clause without a named point of contact, an escalation path, and a resolution deadline is not a dispute resolution clause. It is an invitation to a stalemate the first time something goes wrong.

That principle, drawn from worked clause examples in data sharing agreements, applies just as much to sub-processor objection language. If the controller objects to a new sub-processor within the notice window and the objection isn't resolved, the contract needs to say what happens next, whether that's termination rights, a substitution obligation, or escalation to a named executive.

Anyone building out these annexes for the first time can lean on a structured DPA checklist and annex template to see how the sections fit together before typing anything into a blank document.

Customization checklist and common mistakes to avoid

Templates fail for predictable reasons, and almost all of them come down to treating the annex as an afterthought instead of the operational core of the contract.

Before sending a DPA for signature, confirm:

• Every bracketed placeholder has been replaced with an actual entity name, date, or figure.
• Annex II lists controls your security team has confirmed are currently live, not controls you plan to implement.
• A destruction or return deadline is stated in days, with a certification requirement if data sensitivity warrants it.
• Authorized users or roles with data access are named or governed by a documented approval process, not left undefined.
• Sub-processor notice periods are long enough for your legal team to actually review a change before it takes effect.

The mistakes that show up most often in vendor review:

On negotiation specifics, a 30 day sub-processor notice period, a 24 to 72 hour breach notification window, and an audit model built around SOC 2 or ISO 27001 reports (with a bilateral right to a targeted audit reserved for serious incidents) reflect common market practice, according to GDPRScoreCheck's drafting guidance. Liability caps tied specifically to the DPA (separate from the caps in the underlying master agreement) are increasingly common for high-risk processing, particularly where health or financial data is involved.

Drafting a DPA with a guided tool instead of a blank template

Formable's DPA creator works from a catalog of standard templates built on Common Paper, a widely used open source contract standard designed around a cover page plus hosted standard terms. That structure means the core legal language stays consistent while you customize only the details specific to your relationship.

The process runs as a guided questionnaire. You answer plain questions about the parties, the categories of data involved, the security controls in place, and the sub-processor arrangement, and the tool's AI drafts the annex language and core clauses from those responses. That draft is a real starting point, not a finished contract. Review it against your actual security posture before sending it out, and expect the other side to redline sections like breach notification timing or audit rights.

Once a draft is out for review, the practical value shows up in the negotiation itself:

• Both parties can redline directly in the platform, which cuts out the version-control mess of emailing Word documents back and forth.
• Signed agreements and their audit trails stay stored centrally, so you're not hunting through inboxes when a security questionnaire asks for proof of a signed DPA.
• Templates and completed annexes are reusable across future vendor contracts, which matters once you're managing more than a handful of DPAs at once.

Pro Tip: Keep your Annex II language identical across every DPA where your actual controls are the same. Inconsistent security language across contracts is one of the first things a diligent counterparty's legal team flags during review.

Signing, onboarding, and keeping a DPA current

A signed DPA is a starting point, not a filing cabinet item. The obligations inside it only mean something if someone tracks whether they're being met.

1. Capture the signature with a complete audit trail. Use e-signature tools that log timestamps, IP addresses, and the exact document version signed. That record matters if a regulator or auditor later asks when and how the agreement was executed.
2. Onboard the processor against real evidence. Before or shortly after signing, request the processor's SOC 2 report, ISO 27001 certificate, or equivalent, and complete a security questionnaire that mirrors what's actually written in Annex II. If the questionnaire answers don't match the annex, resolve the discrepancy before treating the relationship as fully onboarded.
3. Review the agreement on a set cadence. Annual review is a reasonable baseline for most vendor relationships, with a trigger review any time the processor changes infrastructure providers, adds a new sub-processor outside the notice process, or experiences a security incident.
4. Keep Annex III current. Whether you use a static list or a live URL, someone on your team needs ownership of updating it. A sub-processor list that hasn't changed in two years, when you know the vendor has grown, is itself a red flag during due diligence.
5. Coordinate incident response in advance, not during an incident. Confirm who at the processor's organization is the actual point of contact for a breach notification, and keep records of every notification received, since supervisory authorities may ask for that history during an inquiry.

Recordkeeping discipline here, naming authorized users, logging destruction certifications, tracking notification history, mirrors the operational checklist found in stronger data use agreement practices, where specificity at signing time paid off during later audits.

Legal basis and the controller processor relationship

A DPA doesn't create the legal basis for processing personal data. It governs the relationship between the party that determines why and how data is processed (the controller) and the party that processes it on the controller's behalf (the processor). The controller is responsible for identifying a valid legal basis under GDPR, such as consent, contractual necessity, or legitimate interest, before any processing begins. The DPA simply ensures the processor handles that data consistently with the controller's obligations.

This distinction matters because it determines who bears primary liability for a given failure. If the controller never had a valid legal basis to collect the data in the first place, no DPA fixes that problem. If the controller had a valid basis but the processor mishandled the data outside its documented instructions, liability shifts toward the processor, particularly if the DPA's instruction and security clauses were clear.

Joint controllership adds another layer. When two parties jointly determine the purposes and means of processing, such as a hospital and a research institution sharing patient data for a study, a joint controller arrangement under a separate agreement is often more appropriate than a standard DPA. Getting this classification wrong at the outset is why step one of any drafting workflow has to be confirming which relationship actually applies before a single clause gets written.

Aligning a DPA with laws beyond GDPR

GDPR sets the template most DPAs follow, but it isn't the only regulatory framework that governs a processing relationship, and treating it as the only one is a common blind spot for companies operating across multiple jurisdictions. Sector and location both matter.

In the United States, frameworks like the California Consumer Privacy Act impose their own contractual requirements on "service providers," a role that closely mirrors the GDPR processor concept but uses different defined terms and imposes different restrictions on data use. A DPA drafted purely against Article 28 language may not satisfy every requirement a state privacy law expects.

Sector-specific rules add another layer. Healthcare data processed on behalf of a covered entity in the United States typically requires a business associate agreement alongside or instead of a standard DPA, governed by HIPAA rather than GDPR. Financial services processors may need to address rules under frameworks like GLBA or sector-specific banking regulations that impose their own security and notification requirements.

The practical fix isn't drafting five separate contracts. It's building a base DPA around GDPR's Article 28 structure, since it tends to be the most comprehensive baseline, then adding jurisdiction-specific riders or annexes that layer in the additional obligations a specific law requires. Confirm with counsel which frameworks actually apply to your data flows before assuming a single template covers every jurisdiction where your business operates.

Sector-specific clauses worth adapting

Healthcare and financial services processing relationships need clauses a generic template won't include by default, because the sensitivity of the data and the regulatory consequences of a breach are both higher.

For healthcare processing, add language specifying that data will not be used for any secondary purpose, including research or product development, without separate written authorization. Destruction deadlines often need to be shorter and paired with a mandatory certification of destruction rather than a simple confirmation, a pattern found in health research data transfer agreements where governance depended heavily on that kind of specificity. Breach notification windows in healthcare contexts often shrink to 24 hours given the regulatory reporting clocks that start immediately once a covered entity becomes aware of an incident.

For financial services, add clauses addressing data residency requirements where regulators require certain financial records to stay within a specific jurisdiction, and consider requiring the processor to carry cyber liability insurance above a stated minimum. Audit rights in financial contexts often need to be more frequent than the standard annual cadence, particularly for processors handling payment data, and liability caps are frequently negotiated higher than in a standard commercial DPA given the regulatory exposure involved.

In both cases, the underlying Article 28 structure stays the same. What changes is the specificity and severity of the deletion, notification, and audit terms layered on top.

The single most reliable way to produce a compliant data processing agreement is to pair a proven template structure with factual, vendor-specific annexes rather than generic language.

Author perspective: why a DPA should function as an operational document

Most DPAs I've seen treated as legal checkboxes fail the moment someone actually tests them, whether that's during a breach, a customer security review, or a regulator's inquiry. The pattern is consistent: Annex II describes security controls the company doesn't actually have, or Annex III hasn't been touched since a sub-processor list that's two vendors out of date. The contract exists, but it doesn't describe reality.

The fix isn't more legal language. It's forcing the annexes to match what your infrastructure and security teams can actually confirm, then keeping that mapping current as vendors and controls change. A DPA that accurately reflects your operations is far easier to defend than one written to sound impressive.

Guided drafting tools help here in a way generic templates don't, because a questionnaire forces someone to answer specific factual questions (what encryption standard, what notice period, which sub-processors) rather than accepting placeholder language by default. That doesn't replace legal review. It does mean the draft arriving on counsel's desk is closer to accurate on the first pass, which shortens the negotiation cycle considerably compared to redlining a document full of aspirational claims.

Treat the DPA as a mirror of your actual practices, not a wish list, and most of the friction in vendor negotiations disappears on its own.

— Alex

Get your DPA drafted and signed in one sitting, not one quarter

Formable turns DPA drafting from a multi-week email chain into a single guided session, built on Common Paper's trusted template structure so you're not negotiating from a blank page. The DPA creator walks you through a questionnaire covering your processing details, security controls, and sub-processor setup, then generates a complete draft with Annexes I, II, and III already populated from your answers.

From there, send the draft straight into redlining so both sides can resolve terms in one shared document instead of trading Word attachments, and capture the signature with a full audit trail once everyone's aligned. Every signed DPA and its sub-processor history stays stored in one place, ready to hand over the next time a customer's security team asks for proof. Run a final legal review before execution, since no generated draft replaces counsel's judgment on your specific risk exposure. Open the DPA creator and see how far a first draft gets you in under ten minutes.

Sources

A handful of resources cover the ground this article can't fully replace, particularly for teams that want a second reference point before finalizing language.

• Gdpr
• The anatomy of a data transfer agreement for health research - PMC
• Data sharing agreement worked example | CASRAI

Whichever template you start from, pair it with factual annexes specific to your actual vendor relationship, and route the final draft through legal review before signature. A template gets you 80% of the way there.

FAQ

What should be included in a data processing agreement?

A compliant DPA must cover the subject matter, duration, nature, and purpose of processing, the categories of data and data subjects involved, plus clauses on confidentiality, security measures, sub-processor authorization, breach notification, deletion or return of data, and audit rights, per GDPR Article 28.

What is a data processing agreement?

A data processing agreement is a legally required written contract between a controller and a processor that governs how personal data is handled on the controller's behalf, ensuring the processor meets GDPR's security and accountability standards.

What are the 5 steps of data processing?

Definitions vary depending on the framework, but in a data lifecycle context the common stages are collection, storage, processing, analysis, and destruction or archiving, each of which a DPA should account for through its Annex I and Annex II language.

Is a DPO legally required?

A Data Protection Officer is mandatory under GDPR only for public authorities, or organizations whose core activities involve large-scale, regular, and systematic monitoring of individuals, or large-scale processing of special category data; most small and mid-sized businesses fall outside that requirement.

Can I use a template to create a DPA myself?

Yes, a structured template like the one from Common Paper or a guided tool such as Formable's DPA creator can produce a solid first draft, but factual annexes and a final legal review remain necessary before signature.