Vendor Data Processing Agreements: The GDPR, CCPA, and State Privacy Provisions Most Financial Services Contracts Are Missing

TL;DR

• GDPR Article 28 requires a written data processing agreement with 8 mandatory provisions — missing any one of them makes the agreement non-compliant, regardless of what else it says
• CCPA/CPRA and 20+ US state privacy laws require similar written contracts with service providers that process customer personal data
• Sub-processor authorization, breach notification timelines, deletion certification, and audit rights are the four provisions most often absent or unenforceable in financial services vendor contracts
• EU-US data transfers require either EU-US Data Privacy Framework certification or Standard Contractual Clauses — a well-drafted DPA without a transfer mechanism doesn’t fix an unlawful transfer

You have a contract with your cloud storage vendor. Your identity verification provider. Your analytics platform. Your customer communication tool. Each of them processes personal data about your customers, probably in multiple countries. And your legal team ran the contract before signing.

But here’s the question worth asking: when’s the last time you read what the data processing provisions actually say — not whether they exist, but whether they say what they need to say to protect you under GDPR, CCPA, and the 20-state US privacy patchwork?

Most financial services vendor contracts contain a DPA or data processing addendum. Most of them are missing at least three provisions that regulators and enforcement authorities treat as mandatory. With GDPR fines exceeding €1.1 billion in 2025 and US state privacy enforcement accelerating, a DPA that looks like a DPA but doesn’t work like one is not protection — it’s exposure with extra paperwork.

Why DPAs Are a Legal Requirement, Not a Best Practice

The framing matters. A Data Processing Agreement isn’t a courtesy document you exchange with vendors to signal good privacy intent. It’s a legally mandated contract whose specific provisions are either present or missing — and missing provisions create both regulatory exposure and liability gaps.

Under GDPR Article 28, every controller-processor relationship requires a written contract. If your vendor processes personal data on your behalf — and most vendors that touch your systems do — the contract must exist and must contain each of the Article 28(3) provisions. Supervisory authorities can audit your DPA directly, and a non-compliant or missing DPA is itself a GDPR violation, separate from any substantive data protection failure.

Under CCPA/CPRA, written contracts with service providers are required to include specific restrictions on how personal information can be used. The California Privacy Protection Agency has audit authority over these contracts, and CPRA’s amendments added sub-processing requirements that many pre-2023 service provider agreements still don’t reflect.

Under US state privacy laws — Virginia CDPA (effective January 2023), Colorado CPA (effective July 2023), Connecticut CTDPA (effective July 2023), Texas TDPSA (effective July 2024), and now more than 20 states with comprehensive privacy legislation — processor contracts must contain specific provisions. The requirements vary by state, but the core elements are consistent: limit processing to specified purposes, maintain confidentiality, assist with data subject rights, allow audits, and require sub-processor flow-down.

For financial services firms already operating under GLBA, there’s an important distinction: GLBA Reg P governs customer privacy notices and opt-outs, but it doesn’t substitute for DPA requirements under state and international law. A GLBA-compliant firm still needs compliant DPAs with its technology vendors.

The Eight Mandatory Provisions Under GDPR Article 28(3)

Article 28(3) specifies exactly what a DPA must contain. Each provision is mandatory, not aspirational:

1. Instruction-based processing only. The processor may process personal data only on documented instructions from the controller — including with respect to transfers to third countries. This limits your vendor to the uses you authorize. If your contract says the vendor can use data for “service improvement” without your explicit instruction, this provision isn’t satisfied.

2. Confidentiality obligation. All persons authorized to process personal data must be subject to a confidentiality obligation — either by contract or by statutory duty.

3. Article 32 security measures. The processor must implement appropriate technical and organizational security measures. Article 32 requires these to be appropriate to the risk. In a DPA, this translates to specifying — or referencing — the actual controls: encryption standards, access controls, testing procedures.

4. Sub-processor authorization and flow-down. The processor cannot engage sub-processors without prior controller authorization (specific or general). When sub-processors are engaged, the same obligations from the DPA must flow down to them, and the original processor remains fully liable.

5. Data subject rights assistance. The processor must assist the controller in responding to data subject requests — access, rectification, erasure, portability, restriction, and objection. This has practical implications: if your vendor holds data you need to produce in response to a DSAR, your contract needs to require them to provide it within a timeframe that lets you meet your response deadline.

6. Compliance assistance. The processor must assist the controller with security obligations (Art 32), breach notification (Arts 33-34), Data Protection Impact Assessments (Art 35), and prior consultation (Art 36). For privacy impact assessments involving high-risk processing, the vendor’s cooperation isn’t optional — it’s contractually required.

7. Data return or deletion. At the end of the services, the processor must delete or return all personal data. The controller chooses which. If your contract just says the vendor “will handle data in accordance with applicable law” after termination, without specifying return or deletion, this provision isn’t met.

8. Audit rights and compliance cooperation. The processor must make available all information necessary to demonstrate compliance and allow for audits and inspections conducted by the controller or a mandated auditor. The processor must also immediately inform the controller if, in its opinion, an instruction infringes GDPR.

Any DPA missing one of these provisions is non-compliant under GDPR. A generic privacy addendum that uses vague language across these categories may not satisfy the requirement even if it purports to be an Article 28 DPA.

What CCPA/CPRA Adds to Service Provider Contracts

The CCPA/CPRA framework uses different terminology (service provider rather than processor), but the contract requirements are structurally similar to Article 28 and are now mandatory for California operations.

Required prohibitions: Your service provider contract must prohibit the vendor from: selling or sharing personal information; retaining, using, or disclosing personal information for any purpose other than the specified services; retaining, using, or disclosing personal information outside the service relationship; and combining personal information received from you with information received from other sources (except in limited circumstances).

CPRA additions: CPRA extended the service provider regime to require that vendors delete personal information at the business’s request, assist with data subject rights requests, and apply the same obligations to their own sub-processors. Contracts executed before January 1, 2023 (CPRA’s effective date) may not contain these provisions.

Audit rights: CPRA gives businesses the right to audit service provider compliance and requires service providers to cooperate. This needs to be in the contract, not just implied by the statute.

US State Privacy Laws: The Patchwork Is Now 20+ States Deep

The core processor contract requirements across US state laws are consistent enough to support a single compliant framework, but the specific variations matter:

The common required provisions across most state laws: process only as directed, maintain confidentiality, implement adequate security, delete or return data at contract end, allow the controller to audit, require sub-processors to meet the same standards, and assist with consumer rights requests.

For financial services firms processing customer data across multiple states, the practical approach is to draft DPAs against the strictest applicable requirements and ensure the result satisfies GDPR Article 28 — because a GDPR-compliant DPA will generally satisfy US state law requirements as well.

The Sub-Processor Problem

Sub-processor provisions are the most frequently incomplete section of DPAs in practice — and they’re where vendor data processing accountability most often breaks down.

Authorization mechanics matter. Most enterprise DPAs use “general authorization” — a blanket approval for sub-processing. This is legally permissible under GDPR Article 28(2), but only if the processor: (a) maintains a list of sub-processors, (b) notifies you of intended changes before they occur, and (c) gives you a meaningful opportunity to object. A DPA that posts a sub-processor list on a website but doesn’t require advance notification of changes and doesn’t give you an objection right is not meeting the general authorization standard.

Flow-down is fully your liability. When your vendor uses a sub-processor, the sub-processor must be subject to the same data protection obligations as your vendor. But if your vendor’s sub-processor agreement doesn’t contain all eight Article 28(3) provisions, and the sub-processor has a data breach, your vendor is fully liable to you — and you may not have an enforceable claim against the actual sub-processor. Contract review should include asking your critical vendors for their standard sub-processor agreements.

The liability chain matters for financial services. For firms subject to GLBA’s Safeguards Rule, the obligation to oversee service providers extends to sub-processors. If your cloud provider uses a sub-cloud provider that handles customer financial data, that relationship is within scope of your oversight obligations even if you don’t have a direct contract with the sub-processor.

International Data Transfers

If your vendor processes data outside the country where it was collected, a transfer mechanism is required. For EU personal data transferred to the US:

EU-US Data Privacy Framework (DPF). The European Commission adopted the DPF as an adequacy decision in July 2023. US organizations that certify to the DPF can receive EU personal data without SCCs. Verify your vendors’ DPF certification status at dataprivacyframework.gov — and note that certification must be renewed annually.

Standard Contractual Clauses (SCCs). The EU Commission’s June 2021 SCCs are the primary alternative. They must be incorporated by reference into the DPA (or as an annex) and executed correctly — the correct module must be selected based on the relationship type (controller-to-processor, controller-to-controller, etc.). SCCs without the correct module selection don’t satisfy the transfer requirement.

The DPF faces ongoing legal challenges, and a successful Schrems III challenge could require a fallback to SCCs. For critical transfers, having SCCs available as a backup — even while relying on DPF certification — is prudent risk management.

The Clauses Most DPAs Are Missing

Six provisions routinely appear incomplete or absent in financial services vendor contracts:

Breach notification SLAs. GDPR requires a controller to notify supervisory authorities within 72 hours of discovering a personal data breach. Your DPA needs to require the processor to notify you with enough lead time to meet that clock — typically a 24-hour or 48-hour notification obligation to you, from the processor’s discovery of the breach. Generic “without undue delay” language is not a sufficient SLA. After a vendor breach, the question of when the vendor knew and when they told you becomes legally material.

Deletion certification. Your contract says the vendor will delete data at the end of the engagement. The missing piece: written certification confirming deletion occurred, from what systems, and when. Without this, you have no evidence of compliance with your data minimization obligations.

AI/automated processing restrictions. If your vendor uses your customer data to train AI models, improve their own products, or run automated decision-making, that processing needs to be explicitly authorized or prohibited. Most DPAs executed before 2023 are silent on AI model training. This is now a material gap, particularly for financial services firms whose vendors process sensitive customer data.

Meaningful audit rights. Article 28 requires audit rights. But many DPAs define them in ways that make them functionally unexercisable: “audits may occur at mutually agreed times” with no obligation on the vendor to cooperate, no timeframe for scheduling, and no right to use an independent auditor if the vendor refuses. Negotiate audit rights that are exercisable unilaterally, with reasonable notice, and with the option to substitute a third-party auditor.

Specific security requirements. “Industry-standard security measures” is not a security requirement. Your DPA should specify: encryption in transit and at rest, access control procedures, penetration testing frequency, and patch management timelines. The level of specificity should be proportionate to the sensitivity of the data the vendor handles.

Return vs. deletion clarity. Article 28(3)(g) requires the processor to delete or return all personal data — at the controller’s choice. Most DPAs are silent on which option applies or say “delete or return as directed.” Without a clear selection in the contract, termination creates ambiguity about whether your data was returned, deleted, or retained by a vendor for some internal purpose.

So What? The DPA Audit Checklist

Run this inventory against your three highest-risk vendor relationships:

1. Does the DPA contain all eight Article 28(3) provisions, or does it use generic language that doesn’t satisfy any of them specifically?
2. Does the sub-processor provision require advance notice and an opportunity to object before sub-processor changes?
3. Does breach notification language specify a concrete SLA (24 or 48 hours) rather than “without undue delay”?
4. Is there a deletion certification obligation at contract termination?
5. Does the DPA address AI/model training and automated processing restrictions?
6. Are audit rights exercisable in practice, with an independent auditor option?
7. For EU personal data: is there a DPF certification on file or SCCs incorporated in the contract?
8. Has this contract been reviewed since CPRA (January 2023) and Texas TDPSA (July 2024) took effect?

If you’re finding gaps in multiple areas, the issue is probably that your template DPA was drafted to a pre-2023 standard and hasn’t been updated for the current regulatory landscape. The 2024-2026 state law wave significantly expanded what processor contracts must contain — and most template DPAs haven’t kept up.

The Data Privacy Compliance Kit includes a GDPR/CCPA-aligned vendor contract provisions checklist, a 19-state privacy law applicability matrix, DSAR workflow templates, and data breach notification procedures — built for teams managing privacy compliance without a dedicated privacy officer.

Sources:

• GDPR Article 28 — Processor obligations
• ICO: What needs to be included in the controller-processor contract
• EU-US Data Privacy Framework
• California Privacy Rights Act (CPRA) — AB 375 as amended
• CPPA — California Consumer Privacy Act Regulations