5.21 Managing information security in the ICT supply chain
Processes and procedures are to be defined and put in place to manage information security risks in the supply chain for ICT products and services. Purpose: keep security across the chain of ICT suppliers at the level agreed. Guidance: on top of the general supplier requirements, consider: setting security requirements for acquiring ICT products and services; requiring ICT service suppliers who subcontract to pass the organization's requirements down the chain; requiring ICT product suppliers to pass suitable security practices to the makers of components they buy in (subcontracted developers, hardware component makers); asking product suppliers to describe the software components inside their products; asking them to describe the security functions implemented and the configuration needed to run the product securely; monitoring and validating that delivered products and services meet stated requirements, for example through penetration testing or checking third-party attestations; identifying and documenting components critical to functionality that need closer scrutiny and follow-up when built externally, especially when further outsourced; getting assurance that critical parts can be followed back to where they came from; obtaining assurance that products work as expected with no unexpected or unwanted features; ensuring components are genuine and unaltered, using anti-tamper labels, hash checks or digital signatures, watching for out-of-specification behaviour as a sign of tampering or counterfeits, and guarding against tampering throughout design, development, integration, operation and maintenance; seeking assurance of required security levels through certification or evaluation schemes such as the arrangement for mutual recognition of Common Criteria certificates; agreeing rules for sharing supply chain issues and compromises with suppliers; and managing component life cycle and availability risk, including suppliers leaving the market or dropping components, with an alternative supplier and a way to transfer software and know-how. Other information: these practices sit on top of general security, quality, project and engineering practice; working with suppliers helps the organization understand the chain and influence it through agreements; ICT should come from reputable sources; the scope includes cloud services, IoT and hosting chains; ISO/IEC 27036-3 and software identification tags (ISO/IEC 19770-2) help.
Source: ISO/IEC 27002:2022, 5.21. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Integrity verification records for delivered products such as hash or signature checks and anti-tamper inspections · Document repository
- Validation evidence such as penetration test results, product certifications or evaluation scheme reports · Vulnerability scanner / patch tooling
- Component end-of-life and availability risk records, with alternative supplier plans · Vendor register / contract repository
governing documentDocuments that govern the control
- Security requirements included in ICT acquisition specifications and contracts, including flow-down to sub-suppliers · Vendor register / contract repository
- Software component information such as SBOMs and descriptions of security functions and secure configuration obtained from product suppliers · Vendor register / contract repository
- A list of critical ICT components with provenance and traceability evidence · Document repository
First move
Common gaps auditors find
- Software is accepted without any bill of materials or component information
- Downloaded software and firmware updates are installed without signature or hash verification
- Critical components have no identified alternative source
- Sub-suppliers are invisible because contracts do not require disclosure or flow-down
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet5.20 Addressing information security within supplier agreements · 5.22 Monitoring, review and change management of supplier services