Risk Register
Proactively identify, assess, and manage risks across your applications
What is the Risk Register?
The Risk Register is where your organisation documents known threats and vulnerabilities before they become incidents. Rather than waiting for something to go wrong, you proactively identify what could go wrong, assess how likely and how damaging it would be, and decide on a course of action.
Every risk in Anzen is scoped to an application - whether that is a business application, a capability, or a service. This ensures risks are not floating abstractions but are tied to something tangible that your team manages and cares about.
The Risk Register feeds directly into the Risk Report, where inherent and residual scores are aggregated into heatmaps, trend analysis, and upcoming review schedules.
Where to Find It
Navigate to any Application detail page and scroll down to the Risk Register section. Each application has its own set of risks, giving you a focused view of what threatens that particular part of the business.
You can also see a consolidated view of all risks across all applications in the Risk Report under the Risk Register tab. This consolidated view is for monitoring only - new risks are always created from the application they affect.
Creating a Risk
Click New Risk from an application's detail page. The form guides you through capturing the essential information:
- Title and description - a clear, specific statement of the threat. Avoid vague language; "ransomware attack on production infrastructure" is better than "cyber risk".
- Category - classify the domain: strategic, operational, financial, compliance, technology, or reputational. This helps filter and prioritise across the organisation.
- Inherent risk scoring - the likelihood and impact before any controls are applied. This represents the raw, unmitigated threat.
- Residual risk scoring - the likelihood and impact after your controls are in place. Anzen computes this for you from the controls you link to the risk, so you do not score it by hand. The gap between inherent and residual tells you how effective your mitigation is. The risk owner can override the computed value when needed (see Risk Scoring below).
- Treatment strategy - your chosen response: mitigate, accept, transfer, or avoid.
- Risk owner - the person accountable for monitoring and managing this risk. Defaults to the application owner but can be changed.
- Review date - when this risk should next be reassessed. Overdue reviews are highlighted in the Risk Report.
Risk Scoring
Each risk is scored on two dimensions: likelihood (how probable is it?) and impact (how severe would the consequences be?). Both are rated on a 1 to 5 scale.
The overall risk score is the product of the two: likelihood × impact, giving a range from 1 (trivial) to 25 (critical). Anzen colour-codes these scores so your team can spot high-priority risks at a glance:
You set the inherent score by hand - the raw threat before any controls. The residual score, by contrast, is computed by Anzen from the controls you link to the risk, and is reported at two levels. The target (predicted) residual is where your controls leave the risk if they all operate as designed. The actual (current) residual takes those same controls at their latest tested effectiveness. The distance between the two is the control-performance gap: it shows where controls are not delivering what they were designed to.
Each control linked to a risk carries a categorical mitigation strength on likelihood and/or impact (None, Low, Medium, or High). This is what drives the target residual: linking or unlinking a control, or changing its strength, recomputes the target. The actual residual then moves with control test results - a partial or failed test, or a control that is overdue or has never been tested, pushes the actual residual back toward inherent until the control is performing again.
Owner override. Residual is computed by default, but the risk owner can override the reported residual likelihood and impact (each 1 to 5) when their judgement differs from the computed value. An override requires a reason and visibly flags the risk as diverging from the computed residual, so the divergence is never silent. The override can be cleared at any time to return to the computed value.
| Score range | Severity | Colour |
|---|---|---|
| 1-4 | Low | Green |
| 5-9 | Medium | Orange |
| 10-15 | High | Red |
| 16-25 | Critical | Purple |
Inherent and residual scores are shown side by side, making it easy to demonstrate that your mitigation efforts are working - and where the computed residual is overridden, the reported value and the divergence flag are shown together so reviewers can see exactly what was changed and why.
Risk Categories
Anzen provides six categories to classify risks across your organisation:
- Strategic - risks to business direction, market position, or competitive advantage.
- Operational - risks to day-to-day processes, staffing, or supplier dependencies.
- Financial - risks to revenue, budgets, or cost structures.
- Compliance - risks of regulatory violations, legal exposure, or policy breaches.
- Technology - risks related to system failures, cyber threats, or infrastructure outages.
- Reputational - risks to brand perception, public trust, or stakeholder confidence.
Risk Statuses
Each risk follows a lifecycle from identification through resolution:
| Status | Meaning |
|---|---|
| Open | The risk has been identified but no action has been taken yet. |
| In Treatment | Active mitigation is underway - controls are being implemented or strengthened. |
| Accepted | The organisation has consciously decided to tolerate this risk. |
| Mitigated | Controls are in place and effective. Residual risk is within acceptable bounds. |
| Closed | The risk is no longer relevant - the threat has been eliminated or the asset retired. |
Treatment Strategies
When you identify a risk, you must decide how to respond. Anzen supports the four standard treatment strategies from ISO 31000:
| Strategy | When to use it |
|---|---|
| Mitigate | Implement controls to reduce the likelihood or impact. This is the most common response - for example, deploying endpoint detection to reduce ransomware risk. |
| Accept | The cost of mitigation outweighs the potential loss, or the risk falls below your appetite threshold. Document why, set a review date, and monitor. |
| Transfer | Shift the financial impact to a third party through insurance, outsourcing, or contractual obligations. |
| Avoid | Eliminate the risk entirely by removing the activity, system, or process that creates it. This is appropriate when the risk is unacceptable and cannot be adequately mitigated. |
Linking Risks to Your Organisation
Risks do not exist in isolation. Anzen lets you connect each risk to the parts of your organisation it affects:
- Affected assets - which configuration items (servers, systems, devices) would be impacted if this risk materialises?
- Affected business processes - which business processes would be disrupted?
- Mitigating controls - which controls reduce the likelihood or impact of this risk? Each link carries a mitigation strength on likelihood and/or impact (None, Low, Medium, or High), and together these links drive the computed residual score. Linking controls to risks creates a traceable chain from threat to mitigation, and is what powers auto fan-out (see below).
- Linked issues - the risk detail page lists every issue currently affecting this risk. The relationship is many-to-many - one issue can hit several risks, and one risk can be affected by many issues over time. When a test on a mitigating control fails, the resulting issue is automatically linked to this risk; ad-hoc issues can be linked by hand.
- Related tickets - any change requests or incidents that relate to this risk for audit traceability.
These links serve two purposes: they give auditors a clear picture of how you manage risk, and they feed into the Risk Report for automated scoring and coverage analysis.
Risk Ownership
Every risk should have an owner - the person who is accountable for ensuring the risk is monitored, treated, and reviewed on schedule. When creating a risk, the owner defaults to the application owner, but you can assign any user.
Risk ownership is not the same as doing the work. The owner may delegate remediation to engineers or security teams, but they remain responsible for ensuring the risk is managed and reported on time.
Assessment History
Every change to a risk is recorded in the Assessment History timeline on the risk detail page. This includes changes to scores, status, treatment strategy, ownership, and review dates.
The history shows who made each change, when, and exactly which fields were modified - with old and new values displayed side by side. This audit trail is essential for demonstrating to regulators and auditors that your risk management is an active, living process rather than a one-time exercise.
Review Cycle
Set a review date on each risk to establish a reassessment cadence. The Risk Report's Risk Register tab highlights risks with upcoming or overdue reviews, ensuring nothing falls through the cracks.
A good practice is to review critical risks (scores above 15) quarterly and lower risks annually. Each review should re-evaluate the inherent score, confirm the linked controls and their mitigation strengths still reflect reality (the residual score follows from these), revisit any owner override, confirm the treatment strategy is still appropriate, and update the review date for the next cycle.