ISO 27001 Annex A 5.20: supplier agreements that hold up

The due-diligence questionnaire asks for the security schedule in your critical supplier's contract. You find a purchase order and an NDA. This guide covers ISO 27001 Annex A 5.20, the control that turns supplier security from a promise into a signed, risk-matched agreement, for security and compliance leads at regulated service providers and B2B SaaS firms.

You will get the control in plain English, the clauses that carry weight, a route through the AWS and Microsoft standard-terms problem, the register auditors sample from, and the questions asked in the room. It is not a mountain. Most of it is a template set, a register and one gated onboarding step.

What does ISO 27001:2022 Annex A 5.20 addressing information security within supplier agreements require?

ISO 27001 Annex A 5.20 requires the security expectations you place on each supplier to be written into a binding agreement, matched to the relationship's type and risk. Both parties' obligations must be explicit, and the agreements need recording in a register and revisiting so terms stay fit for what the supplier now does.

A supplier's promise to look after your data is worth what the contract says it is worth. A payroll processor and a stationery vendor do not warrant the same terms, so the control asks you to match each agreement to the relationship.

In practice, the control asks for three things:

• Binding terms. Security expectations sit in a signed agreement, not in an email thread or a verbal assurance.
• Explicit obligations on both sides. The agreement states what the supplier must do and what you must supply, such as access arrangements and data handling instructions.
• A living record. Agreements are listed in a register and revisited, so terms follow what the supplier now does for you.

Annex A 5.20 is a preventive control that covers confidentiality, integrity and availability. Notification duties, handling rules and exit obligations are agreed before data flows, so failures are limited in advance rather than discovered in the wreckage.

For a 50-person firm, that means a small set of templates and a register, not a legal programme.

How does ISO 27001 Annex A 5.20 connect to A.5.19, A.5.21 and A.5.22?

In the supplier-control chain, A.5.19 sets the policy and tiering, A.5.20 converts that policy into enforceable contract terms, A.5.21 extends the reach down the ICT supply chain, and A.5.22 checks supplier performance against what was signed. Monitoring can only measure what the contract puts in writing.

Auditors read the policy under A.5.19 and the contracts under A.5.20. Your tiering decides which schedule a supplier receives, so vague tiers produce contracts that are either over-papered or too thin to matter.

Each control leaves a different trace in your evidence:

• A.5.19: the supplier policy and the tier definitions.
• A.5.20: signed agreements, security schedules and data processing agreements.
• A.5.21: flow-down and sub-processor terms for ICT services.
• A.5.22: review records measured against the signed terms.

The sub-processor and flow-down clauses in your schedule are where A.5.20 hands over to the ICT supply chain. They bind the supplier's own suppliers to equivalent terms. A review meeting that checks a supplier against a clause nobody agreed has nothing to enforce, so work in order: tier, contract, monitoring.

What belongs in a supplier security schedule?

A supplier security schedule covers what information the supplier receives and how it is handled, applicable legal duties, who may access your assets, a hard incident-notification window, sub-processing rules, usable assurance, continuity expectations, and exit terms. Build one per supplier tier and attach it at onboarding, so legal input happens once.

For anything touching your data, these are the clauses that auditors and incidents test:

• Information and handling. What the supplier receives, how it is classified and how it must be handled.
• Legal duties. The legal and data-protection obligations that apply, and how each will be met.
• Access. Who at the supplier may reach your assets, and how that access is revoked.
• Incident notification. A fixed window of 24–72 hours, plus cooperation during response.
• Sub-processing. Equivalent obligations flow down, and you are told before a sub-processor changes.
• Assurance. Certificates, independent reports or audit rights you can rely on.
• Continuity. Expectations for backup, continuity and change notification.
• Exit. Return, certified destruction and handover support when the relationship ends.

Re-express these in your own words rather than copying anyone's list, but address each one for critical suppliers.

The notification window is the clause that bites first. The ICO personal data breach reporting guidance says a notifiable breach must reach the ICO without undue delay and within 72 hours. A supplier clause that repeats "without undue delay" gives you nothing to enforce while that deadline runs, so name the hours and require logs and cooperation.

Flow-down deserves the same precision. The NCSC supply chain security principles advise putting your minimum security requirements in supplier contracts and requiring suppliers to pass them to their own sub-contractors. Add a notice right on top, so you hear before a sub-processor changes, not after.

Four pitfalls recur, and each clause above inverts one:

• NDA-only protection. Confidentiality is the only thing covered: no notification duty, no availability or integrity obligations, no audit rights and no exit terms.
• Warm words. "Industry-standard security practices" is a phrase no lawyer could enforce and no auditor will credit.
• Silent sub-processor changes. Without terms, the vendor's own supply chain shifts beneath you.
• Missing endings. No return, destruction or handover duty, discovered at the moment of a messy exit.

An NDA is a secrecy agreement, not a supplier security control.

What do you do when AWS or Microsoft won't negotiate?

You do not redline hyperscalers. Review their standard terms and security addenda, collect their independent assurance, and record any residual gap in your risk register with a named owner. That documented judgement, not a bespoke clause, is what an auditor wants to see for click-through and non-negotiable SaaS terms.

Work through three steps:

1. Review the standard terms. Read the service terms and security addendum for data handling, incident notice, sub-processing and exit.
2. Collect independent assurance. Gather certificates and independent audit reports, and check each against date and scope.
3. Record the residual gap. Log what the terms do not cover in your risk register, with an owner and a decision to accept, mitigate or avoid.

The register entry then points to the assurance file and the risk entry, so an auditor can follow your judgement in one pass. Sometimes the gap is too wide to accept, and the documented decision is to choose another supplier or add your own controls.

Proportion cuts the other way too. Demanding bespoke audit rights from a hyperscaler buys risk theatre, not protection. Putting the full critical-tier schedule on a trivial vendor is the same mistake. Low-risk vendors that never touch confidential data may need only confidentiality basics. Over-papering the stationery supplier is wasted legal spend and a review burden you will carry forever.

What goes in an ISO 27001 supplier register?

An ISO 27001 supplier register lists every agreement with its risk tier, contract status, security-terms version, data processing agreement status, assurance validity and renewal date. Auditors sample from it, so it must be current within the last review cycle and show that each contract is still needed and still fits.

Add the signature date to each entry, and schedule a periodic pass to confirm every contract still matches what the supplier delivers. Contracts signed once and never revisited are a common failure: the supplier's role has tripled in scope while the paper still describes the original job.

Version your tier templates and record the version against each supplier. When a template changes, after a new regulation or a lesson from an incident, the register shows at once which suppliers still sit on older terms. That list becomes your re-papering plan.

The register is also the index to the rest of your evidence. For each sampled supplier, expect to produce:

• Executed agreements: the master agreement, security schedule or addendum and DPA, with the security terms actually present.
• Assurance on file: certificates and independent reports, in date and scoped to the service you buy.
• Templates and procedure: the tiered template set and the onboarding step that ties terms to go-live.
• Exit proof: destruction certificates or asset-return confirmations for suppliers that have left.
• Risk entries: accepted gaps for vendors whose standard terms were non-negotiable.

Check scope when you file the assurance, not when the auditor asks. Accepting whatever certificate a supplier sends, without reading its date or scope, is a quiet failure that surfaces in the audit room.

A certificate that covers a supplier's head office says nothing about the service you actually consume.

What will an auditor ask about ISO 27001 A.5.20?

For ISO 27001 A.5.20, auditors usually pick two or three suppliers from your register, most often the most critical plus one recent addition, and read the signed terms against your policy. They then check the promised assurance is on file and in scope, and trace recently terminated suppliers through their exit clauses.

Expect questions like these in the room:

• "Show me the signed agreement for your hosting provider. Where does it say they must notify you of a breach, and within what timeframe?"
• "Your risk assessment flags this processor as critical. How do the contract terms answer those specific risks?"
• "What assurance do these terms entitle you to, and when did you last collect it?"
• "This supplier can subcontract. What do the terms say about equivalent obligations and telling you first?"
• "If you terminated this vendor tomorrow, which clause gets your data back or destroyed, and who verifies it?"

Run the sample yourself before the audit: your most critical supplier, one added in the last year and one that has left. If any of the three cannot be traced from register to signed terms to assurance on file, you have found the finding before the auditor did.

Certification bodies typically grade by severity and pattern:

• Major: a critical supplier operating with no agreement, or agreements with no security content at all.
• Minor: an expired certificate on file, or one supplier on legacy terms awaiting renewal.
• Aggregation: several minors of the same kind can add up to a major as a pattern.

A current register and a tiered template set make all three traces quick to answer.

How can you automate A.5.20 evidence?

Contract negotiation stays human, but the record-keeping around it automates well. Hold the register as structured data, gate onboarding so no supplier goes live without signed tier terms, chase assurance against expiry dates, and watch sub-processor pages for changes. The control then becomes impossible to skip, rather than dependent on memory.

Each piece works like this:

• Register as structured data. Every record carries tier, contract status, terms version, DPA flag, renewal date and assurance expiry. "Which critical suppliers lack current terms?" becomes a query, and renewals raise tickets before dates lapse.
• Gated onboarding. Procurement requests route through a flow that blocks go-live until the right tier's terms are signed and filed. The process gap, not template quality, is where most findings start.
• Scheduled assurance chasing. Expiry dates drive collection requests to suppliers, and the returned documents are filed against the register entry.
• Sub-processor watch. Monitoring vendors' published sub-processor pages turns a contractual notice right into a signal that feeds the A.5.22 review.

A supplier register nobody can query is an inventory, not evidence.

Defining what each tier's terms must contain, and making the accept-or-reject call on non-negotiable vendor terms, is Fractional CISO work. The gated workflow, register-as-data and assurance chasing are GRC engineering deliverables.

The table compares a manually kept register with an engineered one.

Why do DORA, NIS2 and your customers care about A.5.20?

A firm serving regulated clients sits downstream of its customers' obligations. DORA and NIS2 both push contractual requirements through the supply chain, and enterprise procurement teams increasingly ask to see supplier terms, not just policy. Signed, tiered agreements therefore answer diligence questions with evidence instead of promises.

The gap usually surfaces at the worst moment. A diligence exercise or a live incident reveals that a critical vendor was onboarded on a bare order form, with no logs to demand, no duty to cooperate and no recourse.

The pack a regulated buyer wants is the one you already keep for the auditor: the register extract, the tiered schedule template and the assurance on file for your critical suppliers. Share the template and the register extract rather than signed contracts, which usually carry their own confidentiality terms.

At 50 people, a tiered schedule set and a current register let you answer a regulated buyer's diligence from files you already hold.

Frequently asked questions