Key Takeaways:
- Vague privacy language invites risk, whereas specificity creates accountability.
- Controllers must flip the script from accepting boilerplate terms to demanding precision from processors.
- When your contract language reflects enforceable duties rather than vague intentions, you shift the balance from risk acceptance to risk control.
Between 2020 and 2023, Morgan Stanley paid over $100M in penalties for a vendor management failure that started with a simple hardware disposal project.
This episode was attributed to a data processing arrangement that looked fine on paper but collapsed under real-world pressure.
In 2016, Morgan Stanley decommissioned several data centers as part of a hardware refresh project. To handle logistics, the bank hired a moving and storage company, not a specialist in data destruction, to remove and dispose of thousands of servers and hard drives containing sensitive customer data. The contractor, in turn, engaged a subcontractor to wipe or destroy the equipment, but later switched to another unvetted vendor without Morgan Stanley’s knowledge or approval.
What followed was a cascade of failures. Devices that should have been securely wiped were instead sold at public auctions, with unencrypted customer data still accessible on some drives. Dozens of servers went missing entirely.
Much Ado About Data Processing Agreements
Data Processing Agreements (DPAs), now required under multiple data protection laws, have become a mainstay in the world of contracts. Like many legal instruments, they require a balance of ingenuity, engineering, and specificity.
Yet, too often, DPAs contain generic clauses that appear acceptable at first glance but unravel under scrutiny, especially in breach or enforcement situations.
A common example, particularly in controller–processor relationships, is the clause:
“The Processor will implement appropriate security measures.”
If a breach occurs under such language, the processor can simply argue, “We implemented what we deemed appropriate.” The controller is then left holding regulatory fines, customer lawsuits, and remediation costs.
This is precisely why inadequate DPAs are liabilities waiting to happen.
Here are some of the most common DPA clauses that transfer risk to the controller, and how to modify them to transfer the risk right back to the processor.
1. The Appropriate Security Measures Clause
When it comes to security, most DPAs say something like:
“The Processor will implement appropriate technical and organizational measures.”
The problem is that “appropriate” is subjective. Without a defined baseline (e.g., ISO 27001, SOC 2 Type II, or NIST 800-53), there’s no measurable yardstick for adequacy.
You need to replace ambiguity with specificity. Instead of accepting vague promises of “appropriate measures,” require the processor to meet defined and verifiable standards. This means mandating compliance with recognized security frameworks such as SOC 2 Type II or ISO 27001 (or another equivalent standard), insisting on annual certification renewals, and requiring documented security policies that you have the right to review or audit.
You should also establish clear incident response timelines, such as detection within 24 hours and notification within 48 hours, to ensure timely and accountable handling of potential breaches.
Some commercial agreements will even include a separate set of data security terms or a Data Security Addendum.
2. The Limitation of Liability Clause
A typical limitation of liability clause reads:
“Processor’s liability under this DPA is subject to the limitations in the Master Services Agreement.”
The problem is that your MSA likely caps liability at 12 months of fees. Whereas a data breach involving 6,500 data subjects could generate $1M+ in GDPR fines alone (at $160 – $165 per affected individual under typical enforcement), plus remediation and litigation costs.
While this clause isn’t inherently problematic, the risk arises when the DPA, read holistically, doesn’t protect you against liability carve-outs, events like data breaches, gross negligence, or willful misconduct, whose financial impact far exceeds the cap.
What works better is a tiered liability framework that distinguishes between routine service failures and high-impact data protection breaches. Include carve-outs for confidentiality violations, data breaches, gross negligence, willful misconduct, and fraud, making these uncapped or subject to a higher “super-cap” (for example, 2x to 3x times annual fees).
It’s also prudent to require minimum levels of cyber and professional liability insurance to ensure the processor can meet potential liabilities. Finally, preserve direct liability to data subjects, which under Article 82 of the GDPR cannot be waived, ensuring affected individuals retain enforceable rights if the processor’s actions cause harm.
3. The Audit Rights Clause
Many DPAs include this token language:
“Controller may audit Processor’s compliance upon reasonable notice.”
The problem is that “reasonable” is undefined. There’s often no frequency specified, no guaranteed access, and no consequence for refusal.
Negotiation strategies for this clause may differ based on the vendor’s importance and commercial leverage, but the outcome should always be a clause that works in practice i.e., one that defines clear audit rights, notice periods, and escalation triggers for critical vendors. In negotiating, specify a maximum 30-day notice requirement. Likewise, negotiate immediate access in cases of suspected breaches for critical vendors.
Also, require the processor to provide independent assurance reports (such as SOC 2 or ISO certificates) on a regular basis. The goal is not to burden the vendor but to create a verifiable chain of accountability.
4. Sub-Processor Notification
The typical clause reads:
“Processor may engage sub-processors with prior notice to Controller.”
You should know that notice isn’t approval. In Morgan Stanley’s case, their vendor’s sub-processor (who actually handled data destruction) had no qualifications and no oversight. The main vendor just “notified” Morgan Stanley without seeking approval.
This is another clause where revision should be risk-based. For high-impact or critical vendors, require prior written approval for each sub-processor and attach a complete list of existing sub-processors as a DPA exhibit. Reserve the right to audit any sub-processor handling sensitive data directly. Ensure the same security and compliance obligations flow down the chain and make the main processor fully liable for any sub-processor failures.
Most DPAs are drafted to minimize processor obligations and maximize controller responsibility. Your job is to flip that script, to make the processor truly accountable for the processing they control.
That starts with tightening the language: replacing “appropriate” with specific, “reasonable” with measurable, and “notice” with approval. When your contract language reflects enforceable duties rather than vague intentions, you shift the balance from risk acceptance to risk control.
The post How to Improve Your Data Privacy Addendum (Pro Controller) appeared first on Contract Nerds.