A.8.29
Security testing in development and acceptance
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control ensures that systems/applications being developed or acquired are tested to confirm they actually meet the defined security requirements before they are moved into the operational environment. Security testing should be planned and performed throughout the development life cycle, and at the acceptance stage (transfer to operations/purchased-product adoption) results should be verified and approved against pre-established acceptance criteria. This ensures vulnerabilities are found and removed before they reach production and that test results serve as the basis for release approval.
Key checkpoints
- Are the scope, methods, timing, and responsible parties for security testing planned and documented in advance for the target of development/acquisition?
- Is testing designed against the security requirements defined in A.8.26, with traceability maintained between requirements and test cases?
- Are security testing techniques appropriate to the system's risk level applied, such as static/dynamic analysis, vulnerability assessment, and penetration testing?
- At the acceptance stage (transfer to operations/adoption of purchased products), are acceptance criteria defined in advance and are test results verified and approved against those criteria?
- Are discovered vulnerabilities/defects remediated and re-tested according to severity, and is residual risk reflected in release approval?
- Are security test data sensitivity and usage basis assessed, production-data exceptions approved and protected, and test records retained?
Implementation guidance
- Establish a security testing plan aligned with the development life cycle (A.8.25), and vary the test scope and depth (code review, vulnerability assessment, penetration testing, and so on) according to the system's risk rating and exposure environment.
- Translate the security requirements from A.8.26 and the architecture/engineering principles from A.8.27 into concrete test cases, and maintain traceability by linking requirement IDs to test cases so nothing goes unverified.
- During development, integrate static analysis (SAST), software composition analysis (SCA/dependency vulnerability scanning), and secret scanning into the CI pipeline for early defect detection, and complement these with dynamic analysis (DAST)/fuzzing against the running environment.
- At the acceptance stage, define pass/fail criteria (acceptable residual risk, severity-based remediation thresholds) in advance, and approve transfer to operations only when the acceptance testing (secure configuration review, penetration test result review) is passed.
- For purchased/externally sourced products (including SaaS), review the security test/certification results provided by the supplier and, where necessary, perform independent vulnerability assessment to confirm the product meets adoption requirements (linked to A.5.20 and A.5.21; A.5.23 for SaaS; A.8.30 for custom outsourced development).
- Prefer synthetic/transformed data and assess re-identification and source-data disclosure risk (A.8.11, A.8.33). Where real data is essential, apply a lawful basis, owner approval, minimum scope/duration, and restricted access. Retain remediation, retest, and residual-risk approval records.
Evidence
- Security testing plan (scope/methods/timing/responsible parties) and a traceability matrix between requirements and test cases
- Static/dynamic analysis, vulnerability assessment, and penetration test reports, plus CI pipeline security scan logs
- Acceptance test pass criteria and acceptance/transfer-to-operations approval records
- Records of vulnerability remediation, re-test results, and residual-risk acceptance approvals
- Review of supplier security test/certification results and adoption approval documents for purchased/acquired products
- Test data controls (use of pseudonymized/synthetic data) and evidence of test record retention
Nonconformity examples
- Only functional testing is performed without a security testing plan, and the system is transferred to operations.
- There are no test cases linked to security requirements, so the system is released without those requirements being verified.
- High-risk test findings reach production without remediation/retesting required by acceptance criteria or authorized exception approval and necessary compensating controls.
- Acceptance (transfer-to-operations) pass criteria are not defined in advance, so approval decisions are made arbitrarily.
- Purchased/externally sourced products are adopted without reviewing their security test results.
- Live production/personal data is used for security testing without controls.