Every organization that manages risk has a register. Most of them are dead.
You know the type: created with great energy during an audit push or a consulting engagement, lovingly detailed, formatted in corporate colors — and last modified fourteen months ago. It describes the fears of a company that no longer exists, owned by people who have partly moved on, with treatment columns full of measures nobody implemented.
A dead register is worse than none, because it creates the feeling of control without the substance. This article is about building the other kind: a register that people actually open, update, and argue about — the single source of truth for what could hurt your organization and what you're doing about it.
What a register is for
Strip away the formality and a risk register answers five questions for anyone who opens it:
What could go wrong? How bad and how likely is each item? Who owns it? What are we doing about it? Is the situation getting better or worse?
Every design decision follows from these questions. Fields that help answer them earn their place. Fields that don't are friction — and friction is what kills registers.
The anatomy of a good entry
Per risk, the core fields that have proven themselves in practice:
A structured description. Not "cyber risk" but cause, event, and consequence in one sentence: "Because deployment lacks automated rollback, a faulty release may take the portal offline for hours, causing SLA penalties and churn." This single discipline — full sentences with causes — does more for register quality than any other rule, because everything downstream (rating, treatment, ownership) depends on knowing what the risk actually is.
A category (strategic, operational, financial, compliance, IT/cyber, people...) so you can slice the picture and spot clusters.
Likelihood and impact ratings on your defined scales — ideally twice: gross (before controls) and net (with current controls). The pair shows what your controls are worth and whether more treatment is needed.
An owner. One name. Not "IT department," not "management" — a person who answers when the risk is discussed and who feels a gentle discomfort when their risk is overdue for review. Risks without owners are orphans, and orphans don't get fed.
Existing controls — what's already in place and operating.
Treatment: strategy, measures, deadlines, status. Avoid, reduce, transfer, or accept, and if action is planned: what, by whom, by when, and how far along.
Review date and history. When was this risk last honestly looked at, and how have its ratings moved over time? The trend line — is this risk migrating toward green or red? — is often more informative than the current position.
That's roughly ten fields. Registers with thirty fields exist, and they are almost always dead, because every additional field taxes every update, and updates are the register's lifeblood.
The failure modes (and their cures)
The 400-row register. Someone decided completeness was the goal, and the register now contains every conceivable inconvenience down to "printer may jam." Nobody can maintain 400 entries, so nobody maintains any. Cure: ruthless consolidation. Merge duplicates, aggregate trivia, park minor items on a watch list. A register of 20–60 well-tended risks beats 400 abandoned ones in every way that matters.
The wish-list treatment column. Measures like "improve security awareness" or "evaluate options" — undated, unowned, unverifiable. Cure: treatments must pass the checkability test: a named person, a date, and a definition of done. If you can't tell whether it happened, it didn't.
The static snapshot. Ratings that never move. Either your ratings are wrong, or nobody's looking — risks are dynamic by nature, and a register where nothing changes for a year is a register measuring nothing. Cure: a review rhythm (below), plus a rule that every rating change carries a one-line justification, making both movement and stillness explainable.
The parallel-universe register. The register says the top risk is supplier concentration; the management meeting discusses everything but. Risk documentation and actual decision-making run in separate worlds. Cure: the register — or its top-ten view — becomes a standing agenda item where decisions actually happen. If leadership doesn't look at it, why would anyone else?
The rhythm that keeps it alive
A living register runs on cadence, not enthusiasm. Enthusiasm fades; calendars don't. The rhythm that works for most organizations:
Quarterly, each risk owner reviews their entries: are the ratings still right, have circumstances changed, are treatments on track? Fifteen minutes per owner if the register is well-sized.
Quarterly, leadership reviews the aggregate: the matrix, the top ten, the movers since last quarter, overdue treatments. One recurring hour.
Annually, everyone does a deeper refresh: a re-identification workshop to catch new risks, retirement of obsolete ones, recalibration of ratings that have drifted.
Continuously, on triggers: every new project, major contract, reorganization, or incident prompts a register check. Incidents especially — an incident is reality grading your register, and every incident that wasn't in the register is a free lesson in what your identification process misses.
Tooling: when the spreadsheet stops scaling
Registers usually begin life as spreadsheets, and for a first pass that's fine. The pain arrives predictably as the process matures: version chaos ("is RiskRegister_final_v7_NEW the current one?"), no change history for auditors, manual chart-building before every meeting, forgotten review dates, and no way for owners to update concurrently.
At that point, dedicated tooling starts paying for itself — not because software manages risk (people do), but because it removes the friction that kills the update habit: automatic matrix visualization, reminder workflows for reviews and overdue treatments, a change log every auditor loves, and one URL that is always the current truth. The cheapest measure of success applies to any tool: do the risk owners open it without being chased?
The register as a mirror
There's a quieter role the register plays. Over time, it becomes a record of organizational honesty — the place where known weaknesses are written down instead of whispered. The single point of failure everyone jokes about, the dependency on one heroic sysadmin, the aging contract nobody wants to renegotiate: once in the register, with an owner and a date, these stop being ambient anxiety and become work.
That transformation — from whispered worry to owned item — is the register's real product. The document is just how you keep score.