Risk assessment & register
that moves on its own.
Most risk registers are a spreadsheet that was true once. Score a risk on likelihood and impact, attach the controls that treat it, and TryTrustable recalculates residual risk every time those controls change state.
Inherent, then residual, and the difference is the work
A 5×5 assessment gives you the inherent score. The controls you attach give you the residual one. When a control starts failing, the residual score climbs before anyone files a ticket.
- Likelihood and impact scored 1–5
- Inherent and residual held separately
- Residual recalculated from live control state
- Appetite thresholds that raise their own alerts
Four options, one named owner
Mitigate, accept, transfer or avoid, each with an owner and a review date, because an unowned risk is a risk nobody is treating.
- Mitigate · accept · transfer · avoid
- A named owner on every entry
- Review dates that raise reminders
- Categories: infrastructure, vendor, data, people, process
The same register, wider aperture
Data protection impact assessments and vendor reviews feed the same register, so privacy risk and security risk are ranked on one scale instead of two.
- DPIA templates for DPDP and GDPR Art. 35
- Vendor risk scored on data access and evidence on file
- Breach simulation results land as risks
- Board-ready export by category and owner
See your own risks scored.
Bring three real risks to the call. We will score them live, attach the controls, and show you what the residual number does when a control fails.
Inherent, residual, and why the difference is the whole point
A risk register that records one number per risk is recording an opinion. Two numbers record an argument: what this would cost you with nothing in place, and what it costs you given the controls you actually operate. The gap between them is the value of your control set, stated in the only terms a board reads.
Inherent risk is likelihood times impact before treatment. Residual risk is the same assessment after the controls attached to it are accounted for. Most registers hold both as hand-entered figures, which means residual risk only changes when somebody remembers to change it: typically during the week before an audit, and typically downward.
| Score | Band | What it should trigger |
|---|---|---|
| 1–4 | Low | Accept and review annually |
| 5–9 | Moderate | Named owner, treatment plan, review every six months |
| 10–14 | High | Active treatment, quarterly review, visible to leadership |
| 15–19 | Severe | Escalation, dated remediation plan, monthly review |
| 20–25 | Critical | Board-level, immediate treatment or a documented decision to accept |
A 5×5 matrix scoring likelihood and impact 1 to 5. The bands matter less than applying them consistently.
Four treatments, and only one of them is doing nothing
- Mitigate. Attach controls that reduce likelihood or impact. The default, and the only one that changes the residual score by itself
- Transfer. Move the financial consequence to an insurer or a counterparty. Note what this does not move: regulatory liability under the DPDP Act or the GDPR stays with you regardless of what your contract says
- Avoid. Stop doing the thing. Underused, and frequently the cheapest answer for a data set nobody can name a purpose for
- Accept. A legitimate choice, but only when it is a decision with a name and a date attached. An unowned risk is not accepted, it is ignored, and the two look identical in a register and completely different in an inquiry
Why residual risk should move without anyone touching it
If a control that treats a risk starts failing, the risk has changed whether or not anybody has updated the spreadsheet. That is the case for deriving residual score from live control state rather than storing it: the register stops being a record of what somebody believed last quarter and becomes a readout of what is true now.
It also inverts the direction of surprise. In a hand-maintained register, risk scores drift down between audits because nobody logs deterioration. When the score is derived, a failing access review raises the residual figure on the risks it treats, and the alert arrives before the audit rather than during it.
The same control library feeds framework readiness, which is what stops the two diverging: see cross-framework mapping for how one control result reaches several requirements at once.
Where registers go wrong
- Risks written as topics. "Cyber security" is not a risk. "Customer PII exfiltrated from the reporting database via an over-permissioned service account" is one you can score, own and treat
- No owner, or an owner who does not know. The most common finding, and the reason review dates pass silently
- Scores that only ever improve. A register where nothing has worsened in two years is not being maintained
- Vendor risk kept somewhere else. Third-party risk belongs in the same register with the same scoring, or it is compared against nothing
- No link to the assessment that found it. A risk surfaced by a DPIA should point back at it, so the reasoning survives the person who did the work
If you are starting a register from nothing, a readiness check tends to surface the first dozen entries faster than a workshop does, and the DPIA template is the right instrument where the processing is high-risk.
The things people ask us
What is the difference between inherent and residual risk?
Inherent risk is likelihood times impact with no controls applied. Residual risk is the same assessment once the controls treating it are accounted for. Holding both separately is what lets you show what your control set is actually worth; holding only one turns the register into an opinion.
How often should a risk register be reviewed?
Review cadence should follow the score: annually for low risks, six-monthly for moderate, quarterly for high and monthly for severe. More important than the interval is that a review date passing without action raises an alert rather than being noticed at the next audit.
Does transferring a risk through insurance remove it?
It moves the financial consequence, not the obligation. Regulatory liability under the DPDP Act or the GDPR remains with the Data Fiduciary or controller whatever your contracts say, so a transferred risk should still carry a residual score and an owner.
Why should residual risk be calculated rather than entered?
Because a stored number only changes when somebody remembers to change it, and in practice that happens before audits and in the favourable direction. Deriving it from live control state means a failing control raises the score on every risk it treats, at the moment it starts failing.
What makes a risk entry good enough to act on?
It names a specific asset, a specific threat and a specific consequence, rather than a topic. "Cyber security" cannot be scored or owned. "Customer PII exfiltrated from the reporting database via an over-permissioned service account" can be.
Is a DPIA the same thing as a risk assessment?
No. A risk assessment scores risks to the organisation. A DPIA assesses risk to the rights and freedoms of individuals from a specific processing activity, and is required for Significant Data Fiduciaries under DPDP Section 10 and for high-risk processing under GDPR Article 35. Findings from a DPIA should feed the register, linked back to the assessment.