The risk nobody owns is the risk that waits.

An issue can have a ticket, a meeting, and six people following up on it, and still have nobody responsible for getting it resolved.

This is the kind of problem I want security leaders to pay attention to. The technical finding may be well understood. People may agree that it needs fixing. Yet the next meeting produces another update, another dependency, and no decision.

Meanwhile, the exposure stays open. The work of keeping it alive falls to whoever keeps asking.

Everyone can have a reasonable answer

Consider a hypothetical integration that can read more client information than it needs. The identity team can reduce its permissions, but the application team needs to confirm that the change will not break the workflow. Operations needs a workable release window. The business needs the service to remain available.

Security can explain the exposure and help verify the fix. It cannot, by itself, reorganize everyone else’s priorities or decide how much disruption the business should accept.

Each team has a legitimate responsibility. The risk sits across all of them.

That is where a ticket assigned to one team can become misleading. We have named someone to perform a task. We may still have nobody accountable for bringing the whole decision together.

Who can actually decide?

The person writing the fix, the person coordinating the work, and the person authorized to accept the remaining risk may be different people. We should be clear about that.

I want someone who can answer a fairly ordinary question: “What is happening next, and who is making sure it happens?”

That person needs enough authority to bring the right teams together, obtain a decision on competing priorities, and escalate a constraint they cannot resolve. They also need access to the people who can make the business decision. Giving someone the label of owner without those things leaves them chasing updates with a new title.

For the integration example, the work might be led by the owner of the affected service, with delivery responsibilities agreed across application, identity, and operations teams. If immediate remediation is impractical, the person with the appropriate risk authority needs to decide whether the interim position is acceptable, with the relevant evidence in front of them.

The exact arrangement will depend on the organization. What matters is that the responsibilities connect. Nobody should have to guess who is allowed to move the issue forward.

If nobody can decide what happens next, the risk is being accepted by delay.

“In progress” needs a little more explanation

A difficult fix can take time. I do not think every delay is a failure of commitment. Sometimes a team needs a supplier’s help, a release needs careful testing, or the proposed change creates a real service risk.

Those are useful facts. “In progress” hides them.

I would rather hear: “The application owner is waiting for a test environment. We can complete validation by Thursday if that capacity is available. Until then, this access remains open, and this is the interim control we have agreed.”

That gives a leader something to do. It explains the constraint, the exposure, and the decision that could change the situation.

Escalation should carry that information. Put the options and their consequences in front of someone who can choose. If the only outcome is that a more senior person starts asking the same questions, we have moved the conversation without resolving the problem.

The process should survive someone going on holiday

I also worry about work that moves only because one person remembers its history and keeps pushing it along. That person may be doing an excellent job. The organization should still be able to continue when they are unavailable.

Record the decision, the next action, the owner, and the point at which it needs to be revisited. Keep enough context that another person can pick it up. If several risks keep stalling on the same dependency, address that dependency rather than ask every individual owner to fight through it again.

Clear accountability should make it easier for people to act and easier for leaders to see where help is needed. It should not turn a difficult problem into a search for someone to blame.

My test is simple: if I came back to this issue next week, could someone tell me what changed, what is still blocking it, and who can make the next decision?

If we cannot answer that, ownership is one of the things we still need to fix.