ISO 27001 A.8.29: Security testing in development and acceptance
What This Control Requires
Security testing processes shall be defined and implemented in the development life cycle.
In Plain Language
Writing secure code is necessary but not sufficient - you also need to verify it actually works as intended. Security testing validates that your security requirements are implemented correctly and catches vulnerabilities before they reach production. There are several complementary types. Static analysis examines source code without running it. Dynamic analysis probes running applications. Penetration testing simulates real attacks. Fuzz testing throws unexpected inputs at the application. Each catches different categories of problems, so you need a combination. The best results come from automating what you can (SAST and DAST in the CI/CD pipeline for continuous feedback) and supplementing with manual testing for the complex logic and business context that tools cannot assess. Findings need to be tracked through your defect management process and resolved before release.
How to Implement
Define a security testing strategy that maps testing types to development stages and scales with the risk level of each application. Wire automated security testing into your CI/CD pipeline. Deploy SAST tools to analyse source code during builds. Add SCA tools to scan dependencies for known vulnerabilities. Set up DAST tools to test deployed applications for runtime issues. Include container image scanning and IaC scanning if you use those technologies. Set quality gates that block vulnerable code from progressing. For example: no deployments with critical or high-severity findings unresolved. Medium-severity findings get a defined remediation SLA rather than a hard block. Track and trend all findings over time. For high-risk applications, add manual security testing. Validate threat models through security-focused design reviews. Run manual penetration tests before major releases. Conduct security code reviews of critical modules. Test business logic for flaws that automated tools miss. Consider engaging external testers for independent validation. Build security into your acceptance criteria. Define specific security acceptance criteria per application or release. Verify that the security requirements from A.8.26 are met through testing. Include security sign-off in the release approval process. Do not deploy anything that fails security acceptance without a documented risk acceptance from management. Manage findings properly. Classify by severity. Set SLAs for remediation. Track from identification through fix and verification. Report on metrics - finding volumes, types, resolution times, and trends. This data also feeds back into your developer training priorities.
Evidence Your Auditor Will Request
- Security testing strategy and plan documentation
- SAST, SCA, and DAST scan results from CI/CD pipeline
- Penetration testing reports for recent application releases
- Security finding remediation and tracking records
- Security acceptance testing and sign-off records
Common Mistakes
- Security testing is not performed before application releases
- Automated security testing is not integrated into the CI/CD pipeline
- Security testing findings are not tracked or remediated before deployment
- Manual penetration testing is not conducted for high-risk applications
- Security acceptance criteria are not defined or enforced
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| SOC 2 | CC8.1 | Related |
| NIS2 | Art.21(2)(e) | Partial overlap |
Frequently Asked Questions
What types of security testing should we perform?
Should security testing block deployments?
Track ISO 27001 compliance in one place
AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.
Start Free Assessment