The 2022 revision of ISO 27001 reorganized Annex A into four themes and added eleven new controls, several of which target supply chain risk explicitly. The changes were not cosmetic. The previous version treated supplier relationships in a way that was largely contractual, and the new version pushes the controls into operational territory, where evidence has to demonstrate ongoing oversight, not just an executed agreement.
For software organizations, the most consequential controls in the new structure live in the A.5.19 through A.5.23 cluster. They cover supplier relationships, supplier addressing within agreements, the ICT supply chain, the monitoring of supplier services, and the management of changes to supplier services. Each control implies evidence the auditor can sample, and the evidence has to align with how modern software is actually built.
Reading A.5.19 through A.5.23 as a connected program
A.5.19 sets the high-level expectation: information security in supplier relationships must be managed through processes and procedures. The control is the program statement. The auditor will look for written policy, defined responsibilities, and a process that connects supplier identification to ongoing oversight.
A.5.20 narrows to the agreements themselves. Information security requirements should be addressed in supplier contracts, with sufficient specificity to be enforceable. For software supply chains, this includes obligations around vulnerability disclosure, SBOM provision, and incident notification.
A.5.21 is the new control that most directly addresses the software supply chain. It expects information security to be managed throughout the ICT supply chain, including for products and services received from suppliers. This is where SBOMs, component-level vulnerability management, and provenance verification land.
A.5.22 covers monitoring, review, and change management of supplier services. The auditor wants to see that supplier performance against security requirements is reviewed on a defined cadence, and that changes are managed with awareness of the security implications.
A.5.23 covers information security for cloud services specifically, with expectations that overlap heavily with A.5.21 in practice.
Read together, these five controls describe a program that identifies suppliers, contracts with them appropriately, monitors them continuously, manages changes deliberately, and produces evidence at each stage. The work for the auditor is not whether the program exists on paper, but whether the program operates.
What evidence the auditor will sample
ISO 27001 audits sample across the population of suppliers and supplier-related events for the period. The auditor picks a supplier, asks for the agreement, the security requirements, the monitoring records, and any change events that occurred during the period. The evidence has to support the claim that the controls applied, not just that the supplier exists.
For software supply chains, the population is large. Every open-source dependency, every commercial library, every cloud service, every third-party API contributes to the supplier landscape, even if not all of them are in scope as formally contracted suppliers. The program needs a way to scope which suppliers carry which obligations, and to produce evidence proportionate to the criticality of each.
A practical approach is to tier the supplier landscape. Critical suppliers, typically commercial vendors and high-impact cloud services, get full A.5.20 treatment with contracted security obligations and dedicated monitoring records. Significant suppliers, including major open-source projects that the organization depends on, get monitoring records and risk assessments without necessarily having a contracted relationship. Routine suppliers, the long tail of dependencies, are tracked through inventory and aggregated metrics.
The tiering itself is an evidence artifact. The auditor will want to see the criteria, the application, and the review cadence.
How Safeguard fits the program
Safeguard sits at the operational layer of A.5.21 and A.5.22. The platform produces and retains the SBOMs that define the ICT supply chain at any given point in time. As components change across releases, the diffs produce the change records that A.5.22 expects.
For each supplier in scope, Safeguard's supplier risk view aggregates the components attributable to that supplier and maintains a risk profile. When the program calls for a quarterly review of critical suppliers, the review pulls the current risk profile, the vulnerabilities affecting components from that supplier in the period, and the remediation actions taken. The review is logged, and the log becomes the A.5.22 monitoring evidence.
For component-level vulnerability management, Safeguard records findings against the SBOMs that contained them. When a critical vulnerability is reported in a supplier's component, the finding triggers triage, the triage decision is logged, and the remediation, if any, is tied back to the original record. The chain from supplier event to organizational response is unbroken.
Policy gates enforce the requirements at the points where they bite. If A.5.21 implies a constraint on which components can enter the production environment, the gate checks the constraint and logs each evaluation. The gate is both the control and the evidence source.
The information security objectives in supplier agreements
A.5.20 is often the control that requires the most contract work. The information security objectives need to be specific enough to be enforceable, and they need to align with the organization's broader policy.
For software suppliers, common objectives include timely vulnerability disclosure, SBOM provision in a recognized format, prompt notification of incidents that could affect the organization, and adherence to defined patching timelines. Each of these objectives implies evidence the supplier should be willing to provide on request, and the agreement should make that explicit.
When the supplier provides SBOMs and disclosure records on a defined cadence, the organization's evidence base extends naturally. Safeguard ingests supplier-provided SBOMs and integrates them into the broader inventory, which means the supplier's own evidence becomes part of the organization's monitoring program.
Change management and the A.5.22 cadence
A.5.22 expects monitoring, review, and change management of supplier services. The change management dimension is often the part that gets least attention before an audit, because changes happen continuously and reviewing each one feels overwhelming.
A working approach is to define the change types that warrant review and to handle the rest through aggregated metrics. Major version upgrades of critical components warrant individual review. Minor version updates and patch releases can be aggregated into a monthly or quarterly summary. The summary itself is evidence, as long as it is produced consistently and reviewed on the defined cadence.
Safeguard's release-over-release SBOM diffs feed both halves of this approach. Major changes are flagged for individual review. Minor changes contribute to the aggregate metrics. The auditor sees both the headline changes and the routine flow.
Transitioning from the 2013 version
Organizations transitioning from ISO 27001:2013 sometimes underestimate how much the supplier relationship controls have shifted in operational terms. The 2013 controls existed, but they were lighter on the ICT supply chain dimension, and many programs treated them primarily as contracting controls. The 2022 revision pushes the work into ongoing monitoring and component-level evidence, which means the program may need new tooling and new cadences, not just updated documentation.
Building the supply chain evidence base early in the transition shortens the path. The SBOMs, supplier risk records, and policy gate logs that satisfy the 2022 controls also feed adjacent frameworks, which means the investment compounds.
The longer arc
ISO 27001:2022 is one of several frameworks converging on supply chain evidence as core security artifacts. The same SBOMs, vulnerability records, and supplier oversight logs that satisfy A.5.19 through A.5.23 also satisfy SOC 2 supplier controls, NIS2 supply chain expectations, and CRA self-assessment requirements. Treating the ISO program as the first expression of a continuous evidence base, rather than a standalone project, is what turns the next certification into an export rather than a rebuild.