Risk Register

To meet the risk register requirement, you must maintain a living, auditable record of cybersecurity risks that captures each risk’s description, analysis, treatment decision (accept/mitigate/transfer/avoid), owner, due dates, and current status, and you must keep it current as risks change. For C2M2, this is explicitly required to track identified cybersecurity risks and their treatment status ¹.

Key takeaways:

• A “risk register” is a controlled system of record, not a slide deck or one-time assessment output ¹.
• Auditors look for traceability: risk intake → analysis → decision → remediation tracking → closure or acceptance evidence ¹.
• Document your criteria, inputs, reviewers, and decision process, then retain the outputs and management decisions ¹.

A risk register is the operational backbone of your cybersecurity risk program because it is where identified risks get translated into decisions and tracked work. Under C2M2 v2.1 RISK-1.D, the expectation is straightforward: establish and maintain a risk register that tracks identified cybersecurity risks and their treatment status ¹. The hard part is not building a spreadsheet. The hard part is making the register authoritative, consistently populated, and tied to how work actually gets prioritized and approved.

If you are a CCO, CISO, GRC lead, or compliance officer supporting an environment that has adopted C2M2 (often in energy or other critical infrastructure contexts), the risk register is also your best “show me” artifact. It demonstrates governance: who decided what, based on which inputs, and whether deadlines were met. It also prevents silent risk acceptance, where teams acknowledge issues informally but never document the tradeoff.

This page gives requirement-level implementation guidance you can put into operation quickly: scope, roles, minimum fields, intake sources, review cadence, evidence retention, and exam-ready talking points. It also flags common audit hangups so you can avoid rework.

Regulatory text

Requirement (C2M2 v2.1 RISK-1.D): “A risk register is established and maintained to track identified cybersecurity risks and their treatment status.” ¹

What the operator must do:
You must (1) create a risk register as the system of record for cybersecurity risks in scope, and (2) keep it updated so it reflects current treatment status for each risk (for example: under analysis, accepted, mitigation in progress, mitigated/closed, transferred). “Maintained” means it is not static; it gets updated when new risks are identified, when risk ratings change, when compensating controls are implemented, and when leadership accepts or rejects treatment plans ¹.

Plain-English interpretation (what “counts”)

A compliant risk register is a controlled, searchable list of cybersecurity risks with enough detail to:

• Understand the risk scenario and impacted assets/processes.
• See how the risk was analyzed (even at a high level).
• Identify the treatment decision and approver.
• Track remediation actions to completion, or document formal acceptance/transfer/avoidance ¹.

A non-compliant “risk register” is commonly:

• A one-time risk assessment report with no ongoing updates.
• A backlog of security issues with no risk analysis or decision trail.
• A set of meeting notes or email threads without a durable system of record.

Who it applies to

Entity types: Organizations using C2M2 in scope, commonly energy sector organizations and critical infrastructure operators ¹.

Operational context: Applies to the defined C2M2 assessment scope (business unit, function, or OT/IT environment). If you scope C2M2 to a plant network or a control center, your risk register must reflect risks for that scope, not just enterprise IT risks ¹.

Teams involved (typical):

• Risk owner: accountable leader for the impacted service/system (often operations or IT/OT).
• Cyber/GRC: runs the process, quality-checks entries, reports status.
• Engineering/IT/OT: supplies evidence, implements mitigation.
• Executive approver: accepts residual risk and signs off on exceptions.

What you actually need to do (step-by-step)

1) Define scope and the “system of record”

• Confirm the C2M2 scope boundary (sites, networks, systems, processes).
• Pick your system of record: GRC tool, ticketing system with governance fields, or a controlled spreadsheet in a governed repository.
• Set access control and change control (who can create, edit, close, and approve).

Operator tip: If risks live partly in Jira/ServiceNow and partly in spreadsheets, auditors will question completeness. Pick one authoritative register, then link out.

2) Establish minimum required fields (a workable data model)

Use a consistent set of fields so risk entries are comparable and auditable. Minimum fields that operationalize “track identified cybersecurity risks and their treatment status” ¹:

Field	Why it matters in an exam
Risk ID (unique)	Prevents duplicate/conflicting records
Title + scenario description	Proves you understand the risk, not just the vulnerability
Scope mapping (system/site/process)	Shows it is in the C2M2 boundary
Date identified + source	Demonstrates ongoing maintenance and intake
Inherent likelihood/impact (your scale)	Shows analysis occurred
Inherent risk rating	Enables prioritization
Existing controls / compensating controls	Supports residual risk reasoning
Residual risk rating	Ties controls to actual risk reduction
Treatment option	Required by the requirement’s “treatment status” concept 1
Treatment plan link (tickets/projects)	Makes tracking real
Owner + accountable exec	Clarifies responsibility
Target date + milestones	Enables follow-up
Current status	The “treatment status” field the requirement is looking for 1
Approval/acceptance record	Shows governance, especially for accepted risks
Closure criteria + closure evidence link	Prevents “closed because we got tired of it”

3) Document criteria, inputs, reviewers, and decision process

This is where most programs fail audits: they have entries, but no documented method behind them. Create a short procedure that states:

• Risk identification inputs: threat modeling, vulnerability management, incidents, audits, third-party findings, architecture reviews, OT changes, business changes.
• Rating criteria: your likelihood and impact definitions, including OT safety/availability considerations where applicable.
• Reviewers: who validates the analysis (Cyber/GRC), who confirms feasibility (engineering), who approves acceptance (leadership).
• Decision workflow: what requires a formal exception, what can be remediated without leadership signoff, escalation triggers.

This aligns with recommended controls to document criteria and decision process ¹.

4) Build intake pipelines (so the register stays “maintained”)

Create repeatable ways for risks to enter the register:

• Security testing and assessment outputs feed new register entries.
• Incident postmortems create risks for systemic issues.
• Third party assessments create risks tied to third party relationships (use “third party” as the umbrella term).
• Significant changes (new remote access path to OT, new identity provider, new EDR) trigger a risk review.

Practical control: define who converts findings into risk statements. Findings are evidence; risks are decisions.

5) Tie treatment to tracked work and management decisions

For each risk:

• Decide treatment: mitigate, accept, transfer, or avoid.
• If mitigate: create remediation tickets/projects and link them. Record interim compensating controls.
• If accept: record rationale, acceptance period (if you use time-bounded acceptance), and approver.
• If transfer: link insurance/contractual transfer mechanism, if applicable to your program.
• If avoid: document the business decision (for example, removing a technology path).

C2M2 expects you to retain assessment outputs, management decisions, and remediation tracking demonstrating risks were evaluated and addressed ¹.

6) Operational review and reporting

Set a governance rhythm that fits your environment:

• Working-level triage for new entries and status updates.
• Leadership review for high-impact items and risk acceptances.
• Metrics that are defensible without statistics games: counts by status, overdue treatments, acceptances pending approval, risks by scope segment.

7) Evidence retention and audit readiness

Treat the register as auditable. Build a habit: every risk entry has links to supporting artifacts and decisions.

If you run this in Daydream, configure the register so each risk record contains embedded evidence links, an approval workflow, and a status history. That reduces “spreadsheet drift” and gives you a cleaner audit narrative without building custom plumbing.

Required evidence and artifacts to retain

Retain evidence that shows the register is established and maintained, and that treatment status is real ¹:

• Risk register export/screenshot showing fields, statuses, and last updated dates.
• Risk methodology / SOP documenting criteria, inputs, reviewers, and decision process ¹.
• Assessment outputs that triggered risks (scan reports, audit findings, architecture review notes) ¹.
• Decision artifacts: meeting minutes, approval records, risk acceptance memos, exception approvals ¹.
• Remediation tracking: linked tickets, project plans, change records, validation results ¹.
• Closure evidence: retest results, control implementation evidence, signoff that closure criteria were met.

Common exam/audit questions and hangups

Expect variations of these:

1. “Show me your risk register.” They want the system of record, not a summary deck.
2. “How do you know it’s complete?” Be ready to show intake sources and reconciliation points (for example, vulnerability findings sampled against register entries).
3. “Who can accept risk?” If acceptance authority is unclear, auditors will treat acceptances as invalid.
4. “How do you track treatment status?” Status must map to actual work, not opinions.
5. “Prove this is maintained.” They will sample updates over time and look for status history and follow-through ¹.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Confusing issues with risks. An unpatched server is a finding; the risk is the plausible scenario and business impact. Fix: require a risk statement format (threat → vulnerability → impact) before entry.
• Mistake: No documented rating criteria. Teams invent ratings per entry. Fix: publish a one-page rating rubric and enforce it ¹.
• Mistake: “Accepted” with no approver. Fix: require named approver and date for any acceptance status.
• Mistake: Stale register. Fix: assign a register owner, enforce periodic reviews, and auto-report overdue items.
• Mistake: Remediation not linked. Fix: make treatment plan linkage mandatory for “mitigate” decisions ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific C2M2 requirement. Operationally, the risk is still tangible: without documented criteria and follow-up, significant exposures can remain unaddressed and your decisions may not stand up during internal control testing, audits, customer diligence, or regulator review ¹.

Practical 30/60/90-day execution plan

First 30 days (stand up the register)

• Confirm scope boundary for C2M2 assessment ¹.
• Select the system of record and set permissions.
• Define required fields and status taxonomy.
• Publish a short procedure covering criteria, inputs, reviewers, and decision process ¹.
• Migrate known top risks from existing sources (audits, incidents, vulnerability program).

Days 31–60 (make it operational)

• Establish intake feeds (security testing, change management, third party assessments).
• Run a working group to clean up entries: consistent scenarios, owners, treatment decisions.
• Tie “mitigate” risks to tickets/projects; define closure criteria.
• Start leadership review for acceptances and high-impact items.

Days 61–90 (audit-proof and sustain)

• Perform a sample-based QA review: pick several findings from upstream sources and confirm they are represented appropriately in the register.
• Add evidence links and approval records for sampled risks ¹.
• Produce a repeatable monthly risk register report: status breakdown, overdue treatments, acceptances pending approval.
• If using Daydream, configure dashboards and automated evidence collection so audit requests do not trigger manual scrambling.

Frequently Asked Questions

What’s the minimum a risk register entry needs to show for this requirement?

It must show an identified cybersecurity risk and its treatment status, with enough detail to understand the decision and track progress ¹. If you cannot tell who owns it, what was decided, and where it stands, it will not hold up in review.

Can a spreadsheet satisfy the risk register requirement?

Yes, if it is controlled, consistently updated, and contains auditable fields and evidence links that show treatment status over time ¹. Most failures come from spreadsheet sprawl and missing approvals, not the format itself.

How do I prove the register is “maintained”?

Show status history, recent updates, and traceability from assessment outputs to decisions and remediation tracking ¹. Auditors respond well to sampled examples that demonstrate end-to-end lifecycle management.

Do we need formal risk acceptance memos for every accepted risk?

You need documented management decisions and approver evidence for acceptance ¹. Whether that is a memo, an approval workflow in a tool, or signed meeting minutes depends on your governance model, but it must be durable and retrievable.

How should third party risks appear in the register?

Record third party risks the same way as internal risks: scenario, impacted services, analysis, treatment choice, and status. Link to the underlying third party assessment outputs and any contractual or remediation actions ¹.

What’s the fastest way to operationalize this if we already have a vulnerability backlog?

Convert the backlog into risk statements for the items that matter, then track treatment decisions and status in one register. Keep the scan results as supporting evidence, but do not treat “open vulnerabilities” as a substitute for a risk register ¹.

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program