ISO 27001 Annex A 5.20 – Addressing Information Security Within Supplier Agreements

Control 5.20 is where supplier security stops being a policy aspiration and becomes an enforceable term. It requires that the information-security requirements relevant to each supplier are established and agreed with that supplier, normally in a documented agreement clear enough that both sides understand their obligations — not a generic "appropriate security" line.

In practice, the control asks you to translate the risks identified under 5.19 into concrete contractual commitments, with depth that scales to the sensitivity of the information the supplier touches and the access it holds. A supplier processing regulated personal data warrants far more than one that ships stationery. The obligations that typically belong in scope include:

• What information the supplier may access, process or store, and the classification level attached to it.
• Security controls the supplier must maintain, and any certifications or attestations it must hold and keep current.
• Sub-processing terms — whether the supplier may engage further parties, and the notice or approval you require before it does.
• Incident notification: what counts as a reportable event, the deadline for telling you, and the detail you expect in that notice.
• Rights to audit, request evidence or receive assurance reports during the life of the contract.
• Data location and transfer terms, applicable legal and regulatory obligations, and personnel screening where relevant.
• Return or secure destruction of your information, and continuity of service, on termination or exit.

The intent is preventive. By fixing these obligations in writing before information changes hands, you keep the leverage to enforce them and establish a documented baseline against which any later drift in the supplier's service can be judged.

An assessor reading your 5.20 implementation wants to see that clauses are risk-driven, current and evidenced — not merely that a template exists somewhere. The following artefacts tend to demonstrate that.

• A supplier-agreement template or clause library with a modular set of security terms, so contract owners select obligations proportionate to the supplier's risk tier rather than pasting the same paragraph everywhere.
• A register linking each in-scope supplier to its signed agreement, the security clauses that apply, the classification of data involved, and the named review owner.
• Incident-notification windows in the contract that align with your own regulatory reporting deadlines, so a supplier's slower notice cannot blow your obligation.
• Explicit sub-processor terms: a reference to the supplier's authorised subprocessors and a contractual right to be told before that list changes.
• Named audit or assurance rights, plus a record that you actually exercise them — collected assurance reports, completed questionnaires, or reviewed certificates on file.
• Exit terms covering return or secure destruction of information and handover support at contract end.

Mature programmes also close the loop between paper and reality. The agreement says the supplier will notify you of a new subprocessor or a change of processing region; a strong implementation does not rely solely on that promise but independently watches the supplier's published subprocessor list, DPA and security policy so a silent change is caught rather than missed. External change detection of this kind — for example a service such as Venpo, which timestamps when a vendor edits its subprocessor list, DPA, privacy policy or published security policy — gives you dated, independent evidence that the obligation was being watched, rather than leaving you reliant on the supplier to self-report. It is an external detection and evidence layer only: it reads what a supplier publishes, and does not assess the supplier's internal controls, audit anyone, or discharge the assurance rights you hold under the agreement.

5.20 does not stand alone. It is the contractual hinge in a five-control cluster that runs from strategy through to exit:

• 5.19 — Information security in supplier relationships: sets the policy and process for engaging suppliers at all and identifies the risk each relationship carries. It defines what needs protecting.
• 5.20 — Addressing information security within supplier agreements: turns those requirements into binding contract terms. It defines the commitment.
• 5.21 — Managing information security in the ICT supply chain: extends the obligations down the chain to a supplier's own suppliers and to product and component provenance.
• 5.22 — Monitoring, review and change management of supplier services: checks, throughout the contract, that the supplier still meets the 5.20 terms and detects when its service or security posture changes. It defines the ongoing verification.
• 5.23 — Information security for use of cloud services: applies the same disciplines specifically to cloud provisioning, use and exit.

The join between 5.20 and 5.22 is the one organisations most often under-build. 5.20 writes the promise; 5.22 requires you to keep watching whether it still holds after signing — because a supplier can add a subprocessor, move data to a new region, or quietly weaken a data-processing clause without ever reopening the contract. The very terms you set under 5.20 — sub-processing notice, incident reporting, change notification — are precisely what 5.22 monitoring exists to verify.

This is where publicly-observable change detection contributes. Many of the changes 5.22 asks you to catch appear in the supplier's own published legal documents before any formal notice arrives. Capturing and dating those changes gives you corroborating evidence of when a supplier-side change happened — useful when checking whether a notification or approval obligation set under 5.20 was actually met.

• Generic boilerplate. A single "appropriate technical and organisational measures" clause applied to every supplier fails the proportionality the control expects and leaves you nothing measurable to enforce.
• Sign and forget. The agreement is executed, filed, and never revisited. Without the 5.22 monitoring loop, the clauses go stale the moment the supplier's service changes.
• No subprocessor-change term. Contracts silent on downstream processors leave you blind to the change most likely to introduce new risk — and with no contractual basis to object when it happens.
• Misaligned incident windows. A supplier notification deadline looser than your own regulatory obligation quietly makes timely reporting impossible.
• Unexercised rights. Audit and assurance clauses that are written but never invoked read, to an assessor, as controls that live only on paper.
• No exit provisions. Missing data-return or destruction terms turn offboarding into an open-ended data-exposure risk.
• Owner ambiguity. When procurement owns the contract but security owns the risk and neither owns the review, obligations drift with no one accountable.

Most of these reduce to one root cause: treating 5.20 as a one-time drafting exercise rather than a live commitment that has to be verified for the life of the relationship.