ISO 27001 Annex A 5.21 – Managing Information Security in the ICT Supply Chain

Annex A 5.21 addresses a specific blind spot: the security of an ICT product or service rarely rests with the company you actually signed a contract with. Behind your direct supplier sits a chain of subcontractors, component manufacturers, upstream cloud platforms, managed-service providers and software dependencies, and a weakness anywhere in that chain can reach your data. The control asks you to define and operate processes that carry your security requirements down that chain rather than stopping at the first tier.

In practice that means treating supply-chain risk as something to be identified and managed on purpose. You establish criteria for judging whether a supplier, and the parties behind them, is a trustworthy source; you require suppliers to propagate relevant security obligations to their own subcontractors; and you set expectations around component provenance, secure development and how you will be told about changes deep in the chain. Hardware, software and cloud services are all in scope, including the sourcing and lifecycle of components you never handle directly.

The heart of the requirement is flow-down and traceability: the ability to show that a security expectation set at the top is contractually and operationally present at the tiers below, and that you have some way of knowing when the chain shifts underneath you.

A mature implementation produces artefacts an assessor can inspect, not just good intentions. The recurring theme is that requirements are written down, propagated to the parties sitting behind your direct supplier, and evidenced.

• A supply-chain risk process referenced from your supplier policy (5.19) and applied whenever ICT products or services are sourced, with named ownership.
• Flow-down clauses in supplier agreements requiring the supplier to impose equivalent security obligations on its own subcontractors and to disclose material use of fourth parties.
• A register of critical ICT suppliers and their key sub-suppliers, including subprocessors, upstream cloud platforms and significant software components, so the chain is visible rather than assumed.
• Provenance and integrity expectations for hardware and software: how components are sourced, how you obtain a software bill of materials or equivalent assurance, and how you handle counterfeit or tampering risk.
• Change-notification expectations written into agreements, so a supplier is obliged to tell you when it adds a subprocessor, moves processing to a new region, or alters a security-relevant part of its service.
• Evidence of detection: dated records showing that supplier-side changes are actually noticed and reviewed, which is where 5.21 hands off to the monitoring demanded by 5.22.

The depth of scrutiny should be driven by the risk the supplier's service carries, so effort concentrates where a downstream failure would hurt most rather than being spread evenly across every vendor.

Annex A 5.21 does not stand alone. It sits inside the supplier-relationship cluster (5.19 to 5.23), and each control covers a different moment in the supplier lifecycle.

• 5.19 sets the overall policy and approach for information security in supplier relationships, the umbrella under which 5.21 operates.
• 5.20 gets the security requirements into the actual agreement; 5.21 is what makes those requirements meaningful once the supplier is itself buying from others.
• 5.21 extends the same thinking down the ICT supply chain, so obligations reach subcontractors and component suppliers instead of stopping at your direct vendor.
• 5.22 is the ongoing half: monitoring, reviewing and managing change in the services suppliers deliver, and detecting when something shifts after signing.
• 5.23 narrows the lens to cloud services specifically, which for most organisations is where the deepest supply chains now live.

The handoff from 5.21 to 5.22 is where implementations most often break down. 5.21 can define elegant flow-down clauses and a complete supplier register, but if nobody notices when a supplier quietly adds a subprocessor in a new jurisdiction or rewrites a data-processing clause, the control is decorative. 5.22 demands that you detect those post-signature changes and hold evidence that you detected them.

For the subset of supply-chain changes that suppliers publish externally — subprocessor lists, DPAs, the third parties named in privacy and cookie policies, and published security policies — this is exactly the detection gap an external monitor fills. Venpo crawls those public documents on a schedule, flags when the text changes, and produces a dated, linkable redline of what changed, which becomes corroborating evidence that you caught a supplier-side shift when it happened. It is a detection and evidence layer that complements your own supplier reviews; it does not conduct audits, certify anyone, or replace the supplier-management process the cluster requires.

• Stopping at the first tier. Assessing your direct supplier and never asking who sits behind them is the classic 5.21 failure; the control is precisely about the tiers you cannot see.
• Flow-down on paper only. A clause requiring the supplier to impose equivalent obligations downstream means little if you never ask for evidence that it has, or never track its material subprocessors.
• Treating hardware and software provenance as out of scope. Component sourcing, counterfeit risk and dependency assurance are part of this control, not a separate concern to be handled elsewhere.
• No mechanism to learn about change. Relying on a supplier to remember to send a notice, with no independent way to detect a new subprocessor or a changed data location, leaves a gap in your 5.22 evidence.
• Uniform treatment regardless of criticality. Applying the same shallow check to a payroll platform and a marketing widget wastes effort where it does not matter and misses depth where it does.
• Unclear ownership. When procurement, security and the business each assume another function owns supply-chain assurance, reviews lapse and downstream change goes unnoticed.