A.8.25
Secure development life cycle
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Establish and apply rules for the secure development of software and systems.
Points of focus
- Security checkpoints are defined at each SDLC stage: planning, design, build, test, release
- Threat modeling or design review happens for features touching authentication, authorization, or customer data
- Security requirements and testing gates are enforced in CI/CD, not left to individual judgment
- Security champions or a designated reviewer participate in higher-risk feature work
- The lifecycle is documented well enough that a new engineer can follow it without tribal knowledge
Implementation notes
Define what 'secure' means at each stage of your actual development process rather than importing a generic SDLC framework wholesale. At planning, require security and privacy requirements to be captured alongside functional requirements for any feature touching authentication, authorization, payments, or customer data (this is where A.8.26 lives). At design, run lightweight threat modeling — even a 30-minute structured conversation using STRIDE or a simple 'what could go wrong' checklist — for features that cross a trust boundary, and require sign-off from a security champion or senior engineer for anything higher-risk (A.8.27). At build, enforce secure coding standards and automated scanning as required CI checks that block merges rather than warn (A.8.28). Before release, run security testing appropriate to the change's risk — automated DAST/SAST for routine changes, manual review or penetration testing for higher-risk ones (A.8.29). Make the connective tissue explicit: a single page or diagram showing which control applies at which stage, linked from your engineering onboarding docs, so the lifecycle survives team growth and doesn't live only in a few senior engineers' heads. Track exceptions — when a gate was bypassed and why — as a defined, auditable process rather than letting bypasses happen silently under deadline pressure.
Audit tip: Trace one real feature from ticket to production: show the design doc or ticket with security requirements noted, the pull request with a passing security gate, and (if applicable) a design or threat-modeling review artifact. A single coherent trace is more convincing than five separate stage-specific policies.
Evidence auditors typically request:
- SDLC policy or engineering handbook page mapping security activities to each development stage
- A sampled feature's design doc or ticket showing a threat-modeling or security-review checklist completed
- CI/CD pipeline configuration showing security gates (SAST, dependency scan, tests) as required checks
- Security champions program roster or a record of security office hours / design reviews attended
- A blocked or rejected pull request/release showing a security gate actually stopped a deploy
Common gaps
- A security checklist exists in the wiki but engineers ship features without ever opening it, and no ticket or PR references it
- Threat modeling is required 'for major features' but there's no definition of what counts as major, so it's applied inconsistently or not at all
- CI security gates exist but are configured to warn rather than block, so failing checks are routinely ignored under deadline pressure
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.8.25 | This control |
| SOC 2 | CC8.1 | Related Trust Services Criteria themes — map in your crosswalk; not identical requirements. |
| GDPR | Article 25 | Related GDPR articles for personal-data security or processor themes — not a compliance claim. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.25)