ISO 27001 A.5.21: Understand ICT Supply-Chain Risk

What A.5.21 requires in practice

Control A.5.21 extends supplier thinking to the information and communication technology supply chain. The organisation must define and operate processes for managing the security risks tied to ICT products and services, which include the suppliers behind your suppliers. A hosting provider relies on hardware makers, software components and its own subcontractors, and weaknesses there can reach you.

In practice the control looks for evidence that you have considered how far your dependency reaches, asked suppliers about their own sourcing where it matters, and set expectations they pass on. It also expects attention to how components are obtained, updated and replaced. The standard does not say how deep to look; that depends on your risk. Mapping every layer is a method for critical services, not a universal requirement.

Identify dependencies that could change your decision

Start with a consequential product or service and ask what it relies upon. Focus on components whose compromise, withdrawal or failure could undermine its essential function or the protection of your information. A dependency map is useful when it helps answer an operational question, not when it merely creates a large diagram.

Ask the direct supplier for information needed to assess those dependencies. Depending on the product, component information, support arrangements or evidence of downstream security practices may be relevant. A software component inventory can support vulnerability analysis, but its existence is not proof that components are secure or that the information remains current.

Consider shared dependencies across apparently separate suppliers. Two services may rely on the same underlying infrastructure or support organisation. That does not automatically make either unsuitable, but it can weaken an assumption that one will remain available when the other fails.

Carry requirements through the relationship

Clarify which security expectations the direct supplier must pass to relevant subcontractors or component providers. Connect them to supplier agreements. Avoid assuming that a supplier’s promise automatically binds every party further down the chain without an operating mechanism.

Determine how material changes and concerns will be communicated. A supplier replacing a critical component may alter support, compatibility or security characteristics. Your review needs sufficient information to assess the consequence and decide whether testing, configuration changes or alternative arrangements are required.

Why ICT supply-chain risk matters to the business

Many serious incidents begin with a trusted component: a software update, a hardware part or a service several steps removed from your contract. You may never have chosen the company at fault, yet the outage or exposure lands on you. Understanding the chain helps you decide where to ask harder questions, where to keep alternatives and where to accept dependency knowingly. It also supports credible answers when customers ask where your services really come from. Auditors look for judgement proportionate to the importance of the service, not for an exhaustive map of every component.

How to implement A.5.21

Focus first on the ICT services your business could not easily do without. A practical path is given below. Supply-chain questions can overwhelm a small team, so resist the urge to map everything. Pick services whose failure would stop delivery to clients, and learn how they are built. Suppliers often answer these questions readily when asked politely and specifically. Record what you learn in a form the people responsible for continuity and risk can reuse, and accept openly where a dependency cannot be avoided.

1. Identify the ICT products and services that support critical processes.
2. Ask the main suppliers which providers and components they depend on for those services.
3. Note single points of failure, such as one provider with no practical alternative.
4. Add expectations to agreements, including that relevant requirements pass to subcontractors.
5. Decide how you will learn about changes, vulnerabilities or ownership changes affecting the chain.
6. Plan what you would do if a component or provider became unavailable.
7. Review the picture when you adopt new technology.

Illustrative software example: a vulnerable embedded component

Illustrative manufacturing example: replacement network equipment

A hypothetical manufacturer urgently needs a replacement network device for a production area. An unfamiliar intermediary offers a compatible unit quickly, but its origin and support status are unclear. The purchasing decision could introduce altered equipment or an unsupported device into a sensitive environment.

The manufacturer uses an authorised acquisition route and appropriate authenticity checks, then verifies the received device against its intended specification before deployment. It also examines why emergency stock arrangements forced the risky choice. The response combines acquisition assurance with continuity planning rather than relying solely on the supplier’s sales description.

Include the end of component support

Supply-chain risk changes when a component is no longer maintained, a specialist provider closes or a product becomes unavailable. Identify how these events are detected and who decides the response. Replacing a component can require new skills, data migration or revised architecture, so a late discovery may leave few safe options.

For important dependencies, consider feasible alternatives and the information needed to move. Not every component requires a second supplier ready for immediate use. The practical objective is a proportionate response to foreseeable dependency failure, including documented acceptance when constraints prevent an immediate change.

Evidence and failure tests