Data Processing Agreement

A Data Processing Agreement is a contract that sets the rules for how a service provider processes personal data on behalf of another business.

For in-house legal teams, GCs, and legal ops professionals, a DPA is often a standard part of vendor, customer, and SaaS contracting. It helps allocate privacy responsibilities, reduce risk, and meet legal requirements under laws like the GDPR.

What is a Data Processing Agreement?

A Data Processing Agreement (DPA) is a contract between a data controller and a data processor.

• The controller decides why and how personal data is used.
• The processor handles that personal data on the controller’s behalf.

A DPA explains:

• what personal data is being processed
• why it is being processed
• how it must be protected
• who can access it
• whether subprocessors can be used
• what happens if there is a breach
• when the data must be returned or deleted

In practice, a DPA is usually a data processing addendum attached to a:

• Master Services Agreement
• SaaS agreement
• vendor agreement
• outsourcing contract
• customer services contract

Simple example

A company buys a customer support platform. The platform stores customer names, email addresses, and support messages for the company.
In that setup:

• the company is the controller
• the software provider is the processor
• the parties typically sign a controller and processor agreement, usually in the form of a DPA

When do you need a Data Processing Agreement?

You typically need a Data Processing Agreement when one party processes personal data on behalf of another party.

Common examples include:

• SaaS providers
• cloud hosting vendors
• payroll and HR tech platforms
• CRM and marketing tools
• customer support systems
• outsourced IT or back-office services

Under Article 28 GDPR, a controller must have a written contract in place with processors that includes specific terms. Similar obligations also appear in other privacy frameworks and customer procurement requirements.

Does every vendor need a DPA?

No. A DPA is generally needed only if the vendor is processing personal data for you.

For example:

• Yes, DPA needed: a payroll provider handling employee data on your behalf
• Maybe not: a vendor supplying office furniture
• Different analysis: a partner receiving shared customer data for its own purposes may need a data sharing agreement, not a DPA

What should a Data Processing Agreement include?

A strong GDPR data processing agreement usually covers the following points:

• Subject matter and duration of processing
  What services are being provided, and for how long data will be processed.
• Nature and purpose of processing
  Why the processor is using the data and what it is doing with it.
• Categories of personal data
  For example, names, email addresses, employee records, payment details, or usage data.
• Categories of data subjects
  Such as customers, employees, contractors, or website users.
• Documented instructions from the controller
  The processor should only process personal data based on the controller’s instructions.
• Confidentiality obligations
  People handling the data must be bound by confidentiality duties.
• Technical and organizational security measures
  The processor should describe the security controls it uses to protect data.
• Subprocessors and approval mechanisms
  The DPA should explain whether subcontractors can be used and how they are approved. This is where the subprocessor clause becomes important.
• Assistance with data subject rights requests
  The processor should help the controller respond to requests such as access, deletion, or correction.
• Personal data breach notification
  The DPA should say how quickly the processor must notify the controller of a breach.
• Return or deletion of data
  What happens to the personal data when the contract ends.
• Audits and inspections
  Whether the controller can verify compliance and how that process works.
• International data transfers
  If data moves across borders, the parties may need Standard Contractual Clauses or another valid transfer mechanism.
• Liability and indemnity language
  Where applicable, the DPA should align with the main commercial agreement and avoid conflicting risk terms.

Quick checklist: must-have DPA clauses

If you are reviewing a vendor data processing agreement, check for these core items:

• controller and processor roles are clear
• processing purpose is defined
• data categories and data subjects are listed
• security commitments are attached or referenced
• subprocessors are addressed
• breach notification timing is stated
• assistance with privacy requests is covered
• deletion or return terms are clear
• international transfer terms are included where needed
• liability language works with the main agreement

Where does a DPA show up in contracting?

A personal data processing contract often appears as:

• a schedule to an MSA
• a standalone DPA agreement
• a privacy addendum to a SaaS contract
• a procurement paper required during vendor onboarding

For legal and legal ops teams, DPAs often sit at the intersection of:

• procurement
• privacy review
• security review
• vendor management
• contract lifecycle management

Data Processing Agreement vs related privacy agreements

DPA vs Data Sharing Agreement

A DPA applies when one party processes personal data on behalf of another.
A Data Sharing Agreement is used when parties share personal data for their own independent purposes.

DPA vs Business Associate Agreement

A Business Associate Agreement (BAA) is a healthcare-specific agreement used under HIPAA.
A DPA is broader and typically tied to privacy laws like the GDPR. Some healthcare deals may require both.

DPA vs privacy policy

A privacy policy tells individuals how an organization handles personal data.
A DPA is a contract between businesses that allocates legal and operational responsibilities.

DPA vs security addendum

A security addendum focuses on technical and security controls.
A DPA covers privacy-specific processing terms and may incorporate a security exhibit.

Common negotiation issues in a Data Processing Agreement

Most DPA negotiations focus on a few recurring issues:

• Audit rights
  Customers may ask for broad audit rights, while vendors often want questionnaires, certifications, or limited audits instead.
• Subprocessor approvals
  Controllers may want consent rights; processors often prefer general authorization with notice and objection rights.
• Standard Contractual Clauses
  Cross-border transfers often trigger negotiations over SCCs, transfer impact assessments, and data hosting commitments.
• Security exhibit language
  Legal, privacy, and security teams often need to align on how detailed the security commitments should be.
• Breach notice timelines
  Customers may ask for notice within 24 hours; vendors may push for “without undue delay” or a slightly longer period.
• Deletion timelines after termination
  Controllers want prompt deletion; processors may need retention periods for backups, legal holds, or system limitations.
• Liability caps
  One of the most contested issues is whether DPA breaches fall under the main agreement’s liability cap or sit outside it.

Why it matters for in-house legal teams

A well-drafted Data Processing Agreement helps legal teams:

• reduce privacy and security risk
• support Article 28 GDPR compliance
• standardize contracting with vendors and customers
• shorten review cycles with approved fallback language
• improve consistency across procurement workflows
• track ongoing obligations like audits, deletions, and subprocessor updates

In short, the DPA is not just a compliance document. It is a practical risk allocation tool.

How legal teams can manage DPAs at scale

As DPA volume grows, manual review becomes slow and inconsistent. This is where CLM and legal ops processes matter.

Legal teams can manage DPAs more efficiently by using:

• standardized DPA templates
• pre-approved fallback clauses
• clause libraries for privacy and security terms
• automated intake and routing
• approval workflows across legal, privacy, and security
• searchable repositories for privacy agreements
• obligation tracking for audits, renewals, and deletion commitments
• AI-assisted redlining and review

For fast-moving teams, this turns DPA review from a bottleneck into a repeatable workflow.

FAQs

Is a Data Processing Agreement legally required?

Often, yes. Under the GDPR, controllers must have a compliant contract in place when a processor handles personal data on their behalf.

Who signs a Data Processing Agreement?

Usually the data controller and the data processor, often as part of the broader commercial contract package.

What clauses are required in a GDPR Data Processing Agreement?

At a minimum, it should cover the subject matter, duration, processing purpose, data categories, controller instructions, confidentiality, security, subprocessors, assistance obligations, breach notice, deletion or return, and audit rights.

What is the difference between a DPA and a data sharing agreement?

A DPA applies when a processor acts on behalf of a controller. A data sharing agreement applies when parties disclose personal data to each other for their own separate purposes.

Does every vendor need a DPA?

No. Only vendors that process personal data on your behalf typically need one.

Final takeaway

A Data Processing Agreement is a core contract for privacy compliance and vendor risk management. If a service provider handles personal data on your behalf, a DPA helps define the rules, allocate responsibility, and support compliance.

‍