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

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

Walk into most GRC programs and you'll find 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.

Here's the problem: they're all describing 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

The mental model that changes everything is to stop treating risks, controls, issues, and incidents as four programs and start treating them as four entities in one system, linked by their relationships:

Incidents → Risks. Every incident linked to a risk is a data point about that risk's likelihood and impact. If a risk has had five incidents this year, it is not "possible" — it is occurring. And the severity of those incidents tells you what the impact actually looks like when the risk lands, not what you guessed it might be in a workshop.

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 that control's effective effectiveness, 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 explaining why the control is weak is right there, linked, explaining the whole picture. That's not four registers. That's one connected model.

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 honest answer is "judgment" — there's 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, the enterprise picture never assembles, because the pieces don't share a language — the exact failure I wrote about in integrating risk assessments.

The connected model fixes all three. Ratings trace to evidence. New evidence updates the numbers. And because every entity shares IDs and a common scale, the rollup is automatic.

How the Calculation Actually Works

You don't need a platform to do this — you need a shared structure and a few deliberate rules. The version I use works like this:

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 is now a consequence of your control posture, not a hopeful guess.

Issues degrade the controls feeding that calculation. Every open issue linked to a control knocks down its effective effectiveness. So an audit finding doesn't just sit in a findings log — it propagates: 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. The point isn't to remove judgment — it's to make evidence the default and force judgment to be explicit when it departs from the data.

What This Unlocks

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. And the resilience program gets sharper, because incidents are no longer just logged and closed — they feed forward into how you understand the risks they came from, which is the same instinct behind treating incident command as the backbone of resilience.

Where to Start

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 model more honest and more self-maintaining. The destination is a program where your risk numbers are conclusions drawn from evidence — not opinions waiting to be challenged.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.