Information Security Management
Secure Development Policy: What ISO 27001 Controls 8.25 to 8.31 Expect From Software Teams
If you build software, ISO 27001 has a block of eight controls for how you build it, 8.25 to 8.32, and the secure development policy is where you set out how you meet them. Most small software companies already do much of what the controls ask (code review, version control, CI pipelines, dependency scanning) and have none of it written down. The policy is the document that turns engineering practice into audit evidence.
The complete toolkit, every policy, template and record you need. Free, no commitment
This guide covers what the controls require, what to put in the policy, how it maps to the way a small team actually works, the questions auditors ask software businesses, and the template from our toolkit.
Free secure development policy template (Word)
The template sets out the principles (security is everyone’s responsibility, continuous learning, clean and maintainable code, secure environments, protected repositories, secure build and deployment, continuous testing, planning for flaws, data masking), the implementation and compliance expectations, roles, exceptions and review. Replace the placeholders and point each principle at the tool or practice you actually use.
It is one of 18 policy templates in the free ISO 27001 toolkit, which also has the secure development guidelines that sit beneath it.
The controls
Annex A section 8 has a run of controls for development, and the policy is the umbrella over all of them.
| Control | Title | What it asks for |
|---|---|---|
| 8.25 | Secure development life cycle | Rules for secure development, applied to all development of software and systems |
| 8.26 | Application security requirements | Security requirements identified and specified when applications are developed or acquired |
| 8.27 | Secure system architecture and engineering principles | Principles established, documented and applied to engineering activities |
| 8.28 | Secure coding | Secure coding principles applied to software development |
| 8.29 | Security testing in development and acceptance | Security testing defined and carried out in the development life cycle |
| 8.30 | Outsourced development | The organisation directs, monitors and reviews development it outsources |
| 8.31 | Separation of development, test and production environments | Environments separated and secured |
| 8.32 | Change management | Changes to systems subject to change management procedures |
Control 8.25 is the one that names the policy: the rules for secure development are what the policy contains. The others are satisfied by sections within it or by the practices it points to.
What to put in the policy
- Scope. All software and systems you develop, whether for customers, for internal use or as infrastructure as code, and everyone who develops them including contractors and outsourced teams.
- Principles. Security is a requirement, not a phase; least privilege; defence in depth; secure by default; fail securely. Short, and referenced by the rest.
- Security requirements. How security requirements are captured for each piece of work: threat modelling for new features or services, a security checklist in the definition of done, data classification of what the feature handles.
- Secure design. The architecture principles you apply: authentication and authorisation patterns, input validation at boundaries, encryption of data in transit and at rest, logging without secrets, secrets management.
- Secure coding. The standard you follow (OWASP guidance is the usual reference), the languages and frameworks in use, and the rules: no secrets in code, dependencies pinned and scanned, code review before merge.
- Repositories and pipelines. Version control for everything; branch protection; MFA on the repository platform; signed commits where practical; CI pipelines that run static analysis, dependency scanning and tests before anything is deployed; deployment only from the pipeline.
- Environments. Development, test and production separated; production data not used in test without masking; production access restricted and logged.
- Testing. Static and dynamic analysis in the pipeline, dependency vulnerability scanning, security review for significant changes, and penetration testing at a defined interval or before major releases.
- Outsourced development. Contract terms, access controls, code review of delivered work, the same pipeline checks applied.
- Vulnerability handling. What happens when a flaw is found in your own code: the same timescales as the patch management policy, a fix, a test, a record.
- Training. Developers get security training appropriate to their stack, at joining and periodically.
- Roles, exceptions and review. Who owns the policy, who approves exceptions, annual review.
How it maps to a small team’s reality
A six-person engineering team on GitHub, GitHub Actions and AWS probably already has most of the control. The policy’s job is to name it:
| Practice you already have | Control it evidences |
|---|---|
| Pull requests with required review and branch protection on main | 8.28, 8.32 |
| Dependabot or equivalent dependency scanning | 8.8, 8.28 |
| CI pipeline running tests and a static analysis step | 8.29 |
| Separate AWS accounts or environments for dev, staging and production | 8.31 |
| Secrets in a vault, not in the repo; MFA on GitHub and AWS | 8.27, 8.28 |
| Infrastructure as code with the same review process | 8.25, 8.32 |
| An annual penetration test from a third party | 8.29 |
Write the policy so that each section says what the practice is and where the evidence lives (the branch protection settings, the pipeline definition, the last pentest report). The auditor can then verify it in an hour instead of a day.
Outsourced and AI-assisted development
Two things auditors are increasingly asking about.
Outsourced development (8.30). If an agency or contractor writes code for you, the policy applies to them: access through your repositories and pipelines rather than their own, the same review before merge, contract terms covering security requirements and IP, and a review of what is delivered. “They are ISO 27001 certified” is not sufficient on its own.
AI coding assistants. Not a control yet, but every auditor asks. The policy should say which tools are approved, that generated code goes through the same review and testing as any other, that secrets and customer data are not pasted into prompts, and what the licensing position is. Our toolkit’s AI policy covers the organisational side.
Mistakes I see most at audit
- No policy at all. The engineering practice is good; the auditor has nothing to audit it against and raises a finding on 8.25.
- A policy that describes a different company. Copied from a large enterprise template, with change advisory boards and release managers the six-person team does not have.
- Production data in test. Real customer records in a staging environment with weaker access control. A data protection problem as well as an 8.31 finding.
- Secrets in repositories. Still the most common technical finding. Scan for them and rotate them.
- No penetration test, or one from three years ago.
- Outsourced code merged without review.
Where to go next
Secure development runs alongside patch management (vulnerabilities in what you run) and the cloud security policy (the platform you build on). For the full control set see the Annex A guide and the controls list; the other policy guides are on the ISO 27001 policies hub. Most of our clients are software and technology businesses, and our ISO 27001 consultancy service is built around right-sizing these controls for small engineering teams.
Frequently asked questions
Does ISO 27001 require a secure development policy?
If you develop software or systems, yes. Control 8.25 requires rules for secure development to be established and applied, and controls 8.26 to 8.32 cover requirements, architecture, coding, testing, outsourcing, environment separation and change management. The policy is the document that sets those rules out.
What should a secure development policy include?
Scope, principles, how security requirements are captured, secure design and coding standards, repository and pipeline controls, separation of environments, security testing including penetration testing, outsourced development, handling of vulnerabilities in your own code, developer training, roles, exceptions and review. Each section should point to the tool or practice that provides the evidence.
Do I need a penetration test for ISO 27001?
Not by name, but control 8.29 requires security testing in development and acceptance, and for a customer-facing application an independent penetration test is the conventional way to demonstrate it. Most small software businesses commission one annually or before major releases.
Does the policy apply to contractors and outsourced developers?
Yes. Control 8.30 requires outsourced development to be directed, monitored and reviewed. In practice that means contractors work through your repositories and pipelines, their code is reviewed before merge, and the contract covers security requirements.
Can production data be used in testing?
Not without protection. Control 8.31 requires development, test and production environments to be separated and secured, and using real customer data in test is both a common audit finding and a data protection risk. Use synthetic data, or mask production data before it leaves production.
ISO 27001 Online Course + Full Toolkit
Stop guessing. Follow a proven step-by-step process.
“Highly recommended for anyone looking to understand ISO 27001, whether attempting it on your own or even using a consultant.“
Verified customer review
£285
Instant access
✓ Full toolkit included ✓ Learn as you build ✓ 12-month access ✓ 6 hours of video ✓ Call + email support
Author Background
This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.
With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.
Qualifications: Certified ISO/IEC 27001:2022 Lead Auditor,
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.
Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.
