A.8.28 A.8 · Technological Controls New in 2022

A.8.28 — Secure coding

Apply secure coding principles to software development.

Also written as A8.28, Annex A 8.28, ISO 27001:2022 A.8.28, ISO27001 A.8.28.

Written by Jett N. · Last reviewed

What ISO 27001 A.8.28 requires

Secure coding is one of 34 Technological Controls in ISO/IEC 27001:2022 Annex A. Apply secure coding principles to software development. Technological controls are tested against system state, not policy text: expect the auditor to ask for configuration exports, tickets, or console screenshots showing the control is enforced in the live environment.

Audit evidence assessors look for

When preparing your Statement of Applicability (SoA) for A.8.28, gather artefacts such as:

  • Secure coding standards document (e.g. OWASP Top 10 coverage)
  • SAST and DAST tool configuration and scan reports
  • Code review records with security findings addressed
  • Secure coding training records for developers

How to implement A.8.28

  1. Adopt a published standard rather than writing your ownOWASP ASVS or the OWASP Top 10 with language-specific guidance gives you a defensible baseline without a drafting project. What matters for the control is that developers have a standard to apply and that it is maintained.
  2. Put the checks in the pipeline, not in a policySAST, dependency scanning and secret detection running in CI produce evidence continuously. A secure coding policy with no automated enforcement is the weakest possible position, because the only evidence is the document itself.
  3. Define what blocks a mergeScanning that reports but never blocks tends to be ignored. Decide which severity fails the build, document the exception route, and keep the exception records — that is where an auditor will look for whether the control has teeth.
  4. Evidence security in code reviewPeer review records that show a security finding raised and resolved are strong evidence. Generic approvals are not. If your review template includes security prompts, the evidence generates itself.
  5. Train developers specificallyGeneral awareness training does not satisfy secure coding. Role-specific developer training, and records of it, closes the loop between this control and A.6.3.

Common audit findings for A.8.28

What actually gets raised against A.8.28, in rough order of how often it comes up:

Scoping A.8.28

A.8.28 applies wherever software is developed, including significant low-code or scripting work. Organisations that only buy software can justify exclusion, but should check the boundary carefully — infrastructure-as-code, integration scripts and data pipelines are development for the purposes of this control, and are commonly overlooked.

How A.8.28 maps to SOC 2 and NIST CSF

If you run more than one framework, the same evidence usually satisfies all of them. A.8.28 aligns with:

SOC 2: CC8.1 Change management

NIST CSF 2.0: PR.PS-06 Secure software development

ISO 27001:2013 mapping

A.8.28 is a new control introduced in the 2022 revision with no direct 2013 equivalent. Treat it as a fresh requirement when transitioning from ISO 27001:2013.

Map A.8.28 to NIST CSF & SOC 2 →
Crosswalk this control in the Control Mapper & Gap Assessment.
Document the risk →
Record treatment for gaps against A.8.28 in the Risk Register.

Related Annex A controls

A.8.4 Access to source code A.8.25 Secure development life cycle A.8.26 Application security requirements A.8.27 Secure system architecture and engineering principles A.8.29 Security testing in development and acceptance A.8.30 Outsourced development

See all 34 Technological Controls →

Frequently asked questions

Is ISO 27001 A.8.28 mandatory?

Annex A controls are not mandatory in the abstract. Clause 6.1.3 requires you to compare your risk treatment plan against Annex A and justify, in the Statement of Applicability, any control you exclude. If your risk assessment surfaces a risk that A.8.28 addresses, excluding it needs a documented, risk-based rationale that an auditor will test.

How do auditors test ISO 27001 A.8.28?

In two passes. First design: does a documented control exist, is it owned, and does it address the risk? Then operating effectiveness: the auditor samples records from across the audit period to confirm the control actually ran. A Stage 2 audit will typically pull several samples, so evidence that only exists for the month before the audit is a common finding.

How often should A.8.28 be reviewed?

ISO 27001 sets no fixed interval — it requires review at "planned intervals" and after significant change. Annual review is the norm most certification bodies expect, with an out-of-cycle review triggered by incidents, major system changes, restructures, or new regulatory obligations. Record the review date and outcome either way; an undated control is treated as unreviewed.

What does ISO 27001 A.8.28 map to in SOC 2 and NIST CSF?

A.8.28 aligns with SOC 2 CC8.1 and NIST CSF PR.PS-06. Evidence gathered for one framework will usually satisfy the others, which is the basis for a test-once, satisfy-many control library.

Is A.8.28 a new control in ISO 27001:2022?

Yes. A.8.28 is one of the 11 controls introduced in the 2022 revision and has no direct ISO 27001:2013 equivalent, so a transitioning ISMS has no prior evidence to re-point and should treat it as a fresh implementation.

What are the most common audit findings for A.8.28?

A secure coding standard that exists but is unknown to the development team. SAST configured to report only, with a backlog of unresolved high-severity findings and no risk acceptance.