In this ultimate how to audit guide to ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance, you will learn directly from an ISO 27001 Lead Auditor:
- 10 Key Audit Steps
- Verification Criteria
- Required Evidence
- The Pass / Fail Test
I am Stuart Barker, the ISO 27001 Lead Auditor and author of the Ultimate ISO 27001 Toolkit.
Using over 30 years of industry experience across hundreds of audits, I’m giving you the exact templates, walkthroughs, and practical examples you need to achieve ISO 27001 certification.
Table of contents
- ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance Audit Checklist
- 1. Security Testing Policy Formalisation Verified
- 2. Static Application Security Testing (SAST) Integration Confirmed
- 3. Dynamic Application Security Testing (DAST) Implementation Validated
- 4. Vulnerability Remediation Prior to Acceptance Verified
- 5. User Acceptance Testing (UAT) Security Validation Confirmed
- 6. Independent Security Assessment of Major Changes Validated
- 7. Secure Configuration Testing of Testing Environments Verified
- 8. Automated Build Failure (Breaking the Build) Logic Verified
- 9. Regression Testing of Security Controls Confirmed
- 10. Management Sign-off and Acceptance Records Identified
ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance Audit Checklist
Auditing ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance is the technical verification of security validation integrated within the software engineering lifecycle. The Primary Implementation Requirement is automated security gates within CI/CD pipelines and formal UAT, providing the Business Benefit of preventing production-level exploits and ensuring management-authorized risk alignment.
This technical verification tool is designed for lead auditors to establish the efficacy of security testing within the software lifecycle. Use this checklist to validate compliance with ISO 27001 Annex A 8.29.
1. Security Testing Policy Formalisation Verified
Verification Criteria: A documented policy or technical standard exists defining the mandatory security testing activities required before software is promoted to production.
Required Evidence: Approved “Secure Testing Standard” or “SDLC Policy” specifying testing triggers, types, and required severity thresholds.
Pass/Fail Test: If the organisation cannot produce a formal document specifying the technical requirements for security testing, mark as Non-Compliant.
2. Static Application Security Testing (SAST) Integration Confirmed
Verification Criteria: Automated SAST tools are integrated into the development environment or CI/CD pipeline to scan source code for vulnerabilities during the build process.
Required Evidence: Build logs or CI/CD configuration files (e.g., Jenkinsfile, GitHub Actions) showing executed SAST scan stages.
Pass/Fail Test: If source code is committed to a production branch without an automated security scan being triggered, mark as Non-Compliant.
3. Dynamic Application Security Testing (DAST) Implementation Validated
Verification Criteria: Technical testing of the running application is performed in a staging environment to identify runtime vulnerabilities such as misconfigurations or broken access control.
Required Evidence: DAST tool reports (e.g., OWASP ZAP, Burp Suite, Veracode) dated within the current release cycle.
Pass/Fail Test: If the organisation only performs code scans but never tests the application in a running, functional state, mark as Non-Compliant.
