How software supply chain controls map to ISO 27001

ISO 27001 does not name SBOMs or package registries, but its 2022 Annex A supplier controls, especially information security in supplier relationships and managing security in the ICT supply chain, apply to the software you depend on. Map your dependency inventory and build pipeline to those controls, and keep the evidence.

This is an explainer. No tool certifies you against ISO 27001. A certification body audits your management system, and the scope and controls you choose are your decision.

Which Annex A controls are relevant?

The 2022 version of Annex A groups controls into themes. The supplier related ones in the organisational theme, as titled in Open Security Architecture's listing, are:

• 5.19 Information security in supplier relationships
• 5.20 Addressing information security within supplier agreements
• 5.21 Managing information security in the ICT supply chain
• 5.22 Monitoring, review and change management of supplier services
• 5.23 Information security for use of cloud services

One secondary list marks 5.21 and 5.23 as new in 2022 and 5.22 as changed. We could not open ISO's own pages, so check wording and numbering in your licensed copy of the standard.

Consultancy write ups describe 5.19 as policies and procedures to protect assets that suppliers can reach, and 5.20 as agreeing security requirements with each supplier based on that supplier's risk. Treat those as interpretations, not the standard.

Is an open source library a supplier?

Often there is no contract, but there is still a dependency on code you did not write. Auditors differ here, so decide and document your position. Many organizations treat three groups separately.

1. Commercial vendors and SaaS. Covered by contracts, due diligence and review.
2. Open source components. Covered by an inventory, vulnerability monitoring and license checks.
3. Build and delivery tools. Registries, CI services and actions that run with your credentials.

Your scope statement and risk assessment should say how each group is handled. A written decision you follow beats an unwritten assumption.

What evidence supports the mapping?

For vendors, keep the register, the risk rating, the agreement terms and review dates.

For open source, keep a current inventory per product, which is where an SBOM helps, plus a record of how new advisories are checked against it and how long fixes take. If your policy says critical issues are handled within a set time, keep the tickets that show it.

For build tools, keep the list of third party actions and plugins, how they are pinned, and who can change pipeline definitions.

For change and review of suppliers, keep dated reviews and what changed as a result. An auditor will usually sample, so make samples easy to find.

Where tools help and where they stop

Safeguard lists ISO/IEC 27001 in its framework library. Its documentation says that for SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0 it also maps automated tests from the systems you connect, and that each framework page says which requirements a scan decides and which need your own evidence. Read that page before relying on any mapping. The platform builds SBOMs, scans dependencies and checks licenses, which produces inventory evidence, but vendor contracts, risk acceptance and management review stay with your people.

See the idea at /demos/framework-mapping.

What to do

1. Write down which supplier groups are in scope and how each is treated.
2. Add open source and build tools to the supplier or asset risk assessment.
3. Generate an SBOM per product and store it with the release.
4. Define a fix time target per severity and track real fix times.
5. List and pin third party pipeline tools, and limit who edits pipelines.
6. Review suppliers on a schedule and keep dated notes.
7. Ask your auditor early how they view open source dependencies.

Quick check

Sources

• Open Security Architecture: ISO/IEC 27001:2022, found by search 18 October 2026
• DQS: controls A.5.19 to A.5.23, found by search 18 October 2026
• Safeguard documentation: Compliance, fetched 18 October 2026

Last reviewed: 18 October 2026.