ISO/IEC 27001 is the international standard for information security management systems (ISMS), and its 2022 revision reorganised and modernised the control set in ways that matter directly to software teams. If your organisation is certified or pursuing certification, several Annex A controls govern how you develop applications and manage the vulnerabilities in your code and dependencies. This guide walks through those controls and what evidence they call for.
What ISO 27001 is and who it is for
ISO 27001 specifies the requirements for establishing, implementing, maintaining, and continually improving an information security management system. Certification, issued by an accredited body after audit, is recognised globally and often required in enterprise procurement, particularly outside the United States. It applies to organisations of any size in any sector.
The standard has two parts: the management-system clauses (4-10), which cover leadership, risk assessment, and continual improvement, and Annex A, a catalogue of controls you select from based on your risk assessment. The 2022 revision restructured Annex A into 93 controls across four themes — organisational, people, physical, and technological — down from the previous 114. Organisations that were certified against the 2013 version were required to transition to the 2022 version, with the transition period having closed on 31 October 2025, so 2022 is now the operative baseline.
The Annex A controls that govern application security
A cluster of controls in the technological theme (the A.8 series) directly addresses secure development:
- A.8.25 — Secure development lifecycle. Establish and apply rules for securely developing software and systems.
- A.8.26 — Application security requirements. Identify and specify security requirements for applications, including those you acquire or develop.
- A.8.28 — Secure coding. Apply secure coding principles across development.
- A.8.29 — Security testing in development and acceptance. Define and carry out security testing during the lifecycle.
- A.8.30 — Outsourced development. Direct, monitor, and review outsourced development activity.
- A.8.31 — Separation of development, test, and production environments.
And two controls carry most of the software supply chain weight:
- A.8.8 — Management of technical vulnerabilities. Obtain timely information about technical vulnerabilities in the systems you use, evaluate exposure, and take appropriate measures. This is the control that most directly obliges you to know about and act on vulnerable dependencies.
- A.5.19-A.5.23 — Supplier relationships and cloud services. Manage information security risks in supplier relationships, which extends to the third-party and open source components your software depends on.
What A.8.8 really demands
A.8.8 is deceptively short but broad. "Obtain timely information about technical vulnerabilities" means you cannot wait for an annual scan — you need current awareness of newly disclosed vulnerabilities affecting your systems. "Evaluate exposure" means you must assess whether a given vulnerability actually affects you, which requires knowing what components you run. "Take appropriate measures" means documented, timely remediation. An auditor will expect an inventory of assets and components, a source of vulnerability intelligence, a triage process, and remediation records with dates — the same discipline whether the vulnerable component is first-party code or an open source library.
ISO 27001 application security checklist
- Documented secure development lifecycle rules (A.8.25)
- Security requirements defined for each application (A.8.26)
- Secure coding standards applied and evidenced (A.8.28)
- Security testing integrated into development and acceptance (A.8.29)
- Controls over outsourced development activity (A.8.30)
- Separated dev, test, and production environments (A.8.31)
- Component inventory feeding vulnerability management (A.8.8)
- Timely vulnerability intelligence, triage, and remediation records (A.8.8)
- Supplier/third-party code risk covered in supplier controls (A.5.19-A.5.23)
The Statement of Applicability trap
ISO 27001 requires a Statement of Applicability (SoA) listing which Annex A controls you apply and why. A common mistake is marking A.8.8 and the A.8.25-A.8.31 controls as applicable in the SoA, then having no operational evidence behind them for dependencies. Auditors test the gap between what you claim in the SoA and what you can demonstrate — so a control declared applicable but backed only by a policy document, with no scanning results or remediation records, is a nonconformity waiting to be written up.
How Safeguard helps
Safeguard provides the operational evidence behind the Annex A controls that most often lack it. For A.8.8, software composition analysis delivers the "timely information about technical vulnerabilities" the control demands — continuous, not periodic — and records the triage and remediation with dates, so the control is demonstrably operating rather than merely declared in your Statement of Applicability. SBOM Studio maintains the component inventory that makes "evaluate exposure" possible and supports the supplier-risk controls in the A.5 series by making third-party code visible.
The Safeguard CLI embeds security testing into your development and acceptance pipeline (A.8.29) and your secure development lifecycle (A.8.25), producing evidence automatically at each build. Griffin AI prioritises findings by exploitability so remediation effort is defensible and focused. Our compliance pages map each capability to the specific Annex A control it evidences, giving your auditor a clear line from control to proof.
ISO 27001's 2022 controls make application and supply chain security explicit. Back them with continuous, dated evidence and your SoA becomes a set of claims you can actually stand behind.
Turn Annex A controls into evidence auditors can test. Sign up free or read the Safeguard documentation to connect a project and start generating results.