Risk Register

Risk Register

The Risk Register captures uncertainty before it becomes a defect, delay, or launch incident. Record a risk when an uncertain future event could materially affect data integrity, customer experience, SEO, operations, timeline, compliance, integrations, target-store readiness, or service scope.

Do not use the register as an issue log for defects that have already occurred. Once a risk becomes an observed problem, record the actual finding in Validation, Redirects, the relevant task, or the appropriate support evidence.

Describe the risk in operational terms

A useful risk row connects cause or uncertainty to a business consequence.

Field group	Fields	How to use them
Identity	Risk ID, Related Task IDs	Give the risk a stable reference and connect it to the work it can affect.
Exposure	Business Impact Area, Risk Statement	Describe what could happen and why it matters to the project.
Inherent risk	Likelihood (1-5), Impact (1-5), Inherent Score, Inherent Level	Estimate exposure before the planned control is considered. Score and level are calculated automatically.
Control	Mitigation / Control, Owner, Due Date, Trigger / Early Signal	State how exposure will be reduced or monitored, who is responsible, and what evidence signals the risk is becoming real.
Risk state	Status, Response, Review Date	Track whether the risk is open, monitored, mitigated, accepted, or closed and what treatment strategy is being used.
Residual risk	Residual Likelihood, Residual Impact, Residual Score, Residual Level	Reassess exposure after the planned control is considered.
Evidence	Evidence Link, Notes	Link to risk evidence, approved treatment, or supporting analysis without storing sensitive material directly in the workbook.

Understand the score and level

Both inherent and residual scores use Likelihood × Impact with 1 to 5 entered for each dimension.

Score	Level
1-4	Low
5-9	Moderate
10-16	High
17-25	Critical

The numerical score is a prioritization aid, not a substitute for judgment. A lower-frequency event can still require immediate action when its impact is severe or when it affects a launch gate.

Choose a response deliberately

The workbook provides Reduce, Accept, Avoid, Transfer, and Close as risk responses.

• Reduce when a control can lower likelihood, impact, or both.
• Accept when the remaining exposure is understood and authorized.
• Avoid when the project should change the plan to remove the exposure.
• Transfer when responsibility or exposure is deliberately assigned to another controlled party or mechanism.
• Close when the uncertainty no longer applies and the closure evidence is known.

An accepted risk should still have an owner, rationale, review point, and any required decision record.

Use triggers to make risks actionable

A trigger should be observable. Examples include a representative Demo sample showing a relationship mismatch, a priority URL returning an unexpected response, a required access owner becoming unavailable, or a project date moving inside a critical lead-time window.

When a trigger occurs:

1. Update the risk Status and evidence.
2. Open the related task or validation item. Record the observed condition where the team will manage the actual work.
3. Apply or revise the mitigation. Assign a clear corrective owner and due date.
4. Reassess residual exposure. Do not leave the residual score unchanged after the control or project context changes.
5. Create a decision record when authorization is required. Accepted limitations, scope changes, launch exceptions, and go-live decisions belong in Decisions & Sign-off.

High residual risk requires explicit attention

Project Overview counts residual High and Critical risks as readiness blockers. Reduce, avoid, transfer, or explicitly authorize the exposure before treating the project as ready for review.

Next Steps

Translate risks that need proof into representative checks in Validation evidence. Use Define Acceptance Criteria when the pass condition or sample strategy has not yet been established.