ISO 27001 Annex A 8.28 secure coding, and the evidence it asks for

The 2022 revision of ISO/IEC 27001 reorganised Annex A and introduced a set of new controls. One of them, A 8.28, is about secure coding. It asks organisations to apply secure coding principles to software development — both code written in-house and components brought in from elsewhere. For engineering teams the practical question is not whether secure coding is a good idea, but what an auditor expects to see as proof that it is happening.

What 8.28 actually covers

The control is broad by design. It spans the activities before, during, and after writing code:

• Before — establishing secure coding standards and baselines, and tracking known vulnerabilities in the libraries and frameworks you depend on.
• During — applying those standards in the development workflow, with review and tooling that catches insecure patterns as code is written.
• After — monitoring for newly disclosed vulnerabilities in deployed code and components, and handling them through a defined process.

It also reaches third-party and open-source components, which is where much of the real exposure in a modern codebase sits.

Where the evidence problem shows up

A 8.28 is a control an organisation implements, not a certificate a tool issues. The friction for engineering teams is almost always evidence: showing that the standard exists, that it is applied in practice, and that findings are tracked and resolved rather than noted once and forgotten. A policy document on its own rarely satisfies that — auditors look for a record that secure coding is a continuous practice tied to the actual codebase.

Where a scan helps

OLYDI fingerprints the stack and surfaces findings that map to secure coding concerns — insecure patterns, dependency risk, and the controls already in place — and mirrors them into the GitHub Security tab so there is a continuous, dated record rather than a point-in-time snapshot. It does not implement A 8.28 for you or make you certified against ISO 27001; it gives you a baseline read and an evidence trail the secure coding conversation can start from.

Get your baseline

npx @olydi/cli scan
# Scan complete. Findings written to SARIF.

Run the scan, review the findings, and decide what to clear first. The scan is free; clearing findings at volume is paid on Valty tiers.

This article is general information about regulatory developments, not legal advice. Consult qualified counsel for your specific obligations.