Skip to content
AuditFront
A.8.25 ISO 27001

ISO 27001 A.8.25: Secure development life cycle

What This Control Requires

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

In Plain Language

Finding a critical vulnerability in production is expensive, embarrassing, and sometimes catastrophic. Finding it during design costs almost nothing. That is the core argument for a secure development lifecycle - building security into every phase rather than bolting it on at the end with a penetration test.

A proper SDLC means security requirements sit alongside functional requirements from day one. Threat modelling happens during design. Secure coding standards are enforced during development. Automated security testing runs in your CI/CD pipeline. And vulnerabilities found after release are handled through a clear process.

This applies to software you build in-house and anything developed by third parties on your behalf. The specific practices should fit your methodology - whether that is agile, DevOps, or something else - but the principles are the same.

How to Implement

Build a secure SDLC framework that fits your development methodology. For agile and DevOps teams, this means DevSecOps - weaving security activities into sprints and the CI/CD pipeline.

During requirements gathering, identify security requirements alongside functional ones. Run abuse case analysis to spot potential misuse scenarios. Define security acceptance criteria. Pin down compliance obligations (data protection, industry regulations).

At the design stage, conduct threat modelling to identify threats and design countermeasures. Apply secure design principles: defence in depth, least privilege, fail secure, separation of duties. Review the architecture for weaknesses. Define security patterns for common functions like authentication, authorisation, and session management.

During development, enforce secure coding standards (OWASP Secure Coding Practices). Use vetted security libraries instead of rolling your own crypto or auth. Run peer code reviews with a security lens. Use IDE security plugins and linters. Manage dependencies with software composition analysis.

For testing, run SAST in the CI/CD pipeline. Conduct DAST against running applications. Perform SCA for dependency vulnerabilities. Do manual penetration testing for critical applications. Validate that every security requirement has been met.

At deployment, use hardened configurations. Automate deployment through CI/CD. Verify deployment integrity. Strip out debug code and development artefacts. Configure security headers and protections.

Post-release, monitor for new vulnerabilities in your libraries and frameworks. Have a coordinated disclosure process for external reports. Apply security patches promptly. Run periodic security assessments of deployed applications.

Train your developers on secure coding. Cover the OWASP Top 10, secure practices for their specific language and framework, and your internal standards. Refresh the training regularly as the threat landscape shifts.

Evidence Your Auditor Will Request

  • Secure SDLC framework documentation
  • Threat modeling records for recent development projects
  • SAST and DAST scan results from CI/CD pipeline
  • Secure code review records
  • Developer security training records

Common Mistakes

  • No formal secure SDLC exists and security is only addressed through testing at the end
  • Threat modeling is not conducted during the design phase
  • Automated security testing (SAST, DAST) is not integrated into the CI/CD pipeline
  • Developers have not received secure coding training
  • Third-party development is not subject to the same security requirements

Related Controls Across Frameworks

Framework Control ID Relationship
SOC 2 CC8.1 Equivalent
GDPR Art.25 Related
NIS2 Art.21(2)(e) Partial overlap

Frequently Asked Questions

How do we integrate security into agile development?
Add security user stories to the backlog. Run threat modelling during sprint planning. Integrate SAST and SCA into your CI/CD pipeline so they run automatically. Include security review in the definition of done. Appoint security champions on each team. Run DAST against sprint deployments. Treat security findings as sprint work, not a separate backlog. The point is to make security continuous rather than a gate that slows everything down.
What security testing tools should we use in our pipeline?
A solid pipeline typically includes: SAST for source code analysis (SonarQube, Checkmarx, or Semgrep), SCA for dependency scanning (Snyk, Dependabot, or OWASP Dependency-Check), DAST for runtime testing (OWASP ZAP or Burp Suite), container image scanning, IaC scanning for infrastructure code (Checkov, tfsec), and secrets detection to catch credential leaks before they hit the repo. You do not need all of these on day one - start with SAST and SCA and build from there.

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment