Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.29 — Security Testing in Development and Acceptance

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.29 ISO 27001ISO 27002BSI OPS.1.1.6

The release passes all automated tests and the development team certifies it as ready. A week after launch, a security researcher reports a critical authentication bypass that allows access to any user’s account. The issue would have been caught by a standard penetration test. A.8.29 ensures that security testing is an integral part of the release process — with defined criteria that must be met before code reaches production.

Automated security tools catch known patterns. Manual testing catches logic flaws. Both are needed. This control requires a structured security testing approach that covers functional security features, secure coding validation and configuration hardening.

What does the standard require?

  • Plan security testing. Define what to test, which methods to use, expected outcomes and acceptance criteria — based on the system’s criticality and risk profile.
  • Test security features. Verify that authentication, authorization, encryption and other security mechanisms work as designed.
  • Validate secure coding. Confirm that the code is free from common vulnerability classes (OWASP Top 10, CWE Top 25).
  • Verify configurations. Check that security configurations (TLS settings, headers, error handling) meet policy requirements.
  • Use automated and manual methods. Combine SAST, DAST, SCA and manual penetration testing.
  • Test in realistic environments. Use staging environments that mirror production for accurate results.
  • Address outsourced components. Security testing requirements apply to externally developed or acquired components.

In practice

Integrate DAST into the pipeline. Run dynamic application security testing against the staging environment for every release candidate. Tools like OWASP ZAP, Burp Suite or Nuclei can be automated in the CI/CD pipeline.

Conduct annual penetration tests. For critical and internet-facing applications, commission annual manual penetration tests by qualified testers. Track all findings to remediation and verify fixes.

Define acceptance criteria per risk level. High-risk applications: no critical or high findings, all OWASP Top 10 tested, manual pentest for every major release. Medium-risk: automated SAST/DAST, manual pentest annually. Low-risk: automated testing with peer review.

Test third-party components. When integrating purchased or outsourced software, require security test results from the vendor. Where possible, conduct your own security assessment before deployment.

Typical audit evidence

Auditors typically expect the following evidence for A.8.29:

  • Security test plan — documented testing approach with scope and criteria (see Secure Software Development Policy in the Starter Kit and Pentest Report)
  • SAST/DAST reports — automated scan results per release
  • Penetration test reports — annual pentest results with findings
  • Remediation tracking — evidence that findings are tracked to closure
  • Go-live approval records — documented approval based on test results

KPI

Percentage of releases with completed security testing before production deployment

Measured as a percentage: how many production deployments had all required security tests completed and passed before go-live? Target: 100%.

Supplementary KPIs:

  • Number of security findings found in production vs. pre-production
  • Mean time to remediate security test findings
  • Percentage of critical applications with annual penetration test

BSI IT-Grundschutz

A.8.29 maps to BSI modules for software testing:

  • OPS.1.1.6 (Software Testing and Approval) — requirements for security testing before production deployment, including functional testing, vulnerability scanning and formal acceptance.

Sources

Frequently asked questions

What types of security testing are expected?

A layered approach: static analysis (SAST) during development, dynamic analysis (DAST) against running applications, software composition analysis (SCA) for dependencies, and manual penetration testing for complex logic. The mix depends on the application's risk profile.

Is penetration testing mandatory?

ISO 27001 does not mandate penetration testing specifically, but A.8.29 requires validation that security requirements are met before deployment. For internet-facing or high-risk applications, manual penetration testing is the de facto expectation.

Should we test in production or in a staging environment?

Test in a staging environment that mirrors production. Testing in production risks downtime and data exposure. If production testing is necessary (e.g., for infrastructure validation), schedule it during maintenance windows and coordinate carefully.