Risk Register Template with Worked Examples

What a risk register should do

A business risk assessment identifies the scenarios to retain. A risk register should let someone understand an exposure, find its owner and see the next decision. It is not merely a numbered list of worries. A usable row connects a scenario to current safeguards, evidence, a response and a date for reassessment.

NIST IR 8286A Revision 1 describes scenario-based cybersecurity registers as part of enterprise risk communication.¹ The template here adapts that logic for a growing business. It is an original working aid, not a mandated schema or a claim that one spreadsheet satisfies an external framework.

Begin with the smallest set of fields your owners can keep accurate. Add detail when it changes a decision or helps another reviewer understand the record.

The core template

Field	What to record	Why it matters
Risk ID and activity	Stable reference and business process	Connects actions and evidence without repeated descriptions
Scenario	Condition, event and business consequence	Makes the risk assessable
Scope and horizon	Systems, service and time period	Prevents misleading comparisons
Risk owner	Person responsible for managing the record	Avoids ownerless exposure
Existing controls	Safeguards currently operating	Separates current state from planned work
Evidence and gaps	Dated records, sources and uncertainty	Explains confidence in the assessment
Current estimate	Defined likelihood and consequence, with reasons	Supports prioritization
Response and action owner	Decision, task and responsible performer	Turns assessment into work
Due date and completion test	Deadline and evidence needed to finish	Prevents vague closure
Acceptance and review	Authority, rationale, expiry and next check	Makes retained risk a deliberate decision

Use additional fields for inherent or target risk only if the distinction helps your team. Define them in the register instructions. A future target belongs alongside a proposed treatment, not in the current-risk column.

Write a scenario, not a topic

“Data security” is a topic. “Because two former contractors still have access to client files, an account compromise could expose confidential documents” is a scenario. It identifies a condition that can be checked, an event that could happen and an effect that matters.

Use one principal event per row. If the same account could expose information and delete working records, either show the distinct consequence clearly or create linked scenarios where treatments differ. Do not duplicate identical risks just because several teams own related controls.

Name dependencies without exposing secrets. The register can reference an authorized system inventory rather than list account credentials, sensitive customer records or exploitable technical details in a widely shared sheet.

Worked record 1: a payroll dependency

The following fictional record uses descriptive estimates. It is not a benchmark for another company.

Field	Example entry
ID and activity	R-017, monthly payroll
Scenario	An unavailable payroll provider prevents payment instructions being approved before the bank cutoff
Horizon	Next three payroll cycles
Owner	Finance manager
Current controls	Earlier draft preparation; contact escalation; separate approval
Evidence	Recent processing logs and approved payroll timetable
Gap	No checked alternative submission procedure
Estimate	Significant consequence; likelihood uncertain because provider incident data is incomplete
Response	Document and rehearse an authorized fallback using synthetic data
Action owner	Payroll lead, with bank process confirmation from finance
Completion	Retained rehearsal record demonstrating the fallback and its limits
Review	Before the next cycle, or after provider/process changes

The approval control protects against unauthorized instructions. It may not help when the provider is unavailable. The register should describe each control's role rather than treat any nearby safeguard as complete mitigation.

Worked record 2: access left behind

This second fictional record illustrates a different evidence problem. A design agency has a documented departure process, but its completion records cover only email accounts.

The risk owner writes: “Because departures do not consistently include project-file tools, unused accounts may retain access to client material after the engagement ends.” Current control evidence supports email removal but not file-tool removal.

The treatment has two parts: reconcile the authorized account inventory, then test a departure against the revised checklist. The completion test is a record showing every scoped system checked, exceptions explained and access removed where appropriate.

The owner does not lower the current estimate when the new checklist is drafted. A draft is future work. The estimate is revisited after implementation and relevant evidence, with the prior rating retained.

Keep evidence links meaningful

An evidence field should identify the record, covered system, relevant period and access location. “See folder” rarely gives another person enough context.

NIST SP 800-53A distinguishes examination, interview and testing as assessment methods.² Use that distinction to describe your confidence. An interview may explain how a process is intended to work; a sample of completed records can show something about operation; a controlled test can reveal whether a specific scenario works.

Do not attach sensitive evidence indiscriminately. Give reviewers the access they need, preserve source integrity and use references where copying would create unnecessary exposure. Record unavailable or stale evidence as a gap rather than silently substituting a policy.

Define estimates before comparing rows

If you use a numeric scale, publish definitions with the template. The risk-matrix guide explains score limitations and escalation rules. State the horizon, consequence dimensions and how the team handles rare but severe events. Different owners should be able to explain why similar scenarios received different ratings.

NIST SP 800-30 addresses uncertainty and structured risk analysis.³ For this register, add a plain confidence statement such as “low, because outage duration is based only on a supplier claim.” Confidence is not a second arbitrary score; it explains what needs checking.

Do not average safety, privacy and financial consequences into a number that hides an unacceptable outcome. Escalation rules can sit alongside the matrix, with clear authority for significant decisions.

Turn treatment into a checkable action

Write the response decision first, then the actions required. A decision to reduce exposure may produce several tasks. Each task needs an action owner and a completion criterion; the risk owner remains responsible for reviewing the combined result.

“Improve vendor security” is not complete enough. “Confirm whether the provider supports an export of scoped records, perform a synthetic export and document a recovery dependency” is more useful.

Acceptance should record who approved it, the rationale, conditions and expiry. “Accepted by team” obscures authority. A risk may remain open while a time-limited acceptance permits continued work under specific conditions.

Maintain the register without turning it into an archive dump

At each review, check overdue actions, expired acceptances, changed dependencies and stale evidence. Keep completed actions and superseded ratings in the history, while making current state easy to find.

Use statuses that distinguish proposed, active, under verification, accepted with conditions and closed after review. A task marked done does not automatically close its parent risk. Closure requires a reviewer to confirm the agreed criteria and record remaining exposure.

The most useful register review asks three questions: what changed, what decision is required and what evidence supports the answer? If an extra column does not improve those answers, the team may not need it.

Sources and references

NIST. Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management, IR 8286A Revision 1 (2025-12-18). Current revision supports scenario-based risk registers and likelihood/impact estimates; supersedes the 2021 publication. ↩
NIST. Assessing Security and Privacy Controls, SP 800-53A Revision 5 (2022-01). Describes examination, interview and testing methods; source examples are adapted, not a claim to meet federal requirements. ↩
NIST. Guide for Conducting Risk Assessments, SP 800-30 Revision 1 (2012-09). Risk-assessment guidance originally developed for federal information systems; business examples here are an adaptation. ↩