Data processing agreement (DPA)

What it is and when it is used

A data processing agreement (DPA) is the contract a business signs when another business handles personal data on its behalf. The business that decides why and how the data is used is the controller; the business that carries out the processing for it is the processor. Article 28 of the GDPR requires this relationship to be governed by a written contract with specific content.

Dealroom's DPA is built for SaaS and service providers that process customer personal data, under the EU GDPR, the UK GDPR and, where applicable, the CCPA/CPRA. It sits alongside a main services contract, such as a SaaS agreement or a master services agreement, and prevails over it on data protection matters.

Who signs it and in which role

The preamble names two parties: the Controller (the customer that decides on the processing) and the Processor (the provider that processes the data on its behalf). When you create the deal in Dealroom you choose which of the two roles you hold, so the same template serves a customer preparing a DPA for its supplier and a provider preparing one for its customers. The DPA can be negotiated between both parties or completed by one party alone.

Key clauses

Scope of processing and Annex I

This clause sets what data the processor may handle and for what purpose: only named categories, the categories linked to the services, or all data needed to provide and improve the services. The facts go into Annex I (Description of Processing): you write the purpose of the processing in your own words, select the categories of personal data (from contact details and usage data to special-category data and children's data) and, if you wish, list data that is expressly out of scope. The template describes that exclusion as the strongest safeguard a processor can offer, because data it never receives cannot be transferred or compromised.

Processing instructions

Article 28(3)(a) requires the processor to act only on documented instructions. The options range from strict written instructions, through documented instructions with reasonable technical discretion for routine matters (security patches, backups), to treating the service agreement itself as the instructions.

Sub-processors

The processor needs the controller's authorisation before engaging other companies to process the data. The options are general authorisation with 30 or 14 days' notice and a right to object, specific prior approval of each sub-processor (with a 15-business-day response period and deemed approval after a reminder), or notification only. Every option records the initial sub-processor list in force when the DPA takes effect.

Security measures and Annex II

The clause sets the security standard: ISO 27001 certification, SOC 2 Type II, measures listed in an annex, or the processor's own judgement. Annex II (Technical and Organisational Measures) always contains a modest baseline (TLS in transit, role-based access, confidentiality and training, a documented security programme). Further sections, such as encryption at rest, multi-factor authentication, logging or disaster recovery, are added only where the processor confirms it can evidence them. You also state who manages physical security and which measures are inherited from infrastructure sub-processors.

Data breach notification

The processor must tell the controller of a personal data breach within 24, 48 or 72 hours, or "without undue delay" with no fixed deadline.

Data subject rights, audits and confidentiality

The processor helps the controller answer access, deletion and other requests, either by handling them directly, by assisting on request within 10 business days, or through self-service tools. Audit rights go from full on-site inspections, through annual reports with on-site audits only for cause, to reports only or a yearly questionnaire. Confidentiality for staff ranges from individual agreements with background checks to standard employment terms.

Deletion or return of data

At the end of the service the processor may have to return and delete the data within 30 days, return or delete within 60 days, delete within 90 days, or retain only anonymised data. A further option deletes production data within 30 days and treats immutable backups as deleted when the backup rotation completes (at most 180 days).

Liability and term

Liability can be unlimited, capped at two or one times annual fees, or capped per incident. Under EU or UK law the parties may add a separate cap for data breaches, either a higher "super-cap" or a lower "sub-cap". The DPA ends with the Principal Agreement, with options for termination on material breach, a 30-day cure period, termination for convenience or a fixed annual term.

International transfers, Annex III and Annex IV

The transfer clause decides where data may go: nowhere outside the controller's jurisdiction, only under Standard Contractual Clauses, to adequate countries or under SCCs, or at the processor's discretion with safeguards.

When the processor is established in the United States or another country outside the EEA, the DPA adds Annex III, which incorporates by reference the EU Standard Contractual Clauses annexed to Implementing Decision (EU) 2021/914 in their Module Two form (controller to processor). The annex states the elections: no docking clause, the sub-processor option matching the DPA, and Spanish law and the courts of Madrid for the SCCs themselves. With an active EU-U.S. Data Privacy Framework certification, the transfer relies on adequacy and the SCCs are a fallback. By default Annex III also incorporates the UK Addendum issued by the UK Information Commissioner and adaptations for transfers under the Swiss Federal Act on Data Protection, each only to the extent such transfers exist.

Annex IV is a Transfer Impact Assessment following EDPB Recommendations 01/2020, as Clause 14 of the SCCs requires. It is attached by default (it can be switched off) and records the US legal framework, the processor's declared history of government requests and breaches, and the supplementary measures in place.

Government access requests

An optional clause binds the processor to notify the controller of any request from a public authority, review and challenge it where there are grounds, disclose the minimum and report figures. These commitments also feed the contractual measures in Annex IV.

Governing law and jurisdiction

The forum options depend on the jurisdiction: the courts of Madrid for Spain; California courts, JAMS or AAA arbitration for California; and London courts, LCIA arbitration or mediation followed by the London courts for England and Wales. Every jurisdiction also offers a custom governing law and courts option, where the parties write in their own law and forum. The SCC choice of Spanish law and Madrid courts is not affected by it.

What the two sides usually negotiate

The Controller wants narrow scope, strict instructions, specific approval of sub-processors, a short breach window, on-site audits, prompt deletion and unlimited liability. The Processor prefers broad scope, operational discretion, notification-only sub-processing, "without undue delay" breach notice, reports instead of inspections, a long deletion period and a cap tied to fees.

When the two sides disagree, Dealroom proposes the balanced positions: service-linked scope; documented instructions with reasonable technical discretion; general authorisation with 30 days' notice; transfers to adequate countries or under SCCs; measures defined in Annex II; help with data subject requests within 10 business days; reports plus audits for cause; return or deletion within 60 days; a 30-day cure period; and no separate breach cap. Breach notice sits between 48 and 72 hours.

Jurisdictions and languages Dealroom supports for it

Dealroom drafts this DPA for Spain, England and Wales and California, in English or Spanish. Each jurisdiction adds its own provisions: the AEPD as supervisory authority and an SCC fallback for Spain; the ICO and the UK Addendum for England and Wales; and the CCPA/CPRA "service provider" restrictions for California.

Common mistakes

• Notification-only sub-processing or questionnaire-only audits. Dealroom warns that these may not satisfy Article 28(2) and 28(3)(h) GDPR, which require authorisation and audits including inspections.
• A breach window longer than your other commitments. Incident-response policies, cyber-insurance terms and other contracts may promise a shorter window; inconsistent windows across documents are a common audit finding.
• Claiming security measures the processor cannot evidence. Annex II becomes the SCCs' Annex II, so its statements are warranties.
• Leaving the sub-processor list blank. Any cloud-hosted service has at least one sub-processor, and an empty list leaves a visible gap in the document and in the SCC annex.
• Broad scope or vague "industry standard" security. The AEPD and the ICO expect specific, documented purposes and measures.
• Relying only on contractual measures in the transfer assessment. Without at least one technical measure the TIA cannot reach an unqualified conclusion.

# 1. Read the clauses, options and the facts it needs
curl https://dealroom.todo.law/api/v1/agent/templates/DPA \
  -H "Authorization: Bearer drk_YOUR_KEY"

# 2. Create the contract (clauses you leave out take the default option)
curl -X POST https://dealroom.todo.law/api/v1/agent/deals \
  -H "Authorization: Bearer drk_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "schema": "dealroom.solo-intake/1",
    "contractType": "DPA",
    "governingLaw": "ENGLAND_WALES",
    "language": "en",
    "dealName": "Example DPA",
    "selectionPolicy": "defaults"
  }'