ISO 27001 Control 8.25: Secure Development Life Cycle
How to Build Security into the Way You Write and Change Software
ISO 27001 Control 8.25 Secure development life cycle is all about how you build and change systems – not just the end result.
If you’re writing code, configuring cloud platforms as “infrastructure as code”, building low-code apps, or even creating complex scripts and automations, this control expects you to treat development as a disciplined, security-aware process. It’s not enough to “do a pen test at the end” and hope for the best.
Control 8.25 wants you to embed security into:
- Your development methods (Agile, DevOps, Waterfall, whatever you actually use)
- Your environments (development, test, production)
- Your coding practices and tooling
- Your testing and release process
- Your people (training, awareness, roles)
- Your suppliers (if any development is outsourced)
This guide walks through what ISO 27001 Control 8.25 really asks for, and how to implement a secure development life cycle (SDLC) in a way that developers can actually live with.
What ISO 27001 Control 8.25 Actually Requires
In plain English, ISO 27001 Control 8.25 – Secure development life cycle expects you to:
- Define how development is done in your organisation, including security activities.
- Keep development, test and production separated, with proper access control.
- Build security requirements and design into your normal development workflow.
- Use secure coding practices, not just “it compiles, ship it”.
- Include security testing and checkpoints alongside functional testing.
- Secure your repositories and version control systems.
- Ensure developers (including suppliers) are trained and aware of security expectations.
- Manage licensing and third-party components sensibly and securely.
The control applies to all types of development – not only big bespoke applications. That includes:
- Web and mobile apps
- APIs and integrations
- Cloud infrastructure templates (Terraform, ARM, CloudFormation, etc.)
- Scripts, macros and automations that handle important data or processes
- Low-code / no-code solutions where they’re business-critical
- Embedded and IoT software where relevant
Step 1 – Be Clear About Where Development Happens
Before you can secure a development life cycle, you need to know what counts as development in your organisation.
Make a list of:
- Teams that build or customise software, reports, scripts or integrations
- Key systems they work on (internal, customer-facing, cloud, on-premises)
- Tools they use (IDEs, CI/CD platforms, source control, issue trackers, low-code platforms)
For ISO 27001 Control 8.25, you want to be able to say:
“These are our development activities, and this is the secure development approach that applies to them.”
If some work is done by suppliers, note that too – we’ll come back to it.
Step 2 – Separate Development, Test and Production Environments
This is one of the most visible parts of a secure SDLC: dev, test and prod must not be a blurry mess.
You should:
- Maintain separate environments
– Development: where coding and experimentation happen.
– Test/staging: where integrated changes are tested.
– Production: where live users and real data sit. - Control access separately
– Not everyone who can access development should automatically have access to production.
– Admin or deployment rights to production should be limited and well-controlled. - Restrict data movement
– Avoid copying live production data into dev/test unless absolutely necessary.
– If you must, anonymise or mask sensitive fields where you can. - Monitor and log changes
– Log deployments and configuration changes in each environment.
– Ensure you can trace “who changed what, and when”.
This separation reduces the risk of:
- Accidental data exposure in non-production environments
- Debug tools and insecure settings leaking into production
- Developers bypassing controls by “quickly fixing it directly in prod”
Step 3 – Build Security into Your Development Method
Whatever delivery style you use (Agile, DevOps, Waterfall, something homegrown), ISO 27001 Control 8.25 expects security activities to be part of it, not bolted on at the end.
Think in terms of stages:
Requirements
- Capture security and privacy requirements alongside functional ones.
- Use data classification and risk assessments to drive security needs (e.g. encryption, logging, access controls).
Design
- Apply security principles: least privilege, defence-in-depth, secure defaults.
- Conduct basic threat modelling for non-trivial systems:
– What could go wrong?
– How could data be abused or exfiltrated?
– What happens if a component is compromised?
Build
- Follow secure coding standards (see next section).
- Make code review and automated checks normal, not exceptional.
Test
- Include security testing alongside functional and performance tests:
– Static analysis (SAST)
– Dependency checks
– Dynamic testing (DAST) where appropriate
Release / deployment
- Use approved deployment pipelines rather than manual one-off scripts.
- Include security sign-off criteria (e.g. “no high-severity findings unresolved”).
Maintenance
- Apply security updates and library upgrades as part of normal work.
- Re-assess security when making significant changes to architecture or functionality.
The key point: developers shouldn’t have to guess when security matters – it should be clearly built into the way work is planned and tracked (user stories, tasks, definition of done, etc.).
Step 4 – Define and Enforce Secure Coding Practices
Secure development is impossible without secure coding.
Your secure coding guidance should cover:
- Input validation and output encoding
– Treat all input as untrusted.
– Use parameterised queries to prevent SQL injection.
– Encode output appropriately to prevent cross-site scripting and similar issues. - Authentication and session management
– Use standard, well-tested authentication components where possible.
– Never roll your own password storage or crypto. - Authorisation
– Enforce access control at the server side, not just in the UI.
– Use role-based or attribute-based access patterns where applicable. - Error handling and logging
– Don’t leak stack traces, internal paths or sensitive data in error messages.
– Log meaningful events for security (auth failures, access denials, key system actions) in a structured way. - Secrets management
– No hard-coded passwords, keys or tokens in source code.
– Use secret stores, environment variables and secure configuration management. - Third-party libraries and dependencies
– Track what you use.
– Scan for known vulnerabilities and update regularly.
To support ISO 27001 Control 8.25, back this up with:
- Code reviews or pull requests as standard practice.
- Automated static code analysis in the pipeline where feasible.
- Language/framework-specific guidelines (e.g. OWASP guidance for web apps).
Step 5 – Make Security Requirements and Design Explicit
Rather than “we’ll worry about security later”, ISO 27001 Control 8.25 expects you to spell it out early.
Practical ways to do this:
- Include security requirements in specs and user stories
– E.g. “This endpoint must only be accessible to role X”, “All audit records must be immutable”, “All personal data fields must be encrypted at rest”. - Document key design decisions
– Why you chose a particular authentication approach.
– How you’re handling sensitive data in the architecture.
– Which external services you depend on and how they are secured. - Perform simple threat modelling for significant features
– Identify main data flows and potential attackers.
– Decide which controls mitigate those risks (auth, logging, rate-limiting, input validation, etc.).
This gives you a clear line from risk → requirement → design → implementation, which is exactly what auditors like to see under Control 8.25.
Step 6 – Add Security Checkpoints and Testing to the SDLC
Security shouldn’t be a surprise at go-live. Build checkpoints into the lifecycle:
- Security reviews at key milestones
– Design review for high-risk systems or changes.
– Pre-release review for major versions. - Automated security testing in CI/CD
– Static analysis (SAST) on code.
– Dependency scanning (software composition analysis).
– Container image scanning where relevant. - Manual and specialist testing where justified
– Targeted penetration testing of high-risk or externally exposed systems.
– Fuzz testing for critical parsers, file handlers or protocol implementations. - Tracking and remediation
– Log security findings (from tools or reviews) in your normal work tracking system.
– Prioritise and fix based on risk, and re-test where necessary.
Define minimum security gates – for example:
- No critical or high-severity security issues outstanding before production release.
- No use of banned libraries or deprecated protocols.
This turns ISO 27001 Control 8.25 into something that’s visible and measurable, not just aspirational.
Step 7 – Secure Repositories and Version Control
Your source code is itself a sensitive asset. Control 8.25 explicitly expects you to manage it securely.
Good practice includes:
- Private repositories with access control
– Only authorised users and service accounts can access code.
– Use groups/teams aligned to projects and roles. - Strong authentication
– Multi-factor authentication (MFA) for repository access.
– SSH keys or secure tokens instead of plain passwords. - Branch protection and review rules
– Require pull requests for changes to main branches.
– Require review and, where appropriate, status checks (tests, scans) to pass before merge. - Commit hygiene
– Avoid committing secrets; use automated scanning to catch accidental exposures.
– Consider signed commits for higher-assurance environments. - Logging and audit trails
– Keep logs of who changed what, and when.
– Retain history for investigations and compliance. - Dependency and licence management
– Track open-source and third-party components and their licences.
– Use tools to flag licence conflicts and known vulnerabilities.
This gives you a strong story around integrity and traceability of your software – another key point under ISO 27001 Control 8.25.
Step 8 – Train Developers and Manage Outsourced Development
People are at the heart of secure development.
Developer training and awareness
Make sure developers, testers and DevOps engineers understand:
- Common vulnerabilities (e.g. OWASP Top 10) and how to avoid them.
- Your own secure coding standards and cryptography guidance.
- How to handle secrets, credentials and sensitive data.
- How to use the security tools you’ve provided (scanners, secret stores, etc.).
- How to recognise and respond to potential security incidents.
Short, regular, practical training is usually more effective than one long annual session.
Outsourced or third-party development
If you outsource any development:
- Embed secure development requirements in contracts and SLAs
– Reference your secure development life cycle expectations.
– Require adherence to your coding standards where applicable. - Ask for evidence
– Security testing results, code review practices, certifications where relevant. - Review delivered code and artefacts
– Run your own scans and tests on third-party components.
– Check that repositories, pipelines and secrets are not exposed.
For ISO 27001 Control 8.25, the key thing is that suppliers are held to the same standard you apply internally.
Quick Implementation Checklist for ISO 27001 Control 8.25
Use this to review your secure development life cycle:
- ISO 27001 Control 8.25 (Secure development life cycle) is described in a documented SDLC / engineering process.
- Development, test and production environments are separated, with appropriate access controls and data-handling rules.
- Security requirements are captured early (requirements/design), not just at go-live.
- Secure coding standards exist and are known by developers.
- Code is subject to review and, where feasible, static analysis and dependency scanning.
- Security testing (automated and, where appropriate, manual) is built into the SDLC and CI/CD pipelines.
- Source code repositories and version control are access-controlled, audited, and protected by MFA, with sensible branch protection rules.
- Developers and engineers receive regular security training relevant to their work.
- Outsourced development is covered by contractual security requirements, and deliverables are subject to your own checks.
- There is a process to track and fix security findings, with minimum security gates for release.
Bringing It All Together
ISO 27001 Control 8.25 – Secure development life cycle – is about moving from “we’ll think about security later” to “security is part of how we build things here”.
If you:
- Define a clear secure development approach,
- Separate environments properly,
- Embed security into your methods, coding standards and pipelines, and
- Support developers and suppliers with training, tools and clear expectations,
you’ll reduce vulnerabilities, lower the cost of fixing issues, and be in a strong position to show an auditor that secure development is a normal, everyday part of how your organisation delivers change – not an afterthought.
Explore the ISO 27001 Controls