Test Risk Register Template

1 What risk-based testing means in practice

Time is always finite. Risk-based testing is the discipline of spending your limited test hours on the parts of the system where a failure would hurt the most. The risk register is the tool that makes that decision explicit and auditable.

In practice this means two things happen before you write a single test case:

You identify risks — anything that could go wrong: a new calculation engine, an untested integration, a supplier who hasn't confirmed their sandbox is ready.
You score each risk so you can rank them objectively, and the team agrees on who owns it and what the mitigation plan is.

Why this matters on NZ government projects: The NZ Government ICT Assurance Framework and many procurement contracts (NZGP, MBIE) require documented evidence that risk was considered when allocating test effort. A completed register is that evidence.

Risk-based testing does not mean skipping tests on low-risk areas. It means if you run out of time, you are confident the high-risk areas got the deepest coverage.

Three types of risk a QA cares about

Product risk — the software itself might behave incorrectly (wrong calculation, security hole, broken integration).
Project risk — external factors that threaten the test effort (environment not available, unclear requirements, resource gaps).
Residual risk — risks that remain after mitigation. You accept them consciously and document them; you don't accidentally leave them undiscovered.

2 5×5 Risk Scoring Matrix

Score each risk on two dimensions from 1 to 5. Multiply to get the Risk Score. The colour band tells you how urgently it needs attention.

Risk Score L × I		Impact (consequence if it occurs)
Risk Score L × I		1 Negligible	2 Minor	3 Moderate	4 Major	5 Catastrophic
Likelihood (chance of occurring)	5 Almost certain	5	10	15	20	25
	4 Likely	4	8	12	16	20
	3 Possible	3	6	9	12	15
	2 Unlikely	2	4	6	8	10
	1 Rare	1	2	3	4	5

1–5 Low — Monitor; test as time allows 6–12 Medium — Mitigate; schedule dedicated test cycles 15–25 High — Escalate immediately; block release without resolution

Scoring tip: Score the risk before mitigations are in place. After you add the mitigation, optionally record the residual score. The before/after comparison shows stakeholders the value of your test effort.

3 Template table

Use this table structure in your test plan. The columns below are the minimum for a compliant register on most NZ government contracts. Add project-specific columns (e.g. Sprint, Budget code) as needed.

Risk ID	Description	Category	Likelihood (1–5)	Impact (1–5)	Score (L×I)	Mitigation	Owner	Status	Review Date
R-001	[Brief description of the risk]	[Technical / Process / Environment / External]	1–5	1–5	Score	[What will be done to reduce likelihood or impact]	[Name/Role]	Open	DD MMM YYYY
R-002	Add rows as risks are identified during planning, discovery, and sprint cycles.

Column guidance

Column	What to write
Risk ID	Sequential prefix (R-001, R-002…). Never re-use or renumber IDs once assigned.
Description	One sentence: what could go wrong and why. Avoid vague labels like "integration risk". Write "Payment gateway may reject tokens if merchant ID is not provisioned before go-live."
Category	Technical, Process, Environment, or External (see Section 4).
Likelihood	1 = rare (<5% chance), 3 = possible (∼50%), 5 = almost certain (>90%). Use team consensus, not one person's gut feel.
Impact	1 = cosmetic / no data loss, 3 = significant user disruption, 5 = financial loss / regulatory breach / data compromise.
Score	Likelihood × Impact. Auto-calculate in a spreadsheet or JIRA.
Mitigation	Specific and actionable. "Add 15 test cases covering boundary values on the calculation module; obtain IRD sandbox access by Week 2."
Owner	The person accountable for driving the mitigation to completion. Usually QA lead, dev lead, or BA depending on category.
Status	Open / Mitigated / Accepted / Closed.
Review Date	When you will reassess this risk. High-score risks should be reviewed at least each sprint.

4 Risk categories with NZ examples

Group risks into four categories. This helps teams route the risk to the right owner and run targeted mitigations.

Technical

Risks in the code, architecture, or integration points.

KiwiSaver contribution calculation logic changed in this release; regression suite not yet updated
New microservice boundary introduced between the assessment engine and the case management system
PDF generation library upgraded from v2 to v4; rendering differences are unknown
Password hashing algorithm migrated; session invalidation logic unclear

Process

Risks in how the project is run: requirements, sign-off, resourcing.

Acceptance criteria for the appeals workflow not finalised by BA; QA cannot confirm done
Team has no-one with RealMe integration experience; spike not scheduled
User stories for Tier 2 support screens being written during the sprint they're meant to be tested
Regression sign-off relies on one tester who is on leave in Week 5

Environment

Risks in infrastructure, test environments, or data availability.

UAT environment not available until Week 4; only two weeks remain for end-to-end testing
Production-equivalent load balancer not replicable in test; performance results may not reflect prod
Anonymised test data set hasn't been refreshed since Q1; new fields missing
CI pipeline fails intermittently on branch builds but not locally; flaky gate

External

Third-party dependencies the team cannot directly control.

IRD API sandbox only available 9am–5pm NZST Monday–Friday; automated nightly tests will fail
Payments provider certification requires 3-week lead time; not yet requested
DIA RealMe integration requires a signed MOU before sandbox access is granted; MOU still unsigned
AWS ap-southeast-2 (Sydney region) had two outages in the past quarter affecting test pipelines

NZ regulatory note

For systems touching personal information held under the Privacy Act 2020, or financial data governed by the Financial Markets Conduct Act 2013, always add a dedicated Compliance sub-category under External. The Office of the Privacy Commissioner and FMA both require documented evidence that privacy and financial data risks were identified and addressed before go-live.

For health data, refer to the Health Information Privacy Code 2020 and consider a separate register row for each data type (NHI, appointment data, clinical notes) even if they share a system boundary.

5 Worked example — NZ Government digital transformation

The following is a six-row risk register for a fictional NZ government agency moving a legacy benefit payment system to a modern cloud platform. The agency must meet Service NSW-equivalent accessibility standards (WCAG 2.2 AA) and the new system integrates with IRD, MSD, and the Payments NZ API framework.

Risk ID	Description	Category	L	I	Score	Mitigation	Owner	Status	Review
R-001	Benefit calculation engine ported from COBOL to Java; porting rules not independently verified against source legislation	Technical	4	5	20	Commission 3-way calculation parity tests: COBOL output vs Java output vs manual spreadsheet across 500 representative cases. Block release if parity <100%.	QA Lead	Open	15 Jul 2026
R-002	IRD API sandbox restricted to NZST business hours; automated regression suite runs at 2am and will generate false negatives	External	5	3	15	Mock IRD responses for overnight pipeline; run live sandbox validation as a manual gate on Friday afternoons. Document mock limitations in test report.	Dev Lead	Mitigated	22 Jul 2026
R-003	UAT environment provisioning delayed; infrastructure team estimate delivery in Week 4 of a 6-week test phase	Environment	4	4	16	Front-load component and integration testing in lower environments. Prepare UAT test packs in Weeks 1–3 so execution can begin immediately on provisioning. Escalate to Programme Director if Week 4 deadline slips.	BA / Env Team	Open	1 Jul 2026
R-004	WCAG 2.2 AA accessibility audit not yet scheduled; an unchecked failure on citizen-facing forms could breach DIA web standards	Process	3	4	12	Book Deque or CivicActions audit for Week 3. Run axe-core automated scan in CI from Week 1 to catch easy wins early. Assign a11y sign-off to QA.	QA Lead	Mitigated	8 Jul 2026
R-005	Payments NZ scheme certification has a 3-week SLA; certification request not yet submitted with 5 weeks to go-live	External	3	5	15	Submit certification request this week. Identify fallback payment path (manual bank transfer) if certification is not returned in time. Track daily with vendor.	Programme Manager	Open	29 Jun 2026
R-006	Test data set does not include edge-case NHI numbers (individuals with name suppression orders); suppression logic untestable	Technical	2	4	8	Generate synthetic NHI records with suppression flag set via Ministry of Health sandbox generator. Review Privacy Act obligations before loading into UAT.	QA / Privacy Officer	Accepted	20 Jul 2026

Status definitions used above: Open = risk identified, mitigation not yet in place. Mitigated = mitigation applied, residual risk reduced. Accepted = risk understood, team consciously choosing not to mitigate further. Closed = risk no longer relevant (feature descoped, environment fixed, etc.).

6 How to prioritise test effort

Once your register is scored, use the following decision table to allocate your test hours. Sort by Risk Score descending, then apply these effort bands:

Score	Band	Test effort allocation	Cycle recommendation	Release gate
15–25	High	Maximum — dedicated test cycles, pair testing, exploratory charter	Test in every sprint; regression before every release	Must be Mitigated or Accepted with written sign-off before release
6–12	Medium	Standard — scheduled test cases and at least one regression pass	Test in the sprint where work lands; regress at release	Should be Mitigated; Accepted risk requires QA Lead approval
1–5	Low	Light — smoke test and happy-path coverage	Test on completion; skip regression if no change	Accepted or Closed is sufficient; no formal gate

Practical rules for using the register during sprints

Revisit at sprint planning: New stories may introduce new risks, or existing risks may change score as more is known. The register is a living document, not a one-time artefact.
Link risks to test cases: In your test management tool (Zephyr, Xray, TestRail), tag test cases with a Risk ID. This makes it trivial to show which risks have test coverage at audit time.
Never accept a High risk silently: Accepted status on a score of 15+ must have a named approver, a written rationale, and a review date. "We didn't have time" is not an accepted rationale for a government system.
Score before and after mitigation: Recording the residual score demonstrates the value of the testing work. A risk that moves from 20 to 8 after mitigation is a tangible outcome.
Report weekly on open Highs: At the weekly project status meeting, surface all risks with Score ≥15 and Status = Open. These should be visible on the project dashboard, not buried in a spreadsheet tab.

Connecting to test estimation

Risk score directly drives test effort estimates. A common heuristic used on NZ government programmes:

Score 20–25 → multiply base test-case count by 2.5 (full exploratory + scripted + regression)
Score 15–19 → multiply by 1.75
Score 6–12 → multiply by 1.25
Score 1–5 → multiply by 1.0 (no uplift)

Run this through your team's velocity to get a sprint-by-sprint test capacity plan. See the Test Estimation technique page for the full formula.

7 Copy-Paste Block

Copy the markdown table below into your test plan, Confluence page, or README. Replace the placeholder rows with your project's risks.

| Risk ID | Description | Category | Likelihood (1-5) | Impact (1-5) | Score (L×I) | Mitigation | Owner | Status | Review Date | |---------|-------------|----------|-----------------|-------------|-------------|------------|-------|--------|-------------| | R-001 | [Brief description — what could go wrong and why] | Technical | 3 | 4 | 12 | [Specific, actionable mitigation steps] | [Name / Role] | Open | DD MMM YYYY | | R-002 | [Third-party dependency risk] | External | 4 | 3 | 12 | [Mock, escalate, or workaround plan] | [Name / Role] | Open | DD MMM YYYY | | R-003 | [Environment availability risk] | Environment | 3 | 3 | 9 | [Front-loading or escalation plan] | [Name / Role] | Open | DD MMM YYYY | | R-004 | [Process or resourcing risk] | Process | 2 | 4 | 8 | [Process change or resource plan] | [Name / Role] | Open | DD MMM YYYY | **Score bands:** - 15–25 (High) → Block release until Mitigated or formally Accepted with sign-off - 6–12 (Medium) → Mitigate; Accepted requires QA Lead approval - 1–5 (Low) → Monitor; Accepted or Closed sufficient **Status values:** Open | Mitigated | Accepted | Closed **Categories:** Technical | Process | Environment | External **Likelihood scale:** 1 = Rare (<5%) | 2 = Unlikely | 3 = Possible (~50%) | 4 = Likely | 5 = Almost certain (>90%) **Impact scale:** 1 = Negligible | 2 = Minor | 3 = Moderate | 4 = Major | 5 = Catastrophic

For a spreadsheet version, this same structure translates directly to a Google Sheets or Excel table. Add a formula column: =D2*E2 (where D = Likelihood, E = Impact) and apply conditional formatting using the colour bands from Section 2.