⚙️ Your Risk Register Was Accurate Once... But It Was a Long Time Ago

A few years ago the head of data signed a risk acceptance for an internal reporting tool, and the security lead countersigned. The tool had eleven users and read from one warehouse table.

Since then the tool gained a login page for a partner team, and the head of data has left. The row in the register still says "Accepted", with both signatures under it and a review stamp from this April.

I have helped build a register like the one that row sits in. At one company it took months. Every owner gave a risk interview, and each top-tier risk was fine-tuned, then the second tier under it. When it was done, every row was current.

Before long, product security had started a register of its own, because it needed fresher data on its domain, and security operations did the same. The big one was too complex for leadership to steer with and too high-level for the owners to act on, so neither used it as an input. I was the one person who knew what each row meant, and it still took a nontrivial share of my time to maintain rows that nobody read.

Every row in a register is a photograph of its inputs on one date, and nothing in the row says which of those inputs has moved since. I wrote about one artefact rotting this way, the PR approval.

What a ruling reads from

A risk acceptance or a standing exception rests on inputs that were checked once. The inputs move at three speeds.

The fast inputs describe the subject as it is now: what the system is, who can reach it, what it is built from, and which named controls stand in front of it. The threat picture belongs here too. Any of these can change within a fortnight.

The slow inputs stay true for months or years: the impact the ruling was sized against, the test that showed a control working, the attestation, and the signed reading of what the requirement means.

The event-only class has no schedule at all. The person who decided and the person who accepted must still hold that authority. The leaver is the commonest way a ruling dies, and no calendar catches it.

The chart lays out the seven inputs behind one ruling, grouped by speed, with the annual review at the far end.

Red-edged inputs expire within weeks, gold within a quarter, brown within a year or two. The dashed node changes on an event and has no window. The dotted lines show what has already expired by the time the review reads the row.

Why the register goes stale, and why nobody sees it

A ruling is only as fresh as its fastest input. If the acceptance rests on who has access, its first input can expire before the first weekly sync, while the review is fifty weeks away. A ruling that rests on the signed reading of a requirement stays true for a year or more. Nothing in the register marks which rows are which.

The review runs on a calendar. Annual is the default because the audit is annual. A quarterly recertification, where a program has one, is still slow against an input that moves daily.

A stale ruling raises no error. GRC finds its errors during the audit, and a ruling between audits keeps answering, so the board slide and the appetite statement repeat it with no date attached. The register cannot say how old any of its answers is.

The direction of the error is also unknown. A stale ruling can be over-cautious as easily as dangerous, with a control guarding a risk that has died as the mild case, and both are waste because the program cannot tell them apart.

Comprehensiveness makes it worse. The register I described spanned so many domains that tracking what had changed in each was close to impossible, and every domain a row touches is another input on its own clock. It was too complex for leadership and too high-level for the owners, so a stale row waited for the maintainer to find it.

The second chart sketches what the fastest inputs do to a whole register across a year, one marker per point.

The percentages are schematic. No register was measured to draw them.

Expiry as a field

A certificate carries its own end date. RFC 5280 defines a validity field with two parts, notBefore and notAfter, and one past its notAfter fails without anyone deciding that it should. One that arrives without the field is rejected as malformed.

GRC's default runs the other way: a ruling is valid until someone remembers it.

Contracts rest on old inputs too and stay in force, so the idea that old inputs spoil a ruling seems to prove too much. A contract states its term, so everyone knows the day its obligations end, whatever happened to the inputs. A risk acceptance has no such day.

What "High" cannot do

A ruling scored "High" cannot be seen to expire, because nothing in the word "High" carries a date. The severity is all that remains of the inputs it was built from.

A ruling written as a range with dated assumptions can expire, because each one names an input and the day it was last checked; the range only states what they add up to. Two rulings on the same system:

# Ruling A, as most registers hold it
risk: internal reporting tool
severity: High
accepted: 2024-04
reviewed: 2026-04
---
# Ruling B, the same acceptance, had it been rewritten in June 2026 with dated assumptions
risk: internal reporting tool, partner access
range: "twototwentyrecordsexposedperincident,onetofourincidentsayear"
assumptions:
  - assumes: only the data team and the partner team can log in
    confirmed: 2026-06-14
    invalidated_by: a login granted to any third group
  - assumes: no route from the partner login to the warehouse credentials
    confirmed: 2026-06-14
    invalidated_by: any new connector or shared secret on the host
  - assumes: both signers still hold the seats they signed from
    confirmed: 2026-06-14
    invalidated_by: a leaver or a reorg on either team

Today, ruling A looks as it did in 2024 plus one review stamp that names no input. Had ruling B been written in June, it would carry three assumptions a reader can check, two against the system and one against the org chart. The third would already be false: the head of data left in July.

Three properties make this usable in a program that monitors nothing yet. It is reversible: write it on one row, and if it earns nothing you stop. It is adoptable one ruling at a time, without a migration or a new tool. It has no model underneath, only a date and a sentence, and Monte Carlo can wait until you hold a record of past forecasts scored against outcomes.

That last point holds even if you reject risk quantification entirely. Keep the severity label and add assumptions of that shape under it. Dating an assumption is not quantification. A date field goes stale too, and the reader can tell by how much.

Count the rows you cannot date

Take the ten oldest standing acceptances or exceptions in your register. For each one, write the single input that would have to still be true for the ruling to hold, and the date that input was last confirmed with evidence. A date you can write from memory does not count.

A free-text row with no dateable input goes down as cannot date. That row is the finding, by the same rule the five metrics apply to an unknown value; the exercise has not failed. I never ran this on the register I built, and I would rather have had that count than the maintenance.

Write the count, with today's date, at the top of the register where the annual review starts, and run it again next quarter. Two counts make a trend, and the date on the first tells the next reader its age.

The structural fix is an expiry on every ruling, the field the waivers in the debugger issue lacked, plus a trigger that fires when an input changes. Most programs cannot run that on every row yet, and the rows you cannot date are the ones with no input to hang a trigger on.

Try this week

• Date the ten oldest rulings: one input each, last confirmed with evidence, or cannot date.

• Write the count and today's date at the top of the register, so next quarter has something to compare against.