In this ultimate how to implement guide to ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance, you will learn directly from an ISO 27001 Lead Auditor:
Table of contents
- 1. Define Security Acceptance Criteria
- 2. Implement Static Application Security Testing (SAST)
- 3. Conduct Dynamic Application Security Testing (DAST)
- 4. Perform Manual Penetration Testing
- 5. Execute Security Regression Testing
- 6. Validate Input Sanitisation
- 7. Test Authentication and Session Management
- 8. Secure the Testing Environment
- 9. Sanitise Test Data
- 10. Enforce Formal Sign-Off
1. Define Security Acceptance Criteria
Control Requirement: Security requirements must be clearly defined and approved before development begins.
Required Implementation Step: Update your “Definition of Done” for every user story or feature request to include specific security criteria (e.g., “Must pass OWASP ZAP scan with zero High alerts” or “Must enforce MFA”). Do not allow a ticket to move to the ‘Testing’ column without these criteria.
Minimum Requirement: Every project specification document has a dedicated “Security Requirements” section.
2. Implement Static Application Security Testing (SAST)
Control Requirement: Code must be analysed for vulnerabilities during the development phase.
Required Implementation Step: Integrate a SAST tool (like SonarQube or Snyk) directly into your CI/CD pipeline. Configure the build to fail automatically if critical vulnerabilities (such as hardcoded credentials or SQL injection patterns) are detected in the source code.
Minimum Requirement: Automated code scanning runs on every commit.
3. Conduct Dynamic Application Security Testing (DAST)
Control Requirement: The running application must be tested for vulnerabilities in an operating state.
Required Implementation Step: Schedule automated DAST scans against your staging environment. Tools like OWASP ZAP or Burp Suite Professional should aggressively test endpoints for runtime issues that static analysis misses, such as misconfigured headers or cross-site scripting (XSS).
Minimum Requirement: A weekly automated vulnerability scan of the staging environment.
4. Perform Manual Penetration Testing
Control Requirement: High-risk systems require human validation of security controls.
Required Implementation Step: Commission a manual penetration test for all major releases or critical infrastructure changes. Do not rely solely on automated tools; require a human tester to attempt logic bypasses and privilege escalation attacks.
Minimum Requirement: An annual manual penetration test by an external or independent internal team.
5. Execute Security Regression Testing
Control Requirement: Changes must not break existing security controls.
Required Implementation Step: Maintain a suite of automated security regression tests (e.g., “Verify login page still locks out after 5 attempts”). Run this suite before every deployment to ensure that new code commits have not accidentally disabled firewall rules or authentication checks.
Minimum Requirement: Automated tests confirm that previously fixed bugs have not re-emerged.
6. Validate Input Sanitisation
Control Requirement: The system must correctly handle invalid or malicious input.
Required Implementation Step: Create positive and negative test cases specifically for input fields. Attempt to inject SQL commands, script tags, and buffer overflow strings into all API endpoints and forms to prove that the application rejects them gracefully.
Minimum Requirement: Evidence of Fuzz testing on all public-facing input fields.
7. Test Authentication and Session Management
Control Requirement: Access controls must function as designed under attack conditions.
Required Implementation Step: Manually verify that session tokens expire correctly, that users cannot access URLs belonging to other tenants (IDOR), and that “Forgot Password” flows cannot be abused for account enumeration.
Minimum Requirement: Documented test results proving user segregation is enforced.
8. Secure the Testing Environment
Control Requirement: The environment used for testing must be secure and controlled.
Required Implementation Step: Apply the same hardening standards to your Staging/Test environment as you do to Production. Ensure the test server is patched, unnecessary ports are closed, and access is restricted to the QA/Dev team only.
Minimum Requirement: The test environment is isolated from the open internet via VPN or IP whitelist.
9. Sanitise Test Data
Control Requirement: Production PII must not be exposed in lower environments.
Required Implementation Step: Use synthetic data generators (e.g., Faker) to populate test databases. If production data must be used for acceptance testing, run an anonymisation script to mask names, emails, and financial data before it leaves the production network.
Minimum Requirement: No real customer names or credit card numbers exist in the test database.
10. Enforce Formal Sign-Off
Control Requirement: Deployment to production requires explicit security approval.
Required Implementation Step: Implement a “Gatekeeper” step in your release process. The Product Owner or Security Lead must physically or digitally sign a release form confirming that all security tests have passed and acceptable risks are documented.
Minimum Requirement: A recorded “Go/No-Go” decision based on security test results.
About the author
