# Risk Registry (Beta)
URL: https://docs.clearly-ai.com/docs/risk-registry
Description: Track risks from reviews and manual findings through ownership, mitigation, acceptance, and history.
**Risk Registry (Beta)** is a system of record for security and compliance risks that need follow-up after review.
Use it to track who owns a risk, how severe it is, what remediation is planned, whether it was accepted, and what evidence or review produced it.
Risk Registry is in beta and must be enabled for your organization. If you do not see **Risk Registry** or **Risks**, ask your administrator or Clearly AI.
## Open Risk Registry [#open-risk-registry]
Open **Risks** from the sidebar.
The list page shows:
* **Open Risks**
* **Critical & High**
* **Unowned**
* **Overdue**
* Filters for **Status**, **Severity**, **Owner**, **Project**, and **Category**
* **New Risk** when you have edit permission
Risks are sorted by **Severity**, then **Due Date**, then most recently updated. Click a header with a sort icon to sort by that column, and click it again to reverse the order. The table loads 25 risks at a time, and sorting reorders only the loaded risks. To sort across more risks, click **Load more risks** first.
Use **Columns** to show or hide columns. The table returns to its default columns when you reload the page.
If you can edit risks, change **Status**, **Severity**, **Owner**, or **Due** directly in the table. Click a risk's title to open it, or its review name to open the review it was published from. When ticket sync is on, the table lists each risk's tracker tickets with their sync status. Click a ticket key to open the ticket in its tracker.
If draft risks exist, the page shows a banner such as **draft risks need triage** with **View drafts**.
[Image: Risk Registry list with summary cards, filters, and risk rows showing the Severity, Impact, Likelihood, and Project columns]
## How risks are created [#how-risks-are-created]
Risks can be created in two ways.
**Published from reviews:** Use **Publish to Risk Registry** on a review or an individual answer.
[Image: Review answer with the Publish to Risk Registry action and a risks published link]
Clearly AI analyzes the answers in scope, detects candidate risks, and opens the **Publish to Risk Registry** panel where you can review them. Each detected risk shows an editable title, description, remediation plan, and scoring, along with an AI confidence indicator. Low-confidence detections are de-emphasized and left unselected, so you choose exactly which risks are worth tracking. You can retry an answer that failed to analyze, and risks already in the registry are marked so you don't publish duplicates.
[Image: Publish to Risk Registry panel showing detected risks with editable fields, scoring, and AI confidence]
Published risks are created directly in the **Open** state and link back to the source review and answer. Publishing works across all answer types. After publishing, the answer shows a **risks published** link that opens the Risk Registry filtered to that answer.
**Manually:** Click **New Risk** and enter the risk details yourself.
When creating a risk, you can optionally link it to a standardized definition in the [Risk Catalog](#risk-catalog).
## Create a risk manually [#create-a-risk-manually]
1. Open **Risks**.
2. Click **New Risk**.
3. Enter **Title** and **Description**.
4. Optionally set **Impact** and **Likelihood** (severity is derived from these), plus **Category**, **Owner**, and **Project**.
5. Click **Create Risk**.
Manual risks start as draft risks.
## Risk fields [#risk-fields]
Each risk can include:
* **Title**: short summary.
* **Description**: what the risk is and why it matters.
* **Status**: current lifecycle state.
* **Impact**: how serious the consequences would be if the risk occurred.
* **Likelihood**: probability of occurrence.
* **Severity**: derived from **Impact** and **Likelihood** using your organization's scoring matrix, or set directly when your organization uses severity-only scoring.
* **Owner**: person responsible for follow-up.
* **Category**: classification such as access control, data protection, or logging.
* **Project**: the project the risk applies to or was published from.
* **Due Date**: target date for remediation or decision. Assigned automatically from the severity SLA when a risk is published, and editable afterward.
* **Remediation Plan**: planned mitigation or fix.
* **Linked Entities**: related reviews, projects, tickets, or other entities.
* **History**: recorded field and status changes.
## Risk scoring [#risk-scoring]
By default, Clearly AI derives a risk's **Severity** from its **Impact** and **Likelihood** using a scoring matrix. The default matrix is 3×3 (low, medium, high for each axis) and maps each combination to a severity of **Low**, **Medium**, **High**, or **Critical**. Hovering a severity shows how it was derived, for example *Impact × Likelihood → Severity*.
When a risk is published, its **Due Date** is set automatically from a per-severity SLA (by default 1 day for Critical, 7 for High, 30 for Medium, and 90 for Low).
Administrators configure scoring under **Risk Settings → Scoring** (`/risks/settings`):
* **Severity matrix**: choose the severity that each Impact × Likelihood combination produces.
* **SLA table**: set how many days to resolve risks of each severity, which drives the automatic due dates.
[Image: Risk Settings Scoring page with the severity matrix editor and per-severity SLA table]
Organizations that prefer to set severity directly can use a severity-only methodology instead of the Impact × Likelihood matrix.
## Triage draft risks [#triage-draft-risks]
Draft risks need enough information to become actionable. Manually created risks start as drafts (risks published from reviews already arrive as **Open**).
For each draft risk:
1. Open the risk.
2. Confirm the **Description**.
3. Set **Impact** and **Likelihood**.
4. Assign an **Owner**.
5. Set **Category**, **Project**, and **Due Date** when useful.
6. Add or update the **Remediation Plan**.
7. Move **Status** from **draft** to **open** when the risk is ready to track.
The draft banner on the list page is a shortcut to these untriaged risks.
## Status lifecycle [#status-lifecycle]
Risk statuses are:
* **draft**
* **open**
* **mitigating**
* **accepted**
* **resolved**
* **closed**
Allowed transitions depend on the current status.
* **draft** can move to **open** or **closed**.
* **open** can move to **mitigating**, **accepted**, **resolved**, or **closed**.
* **mitigating** can move back to **open**, or forward to **accepted**, **resolved**, or **closed**.
* **accepted** and **resolved** can reopen or close.
* **closed** is terminal in the current UI.
Risks published from reviews start in **open**. Manually created risks start in **draft**.
Use **Accept Risk** instead of the status dropdown when accepting an open or mitigating risk.
## Accept a risk [#accept-a-risk]
Users with accept permission can accept risks that are **open** or **mitigating**.
1. Open the risk.
2. Click **Accept Risk**.
3. Enter **Justification**.
4. Optionally enter **Residual Risk Notes**.
5. Click **Accept Risk**.
Accepted risks show the acceptance justification and residual risk notes on the risk detail page.
## Link related entities [#link-related-entities]
Use **Linked Entities** to connect a risk to the work or evidence around it.
Link types include:
* **Relates to**
* **Caused by**
* **Mitigates**
* **Blocks**
Risks published from reviews include a deep-link back to the source review and answer under **Linked Entities**. You can add more links manually when you have edit permission.
## Bulk update risks [#bulk-update-risks]
From the risks table, select one or more risks to show bulk actions.
Available bulk actions include:
* Set status.
* Set severity.
* Set owner.
* Delete selected draft risks.
Only draft risks can be deleted.
## Risk Catalog [#risk-catalog]
The **Risk Catalog** is a library of reusable, standardized risk definitions for your organization. Instead of describing the same risk differently on every project, you maintain a curated set of known risks (catalog risks) and link your live risks to them. This gives your team a common risk language, consistent classification, and a traceable link from each live risk back to its standard definition.
The Risk Catalog is part of the Risk Registry beta and uses the same access. Anyone who can edit risks can create, publish, and import catalog risks. Only administrators can delete them, and only drafts can be deleted.
### Open the catalog [#open-the-catalog]
Open **Risks**, then go to **Risk Settings → Catalog** (`/risks/settings`).
The **Catalog** tab lists your catalog risks with:
* Search, and filters for **Status** and **Category**
* Columns for ID, name, category, default severity, status, and version
* **New catalog risk** when you have edit permission
[Image: Catalog tab in Risk Settings showing catalog risks with search, a status filter, the ID, name, category, severity, status, and version columns, Import CSV, and New catalog risk]
*Figure 1. The Catalog tab in Risk Settings, with search, a status filter, the catalog risks table, Import CSV, and New catalog risk.*
### Catalog risk fields [#catalog-risk-fields]
Each catalog risk can include:
* **Name**: short title for the risk type.
* **Description**: what the risk is and why it matters.
* **Risk Statement**: a standardized statement of the risk, suitable for reuse.
* **Category** and **Subcategory**: classification for grouping and reporting.
* **Default Impact**, **Default Likelihood**, and **Default Severity**: the standard scoring for this risk type. Severity is derived from impact and likelihood using your organization's scoring matrix, the same way live risks are scored.
* **Suggested Controls**: recommended mitigations.
* **Mapped Frameworks**: related frameworks or standards, entered as free text.
* **Status**: **draft**, **published**, or **archived**.
* **Version**: increases each time a published catalog risk is edited.
### Create and publish a catalog risk [#create-and-publish-a-catalog-risk]
1. In the **Catalog** tab, click **New catalog risk**.
2. Enter at least a **Name** and **Description**, and set defaults such as impact, likelihood, category, and suggested controls.
3. Save it. The catalog risk starts as a **draft**.
4. When it is ready to use, **Publish** it. Only published catalog risks can be linked to live risks.
5. **Archive** a catalog risk to retire it without affecting the risks already linked to it.
[Image: New catalog risk form with Name, Description, Risk Statement, Category and Subcategory, Default Impact and Likelihood, Mapped Frameworks, and Suggested Controls]
*Figure 2. The New catalog risk form for authoring a reusable risk definition.*
Editing a published catalog risk raises its **version**, while risks already linked to it keep the version they were linked at. Only **draft** catalog risks can be deleted; archive published ones instead.
### Import catalog risks from a CSV [#import-catalog-risks-from-a-csv]
To build the catalog quickly, use **Import CSV** to add many catalog risks at once. Imported catalog risks are created as drafts. Each row is reported as **created**, **updated**, **skipped**, or **failed**, with a reason for anything that did not import. Re-importing the same file updates matching catalog risks instead of creating duplicates.
[Image: Import catalog risks from CSV dialog with drag-and-drop upload, Browse files, and Download template]
*Figure 3. The Import catalog risks from CSV dialog, with a downloadable template. Imported risks are created as drafts.*
### Link a risk to the catalog [#link-a-risk-to-the-catalog]
Linking records that a live risk corresponds to a standard catalog definition. It stores the link and the catalog risk's version; it does not change any of the risk's own fields.
* **When creating a risk**: in **New Risk**, use the optional **Catalog** field to associate the new risk with a published catalog risk.
* **On an existing risk**: open the risk and use **Link to catalog** in its properties. You can change or remove the link later.
A linked risk shows its catalog risk ID and version on the risk detail page.
### Track catalog adoption [#track-catalog-adoption]
* Filter the Risk Registry by **Catalog Item** to see every live risk linked to a given catalog risk.
* Each catalog risk shows how many live risks are linked to it, with a shortcut to that filtered list.
[Image: Catalog risk detail panel showing risk statement, category, default severity, controls, frameworks, and a Live risks shortcut to view linked risks in the registry]
*Figure 4. A catalog risk's detail panel, showing the number of live risks linked to it with a shortcut to the filtered Risk Registry.*
### Require catalog mapping when publishing [#require-catalog-mapping-when-publishing]
Administrators can require that risks published from a review are mapped to the catalog. When this is on, Clearly AI matches each detected risk against your published catalog risks during **Publish to Risk Registry**, shows the matched catalog risk, and asks you to map each one before publishing, so promoted risks stay tied to standard definitions.
[Image: Publish to Risk Registry panel showing each detected risk mapped to a catalog risk by ID and name]
*Figure 5. With catalog mapping enforced, Publish to Risk Registry shows the catalog risk each detected finding maps to.*
## FAQs [#faqs]
The feature may not be enabled, or your role may not have permission to view risks.
Risks are not created automatically. Use **Publish to Risk Registry** on the review or an individual answer to review the detected risks and choose which findings become tracked risks.
Only users with accept permission can accept risks. The risk must be **open** or **mitigating**.
Only draft risks can be deleted. Move non-draft risks to an appropriate lifecycle status instead.
Set both **Impact** and **Likelihood** so severity can be derived from the scoring matrix, or set **Severity** directly if your organization uses severity-only scoring.
The Risk Catalog holds reusable, standardized risk definitions (catalog risks). The Risk Registry holds the live risks you actually track and resolve. Link a live risk to a catalog risk to standardize and report on it.
Only draft catalog risks can be deleted, and only administrators can delete them. Archive published catalog risks instead.