Secure development life cycle

What the control asks

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.

Purpose in the standard’s terms, in our words: Builds security into software and systems from design through implementation.

Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Protect; Application security, System and network security; Protection.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• Documented secure development rules or SDLC standard covering environments, methodology, coding guidelines, security requirements, checkpoints, testing, repositories and version control
• Secure coding guidelines for each language in use
• Project records showing security checkpoints or gates passed
• Security testing outputs such as static analysis, regression and penetration test results
• Developer security training records and competence expectations
• Evidence of assurance that outsourced developers follow the rules, and of licence checks on components

Where audits commonly find gaps

• 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

What ISO/IEC 27028 changes for this control

It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 2 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (14.2.1) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 8.18 Use of privileged utility programs
• 8.26 Application security requirements
• 8.27 Secure system architecture and engineering principles

Read the five attributes All 93 controls