The Risk Management module provides a comprehensive framework for identifying, assessing, treating, and monitoring risks across every domain the organisation owns — ICT and cyber, regulatory and compliance, operational, financial crime / AML, strategic and business, conduct and reputation, fraud, third-party and concentration, and ESG / climate risk. It works against every framework you enable in Venvera (DORA, NIS2, ISO 27001, GDPR, SOC 2, NIST CSF, EU AI Act, AMLD, PCI DSS, HIPAA, CMMC, UAE IA and more) and includes a visual dashboard for executive oversight, a detailed risk register, and configurable risk appetite settings.
Risk Dashboard
The dashboard provides an executive-level overview of your organization's ICT risk posture through interactive visualizations and summary statistics.
Summary Stat Cards
| Card | Content |
|---|---|
| Total Risks | The total count of all risks in the register, with a breakdown by risk level: Critical, High, Medium, and Low counts displayed beneath. |
| Critical + High | The combined count of Critical and High level risks, along with the percentage this represents of all risks. This highlights your most urgent risk exposure. |
| ICT Assets Tracked | The total number of ICT assets in the asset register, with the count of assets classified as Critical shown separately. |
| Overdue Reviews | The number of risks whose Next Review Date has passed without an updated review. These require immediate attention. |
Risk Heatmap
A 5x5 matrix with Impact (1-5) on the X-axis and Likelihood (5-1, top to bottom) on the Y-axis. Each cell displays the count of risks falling at that intersection of likelihood and impact. Cells are color-coded by the calculated risk score (Likelihood x Impact):
| Score Range | Color | Level |
|---|---|---|
| 1 – 4 | Emerald / Green | Low |
| 5 – 9 | Amber / Yellow | Medium |
| 10 – 15 | Orange | High |
| 16 – 25 | Red | Critical |
Risk Distribution by Category
A horizontal bar chart showing how many risks exist in each category (Cybersecurity, Data Breach, System Failure, Third Party, etc.). The bars are proportionally sized so you can quickly see which risk categories dominate your register.
Risk Appetite Indicator
Displays the organization's current risk appetite level (Conservative, Moderate, or Aggressive) along with the configured acceptance and escalation thresholds. This provides context for interpreting risk scores against the organization's stated tolerance.
Controls Coverage
A grid visualization showing how ICT controls map to risk categories, helping you identify areas with strong control coverage and gaps that need attention.
Top 10 Risks
A ranked table of the ten highest-scoring risks in the register, sorted by inherent risk score descending. This provides a quick view of the most critical risks that require management attention.
Risk Register
The risk register is the main working page for viewing, filtering, and managing all ICT risks.
Filters
| Filter | Options | Description |
|---|---|---|
| Search | Free text | Search by risk title or description text. |
| Category | Cybersecurity, Data Breach, System Failure, Third Party, Change Management, Access Control, Physical Security, Compliance, Operational, Other | Filter risks by their assigned category. |
| Level | Low, Medium, High, Critical | Filter by the calculated inherent risk level derived from the Likelihood x Impact score. |
| Status | Identified, Assessed, Treating, Monitoring, Closed | Filter by the current stage of the risk management lifecycle. |
| Treatment | Mitigate, Accept, Transfer, Avoid | Filter by the chosen treatment decision. |
Table Columns
| Column | Description |
|---|---|
| Title | The risk title. Click to open the risk detail/edit form. |
| Category | The risk category (e.g., Cybersecurity, Data Breach). |
| Score | Displayed as L x I = Score (e.g., 4 x 5 = 20) with a color-coded level badge (Low/Medium/High/Critical). |
| Treatment | The treatment decision: Mitigate, Accept, Transfer, or Avoid. |
| Status | The lifecycle status of the risk. |
| Owner | The person or role responsible for managing this risk. |
| Review Date | The next scheduled review date for this risk. |
Creating or Editing a Risk
Click New Risk to create a new entry, or click an existing risk title to edit it. The risk form is divided into multiple sections.
Basic Information
| Field | Type | Description |
|---|---|---|
| Title | Text input | A concise name for the risk. Required |
| Description | Textarea | A detailed narrative of the risk scenario, including potential causes and consequences. Optional |
| Risk Category | Select dropdown | Choose from: Cybersecurity, Data Breach, System Failure, Third Party, Change Management, Access Control, Physical Security, Compliance, Operational, Other. Required |
| Threat Source | Text input | The origin of the threat (e.g., "External attacker", "Disgruntled employee", "Natural disaster"). Optional |
| Vulnerability | Text input | The specific weakness that could be exploited (e.g., "Unpatched web server", "No MFA on admin accounts"). Optional |
Inherent Risk Assessment
The inherent risk assessment captures the risk level before any controls or treatment measures are applied.
| Field | Type | Description |
|---|---|---|
| Likelihood | 1-5 pill selector | Rate the probability of the risk materializing on a scale of 1 (Rare) to 5 (Almost Certain). Click a pill to select. |
| Impact | 1-5 pill selector | Rate the potential business impact on a scale of 1 (Negligible) to 5 (Catastrophic). Click a pill to select. |
| Score | Auto-calculated display | Automatically calculated as Likelihood x Impact. Displayed with a color-coded level badge (Low 1-4, Medium 5-9, High 10-15, Critical 16-25). |
Treatment
| Field | Type | Description |
|---|---|---|
| Treatment Decision | Radio buttons | Select one of four treatment strategies: • Mitigate — Implement controls to reduce likelihood or impact. • Accept — Acknowledge the risk and take no further action (within appetite). • Transfer — Shift the risk to a third party (e.g., insurance, outsourcing). • Avoid — Eliminate the risk by removing the activity or system. |
| Treatment Description | Textarea | Detail the specific actions being taken or planned for the chosen treatment strategy. Optional |
Residual Risk Assessment
The residual risk assessment captures the risk level after treatment measures and controls have been applied or are planned.
| Field | Type | Description |
|---|---|---|
| Residual Likelihood | 1-5 pill selector | The expected likelihood after treatment measures are in place. |
| Residual Impact | 1-5 pill selector | The expected impact after treatment measures are in place. |
| Residual Score | Auto-calculated display | Residual Likelihood x Residual Impact, displayed with a level badge. |
Risk Tolerance
| Field | Type | Description |
|---|---|---|
| Risk Tolerance | Radio buttons | Indicate whether the residual risk falls within the organization's appetite: • Within Tolerance — Residual risk is acceptable per risk appetite settings. • Above Tolerance — Residual risk exceeds appetite; additional treatment or monitoring needed. • Requires Escalation — Risk exceeds escalation threshold and must be reported to senior management or the board. |
Risk Status
| Field | Type | Description |
|---|---|---|
| Risk Status | Select dropdown | The lifecycle stage of the risk: • Identified — Risk has been recognized but not yet assessed. • Assessed — Risk has been scored and categorized. • Treating — Treatment actions are actively being implemented. • Monitoring — Treatment is in place; risk is being monitored for changes. • Closed — Risk has been eliminated or is no longer relevant. |
Linked Entities
| Field | Type | Description |
|---|---|---|
| Linked Assets | Multi-select checkboxes | Select one or more ICT assets from the asset register that are affected by or related to this risk. |
| Business Functions | Multi-select checkboxes | Select the business functions impacted by this risk. Functions marked as critical in the Register of Information display a Critical badge. |
| ICT Controls | Multi-select checkboxes | Select the controls that mitigate or address this risk. This creates a bidirectional link between risks and controls. |
Regulatory References
Map the risk to specific regulatory requirements across the frameworks below. A single risk can be tagged to many frameworks at once — the framework toggles available depend on which frameworks you have enabled in your tenant.
| Framework | Type | Description |
|---|---|---|
| DORA Articles | Toggle buttons | Select applicable DORA articles from Art. 5 through Art. 16. Each button has a tooltip explaining the article's scope (e.g., Art. 5: ICT Risk Management Framework, Art. 6: ICT Systems and Tools, etc.). |
| NIS2 Articles | Toggle buttons | Select applicable NIS2 cybersecurity measures from Art. 21(2)(a) through Art. 21(2)(j), covering areas such as risk analysis, incident handling, business continuity, supply chain security, and cryptography. |
| ISO 27001 Controls | Toggle buttons | Select applicable ISO 27001:2022 Annex A controls from A.5 (Organizational) through A.8 (Technological). |
Review Dates
| Field | Type | Description |
|---|---|---|
| Review Date | Date picker | The date this risk was last reviewed. Optional |
| Next Review Date | Date picker | The scheduled date for the next risk review. When this date passes, the risk will appear in the Overdue Reviews count on the dashboard. Optional |
Key Risk Indicators (KRIs)
Key Risk Indicators are the quantitative early-warning signals that sit alongside the risk register. While a risk describes a possible scenario, a KRI is the measurement that tells you whether that scenario is becoming more likely or more impactful right now. KRIs answer the regulator's first question: “How do you know your risk environment is still within tolerance?”
Venvera ships ~20 standard KRIs across all ten enterprise risk domains, each one anchored to specific regulatory articles. Common examples:
| KRI | Domain | Anchored to |
|---|---|---|
| Critical risks above tolerance | Operational | DORA Art. 6, Art. 16 · ISO 27001 6.1.2, 6.1.3 · NIS2 Art. 21(2)(a) |
| Open major incidents | Cyber & ICT | DORA Art. 17, Art. 19 · NIS2 Art. 23 · ISO 27001 A.5.24 |
| Incidents with missed regulator deadline (90d) | Cyber & ICT | DORA Art. 19 · NIS2 Art. 23 · GDPR Art. 33 |
| Mean time to remediate critical risks | Cyber & ICT | DORA Art. 6, Art. 9 · ISO 27001 8.1, 10.1 |
| % policies past review date | Regulatory | ISO 27001 5.1, 5.5 · DORA Art. 9 · NIS2 Art. 21(2)(a) |
| Top-5 vendor spend concentration | Third-Party | DORA Art. 31 |
| Vendor spend HHI (Herfindahl-Hirschman Index) | Third-Party | DORA Art. 31 |
| Critical functions on a single provider | Third-Party | DORA Art. 31 |
| % staff completed annual security training | Cyber & ICT | NIS2 Art. 21(2)(g) · ISO 27001 A.6.3 · DORA Art. 13 |
| Open vulnerabilities > 30 days (high / critical) | Cyber & ICT | ISO 27001 A.8.8 · DORA Art. 9 · NIS2 Art. 21(2)(e) |
| AML alerts open > 30 days | Financial Crime | AMLD6 Art. 13, Art. 30 |
| % of resilience tests on schedule | Resilience | DORA Art. 24-27 |
Direction, thresholds and status
Each KRI declares whether lower is better (e.g. # open incidents) or higher is better (e.g. % staff training completion). Two thresholds — green and amber — partition the value range into three zones. The status that gets recorded with every measurement is:
| Status | Lower is better | Higher is better |
|---|---|---|
| Green | value ≤ green threshold | value ≥ green threshold |
| Amber | green threshold < value ≤ amber threshold | amber threshold ≤ value < green threshold |
| Red | value > amber threshold | value < amber threshold |
Auto-computed vs manual KRIs
KRIs with an auto_compute_key derive their value from system data — risks, incidents, controls, vendors, sub-outsourcing chains, integration findings. Click Auto-compute on the KRI page (or wait for the daily worker) and every auto-computable KRI gets a fresh measurement. Manual KRIs (AML alerts, phishing click-rate, RTO/RPO compliance, ESG climate exposure) are recorded by their owner from the KRI detail page.
Regulatory-clock coupling on breach
On each KRI definition you can toggle “Auto-create regulatory incident on breach”. When the KRI crosses into red, Venvera immediately:
- Records a
kri_breach_eventsrow. - If the toggle is on, opens an
incidentsrow with the statutory clock derived from the KRI’s framework anchoring:- DORA — 4-hour initial / 24-hour intermediate / 72-hour final / 1-month root-cause (Art. 19)
- NIS2 — 24-hour early warning / 72-hour notification / 1-month final (Art. 23)
- Fires an outbound webhook (Slack / Teams / custom) to the configured channels.
Composite domain-health scores
The KRI page header card “Overall health” plus the per-domain composite grid surface a 0–100 score for each of the ten enterprise risk domains. The score is a weighted average of the constituent KRIs, where KRIs anchored to more framework articles weigh more (a KRI tagged to DORA Art. 6 and ISO 27001 6.1.3 and NIS2 Art. 21(2)(a) carries more pull than one with a single anchor). Trajectory (improving / stable / worsening) is derived from the last three snapshots.
Regression alerts
The dashboard banner “KRIs trending toward red” highlights indicators whose trajectory is worsening, including those still inside the green band. Detected patterns:
- Status downgrade in the most recent measurement (green → amber or amber → red) — flagged as rapid worsening.
- Three consecutive measurements each worse than the previous — flagged as worsening.
- Value drifted >25 % closer to the amber threshold over the recent window.
Control-failure to KRI propagation
Each KRI detail page has a Linked controls section. Pick the controls whose effectiveness materially affects the KRI value. When any of those controls fails (implementation_status not_implemented or effectiveness below partially_effective), the KRI is surfaced in the “KRIs at risk from failing controls” banner on the dashboard — even before the next measurement is recorded.
Recording a measurement
- Open the KRI detail page (click any row in the KRI list).
- In the Record measurement card enter the new value (and optionally a note explaining the context).
- Click Record. The status is derived from the value plus thresholds. If the status crosses into red, the breach handler fires.
Auto-compute
Click Auto-compute at the top of the KRI page to refresh every auto-computable KRI from current system data. The action returns a count of measurements recorded plus the number of breaches opened in this batch. A daily background job runs the same code without user action.
Regulator-grounded threshold suggestions
When you define a new KRI and tag it to a framework article, Venvera suggests a sensible default for unit, direction and the green/amber thresholds — anchored to what the regulation actually expects. For example, an article-tagged DORA Art. 31 KRI starts with HHI thresholds at 1500 (green) and 2500 (amber), the bands used in competition-policy precedent. Suggestions cover DORA, NIS2, ISO 27001, GDPR and AMLD6.
KRI Snapshots
Every risk snapshot captures the current KRI landscape alongside the risk register. The snapshot detail page shows a full KRI snapshot section with the value, status, target and regulatory anchors at the time of capture. This is what auditors review when they ask “how did the risk picture look in Q1?”
Snapshot diff
From Risk Management › Snapshots click Compare snapshots to pick two snapshots and render a board-ready narrative of what changed:
- KRI transitions (green → amber, amber → red, etc.)
- Risk-level delta per status
- Control implementation delta
- Narrative summary: “Between Q1 2026 and Q2 2026: 3 KRIs worsened, 1 critical-level risk added, control coverage moved 86% → 91%.”
The diff page has a one-click Download board-pack PDF (with this diff) button that produces a fully formatted PDF including the diff narrative as a section.
Board Pack PDF
The Board pack PDF button on the KRI page generates a board-ready PDF covering:
- Cover page with overall health score, status and trajectory.
- Per-domain composite health with score bars.
- “KRIs trending toward red” — regression alerts, including KRIs still inside green.
- Open KRI breaches with statutory clock status (DORA / NIS2 due-dates highlighted when overdue).
- Optional snapshot diff narrative.
- Regulatory readiness per framework — composite score across all KRIs anchored to that framework.