Secure development life cycle
Purpose
Establish and apply rules so that security is built into the whole lifecycle of developing software and systems.
How to meet this control
In short: Establish and apply rules for secure development of software and systems.
- Step 01Document a secure development lifecycle that separates development, test and production and embeds security at each stage
- Step 02Adopt secure coding standards per language and reference them at developer onboarding
- Step 03Capture security requirements in specifications and set security checkpoints or gates within the pipeline
- Step 04Build security testing into CI, including static analysis, dependency scanning and periodic penetration testing
- Step 05Manage source in secure repositories with version control, branch protection and secret scanning
- Step 06Where development is outsourced, obtain assurance the supplier follows equivalent secure development rules
Tip: Document your secure SDLC and reference it in onboarding.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Separate development, test and production environments
- ›Build security into the development methodology and use secure coding guidelines per language
- ›Capture security requirements in specification and design and set security checkpoints
- ›Carry out system and security testing such as regression testing, code scanning and pen tests
- ›Use secure repositories for source code and configuration and apply version control security
- ›Ensure developers have the application security knowledge, training and skills
- ›Consider licensing requirements to keep solutions cost-effective
- ›When development is outsourced, obtain assurance the supplier follows secure development rules
Audit evidence to keep
- - Documented secure development lifecycle or SDLC policy
- - Secure coding standards referenced in onboarding
- - CI pipeline configuration showing security gates
- - Evidence of separated development, test and production environments
- - Records of security testing across the lifecycle
Common mistakes
- - Treating security review as optional when release pressure rises
- - Testing only happy paths and missing abuse cases
- - Not linking production changes to approvals and rollback plans
Owner, cadence, and proof
Assign one accountable owner for A.8.25. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.