Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

07.04 From Incident to Risk and Back

The bidirectional relationship between incidents and risks — risks predict incidents that may materialize, incidents reveal risks that should have been on the register. Here's how SimpleRisk's `incident_management_incident_to_risks` linkage supports the discipline of using both directions.

Why this matters

The relationship between incidents and risks runs in both directions, and a working GRC program uses both. A risk predicts an incident that may materialize: the risk register holds the program's articulated theory of what could go wrong, and when one of those scenarios actually plays out, the materializing incident is the predicted-thing-that-came-true. An incident reveals risks that should have been on the register: the post-incident review surfaces gaps the program didn't realize it had, and the new risks that get added afterward represent the program's revised theory of what could go wrong next.

The trap is treating the two directions as one-way. A program that records incidents but doesn't update the risk register from them learns the same lesson repeatedly — every time the same kind of incident recurs, the response is improvised because the risk wasn't on the register to drive controls. A program that maintains a thorough risk register but doesn't link materializing incidents back to it produces a register that doesn't reflect operational reality. The bidirectional discipline is what keeps the two artifacts coherent.

The other reason this matters: the linkage is the load-bearing piece auditors look for when they evaluate whether the program is operating. A SOC 2 auditor reads the incident log and the risk register together — incidents linked to risks tell a story of "we knew this could happen, here's what we did about it"; incidents not linked to risks raise the question "was this a known exposure or a surprise?" A reviewer can tell the difference between a program that's surprised regularly and one that's surprised rarely; the linkage is part of what shows the difference.

The fourth thing: SimpleRisk implements the linkage through the incident_management_incident_to_risks table, populated through the Related Risks field on the incident form. The link is many-to-many — one incident can relate to several risks, one risk can relate to several incidents. The data model supports the bidirectional reads natively.

How frameworks describe this

Most major frameworks treat the incident-risk relationship as a feedback loop, with the incident-side learning explicitly required to update the risk-side picture.

  • NIST Special Publication 800-61 r2 Computer Security Incident Handling Guide in the Post-Incident Activity phase explicitly mandates "lessons learned" reviews that produce updates to the risk assessment process. The standard's framing: an incident is the empirical evidence that the prior risk theory was incomplete; the response to the incident must include revising the theory.
  • NIST Cybersecurity Framework (CSF) v2.0 under the Recover function (RC.IM-1 and RC.IM-2) requires that recovery activities and strategies are updated based on lessons learned. The Identify function (ID.RA-3, ID.RA-4) requires the risk-assessment process to incorporate threat intelligence and incident data; the loop is explicit.
  • NIST SP 800-53 IR-4(11) (Coordination with Risk Management) is the federal control: "the organization coordinates incident response activities with the risk management process to inform organizational risk decisions and ensure that risk responses are aligned with incident response activities." This is the bidirectional integration in policy form.
  • ISO/IEC 27001 Annex A A.5.27 (Learning from information security incidents) requires that the organization's risk-management process is informed by lessons from incidents. The clause's framing is explicit about the feedback loop into the ISMS's broader risk treatment.
  • PCI DSS v4.0 Requirement 12.10.5 mandates that incident-response procedures include monitoring and assessing risks based on incident learnings.

The takeaway across all five: the bidirectional integration is not optional for serious programs. The frameworks vary on the specific mechanism (some mandate annual risk-assessment updates, some mandate per-incident updates, some mandate both), but the principle is universal — incidents inform risks, risks inform incident preparation.

How SimpleRisk implements this

SimpleRisk's bidirectional integration lives in two surfaces:

The incident-to-risk direction is populated when an incident is recorded or edited. The Associations tab on the Submit An Incident form (and on the incident's detail view for already-recorded incidents) has a Related Risks multi-select widget that links the incident to existing risks in the standard register. The selection writes to the incident_management_incident_to_risks table; the link is then visible on both sides — the incident's detail view shows linked risks in the Associations section, and the risk's view (in the standard risk-register UI) shows the linked incidents under its associated entities.

The two patterns this captures:

  • Risk materialized into incident. The risk was on the register before the incident; the incident is the materialization. Link the incident to the risk; the risk's history now shows that this prediction came true at this date. The risk's residual score may need adjustment downward (the controls didn't hold) or the risk may need re-treatment (the existing mitigation wasn't sufficient).
  • Incident referenced a known risk in scope. The incident affected systems that are subject to known risks even if the materializing risk isn't itself one of them. Link the incident to the in-scope risks for context; this surfaces "this incident touched our PCI-scope systems" or "this incident affected the customer-data warehouse" in cross-cutting reporting.

The post-incident-to-new-risk direction is operational rather than data-modeled. SimpleRisk doesn't auto-create risks from incident lessons — the post-incident review (held during the Lessons Learned phase) is where the program decides whether the incident surfaced new risks that should be added to the register. Adding the new risk happens via the standard Submit Risk flow; once submitted, link the new risk back to the originating incident through the same incident_management_incident_to_risks table for traceability.

The two directions together produce the audit-friendly story:

  • Risk X was on the register since 2025-Q1 with an articulated treatment plan.
  • Incident Y materialized in 2026-Q3, linked to Risk X.
  • The post-incident review found that Risk X's mitigation was insufficient, and surfaced a new Risk Z that hadn't been articulated.
  • Risk X's residual was bumped up; Risk Z was added to the register; Incident Y is linked to both Risk X (the materialization) and Risk Z (the newly-surfaced exposure).

A reviewer reading the audit trail can reconstruct the program's revised theory of risk after the incident; without the linkages, the same audit trail reads as "an incident happened" with no connection to the risk register.

Common pitfalls

A handful of patterns recur with the bidirectional discipline.

  • Incidents recorded with no risk linkage. The most common failure pattern. The team responds to the incident, closes it, and moves on without populating the Related Risks field. The incident is then a closed-system record with no connection to the program's risk picture. The fix is operational: include "link to relevant risks" as a step in the recording workflow, with the Allow Access to "Risk Management" Menu permission required so the recorder can search the register.

  • Linking everything that's vaguely related. The opposite failure: every incident gets linked to twenty risks because "they all kind of relate to security." A risk linked to dozens of incidents stops being meaningful for trend analysis (the cross-incident pattern is buried in noise). Link incidents to the materializing risks and the clearly in-scope risks; resist linking to every risk in the same general topic area.

  • No post-incident risk update. The Lessons Learned phase ends with lessons attached to the incident but no new risks added to the register. The next time the same kind of incident happens, the program is still working from the pre-incident risk theory. The discipline is to ask, in every post-incident review: "What does this incident tell us about risks the register doesn't currently reflect? What should be added or revised?"

  • Treating the linkage as administrative. The linkage isn't paperwork; it's the bridge that makes the two disciplines reinforce each other. A program that treats incident_management_incident_to_risks updates as a checkbox produces a linkage table that's technically populated but operationally useless. The check should be: does reading the risk's incident history tell me something about the risk's residual exposure I didn't already know?

  • Updating the risk register without recording in the audit trail. A residual-risk adjustment after an incident is meaningful only if the audit trail captures why it was adjusted. Use the risk's update mechanism to reflect the change, and reference the originating incident in the change comment ("Bumped residual from Medium to High after Incident IM-2026-Q3-0042 demonstrated existing mitigation was insufficient"). The combination of the audit-log entry and the comment is what makes the change defensible.

  • Auto-creating risks from incidents. Some programs build automation that creates a risk for every closed incident. The result is a risk register full of single-incident artifacts that don't represent ongoing exposures — they represent things that happened once. Risks are about prospective scenarios; incidents are about materialized events. Auto-creating risks-from-incidents conflates the two; the post-incident review's human judgment about whether a new risk is warranted is the value the automation removes.

  • Skipping the linkage on small incidents. A small incident ("misconfigured firewall rule, caught and reverted within an hour") might not seem worth linking to risks. The opposite: small incidents are often the early-warning signal for the bigger incidents the same risk could produce. Linking small incidents to the relevant risks lets the trend analysis surface "this risk has produced 12 small incidents in the past quarter, the residual is too low."

  • Not using the linkage in audit conversations. The bidirectional integration is one of the audit-friendly story elements the program has. A reviewer asked "show me how your incident response feeds back into your risk management" can either gesture at policy or show the data — incident-to-risk links in the database, risks updated after incidents, new risks surfaced from post-incident reviews. The latter is much more compelling. Use the linkage as the demonstration when the audit conversation asks the question.

Related