Your Risk Register Has 200 Risks. Security Owns 180. That’s the Problem.

Finding a risk and owning the decision about it are different jobs. When one team holds both, the register fills with risks that nobody with authority has ever been asked to decide.

Someone opens a risk register with 200 items in it.

Security owns 180 of them.

On paper, that looks like accountability. Every row has a name next to it. Nothing is unassigned.

In reality, almost none of those 180 people can approve the money, authorize the downtime, direct another department's resources, or accept the business exposure. They can describe the risk beautifully. They cannot decide what happens to it.

That is the contradiction at the center of a lot of risk registers. The names are filled in, and the decisions still aren't being made.

Every Row Has a Name. That's Not the Same as an Owner.

This usually happens for an understandable reason. Security maintains the register. Security runs the scans, sits in on the audits, and does the vendor reviews. When a new item goes in, the easiest name to put beside it is the one already doing the typing.

It looks harmless at first. Then a few things start to happen.

The business owners of those systems never realize they're responsible for anything. Remediation requests go out and compete with everyone's normal work, and nobody with real authority has to say yes or no. Security ends up chasing people for updates it has no power to require.

Then leadership looks at the register, sees a huge number of open risks under security's name, and concludes that security is behind.

It isn't behind. The decisions just aren't reaching the people who are supposed to make them.

The Question That Sorts It Out

ISO 27001 and its related standards use the term risk owner for the person with the accountability and authority to manage a risk. The word that matters is authority. An owner has to be someone who can actually decide what happens, which usually means someone who controls the system or the budget involved.

So here is the test I like:

Who can say yes to the money, the downtime, or the exposure?

Whoever that is, that's probably your risk owner. For most business systems, that person doesn't work in security.

Finding the risk does not make you the owner of the risk. It makes you the person who found it.

Four Jobs That Get Squeezed Into One Column

Part of the problem is that one column is being asked to answer four different questions.

• Risk identification: who found and described the risk. Security, internal audit, an outside assessor, IT operations, or even a vendor warning you about a problem on their side.
• Risk ownership: who is accountable for deciding how the risk gets treated. Reduce it, transfer it, avoid it, or accept it for now.
• Remediation ownership: who actually does the work. Patching a server, changing a configuration, renegotiating a contract. Often IT or an application team, and often not the same person as the risk owner.
• Acceptance authority: who is allowed to formally accept the risk at a given level. Many organizations tie this to severity in the risk policy, so a department manager might accept a low risk while a high one needs a senior executive.

On a small risk, one person might wear several of those hats, and that's fine. The point is to write down who's who, so nobody is guessing when a decision comes due.

What it looks like with a real system

Say a vulnerability assessment finds that an internal application the finance team depends on is running on an operating system that no longer receives security updates from its vendor. A newer version is supported, but the upgrade costs real money, needs weeks of testing, and finance does not want that disruption anywhere near month-end close.

Security's part is real. They identify the issue, work out how exposed the system actually is, and explain what could happen in plain business language. They lay out the options: upgrade now, isolate the system and tighten who can reach it while the upgrade is planned, accept the risk for a defined period, or start planning to replace the application.

But security should not be making that call for the finance leader. The finance leader who owns the application is far better positioned to weigh month-end close against the cost of the upgrade. That's the risk owner.

The infrastructure team, working with the application vendor, might be the remediation owner.

And if the finance leader wants to leave the system alone for another six months, the policy might say a risk at that level needs sign-off from someone higher up, perhaps the CIO or the CFO. That's acceptance authority.

One finding. Four different roles. Possibly four different people.

Back to the 180

Now picture that same logic applied across a register where security owns 180 of 200 entries.

Some of those risks need budget. Some need engineering work scheduled against a roadmap. Some need a system taken offline, with a business process interrupted along with it. Some need a leader to look at an exposure and say, on the record, "we are going to live with this for now."

Security can't authorize any of that on its own. So the risks wait. The notes in the register get longer. The oldest items start to read "following up with the app team," and they keep reading that way for a very long time.

I see this pattern when I look at a risk register for the first time. The owner column is full of security names, and the aging items all have the same follow-up note. When we started asking who could actually approve the money or the downtime to fix each one, the answer usually wasn't someone in security.

So we walked the list with the business and system owners and put each risk in front of the person who could make the call. What stood out was how quickly some items moved once the right person saw them. A few got funded. A few were formally accepted by someone with the authority to accept them. A couple turned out to involve systems that were already scheduled for retirement, which security could never have known from the scan results.

That's the quiet benefit of real ownership. The person closest to the business decision often has information that changes the answer.

This Is Not Security Handing Off the Work

None of this means security's job ends once a risk is logged. Assigning accountability correctly is not the same as walking away. The facilitation work is where good security teams earn their credibility.

Security still has to:

• rate risks consistently, so "high" means the same thing everywhere in the register
• explain each risk in terms the owner can act on
• maintain the register, track dates, and follow up
• raise it when a date slips
• verify that remediation actually happened

That last one matters more than it sounds. If the infrastructure team says the system is now isolated, someone should confirm it.

And sometimes security owns a risk outright. If the risk lives in a security tool or a security process, security owns that system, and its name belongs in the column. The goal is not to push names out of security's column. The goal is to put each name where it's actually true.

When a Vendor Calls and Nobody Is Sure Yet

Ownership gets very visible when a real decision has to be made with incomplete information. Here's a hypothetical built on a common risk scenario.

Your biggest data vendor calls. They think, but aren't fully sure, that some of your data was exposed in a breach on their side.

Security has plenty to do in the next hour. Contain whatever is within your control. Tighten monitoring on anything connected to that vendor. Work out what is confirmed and what is still only suspected. Don't wait on the vendor's timeline for the parts of the response that are yours to run.

But notice what comes next. Someone has to decide whether to terminate the relationship, invoke your contractual rights and stay engaged, or choose something in between. That decision depends on how critical and replaceable the vendor is, what's actually confirmed, and what your contract and your own legal obligations already require.

Terminating can create an availability problem on top of the confidentiality problem you already have, without necessarily reducing your risk. That is a business consequence, and the person who has to live with it is rarely the analyst who took the call.

Security can analyze the issue and recommend a path. It does not automatically follow that security has the authority to end a vendor relationship or to accept the consequences of keeping it.

The four responses still need someone to choose

The standard risk responses make the same point.

• Mitigation: invoke the contract, run a joint investigation, reduce the risk while keeping the relationship.
• Avoidance: terminate and end your reliance on the vendor going forward. It doesn't undo a breach that has already happened.
• Transfer: cyber insurance can shift some of the financial impact. It doesn't transfer your regulatory obligations or your accountability.
• Acceptance: consciously deciding the cost of a control isn't justified by the risk. A poor fit for a live, confirmed breach, but often a deliberate and correct call for a lower-tier vendor.

Security can recommend any of these. Somebody with the appropriate authority still has to pick one.

Open the Owner Column

If you work with a risk register, whether in GRC, security engineering, or leadership, open it this week and look only at the owner column.

For each name, ask one thing: can this person approve the money, authorize the downtime, direct the resources, or accept the exposure?

If they can't, you may not have a risk owner. You may just have the name of the person who found the problem.

So which risk in your register has been sitting under the wrong name the longest?

I walk through risk ownership and response decisions in a CISSP-style vendor-breach reasoning exercise in the companion video: watch it here. You can also find free guides, articles, and resources at professorsimon.com/links.