Every quarter, someone on a leadership team asks a version of the same question: "what's our biggest risk right now?" And every quarter, answering it means opening the risk spreadsheet, pinging whoever owns the incident log, digging up last month's vendor review, and hoping nothing's slipped through in between. That gap, between a simple question and a scavenger hunt for the answer, is the whole reason this project exists.
The problem isn't a lack of data. It's fragmentation. Risk and compliance teams in 2026 are drowning in systems that don't talk to each other: the register lives in one tool, controls testing results sit in a spreadsheet someone emailed last month, audit findings live somewhere else entirely, and cyber risk is tracked by a completely separate team on its own platform. None of that is a data problem. It's a "which of five tabs do I open" problem, and it costs real money and real trust every time a board question takes days instead of minutes to answer.
So I started building a Risk Register that refuses to be one more disconnected spreadsheet. Over the past several months it's grown from a simple taxonomy into something closer to a real GRC platform.
What's built so far
What I got wrong early on
I originally modeled risks as a simple list: one risk, one category, done. It took a real incident that touched three different risk categories at once to make me rebuild the data model around many-to-many relationships instead of a tidy tree. More on that rebuild in a future post, because it broke more than I expected it to.
Where it stands today
What started as a single risk register is now nine connected modules sharing one taxonomy. That's the whole point: not nine separate tools that happen to sit near each other.
Next up
Why a risk taxonomy needs five categories instead of three, and what "admin-configurable and versioned" actually means in practice. If you're building anything in the GRC or internal-tools space, or you've got your own spreadsheet horror story, I'd like to hear it.