ISO 27001:2022, A.8.25 to A.8.28: the four development controls and what evidences each one
Annex A of ISO 27001:2022 gives building software four numbered controls. This piece takes them one at a time, says plainly which ones a per-commit scan can back up with dated records, which ones only a document or a review can, and why A.8.8 belongs in the same conversation.
Why the 2022 edition is more precise here
In the previous edition the requirements for secure development were spread across a broader section. The 2022 revision regrouped them in Annex A under the technology theme and gave each its own number. For a mid-sized company that has one practical consequence: an auditor works down the numbers individually and expects a separate record for each. A general statement that development is done securely covers none of the four.
Our code security and compliance page carries the mapping in short form. What follows is the long form, control by control, with an honest note on what a scan contributes and what it does not.
A.8.25: Secure development life cycle
The control asks that rules for the secure development of software and systems be established and applied. The second half is the hard one. Rules go into a document quickly; that they are applied has to be shown. A scan that runs on every commit and assesses each change in the context of the codebase before the code moves on is a record of exactly that second half: the rule bites in the process, not only in the annual report.
What the scan does not replace is the rule itself. The document that lays down how development is done has to exist. The scan evidences its application, not its existence.
A.8.26: Application security requirements
This one is about identifying, specifying and approving security requirements when an application is developed or acquired. It happens before the first line of code, in specifications, tickets and sign-offs. A scanner sees none of it. It can check whether an input is validated, but not whether someone decided beforehand that it had to be.
The evidence for A.8.26 is therefore a document: the specified requirements and their approval. Presenting a scan report here evidences the wrong control.
A.8.27: Secure system architecture and engineering principles
This control requires principles for secure architecture to be established, documented and applied in every development. That too is a design matter. How services are separated, where trust boundaries lie, which data is processed where: it lives in architecture documents and reviews, not in source text. A scanner finds a hardcoded password; it does not find that a component should never have been exposed to the network by design.
For A.8.27, architecture reviews are the evidence. A penetration test can complement them, because it checks the running system as a whole from an attacker's point of view.
A.8.28: Secure coding
The control requires secure coding principles to be applied. This is where the scan is at home. Unvalidated input, dangerous system calls, missing access checks, hardcoded credentials: these are breaches of coding principles that have a pattern, and a scan on every commit catches them as they appear. Each finding, its assessment, the fix and the date together form the record that the principles are not merely adopted but enforced.
The record has an upper bound, and the auditor should hear it from you first: a rule about who may approve which invoice cannot be expressed as a code pattern, so the scan will never flag a breach of it, and a tool that pattern-matches will sometimes flag things that turn out to be harmless in your particular setup. Human triage between the raw hit and the documented finding is what keeps both problems out of the file.
A.8.8: Management of technical vulnerabilities, across the board
A.8.8 is not a development control, but it sits over all four: information about technical vulnerabilities in the systems in use must be obtained, exposure assessed and measures taken. For your own code that means above all the open-source dependencies. The scan matches them continuously against known vulnerabilities, and when a library is updated, the finding, the action and the date go into the file. It is the simplest record on the whole list, and the one most often missing.
The way in is the free code analysis: connection, an inventory scan across secrets, dependencies and unsafe patterns, prioritised findings.
Frequently Asked Questions
Does a code scan evidence all four development controls?
No. It evidences A.8.28 and the application half of A.8.25 directly and with dates. A.8.26 and A.8.27 concern requirements and architecture, decisions taken before the code, and those need documents and reviews.
Does the scan replace the ISMS or the certification?
No, and the order runs the other way: the ISMS decides which controls apply to you, the risk assessment decides how far, and certification checks both. The scan merely supplies the dated findings for two of those controls and for A.8.8. It feeds the file; it is not the file.
We have not adopted the standard yet. Is the scan still worth it?
Yes, because the same findings count under Section 30 BSIG if you fall under NIS2, and because records created with a date today do not have to be collected retrospectively later. The scan is the tool you have first, not the last.