Control Definition
Relevant information security requirements must be established and agreed with each supplier, based on the kind of relationship and what the supplier accesses, processes, stores, or provides. In practice this means the security obligations identified during supplier assessment are written into the binding agreement between the parties — not left in questionnaires and emails.
Control Objective
To keep an agreed level of information security in supplier relationships by making each party's security obligations explicit, documented, and contractually enforceable.
What This Really Means
A questionnaire answer is a courtesy; a contract clause is an obligation. Everything your due diligence under A.5.19 established about a supplier — their certifications, their encryption story, their promise to tell you about breaches — describes that supplier on the day you checked. A.5.20 is the control that converts the parts you actually depend on into terms the supplier is legally bound to keep, for as long as the relationship runs. If a security requirement matters enough to ask about before signing, it matters enough to survive into the signature.
The working question is which clauses, for which suppliers. The recurring set: how your information may be used, classified, and handled; confidentiality and personnel obligations on the supplier's side; access control and the supplier's duty to vet and manage its own staff; incident and breach notification with an explicit window and contact path, not "promptly"; the right to audit, or the obligation to maintain and share independent assurance such as an ISO 27001 certificate or SOC 2 report; rules on subcontracting and sub-processors, including approval or notification and the duty to flow your requirements down; data location constraints where law or customers demand them; return or verified destruction of your information at exit; liability for security failures; and compliance with the laws that bind you. Few suppliers need all of it — the clause depth should track the risk tier A.5.19 assigned.
This is a two-craft control: security knows what to require, legal knows how to make it enforceable, and the artifact that joins them is a standard security schedule or addendum — a maintained clause library with a tiered template, so account teams are not improvising terms deal by deal. The lifecycle matters as much as the first signature: clauses get refreshed at renewal, uplifted in legacy contracts on a prioritized schedule, and re-papered when the service, the law, or the supplier's ownership changes. A contract negotiated before your current data protection obligations existed is not protecting you from them.
For auditors, the heart of A.5.20 is the distance between your template and your signed reality. They will pick critical suppliers from the register and read the actual executed agreements, looking for the clauses your own tiering says are mandatory — and probing the exceptions: where a supplier refused terms, was the gap documented and the risk formally accepted, or did the deal simply close? A beautiful addendum template with unsampled, un-uplifted contracts behind it is the classic failure here.
Why It Matters
When a supplier is breached, the contract decides whether you hear about it from them in hours or from the press in weeks. Your own regulatory clocks — breach notification duties measured in hours and days — start running regardless of whose environment failed, and the only mechanism that obligates a supplier to feed you the facts inside your window is a notification clause with a number in it. The same logic applies at exit: without a return-and-destruction term, the supplier holding your data after termination owes you nothing, and your leverage evaporated at signature.
Leverage is the deeper point. Before the contract is signed you have all of it; afterward you have whatever the document says. Data protection regimes sharpen this further by making processor contracts a legal requirement, not a best practice — a fiduciary or controller that hands personal data to a processor without a compliant contract has a finding before anything has even gone wrong.
Where security requirements never make it into agreements, organizations face:
- •Silent supplier breaches – no contractual notification duty means you learn of an incident after your own regulatory window has already burned down
- •Unenforceable expectations – the promises made in a pre-sales questionnaire cannot be enforced when the supplier quietly drops the practice
- •Data hostage situations at exit – without return-and-destruction terms, ended relationships leave your data sitting in a former supplier's systems indefinitely
- •Sub-processors you never approved – absent subcontracting clauses, your data flows to fourth parties in jurisdictions you never assessed
- •Direct compliance findings – missing or inadequate processor terms is a nonconformity in itself under data protection law and a commonly sampled gap in certification audits
Regional Compliance Context
Under India's DPDP Act 2023, a data fiduciary may engage a data processor only under a valid contract, and the fiduciary remains answerable for the processing — so for any supplier touching personal data, the agreement is not just an ISO control but the legal basis of the relationship, and notification clauses should be tuned to clocks like CERT-In's 6-hour incident window and the 72-hour detailed breach report under the DPDP Rules. RBI's outsourcing directions go further for banks and NBFCs, prescribing contract content for material outsourcing: audit and inspection access for the regulated entity and its regulator, data location and confidentiality terms, and exit provisions with transition assistance.
The Saudi PDPL and UAE federal PDPL carry the same controller-processor contract logic — processors bound by written terms offering adequate safeguards — so a single tiered clause library can serve India and Gulf operations with jurisdiction-specific schedules rather than separate programs.
Implementation Guidance
Build a Tiered Clause Library with Legal
Have security define the requirement set and legal convert it into enforceable language, maintained as a standard security schedule or addendum with versions per supplier tier. Store it where deal teams actually work — the contract lifecycle management tool or procurement workspace — and assign joint ownership so neither function can drift it unilaterally.
Map Clause Sets to Supplier Tiers
Decide which clauses are mandatory at each risk tier from your A.5.19 model: critical suppliers get the full schedule including audit rights and exit assistance; mid-tier suppliers get the core set; low-tier suppliers get confidentiality and notification basics. Write the mapping into the supplier security policy so the depth of contractual protection is a rule, not a negotiation-by-negotiation mood.
Fix the Non-Negotiable Core
Name the clauses no deal may close without: incident and breach notification with an explicit window (24–72 hours from confirmation is the common range) and a named contact path, data handling aligned to your classification scheme, return or verified destruction of data at exit, sub-processor approval or notification with flow-down of requirements, and maintenance of agreed certifications. Require documented security sign-off for any deviation from this core.
Wire Contracting into the Onboarding Gate
Connect the A.5.19 assessment output to the contract process so the requirements identified for a supplier arrive as a clause checklist, and no credentials, integrations, or data flows are enabled before the agreement including its security terms is executed. Procurement holding the purchase order until the addendum is signed converts policy into practice.
Handle Suppliers Who Will Not Negotiate
For hyperscalers and large SaaS vendors on standard terms, review their published DPA, security terms, and assurance reports against your clause set and record the deltas. Each gap gets a documented decision: accept the risk formally, compensate on your side (tighter configuration, less data shared, shorter retention), or choose a different supplier. The review record is what makes standard-terms purchases conforming.
Refresh Clauses at Renewal and on Change
Track renewal dates in the supplier register and treat each renewal as a clause review: compare the live contract against the current library and uplift gaps. Run a prioritized remediation plan for legacy contracts — critical tier first, via addenda or side letters where renewal is distant — and trigger off-cycle re-papering when the service scope, the law, or the supplier's ownership changes.
Hand the Verification Schedule to Supplier Reviews
For every clause that promises ongoing evidence — annual certificate maintenance, SLA security metrics, notification tests, sub-processor change notices — record what is owed and when, and feed that schedule into the A.5.22 monitoring rhythm. A clause nobody ever verifies is decoration; the contract layer and the review layer have to know about each other.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.20:
Documentation
- Security clause library or standard security addendum, versioned, with legal and security approval
- Policy or procedure mapping supplier risk tiers to required clause sets
- Executed agreements for sampled critical suppliers showing the tier-mandated security clauses
- Gap analyses and risk acceptance records for suppliers on non-negotiable standard terms
- Renewal or uplift tracker showing legacy contracts being brought onto current security terms
Interviews
- Legal counsel or contracts manager on how security terms enter agreements and who is authorized to concede them
- CISO or supplier risk owner on how the clause sets were derived from tiers and what is non-negotiable
- Procurement lead on what happens when a supplier rejects the security schedule — escalation, exception, or walk-away
Observations
- Direct reading of a signed critical-supplier contract, locating the breach notification window, audit or assurance rights, and exit terms
- Trace of one recent onboarding from assessment output through clause checklist to the executed addendum
- Inspection of the exception register for standard-terms suppliers, checking each gap has a dated, signed risk decision
Practitioner Insights
A pattern I see constantly: the organization shows me a polished security addendum, and then every contract I sample predates it. Templates are intent; executed agreements are evidence. Before an audit, pull your ten highest-risk suppliers and read each signed contract for three things — the notification window, the assurance obligation, and the exit terms. The gaps you find are your uplift plan, and walking into the audit with that plan already moving is the difference between an observation and a nonconformity.
Smaller organizations buy almost everything from vendors far larger than themselves, and the common mistake is pretending otherwise — filing an unsigned addendum the vendor will never execute and calling it done. The conforming move is honest review: read the vendor's standard DPA and security terms, write down where they fall short of your clause set, and record the acceptance or the compensating step. Three dated paragraphs per supplier beats a folder of fictional paperwork, and it is exactly what auditors ask SMBs to produce.
Common Challenges & Solutions
Challenge
Large vendors refuse custom security terms, and the organization has no leverage to force them.
Solution
Stop negotiating and start reviewing: assess their published DPA, security exhibit, and audit reports against your clause set, document the deltas, and make a formal risk decision on each. Compensate on your own side of the line — configuration hardening, minimizing the data shared, shorter retention. Reserve real negotiation effort for suppliers where you genuinely have it.
Challenge
Years-old contracts with critical suppliers contain no meaningful security clauses, and renewals are staggered far into the future.
Solution
Run a prioritized uplift program rather than waiting for renewals: critical tier first, using a short security addendum or side letter that can be executed without reopening commercial terms. Track it like an audit action list with owners and dates. For relationships where even an addendum stalls, record the exposure in the risk register so management owns the gap knowingly.
Challenge
Sales pressure and deal velocity let agreements close with security clauses quietly traded away.
Solution
Classify the clause library into negotiable and non-negotiable terms, and require documented security sign-off for any deviation from the core. Make the mechanism structural: the CLM or procurement workflow blocks execution until the security checklist is complete or an exception is approved. Negotiation flexibility survives; silent concessions do not.
Challenge
Breach notification clauses say "promptly" or "without undue delay", which means nothing at 2 a.m. on the day it matters.
Solution
Replace adjectives with numbers anchored to your own obligations: if regulators give you hours, the supplier window must be shorter still — 24 to 48 hours from confirmation is a common ask, with an explicit definition of what starts the clock and a named contact channel. Test the path once a year by asking the supplier to walk through how they would notify you.
Challenge
Clauses exist on paper but nothing verifies the supplier honors them after signature.
Solution
Extract every clause that promises recurring evidence — certificate maintenance, assurance report delivery, sub-processor notices, SLA security metrics — into a verification schedule, and hand it to the A.5.22 review process with named owners. Exercise audit rights, or their assurance-report substitute, at least for the top tier or after a supplier incident. Contracts get teeth from the review rhythm, not from the signature.
