Security testing in development and acceptance
Plain English Translation
Security testing in development and acceptance requires organizations to define and integrate security testing throughout the software development life cycle (SDLC). By embedding tests like static code analysis, vulnerability scanning, and manual penetration testing before software is deployed, organizations ensure that new applications do not introduce vulnerabilities into the production environment. These tests must be aligned with formal acceptance criteria that dictate whether a build is secure enough to go live.
Technical Implementation
Use the tabs below to select your organization size.
Required Actions (startup)
- Enforce peer code reviews and basic software composition analysis (SCA) for open-source dependencies.
- Run regular vulnerability scans against staging environments prior to production releases.
Required Actions (scaleup)
- Integrate Static Application Security Testing (SAST) into the CI/CD pipeline to catch flaws automatically.
- Define explicit security acceptance criteria that must be signed off during the QA process.
Required Actions (enterprise)
- Deploy Dynamic Application Security Testing (DAST) and Interactive Application Security Testing (IAST) for comprehensive runtime analysis.
- Mandate third-party penetration testing before major version releases and enforce automated release gating based on test results.
ISO 27001 A.8.29 security testing in development and acceptance requires organizations to formalize and execute security testing throughout the software creation process. This control ensures that testing is not skipped and that vulnerabilities are detected prior to any system going live.
Defining a security testing process in SDLC involves documenting specific testing phases within the organization's secure development policy. This outlines when peer reviews, vulnerability scanning during development, and formal QA testing must occur before code is merged or deployed. Tools like WatchDog Security's Policy Management can help maintain the secure development policy with version control and attestations that teams acknowledge required testing gates.
Before a system is accepted, organizations should complete static code analysis, dynamic testing, and potentially a penetration testing before production release. These tests validate that the software meets the predefined security acceptance testing criteria and is free of critical vulnerabilities.
Static application security testing (SAST) tools analyze raw source code for flaws without running the application, making them ideal for early development stages. Dynamic application security testing (DAST) tools interact with the compiled, running application to find runtime vulnerabilities like cross-site scripting, best used during staging and QA phases.
Integrating testing into a CI/CD security testing pipeline involves using automated tools that scan code every time a developer commits changes. In a mature DevSecOps security testing model, pipelines are configured to automatically fail builds if high-severity vulnerabilities are detected, preventing insecure deployments.
Common security testing acceptance criteria dictate that software cannot be released if it contains any known 'High' or 'Critical' vulnerabilities based on CVSS scoring. An application security testing checklist is often used by QA teams to verify that these criteria are met and all tests passed before sign-off.
To provide ISO 27001 security testing evidence for audit, teams should save outputs from automated scanning tools, documented QA sign-offs, and third-party penetration test reports. Auditors will review these records alongside change management tickets to confirm that security tests were executed prior to deployment. Tools like WatchDog Security's Compliance Center can centralize these artifacts and map them to A.8.29 for faster evidence retrieval during audits. WatchDog Security's Secure File Sharing can help share penetration test reports with controlled access and audit logs.
Vulnerability scanning during development should occur continuously, ideally triggered by every code commit or pull request. Comprehensive, deeper security testing, such as manual code reviews and dynamic analysis, should be performed at major milestones or the end of each sprint.
A security testing plan should outline the scope of the testing, the specific tools to be used (like SAST vs DAST), the roles responsible for executing the tests, and the timeline. It must also establish the required remediation SLAs for any vulnerabilities discovered during the testing cycle.
Organizations must clearly define security testing requirements within vendor contracts and master service agreements. Outsourced teams should be required to submit their own testing reports, or the organization must subject the delivered code to its own secure software development lifecycle (SSDLC) validation before acceptance.
Security testing generates findings across code, dependencies, and runtime behavior, and teams often struggle to assign ownership, enforce remediation SLAs, and prove fixes were retested before release. Tools like WatchDog Security's Vulnerability Management can centralize findings from multiple sources, support triage workflows, and track MTTR and closure evidence.
Audit readiness typically fails when scan results, QA sign-offs, and pen test reports are scattered across pipelines, tickets, and email threads without a clear evidence trail. Tools like WatchDog Security's Compliance Center can map required evidence to A.8.29, collect artifacts, and make it easier to demonstrate that testing occurred before acceptance.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-17 | WatchDog Security GRC Team | Initial publication |
