--- title: Risk Management description: Identify, score, treat, and review information-security risks against a 5×5 model, link them to POA&Ms, and track your active risk posture over time. navigation: icon: i-lucide-shield-alert --- # Risk Management The **Risk Management** module is your organization's risk register: a living record of the information-security risks that could affect your CUI environment. You score each risk on a **5×5 likelihood × impact** model, decide how you'll treat it, assign an owner, and — where a risk maps to a compliance gap — link it to a **POA&M** so remediation is tracked in one place. CMMC and NIST SP 800-171 (practice **RA.L2-3.11.1**) expect a documented, repeatable risk assessment process. This module is where that lives, and its output feeds your **compliance posture**, the **SSP**, and the **AI connector**. ::note Find it in the sidebar under **Risk Management** (`/dashboard/risk`). It's visible to every role that can read compliance data; editing requires a manager role — see [Permissions](#permissions). :: --- ## Key concepts ### The 5×5 scoring model Every risk is scored on two axes, each **1–5**. The **score** is simply `likelihood × impact` (1–25), and the score maps to a **band**. | Likelihood | Impact | | --- | --- | | 1 — Rare | 1 — Negligible | | 2 — Unlikely | 2 — Minor | | 3 — Possible | 3 — Moderate | | 4 — Likely | 4 — Major | | 5 — Almost certain | 5 — Severe | | Band | Score range | | --- | --- | | :badge[Low]{color="success"} | 1 – 4 | | :badge[Moderate]{color="warning"} | 5 – 9 | | :badge[High]{color="warning"} | 10 – 15 | | :badge[Critical]{color="error"} | 16 – 25 | ::tip The band is derived automatically from likelihood and impact — you never set it by hand. Change either axis and the score, band, and heatmap position update together. :: ### Status A risk moves through a lifecycle. The status drives whether a risk counts toward your **active** posture. | Status | Meaning | | --- | --- | | **Open** | Newly identified, not yet worked | | **Assessing** | Being analyzed / scored | | **Treating** | A treatment is in progress | | **Monitoring** | Treated, being watched | | **Accepted** | Consciously accepted (documented) | | **Closed** | Resolved or retired — **excluded** from active posture | ### Treatment strategy How you intend to handle the risk. Each has a plain-language label for non-technical stakeholders. | Strategy | Plain language | | --- | --- | | **Mitigate** | "We're fixing it" | | **Accept** | "We're living with it" | | **Transfer** | "Insurance or a contract covers it" | | **Avoid** | "We stopped doing the risky thing" | ### Applicability Not every catalog risk applies to every environment. Marking a risk **Not applicable** *with a reason* is itself evidence — an assessor tests the completeness of your risk argument — so it's stored, not deleted. | Applicability | Effect on posture | | --- | --- | | **Applies** | Counts toward active posture | | **Not applicable** | Excluded from the rollup; counted separately | | **Not yet reviewed** | Excluded from active exposure until triaged | --- ## Using the module The Risk page has two tabs: **Risks** (the register) and **Reports** (generated PDF risk reports). The register renders as a table of expandable rows, with a **heatmap** summarizing your open risks by band. ### Add a risk There are two ways to create a risk — a quick form, or a guided wizard that walks you through catalog scenarios. ::steps{level="4"} #### Open the risk form From the **Risks** tab, start a new risk. You can begin from a blank form or pick a **catalog scenario** (a pre-written threat/vulnerability pairing) to pre-fill the details. #### Describe the risk Give it a **title** and description. Optionally record the **threat source** (what could cause harm) and **vulnerability** (the weakness it exploits), plus a category and CMMC family. #### Score it Set **likelihood** and **impact** (1–5 each). The **score** and **band** compute automatically and place the risk on the heatmap. #### Assign ownership and scope Pick an **owner** (a user accountable for the risk) and, if relevant, link the **systems** and **assets** the risk applies to. #### Save The risk appears in the register with its band, status **Open**, and its heatmap cell populated. :: ::tip Prefer the **guided wizard** for a first pass — it runs an intake step and a rating step across common scenarios so you build a defensible register quickly, rather than inventing risks from a blank page. :: ### Treat a risk ::steps{level="4"} #### Choose a treatment strategy Open the risk and set its **treatment strategy** — Mitigate, Accept, Transfer, or Avoid. #### Write the treatment plan Record **what's needed and what will be done**. This free-text plan is what an assessor and your team read to understand the remediation. #### Move the status Set the status to **Treating** (or **Accepted** / **Monitoring**) to reflect where the risk is in its lifecycle. :: ### Link a risk to a POA&M When a risk represents a compliance gap, connect it to a **Plan of Action & Milestones** item so the remediation is tracked in your POA&M workflow. ::steps{level="4"} #### Open the risk From the register, expand the risk and open its POA&M section. #### Link or create **Link** an existing POA&M, or **create** a new POA&M directly from the risk. Creating one carries the risk's context (title, target date, objectives) into the new POA&M. :: ::note Creating a POA&M from a risk is **idempotent** — it returns the existing POA&M if one already matches, so repeated clicks won't spawn duplicates. If the POA&M is later deleted, the risk's link simply clears (the risk itself is untouched). :: ### Mark a risk not applicable If a catalog risk doesn't apply to your environment, set its **applicability** to **Not applicable** and record the **reason**. It's removed from your active posture rollup but retained as evidence of a complete review. ### Run a review cycle Risk registers must be reviewed periodically. A **review cycle** lets you walk the register, re-rate or re-affirm each risk, and close out the cycle as a documented, point-in-time review. ::steps{level="4"} #### Start a cycle Begin a new review cycle from the register. #### Review each risk Step through risks — confirm the rating, update status, or accept low risks in bulk. #### Close out Close the cycle to stamp a completed review. The cycle history is retained for your audit trail. :: ### Generate a risk report The **Reports** tab produces a downloadable **PDF risk report** — a snapshot of your register suitable for leadership or an assessor. Generated reports are stored as evidence and can be re-downloaded. ### Comment on a risk Each risk has a **comment thread** for collaboration — questions, decisions, and context. Anyone who can view risks can read and add comments. --- ## Permissions Access is governed by two permissions in the role matrix. | Capability | Permission | | --- | --- | | View the register, heatmap, comments, reports | :badge[VIEW_RISK]{color="neutral"} | | Create / edit / delete risks, treat, link POA&Ms, run review cycles, generate reports | :badge[MANAGE_RISK]{color="info"} | `VIEW_RISK` is held by every non-platform role (including Assessor and Org User). `MANAGE_RISK` is held by Org Admin, Org User, MSP Super, and MSP Admin — **not** Assessor (read-only) or Platform Admin. ::warning Adding a comment requires only `VIEW_RISK` (collaboration is open to all readers), but every risk **mutation** — including bulk-accept and starting a review cycle — requires `MANAGE_RISK`. :: --- ## How it works Extra detail on what the module stores and how it behaves — product behavior, not internals. ### What a risk record holds Each risk is a single record that belongs to your organization. :::field-group ::field{name="Title & description"} A short name (required) and a fuller explanation of the scenario. :: ::field{name="Threat source & vulnerability"} What could cause harm (e.g. "malicious insider") and the weakness it exploits. :: ::field{name="Likelihood" type="1–5"} How likely the scenario is. :: ::field{name="Impact" type="1–5"} How damaging it would be. :: ::field{name="Score & band" type="calculated"} Likelihood × impact (1–25) and the resulting band — computed for you, never entered by hand. :: ::field{name="Status"} Open, Assessing, Treating, Monitoring, Accepted, or Closed. :: ::field{name="Applicability"} Applies, Not applicable, or Not yet reviewed — with a reason recorded when Not applicable. :: ::field{name="Treatment"} A strategy (Mitigate / Accept / Transfer / Avoid) and a free-text treatment plan. :: ::field{name="Owner"} The person accountable for the risk. :: ::field{name="Linked POA&M"} The remediation item this risk is tracked under, if any. :: ::field{name="Target date"} When you aim to have the risk treated. :: ::field{name="Scope & mapping"} The systems and assets the risk applies to, plus an optional assessment and CMMC mapping (defaults to the Risk Assessment family, RA.L2-3.11.1). :: ::: Each risk also carries its **comment thread**, its **review history**, and — when created from the catalog — a reference to the **scenario** it came from. ### How scoring works The band is calculated automatically from likelihood × impact — you never set it directly. The ranges are fixed: **Low 1–4**, **Moderate 5–9**, **High 10–15**, **Critical 16–25**. Change either axis and the score, band, and heatmap position update together. The wording of the likelihood and impact levels (Rare → Almost certain, Negligible → Severe) can be **customized per organization** if your risk methodology uses different anchors. ### What counts toward your posture Your dashboards, reports, and the AI connector summarize only your **active** risks — those that are **not closed and marked as applying**. ::warning Not-applicable and closed risks are left out of your band counts, highest-band, and heatmap so they can't distort your posture. They stay in the full register — a Not-applicable risk is retained (with its reason) as evidence of a complete review, and is reported separately as a not-applicable count. :: The posture summary gives you: the number of active risks, a breakdown **by band** and **by status**, the count of **high-and-above** risks, your **highest active band**, and the 5×5 **heatmap**. ### AI assistant access When the [AI Connector](https://app.dibfi.com/dashboard/org-settings) is enabled, assistants can **read** (never change) your risk data through two tools: - **`get_risk_register`** — your risks with score, band, treatment, owner, and linked POA&M. - **`get_risk_summary`** — your active-risk posture: counts by band and status, highest band, and the heatmap. Access follows the same permissions as the app: an assistant only ever sees what the connected user's role is allowed to see. --- ## Related features :::card-group ::card{title="POA&M" icon="i-lucide-list-checks" to="https://app.dibfi.com/dashboard/poam"} Track remediation of risks and compliance gaps as milestones. :: ::card{title="Compliance Ops" icon="i-lucide-calendar-check" to="https://app.dibfi.com/dashboard/compliance-ops"} Schedule the recurring risk review as an operational task. :: ::card{title="AI Connector" icon="i-lucide-bot"} Read your risk register and posture through an AI assistant. :: :::