A.5.21ISO 27001Last reviewed 19 February 2026

ISO 27001 A.5.21: Managing information security in the ICT supply chain

SolarWinds. Log4j. These are the supply chain attacks that made headlines, but they illustrate a pattern: attackers target suppliers to compromise thousands of downstream organisations at once. Your technology stack has a supply chain, and you need to understand it.

Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.

Start my free ISO 27001 assessmentNo account · No credit card · Save when useful

Requirement summary

Processes and procedures shall be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.

Check the source wording and scope in ISO/IEC 27001:2022. The guidance below explains how to approach a review.

In Plain Language

This control goes beyond your direct vendors. A software vendor uses open-source libraries, a hardware manufacturer sources chips from multiple suppliers, a cloud provider relies on other infrastructure providers. A compromise at any point in that chain can reach you.

Managing ICT supply chain risk means mapping out where your critical technology comes from, assessing the security of that chain, requiring your suppliers to manage their own supply chain risks, and watching for incidents and vulnerabilities that could affect you.

How to Implement

Start by mapping the ICT supply chain for your critical systems and services. Identify key suppliers, their sub-suppliers where possible, and your software dependencies including open-source components. You cannot protect what you do not know about.

Define supply chain security requirements for different categories. For hardware: use trusted procurement sources, require tamper-evident packaging, verify integrity on receipt, and configure securely before deployment. For software: evaluate the vendor's development security practices, request SBOMs (software bills of materials), verify code signing, and ensure secure delivery. For services: assess the provider's own supply chain management.

Put supply chain security requirements into your supplier agreements. Require suppliers to maintain their own supply chain security programme, notify you of significant supply chain incidents, give you visibility into critical sub-suppliers, follow secure development practices, and provide SBOMs where applicable.

Implement technical controls for verification. Check software integrity using digital signatures and checksums before deploying anything. Run vulnerability scanning on software components and dependencies. Monitor supply chain compromise advisories from CERTs and vendor security teams. Use application whitelisting to block unauthorised software.

Set up ongoing monitoring. Subscribe to vulnerability feeds for your technology stack. Watch for security advisories from ICT suppliers. Join information-sharing communities that report supply chain incidents. Assess critical suppliers' security practices periodically. Have a response plan ready for supply chain compromise scenarios.

Evidence to review

ICT supply chain mapping for critical systems and services
Supplier agreements with ICT supply chain security requirements
Software integrity verification procedures and records
Vulnerability management records for ICT products and dependencies
Supply chain incident monitoring and response procedures

Common Mistakes

No visibility into the ICT supply chain beyond direct tier-one suppliers
Software dependencies and open-source components are not tracked or assessed
Hardware is deployed without integrity verification after delivery
Supplier agreements do not address supply chain security requirements
No monitoring for supply chain compromise advisories or incidents

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	SOC 2 CC9.2: Risk Mitigation - Vendor and Business Partner Risk Management	Related
NIS2	NIS2 Art.21(2)(e): Security in Network and Information Systems Acquisition, Development and Maintenance	Equivalent
GDPR	GDPR Art.28: Processor	Partial overlap

Frequently Asked Questions

What is a Software Bill of Materials (SBOM) and should we require it?

An SBOM is a machine-readable inventory of every component and dependency in a piece of software. Think of it as a nutrition label for code. It lets you quickly check whether you are affected when a new vulnerability drops - like when Log4j hit and everyone was scrambling to figure out where it was in their stack. Requiring SBOMs from critical software suppliers is increasingly considered best practice, and some regulations are already making them mandatory. If you are not asking for them yet, start with your most critical vendors.

How do we manage open-source supply chain risks?

Use software composition analysis (SCA) tools to inventory all open-source components in your codebase. Monitor vulnerability databases (NVD, GitHub Security Advisories) for known issues in those components. Set up a process for patching vulnerable dependencies quickly - do not let them sit for months. Consider using curated or verified open-source repositories rather than pulling from anywhere. Pin your dependencies and check integrity in your build pipeline. The goal is not to avoid open source - that is unrealistic - but to know exactly what you are using and react fast when something goes wrong.

Track ISO 27001 compliance in one place

Work through the ISO 27001 assessment, record supporting evidence and review the gaps in your answers.

Start Free Assessment

Start without an account · Sign up only to save

Start my free ISO 27001 assessment