Secure Development Controls in ISO 27001: A.8.25–A.8.28 Explained

Most ISO 27001 content is written for compliance people. Controls A.8.25 through A.8.28 are the exception: they're written about your engineering team. They govern how software gets designed, written, and shipped — and if your company builds a product, these four controls carry a disproportionate share of your audit.

They're also where startups have a quiet advantage. A disciplined modern development workflow already implements most of what these controls demand. The gap is almost never the practice; it's the paper trail. Let's go through each control: what it says, what it means, and what evidence actually satisfies an auditor.

Where these controls sit

The 2022 revision of ISO/IEC 27001 restructured Annex A into 93 controls across four themes; A.8 is the technological theme, and the secure development cluster runs from A.8.25 to A.8.34. This guide covers the four core ones — the surrounding controls (security testing A.8.29, outsourced development A.8.30, environment separation A.8.31, change management A.8.32) plug into the same life cycle and get a brief mention at the end.

One framing note: Annex A controls apply through your risk treatment and Statement of Applicability. In principle you can exclude a control with justification — but for a company whose product is software, excluding secure development controls is close to impossible to defend. Assume all four are in scope.

A.8.25 — Secure development life cycle

What the control requires: rules for the secure development of software and systems shall be established and applied.

This is the umbrella control: it asks whether you have a defined way of building software that has security built into it, rather than security as an occasional afterthought. "Established and applied" is the key pair — you need documented rules, and your actual development activity has to match them.

What it looks like in practice: a secure development policy (or SDLC section in a broader policy) that describes your workflow end to end: how work is specified, how code is reviewed, what automated checks run before merge, how releases reach production, and where security touches each stage. It doesn't have to be long. It has to be true.

Evidence auditors accept: the SDLC policy itself; branch protection settings showing the enforced workflow; a sampled pull request demonstrating the documented flow (review, passing checks, approval before merge). Auditors love this control because it's cheap to test: they read your policy, then look at your repository settings and see whether the two agree.

A.8.26 — Application security requirements

What the control requires: information security requirements shall be identified, specified and approved when developing or acquiring applications.

Two things founders miss here. First, this control is about the requirements phase — before code exists. When you plan a new feature or system, security requirements (authentication, authorization, data protection, logging, input validation) should be considered alongside functional ones, and someone should approve them. Second, "or acquiring" pulls in the software you buy: when you adopt a new SaaS tool or third-party component that touches sensitive data, the same requirement-setting applies.

Evidence auditors accept: a security requirements checklist or template used in feature planning; tickets or design docs for sampled features showing security requirements were specified and approved; for acquired software, vendor assessment records showing security requirements were evaluated before adoption. If your issue tracker has a "security considerations" section in the feature template, you're most of the way there.

A.8.27 — Secure system architecture and engineering principles

What the control requires: principles for engineering secure systems shall be established, documented, maintained and applied to any information system development activities.

This is the control most likely to exist entirely in your senior engineers' heads. Every experienced team applies principles like least privilege, defense in depth, secure defaults, minimizing attack surface, and failing securely — but A.8.27 requires them documented and maintained, not just practiced. The word "maintained" matters too: a principles document written once in 2023 and never revisited invites the follow-up question of how it's kept current.

Evidence auditors accept: a written set of secure engineering principles (one or two pages is genuinely fine); architecture or design review records showing the principles being applied to real decisions; review dates or version history showing the document is alive. If you run design reviews for significant changes, adding a line referencing the principles turns existing practice into evidence.

A.8.28 — Secure coding

What the control requires: secure coding principles shall be applied to software development.

A.8.28 is one of the controls newly introduced in the 2022 revision — it didn't exist as a standalone control in the 2013 version, so guides written against the old standard skip it entirely. It moves one level down from A.8.27: not how systems are designed, but how code is written. The expectation is a secure coding standard covering things like input validation, output encoding, secrets handling, error handling, and use of vetted libraries — plus mechanisms that enforce it.

What it looks like in practice for a startup: you rarely need to write a coding standard from scratch. Adopting an established reference — the OWASP secure coding practices are the usual anchor — and documenting your enforcement stack covers the substance: static analysis or linters in CI, dependency vulnerability scanning, secret scanning, and code review that includes security. Developer awareness counts too: secure coding expectations should appear somewhere in onboarding or training.

Evidence auditors accept: the documented coding standard (or the adopted reference plus your additions); CI configuration showing the automated checks; a sampled pull request where a scanner or reviewer caught an issue and it was fixed; training or onboarding records referencing secure coding.

The neighbors, briefly

Four adjacent controls complete the life cycle and usually get audited in the same session: A.8.29 (security testing in development and acceptance — your test suites, and penetration testing if your risk treatment calls for it), A.8.30 (outsourced development — if contractors or agencies write code for you, the same rules and oversight must reach them), A.8.31 (separation of development, test and production environments), and A.8.32 (change management — for most startups, satisfied by the same PR-based workflow as A.8.25, documented once and referenced twice).

Where audits actually go wrong here

The recurring nonconformities in this cluster are all documentation-versus-reality gaps:

• The policy describes a process the repo doesn't enforce. The SDLC policy promises mandatory review, but branch protection is off and a sampled merge shows a self-approved commit to main. This is the classic finding — auditors check settings, not intentions.
• No written secure coding standard. The team writes careful code, CI runs scanners, but nothing documents the expectation — so A.8.28 fails on the "principles" half despite good practice.
• Principles that exist only as culture. A.8.27 needs a document. "Our senior engineers know this" is an honest answer and an audit finding at the same time.
• Acquired software skipping the requirements step. New vendors and components adopted without any recorded security evaluation — the "or acquiring" clause of A.8.26 that nobody read.

The bottom line

A.8.25–A.8.28 reward teams for what they already do and punish them only for not writing it down. Document your real SDLC, adopt a secure coding reference, put your engineering principles on one page, add a security line to your feature template — then make sure the repository settings enforce what the documents claim. Do that, and the secure development cluster becomes evidence you generate automatically with every merge, which is exactly the kind auditors accept without argument. If you're building out the rest of your ISMS around it, the full Annex A guide covers all 93 controls, and the internal audit guide shows how to test this cluster yourself before your auditor does.