Risk registers
Track a risk scenario, its owner, decisions, and progress over time.
The idea
A risk register is a structured record of identified risks and their management. It should include the scenario, affected resources, assessment, owner, treatment, actions, status, and review date. Distinguish the risk itself from a remediation task. A register becomes useful when it supports prioritization and follow-up rather than merely collecting entries. Link supporting evidence and record changes in assumptions or residual risk.
In practice
A risk about prolonged payroll outage has an owner, agreed recovery improvements, due dates, and a review of remaining exposure after those actions.
A common misunderstanding
Closing a task does not automatically eliminate the risk. The expected effect must be verified and reassessed.
Check your understanding
What should a risk review ask?
Think it through: Whether the scenario, controls, ownership, progress, and accepted residual risk remain accurate.
Track a decision, not only a concern
A risk register gives an organization a persistent record of risk scenarios and their management. Useful entries identify the affected activity, scenario, owner, assessment context, chosen response, actions, and review point. A title and a colored score alone do not show what somebody is expected to do or why the current position is acceptable.
Distinguish the risk owner from an action owner. The person accountable for a service's risk may ask engineers to implement a control, procurement to negotiate a supplier term, or operations to test recovery. Completing one action does not necessarily remove the risk. Review what exposure remains after the action and whether the assumptions still hold.
A fictional stale entry
An academy records a risk about a shared administrator account and assigns an action to introduce named accounts. Months later, the action is marked complete, but a legacy integration still uses the shared identity. The risk register should reflect that remaining exposure and the decision about it, rather than close the scenario because most of the work finished.
Review triggers can include a changed service, new threat information, an incident, a failed test, or an agreed date. Keeping every entry forever without reassessment makes the register harder to use. Retain history while distinguishing active risks, accepted positions, and scenarios that no longer apply.
Create a reviewable row
For a fictional backup dependency, write the scenario, business effect, owner, existing protection, planned action, and review trigger. Add evidence that would justify reducing the assessed exposure. Then explain who can accept the remaining risk. A good entry should allow a new reviewer to understand the position without reconstructing the original meeting from memory.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
NIST: Guide for Conducting Risk Assessments