ISO 27001 Annex A 8.25

Security has to be built in - retrofit always costs more.

ISO 27001 Annex A 8.25 - Secure Development Life Cycle

The control sets the framework for how security fits into software development. Security activities at every stage of the development lifecycle - threat modelling at design, secure coding during build, security testing before release, monitoring after deployment - cost less than fixing the same issues retrospectively. The control asks for these activities to be defined and applied consistently.

Practical secure development typically combines training (developers know what secure code looks like), tools (linters and security scanners catch issues automatically), processes (security review at defined gates), and culture (security treated as a shared responsibility rather than a separate function). Each element supports the others.

The control sits at the head of a small group of related controls. A.8.26 covers application security requirements, A.8.27 system architecture, A.8.28 secure coding, A.8.29 security testing, A.8.30 outsourced development, and A.8.31 environment separation. Together they describe how security is built into the development of software and systems.

Secure development is hardest to retrofit into an existing development team. Where security has not been part of the culture, adding it is a multi-year programme rather than a tooling exchange. Where the team understands security and has built habits around it, the technical controls add structure to existing practice. The cultural part is what makes the technical part work.

Practical Compliance Guidance

Secure development life cycle is described in the IMS1 manual at section 8.5 alongside the Information Security Policy where development activities are in scope.

alphaZ document How to use it
ISO 27001 Toolkit The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
PP-8-100 Information Security Policy Procedure Contains the Information Security Policy including the development security baseline where applicable. Use as the source for development security governance.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

If the organisation does not develop or modify code, the control may not apply or may apply only to outsourced development arrangements under A.8.30. The position should be documented in the Statement of Applicability with the justification.
Threat modelling at design, secure coding standards under A.8.28, code review with security focus, automated security scanning of code and dependencies, security testing under A.8.29, and operational hardening before release. The exact mix depends on the development pattern.
Through metrics such as time to remediate security findings, density of vulnerabilities found in production versus pre-release, coverage of security testing, and proportion of releases with completed security review. The metrics feed into the wider performance measurement under Clause 9.1.

Further Resources

payment logos