The Accountability Gap

Risk registers are usually things of beauty.

Colours everywhere. Red for high. Amber for medium. Green for low. Status labels that tell you exactly what is happening to each risk. Residual risk scores that show how much exposure remains after controls are applied. Treatment plans with due dates and owners assigned.

They look impressive. Especially in a board presentation.

But looks can be deceiving.

When I was an auditor, one of my favourite things to do during a risk register review was to ask to speak to the risk owner of a specific risk.

Not the security manager. The actual risk owner. The person whose name was in the spreadsheet.

I would sit down with them and ask a few simple questions. What is this risk? Why does it matter to the business? What are you doing about it? What would happen if it materialised tomorrow?

More often than not, the person would shift nervously in their chair. Their eyes would dart across the room to the security manager, silently pleading for a lifeline.

And the security manager would usually jump in.

Because the risk owner had no idea.

Not because they were incompetent or because they didn't care. But because somewhere along the line, a risk had been identified, probably from a penetration test or an audit finding, and this person had been assigned ownership because they seemed like the most relevant person.

Nobody had ever sat down with them and explored with them what the risk actually was, why it mattered, or what owning it actually meant.

They had a name in a spreadsheet. That's all they had.

Someone cannot own a risk they do not understand.

This sounds obvious when you say it out loud. But it is one of the most common governance failures I have seen across organisations of every size and sector.

The risk register looks healthy. The colours are right. The treatment plans exist. The owners are named.

But the ownership is fictional. It exists on paper and nowhere else.

A lot of this comes down to how risk registers get maintained in practice.

In most organisations, the security GRC team is the engine room of the risk register. They identify risks, they create the entries, they chase engineers and business owners for status updates, they update the colours, they produce the reports.

It looks like risk management. It isn't.

What it actually is, is data janitorial work.

We spend our time chasing people for updates so we can colour in a spreadsheet. We are not managing risk. We are cataloging it. There is a significant difference between the two, and most organisations have quietly drifted from one to the other without noticing.

The risk register becomes a living document that only the security team truly understands, maintained by the security team, reported on by the security team, and quietly owned by the security team in every sense that actually matters.

And that's where the accountability gap opens up.

When the security team is the only function actively engaging with the risk register, the business draws a natural conclusion: security owns the risk.

If something goes wrong, it's a security problem. If a risk materialises, the question goes to the CISO, not to the business unit that was generating the risk in the first place.

This is a catastrophic governance failure. And it happens slowly, quietly, and with the best of intentions.

The security team didn't set out to own all the risk. They were trying to be helpful. They raised the risks because they spotted them. They chased the updates because nobody else was doing it. They kept the register alive because without them it would have died.

But in doing so, they inadvertently absorbed accountability that was never theirs to carry.

In the Three Lines of Defence model, the security team sits in the second line. Their job is to set the standards, measure the risk, and report on it. They are the surveyors, not the builders.

The first line, the business, owns the risk. They generate it through the decisions they make, the systems they run, and the processes they operate. If a business unit deploys a new tool that introduces a vulnerability, that risk belongs to the business unit. The security team's job is to identify it, quantify it, and report on it. Not to own it.

When that distinction collapses, when the security team becomes the de facto owner of risks that belong to the business, the model breaks. The business loses accountability. The security team carries weight it was never designed to carry. And when something goes wrong, nobody is quite sure who was responsible, because everyone was pointing at everyone else.

It starts with how risks get assigned in the first place. A name in a spreadsheet is not ownership. Ownership means the risk owner understands the risk, understands what they are accountable for, and has the authority and the resources to do something about it.

That means the security team's job when a new risk is identified is not just to log it and assign it. It is to sit down with the risk owner, define the risk in business terms, not technical ones, and make sure they can answer the four questions an auditor will eventually ask them.

What is this risk? Why does it matter? What are you doing about it? What happens if it materialises?

If a risk owner cannot answer those questions, they do not own the risk yet. The work is not done.

Here is something worth trying before your next audit.

Pick three risks from your register at random. Not the easy ones. Go and find the named owner of each one and ask them those four questions. No warning. No briefing beforehand.

What you find will tell you everything you need to know about the real state of your risk management programme.

Because the next time an auditor asks to speak to your risk owners, the outcome of that conversation was determined long before the auditor walked in the door.

A risk register full of names is not a risk management programme.

A risk register full of people who can answer those four questions is.