Risk Register
A risk register holds identified risks, their assessments, decisions, and changes over time. It includes unresolved risks as well as those with an approved response. NIST’s register guidance separates the risk description and assessment from the response, owner, and status, allowing readers to see both what is known and what remains to be decided.
A newly identified risk may need investigation before a response can be chosen. Record the pending action, responsible person, and due date rather than waiting to add the risk until it is approved. Once a decision is made, preserve its basis and track implementation separately.
Fields that make an entry usable
| Field | What it holds | Why it matters |
|---|---|---|
| Scenario | Cause, event, and consequence in one sentence | Database risk cannot be assessed; a regional outage takes the only database replica offline and orders stop for its duration can. The method is covered in risk assessment |
| Estimate and basis | Likelihood and impact, with the evidence behind them and the time horizon | An estimate without a basis cannot be challenged or updated |
| Decision and status | Selected response and approval, or the assessment/decision still pending; next action and due date | Keep selection, authorization, and implementation distinct. Options are described in risk response |
| Controls in place | What currently reduces likelihood or impact, and how that is known | Distinguishes operating controls from planned ones. See risk control |
| Residual estimate | What is left after those controls | This, not the inherent estimate, is what someone is accepting. See residual risk |
| Owner | Accountable role, current holder, mandate, and deputy or vacancy route | Maintain the mapping and handover; distinguish the risk owner from the authorized acceptor |
| Review trigger | A date, and the events or indicators that bring the review forward | A risk that changes between reviews should not wait for the calendar |
| History | Previous estimates and decisions, with dates | Shows whether the risk is being managed or merely carried |
Keep the risk rating alongside response and implementation status. An accepted exposure, a mitigation under construction, and an assessment awaiting evidence need different follow-up. Record approval conditions and any expiry separately from the next review and task deadlines. A color alone cannot show whether action is overdue.
Mitigation paths are plans with milestones
A mitigation path can be documented in a plan of action with milestones, which records tasks, resources, and scheduled completion dates. An entry that says mitigation planned without those fields can conceal delay, because the word planned can stay true for years. The same structure applied to individual findings is described in vulnerability exception.
How register maintenance fails
- Color lock. An entry sits at the same rating for years. Check whether assumptions and evidence were reviewed; a stable rating alone proves neither stability nor neglect.
- Stale ownership. The role or named person no longer maps to someone accountable, and no deputy or handover is recorded. Either a role or a personal name can become stale.
- Untracked mitigation. An undated plan hides progress and current exposure. Credit only operating, verified controls; record whether remaining exposure has valid acceptance, is awaiting a decision, or requires restriction. The plan itself grants no acceptance.
- Unreconciled scopes. Security, operational, and project registers may legitimately assess the same scenario differently. Link them with a shared scenario identifier, assessment scope and horizon, and clear overall and local responsibilities. Investigate unexplained contradictions, double counting, or gaps in accountability.
- Updates without review. The register is refreshed before a committee meeting by copying last quarter’s entries, which preserves the form and discards the history the definition asks for.
Judging a register
Check whether ownership mappings and approvals remain valid, whether assessments or decisions are overdue, and whether mitigation milestones have evidence of completion. A missed milestone calls for reassessment; renewal is needed when the approval’s scope, period, or conditions require it. Track the last substantive review rather than treating an unchanged rating as proof of neglect. After an incident, compare the prior assessment and documented actions with the outcome; merely having listed the scenario does not show that the register guided action.
How the organization sets direction and applicable limits for risk is covered in risk appetite. How assessment, response, acceptance, ownership, and review fit together for technology risk is worked through in Amber for Three Years.
References
- NIST Computer Security Resource Center Glossary, risk register
- NIST Computer Security Resource Center Glossary, plan of action and milestones
- NIST IR 8286 Rev. 1 — Integrating Cybersecurity and Enterprise Risk Management (2025)
- NIST SP 800-39 — Managing Information Security Risk (2011)
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.