ISO 27001 A.8.25 - Secure Development Life Cycle

Requirement

“Rules for the secure development of software and systems shall be established and applied.”

Plain-language meaning

Development work should follow secure rules from the beginning. This applies to software, services, networks, infrastructure, environments, and systems that are built or changed by the organization or its suppliers.

The control is not only about writing secure code. It also covers development environments, developer competence, standards, vulnerability handling, third-party developers, secure code review, and regular review of the development rules.

Why this matters

Weak development practices can introduce vulnerabilities, hidden functionality, insecure defaults, poor access control, dependency weaknesses, or production-impacting defects. A compromised development environment can also become a path into future production systems.

Secure development also protects intellectual property in code, designs, tooling, test data, and development environments.

Implementation guidance

1. Define secure development rules

Define rules for secure coding, secure configuration, dependency use, secrets handling, code review, testing, vulnerability remediation, release gates, development environment protection, and development tool access.

2. Apply rules to all development work

Apply the same secure development expectations to internal teams, contractors, outsourced developers, and supplier-built systems where they affect the organization.

3. Train developers and reviewers

Developers, reviewers, DevOps engineers, architects, and testers should understand the secure development practices relevant to their role.

4. Verify compliance

Use peer review, secure coding audits, automated scanning, manual review, dependency scanning, and release checks. Automated tools help, but they do not replace standards, competence, and independent review.

5. Review and improve standards

Secure development standards should be reviewed when threats, public standards, technology, frameworks, incidents, or vulnerability patterns change.

Audit guidance

Auditors should verify:

• secure development policy or standard exists;
• standards are suitable to the risk profile;
• developers and reviewers are trained and competent;
• adherence is mandated and checked;
• secure coding audits or reviews are performed by competent people;
• reviews are not performed only by the same people who wrote the code;
• automated tools are used appropriately but not treated as the whole control;
• vulnerabilities and nonconformities are followed up and resolved;
• third parties and contractors follow the same rules;
• secure development standards are periodically reviewed and improved.

Evidence examples

Strong evidence

• Secure development rules are integrated into project/release workflows.
• Secure coding and review evidence exists for sampled projects.
• Findings are tracked to closure.
• Contractors and suppliers are covered by the same requirements.
• Reviewers are competent and independent enough for the risk.
• Standards are updated after incidents, technology changes, or public guidance changes.

Weak evidence

• Secure coding guidelines exist but are optional.
• Developers are expected to “know security” without training.
• Tools run but findings are ignored.
• Reviews are done only by the code author.
• Supplier development is not checked.
• Standards are stale and do not match current languages or frameworks.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.4 Access to Source Code
• A.8.8 Management of Technical Vulnerabilities
• A.8.19 Installation of Software on Operational Systems
• A.8.26 Application Security Requirements
• A.8.27 Secure System Architecture and Engineering Principles
• A.5.8 Information Security in Project Management
• A.5.20 Addressing Information Security Within Supplier Agreements
• Risk Assessment
• Statement of Applicability
• Secure Development Policy
• Secure Development Compliance Review Checklist
• Secure Code Review Record
• Developer Security Training Matrix
• A.8.25 Audit Evidence Pack
• A.8.25 Audit Checklist

KB-ready summary

• Define secure development rules.
• Train developers and reviewers.
• Apply rules to internal and supplier work.
• Verify compliance through reviews and audits.
• Track vulnerabilities to closure.
• Review standards regularly.

Templates and checklists

• Secure Development Policy
• Secure Development Compliance Review Checklist
• Secure Code Review Record
• Developer Security Training Matrix
• A.8.25 Audit Checklist