Risk register
Risk Management → Risk Register
The register is the organisation's single list of risks. Everything else in the risk module — engagements, treatments, KRIs — hangs off it.
A register risk is one that somebody has adopted and taken ownership of. Plain risk statements that nobody owns yet belong in the risk library, which is where most register risks start.
Reading the register
Each row is one risk:
| Column | What it shows |
|---|---|
| Code | The risk's reference, in full — the one you cite in reports. |
| Risk | The title, with its category underneath. |
| Inherent | The score before controls, with its level spelled out — for example 20 · Critical. Hover it for likelihood × impact. |
| Residual | The score after controls, with its own level. Not assessed means nobody has assessed it yet — see below. |
| Status | Where the risk is in its lifecycle. |
| Owner | The person accountable for the risk. |
The register opens with the highest inherent score first. Click any column header to sort by it; click again to reverse. Risks with no residual score or no owner always sort to the bottom, whichever direction you choose. Click a row to open the risk.
Levels follow the 5 × 5 matrix: Critical 15–25, High 8–14.9, Medium 4–7.9, Low below 4.
The risk page
A risk opens with a header that carries its code, title, status and four facts at a glance: owner, category, next review (with how many days are left, or how overdue it is) and last assessed.
Below that, the lifecycle shows how far the risk has come — identified, assessed, treating, monitored. Finished stages are filled in, the current stage is highlighted in gold. An accepted or closed risk shows that decision as its status instead of a stage, because a risk can be accepted or closed from several points in the lifecycle.
The score strip underneath shows the three readings side by side — inherent, residual and target — each with its level. Likelihood × impact is shown only when both were actually recorded.
In the Arabic interface the risk shows its Arabic title when one has been entered.
Adding a risk
Two routes.
From the library — the usual way. In the risk library, import
an entry from your organisation library. It arrives with its inherent score,
category and origin, status identified, and you as the owner until you
reassign it.
New Risk — for a risk that is genuinely one-off. Record:
| Field | Notes |
|---|---|
| Title / Title (Arabic) | What could go wrong. |
| Category | Groups the register for reporting. |
| Likelihood / Impact | 1–5 each. Their product is the inherent score (1–25). |
| Owner | The person accountable. Not the person doing the work. |
| Source | Where the risk came from — assessment, incident, workshop, regulator. |
Inherent, assessed, residual
Three scores, three meanings. Keeping them apart is the point of the module.
- Inherent — the risk before any controls. Set on the register.
- Assessed — what an engagement concluded when it looked.
- Residual — what remains after controls and treatments.
A blank residual means nobody has assessed it yet. It does not mean zero, and the platform will not fill it in for you.
The residual is not typed in. It is calculated from the controls mapped during an assessment and how effective each one was found to be — Controls shows the formula, worked through, and what happens as controls accumulate. A risk assessed with no controls mapped has a residual equal to its assessed score: no controls, no reduction.
Two rules hold everywhere:
- Residual never exceeds inherent. If a change would leave the residual above the inherent score — a lower base score, or a treatment that planned a higher residual — the residual is brought down to the inherent score.
- Completing treatments is not an assessment. When every treatment on a risk is done, the risk moves to monitored and its residual moves to the lowest residual those treatments planned. Its last assessed date does not change: nobody re-scored the risk.
Status
identified → assessed → treating → monitored, with accepted for risks
knowingly carried and closed for risks that no longer apply. Transitions are
validated by the platform; a risk can be closed from any status, and a closed
risk is reopened back to identified.
A new risk always starts as identified, whichever route created it.
Closing is a checker's decision. The analyst who raised and worked a risk cannot retire it: moving a risk to closed needs a manager or above, the same bar as accepting it. An analyst who tries is told who to ask. Reopening a closed risk (back to identified) stays open to any editor.
Appetite
When a risk's category has an active appetite statement, the risk is checked against its critical line whenever its scores change. The check uses the risk's current score — the residual once it has been assessed, the inherent score until then — so a risk that controls have brought well below the line does not raise a breach just because its inherent score is high. A risk at or above the line opens a breach and notifies its owner.
Owner and review frequency
Every risk has one accountable owner — choose them by name on the new-risk form (it defaults to you) and change them later from Edit on the risk page, where the review frequency (monthly, quarterly, semi-annual, annual) also lives. The owner must be a member of your organisation.
Treatments
A treatment is what you are doing about a risk: mitigate, transfer, avoid or accept. Each has an owner, a due date and a target residual score. Treatments appear in the engagement report and on the dashboard, with overdue ones flagged.
A treatment is overdue once its due date has passed and it is not completed or cancelled. The daily check marks it Overdue; until that check has run, it is counted as overdue anyway. The Overdue count on the Treatments page, the Overdue due-date filter and the board pack all use this same rule.
Accepting a risk
Accepting a risk means the organisation will carry it rather than treat it. That is a decision someone is accountable for, so it is recorded, not just a status: on the risk page, Risk acceptance → Accept risk.
- Who — a manager or above. The approver should not be the risk's own owner; a small organisation can still do it, but the platform asks for a reason (at least 10 characters) and keeps it with the acceptance.
- Why — a written rationale of at least 20 characters.
- Until when — an expiry between tomorrow and 24 months ahead. The risk's next review date follows it.
The panel shows the active acceptance: who accepted it, when, until when, at what residual score, and why. Renew records a new acceptance that replaces the old one (both are kept). Withdraw ends it with a reason and sends the risk back to assessed. When an acceptance expires, the overnight job ends it and sends the risk back to assessed for a new decision — accepted risks also get review reminders like any other.
You cannot set accepted by editing a risk's status; it always goes through this record. Nor can an analyst end one: while an acceptance is active, moving the risk to any other status is refused below manager — the decision is ended only by the manager's Withdraw, by expiry, or by a manager moving the risk on. Other fields of an accepted risk stay editable. An engagement that closes with a reviewed accept response records an acceptance too, approved by whoever closed the engagement and expiring at the risk's next review.
An accepted risk with a named approver, a reason and an expiry is defensible to a regulator; an ignored one is not.
Proposals from findings
A compliance finding can be escalated into the register as a risk proposal: the auditor proposes a new risk, or a link to an existing one, with a written rationale; the risk team (manager or above) accepts, rejects or asks for more information from Risk → Proposals. Accepting a new proposal creates the register row and links the finding to it; every link in the register is traceable to a proposal someone accepted.
The proposer does not decide their own proposal. A manager who proposed a risk and then presses Accept or Reject is asked to record why no one else on the risk team can decide it (at least 10 characters); the reason is kept in the audit trail against the decision. The proposer may always withdraw an undecided proposal.