8.25 Secure development life cycle
The organization is to set and apply rules for developing software and systems securely. Purpose: have security designed and built in as software and systems are developed. Guidance: secure development is the basis to produce secure services, architectures, software and systems, so consider: keeping development, test and production environments separate (8.31); guidance on security in the development life cycle, covering security in the development methodology (8.27, 8.28) and secure coding guidelines for every programming language used (8.28); security requirements at specification and design (5.8); security checkpoints within projects (5.8); testing of the system and its security, for example regression tests, code scans and penetration tests (8.29); protected repositories holding code and configuration (8.4, 8.9); security in version control (8.32); the application security knowledge and training required (8.28); developers' ability to prevent, find and fix vulnerabilities (8.28); and licensing requirements and alternatives that keep solutions cost-effective and avoid later licensing problems (5.32). Where development is outsourced, obtain assurance that the supplier follows the organization's secure development rules (8.30). Other information: development also happens inside applications such as office tools, scripts, browsers and databases.
Source: ISO/IEC 27002:2022, 8.25. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Project records showing security checkpoints or gates passed · Source control / CI pipeline
- Security testing outputs such as static analysis, regression and penetration test results · Vulnerability scanner / patch tooling
- Developer security training records and competence expectations · HR system / LMS
- Evidence of assurance that outsourced developers follow the rules, and of licence checks on components · Source control / CI pipeline
governing documentDocuments that govern the control
- Documented secure development rules or SDLC standard covering environments, methodology, coding guidelines, security requirements, checkpoints, testing, repositories and version control · Policy repository / GRC workspace
- Secure coding guidelines for each language in use · Policy repository / GRC workspace
First move
Common gaps auditors find
- The SDLC standard exists but projects skip the security gates under schedule pressure
- Coding guidelines cover only one language while several are used
- Low-code, scripting and spreadsheet development fall outside the rules
- Outsourced development is accepted without any evidence of secure practices
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet8.24 Use of cryptography · 8.26 Application security requirements