GDPR-compliant data processing agreements (DPAs): The 8 essential clauses

Many organizations rely on third-party vendors to process personal data, which introduces security and privacy risks they must manage. Under the GDPR, controllers must establish contractual arrangements with processors through data processing agreements (DPAs) to govern how personal data is handled and protected.

‍

Teams often approach DPAs the wrong way: they treat them as standard legal paperwork rather than operational tools for managing privacy compliance. To be effective under the GDPR, DPAs need to address specific contractual requirements, including areas such as processing instructions, confidentiality, subprocessors, data subject rights, and audits.

‍

What is a data processing agreement?

A DPA is a legally binding agreement between a controller and a processor that sets out the processor’s obligations and the conditions under which it can handle personal data on the controller’s behalf.

‍

DPAs apply specifically to the controller-processor relationship and outline responsibilities for each party’s role under the GDPR. Under Article 28, controllers must only engage processors that provide sufficient guarantees to implement appropriate technical and organizational measures to protect personal data and data subject rights.

‍

The article also bars processors from engaging subprocessors without the controller’s prior authorization. If the processor has general authorization, it still must inform controllers of any intended changes and give them a chance to object.

‍

DPAs should be treated as operational documents instead of a compliance formality, as they help address risks across the entire supply chain. An effective agreement translates GDPR requirements into clear operational tasks and responsibilities, covering how data is processed, protected, monitored, and managed across the processor’s supply chain.

‍

{{cta_withimage14="/cta-blocks"}} | GDPR compliance checklist

‍

When is a DPA required?

A DPA is required whenever a controller engages a third party to process personal data on its behalf. This requirement is location independent: a controller subject to the GDPR may need an Article 28 arrangement even if its processor is located outside the EU.

‍

Besides a DPA, the organizations might also need to put an appropriate transfer mechanism in place, such as executing the European Union’s Standard Contractual Clauses (SCCs) to guarantee transfers meet GDPR criteria. This requirement applies only when international transfer is restricted, and no adequacy decision or other valid transfer mechanism is available.

‍

These requirements extend beyond the controller-processor relationship. If the processor introduces any subprocessors, they must ensure that they’re bound by contractual obligations that provide the same level of data protection required by GDPR Article 28.

‍

When should a DPA be executed?

DPAs should be executed before the processor begins processing personal data and incorporated in the third-party onboarding flow rather than handled after.

‍

In practice, the sequence should look like this:

‍

• Run a third party risk assessment to determine whether the third-party will process personal data and identify the relevant privacy requirements
• Draft a DPA or review the third-party’s standard agreement against your requirements
• Execute the DPA alongside the master service agreement (MSA), or make the DPA a condition for the relationship
• Don’t provide access to personal data or begin integration until the required contractual protections are in place

‍

A common gap is signing the MSA first and handling the DPA later, often because procurement prioritizes closing the third-party relationship. This can leave organizations with a vendor processing personal data before the contractual requirements governing that processing are finalized.

‍

Bonus read: Explore the five best GDPR compliance software to support your compliance program.

‍

The 8 stipulations of DPAs

GDPR’s Article 28 lists eight minimum requirements each DPA must include to meet regulatory expectations. They are:

‍

1. Processing instructions
2. Confidentiality obligations
3. Security of processing
4. Subprocessor management
5. Data subject rights assistance
6. Assistance with GDPR alignment
7. Return or deletion of personal data
8. Audits and demonstrating compliance

‍

1. Processing instructions

According to Article 28, processors can only process personal information as defined in the agreement with the controller. This includes instructions concerning international transfers of personal data. However, if the EU or a Member State requires the processor to handle data differently, the processor must notify the controller of the requirement, unless the law prohibits such disclosure on important grounds of public interest.

‍

Processing instructions are one of the most important safeguards of a DPA, so you must define them accurately. They should outline processing purposes, activities, data categories, and other criteria unambiguously, allowing processors to conduct activities within defined boundaries.

‍

If too broad, the instructions leave space for processors to interpret their responsibilities. Common examples of ambiguous or weak instructions include:

‍

• Vague instructions such as “process data as necessary”
• An undefined or overly broad processing purpose
• Instructions contained in verbal agreements

‍

The opposite is also true. If the instructions are too detailed, they can lose their effectiveness or purpose as processing activities evolve.

‍

2. Confidentiality obligations

The DPA should require processors to ensure that any person who has access to personal data is bound by confidentiality, either through contractual arrangements or statutory obligations. The requirement applies to all stakeholders authorized to process personal data, including employees, temporary workers, contractors, and other staff working on behalf of the processors. Defining these obligations helps minimize the risk of unauthorized access and insider risk.

‍

It’s also important to ensure confidentiality obligations continue to apply even after a person’s access ends. This includes requiring confidentiality agreements for all authorized personnel where appropriate (internal or external), enforcing role-based access, establishing onboarding and offboarding procedures, and conducting regular awareness training.

‍

3. Security of processing

DPAs require processors to have appropriate technical and organizational measures in place to meet GDPR criteria. Article 28 specifically points to Article 32, which requires processors to implement appropriate security measures, including:

‍

• Pseudonymization and encryption for personal data
• The ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services
• The ability to restore the availability and access to personal data in case of a physical or technical incident
• A process for regularly testing, evaluating, and assessing the effectiveness of the technical and organizational controls

‍

Instead of relying on generalized expectations, the DPA should lay out the security requirements, reference appropriate technical and organizational measures, establish notification responsibilities, and support ongoing assurance processes. Security measures should be appropriate to the types of data processed, services provided, and the level of risk introduced by processing.

‍

Common drafting mistakes include relying on generic security requirements, failing to specify applicable security standards and controls, and omitting provisions for ongoing security oversight.

‍

{{cta_withimage11="/cta-blocks"}}| The US data privacy checklist

‍

4. Subprocessor management

Processors can’t engage other processors for the specified processing activity without the controller’s prior authorization. When subprocessors are onboarded, they must enter a DPA with the processor that imposes the same data protection obligations as those set out in the controller-processor relationship.

‍

In complex environments, personal data will often pass across multiple systems throughout its lifecycle. Failures can occur anywhere in the supply chain, making effective oversight of subprocessors an important part of managing risk. An effective DPA should require processors to:

‍

• Maintain up-to-date lists of approved subprocessors
• Establish clear notification procedures when adding new ones
• Flow down contractual obligations to each subprocessor
• Implement supply chain risk management and oversight procedures

‍

A common issue with subprocessor management is weak approval processes. When a new subprocessor is introduced, the processor should notify the controller to allow them to object. In practice, the processor’s notification is often just an update to the subprocessor list on their website or trust center. In this scenario, the controller’s right to object is harder to exercise if the controller isn't directly alerted to the change.

‍

“Without proper notification procedures, subprocessor lists quickly become outdated. A DPA might name five approved subprocessors when it’s signed, but the vendor could add three more over the next two years without notifying the controller or updating the agreement. At that point, the DPA no longer reflects who actually has access to the data, leaving a gap in oversight.”

Evan Rowse

GTM GRC SME, Vanta

|

LinkedIn

‍

AI vendors further limit the visibility into subprocessors. A normal subprocessor relationship is static after onboarding, but for an AI product, a subprocessor can mean three things:

‍

1. Infrastructure subprocessors (the cloud host running the model)
2. Model providers, i.e., the vendor is wrapping OpenAI, Anthropic, or another foundation model via API rather than running their own
3. Data enrichment or annotation vendors, where your data is used for fine-tuning, or human review

‍

The issue is that DPAs are typically written for one use case.

‍

“Most standard DPA templates were built for infrastructure vendors, not AI vendors, so if the agreement doesn't explicitly address model providers and training data use, you haven't actually evaluated the risk; you've just filed paperwork.”

Evan Rowse

GTM GRC SME, Vanta

|

LinkedIn

‍

5. Data subject rights assistance

Processors must help controllers fulfill data subject requests (DSRs) and meet data subject rights under the GDPR. Controllers remain responsible for responding to these within the GDPR’s time frames, but processors must provide the information and operational support needed to comply.

‍

Data subjects can exercise several rights under the GDPR, including the right to access their personal data, have it erased, have inaccurate information rectified, or receive it in a portable format to transfer to another organization. Processors are often in charge of the systems that store, manage, or process that information, which makes it necessary to establish intake and response workflows between controllers and processors.

‍

Your DPA should define procedures for receiving and escalating DSARs, specify notification time frames for the processor, allocate responsibilities between the controller and processor, and outline a standardized response process.

‍

6. Assistance with GDPR alignment

Processors are expected to support controllers in aligning with Articles 32–36 of the GDPR, taking into account the nature of processing and the information available to them. Their knowledge of the systems and processing activities they manage makes their cooperation essential to ongoing compliance.

‍

The assistance should cover activities like:

‍

• Breach notifications
• Data protection impact assessments (DPIAs)
• Security of processing
• Consulting with supervisory authorities where needed

‍

DPA obligations don’t end once the DPA has been signed. Controllers may rely on processors when responding to security incidents, conducting DPIAs, or addressing other GDPR obligations, so the DPA should clearly define the processor’s responsibilities and communication procedures.

‍

Weak DPAs typically provide general compliance statements here, while a good one defines how and when the processor must assist with breach response, DPIAs, supervisory authority inquiries, and other GDPR obligations, including clear response timelines and escalation procedures.

‍

7. Return or deletion of personal data

Once the processing activity ends, processors are expected to return or delete all of the information provided by the controller, unless a Union or Member State law requires otherwise.

‍

This means that your DPA should define:

• Offboarding procedures
• Safe deletion methods (when data must be returned or deleted)
• Backup retention
• Legal exceptions to deletion
• Documentation verifying deletion occurred

‍

The goal is to make sure personal information doesn't linger in vendor environments, backups, or connected systems past the retention date. Weak DPAs often overlook retention and offboarding, providing little guidance on when data should be deleted or on appropriate deletion methods.

‍

8. Audits and demonstrating compliance

Compliance with the GDPR must be demonstrable, and controllers need reliable evidence when assessing processor risk. To comply with Article 28, processors must make available all information required for compliance and allow for and contribute to audits and inspections conducted by the controller or another auditor mandated by the controller.

‍

Weak DPAs often fail to clearly define audit rights, processes to share resources, or reasonable review requirements. In some cases, you’ll also see overly restrictive review clauses that impact the controller's ability to verify compliance.

‍

A strong DPA clearly defines audit rights, lists acceptable forms of assurance such as independent audit reports, defines evidence-sharing processes, and imposes reasonable limitations that balance assurance needs with operational practicality.

‍

How to operationalize DPAs across vendors

Some best practices to operationalize DPAs include:

‍

• Use a standardized DPA template: A standardized DPA template helps maintain consistent coverage across vendor relationships and reduce the risk of overlooking key provisions
• Integrate DPAs into vendor procurement: Making DPAs part of vendor onboarding means your team handles compliance requirements before clearing vendor access
• Link each DPA to specific processing activities: Connecting each DPA to a processing activity helps align contractual obligations with relevant data flows, vendors, and systems
• Continuously monitor DPA status: Continuous monitoring keeps DPAs current and helps you address changes in processing activities and vendor relationships faster

‍

Top GRC solutions such as Vanta can help you centrally manage DPAs and automate key GDPR compliance workflows, enabling continuous monitoring.

‍

How Vanta helps you manage DPAs and comply with privacy laws

Vanta is the #1 agentic trust platform that helps organizations streamline compliance with privacy laws and customer expectations. The platform offers agentic risk and compliance management workflows, automated evidence collection, and continuous monitoring to help teams align with 35+ regulations and frameworks.

‍

Vanta offers a privacy module to oversee privacy and risk management obligations across jurisdictions. Use it to maintain a live data inventory with processing activities linked to specific vendors, run DPIAs and manage RoPAs, and map privacy obligations to specific frameworks. The continuous monitoring extends to third and fourth-party relationships, helping you establish oversight and track DPAs across your processors.

‍

Vanta’s privacy module is available with its privacy compliance products, such as the GDPR and USDP. Other key features include:

‍

• Policy management supported by Vanta AI
• Workflow automation and control tests powered by 400+ integrations
• Risk management that connects your controls to evidence
• Centralized dashboard for tracking

‍

Schedule a custom demo to see Vanta’s features firsthand.

‍

{{cta_simple19="/cta-blocks"}} | GDPR product page

‍

Vanta is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.