Open the risk register in most engineering organisations and you'll find something like this. A few hundred rows. Titles like "Enable MFA on the admin portal" and "Upgrade OpenSSL on the build agents". A severity column, mostly High. A status column, mostly Done. A handful of rows marked Open whose creation date is well over a year ago. An owner column full of engineers' names.
That isn't a risk register. It's a backlog with a severity column. Nothing is wrong with backlogs, and every security team needs one. The problem is that the organisation believes it has a risk register, auditors were shown it as one, and nobody can answer the question a risk register exists to answer: what risk are we carrying right now, and who decided that was acceptable?
The short version: a backlog tracks work; a risk register tracks exposure and the decisions made about it. If your rows are fixes rather than risks, if "Done" means a ticket closed rather than the risk changed, and if nothing is ever formally accepted, you have a backlog. The fix isn't a new tool. It's writing rows as risk statements, scoring them twice, making acceptance an explicit decision with an approver and a review date, and reviewing the register with people who can actually make that decision.
Two lists that answer different questions
The confusion is understandable: both are lists, both have priorities, both get worked through. But they exist for different readers and finish in different ways.
| Backlog | Risk register | |
|---|---|---|
| Question it answers | What should we work on next? | What exposure are we carrying, and is it acceptable? |
| A row is | A piece of work | Something that could go wrong, and what it would cost |
| A row is finished when | The work is done | Someone with authority decides the remaining risk is acceptable |
| Owner | Whoever does the work | Whoever answers for the consequence |
| Who reads it | The team | The people who set risk appetite: leadership, risk committees, auditors |
| When ignored | Work is late | The organisation is carrying risk nobody agreed to |
A healthy organisation has both, linked together: one risk in the register, several tickets in the backlog that reduce it. The trouble starts when the register collapses into the backlog and only the tickets are left.
Seven signs your risk register is a backlog
1. The rows are fixes, not risks. "Enable MFA on the admin portal" is a control, not a risk. It doesn't say who would attack what, how, or what the business would lose. Without that, there's no way to tell whether MFA is the right fix, whether it's enough, or whether the row can be closed when someone enables MFA but leaves the support tool's shared login untouched. A register of fixes is a list of answers with the questions removed.
2. "Done" means a ticket closed. The status column tracks work, so a row turns green when the ticket does. But completing a mitigation and reducing a risk aren't the same event. The fix may cover one path out of three, or the threat may still be serious at a lower likelihood. A register that closes rows on ticket completion records activity, not exposure, and it slowly fills with green rows that describe risks the organisation still has.
3. Every risk has one score, assigned once. Likelihood and impact were set when the row was created and never touched again. There's no distinction between the risk before controls (inherent) and after them (residual), so the register can't show whether any of the work changed anything. It also can't show drift: a risk scored "low" three years ago, before the service became public-facing, is still "low".
4. Nothing is ever accepted, except by silence. Look for the rows that have been open for a year or more. Each of them is a risk the organisation has, in practice, accepted. Nobody approved it, nobody wrote down why, and nobody set a date to look again. A real register has explicit treatment decisions (reduce it, avoid it, transfer it, or accept it), and an acceptance names who accepted it and when it expires. Our prioritisation guide puts it simply: accepting a risk is a decision, not a silence.
5. The owner is whoever got the ticket. The engineer implementing the fix is an action owner. The risk owner is the person who would have to explain the consequence: the head of payments for fraud on the payout flow, the product owner for a data leak from their feature. When the owner column lists only engineers, nobody with the authority to accept or fund the risk has ever seen it.
6. Only the team reads it. If the register is reviewed in sprint planning and nowhere else, it's being used as a backlog, because that's the question sprint planning asks. Risk decisions need to reach people who can set priorities across teams and decide how much risk the organisation will carry. If no one at that level has looked at it this quarter, it isn't functioning as a register.
7. It only ever grows. Rows refer to services that were decommissioned last year, while the payments integration that shipped last month has no rows at all. That happens when the register isn't connected to the system it describes. Without that link, there's no trigger to add risks when the architecture changes or retire them when it changes again.
How registers turn into backlogs
Nobody sets out to build a backlog and call it a risk register. It happens through a series of reasonable shortcuts.
- The register lives in the issue tracker. Issue trackers model work, so everything put into one becomes work: a title, an assignee, a status that ends in Done.
- Closing items feels like progress. "We closed 40 security items this quarter" is easy to measure and report. "Residual risk on customer data exposure dropped from high to medium" takes judgment, so it gets reported less.
- The audit asked whether a register exists. A first audit often checks that risks are recorded and assigned. Whether the decisions in it are real only comes up later, if at all.
- Scoring happens at intake. Risks get scored when they're found, by the people who found them, and there's no step in the process where they get scored again.
Turning it back into a register
None of this needs a new tool. It needs a few fields to mean something and one meeting to happen.
Write every row as a risk statement. A simple shape works: [a threat actor] could [do something] to [an asset] via [a path], resulting in [a business consequence]. "An external attacker could take over a support agent's account via a phished password on the support tool, which has no MFA, and issue refunds to accounts they control." That row can be scored, owned, discussed with a non-engineer and, importantly, closed for a reason.
Keep the risk and the work separate. One risk, several tickets. The tickets close when the work is done. The risk changes only when someone re-scores it. This single change stops most of the drift, because a ticket closing becomes a prompt to re-assess rather than an automatic tick.
Score twice. Record the inherent score and the residual score after controls. The gap between them is the evidence that the work mattered. A residual score that's still high after every ticket closed is the most useful thing a register can show you, and a backlog can never show it. Score in context rather than copying a vulnerability's base score; our CVSS post explains why.
Make treatment an explicit decision. Every risk gets one of four treatments: reduce, avoid, transfer or accept. An acceptance records who approved it, why, and when it will be reviewed. ISO 27001 builds this in: clause 6.1.3 expects risk owners to approve the treatment plan and accept the residual risk. If the treatment relies on something other than the obvious fix, document it with the same discipline as a compensating control.
Name the risk owner, not just the assignee. Each row needs the person accountable for the consequence, as well as the people doing the work. If no one is willing to be named, that says more about the organisation's risk appetite than anything else in the register.
Review it where decisions get made. A short quarterly review with someone who can accept risk is enough. Three questions cover most of it: what's changed since last time, which acceptances are expiring, and which residual risks are above what we've said we're willing to carry?
Tie every row to the system. Link each risk to the part of the architecture it lives in, ideally a component or flow in the threat model. When that part of the system changes, its risks get reviewed. This is what keeps the register current without a heroic annual clean-up, and it's the same principle behind our re-threat-modeling triggers.
One row, before and after
| Field | Backlog row | Register row |
|---|---|---|
| Title | Enable MFA on support tool | Attacker phishes a support agent and issues refunds to accounts they control |
| Score | High | Inherent 4 × 5 = 20; residual 2 × 4 = 8 after MFA and a refund approval limit |
| Treatment | (none) | Reduce: MFA, refund cap per agent per day, second approval above the cap |
| Owner | A platform engineer | Risk: head of customer operations. Actions: platform and support tooling teams |
| Status | Done | Residual accepted by the risk owner, review in six months or when the support tool changes |
The backlog row is finished. The register row says what's left, who agreed to it, and when it gets looked at again, which is the information an auditor, an incident review or a new security lead will actually need.
A five-minute test
Pick three rows from your register at random and try to answer these for each one:
- What could go wrong, and what would it cost the business?
- What's the risk now, after everything that's been done?
- Which treatment was chosen, and who decided?
- If it's been accepted, when does that acceptance get reviewed?
- Which part of the system does it belong to, and is that part still the same?
If you can answer all five for all three rows, you have a risk register. If you can only answer "who's working on it" and "is it done", you have a backlog, and somewhere above it there's a list of risks your organisation is carrying without having agreed to any of them.
For the fields a register needs from the start, see what a risk register is, or download the free risk register template, which includes a control owner and a last-reviewed date for every row. If your register also has to satisfy an auditor, see why your risk register needs to speak ISO 27001.