The Connected GRC Model: How Risks, Controls, Issues & Incidents Fit Together

Category: Operating Models Tags: integrated risk, GRC, controls, issues, incidents, residual risk, data model

Most GRC programs run four registers that never talk to each other. There's a risk register in one spreadsheet, a control library in another, an issues or findings log in a third, and an incident tracker somewhere in the security team's tooling. Four owners, four formats, four definitions of "high." Each is maintained as if the others don't exist.

They all describe the same reality from different angles. An incident is evidence that a risk is materializing. A control is the thing that's supposed to keep that risk from materializing. An issue is a finding that a control isn't working. When these live in separate silos, your risk ratings become educated guesses, someone's judgment about likelihood and impact, disconnected from the operational evidence sitting two tabs away. Connect them, and the numbers stop being opinions and start being conclusions.

The Four Entities Are One System

Treat risks, controls, issues, and incidents as four entities in one system instead of four programs, and the links between them start doing most of the work.

Incidents → Risks. Every incident linked to a risk is a data point about that risk's likelihood and impact. A risk with five incidents this year is occurring, whatever the register says about it being "possible." The severity of those incidents shows you what the impact looks like when the risk actually lands.

Controls → Risks. The entire purpose of a control is to move a risk from its inherent level to a lower residual level. So residual risk should be a function of the controls linked to it and how effective they are, not a second, independent guess made in the same workshop that produced the inherent score.

Issues → Controls. An issue (an audit finding, an exam observation, a failed certification test) is evidence that a control is weaker than its rating claims. An open finding against a control should reduce the effectiveness you credit it with, which in turn raises the residual risk it was supposed to be holding down.

Read those three together and a chain appears. An incident raises a risk's likelihood, a weak control fails to bring it back down, and the open audit issue that explains why the control is weak sits right there, linked to both.

Why Disconnection Is So Expensive

When the entities are siloed, three things break. First, your risk ratings can't be defended. Ask why a risk is rated the way it is and the answer comes down to "judgment," with no line back to evidence. Second, nothing self-updates. A new incident or a fresh audit finding should move a risk rating automatically; in siloed registers, it moves nothing until a human remembers to re-score. Third, you never get an enterprise view, because each piece is scored in its own terms, the failure I wrote about in integrating risk assessments.

The connected model fixes all three. Because every entity shares IDs and a common scale, ratings trace back to evidence, new evidence moves the numbers, and the rollup happens on its own.

How the Calculation Actually Works

You don't need a platform to do this, just a shared structure and a few deliberate rules. In the version I use, each link sets a default.

Likelihood is suggested from incident count. Zero linked incidents suggests a low likelihood; a steady stream suggests a high one. The analyst can override with judgment, but the default is evidence.

Impact has a floor set by real events. You still score impact across dimensions (financial, operational, reputational, regulatory) using the discipline from the data-driven risk assessment. But the largest linked incident raises the floor: if an event already cost you a 4, the risk's impact is at least a 4, regardless of optimism.

Residual is derived from control effectiveness. Link a risk to the controls that mitigate it, average their effectiveness, and apply a reduction factor to the inherent score. Strong, tested controls earn a large reduction; weak ones earn almost none. The residual number now follows from your control posture.

Issues degrade the controls feeding that calculation. Every open issue linked to a control knocks down the effectiveness credited to it. So an audit finding propagates instead of sitting in a findings log: weaker control, smaller reduction, higher residual risk, automatically. The framework concepts behind the control side of this are covered in the case for a unified control library.

Every one of these is a suggestion the practitioner can override. Judgment stays in the model. What changes is that evidence becomes the default, and any departure from the data has to be made explicitly.

What Changes When It's Connected

The first time leadership sees a risk rating that updates itself when an incident is logged, the conversation changes. Board reporting stops being a quarterly re-litigation of subjective scores and becomes a read on what the evidence is actually saying, the kind of decision-driving reporting I argued for in board risk reporting that actually drives decisions. Audit readiness improves, because every rating has a traceable evidence chain. The resilience program gets sharper too, because incidents stop being logged and closed and start feeding forward into how you understand the risks they came from. It's the same instinct behind treating incident command as the backbone of resilience.

Start With Incidents

You don't have to connect everything at once. Start with the link that has the most evidence sitting unused: incidents to risks. Take your incident log, map each incident to a risk, and look at the count. You'll almost certainly find risks rated "unlikely" that have been happening repeatedly, and risks rated "critical" that haven't materialized once. That single exercise will tell you more about your risk register's accuracy than another scoring workshop ever will.

Then add controls, then issues. Each link you build makes the register more honest, and leaves less of it depending on someone remembering to re-score.