Auditing ISO 27001 Annex A 8.25 Secure Development Lifecycle is the technical verification of security integration throughout the software engineering process. The Primary Implementation Requirement is automated security testing within CI/CD pipelines, providing the Business Benefit of reducing production vulnerabilities and ensuring high-integrity software delivery.
ISO 27001 Annex A 8.25 Visualisation of Secure Development Lifecycle Audit Checklist
This technical verification tool is designed for lead auditors to establish the security integrity of the software development process. Use this checklist to validate compliance with ISO 27001 Annex A 8.25.
1. Secure Coding Policy Formalisation Verified
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. Security Requirements Integration in Design Confirmed
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. Vulnerability Mitigation in Software Components Validated
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.
4. Secure Coding Practices Implementation Confirmed
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. Development and Production Environment Segregation Verified
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. Secure Handling of Sensitive Data in Development Validated
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. Version Control and Change Authorisation Confirmed
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. Automated Security Testing in CI/CD Pipeline Verified
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. Secure Decommissioning of Development Assets Identified
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. Management Oversight of Developer Competency 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.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Policy Implementation | Tool marks “Pass” because an SDLC Policy PDF is uploaded. | Verify Technical Enforcement. A policy is words; an auditor must see the “Force PR” setting in GitHub. |
| Component Vulnerabilities | GRC tool assumes libraries are safe because “Antivirus is active.” | Demand the SCA Report. Antivirus does not detect insecure node_modules or outdated Java packages. |
| Environment Segregation | Platform identifies “Dev” and “Prod” as separate folders. | Check the IAM Policy. If the same service account has ‘Full Access’ to both S3 buckets, they are not segregated. |
| Peer Review Integrity | SaaS tool records “PRs are used” in the developer workflow. | Verify Independent Approval. Does the system allow a dev to approve their own PR from a second “admin” account? |
| Data Obfuscation | Tool accepts a questionnaire answer saying “We use fake data.” | Audit the Database. Check for the presence of legitimate email addresses or names in the ‘Test’ schema. |
| Security Testing | Platform confirms “Scanning Tool is Integrated.” | Check the Scan History. GRC tools often ignore the fact that the scanner has been “ignoring” all findings for months. |
| Secret Management | Tool assumes secrets are secure in the repository. | Run a Secret Scanner. If the GRC tool says “Compliant” but the repo contains AWS keys, the tool has failed. |
About the author
