Summary
A testing policy must be defined that specifies the categories and scope of testing required before any change is released to production, proportionate to the risk profile of the change.
Description
This control establishes the policy layer of the organisation’s testing posture: what types of testing must be performed and when. It does not govern whether the testing was actually executed (SDLC-PREV-016), whether it was enforced mechanically (SDLC-PREV-012), or whether the results were retained (SDLC-PREV-014). Its sole concern is that the organisation has defined, documented, and maintains a testing policy that maps required testing activities to change types.
The testing policy definition defines what degree of testing applies to different change types. This is particularly critical with manual testing due to the overall expense and you may wish to define when it is or is not appropriate to run which suites of testing. Without an explicit testing policy, testing decisions are left to individual judgement and vary across teams, repositories, and release cycles. This creates inconsistency, makes audit response difficult, and means the organisation cannot demonstrate that its testing expectations were defined in advance rather than rationalised after the fact. In regulated financial services environments, examiners expect a documented testing standard that exists independently of any individual release.
The policy must address the full spectrum of change types — from low-risk configuration updates to security-sensitive changes — and define what testing is required for each. It should be specific enough to be enforceable and auditable, but not so prescriptive that it cannot accommodate the diversity of technologies and delivery patterns within the organisation.
Requirements
- A testing policy MUST be defined that specifies the categories of testing required for each change classification (e.g., patch, minor feature, major release, infrastructure change, security-sensitive change)
- The policy MUST define a minimum testing baseline that applies to all changes regardless of classification; this baseline MUST include at minimum regression testing to confirm that existing behaviour is not broken
- Changes to security-sensitive components — including authentication, authorisation, session management, cryptographic operations, and data handling — SHOULD require targeted security testing in addition to functional testing
- Changes to critical code path that have ben identified as being partocularly sensitive to the application SHOULD require additional testing.
- The policy MUST define minimum code coverage thresholds per repository or service, with documented rationale for the chosen threshold appropriate to the risk profile of the component
- The policy MUST specify exit criteria that define what constitutes a passing test outcome for each change classification, including acceptable treatment of pre-existing known failures
- The testing policy MUST be reviewed at least annually, or when significant changes to the technology stack, threat landscape, or regulatory requirements occur
Examples & Commentary
- Change Classification: Define a simple taxonomy of change types and map required testing to each. For example: a dependency patch may require automated unit and integration tests plus a DAST scan; a new customer-facing feature may additionally require functional UAT and a targeted security review; a change to the authentication flow may require penetration testing or red team exercise sign-off before release
- Coverage Thresholds: Define thresholds appropriate to the risk profile of each repository — a payment processing service may require 80% line coverage, while an internal tooling repository may set a lower bar. Document the rationale for the chosen threshold in the repository’s governance documentation
- Exit Criteria: Define release readiness criteria before testing begins, not after. Criteria should specify: no new test failures introduced by the change without documented acceptance; code coverage must not fall below the defined threshold; no new critical or high SAST or DAST findings introduced unresolved; security sign-off obtained for security-sensitive changes. Pre-existing failures that are known, tracked, and unrelated to the change may be accepted without blocking release, provided they are documented. Vague or unwritten criteria are easily gamed and do not provide meaningful assurance ase. SDLC-PREV-014 (Test Evidence Retention) ensures the records of completed testing are preserved. All three are required for a complete testing assurance posture
- Penetration Testing: Is usually an expensive practice sometimes dedicated to a sat of experts who will testing manually or semi-automatically to see if they can breach the system overall. Doing such testing on every release may not be advisable or cost effective, especially if the release was small. This practice will need to be defined somewhere.