Scenario and consequence
Record the business objective, asset or process, threat event, vulnerable or predisposing condition, and a complete risk statement. This preserves the causal chain that a short risk title cannot explain.
Free editable CSVNIST-informed structure
Free cybersecurity risk register template
Download an ungated CSV that turns cyber risk from a vague color into a reviewable decision. The template connects a threat event and vulnerable condition to the business objective at risk, existing controls, likelihood, impact, treatment, accountable owners, evidence, residual risk, and the event that should trigger the next review.
Eight clearly labeled example records show how the fields work. Replace them with your organization’s facts, definitions, authority, and evidence. No email address is required, and the file contains no macros or executable formulas.
What you get
A register built around decisions, not decorative scoring.
The fields are intentionally plain enough for a spreadsheet and structured enough for a later import into governance, risk, compliance, ticketing, or reporting software.
Analysis and controls
Capture existing safeguards, likelihood, impact, inherent score, residual likelihood, residual impact, and residual score. Evidence references make it possible for another reviewer to test the assumptions.
Decision and accountability
Name the response, treatment action, risk owner, treatment owner, target date, status, acceptance authority, last review, and next review or event trigger. A risk without authority and follow-through is only an observation.
Why the download includes examples
A blank grid rarely teaches a team how to distinguish a threat from a vulnerability, a control from evidence, or a risk owner from a treatment owner. The example records are explicitly marked EXAMPLE and cover identity, internet-facing software, backups, suppliers, service accounts, cloud storage, logging, and network resilience. Delete or overwrite every example before treating the register as an organizational record.
Risk statements
Write a scenario that can be challenged and treated.
A useful statement identifies a plausible cause, event, and consequence. Avoid labels such as “ransomware risk,” “cloud risk,” or “lack of MFA” that do not say what could happen or why it matters.
Cause or condition
Describe the exposure that makes the event plausible: weak recovery controls, unsupported software, excessive privilege, incomplete logging, a supplier dependency, public access, or a single point of failure. Be precise enough that a treatment owner can change the condition.
Threat event
State the event that may occur, such as credential phishing, exploitation of an internet-facing service, destructive malware, provider outage, accidental public sharing, unauthorized administrative activity, or failure of a critical circuit.
Consequence
Connect the event to a mission or business result: service interruption, unsafe operations, loss of confidentiality, unreliable records, financial loss, inability to meet obligations, delayed recovery, or loss of public trust. Do not stop at a technical symptom.
Reviewable example
“Because privileged cloud administrators can enroll phishable authenticators, a targeted phishing event could compromise the control plane, allowing unauthorized configuration or data access and causing material service and confidentiality impact.” The statement can be tested, assigned, and treated.
Likelihood and impact
Define the scale before multiplying the numbers.
The example CSV uses a simple one-to-five likelihood and impact model and records the product as an inherent or residual score. That arithmetic is a convenience, not an objective measurement of loss. Two teams can produce the same number from very different assumptions, so retain the scenario, evidence, scale definitions, and decision notes beside the score.
Likelihood should reflect evidence
- Threat activity and credible exposure.
- Ease of exploitation or occurrence.
- Frequency and duration of the condition.
- Coverage and effectiveness of existing controls.
- Relevant incidents, findings, tests, and near misses.
- Uncertainty and missing telemetry.
Impact should reflect objectives
- Mission and service disruption.
- Safety and operational consequences.
- Confidentiality, integrity, and availability.
- Financial, contractual, legal, and regulatory effects.
- Recovery time and dependency concentration.
- Customer, workforce, partner, and public consequences.
Document what each value means for your organization. For example, a five for impact might require an outage beyond a defined duration, loss of a critical function, severe safety consequence, high-volume sensitive-data exposure, or an enterprise-level financial threshold. A five should not mean merely “very bad.” Keep escalation and acceptance authority separate from color bands so a serious scenario cannot be normalized by adjusting a heat-map threshold.
Treatment and residual risk
Record the decision, the owner, and the proof that conditions changed.
Mitigate
Describe a specific change with an accountable treatment owner, target date, acceptance criterion, and evidence. “Implement MFA” is weak. “Require phishing-resistant authentication for privileged cloud administration and verify complete enrollment from the identity platform” is testable.
Avoid, transfer, or share
Avoidance may remove the exposed activity or system. Transfer or sharing may allocate defined consequences through contracts or insurance. Neither choice removes the organization’s responsibility to understand dependencies, residual exposure, and whether the counterparty can perform.
Accept
Acceptance should identify the approving authority, rationale, known residual consequence, compensating safeguards, monitoring expectation, expiration or review date, and event that reopens the decision. Silence, delay, or a closed ticket is not risk acceptance.
Verify residual risk
Do not lower a score because work was scheduled or a tool was purchased. Confirm the intended control exists, covers the relevant population, operates as expected, and changes the scenario. Link the verification evidence, then reassess likelihood and impact.
Using the CSV
Turn the starter file into an operating register.
The download opens in common spreadsheet software and can also be imported into many data, ticketing, and governance tools. Preserve a controlled authoritative copy rather than circulating conflicting versions.
1. Tailor the definitions
Agree on scope, risk statement structure, likelihood and impact definitions, scoring bands, treatment choices, ownership roles, acceptance authority, evidence expectations, review cadence, and escalation thresholds. Record those definitions outside the individual rows.
2. Replace the examples
Delete the eight sample records. Build new scenarios from assets, business processes, architecture, incidents, vulnerabilities, exceptions, supplier reviews, recovery tests, audit findings, and planned changes. Avoid copying a generic risk library without validating relevance.
3. Assign two kinds of owner
The risk owner is accountable for the business consequence and treatment decision. The treatment owner is accountable for the work that changes the condition. They may be the same person in a small organization, but the roles should remain explicit.
4. Link evidence safely
Reference authoritative records such as architecture diagrams, test results, scan summaries, restore evidence, policy exceptions, supplier reviews, tickets, and decision minutes. Do not place passwords, tokens, private keys, regulated records, or unnecessary personal data in the CSV.
5. Set review triggers
Use both dates and events. Reopen a risk after a material incident, significant architecture change, new public exposure, supplier change, failed control test, missed treatment date, major vulnerability, acquisition, recovery failure, or change in mission criticality.
6. Report without hiding meaning
Summaries may group risk by objective, owner, supplier, technology, or theme, but preserve the underlying scenario and evidence. Leadership needs to see material exposure, overdue actions, accepted-risk aging, concentration, uncertainty, and decisions that require authority.
Governance
Keep the register connected to enterprise decisions.
NIST IR 8286 Rev. 1 explains the value of integrating cybersecurity risk information into broader enterprise risk management, while IR 8286A Rev. 1 addresses risk identification and analysis. A practical register should therefore connect technical conditions to strategic objectives and allow important risks to move upward without losing the scenario, owner, assumptions, and evidence that give them meaning.
Establish a review forum with authority to resolve ownership disputes, approve or reject treatment, fund cross-functional work, address dependency concentration, escalate missed commitments, and record acceptance. Risk staff may facilitate the method, but they should not silently become the owner of every operational and business consequence.
Protect the register according to its contents. It may reveal vulnerable systems, control gaps, supplier weaknesses, recovery limitations, sensitive processes, and executive decisions. Apply appropriate access control, versioning, retention, backup, and disclosure handling. A public template can be open; a completed enterprise register usually should not be.
Review quality as well as quantity. Useful measures include unowned material risks, overdue treatment, stale evidence, accepted risks approaching expiration, repeated scenarios, concentration in shared suppliers or control planes, and score reductions without verification. More rows do not necessarily mean a more mature program.
Primary sources
Use the current NIST material and your organization’s authority.
- NIST IR 8286 Rev. 1 — Integrating Cybersecurity and Enterprise Risk Management, including NIST’s own supplemental risk-register schemas.
- NIST IR 8286A Rev. 1 — Identifying and Estimating Cybersecurity Risk.
- NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments.
- NIST Cybersecurity Framework 2.0 Resource Center.
This Zeph Tech CSV is an independent starter template, not a NIST publication and not legal, audit, insurance, or regulatory advice. Tailor it to your organization’s mission, risk appetite, assessment method, legal obligations, records requirements, and delegated decision authority. For complex enterprise integration, also review NIST’s official supplemental risk-register and risk-detail schemas linked from IR 8286 Rev. 1.