ISO 27001 secure development: Annex A 8.25 to 8.33 as engineering practice and evidence

ISO/IEC 27001 specifies a management system: you define a scope, assess information security risks, choose how to treat them and run a cycle of monitoring, internal audit, management review and improvement. Controls come from risk treatment. You compare the controls you need against Annex A so nothing is overlooked, and the Statement of Applicability records each control's status and reasons. A certification body audits the system in stages, then holds surveillance audits during a three-year certification cycle.

The 2022 edition reorganized Annex A from 114 controls in 14 groups into 93 controls in four themes. Most development controls sit in the technological theme, 8.25 to 8.33, and 8.28 secure coding is one of the 11 new controls. ISO/IEC 27002:2022 explains each control's purpose and gives implementation guidance; both documents are licensed, so the table below paraphrases each control's topic.

The evidence column lists records a certification auditor can sample. The guide column links the practice on this site.

Secure coding became a control of its own in 2022. Read ISO/IEC 27002 for the guidance an auditor will compare against; in engineering terms it comes down to four things you can show. A coding standard for each language you use, written for your frameworks rather than copied from a generic list. Tools that enforce it, such as SAST rules and dependency policies in CI, configured to block. Reviews that check security, with the reviewer independent of the author. And maintenance: findings tracked to closure, and the standard and rules updated when a class of defect keeps appearing.

Evidence that operates beats evidence that describes. A policy saying code is reviewed is weaker than a ruleset export showing review is required, plus a sample of merged changes with their approvals; the change export in /frameworks/soc2-for-engineering-teams/ produces exactly that.

Controls 8.31 and 8.32 are easiest to show when the cloud enforces them. With GitHub Actions and AWS, give production its own account and a deployment role that trusts only jobs running in the repository's production environment, and protect that environment with required reviewers. The OIDC subject claim names the environment, so a job in a development branch or another environment can't assume the role, however its workflow is written. The same idea works with other CI systems and clouds through their workload identity federation.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OnlyTheProductionEnvironmentOfThisRepository",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:example-org/payments-api:environment:production"
        }
      }
    }
  ]
}

Clause 6.1.3 d) asks the Statement of Applicability to list the necessary controls, justify including them, say whether they are implemented and justify excluding any Annex A control. Teams drift when the SoA lives in a document nobody connects to the systems. Keep the development rows as data next to the evidence, and check them in CI: the identifiers exist in the 2022 Annex A, every row has a reason, implemented controls cite evidence, and rows are rechecked within your review interval. The check catches leftover 2013 identifiers such as A.14.2.1, which no longer exist.

{
  "isms_scope": "Development and operation of the Payments API service",
  "standard": "ISO/IEC 27001:2022 Annex A",
  "reviewed_on": "2026-10-10",
  "controls": [
    {
      "id": "8.25",
      "applicable": true,
      "reason": "Risk R-12: vulnerabilities introduced during development",
      "implemented": "yes",
      "evidence": ["ssdf-evidence.csv"],
      "last_checked": "2026-09-30"
    },
    {
      "id": "8.28",
      "applicable": true,
      "reason": "Risk R-12; contractual requirement from enterprise customers",
      "implemented": "yes",
      "evidence": ["rulesets/default-branch.json", "sast/results-2026-09.sarif"],
      "last_checked": "2026-09-30"
    },
    {
      "id": "8.30",
      "applicable": true,
      "reason": "Mobile client built by a contracted agency",
      "implemented": "partial",
      "evidence": ["contracts/agency-security-schedule.pdf"],
      "last_checked": "2026-06-12"
    },
    {
      "id": "8.31",
      "applicable": true,
      "reason": "Risk R-07: changes reaching production without approval",
      "implemented": "yes",
      "evidence": ["iam/prod-deploy-trust-policy.json", "environments/production.json"],
      "last_checked": "2026-09-30"
    },
    {
      "id": "7.10",
      "applicable": false,
      "reason": "No removable storage media in scope; hosting provider handles physical media",
      "implemented": "no",
      "evidence": [],
      "last_checked": "2026-09-30"
    }
  ]
}

The one-year recheck is this team's rule, not the standard's; set it to your internal audit plan. The script prints 5 rows OK for the file above.

"""Check the development rows of a Statement of Applicability before an internal audit.

ISO/IEC 27001:2022 clause 6.1.3 d) asks for the necessary controls, why each is included,
whether it is implemented, and why any Annex A control is excluded. This check adds the team's
own rules: implemented controls cite evidence, and every row was checked within a year.
Usage: python3 check_soa.py soa-development.json
"""

import json
import re
import sys
from datetime import date

THEMES = {"5": 37, "6": 8, "7": 14, "8": 34}  # Annex A: 93 controls in four themes


def valid_id(control_id):
    match = re.fullmatch(r"([5-8])\.(\d{1,2})", control_id)
    return bool(match) and 1 <= int(match.group(2)) <= THEMES[match.group(1)]


with open(sys.argv[1], encoding="utf-8") as f:
    soa = json.load(f)
reviewed = date.fromisoformat(soa["reviewed_on"])

problems = []
for row in soa["controls"]:
    cid = row["id"]
    if not valid_id(cid):
        problems.append(f"{cid}: not an ISO/IEC 27001:2022 Annex A control")
    if not row.get("reason"):
        kind = "inclusion" if row["applicable"] else "exclusion"
        problems.append(f"{cid}: no justification for {kind}")
    if row["applicable"] and row["implemented"] in ("yes", "partial") and not row["evidence"]:
        problems.append(f"{cid}: implemented but no evidence")
    if (reviewed - date.fromisoformat(row["last_checked"])).days > 365:
        problems.append(f"{cid}: last checked {row['last_checked']}, over a year ago")

print("\n".join(problems) or f"{len(soa['controls'])} rows OK")
sys.exit(1 if problems else 0)

The development controls overlap heavily with other frameworks, so collect the evidence once. An SSDF evidence matrix serves 8.25 to 8.29; the change population that answers SOC 2 CC8.1 also answers 8.32; vulnerability management records serve 8.8, SOC 2 CC7.1 and CRA Annex I Part II. Overlap is not equivalence: a SOC 2 report doesn't certify an ISMS, and an ISO certificate doesn't give a product the CRA's conformity assessment. /frameworks/compliance-evidence-reuse/ shows the mapping and /frameworks/control-mapping-and-evidence/ how to state each relationship without overclaiming.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. ISO/IEC 27001:2022 Information security management systems: Requirements. Edition 3 (October 2022).
2. ISO/IEC 27002:2022 Information security controls. Edition 3 (February 2022).
3. ISO/IEC 27001:2022/Amd 1:2024 Climate action changes. February 2024.
4. IAF MD 26:2023, transition requirements for ISO/IEC 27001:2022. Issue 2 (15 February 2023).
5. GitHub Docs: configuring OpenID Connect in Amazon Web Services
6. GitHub Docs: OpenID Connect reference (subject claims for environments)
7. GitHub Docs: deployments and environments, required reviewers

Reference information

Tags

Secure development lifecycleCompliance and assurance evidence

SDLC phase

Security program

Role

Platform engineers and SREsSecurity leaders

Download this guide as Markdown

Continue exploring