Data Processing Agreements: Controllers, Processors, and SCCs

Modern companies rarely process personal data alone. Customer data sits in CRM systems, employee data in payroll platforms, marketing data in email tools, support data in help desk software, and product data in analytics platforms. Each vendor can create legal exposure. The data processing agreement is the document that turns that exposure into controlled responsibility.

This guide is part of the Kurums Law department and its Data Privacy and KVKK pillar, and it connects directly to the broader business agreements framework. It explains controller and processor roles, DPA clauses, Standard Contractual Clauses, sub-processors, audits, security, and negotiation points.

What is a data processing agreement?

A data processing agreement is a legally required or commercially necessary contract that governs processing of personal data by one party on behalf of another. It translates privacy law into operational duties. The agreement tells the vendor what it may do, what it may not do, how it must protect data, when it must notify incidents, and what happens when the services end.

Under GDPR, controller-processor relationships require specific contractual terms. Under California privacy law, service provider and contractor terms affect whether certain disclosures are treated as sale or sharing. Under KVKK and similar regimes, vendor arrangements must support security, confidentiality, transfer, and controller accountability. The labels vary, but the business purpose is the same: prevent vendors from becoming uncontrolled data risk.

Controller, processor, joint controller, service provider: what is the difference?

The most important DPA question is role classification. If the roles are wrong, the contract will assign the wrong obligations. A controller decides the purposes and means of processing. A processor processes personal data on the controller’s instructions. Joint controllers jointly determine purposes and means. Under California law, service providers and contractors are restricted recipients that process personal information for specified business purposes.

What clauses must a DPA include?

A strong DPA contains both mandatory legal terms and practical operational terms. The legal terms satisfy statutory requirements. The operational terms make the contract useful when a vendor changes infrastructure, adds a sub-processor, receives a request, suffers a breach, or terminates services.

1. Processing details – subject matter, duration, nature, purpose, data categories, and data subject categories.
2. Instructions – processor may process only on documented instructions.
3. Confidentiality – staff and contractors with access must be bound by confidentiality.
4. Security measures – technical and organizational controls, often in an annex.
5. Sub-processors – approval, notice, objection, and flow-down obligations.
6. Assistance – support for rights requests, DPIAs, audits, and regulator inquiries.
7. Breach notification – timing, content, cooperation, and evidence preservation.
8. Deletion or return – data handling at end of services.
9. Audit rights – reports, questionnaires, certifications, or on-site audits.
10. Transfers – SCCs, transfer impact assessment support, and location controls.

How do Standard Contractual Clauses fit into DPAs?

Standard Contractual Clauses are transfer terms used under GDPR when personal data is transferred outside the EEA to a country without an adequacy decision. They are often attached to or incorporated into a DPA, but they do not replace the commercial DPA. The DPA controls processing; SCCs address transfer safeguards.

SCCs are module-based. Different modules apply depending on whether the parties are controller-controller, controller-processor, processor-processor, or processor-controller. Businesses must identify the correct module, complete annexes, describe transfer details, list technical and organizational measures, and assess local law risks through a transfer impact assessment where required.

How should businesses manage sub-processors?

Sub-processors are downstream vendors used by the processor to perform services involving personal data. They matter because data risk does not stop with the first vendor. A CRM provider may use cloud hosting, support tools, analytics, email infrastructure, and security vendors. Each may touch customer data.

A practical DPA should require the processor to list sub-processors, give notice before changes, allow objection in defined circumstances, impose equivalent obligations on sub-processors, and remain liable for sub-processor performance. High-risk vendors may require approval rather than notice-only mechanisms.

What should breach notification clauses say?

Breach clauses should require prompt notice, meaningful detail, cooperation, evidence preservation, containment support, and updates as facts develop. Many vendors prefer vague wording such as “without undue delay.” Customers often need a tighter operational standard because GDPR, KVKK, customer contracts, and insurance notices may impose short deadlines.

A balanced clause requires notification after the vendor becomes aware of a personal data breach, includes known facts, affected systems, data categories, likely consequences, mitigation steps, contact person, and follow-up updates. It should also prohibit public statements without coordination unless legally required.

DPA negotiation checklist

• Confirm whether each party is controller, processor, joint controller, service provider, or contractor.
• Describe processing accurately in the annex.
• Align security measures with actual technical controls.
• Require sub-processor transparency and flow-down terms.
• Check transfer locations and SCC modules.
• Set breach notice timing that supports legal deadlines.
• Define deletion, return, backup retention, and certification.
• Align liability caps with privacy risk, not only service fees.

How should DPA liability be handled?

Privacy liability should be negotiated based on actual data risk, not simply copied from the commercial services agreement. A low monthly subscription fee does not mean the privacy exposure is low. A small vendor may hold employee identity documents, customer payment metadata, health information, location data, children’s data, or authentication logs. If that data is exposed, the customer’s cost may include regulator response, customer notification, legal advice, forensic work, credit monitoring, contractual claims, operational disruption, and reputational harm.

Common approaches include a separate higher cap for privacy breaches, uncapped liability for intentional misuse or confidentiality breaches, super-caps for security incidents, indemnity for third-party claims, and exclusions for indirect damages that still preserve direct remediation costs. Vendors will resist unlimited exposure, and customers should be realistic. The negotiation should focus on proportional risk allocation: who controlled the failure, who could prevent it, and what level of insurance or security maturity supports the risk.

What evidence should be collected before signing a DPA?

A DPA should not be signed in isolation from vendor due diligence. The customer should collect enough evidence to confirm that the contractual promises are credible. For low-risk vendors, a security questionnaire and privacy documentation may be enough. For high-risk vendors, request security certifications, penetration test summaries, incident history, sub-processor lists, data location details, business continuity documents, and sample deletion procedures.

The goal is not to turn every procurement into a six-month audit. It is to match review depth to risk. A newsletter tool processing public business emails may need a lighter review than a payroll platform holding salary, bank, ID, and health-related absence data. The DPA should reflect this risk tiering through different audit rights, breach notice requirements, security annexes, and approval thresholds for sub-processors.

When should a DPA be re-reviewed?

A DPA should be reviewed whenever the data, service, law, transfer route, or vendor architecture materially changes. Common triggers include new product modules, new sub-processors, new hosting regions, new AI features, new analytics use, a merger, a security incident, a regulatory update, or a customer requirement that imposes stricter downstream terms.

Do not treat a signed DPA as permanent. Vendor data use changes over time, especially with SaaS products. Add annual review for high-risk vendors and require notice before material privacy or security changes. This keeps the contract aligned with the actual service.

Frequently Asked Questions