Why the Risk Register Is Still a Spreadsheet

The last few GRC Engineering panels I've sat on, every demo follows the same shape. Controls in code. Evidence in pipelines. Frameworks in version control. CI/CD pushing the whole thing into the platform on every merge. It's good work, and I'll defend it on any stage.

But I keep noticing what doesn't get demoed.

The risk register. The thing every one of those controls is supposed to be protecting against. The score that decides which findings get escalated, which gaps get budget, which programs the board actually pays attention to. We're engineering everything around it, and leaving it alone in the middle.

That bothers me. Coming out of offensive security, the whole point of touching a control was to understand what risk it was actually keeping pressure on. If the control degrades and the risk score doesn't move, you don't have a risk program. You have a museum.

How Risk Got Left Behind

GRC didn't decide to ignore risk. Risk scoring just never got the same upgrade that controls and evidence collection did.

Inherent likelihood and impact get scored in a workshop. Residual gets a manual adjustment after a control review. The register sits in a spreadsheet, or in a GRC module that behaves like one, until somebody opens it for the next cycle. That worked when control testing was annual and the business changed slowly enough for last quarter's score to still mean something.

Three things broke that model, and they broke at the same time.

Control effectiveness stopped being a yearly fact. Modern programs test continuously, and a control that's healthy on Monday can drift by Friday because an IAM policy got loosened, a logging pipeline went silent, or a new region came online without the same baseline. The control side of the program has a real-time pulse. The risk side is still taking attendance once a quarter.

Threat and vulnerability data moved into its own stack. Qualys, Wiz, CrowdStrike, and a dozen others produce live signal about what's exposed and what's being targeted. That signal lands in the security team's queue and stops there. The risk register, sitting one floor over in the GRC tool, never sees it.

Programs got bigger. More entities, more frameworks, more geographies, more controls per risk and more risks per control. The mapping a risk manager could once hold in their head is now a graph that needs software to evaluate.

What you're left with is a risk score that's correct on the day it was last touched, and a little less useful every day after.

What Risk Engineering Actually Requires

Here's what bothers me about most of the "risk engineering" conversations I hear: they describe the spreadsheet getting a better UI. They don't describe the score behaving like an engineered output.

If you want risk to be engineered the same way controls now are, three things have to be true. None of them are optional.

• Risks are declared in code. Versioned in Git, reviewable through pull requests, deployable through pipelines. A risk register that lives in a UI and gets edited by whoever has the login is a notebook, not a register.
• Residual scores are computed, not entered. They are outputs of live inputs: the current effectiveness of each mitigating control, the freshness of the evidence behind those controls, the state of the threat surface they cover. Anything a human types directly into a residual field is a number that goes stale the second they hit save.
• The inputs that move the score flow in continuously from the systems where the truth lives. Cloud config, identity providers, vulnerability scanners, ticketing, code repos, HR. If the platform can't reach the source, the score can't move.

Two out of three is a static register with extra steps.

{{ banner-image }}

What This Looks Like in Practice

At Anecdotes, risks are a first-class resource in the Terraform Provider, declared alongside frameworks, controls, and requirements. Each risk carries its name, owners, treatment strategy, inherent likelihood, inherent impact, and one or more mitigation_control blocks. Each mitigation_control block links the risk to a specific control and carries two weights: how much that control reduces likelihood, and how much it reduces impact. All of it lives in Git, and the history of every score change carries an author, a timestamp, a reviewer, and a reason.

Control status is the piece that makes the score move on its own. Status isn't declared, the platform computes it from the evidence linked to the requirements the control depends on. When the evidence weakens, the requirement weakens. When enough of a control's requirements weaken, the control's status changes. Because the risk has already declared that control as a mitigation with explicit weights, the residual score recalculates the same day the control moves. Not the next review. Not when somebody finally opens the register.

The third piece is the data layer. The Plugin Library reaches across 230+ sources, covering cloud, identity, vulnerability management, ticketing, code, and HR. Anything those plugins emit becomes evidence on a requirement. Anything wired to a requirement contributes, indirectly, to the residual score of every risk that depends on the controls above it. That's the part most risk registers have never had access to, and it's the difference between a number that means something and a number that doesn't.

In one sentence: if a vulnerability scanner flags a critical finding on an in-scope asset today, the residual score of every risk that finding touches moves today.

What the Job Looks Like When the Score Moves

I get a version of the same question from every risk manager I talk to: "What am I supposed to do if the system is already calculating the score for me?"

The honest answer is, the job gets better.

Risk reviews stop being a quarterly archaeology project, because the score is already current when the meeting starts. The register stops being a deliverable and starts being a product surface, reviewed and versioned and tested with the same rigor as controls. The risk manager's day moves from maintaining the register to setting the rules behind it: which controls mitigate which risks, what weights are defensible, what evidence sources are authoritative, when a score change should trigger an alert, and when it should trigger a treatment review.

The board, the auditor, and the operator end up looking at the same view at the same time. The argument moves from "is this number current" to "is the weighting right." Risk managers have always wanted to spend their time on the second question. Most of them never get to.

Closing the Loop

GRC Engineering as a movement has done the harder half of the work first. Controls in code, evidence in pipelines, frameworks in version control. That was the prerequisite. None of it was the point.

The point was always to make risk behave like a live signal. The pieces to do that are here now: declarative risks, computed residuals, and a data layer that reaches every system where the truth actually lives. Risk engineering didn't get skipped because nobody cared about risk. It got skipped because the data layer underneath it wasn't ready. Now it is.

‍