Overview
Risk registers are the primary containers for organizing and managing your information security risks. Each register holds a collection of risks that can be assessed, treated, and tracked over time. You can create multiple registers to separate risks by business unit, project, compliance framework, or any other organizational boundary.Managing Risk Registers
Viewing Registers
Navigate to Risk > Risk Register to see all registers in your organization. The list view shows:| Column | Description |
|---|---|
| Name | Register name |
| Description | Purpose of the register |
| Default | Whether this is a system-created default register |
| Risk Count | Number of risks contained in the register |
| Created | When the register was created |
Creating a Register
Provide Details
Enter a name and description for the register. The name should clearly identify the scope (e.g., “Corporate Risk Register”, “Product Engineering Risks”, “HIPAA Risk Register”).
Editing and Archiving
- Edit — update the register name and description at any time
- Archive — move a register to archived status when it is no longer active. Archived registers and their risks are preserved for historical reference but hidden from the active view.
- Delete — permanently remove a register. This action cannot be undone and removes all associated risks.
Managing Risks
Click on a register to open its detail page and see all risks within it.Creating a Risk
Fill in Risk Details
Complete the following fields:Core Information
Inherent Risk Scoring
Residual Risk Scoring
Treatment
Associations
| Field | Required | Description |
|---|---|---|
| Title | Yes | Concise name for the risk |
| Description | Yes | Detailed explanation of the risk scenario |
| Category | Yes | Risk category (see Risk Overview for categories) |
| CIA Category | No | Confidentiality, Integrity, or Availability classification |
| Owner | Yes | Person or security role responsible for managing this risk |
| Status | Yes | Current workflow status |
| Field | Description |
|---|---|
| Inherent Likelihood | 1-5 scale of probability before controls |
| Inherent Impact | 1-5 scale of severity before controls |
| Field | Description |
|---|---|
| Residual Likelihood | 1-5 scale of probability after controls |
| Residual Impact | 1-5 scale of severity after controls |
| Field | Description |
|---|---|
| Treatment | Mitigate, Accept, Transfer, or Avoid |
| Treatment Notes | Explanation of the treatment strategy |
| Treatment Reason | Business justification for the chosen treatment |
| Field | Description |
|---|---|
| Linked Controls | Controls that mitigate this risk |
| Linked Vendors | Vendors associated with this risk |
Risk Score Display
Each risk shows two calculated scores:- Inherent Risk Score = Inherent Likelihood x Inherent Impact (1-25)
- Residual Risk Score = Residual Likelihood x Residual Impact (1-25)
Risk Heat Map
The register detail page includes a visual risk heat map that plots all risks on a likelihood-impact matrix. Each cell shows the count of risks at that intersection, color-coded by severity. The heat map provides an at-a-glance view of where your risk concentration lies.Risk Detail View
Click on any risk to open its full detail view, which includes:Risk Summary
Risk Summary
Title, description, category, CIA classification, risk ID, and current status. Shows both inherent and residual risk scores with visual indicators.
Scoring Details
Scoring Details
Full breakdown of likelihood and impact values for both inherent and residual assessments. Visual comparison of before and after control effectiveness.
Treatment Plan
Treatment Plan
Selected treatment strategy (mitigate, accept, transfer, avoid) with notes and business justification. For mitigated risks, links to the controls providing mitigation.
Linked Controls
Linked Controls
Controls from your compliance frameworks that are linked to this risk. Shows control ID, title, framework, and implementation status.
Linked Vendors
Linked Vendors
Vendors associated with this risk. Vendor risks can be traced back to the vendor’s own risk assessment and compliance status.
Additional Metadata
Additional Metadata
Equipment needed, estimated cost, risk source (library or custom), identification date, and trend direction (increasing, stable, or decreasing).
Linking Risks to Controls
Linking risks to controls establishes a traceable relationship between identified risks and the measures implemented to mitigate them. This mapping is essential for:- Demonstrating control effectiveness to auditors
- Identifying gaps where risks lack adequate controls
- Prioritizing control implementation based on risk severity
Linking Risks to Vendors
Risks can be associated with one or more vendors, enabling vendor-specific risk tracking. This is particularly useful for:- Tracking risks introduced by third-party dependencies
- Connecting vendor risk assessments to your internal risk register
- Reporting on vendor-related risk exposure
Filtering and Search
The risk register detail view supports:- Text search — search by risk title or description
- Status filter — filter by workflow status (Draft, Needs Review, Approved, etc.)
- Category filter — filter by risk category
- Risk level filter — filter by inherent or residual risk level
Exporting Risks
Export the risk register to CSV for reporting, executive briefings, or audit submissions. The export includes all risk fields, scores, and treatment details.Snapshots from Registers
You can create a point-in-time snapshot directly from a risk register. This captures the current state of all risks in the register, including scores, statuses, and treatment plans. See Risk Snapshots for more details.Best Practices
- Assign clear owners to every risk — ownership drives accountability and timely treatment
- Review risks quarterly at minimum, updating scores based on new information or control changes
- Use the “Needs Review” status to flag risks that require attention at your next risk committee meeting
- Link every mitigated risk to at least one control to demonstrate a clear mitigation path
- Keep risk descriptions specific — “Data breach” is too vague; “Unauthorized access to customer PII via unpatched web application” is actionable
- Create separate registers for distinct compliance programs when their risk scopes differ significantly
- Take snapshots before major changes (quarterly reviews, control implementations, incident responses) to track the impact