The ultimate audit guide to ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance
Table of contents
- 1. Verify the Security Testing Policy
- 2. Evidence Static Application Security Testing (SAST) Integration
- 3. Review the Dynamic Application Security Testing (DAST) Implementation
- 4. Ensure Vulnerability Remediation Prior to Acceptance
- 5. Confirm User Acceptance Testing (UAT) Security Validation
- 6. Ensure the Independent Security Assessment of Major Changes
- 7. Check the Secure Configuration Testing of Testing Environments
- 8. Evidence the Automated Build Failure (Breaking the Build) Logic
- 9. Evidence Regression Testing of Security Controls
- 10. Ensure Management Sign-off and Acceptance Records
1. Verify the Security Testing Policy
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. Evidence Static Application Security Testing (SAST) Integration
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. Review the Dynamic Application Security Testing (DAST) Implementation
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.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Ensure Vulnerability Remediation Prior to Acceptance
Verification Criteria: All identified security vulnerabilities are triaged and “Critical” or “High” risk findings are remediated before User Acceptance Testing (UAT) sign-off.
Required Evidence: Remediation logs or Jira tickets showing the closure of security findings cross-referenced with the production release date.
Pass/Fail Test: If a production release contains unmitigated “High” severity security vulnerabilities without an approved risk acceptance, mark as Non-Compliant.
5. Confirm User Acceptance Testing (UAT) Security Validation
Verification Criteria: Acceptance testing includes specific scenarios to validate that security functional requirements (e.g., MFA, session timeouts) operate as designed.
Required Evidence: Signed UAT Test Plan and Results showing successful validation of security features and access control logic.
Pass/Fail Test: If UAT focuses solely on business functionality and ignores the validation of security controls, mark as Non-Compliant.
6. Ensure the Independent Security Assessment of Major Changes
Verification Criteria: Significant architectural changes or major releases undergo an independent security review or penetration test prior to deployment.
Required Evidence: Signed Penetration Test report or Independent Security Audit summary for the most recent major system update.
Pass/Fail Test: If a major system overhaul was promoted to production without an independent security assessment, mark as Non-Compliant.
7. Check the Secure Configuration Testing of Testing Environments
Verification Criteria: The environment used for security testing is hardened and configured to mirror the security posture of the production environment.
Required Evidence: Staging environment hardening checklists or IaC (Infrastructure as Code) templates showing parity between Staging and Production.
Pass/Fail Test: If security testing is performed in an environment with lower security settings than production (e.g., disabled firewalls), mark as Non-Compliant.
8. Evidence the Automated Build Failure (Breaking the Build) Logic
Verification Criteria: The CI/CD pipeline is configured to automatically stop the deployment if security testing identifies vulnerabilities exceeding a defined threshold.
Required Evidence: Pipeline configuration screenshots showing “Fail-on-High” or “Fail-on-Critical” security scan logic.
Pass/Fail Test: If security scans are “Information Only” and do not technically prevent the deployment of vulnerable code, mark as Non-Compliant.
9. Evidence Regression Testing of Security Controls
Verification Criteria: Following any modification or patch, regression tests are performed to ensure that existing security controls remain functional and effective.
Required Evidence: Automated test suite logs showing successful execution of security regression test cases (e.g., auth, permissions, encryption).
Pass/Fail Test: If the organisation lacks automated or manual regression tests specifically for security functions after a code change, mark as Non-Compliant.
10. Ensure Management Sign-off and Acceptance Records
Verification Criteria: A formalised record of management acceptance exists for every release, confirming that all required security testing has been completed and risks triaged.
Required Evidence: Signed Release Authorisation or “Go/No-Go” meeting minutes with a specific Security sign-off attribute.
Pass/Fail Test: If software is promoted to production via “silent deploy” without a formal record of management acceptance of the security status, mark as Non-Compliant.
About the author
