ISO 27001 Control 8.29: Security Testing in Development and Acceptance
Security acceptance testing isn't optional—it's your gate before production. ISO 27001 8.29 mandates that you verify security requirements are met in your development pipeline before any code reaches users. Without formal testing processes, vulnerabilities slip through and compliance gaps grow.
What this means
Control 8.29 requires your organization to establish and implement documented security acceptance testing processes as part of your development and acceptance workflows. This means defining what 'secure enough' looks like, running tests against those criteria, and only promoting code to production when it passes. Testing must cover both functional security requirements (authentication, encryption, access controls) and non-functional security properties (performance under attack, resilience, data integrity). These processes must be integrated into your SDLC—not bolted on afterward.
How to comply
- 1.Define security acceptance criteria for all development projects, including authentication, authorization, data protection, and input validation requirements
- 2.Document your security testing methodology, specifying which tests run at which pipeline stages (unit, integration, acceptance)
- 3.Implement automated security scanning tools (SAST, DAST) within your CI/CD pipeline to catch vulnerabilities early
- 4.Conduct manual security testing and code reviews before acceptance, focusing on high-risk components and attack surfaces
- 5.Establish clear pass/fail criteria—define what defects block deployment versus which can be deferred
- 6.Train development teams on secure coding practices and security testing responsibilities
- 7.Log and track all security testing results, including findings, remediation, and evidence of acceptance approval
- 8.Review and update security testing processes annually or when development tools, frameworks, or threat models change
Evidence auditors look for
- Security testing policy document with defined acceptance criteria and testing requirements
- SDLC documentation showing security testing gates at development, integration, and acceptance phases
- Test plans and test cases covering security requirements (authentication, encryption, access control, input validation)
- SAST/DAST tool configurations and scan reports from recent development cycles
- Security code review checklists and peer review records with sign-off
- Penetration testing reports or vulnerability assessment results before production release
- Security testing results matrix showing which controls were tested and status (pass/fail)
- Records of security defects found, remediated, and verified closed before deployment
- Developer training records on secure coding and security testing procedures
Frequently asked questions
When will FAQs be available?
The FAQ for this control is currently being prepared.
GRCWatch automates security testing evidence collection by integrating with your CI/CD pipeline, capturing SAST/DAST results, code review records, and test execution logs—then organizing them by control for instant audit proof of ISO 27001 8.29 compliance.
See how GRCWatch handles this control automatically
Start free trial