Council call recap · Chatham House Rule
Your vendor’s breach is your breach
Writing contracts that actually protect supplier-handled data. A virtual council call on contract constructs for supplier data protection.
Oct 14, 2026 · 9 min read
Every security leader on the call had lived some version of the same story. A supplier gets onboarded, the contract gets signed with a line about “industry standard security,” and the data starts flowing. Then something goes wrong, and the team pulls the contract out of the drawer only to find it promises almost nothing they can enforce.
The council met to close that gap. The conversation followed the life of a supplier relationship from signature to termination, and at every stage the conclusion was the same: if a protection is not written into the contract in specific terms, it does not exist when you need it.
Chapter
01
The signature
Make the security program contractual.
The story starts at the negotiating table, and members agreed this is where most organizations give away their leverage. “Industry standard security” sounds reassuring, but no one can define it, which means no one can enforce it.
The stronger approach is to require the supplier to maintain a documented security program and to name the specific controls you expect inside it. Any downgrade to those controls should require your written consent, so a supplier cannot quietly retire a safeguard mid-contract. Independent assessments belong in the contract as an obligation, not as a courtesy the supplier extends when convenient.
When legal says no
Members were candid that these terms are hard to win. Large service providers resist custom language because they negotiate from scale. Smaller suppliers resist because they lack the maturity to commit. Either way, security does not always get the clause it wants.
The council’s answer was not to fight every battle, but to make sure the outcome is recorded. If legal or procurement will not accept the proposed language, document the security recommendation and the residual risk. The business then owns that decision on the record, and security is not left holding a risk it argued against.
Chapter
02
Day one of operations
Spell out the technical baseline.
Once the contract is signed, the supplier starts handling your data, and the question shifts from “do they have a program” to “what exactly are they doing.” Members argued the contract should answer that in plain technical terms.
Encryption and keys
The baseline should cover data in transit, at rest, and in backups. Backups were called out because they are easy to overlook and often live outside the controls applied to production. Key management practices belong in the same clause, since encryption is only as strong as the handling of its keys.
Members also recommended starting to flag quantum-resistant encryption now as a forward-looking requirement. Contracts signed today will outlive current cryptographic assumptions, and putting the expectation in writing early sets up the conversation for renewal.
Access and hygiene
The contract should specify:
- Multi-factor authentication
- Least-privilege access
- Timely deprovisioning of accounts
- Logging
- Defined timelines for vulnerability remediation
- Independent penetration testing
None of these are exotic. The point is that each one becomes enforceable only when it is named.
The through-line
If a protection is not written into the contract in specific terms, it does not exist when you need it.
Chapter
03
The data changes hands
Define the data contract, including AI.
As the relationship matures, the supplier is no longer just storing your data. It is processing it, analyzing it, and increasingly running it through AI tools. Members agreed this is where many existing contracts have quietly fallen behind.
Ownership and permitted use
The contract should state who owns the data and how it may be used. It should also answer, explicitly, whether the supplier may use your data to train AI models. Silence on that question is now a risk in its own right. Privacy obligations and disposal requirements at termination round out the clause.
ISO 42001 as evidence
Members compared notes on ISO 42001, the AI management system standard. The consensus was that it is gaining traction as an AI governance signal in vendor assessments. But the certificate alone proves little. Its value depends on how its controls are mapped to the actual terms in your contract, so the certification supports specific obligations rather than standing in for them.
Chapter
04
Something goes wrong
Build incident response and audit rights that reach downstream.
Every supplier relationship eventually gets tested. When it does, the contract is the only thing that determines how fast you hear about it, how much you learn, and whether you can confirm it was fixed.
Breach provisions
Members recommended defining four things in advance:
- Notification timelines
- Expectations for cooperation during the investigation
- Post-incident reporting
- Evidence that remediation was actually completed
The last point matters most. A supplier telling you an issue is resolved is not the same as showing you.
Fourth-party reach
The sharpest point of the discussion was that much of the real exposure does not sit with your supplier at all. It sits with your supplier’s suppliers: the cloud platforms, subprocessors, and downstream providers you never signed with. Members urged extending audit rights to cover those third parties, so your visibility does not stop at the first contract in the chain.
Chapter
05
The relationship ends
Plan for proof of data destruction.
The final chapter is the one most contracts treat as an afterthought. The relationship ends, the supplier agrees to destroy your data, and you ask for proof. That is where members hit a wall.
The gap
Cloud providers often will not issue destruction certificates to the service providers built on top of them. Your supplier may be fully willing to certify destruction, but it cannot produce evidence from a platform that will not give it one. The result is a hole in the evidence chain at exactly the moment you need it closed.
The options
Executive self-attestation from the supplier is a practical fallback, and members saw it used often. But there is a catch: if your contract requires external attestation, self-attestation will not satisfy it, and you end up with a supplier in technical breach over something it could never deliver.
The fix is to write the contract around reality. Align the destruction clause with the evidence the supplier can realistically produce, and decide up front what level of proof you will accept.
Chapter 06
The takeaway
Your contract is your security program on paper.
Follow a supplier relationship from start to finish and the pattern is clear. At signature, at onboarding, as data use expands, when an incident hits, and when the relationship ends, the protections that hold are the ones written down in specific, measurable terms.
No contract will be perfect, and members were realistic about how much leverage security has in negotiation. But the goal is not a perfect contract. It is a contract where every protection that matters is either secured in writing or recorded as a risk the business chose to accept.