The ultimate audit guide to ISO 27001 Annex A 8.25 Secure Development Life Cycle
Table of contents
- 1. Verify the Secure Coding Policy
- 2. Confirm Security Requirements Integration in Design
- 3. Validate Vulnerability Mitigation in Software Components
- 4. Evidence Secure Coding Practices Implementation
- 5. Verify Development and Production Environment Segregation
- 6. Ensure Secure Handling of Sensitive Data in Development
- 7. Check Version Control and Change Authorisation
- 8. Review Automated Security Testing in CI/CD Pipeline
- 9. Ensure Secure Decommissioning of Development Assets
- 10. Evidence that Management Oversight of Developer Competency is Recorded
1. Verify the Secure Coding Policy
Verification Criteria: A documented policy exists defining the mandatory security principles for software development, including minimum security baselines for coding and architectural design.
Required Evidence: Approved “Secure Development Policy” or “Secure Coding Standard” with explicit version control and management sign-off.
Pass/Fail Test: If the organisation cannot produce a formalised document specifying the security requirements for development activities, mark as Non-Compliant.
2. Confirm Security Requirements Integration in Design
Verification Criteria: Security requirements are identified and documented during the specification and design phases of every software development project.
Required Evidence: Project specification documents or Jira tickets containing explicit “Security Requirements” or “Non-Functional Requirements” sections.
Pass/Fail Test: If a sampled project lacks documented security specifications prior to the commencement of coding, mark as Non-Compliant.
3. Validate Vulnerability Mitigation in Software Components
Verification Criteria: Technical controls are in place to identify and remediate vulnerabilities in third-party libraries and open-source components (Software Composition Analysis).
Required Evidence: SCA tool reports (e.g. Snyk, GitHub Dependabot, or SonarQube) showing zero “Critical” or “High” vulnerabilities in production code.
Pass/Fail Test: If production code contains unpatched third-party libraries with known “High” severity vulnerabilities and no documented mitigation, mark as Non-Compliant.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Evidence Secure Coding Practices Implementation
Verification Criteria: Developers utilise secure coding techniques (e.g. input validation, output encoding, and secure session management) to prevent common exploits like SQLi and XSS.
Required Evidence: Static Application Security Testing (SAST) reports or peer code review logs explicitly flagging security-related code checks.
Pass/Fail Test: If a manual spot-check or SAST report identifies plain-text sensitive data storage or lack of input sanitisation in the codebase, mark as Non-Compliant.
5. Verify Development and Production Environment Segregation
Verification Criteria: Development, testing, and production environments are strictly segregated both logically and, where possible, physically to prevent unauthorised access to production data.
Required Evidence: Network topology diagrams or cloud VPC configuration logs showing isolation between Dev/Test and Production environments.
Pass/Fail Test: If a developer has standing “Write” access to the production environment using their standard development credentials, mark as Non-Compliant.
6. Ensure Secure Handling of Sensitive Data in Development
Verification Criteria: Production data, specifically PII or financial records, is not used in development or testing environments unless it has been appropriately masked or anonymised.
Required Evidence: Data masking logs or screenshots from the testing database demonstrating the use of synthetic or obfuscated data.
Pass/Fail Test: If unmasked production PII is found residing in a developer’s local database or a shared testing environment, mark as Non-Compliant.
7. Check Version Control and Change Authorisation
Verification Criteria: All source code is managed via a secure version control system (VCS) with mandatory peer review and approval for all production-bound commits.
Required Evidence: VCS settings (e.g. GitHub/GitLab) showing branch protection rules and a history of approved Pull Requests (PRs).
Pass/Fail Test: If a developer can unilaterally push code directly to the production branch without a second-party technical review, mark as Non-Compliant.
8. Review Automated Security Testing in CI/CD Pipeline
Verification Criteria: Security testing (SAST/DAST) is integrated into the automated Build/Deployment pipeline, with “fail-build” triggers for high-risk findings.
Required Evidence: CI/CD pipeline configuration files (e.g. Jenkinsfile, GitLab CI YAML) showing security scan stages and pass/fail thresholds.
Pass/Fail Test: If the deployment pipeline proceeds to production despite the presence of “Critical” security vulnerabilities identified during scanning, mark as Non-Compliant.
9. Ensure Secure Decommissioning of Development Assets
Verification Criteria: Development repositories, API keys, and temporary environments are securely decommissioned or rotated once a project is completed or terminated.
Required Evidence: Decommissioning logs or secret management records (e.g. AWS Secrets Manager/Vault) showing rotation or revocation of project-specific keys.
Pass/Fail Test: If active, unrotated API keys for a completed project are found in the codebase or an unmanaged environment, mark as Non-Compliant.
10. Evidence that Management Oversight of Developer Competency is Recorded
Verification Criteria: Developers receive regular training on secure coding standards and emerging security threats relevant to their specific technology stack.
Required Evidence: Training completion records for all development staff cross-referenced against the OWASP Top 10 or similar industry benchmarks.
Pass/Fail Test: If the organisation cannot provide evidence of secure development training for its core engineering team in the last 12 months, mark as Non-Compliant.
About the author
