ISO 27001 Annex A 8.25 – Secure Development Life Cycle (SDLC) requires organizations to establish and apply rules for the secure development of software and systems.
The objective is to make security part of the development lifecycle rather than treating security as an activity performed only after software has been developed.
For startups and SaaS companies, this is particularly important because vulnerabilities introduced during development can later affect customers, production systems, business operations, and compliance commitments.
What is ISO 27001 Annex A 8.25?
Annex A 8.25 focuses on integrating information security throughout the software and system development lifecycle.
Security should be considered from the beginning of development and continue through:
Planning → Requirements → Design → Development → Testing → Deployment → Maintenance → Retirement
The organization should define and follow secure development practices appropriate to its technology, risks, and business requirements.
This can apply to:
- Web applications
- Mobile applications
- SaaS platforms
- APIs
- Cloud applications
- Internal applications
- Infrastructure-as-code
- Scripts and automation
- Databases
- Microservices
- AI/ML applications
- Software developed by third parties
Simple Explanation
A simple way to understand A.8.25 is:
Build security into the software development process from the beginning instead of trying to fix security problems after deployment.
For example, instead of:
Develop → Deploy → Discover vulnerability → Fix
a secure development lifecycle follows:
Plan → Design securely → Develop securely → Test → Review → Deploy → Monitor → Improve
Why is Secure Development Important?
Software vulnerabilities can result in:
- Data breaches
- Unauthorized access
- Account takeover
- Data leakage
- Malware
- Business disruption
- Financial loss
- Regulatory issues
- Customer security concerns
- Contractual problems
- Reputational damage
A vulnerability discovered after production deployment can also be significantly more expensive and disruptive to fix than one identified during development.
For SaaS companies, secure development is especially important because one vulnerable application can potentially affect many customers.
What Does ISO 27001 A.8.25 Require?
The organization should establish secure development rules and integrate security into its development lifecycle.
Depending on the organization’s environment and risk, this can include:
- Security requirements
- Secure architecture and design
- Secure coding practices
- Security testing
- Code review
- Vulnerability management
- Dependency management
- Change management
- Separation of development and production
- Security approval before release
- Protection of development environments
- Secure handling of source code
- Security considerations for outsourced development
- Documentation and evidence
Not every organization will need the same level of controls. The secure development approach should be appropriate to the organization’s technology, risk, and development model.
Activities Required to Implement A.8.25
1. Define Secure Development Requirements
Start by defining what security means for your development process.
Requirements may cover:
- Authentication
- Authorization
- Encryption
- Password handling
- Session management
- Logging
- Input validation
- Secure API design
- Data protection
- Secrets management
- Error handling
- Security testing
- Dependency management
- Vulnerability remediation
These requirements should be considered before development begins.
2. Include Security in Software Requirements
Security requirements should be included in the application requirements.
For example:
| Requirement | Security Consideration |
|---|---|
| User login | MFA, secure authentication |
| Customer data | Encryption and access control |
| API | Authentication and authorization |
| Admin portal | Strong access controls |
| File upload | Malware and file validation |
| Payment functionality | Appropriate security requirements |
| Sensitive information | Encryption and restricted access |
| Audit trail | Security logging |
Security should therefore become part of the product requirement rather than an afterthought.
3. Apply Secure Design Principles
Before development starts, the organization should consider security risks in the architecture and design.
Examples include:
- Least privilege
- Defense in depth
- Secure defaults
- Separation of duties
- Network segmentation
- Strong authentication
- Authorization boundaries
- Data minimization
- Secure communication
- Fail-secure behavior
For high-risk applications, organizations may also perform:
- Threat modeling
- Architecture security reviews
- Abuse-case analysis
- Attack-surface analysis
4. Establish Secure Coding Practices
Developers should follow secure coding standards appropriate to the technologies being used.
Examples include controls against:
- SQL injection
- Cross-site scripting
- Command injection
- Authentication weaknesses
- Authorization bypass
- Insecure direct object references
- Improper input validation
- Hardcoded credentials
- Sensitive information exposure
- Insecure deserialization
- Unsafe dependencies
Organizations may use recognized secure coding guidance such as OWASP resources as part of their development practices.
5. Implement Code Review
Code review can identify security weaknesses before software reaches production.
The organization should define when code review is required and who can perform it.
For example:
Developer → Pull Request → Peer Review → Automated Checks → Security Checks → Merge
For high-risk changes, additional security review may be required.
6. Perform Security Testing
Security testing should be integrated into the development lifecycle.
Depending on the application, this can include:
- SAST
- DAST
- Software Composition Analysis
- Dependency scanning
- Secret scanning
- Container scanning
- Infrastructure-as-Code scanning
- API security testing
- Manual security testing
- Penetration testing
Security testing should be appropriate to the organization’s risk and technology.
7. Manage Third-Party Dependencies
Modern applications often depend on:
- Open-source libraries
- Packages
- Frameworks
- Containers
- APIs
- SaaS services
- Cloud services
The organization should have a process for identifying and managing vulnerabilities in these dependencies.
For example:
Identify dependency → Scan → Identify vulnerability → Assess risk → Update/patch → Test → Deploy
8. Protect Source Code
Source code should be protected against unauthorized access and modification.
Controls may include:
- Access control
- Repository permissions
- Branch protection
- MFA
- Pull-request controls
- Audit logging
- Backup
- Repository monitoring
- Secret scanning
Examples of source-code platforms include GitHub, GitLab, Bitbucket and similar services.
9. Separate Development, Testing and Production
Development environments should be appropriately separated from production.
A common startup architecture is:
Development → Testing/Staging → Production
Developers should not automatically have unrestricted production access.
Production credentials and secrets should also not be stored in development repositories or source code.
This requirement works closely with ISO 27001 Annex A 8.31 – Separation of development, test and production environments.
10. Integrate Security into CI/CD
For modern SaaS companies, secure development should be integrated into CI/CD pipelines.
A simplified pipeline can be:
Code Commit
↓
Build
↓
SAST
↓
Dependency Scan
↓
Secret Scan
↓
Unit/Integration Tests
↓
Security Testing
↓
Approval
↓
Deployment
↓
Production Monitoring
This approach is often called DevSecOps.
11. Define Security Requirements for Releases
Before deploying a significant application change, the organization should determine whether security requirements have been satisfied.
A release checklist may include:
| Check | Status |
|---|---|
| Code review completed | ☐ |
| Security testing completed | ☐ |
| Critical vulnerabilities resolved | ☐ |
| Dependencies reviewed | ☐ |
| Secrets scanned | ☐ |
| Configuration reviewed | ☐ |
| Security requirements completed | ☐ |
| Required approval obtained | ☐ |
| Production deployment authorized | ☐ |
The exact release criteria should be based on organizational risk.
12. Manage Security Vulnerabilities
When a vulnerability is discovered, the organization should have a process for:
Identify → Assess → Prioritize → Remediate → Test → Deploy → Verify
Critical or high-risk vulnerabilities may require accelerated remediation.
The organization should retain evidence of remediation where appropriate.
Example: Startup Implementing A.8.25
Consider a SaaS startup with:
- React frontend
- Node.js backend
- PostgreSQL database
- AWS infrastructure
- GitHub repository
- GitHub Actions CI/CD
The startup implements the following process:
Development
Developers follow secure coding guidelines.
Code Repository
Developers use individual accounts and MFA.
Pull Request
All production code requires peer review.
Automated Security
The CI/CD pipeline performs:
- SAST
- Dependency scanning
- Secret scanning
- Container scanning
Testing
Security testing is performed before major releases.
Production
Production access is restricted to authorized personnel.
Vulnerabilities
Security findings are recorded and tracked through remediation.
Evidence
The company retains:
- Secure development policy
- Secure coding guidelines
- Pull-request records
- CI/CD security scan results
- Vulnerability tickets
- Security testing reports
- Release approvals
This provides a practical implementation of A.8.25 without requiring a large security department.
When Should Secure Development Activities Be Triggered?
Secure development should not be limited to a single annual activity.
Security activities may be triggered by:
- New application development
- Major application changes
- New features
- New APIs
- New integrations
- New technology
- New cloud infrastructure
- Significant architecture changes
- New sensitive data processing
- Major dependency changes
- Security vulnerabilities
- Security incidents
- New regulatory requirements
- New customer security requirements
- Major changes to authentication or authorization
- Significant changes to CI/CD pipelines
Startup-Focused Quick Summary
For a startup, A.8.25 does not mean creating a huge security department or implementing dozens of expensive tools.
A practical startup implementation can begin with:
- Secure development policy
- Secure coding guidelines
- Security requirements for applications
- Code review
- Protected source-code repositories
- Dependency scanning
- Secret scanning
- SAST or equivalent automated security testing
- Vulnerability management
- Security testing before important releases
- Development/test/production separation
- Documented release process
Minimum Startup Implementation
Secure Coding + Code Review + Security Scanning + Vulnerability Management + Secure CI/CD + Controlled Production Access
This provides a strong foundation for A.8.25.
Simple Rule
Do not wait until production to think about security. Build security into every important stage of development.
Secure Development Lifecycle Example
| Stage | Security Activity |
|---|---|
| Planning | Identify security requirements |
| Requirements | Define security requirements |
| Design | Threat modeling / architecture review |
| Development | Secure coding |
| Code Review | Peer/security review |
| Build | Automated security scanning |
| Testing | Security testing |
| Release | Security approval/checklist |
| Deployment | Controlled deployment |
| Operations | Monitoring and vulnerability management |
| Maintenance | Patch and remediate |
| Retirement | Secure removal and data handling |
Example Secure Development Register
Organizations can maintain a simple register:
| Application | Owner | Technology | Security Requirements | Testing | Last Review | Status |
|---|---|---|---|---|---|---|
| Customer Portal | CTO | React/Node | Authentication, encryption, logging | SAST + DAST | 2026-09 | Active |
| Mobile App | Product Head | iOS/Android | Authentication, API security | SAST + testing | 2026-09 | Active |
| Internal HR App | IT | Web | Access control, privacy | SAST | 2026-08 | Active |
What Evidence Can an Auditor Ask For?
An auditor may examine evidence such as:
- Secure development policy
- SDLC procedure
- Secure coding standards
- Security requirements
- Architecture/security review records
- Threat models
- Code review records
- Pull requests
- Branch protection configuration
- CI/CD configuration
- SAST results
- DAST results
- Dependency scan reports
- Secret scanning results
- Vulnerability register
- Penetration testing reports
- Security test results
- Release approval records
- Developer security training
- Production access controls
- Development/test/production separation evidence
- Records of security issues and remediation
The exact evidence required will depend on the organization’s development model, scope, and risk.
ISO 27001 A.8.25 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Is a secure development lifecycle defined? | SDLC procedure |
| Are security requirements identified? | Security requirements |
| Are secure coding practices defined? | Coding standard |
| Is code reviewed? | Pull requests/reviews |
| Is source code protected? | Repository configuration |
| Is security testing performed? | Test reports |
| Are dependencies monitored? | Dependency scans |
| Are secrets protected? | Secret-management/scanning evidence |
| Are vulnerabilities tracked? | Vulnerability register |
| Are security issues remediated? | Tickets/evidence |
| Is security integrated into CI/CD? | Pipeline configuration |
| Are production deployments controlled? | Release approvals |
| Are development and production appropriately separated? | Architecture/configuration |
| Are developers aware of secure development requirements? | Training records |
| Are secure development practices reviewed and improved? | Review records |
Common Mistakes
1. Security Testing Only at the End
Waiting until the final stage of development can allow vulnerabilities to remain undetected for too long.
Better approach: integrate security throughout the SDLC.
2. Treating Code Review as Security Testing
A normal code review does not necessarily identify all security vulnerabilities.
Better approach: combine peer review with automated and, where appropriate, specialized security testing.
3. Storing Secrets in Source Code
Examples include:
- API keys
- Passwords
- Cloud credentials
- Database credentials
- Tokens
Better approach: use an appropriate secrets-management mechanism.
4. Ignoring Open-Source Dependencies
A secure application can still contain vulnerable third-party components.
Better approach: implement dependency monitoring and vulnerability remediation.
5. Developers Having Unrestricted Production Access
Excessive production privileges increase security risk.
Better approach: apply least privilege and controlled production access.
6. Having a Policy Without Actual Implementation
An organization may have a secure development policy but no evidence that developers actually follow it.
Better approach:
Policy → Process → Technical Controls → Evidence
Practical Implementation Model
A simple model for A.8.25 is:
Define Security Requirements
↓
Secure Design
↓
Secure Development
↓
Code Review
↓
Security Testing
↓
Vulnerability Remediation
↓
Security Approval
↓
Controlled Deployment
↓
Monitoring & Maintenance
↓
Continuous Improvement
Policy vs Process vs Technical Control vs Evidence
| Layer | Example |
|---|---|
| Policy | Secure Development Policy |
| Process | SDLC procedure |
| Standard | Secure Coding Standard |
| Technical Control | SAST, DAST, dependency scanning |
| Operational Control | Code review and release approval |
| Evidence | Scan reports, PRs, tickets, approvals |
This distinction is important during an ISO 27001 audit.
Having a policy alone does not demonstrate effective implementation.
Useful Resources
Draft Secure Development Policy
[Insert Draft Secure Development Policy Link]
Secure Coding Standard
[Insert Secure Coding Standard Link]
Secure SDLC Checklist
[Insert Secure SDLC Checklist Link]
Application Security Checklist
[Insert Application Security Checklist Link]
Vulnerability Management Register
[Insert Vulnerability Register Link]
Software Security Testing Checklist
[Insert Security Testing Checklist Link]
Related ISO 27001 Controls
A.8.25 works closely with several other Annex A controls:
- A.5.8 – Information security in project management
- A.5.15 – Access control
- A.5.17 – Authentication information
- A.5.23 – Information security for use of cloud services
- A.5.30 – ICT readiness for business continuity
- A.8.4 – Access to source code
- A.8.8 – Management of technical vulnerabilities
- A.8.9 – Configuration management
- A.8.20 – Networks security
- A.8.22 – Segregation in networks
- A.8.24 – Use of cryptography
- A.8.26 – Application security requirements
- A.8.27 – Secure system architecture and engineering principles
- A.8.28 – Secure coding
- A.8.29 – Security testing in development and acceptance
- A.8.31 – Separation of development, test and production environments
- A.8.32 – Change management
A.8.25 vs A.8.28 vs A.8.29
These controls are related but have different practical focuses.
| Control | Primary Focus |
|---|---|
| A.8.25 | Secure development lifecycle |
| A.8.28 | Secure coding |
| A.8.29 | Security testing in development and acceptance |
| A.8.31 | Separation of development, test and production |
In simple terms:
A.8.25 = How security is integrated into the development lifecycle
A.8.28 = How developers write secure code
A.8.29 = How security is tested before acceptance/release
A.8.31 = How environments are separated
Final Takeaway
ISO 27001 Annex A 8.25 is about making security part of the software development lifecycle.
For a startup, the goal is not to create unnecessary bureaucracy. The goal is to establish a repeatable process where security is considered before development, checked during development, tested before release, and maintained after deployment.
A practical secure development lifecycle can be summarized as:
Plan securely → Design securely → Develop securely → Test → Remediate → Approve → Deploy → Monitor → Improve
For startups and SaaS companies, implementing this approach can also provide useful evidence for customer security reviews, SOC 2, ISO 27001, and other security/compliance requirements.