For ISO 27001 control 8.25, you show that security rules exist for every stage of the software life cycle and that teams follow them. Keep a secure development policy, plus a few dated samples per stage, from requirements through testing, release, maintenance and retirement.
What the control asks for
Control 8.25 asks you to define rules for developing software and systems securely, then apply them. The rules cover requirements, design, coding, testing, deployment, maintenance and secure decommissioning. The idea is simple: a stage with no security thinking is where flaws get in.
A written document is recommended, not mandatory. Smaller and mid sized companies usually fold it into a secure development policy. Larger ones write a separate procedure.
The evidence, stage by stage
Auditors look for proof that security is built into the life cycle from conception to retirement. A policy alone shows intent. Samples show practice.
| Stage | A sample an auditor can pick | Where it usually lives |
|---|---|---|
| Requirements | A ticket with security acceptance criteria | Issue tracker |
| Design | A design note or threat model with a reviewer name | Docs or wiki |
| Coding | A pull request with review and scan results | Source host |
| Testing | A pipeline run with security test output | CI system |
| Deployment | A release record with approval | Deploy tool |
| Maintenance | A patched dependency with a linked ticket | Issue tracker |
| Retirement | A decommission checklist for an old service | Wiki or tickets |
You do not need a sample for every release. Pick recent, ordinary ones, because auditors prefer normal work over a polished showcase.
Habits that make this easy
- Write the policy in plain language, one page per stage at most.
- Name an owner for the policy and a review date.
- Let the pipeline produce evidence as a side effect, so nobody collects screenshots at audit time.
- Keep a short list of exceptions with a reason and an expiry.
- Train developers and keep the attendance record.
Try it yourself
Open the demo and look at how a pull request gets a pass or fail result from security checks. That result is the kind of dated record that supports the coding and testing rows above.
Click through it at your own pace, or open it full screen.
Where tooling helps
Safeguard offers policies and gates that run on pull requests, SBOM and dependency scanning, and compliance and evidence automation, so pipeline results are kept as records. You still write the policy and make the decisions. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Is a secure development policy required by ISO 27001?
It is recommended, not mandatory. You still need to define and apply secure development rules, and the policy is the usual way to record them.
Do auditors want evidence for every release?
No. They typically sample. Keep consistent, dated records so any release they choose can be traced through the stages.
Sources
Last reviewed: 19 October 2026.
