A.5.21 Managing information security in the information and communication technology (ICT) supply chain

Control objective

This control requires the supply chain risks that arise across the acquisition and use of ICT products and services to be identified and managed. Hardware, software, firmware, cloud, and managed services reach an organization through multiple upstream and downstream suppliers, so a vulnerability or tampering in a single component can propagate across the whole environment. The control's aim is to assure the authenticity and integrity of components, prepare for supply disruption, and prevent risk proactively. ISO/IEC 27002 guidance recommends requiring suppliers to flow the organization's security requirements down to their sub-suppliers (subcontractors), and having a way to confirm that delivered ICT products and services meet those requirements.

Key checkpoints

Is there a procedure to identify and assess ICT supply chain risks (component provenance, sub-suppliers, tampering/counterfeiting) when acquiring ICT products/services?
Do contracts/agreements require security requirements to be propagated down to sub-suppliers (subcontractors)?
Are there methods to verify the authenticity and integrity of acquired hardware/software components (genuineness, tamper checks, signature/hash verification)?
Are software components (open source, third-party libraries) inventoried (for example, an SBOM) with tracking of vulnerabilities, licenses, and end-of-life/support (EoL/EoS) status?
Have alternatives and continuity measures been considered for supply disruption, discontinuation, or supplier failure of critical ICT products/services?
Is security verification and monitoring performed on components delivered through the supply chain, both before adoption and during operation?

Implementation guidance

State supply chain security requirements (component provenance disclosure, authenticity evidence, flow-down obligations to sub-suppliers, vulnerability notification duties) in the ICT acquisition policy and embed them in the procurement process.
Identify ICT products/services critical to the organization and their suppliers, map the supply chain tiers (first, second, and beyond) and subcontracting structure, and apply management effort proportionate to risk.
Include in contracts/agreements the flow-down of security requirements, provision of component specifications (including an SBOM), notification of security incidents/vulnerabilities, and audit/verification rights.
Check hardware provenance and tampering through seals, identifiers, and custody records. Verify software using trusted signatures or digests obtained through an authenticated supplier channel; a checksum from an untrusted source does not establish authenticity.
Obtain and maintain a software bill of materials (SBOM) and continuously track known vulnerabilities (CVEs), license risks, and end-of-support dates.
Reduce single-supplier dependence for critical components by pre-assessing alternative suppliers/products, and keep migration plans ready for discontinuation or end of support (EoS).
Formalize pre-adoption security verification (acceptance testing, known-vulnerability checks) and in-operation monitoring (reflecting patches, version changes, and vulnerability advisories).

Related controls and attributes

Evidence

ICT acquisition policy/procedures that include supply chain security requirements
List of critical ICT products/services and suppliers, plus documentation mapping supply chain tiers/subcontracting
Contracts/agreements specifying security requirements (flow-down to sub-suppliers, SBOM provision, vulnerability notification)
Records of component authenticity/integrity verification (signature/hash checks, genuineness confirmation)
Software bill of materials (SBOM) and a register tracking vulnerabilities/licenses/end-of-support
Pre-adoption security verification results and in-operation monitoring/action records
Alternative-supplier assessments for critical components and continuity/migration plans

Nonconformity examples

ICT products/services are contracted without identifying supply chain risks or defining security requirements.
Security requirements are imposed only on the directly contracted supplier, with no flow-down to sub-suppliers (subcontractors).
No software bill of materials (SBOM) is obtained for adopted software, so the impact scope of open-source vulnerabilities (CVEs) cannot be determined.
Hardware/software is adopted without authenticity/integrity verification (genuineness, signature, hash), exposing the organization to tampering/counterfeiting risk.
A critical ICT product remains in operation past its end of support (EoS) with no replacement or migration plan.