Risk Register

A risk register keeps discovery findings, accepted risks, and mitigation work visible. It should be reviewed with decision-makers, not buried in notes.

Risk fields

Track each risk with:

• Risk statement.
• Affected systems or teams.
• Evidence.
• Impact.
• Likelihood.
• Owner.
• Mitigation or next step.
• Target date.
• Status.
• Decision or acceptance needed.

Risk statement format

Use consequence-focused statements.

Weak:

Secrets are inconsistent.

Better:

Several production services use manually rotated shared credentials,
increasing outage and breach impact if one credential leaks.

Workflow

Review cadence

Review risks during discovery readouts, weekly engagement updates, planning sessions, and after incidents. High risks need named decisions, not passive awareness.

Watchouts

• Risks without owners do not move.
• Accepted risks need expiry or review triggers.
• Too many low-value risks hide the important ones.
• A risk register is not a substitute for fixing urgent production hazards.