Part II · Chapter 3 · Risk, without the score · lesson 11
A finished register is an inventory of how to hurt you
11 min
Builds on This is a place to think, not a place to keep the only copy
Part II · Chapter 3 · Risk, without the score · lesson 11
11 min
Builds on This is a place to think, not a place to keep the only copy
Look at what you have built over the last ten lessons.
A single document listing every weakness you know about. Each one as a sentence specific enough to act on. Beside each one, how often you think it happens and how bad it would be. Beside that, what you are doing about it — including the rows where the honest answer is nothing — and the name of the person who decided to live with each of those.
There is no other document in your organisation like it, and the places it usually lives are a shared drive, a wiki page, and an attachment on a ticket.
A good register is the thing an attacker spends the first three weeks trying to build.
Reconnaissance is slow. Working out which systems are soft, which processes depend on one person remembering, and which failures nobody would notice for a fortnight takes real effort from outside. Your register answers all three, in priority order, in the defender's own words, with the gaps labelled as gaps.
The second reader is not an attacker. After an incident, an accepted risk with a name and a date is a record that the organisation knew about the weakness and chose to carry it. That document is read by lawyers and regulators rather than by auditors, and it is read for what you knew and when.
Both of those are real costs of having written it well. Neither is a reason not to.
Once somebody in the room notices the what-you-knew-and-when problem, the instinct is to write the register more vaguely. Soften the sentences. Drop the dates. Take the names off the acceptances. Use phishing instead of the sentence about the invoice.
That instinct converts a legal exposure into an operational one. You now hold a register nobody can act on, with no owners and no decisions in it, and you have paid for the change twice: the vagueness does not make the knowledge go away, because the knowledge was in the meeting and the emails, and the register has stopped being the thing that gets the work done.
It is not a trade between risk and safety. It is a trade between two bills, and the vague register gets you both.
Something people say
“A risk register is an internal document, so the team wiki is the right place for it.”
Which split does the most work for the least friction?
Name the readers as a list of people, not a group. A group is a membership you have not looked at. The useful question is not who should have access, it is how many people have it right now — and the number is almost always larger than the answer you would have guessed.
Review that list when the register changes, not annually. The register is edited on the days decisions get made, which is exactly when a reader joined who was not there last quarter.
Keep the register out of the folder you send to buyers. These two documents end up next to each other because both are filed under compliance, and one of them is a list of your weaknesses.
Know where the copies are. A register that has been emailed as a spreadsheet exists in as many places as there were recipients, permanently, including the ones who have left. That is not reversible and the only fix is not doing it again.
Check
The register block in this subject keeps your rows in your own browser, and nothing leaves it unless you are signed in. That is a smaller promise than it sounds, and it is deliberately not the main point.
The main point is that this is somewhere to think. Keep the real one in your own systems, under your own access control, where somebody who audits you can be shown it — because a register that exists only inside a learning tool is a register your organisation does not have.