Risk Register [Command+]

The Risk Register is CMDash's centralized inventory of identified cybersecurity risks. It gives your security program a structured, auditable place to track what threats exist, how serious they are, and what is being done about them. The Risk Register is available on Command and Enterprise subscriptions.

What Is the Risk Register?

The Risk Register is a standard GRC artifact. It is the authoritative list of risks your organization has formally identified, assessed, and accepted — or is actively working to mitigate. Auditors, assessors (SOC 2, ISO 27001, CMMC), and boards expect to see a maintained risk register as evidence that your security program is operating systematically rather than reactively.

In CMDash, the Risk Register connects to your compliance framework controls (via the API — see Linking Risks to Compliance Controls below) and your remediation task tracking, so risk management does not exist in isolation.

Risk Scoring Model

Every risk in CMDash is scored using a standard likelihood × impact model:

Raw Score = Likelihood (1–5) × Impact (1–5)

This produces a raw score from 1 to 25, which CMDash normalizes to a 0–100 scale for display consistency with other scoring throughout the platform.

Likelihood scale (1–5):

1. Rare — unlikely to occur within the next 3 years
2. Unlikely — could occur but not expected within 12 months
3. Possible — may occur within 12 months
4. Likely — expected to occur within 12 months
5. Almost Certain — expected to occur within 90 days or is actively being exploited

Impact scale (1–5):

1. Negligible — minimal operational or financial impact
2. Minor — limited impact; contained within the security team
3. Moderate — material impact; executive awareness required
4. Major — significant operational disruption, regulatory exposure, or reputational harm
5. Critical — existential threat; major data breach, regulatory sanction, or operational shutdown

Both scores are set manually during risk creation and can be updated as circumstances change.

Creating a Risk

Click + Add Risk on the Risk Register table. CMDash has no separate risk detail page — the same New Risk / Edit Risk dialog you use to create a risk is also where you reopen it later, and (once the risk is saved) it additionally shows a custom-fields panel and a comment thread for that risk.

Required Fields

• Title: A clear, concise description of the risk. Example: "Unpatched critical vulnerabilities in production environment exceed 30-day SLA." Use a consistent naming convention across your register (e.g., [Domain]: [Risk description]).
• Likelihood: 1–5 scale (see above), set with a slider.
• Impact: 1–5 scale (see above), set with a slider.

Optional Fields

• Description: Free-text narrative elaborating on the nature of the risk, how it was identified, potential attack vectors, and affected business processes.
• Category: A free-text label (e.g., "Operational", "Technical") — not a fixed dropdown.
• Notes: Free-text field for anything else worth recording.
• Status: Defaults to Open; can be set to any of the five statuses at creation time (see Risk Lifecycle below).

There is no Owner field, and no way to link compliance controls or assets from this dialog. Tags are not set here either — apply them from the tag picker on the risk's row in the Risk Register table after it's created.

Risk Lifecycle

A risk carries one of five statuses: Open, Mitigated, Accepted, Transferred, or Closed. There is no separate "in progress" state — a risk stays Open while remediation tasks are underway, and only moves once the outcome is known:

Open → Mitigated → Closed
   ↓        ↓
Accepted  Transferred

Open: Risk has been identified and documented. This is the starting state for all new risks, and remains the status while remediation tasks are in progress. The risk score does not automatically change while tasks are underway — update likelihood or impact when mitigations actually reduce the risk.

Mitigated: The remediation has been carried out and reduced the risk to an acceptable level, but the risk has not yet been formally closed.

Transferred: The organization has shifted the risk to a third party — for example, via a cyber insurance policy or a vendor contract — rather than mitigating or accepting it directly.

Closed: The risk is fully resolved and verified. Before closing a risk, document the mitigating controls that reduced the risk to an acceptable level. Closed risks are retained in history for audit purposes and are excluded from your active risk count.

Accepted: The organization has made a decision to accept this risk rather than remediate it. Setting a risk's status to Accepted is a plain status change in CMDash — there is no dedicated acceptance workflow with a required rationale, owner, review date, or reminder notification. If your process requires capturing a written rationale, an accountable owner, or a review date, record it in the risk's Notes field, a tenant-defined custom field, or the risk's comment thread.

Risk acceptance is a governance decision, not a technical one. In mature programs, accepted risks are reviewed by a risk committee or executive sponsor on a schedule you manage outside CMDash.

Important: Do not use "Accepted" to close risks that are simply difficult to fix. Accepted risks remain visible, count toward your risk register metrics, and are surfaced to assessors.

Bulk Import

If you are migrating an existing risk register into CMDash, use the CSV bulk import feature:

1. Click Bulk Import on the Risk Register table. There is no template file to download — the dialog is a text box you paste CSV content directly into.
2. Prepare your CSV with a header row and these columns: title, description, category, likelihood, impact, status. Only title, likelihood, and impact (integers 1–5) are required; the others are optional and status defaults to open if omitted or unrecognized.
   • status — one of: open, mitigated, accepted, closed (defaults to open; transferred is a valid status elsewhere in CMDash but is not currently one of the values the CSV importer recognizes)
3. Paste the CSV content into the dialog and click Import.
4. The result shows how many rows imported and lists any per-row errors. Rows that fail are skipped; valid rows import regardless.

There is no separate owner or tags column, and no documented maximum import size — very large pastes have not been characterized.

Linking Risks to Compliance Controls

CMDash's API supports linking a risk to one or more compliance controls (up to 50 per risk), and linked controls are included in the POA&M export [Starter+] alongside the risk finding. There is currently no dashboard UI for creating or viewing these links directly — this is an API-only capability today.

Remediation Tasks

Each risk can have one or more remediation tasks associated with it. Tasks provide granular tracking of the work required to close a risk.

To create a remediation task: go to the Remediations page (a separate top-level page, not inside the Risk Register) and create a new task, picking the risk it belongs to from a dropdown.

Task fields include:

• Title: What needs to be done. Example: "Deploy MFA to all admin accounts in Azure AD."
• Risk: Which risk this task remediates.
• Priority.
• Due Date: Target completion date.
• Description: Optional — additional context, acceptance criteria, or links to runbooks.
• Status: Open → In Progress → Verification → Closed.

Tasks created this way can also be referenced in POA&M exports [Starter+], where each task maps to a POA&M milestone entry.

Risk Filters and Views

The Risk Register table supports a range of filters to help you focus on the risks that matter most in a given context:

• Status: Filter by Open, Mitigated, Accepted, Transferred, or Closed.
• Tag: Filter to a single tag at a time.

There is no Score range, Owner, Framework, or Date created filter, and no per-risk detail page — the Risk Register is one table with these two filters plus column sorting.

To save a filter combination:

1. Apply your desired filters.
2. Click Saved views in the filter bar, then Save current view….
3. Give the view a name.
4. Saved views can optionally be shared with the rest of your workspace, or kept private to you.

Saved Views are useful for recurring workflows — for example, a monthly review of all open high-severity risks, or a quarterly view of accepted risks due for re-evaluation.

Exporting the Risk Register

Click Export CSV on the Risk Register page to export your full risk register.

The export includes: Risk ID, title, description, category, likelihood, impact, risk score (the raw 1–25 likelihood × impact score, not the normalized 0–100 display score), status, owner (an internal user ID, not a name), due date, notes, and linked controls. Tags, creation date, and last-updated date are not included.

The export always contains the full register — table filters are not applied to it.

The POA&M register is a separate top-level page in the main nav, on every plan. Exporting a POA&M (which includes remediation task detail) needs the POA&M export feature, Starter and above.

FAIR Quantification [Enterprise]

Enterprise subscribers can convert any risk to a financial impact estimate using FAIR (Factor Analysis of Information Risk) methodology. FAIR quantification translates the qualitative likelihood × impact model into an annualized loss expectancy (ALE) expressed in dollars, which is significantly more compelling for board-level reporting.

To enable FAIR on a risk: open the separate FAIR Risk Quantification page (in the main nav, not inside the Risk Register), select the risk from the list, and enter its loss magnitude parameters (data sensitivity, asset value, regulatory exposure) and frequency factors. CMDash calculates a Monte Carlo probability distribution and displays a range of probable annual loss. The page also lets you select multiple risks to compare their annualized loss expectancy side by side.

For a complete walkthrough of FAIR quantification in CMDash, see the FAIR Risk Quantification guide.

Best Practices

Review the register monthly. Risks change — threat landscape shifts, mitigations are deployed, business context changes. A risk register that is not reviewed regularly becomes a stale document rather than a living management tool. Assign a standing agenda item for risk register review in your monthly security review meeting.

Require board-level approval for risk acceptance. Accepting a risk means your organization is knowingly carrying that exposure. For high and critical risks (normalized score 70+), the acceptance decision should be documented at the executive or board level, not made unilaterally by the security team. Since CMDash has no dedicated acceptance workflow, record that documentation in the risk's Notes, a custom field, or its comment thread.

Close risks only when mitigation is verified. Do not close a risk based on a remediation task being marked "Closed" without independently verifying that the mitigation actually reduced the risk. For example, if the remediation was deploying MFA to admin accounts, verify the MFA coverage signal in your identity integration before closing the risk.

Use tags consistently. Tags are your primary tool for organizing risks by business unit, system, threat category, or regulatory scope. Establish a standard tag vocabulary for your organization (e.g., cloud-aws, third-party-vendor, ransomware, data-exfiltration) and apply it as you tag each risk — tags are added from the risk's row after it's created, not at creation time.

Link every risk to at least one compliance control, via the API. There's no dashboard screen for this yet (see Linking Risks to Compliance Controls above), but if your workflow can call the API, the connection helps you demonstrate to auditors that your risk management program informs your compliance posture — and vice versa — and ensures risks surface in POA&M exports.

Risk Proposals (The Skeptic)

Risk Proposals (/risk-proposals) clusters open integration findings into proposed risk-register entries with a FAIR pre-fill, so you approve or reject a draft instead of writing one from scratch. It is a tab on Risk Register, not its own sidebar row: Security → Risk Register, then the Proposals tab. Accepting a proposal creates a normal risk in this register; rejecting records why, so the same cluster is not proposed again. It is part of the AI Assistant add-on: without it the tab shows the add-on wall, and the demo workspace does not carry it.