Skip to content
AuditFront
A.5.21 ISO 27001

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

What This Control Requires

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

In Plain Language

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.

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 Your Auditor Will Request

  • 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 CC9.2 Related
NIS2 Art.21(2)(e) Equivalent
GDPR Art.28 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

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment