By Ritika — a practical guide for in-house counsel, product teams, and vendors.
Data protection law is no longer a niche legal topic — it’s a business-critical risk area that shapes how modern technology agreements are negotiated and drafted. The EU’s General Data Protection Regulation (GDPR) sets baseline rules that ripple through cloud contracts, SaaS terms, vendor agreements, development and data-processing relationships, and international data flows. This blog explains the legal background you need, the contract clauses that matter most, practical drafting and negotiation tips, and provides concrete sample language you can adapt.
GDPR is the EU’s comprehensive data protection law that came into force in 2018 and governs processing of personal data of people in the EU/EEA. It imposes duties on controllers and processors (e.g., records, legal bases, rights, security, breach notification, and accountability).
International transfers are a core risk. Transfers of personal data outside the EU/EEA require an adequate safeguard (e.g., an EU adequacy decision, Standard Contractual Clauses (SCCs), binding corporate rules, or another valid mechanism).
Schrems II changed the landscape. The Court of Justice of the EU (CJEU) in Schrems II (2020) invalidated the EU–U.S. Privacy Shield and emphasized that transfers must ensure “essentially equivalent” protection in the recipient country — making simple reliance on a transfer mechanism insufficient without assessment and supplementary measures.
New transfer frameworks keep evolving. The EU and U.S. have since negotiated frameworks (the EU-U.S. Data Privacy Framework and subsequent judicial challenges and reviews). Organizations must monitor adequacy findings and court developments when relying on any transatlantic mechanism.
Technology contracts allocate responsibilities, limit (or increase) liability, and document the parties’ approach to compliance. For data protection specifically, contracts:
Define who is the controller vs processor (or joint controllers).
Implement the GDPR’s Article 28 requirements (processor obligations).
Create the contractual basis for lawful cross-border transfers (SCCs, additional safeguards).
Set expectations for security, breach response, audits, subcontracting, retention, deletion, and post-termination handling.
A weak or vague clause can lead to regulatory penalties, enforcement actions, and reputational damage — as regulators have demonstrated with large fines against major tech companies for transfer and other compliance failures.
Below are the must-have clauses for any tech agreement that touches personal data, with drafting tips.
Why: GDPR Article 28 requires a written contract between controllers and processors specifying subject matter, duration, nature and purpose, types of personal data, categories of data subjects, and the obligations of the processor.
Key elements:
Clear role definitions (controller/processor/joint controllers).
Processing details (purpose, categories of data, categories of data subjects).
Security measures (technical & organisational measures — TOMs).
Sub-processing rules and notification/consent for subprocessors.
Assistance for data subject rights and data protection impact assessments (DPIAs).
Return/deletion at termination; audit/cooperation rights.
Practical drafting tip: Include a standalone DPA annex with a table listing data types, retention, and TOMs so operational teams can implement controls.
Sample (short) clause:
DPA & Processing Instructions. Vendor shall process Personal Data only on Customer’s documented instructions, as set out in Annex A (Processing Instructions). Vendor shall implement and maintain appropriate technical and organisational measures to protect Personal Data and shall not engage Subprocessors without Customer’s prior written consent. On termination Vendor shall, at Customer’s option, return or irrevocably delete Customer Personal Data. (Adapt and expand Annex A per Article 28).
Why: Security obligations are a core GDPR requirement (Article 32). Contracts must be specific enough to be enforceable and auditable. EUR-Lex
Key elements:
Baseline security standards (ISO 27001, SOC2, encryption at rest/transport, MFA, vulnerability management).
Timeline and content for breach notifications (e.g., within 72 hours to controller where feasible).
Incident cooperation: forensic access, remediation, and notification of affected individuals if required.
Practical drafting tip: Avoid vague phrases like “reasonable security.” Tie obligations to measurable standards and add reporting SLAs.
Sample clause excerpt:
Security. Vendor shall maintain security measures no less protective than those described in Annex B (TOMs) and industry best practices (including encryption, access controls, vulnerability management). Vendor shall notify Customer of any Security Incident affecting Customer Personal Data within [48] hours of detection and provide regular updates until resolution.
Why: Transfers outside EU/EEA are high risk because the recipient country’s laws may not provide equivalent protection; reliance on SCCs or adequacy must be documented and assessed.
Key elements:
Specify the legal mechanism for transfers (SCCs, adequacy decision, BCRs, or other).
Contractually require the vendor to conduct transfer impact assessments and implement supplementary measures if necessary (encryption, pseudonymisation, contractual limitations on access).
Allocation of risk for regulatory enforcement and third-party access requests (e.g., government access).
Practical drafting tip: Add an obligation for the processor to notify the controller promptly if it receives any governmental request for data and to contest requests where permitted.
Sample clause excerpt:
Transfers & Compliance. All transfers of Customer Personal Data outside the EEA shall be governed by the EU Standard Contractual Clauses (SCCs) attached as Annex C unless an EU Commission adequacy decision applies. Vendor shall perform a Transfer Impact Assessment and implement supplementary technical, contractual or organisational measures where required.
Why: Processors often subcontract. GDPR demands written consent and flow-down obligations. European Commission
Key elements: vendor pre-approved list, notice and objection process, flow-down of DPA obligations, liability for subprocessors’ acts.
Practical drafting tip: Establish a standing consent plus a right to object to new subprocessors within a fixed period (e.g., 10 business days).
Why: GDPR’s accountability principle requires controllers to be able to demonstrate compliance. Contracts should enable audits or provide attestations (reports, certifications).
Key elements: right to audit (in-person or remote), regular compliance reporting, breach logs, audit remediation obligations.
Practical drafting tip: Limit invasive audits with advance notice, mutually agreed scope, and option for vendor-provided certifications in lieu of audits.
Why: Controllers must respond to data subject requests; processors must assist. Contracts should define operational steps, timelines and any cost allocation. EUR-Lex
Key elements: notification of requests, response SLAs, escalation for complex requests, deletion/portability processes.
Why: GDPR principles require minimisation and limited retention. Contracts must address end-of-term handling. EUR-Lex
Key elements: retention schedule, secure deletion certification, exceptions for backups and legal holds.
Why: These clauses allocate financial risk for breaches, regulatory fines (note: regulators primarily fine the controller, but processors can be liable too). Large fines have become reality — include insurance and caps carefully.
Practical drafting tip: Don’t let a vendor’s overall liability cap swallow liability for GDPR breaches — consider carve-outs for gross negligence, willful misconduct, or data protection breaches; require cyber insurance with specified minimum coverage.
The Schrems II judgment forced organizations to re-examine transfers and not rely blindly on transfer mechanisms. The European Commission updated SCCs in June 2021 to better reflect GDPR rules and provide modular clauses for different controller/processor relationships. But the SCCs alone do not eliminate the need for transfer impact assessments and technical/organisational supplementary measures. Regulators and the European Data Protection Board (EDPB) expect exporters to evaluate legal environments and use supplementary measures where necessary.
Recent developments in EU–U.S. arrangements (such as the EU-U.S. Data Privacy Framework) change the practical options available, but they remain subject to judicial review and periodic adequacy reviews — so contracts should be drafted to adapt (e.g., fallback to SCCs + supplementary measures if an adequacy decision is invalidated).
Operationalize the DPA. Push for a DPA annex that lists data elements, retention, TOMs and subprocessors. Make this the go-to operational reference.
Make transfers explicit. Require advance notice and mitigation obligations if the vendor needs to transfer data to additional jurisdictions.
Tighten breach SLAs. Specify detection, notification, and remediation timelines; insist on periodic tabletop exercises for critical suppliers.
Limit liability caps for data breaches. Either carve data protection breaches out of caps or set a higher cap and require cyber insurance.
Use certifications and audits smartly. Accept SOC2/ISO27001 reports where appropriate, but reserve audit rights if there’s a suspected breach or systemic issue.
Parties, effective date, roles (controller/processor)
Processing details: purposes, categories of data subjects, categories of personal data
Security measures (refer to Annex B: TOMs)
Subprocessors — list and approval process
Data transfers & mechanism (SCCs/adequacy/fallback) and Transfer Impact Assessment obligations
Breach notification & incident response process and SLAs
Data subject rights assistance procedures and timelines
Retention, deletion and return procedures
Audit, reports & certifications
Liability, indemnity & insurance
Termination and post-termination cooperation
1. Processor obligations (Article 28 style)
Vendor shall process Personal Data only on Customer’s documented instructions, including with respect to transfers, and shall not process Personal Data for any other purpose. Vendor shall ensure persons authorized to process Personal Data are bound by confidentiality.
2. Subprocessor consent
Customer provides general consent to the use of Vendor’s subprocessors identified in Annex D. Vendor shall notify Customer of any new Subprocessor at least 30 days in advance; Customer may object within 10 days on reasonable grounds related to data protection.
3. Transfer impact assessment & supplementary measures
Where Personal Data is to be transferred to a country without an EU adequacy decision, Vendor shall perform and provide to Customer a Transfer Impact Assessment and implement appropriate supplementary technical, contractual or organisational measures (including encryption/pseudonymisation) to achieve level of protection essentially equivalent to EU law.
4. Breach notification
Vendor shall notify Customer of any Security Incident affecting Customer Personal Data without undue delay and, in any event, no later than 48 hours after Vendor becomes aware. Notification shall include nature, scope, remediation steps, and contact for further information.
“Reasonable” security language without standards. Ask for measurable standards (ISO 27001, SOC2).
Excessively broad audit restrictions. Vendors often limit audits; accept attestations or narrow the audit scope with trusted third-party reports.
Overbroad subcontracting rights. Require notice + objection and a flow-down of obligations.
Complete liability caps for data breaches. Ensure sensible carve-outs or higher limits.
A great contract won’t protect you if your vendors or internal teams don’t operationalise it. Make sure to:
Map where personal data flows across systems and third parties.
Maintain an up-to-date inventory of subprocessors and jurisdictions.
Run DPIAs for high-risk processing and document mitigation measures.
Include privacy & security obligations in vendor onboarding and renewal processes.
GDPR enforcement is real: supervisory authorities have issued large fines in recent years for transfer and other failures. Examples include multihundred-million euro fines against major tech companies — demonstrating the financial and reputational stakes when transfers and other GDPR obligations are mishandled. That enforcement backdrop should inform negotiation posture and risk allocation.
Is there a clear DPA that satisfies Article 28?
Are roles (controller vs processor) properly allocated?
Are security measures defined and measurable (not “reasonable”)?
Are international transfers explicitly covered (SCCs, adequacy, fallback)?
Are subprocessors listed and subject to notice/objection?
Are breach notification timelines and remediation obligations acceptable?
Is liability for data breaches and required insurance adequate?
Can the vendor demonstrate compliance (certifications/reports)?
GDPR forced data protection to the center of commercial contracting. The legal frameworks around cross-border transfers (SCCs, adequacy decisions, and court challenges such as Schrems II) mean that legal teams must couple precise contract drafting with operational checks and regular re-evaluation of transfer mechanisms. Don’t treat DPAs as boilerplate — turn them into living documents attached to operational annexes (TOMs, subprocessors, retention schedules), insist on measurable security standards, and negotiate risk allocation that reflects real regulatory exposure.