Answers

What is a Data Processing Agreement?

This page explains what belongs in a DPA, who signs one, when it is legally required, and how it fits alongside the main services agreement. It is a general-purpose explanation, not legal advice. Talk to privacy counsel before executing or negotiating one.

Start free trial See pricing

Short answer

A Data Processing Agreement (DPA) is a written contract between a data controller and a data processor that spells out how personal data will be handled on the controller's behalf. GDPR Article 28 requires one with every vendor that touches personal data, and UK GDPR, CPRA, Virginia CDPA, and Colorado CPA have adopted the same pattern. A compliant DPA names the categories of data, the purposes of processing, the security measures, the rules for sub-processors, the deletion or return of data at the end, and the controller's audit rights.

Key points

What matters most.

Six things every revenue leader, legal lead, or procurement reviewer should know about Data Processing Agreements before signing one or sending one out.

What it is

A controller-to-processor contract.

A DPA is a written agreement between the party that decides why and how personal data is processed (the controller) and the party that processes the data on the controller's behalf (the processor). It sits alongside the main services contract and governs the data-handling piece specifically, not the commercial terms.

Legally required

GDPR Article 28 is the anchor.

GDPR Article 28 requires a written contract with every processor and lists eight specific terms it must contain. UK GDPR mirrors this. CPRA, Virginia CDPA, and Colorado CPA now require similar contracts between businesses and service providers or processors, with their own term lists layered on top.

Who signs

Every vendor that touches the data.

Your CRM, email platform, enrichment service, dialer, call recorder, data warehouse, analytics tool, and any contractor that handles personal data on your behalf is a processor. Each one needs its own signed DPA. Internal employees are not processors; staff access is governed by employment contracts and policy.

What it covers

Scope, security, sub-processors, exit.

A compliant DPA defines the categories of data and data subjects, the purposes and duration of processing, the technical and organizational security measures, the rules for engaging sub-processors, the handling of data subject requests, breach notification timelines, and what happens to the data when the contract ends.

Transfers

SCCs when data leaves the region.

If the processor hosts data outside the EU or UK, the DPA usually incorporates Standard Contractual Clauses (SCCs) or the UK International Data Transfer Addendum. For California, Virginia, and Colorado, cross-border terms matter less, but service-provider contract language is still non-negotiable under those statutes.

Audit rights

The controller can inspect.

Article 28 requires that the controller be able to audit the processor, typically through on-site review, written responses, or third-party certifications like SOC 2 or ISO 27001. Most SaaS DPAs channel the audit right into reviewing an existing report rather than booking a visit, which is accepted practice.

What must be in it

The eight Article 28 clauses.

GDPR Article 28(3) does not just require a contract; it enumerates eight specific things the contract must say. UK GDPR carries the same list. A DPA that is missing any one of these clauses is not compliant, no matter how long the document is. The eight clauses are the backbone, and most published vendor DPAs organize themselves around them. Reading one is faster if you know what you are looking for.

Subject matter

Scope, nature, and purpose.

The contract must describe the subject matter and duration of the processing, the nature and purpose of the processing, the types of personal data, and the categories of data subjects. This is usually handled by a schedule or exhibit at the end of the DPA, and it is often the only part that changes between customers.

Documented instructions

Processor acts on written orders.

The processor must only act on documented instructions from the controller, including on international transfers. The main services agreement and the DPA itself count as instructions. If the processor wants to use the data for its own purposes, it becomes a controller for that use and needs its own lawful basis.

Confidentiality

Staff bound to secrecy.

Anyone the processor authorizes to access the data must be under an obligation of confidentiality, either by statute or by a written agreement. Blanket employment NDAs usually satisfy this, but the DPA should make the obligation explicit so a controller does not have to go hunt down each HR file.

Security

Appropriate technical measures.

The processor must implement all security measures required by Article 32: pseudonymization and encryption where appropriate, confidentiality and integrity of systems, resilience, and regular testing. In practice this is where SOC 2 Type II, ISO 27001, encryption-at-rest, and access-control detail show up.

Sub-processors

Prior authorization required.

The processor cannot engage another processor without the controller's prior specific or general authorization, and must flow down the same data-protection terms to any sub-processor it does engage. Most SaaS DPAs use general authorization plus a published sub-processor list and a notice-of-change mechanism.

Data subject rights

Help the controller respond.

The processor must help the controller respond to data subject requests (access, erasure, portability, objection) by appropriate technical and organizational measures. In practical terms the processor needs to expose export, deletion, and search tooling so the controller can meet the one-month response clock.

The other three clauses

Assistance, exit, and audit.

The eight-clause list continues with three more that often take the longest to negotiate because they define the processor's ongoing obligations, how the relationship ends, and how the controller verifies compliance. These are the clauses procurement teams tend to redline, and they are where most of the risk sits once a contract is live. The audit and sub-processor terms in particular drive the length of enterprise DPA review cycles.

Breach assistance

Help with Article 32 to 36.

The processor must assist the controller in meeting its own obligations under Articles 32 to 36: security, breach notification, data protection impact assessments, and prior consultation with the regulator. Specific timelines (often 48 or 72 hours) and notice formats usually sit in a schedule or incident-response addendum.

Deletion or return

What happens at the end.

At the end of the services, the processor must delete or return all personal data to the controller, at the controller's choice, and delete any copies unless law requires retention. Backup-retention windows and certified-deletion language are common extensions; most SaaS DPAs allow 30 to 90 days for deletion from backups.

Audit rights

Information, inspection, or report.

The processor must make available all information necessary to demonstrate compliance and allow and contribute to audits conducted by the controller or an auditor the controller mandates. Most SaaS vendors channel this into reviewing SOC 2 Type II or ISO 27001 reports, which is accepted practice for ordinary audits.

Chain of liability

Processor stays on the hook.

If a sub-processor fails, the original processor remains fully liable to the controller for performance of the data-protection obligations. That is why the sub-processor flow-down matters: it is the mechanism the top-level processor uses to protect itself as much as the controller.

Transfer mechanism

SCCs or an adequacy decision.

If personal data leaves the EU or UK, the DPA must include a valid transfer mechanism: Standard Contractual Clauses (the 2021 EU set or the 2022 UK addendum), binding corporate rules, or reliance on an adequacy decision like the EU-US Data Privacy Framework. Transfer impact assessments are increasingly expected alongside.

Governing law

Jurisdiction and dispute venue.

The DPA names the governing law and the venue for disputes about data handling. These are often aligned with the main services agreement but can diverge, especially when the SCCs are incorporated: the SCCs themselves specify an EU member state as the governing law for the transfer clauses, regardless of what the services agreement says.

Beyond GDPR

US state privacy laws now require similar contracts.

GDPR was the forcing function, but US state privacy laws have adopted the same controller-processor contract pattern under their own terminology. CPRA calls the vendor a service provider or contractor, Virginia CDPA uses processor, and Colorado CPA uses processor. Each statute mandates specific contract terms that overlap with but do not perfectly mirror Article 28. Teams selling into the US now need DPAs that satisfy both the EU regime and the US state regimes without stapling three separate documents together.

CPRA California

Service provider contract terms.

CPRA requires contracts with service providers and contractors that prohibit selling or sharing personal information, restrict processing to the business purpose, require the same CPRA obligations be flowed down, and give the business audit and remediation rights. The contract is what distinguishes a service provider from a third party for CCPA purposes.

Virginia CDPA

Processor obligations statute.

Virginia's Consumer Data Protection Act requires contracts between controllers and processors covering processing instructions, confidentiality, deletion or return, assistance with security and data subject rights, and audit cooperation. The clause list reads a lot like Article 28 with Americanized vocabulary.

Colorado CPA

Nearly identical processor terms.

Colorado's Privacy Act requires substantially the same processor contract terms as Virginia, with its own enforcement regime under the Attorney General. In practice, a DPA that satisfies CPRA, CDPA, and CPA can be unified into one US addendum, especially if the vendor sells across all three states.

Connecticut and Utah

Added to the list in 2023.

Connecticut's Data Privacy Act and Utah's Consumer Privacy Act followed the same pattern with their own processor-contract requirements. Several more states (Texas, Oregon, Montana, Delaware, New Jersey) have joined or are joining, and the processor-contract clause pattern is now a national standard in all but name.

One DPA, many regimes

Consolidated vendor DPAs are the norm.

Rather than negotiating a separate contract per statute, most SaaS vendors publish a single DPA with an EU/UK module (incorporating SCCs) and a US state-law module that satisfies CPRA, CDPA, CPA, CTDPA, UCPA and successors. The structure keeps negotiation manageable and gives buyers one artifact to review.

Sector overlays

HIPAA, GLBA, and FERPA stay separate.

Sector laws like HIPAA (health), GLBA (financial), and FERPA (education) have their own contract requirements (Business Associate Agreements, service-provider agreements, written agreements) that sit alongside the DPA, not inside it. A healthcare-adjacent sales program typically needs both a DPA and a BAA with the same vendor.

A CRM with a published DPA, SCCs, and SOC 2 Type II in the trust center.

Strkr publishes its DPA, sub-processor list, and security posture openly, so procurement can review the artifact before the first call. Pricing is public and the feature pages show exactly what ships today. Still: talk to privacy counsel before executing any vendor contract.

Start free See the platform

Related questions.

Who signs a Data Processing Agreement?

The controller (your company, which decides why and how personal data is used) and the processor (the vendor acting on your behalf). Every SaaS vendor that touches personal data on your behalf is a processor: the CRM, the email platform, the enrichment service, the dialer, the call recorder, the data warehouse, the analytics tool, the help-desk system. Each one needs its own signed DPA. Internal employees are not processors; their access is governed by employment agreements and internal policy, not by a DPA.

Is a DPA legally required?

Yes, in most relevant regimes. GDPR Article 28 and UK GDPR require a written contract with every processor and list the specific terms it must contain. California CPRA, Virginia CDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, and the newer state statutes all require similar contracts between businesses and their service providers or processors. Operating without a signed DPA for a vendor that processes personal data is a violation on its face, independent of whether anything bad happens with the data.

What is the difference between a DPA and an NDA?

An NDA (non-disclosure agreement) is a general confidentiality contract that stops the other party from disclosing information you share with them. A DPA is specifically about personal data and the mechanics of GDPR Article 28 and equivalent US state laws: it defines scope, security, sub-processors, deletion, breach notification, and audit rights. An NDA is not a substitute for a DPA, and a DPA usually incorporates its own confidentiality obligations that make a separate NDA redundant for the data-handling piece.

Does my CRM vendor need a DPA?

Yes. Your CRM processes personal data (names, business emails, phone numbers, meeting notes) on your behalf, which makes it a processor under GDPR and a service provider under US state laws. GDPR Article 28 requires a signed DPA before the processing begins. Most reputable CRM vendors publish a template DPA that can be executed with a signature and link to it from their security or trust page. If a vendor cannot produce one, that is a serious procurement signal.

What are Standard Contractual Clauses, and when do they go in a DPA?

Standard Contractual Clauses (SCCs) are European Commission-approved template clauses that provide a lawful basis for transferring personal data out of the EU to a country without an adequacy decision. They go in the DPA whenever the processor hosts or accesses personal data outside the EU or UK. The 2021 EU SCCs replaced the older 2010 set, and the UK uses its own International Data Transfer Addendum. Most SaaS DPAs incorporate the current SCCs by reference and complete the required annexes.

What is a sub-processor, and how is it handled in a DPA?

A sub-processor is a vendor that your processor engages to help process personal data (for example, your CRM's hosting provider, email delivery service, or analytics tool). GDPR Article 28 requires the processor to obtain the controller's authorization before engaging a sub-processor and to flow down the same data-protection obligations. In practice, most SaaS DPAs use general authorization: the processor publishes a sub-processor list, gives notice before adding one, and allows the controller to object. The processor remains liable to the controller for the sub-processor's performance.

How long should a DPA be in force?

A DPA is in force for as long as the processor processes personal data on the controller's behalf, which is typically the term of the underlying services agreement. Several obligations survive termination, especially confidentiality, deletion or return of data, and any residual audit rights. The deletion clause usually specifies a window (30 to 90 days is common) during which the processor can purge data from live systems and backups before certifying completion. Keep the signed DPA on file for the full retention period of the data it covers, often years after the contract ends.

What happens if a processor breaches the DPA?

Several things, usually in parallel. The controller can terminate for breach under the services agreement, seek damages under the DPA, and may face its own regulator exposure if the breach caused a reportable personal-data incident. Under GDPR, both the controller and the processor can be fined directly, so the processor has its own regulatory risk, not just contractual risk. A serious breach also usually triggers the 72-hour notification clock for the controller and may require individual notice to affected data subjects. The DPA itself typically includes indemnification and liability-cap language that allocates these risks between the parties.

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing