ISO 27001 A.8.28 — Secure coding

A.8.28 applies to anyone who writes or commissions software — including a two-developer product team. It asks for secure coding principles that are defined, applied and checked, not a formal AppSec programme.

Michael McCarroll 6 min read Updated August 2026

What the control says

Secure coding principles shall be applied to software development. That spans planning (standards and training), during coding (review, static analysis, dependency management) and after release (patching, vulnerability handling).

Theme: Technological · New in ISO 27001:2022

Why it matters

If you sell software, this is the control your enterprise buyers read most closely in your Statement of Applicability. It is also where a small team can score well cheaply — most of the expected practice is already in a modern CI pipeline.

Write a one-page secure coding standard, enforce pull-request review in the repository, turn on the dependency and secret scanning your Git host already provides, and keep the evidence those tools generate.

How to implement it

  1. Publish a short secure coding standard: input validation, output encoding, authentication and session handling, secrets management, error handling and logging, dependency policy.
  2. Reference a recognised source such as the OWASP Top 10 or ASVS rather than writing your own catalogue of vulnerabilities.
  3. Enforce peer review through branch protection so no change reaches production unreviewed.
  4. Enable automated checks in CI: static analysis, software composition analysis for dependencies, and secret scanning.
  5. Define how vulnerability findings are triaged and how quickly each severity must be fixed, and track them like any other action.
  6. Give developers secure coding awareness at least annually and keep the attendance record.

Evidence auditors ask for

  • The secure coding standard, versioned and dated
  • Branch protection settings and a sample of reviewed pull requests
  • CI pipeline configuration plus recent scan output
  • Dependency and secret scanning alerts with their remediation history
  • Developer training records
  • Evidence for outsourced development where relevant (A.8.30)

Common findings

  • A standard exists but pull requests are merged without review, so the control is not operating.
  • Scanning enabled with a backlog of unaddressed high-severity findings and no triage record.
  • Secrets committed to repositories with no scanning or rotation process.
  • Outsourced development excluded from the control despite third parties shipping production code.

Related controls

  • A.8.25 Secure development lifecycle
  • 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
  • A.8.31 Separation of development, test and production environments

See the full list of all 93 Annex A controls or start from the Statement of Applicability template.

FAQ

Does A.8.28 apply if we do not build software?
If nobody in the organisation writes code — including scripts, automations and low-code applications that process your information — you can exclude it, but the justification must be explicit in the Statement of Applicability. Most organisations write more code than they think.
Do we need a penetration test to satisfy secure coding?
Penetration testing sits mainly under A.8.29 security testing. A.8.28 is about how the code is written and reviewed. Most software vendors do both because buyers ask for the test report.
Is using AI coding assistants a problem for A.8.28?
Not in itself, but your standard should say how AI-generated code is reviewed and how you prevent proprietary code or secrets being pasted into third-party tools. Auditors have started asking about this specifically.

Evidence A.8.28 without the spreadsheet

ISO-STANDARD.app ships all 93 Annex A controls pre-loaded, linked to your risks, evidence and owners — with an AI 'Fix this' plan for anything failing.

ISO-STANDARD.app ships a ready-to-adopt ISO 27001 workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.

Free downloads for this topic

Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.

Related guides
Trust & security
ISO 27001 aligned
Controls mapped to Annex A
Encryption in transit & at rest
TLS 1.3 · AES-256
MFA enforced
TOTP required for all admins
GDPR & UK GDPR
DPA on request · EU/UK data
SOC 2 ready posture
Audit-grade logging
RLS-isolated tenants
Row-level data separation
← All guidesHome →