Open your cloud risk register and look at the last-modified dates. If they cluster in the fortnight before an audit or a board meeting, you do not have a risk register — you have an audit deliverable shaped like one.
This is close to universal, and it is not a discipline failure. It is what happens when an artefact has no reader.
The problem: a document with no audience
A risk register is supposed to inform decisions. In practice most are written to demonstrate that risks were identified, which is a different job with a different customer — the auditor, not the organisation.
You can tell which one you have by asking a simple question: when did a decision last change because of something in the register? If nobody can produce an example, the register is documentation rather than a control, and the effort going into it is being spent on the wrong thing.
The cloud makes this worse, not better. Environments change weekly, new services appear in your subscription without a procurement cycle, and cost and security decisions are made by the same teams in the same sprint. A register updated annually was already a poor fit for a datacentre. Against a cloud estate it is describing a system that no longer exists.
What actually goes wrong
Risks with no owner belong to nobody. "Security" or "Platform Team" is not an owner. If the entry does not name a person who can be asked about it, the risk has been recorded rather than assigned, and recording is not a mitigation.
Annual review reconfirms everything by default. A meeting that walks a long list will approve almost all of it, because disagreeing with an entry requires having re-read it and having an alternative. The review produces a date stamp, not a decision.
Accepted risk is accepted verbally and never bounded. Someone senior says "we'll live with that for now." Everyone remembers the decision and nobody records who made it, on what basis, or until when. Two years later the acceptance is load-bearing and unattributable — and the person who made it has usually moved on.
A security-only register gets read by security only. This is the deepest problem and the least discussed. If the register contains nothing about cost, resilience or operational fragility, then the people who make delivery decisions have no reason to open it, and your security risks sit in a document their audience never reads.
Nothing is ever removed. Registers grow monotonically. Risks that were mitigated years ago stay, because deleting a row feels like losing evidence. Eventually the length of the document is itself the reason nobody reads it.
What to do
1. Give every risk a named person
Not a team, not a function. A person who can be asked "what is happening with this?" and can answer without convening anyone.
The immediate effect of doing this is instructive: a meaningful number of entries turn out to have no plausible owner, which usually means they are not risks anyone intends to act on. Those should be accepted explicitly or removed, not left in place as an implied intention.
2. Make the review date expire, not recur
This is the single highest-value change and it is a mechanical one.
An entry with a review date that lapses shows up as overdue and forces a decision — renew, mitigate, or accept and close. An entry that appears on an annual agenda is nodded through. Same information, opposite outcome, because one requires action to persist and the other requires action to change.
3. Record acceptance as a first-class object
When a risk is accepted, capture four things: who accepted it, what they knew, on what basis, and until when.
The expiry is what makes acceptance honest. "Accepted" without a date is indistinguishable from "ignored", and the difference matters enormously the day something goes wrong and someone reasonably asks whether this was a known trade-off or an oversight.
4. Cover cost and operations, not just security
This is what determines whether the register is opened between audits.
Cloud cost risk, single-region dependencies, services with no runbook, platform components with one person who understands them — these belong in the same register as your security risks, because they compete for the same engineering time and are decided by the same people.
A register that helps a delivery lead argue for capacity is a register a delivery lead will read. And once they are reading it, your security entries get read too. That is the actual mechanism by which the security content gets attention: not by being urgent, but by being in a document that already has an audience.
5. Review it in a forum that already exists
Do not create a risk forum. Attach the review to your existing architecture or operations meeting, and keep it to the entries that changed or expired.
A standing five-minute item in a meeting that already happens will outlast any dedicated governance body, because it does not depend on someone continuing to organise it.
6. Delete aggressively
A mitigated risk should leave the register. Keep the record for evidence if you must, but do not carry it in the working document.
The register's value is inversely proportional to its length, past a point. Nobody reads eighty rows. Everyone reads twelve.
The test
You will know the register works when someone outside security cites it in an argument they are having about something else — a delivery date, a budget, an architecture decision.
Until that happens, it is an artefact, and the honest thing to do is either make it useful or stop pretending the annual update is a control.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.