Most organisations keep their incident log and their risk register in separate worlds. One is owned by operations, the other by the risk team, and the two rarely talk to each other. That is a missed opportunity, because an incident is simply a risk that materialised. Every incident is hard evidence about which risks are real, how likely they actually are, how much they actually hurt, and whether your controls actually work. Wiring these two systems together turns your incident log from a record of pain into a continuous calibration engine for your risk register. This guide shows you, step by step, how to build that connection.
What You'll Achieve
By the end of this tutorial you will be able to treat incidents as materialized risks, link each incident to the relevant register entry, use incident data to validate likelihood and impact scores, test whether your controls are working, surface genuinely new risks, and operate the full feedback loop, with a complete worked example to copy.
An Incident Is a Materialized Risk
The cleanest way to think about the relationship is this: your risk register is a list of bad things that might happen, and your incident log is a list of bad things that did happen. When an incident occurs, one of the risks you were worried about (or one you weren't) just came true. That is enormously valuable feedback.
A risk register is, by nature, built on estimates. You estimate how likely each risk is and how badly it would hurt. Those estimates are educated guesses until reality tests them. An incident is reality testing your estimate for free. If you ignore it, your register stays theoretical; if you feed it back in, your register becomes grounded in evidence.
This is why mature programmes deliberately connect the two. The incident log, set up as described in how to build an incident register, becomes the empirical layer underneath the register's estimates.
Pro Tip
Before you can link anything, both systems need to exist and be reasonably clean. If you have not yet built them, start with the incident side and the register side separately, then connect them. Trying to build both at once usually produces two half-finished systems.
Step 1: Link Each Incident to a Risk
The mechanical foundation of the feedback loop is a simple link: every significant incident should reference the risk register entry (or entries) it relates to. In practice this is a "Related Risk" field on the incident record holding one or more risk IDs.
When you log or close out an incident, ask: "Which risk in our register does this incident represent?" There are three possible answers, and each one drives a different action.
| Answer | What It Means | Action |
|---|---|---|
| It maps to an existing risk | A risk you were tracking materialized | Link the incident; revisit the risk's scores and controls |
| It partially maps | Related to a known risk but with a new angle | Link it and update the risk description / add a scenario |
| It maps to nothing | A risk you were not tracking at all | Create a new risk register entry |
This linking step is the same discipline described in how to link risks, controls and actions. You are just extending the web of relationships to include real-world events. Once the link exists, every other part of the loop becomes possible.
Want the full framework with worked examples?
Step 2: Validate Likelihood and Impact
This is where the feedback loop starts paying off. When you originally scored a risk, you estimated its likelihood and impact. An incident gives you actual data to check those estimates against.
Validating Likelihood
If you scored a risk as "Rare" (once every several years) but you have now had three incidents of that type in twelve months, your likelihood estimate was wrong. The register should be updated upward. Conversely, if a risk you scored as "Almost Certain" has not materialised in two years despite no new controls, you may have over-estimated it.
Validating Impact
Your impact estimate is also testable. If you scored a risk's impact as "Moderate" (a few hours of disruption) but the incident actually caused two days of downtime and a regulatory notification, the real impact was higher than estimated. Update the score and the rationale.
Important
Do not over-react to a single data point. One severe incident does not necessarily mean a risk is now "Almost Certain"; it might have been an unlucky tail event. Use incidents as evidence that informs your judgement, alongside trend data, not as an automatic recalculation. The goal is a register that is better calibrated over time, not one that lurches with every event.
Step 3: Test Control Effectiveness
Every risk in your register has controls attached, the measures that are supposed to reduce its likelihood or impact. An incident is a live test of those controls. When a risk materialises, at least one control either failed, was missing, or was bypassed. The PIR (covered in what a post-incident review is) is where you diagnose which.
For each linked incident, ask three questions of the controls:
- Did the preventive controls fail or were they missing? If the control existed and still let the incident through, it is less effective than your register claims.
- Did the detective controls catch it in time? If detection was slow, your monitoring controls need work.
- Did the corrective controls limit the damage? If recovery was slow or messy, your response controls need work.
The answers feed directly into your residual risk scoring. Residual risk is what is left after controls; if an incident proves your controls are weaker than assumed, your residual risk is higher than your register shows. Understanding the different types of risk controls helps you target the right fix, whether preventive, detective, or corrective.
Pro Tip
When an incident reveals a weak control, the PIR action item to strengthen it should be linked back to the risk register entry. That way the register shows not just "this control is weak" but "and here is the dated action to fix it, with an owner." The loop is only closed when the action is tracked against the risk.
Step 4: Surface New Risks
Some incidents map to nothing in your register; they represent a risk you simply were not tracking. These are the most valuable incidents of all, because they reveal a blind spot. When an incident has no matching risk, create one.
A new risk born from an incident has a built-in advantage: you already know it is real, because it just happened. You can score its likelihood as at least "Possible" (it occurred once) and its impact from the actual damage. You also already have a candidate control gap from the PIR. This makes incident-derived risks some of the best-evidenced entries in your whole register.
The Feedback Loop in Full
Put the steps together and you have a continuous loop that keeps your register honest:
- An incident occurs and is logged in the incident register.
- You link it to an existing risk, or create a new one if none fits.
- You run a post-incident review to understand causes and control failures.
- You update the risk: revise likelihood and impact, downgrade control effectiveness where it failed, and add remediation actions.
- The improved controls reduce the chance or impact of the next occurrence.
- The next incident (or its absence) tests whether the changes worked, and the loop continues.
Over time this loop makes your register progressively more accurate and your controls progressively stronger. It is the mechanism by which an organisation actually learns from experience rather than repeating it.
Worked Example
Here is the loop running end to end on a single incident.
From Incident INC-2026-0211 to Register Update
The incident: A phishing email led to a compromised staff mailbox, used to send fraudulent payment-change requests. Detected after 6 hours; one near-miss payment was stopped by finance.
Step 1, Link: Maps to existing risk R-2026-014 "Business email compromise / payment fraud." Incident linked.
Step 2, Validate scores: Risk was scored Likelihood 2 (Unlikely). This is the second BEC incident this year, so likelihood revised to 3 (Possible). Impact held at 4 (Major), since the near-miss showed how close a large fraudulent payment came.
Step 3, Test controls: Preventive control (email filtering) failed to catch the phish. Detective control (login-anomaly alerting) did not exist. Corrective control (finance call-back on payment changes) worked and prevented the loss, so that is the control to protect.
Step 4, New risk? No new risk needed, but the missing detective control is added as a control gap on R-2026-014, with action "Deploy impossible-travel login alerting (Owner: IT Security, Due: 30 Jun 2026)."
Residual risk update: Residual score raised from 6 to 9 until the new detective control is in place, then to be re-reviewed.
Common Mistakes to Avoid
1. Keeping the Two Systems Apart
If incidents and risks live in separate tools with no link between them, the feedback loop never runs. The "Related Risk" field is the cheapest, highest-value connection you can build.
2. Linking but Never Acting
Adding a risk ID to an incident is only step one. If you never revisit the risk's scores and controls afterwards, you have a tidy link and a stale register.
3. Over-Reacting to One Incident
A single severe event can be a tail outcome, not a new normal. Adjust scores using incidents as evidence alongside trends; do not lurch on every event.
4. Forgetting the "No Match" Case
Incidents that map to no existing risk are the most valuable, because they reveal blind spots. Don't discard them as "out of scope"; create the new risk.
5. Ignoring Controls That Worked
The loop is not only about what failed. Recording which control saved you tells you what to protect and reinforces good investment.
Summary
- An incident is a materialized risk; it is free, real-world evidence about your register's accuracy.
- Link every significant incident to the relevant risk entry (or create a new one if it maps to nothing).
- Use incidents to validate likelihood and impact scores and to test whether your controls actually work.
- Incidents that match no existing risk reveal blind spots and produce well-evidenced new register entries.
- The full feedback loop of log, link, review, update, improve, and retest makes your register and controls better over time.
Frequently Asked Questions
Should every incident be linked to a risk?
Every significant incident should be. Trivial, low-severity events can be batched and reviewed for trends rather than linked individually. The rule of thumb: if an incident is worth a post-incident review, it is worth linking to a risk.
What if an incident relates to several risks?
Link it to all of them. A single incident, say a major outage caused by a failed change, can simultaneously be evidence for an availability risk, a change-management risk, and a vendor risk. Use a multi-value "Related Risk" field so each affected risk gets the feedback.
How quickly should I update the register after an incident?
Do the linking immediately when the incident is closed, and do the score and control updates as part of the post-incident review, usually within a week or two. The PIR is the natural moment to feed findings back into the register while the detail is fresh.
Does one incident mean I should raise the likelihood score?
Not automatically. A single occurrence is evidence, but it could be a rare tail event. Look at the pattern: if a risk you scored as rare has now happened two or three times, the original estimate was almost certainly too low and should be revised. Use judgement informed by trend data.
How do incidents affect residual risk specifically?
Residual risk is the risk left after controls. When an incident shows a control failed or was missing, your controls are weaker than assumed, so your real residual risk is higher than the register states. Update the residual score, add a remediation action, and re-review once the control is strengthened. See inherent vs residual risk for the full distinction.
Who owns this feedback loop, risk or operations?
It is shared, but someone has to be accountable for the hand-off. Typically operations owns logging and resolving the incident, and the risk function owns translating the findings into register updates. The post-incident review is the meeting where both sides come together, which is why a risk representative should attend reviews of major incidents.
Save this guide for later
Download the PDF version to read offline or share with your team.
