ISO/IEC 27001 is the international standard for information security management systems (ISMS), and its 2022 revision reshaped Annex A — the catalogue of controls organisations select from to treat their risks. If you certified against the 2013 version, or are certifying for the first time, the 2022 structure changes what your engineering and supplier controls look like, and it adds several controls that speak directly to how software is built and sourced. This guide focuses on the Annex A subset that lands on development and platform teams, and on the evidence auditors expect for each.
What changed in ISO/IEC 27001:2022
The 2022 revision reduced and reorganised Annex A from the old 114 controls across 14 domains to 93 controls across 4 themes: Organizational (37 controls), People (8), Physical (14), and Technological (34). Eleven controls are genuinely new, and many others were merged or renamed. The control detail itself lives in ISO/IEC 27002:2022, which Annex A references. Importantly, Annex A is not a mandatory checklist — you select applicable controls through a risk assessment and document your choices in a Statement of Applicability (SoA). That said, the software and supplier controls below are hard to justify excluding for any organisation that builds or buys software.
The transition mattered on the calendar: certificates issued against ISO/IEC 27001:2013 needed to migrate to the 2022 version by the end of the three-year transition period, which closed on 31 October 2025. As of 2026, active certifications are on the 2022 version, so the controls in this guide are the operative ones.
The controls that land on engineering
Several new and updated controls are where software teams do the work:
- 8.28 Secure coding — establish and apply secure coding principles across the development lifecycle, including for externally sourced and open-source components.
- 8.25 Secure development life cycle — rules for securely developing software and systems.
- 8.26 Application security requirements — identify, specify, and approve security requirements when developing or acquiring applications.
- 8.27 Secure system architecture and engineering principles — build systems on secure-by-design principles.
- 8.29 Security testing in development and acceptance — define and run security testing throughout the SDLC.
- 8.30 Outsourced development — direct, monitor, and review outsourced development activity.
- 8.8 Management of technical vulnerabilities — obtain timely information about vulnerabilities, evaluate exposure, and take appropriate measures.
- 8.9 Configuration management and 8.31 Separation of development, test, and production environments round out the build hygiene set.
On the supplier side, the organisational theme carries the supply-chain controls: 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, and 5.23 Information security for use of cloud services. Control 5.21 is the explicit ICT-supply-chain control, and it is where knowing your software components becomes an audit expectation.
Compliance checklist
| Annex A control | Engineering evidence |
|---|---|
| 8.8 Technical vulnerabilities | Continuous vulnerability feed, exposure assessment, remediation records |
| 8.25 / 8.26 SDLC and app-sec requirements | Documented lifecycle and security requirements per project |
| 8.28 Secure coding | Coding standards, reviews, and results |
| 8.29 Security testing | Test coverage evidence in dev and acceptance |
| 8.30 Outsourced development | Oversight and review records for third-party dev |
| 8.31 Environment separation | Segregated dev/test/prod evidence |
| 5.21 ICT supply chain | Component inventory (SBOM) and supplier assurance |
| 5.22 Supplier monitoring | Ongoing review of supplier security posture |
How Safeguard helps
ISO/IEC 27001 auditors want to see that your selected controls operate, not just that they are documented, and the technical-vulnerability and supply-chain controls are the hardest to evidence with static artefacts. SBOM Studio maintains the component inventory that underpins control 5.21 (ICT supply chain) and gives control 8.8 (technical vulnerabilities) something concrete to assess exposure against. Safeguard's SCA provides the "timely information about technical vulnerabilities" that 8.8 requires, continuously matching your components against known CVEs and ranking them by reachability so remediation records show risk-based prioritisation. Griffin AI delivers tested fixes as reviewable pull requests, which supports both the secure-coding intent of 8.28 and the security-testing expectation of 8.29 by keeping remediation inside the review process. Because every scan and fix is time-stamped in one record, the evidence an auditor samples for your Statement of Applicability is retrievable on demand. Our compliance pages map each capability to the relevant Annex A control.
Frequently Asked Questions
Do I have to implement every Annex A control? No. Annex A is a reference set, and you select applicable controls through your risk assessment, recording the decision and justification in the Statement of Applicability. You can exclude a control if you justify why it does not apply — but excluding the technical-vulnerability or ICT-supply-chain controls is difficult to defend for any organisation that builds or consumes software.
What is the difference between ISO 27001 and ISO 27002? ISO/IEC 27001 is the certifiable standard that specifies the ISMS requirements and lists the Annex A controls by reference. ISO/IEC 27002 is the implementation guidance that explains each control in detail. You certify against 27001; you read 27002 to understand how to implement the controls it describes.
Is an SBOM required for ISO 27001 certification? Not by name. Control 5.21 requires you to manage information security risks in the ICT supply chain, and control 8.8 requires timely vulnerability information and exposure assessment. A software bill of materials is the practical mechanism auditors expect behind both, because you cannot manage supply-chain risk or assess exposure in components you have not inventoried.
Did the 2013 to 2022 transition deadline pass? Yes. The three-year transition period for migrating certificates from ISO/IEC 27001:2013 to the 2022 version closed on 31 October 2025. Active certifications are now on the 2022 structure, so the 93-control Annex A and its new secure-development controls are the operative baseline in 2026.
Mapping Annex A to real evidence? See how our SCA engine supports controls 8.8 and 5.21 on the compliance pages, or read the Safeguard documentation.