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

What the requirement asks

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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

The ICT supply chain adds subcontractors and dependencies. The guidance asks how far down the chain the organization can see, what it requires at each layer and how it learns about a change.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep security requirements included in ICT acquisition specifications and contracts, including flow-down to sub-suppliers and one live sample together.

Evidence an assessor asks for

• ICT supply chain securitySecurity requirements included in ICT acquisition specifications and contracts, including flow-down to sub-suppliers
• ICT supply chain securitySoftware component information such as SBOMs and descriptions of security functions and secure configuration obtained from product suppliers
• ICT supply chain securityA list of critical ICT components with provenance and traceability evidence
• ICT supply chain securityIntegrity verification records for delivered products such as hash or signature checks and anti-tamper inspections
• ICT supply chain securityValidation evidence such as penetration test results, product certifications or evaluation scheme reports
• ICT supply chain securityComponent end-of-life and availability risk records, with alternative supplier plans

The question an assessor will ask

An assessor will ask for security requirements included in ICT acquisition specifications and contracts, including flow-down to sub-suppliers, then trace it to the system it protects. For A.5.21 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• 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

Before the next audit

Before the next audit, check one live sample for this gap: software is accepted without any bill of materials or component information.