Managing information security in the ICT supply chain

What the control 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.

Purpose in the standard’s terms, in our words: Keeps security across the ICT product and service supply chain at the agreed level.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Identify; Supplier relationships security; Governance and ecosystem, Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

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

Where audits commonly find 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

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. Its earlier numbering (15.1.3) is kept in the register so an older audit file can still be traced. It serves more than one security domain, which is why a domain count taken by row understates the view.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 5.19 Information security in supplier relationships
• 5.20 Addressing information security within supplier agreements
• 5.22 Monitoring, review and change management of supplier services

Read the five attributes All 93 controls