ISO 27001 control 8.25: what it requires on secure development and what evidence the auditor reviews
By Kike Gandia · Co-Founder & CEO, OSCP · Last updated:
The 2022 version of ISO 27001 groups several software development controls in Annex A, and the first is 8.25: secure development life cycle. If your company develops software and is getting certified, or if your clients are certified and audit you as a supplier, these controls set the terms of the conversation. This guide explains what 8.25 says, how it relates to the controls around it and which evidence is usually requested.
What control 8.25 says
Control 8.25 requires rules for the secure development of software and systems to be established and applied. It is a process control: it does not require a specific tool, but that the organization has defined rules, applies them and can prove it.
The implementation guidance is in ISO/IEC 27002:2022, which proposes, among other things, separating environments, building security into the development methodology, using secure coding guidelines, including security requirements in specification and design, setting security checkpoints in projects, testing, protecting repositories and managing versions.
The development controls, in a table
| Control | Name | What the auditor usually asks for |
|---|---|---|
| 8.25 | Secure development life cycle | A secure development policy or procedure and evidence that it is followed |
| 8.26 | Application security requirements | Security requirements identified and approved in projects |
| 8.27 | Secure system architecture and engineering principles | Documented and applied secure design principles |
| 8.28 | Secure coding | Secure coding guide, code review and dependency control |
| 8.29 | Security testing in development and acceptance | Security test plan and its results, including the pentest |
| 8.30 | Outsourced development | How development done by a third party is directed, monitored and reviewed |
| 8.31 | Separation of development, test and production environments | Separate environments and access control to each |
In an audit these controls are looked at together: 8.25 is the umbrella and the rest are the pieces that prove the process works.
Evidence that usually works
- A secure development procedure, short and real: what is done in each phase, who does it and what is recorded.
- Security requirements in projects, for example referencing an OWASP ASVS level.
- Code reviews visible in the repository, with the checklist used.
- Pipeline results: dependency, secret and static analysis, with approved exceptions.
- Pentest and retest reports for major releases.
- Environment separation and control over who accesses production.
- Training of the team in secure development.
The usual mistake is writing an ambitious procedure that nobody follows. An auditor prefers a modest process with evidence to a perfect one without it.
If your client is certified: control 8.30
Control 8.30 obliges the certified organization to direct, monitor and review the development it outsources. If you are its supplier, that means it will ask you for things: security clauses in the contract, the right to audit you, your secure development practices, test results and, often, a pentest before accepting the delivery.
Having your own process aligned with 8.25 means those requests are answered with documents that already exist, rather than with new effort on every project.
How the pentest fits
The pentest is the clearest evidence for control 8.29, and it also shows that 8.25 works: if the process is good, the pentest finds little and it is fixed quickly. A pentest report with its retest, done by an independent third party, is one of the first things an auditor or a client overseeing you asks for.
FAQ
What is ISO 27001 control 8.25?
It is the ISO 27001:2022 Annex A control that requires rules for the secure development of software and systems to be established and applied. In the 2013 version its equivalent was control A.14.2.1, secure development policy.
Does control 8.25 require a pentest?
Not by that name, but control 8.29 requires security testing during development and acceptance, and a pentest is the most common and easiest-to-prove way of meeting it for exposed applications.
Does 8.25 apply if we do not develop software?
If the organization does not develop, the control can be excluded with a justification in the statement of applicability. But if it commissions development from third parties, control 8.30 does apply and requires overseeing that supplier.
Which documents are needed?
At least a secure development procedure and evidence that it is applied: security requirements in projects, code reviews, test results and environment separation. You do not need one document per control, but every control needs an answer.
Where is the detail on how to implement it?
In ISO/IEC 27002:2022, the controls guide that accompanies ISO 27001. For secure development, frameworks such as NIST SSDF, OWASP SAMM and OWASP ASVS help make concrete what to do in each phase.
Related service
cybersecurity for software development companies