Where Risk Reduction Stalls Between the Finding and the Fix
Ask a security leader whether their team can reduce risk and you will get a yes, with an example attached: the critical vulnerability patched inside a day, the exposed bucket closed before anyone outside the team knew it was open.
Now ask the narrower version. Does that happen every month, for findings nobody escalated, on systems nobody has a personal stake in? The answer gets qualified. That hesitation is not describing a team that lacks skill or tooling. It is describing a team whose best outcomes depend on conditions that do not reliably repeat.
The usual reading is that this is a visibility problem, which is convenient, because visibility is the easiest thing to buy. But most organizations already see more than they can act on. What breaks happens after the finding exists, in the space between knowing and fixing, where the work changes hands. It is an execution problem, and it concentrates in five specific places.
Why Individual Wins Do Not Add Up to a Model
A single successful remediation is a project. A program is something else: the same outcome produced repeatedly by a process that does not depend on who noticed, who escalated, or how much press the vulnerability got that week.
That consistency is far from universal. A 2026 survey found that 43% of security leaders described their internal exposure-management processes as inconsistent or ad hoc. The difference between a process that works sometimes and one that works consistently often comes down to what had to happen around the process to produce the win.
Take a win apart and the anatomy is usually the same. Someone senior enough to be listened to saw it early, had standing with the team that owned the asset, and stayed on it until it was verified rather than assumed. None of that is in a runbook. It is a set of conditions that happened to coincide, which makes the win evidence of capability, not of a model.
The better test is the finding nobody remembers. Two exposures of the same severity, raised the same week: one closes in four days, the other is still open ninety days later, and the difference is not complexity and not engineering capacity. It is that somebody happened to see the first one and carry it. That spread is the real output of the program.
Which changes the question worth asking. Not whether the team can fix things quickly, because it can. How much of the outcome depends on who is in the room.
A useful diagnostic: pull a finding from ninety days ago that nobody escalated and trace what actually happened to it. If the honest answer involves the phrase "it is still in the queue," the gap is not capability. It is the model.
The Five Most Common Breakdowns
Follow a finding from the moment it is identified to the moment risk reduction is confirmed, and five recurring breakdowns emerge. Some happen within the work itself. Others happen between teams, when a decision, its context, or its ownership has to survive a handoff.
Discovery can work, prioritization can work, and remediation can work. Yet the finding can still stall between them. The five breakdowns below follow that path in order, showing where otherwise capable programs most often lose consistency.
Breakdown One: Every Team Prioritizes Differently
Prioritization is where most programs believe they are strongest, because almost everyone has a scoring method. The problem is not that scoring is missing. It is that most organizations are running several at once, and nobody has reconciled them.
- Security scores exposure by severity, exploitability, and reachability from the internet.
- Infrastructure scores the same finding by blast radius and change risk, how many systems shake if this host gets touched during business hours.
- Application teams score it by sprint cost and regression risk.
- Cloud teams score it by whether the fix means changing a shared module that forty services inherit.
- Governance scores it by control mapping and audit exposure.
Every one of those is a defensible view, but none of them is the same view.
The consequence is that one finding collects five different verdicts, and none of them is wrong from where that team is sitting. A finding rated critical by security and low priority by the team that owns the asset does not get resolved by argument. It gets resolved by whoever is more persistent, which is not a model but a personality dependency, and it leaves when that person does.
The deeper issue is that these scores are not measuring the same thing in the first place. Security is scoring the likelihood and impact of compromise. Everyone else is scoring the cost and risk of the fix. Both belong in the decision; neither substitutes for the other, and a single number that silently blends them will be trusted by nobody the moment its output becomes inconvenient.
- Separate the two questions. Score the exposure and score the remediation cost independently, then decide with both in front of you. A finding that is high exposure and cheap to fix should never sit in the same queue position as one that is high exposure and expensive.
- Agree on the inputs, not the number. Teams will rarely accept someone else's score. They will accept a shared set of factor: internet reachability, known exploitation, business criticality of the asset, and compensating controls in place, because those are verifiable.
- Write down the tie-breaker. When security and the asset owner disagree, name in advance who decides and on what basis. An undocumented tie-breaker defaults to whoever escalates hardest.
Breakdown Two: Ownership Is Unclear, or Arrives Too Late
Most programs assign ownership after prioritization is finished. It feels logical, but it creates a predictable source of backlog. A 2026 survey of 300 IT and security leaders found that 38% said remediation ownership either depends on the situation or is unclear, while 82% said the team identifying a vulnerability cannot consistently remediate it without involving someone else.
By the time a finding has been triaged, scored, and queued, “who owns this?” can trigger a search: query the CMDB, find a stale entry, ask the former owner, get redirected, open a ticket against a group inbox, wait. Nobody rejected the work. It is simply unassigned, and unassigned work accumulates.
The problem is often worst around shared infrastructure, base images, identity configuration, inherited cloud modules, and acquired systems, where ownership is less obvious and a single fix can remove risk across multiple assets.
There is also a harder form of the problem: owning the asset is not the same as owning the decision. A team may own a service but lack authority to accept downtime, defer a release, or change a shared dependency. When the asset owner is known but the decision owner is not, an unassigned finding simply becomes a stalled one.
- Resolve ownership at discovery, not at triage. An asset inventory that cannot answer "who owns this and who can approve a change to it" is an inventory, not an operating input.
- Name two owners. One accountable for the asset, one empowered to make the trade-off. On most shared infrastructure, those are different people, and pretending otherwise is what produces the stall.
- Treat unowned findings as their own risk category. Report unassigned exposures separately from open ones. The first is a governance problem, the second is a capacity problem, and conflating them hides both.
“I think where I've seen that is when they operate in their own silos, right? And they don't coordinate a lot and there you get a lot of finger pointing, well, we said to do this and they chose to do this.”
Konrad FellmanCISO & VP of Global IT Infrastructure, Modine ManufacturingSee it in the transcript at 2:02 · Security Starts with Infrastructure → Breakdown Three: Context Is Lost Between Decision and Action
A well-run triage meeting can produce a good decision. This finding matters because the asset is internet-facing, sits in the payment path, and runs a version with known exploitation. Fix it this sprint, and here is what has to change for it to count as fixed.
What reaches the engineer is a ticket with a CVE, severity label, hostname, and due date.
Everything that made the decision defensible, why this one matters, what the fix protects, and what “done” means, disappears in the handoff. The engineer gets an instruction without the reasoning behind it, encouraging the narrowest interpretation of the ticket with little reason to consider other systems carrying the same condition.
That is how remediation quietly diverges from intent. A team may upgrade the vulnerable component on the listed host while the same component ships in a base image used by thirty services. Or it may close an exposed interface with a firewall rule while leaving it reachable over a peered network. Neither is negligence. The instruction traveled; the reasoning did not.
The handoff also runs one way. An engineer without that context cannot flag that the proposed fix will not work, suggest a safer alternative, or point out that one change could resolve several findings at once. The person best positioned to improve the decision was not given enough context to question it.
- Ship the reasoning with the request. Three lines usually does it: what an attacker could do with this, why it ranked above other work, and what specific condition has to be false before this counts as resolved.
- Define done as a state, not an action. "Upgrade package X to version Y" is an action. "Component X is no longer reachable below version Y on any asset in this environment" is a state, and a state is testable.
- Make the path back easy. Give the engineer an obvious way to say "this fix will break Z, here is a better one," and route that answer to whoever made the original call.
Breakdown Four: Remediation Competes for the Same Hands
Security work does not fail because engineering teams disagree that it matters. It fails because it enters an already full queue, owned by people also running the platform, inside change windows that were never designed around exposure timelines.
A remediation request competes with customer commitments, migrations, on-call demands, and freeze windows. Put a thirty-day target in front of a change advisory board that meets every other week and a two-week freeze, and the target was never achievable. It was aspirational arithmetic applied to real constraints.
Dependencies make it worse. A library upgrade requires a runtime upgrade, which requires a base image rebuild owned by another team and regression testing across every service that inherits it. What looked like a one-line change becomes a four-team project.
The common response is escalation, and escalation works. Once. Used routinely, it borrows capacity from other work and teaches teams that everything is urgent. A program that can only move work through escalation has a ceiling: how often leadership is willing to intervene.
Remediation capacity has to be treated as a budgeted resource, not an assumption, engineering time allocated in advance so security work does not require a fresh negotiation every cycle.
- Negotiate capacity, not individual tickets. A standing percentage of each team's cycle reserved for exposure work turns hundreds of small negotiations into one annual one.
- Surface dependencies before the target date is set. If a fix requires a platform change, the platform team's timeline is the real timeline. Setting a date without them produces a missed date and a false signal.
- Set targets against the change calendar you actually have. Freeze windows, release trains, and board cadences are facts. An SLA that ignores them gets missed for structural reasons, then read as a performance problem.
- Batch by fix, not by finding. One base image rebuild that resolves sixty findings is a far easier sell than sixty tickets, and it is the same work.
Breakdown Five: The Fix Is Treated as the Finish Line
The fifth breakdown is one this series covered last week, so it is worth carrying forward rather than repeating: a closed ticket records that someone performed an action. It does not confirm that the exploitable condition is gone.
This one also differs from the other four. They cause work to stall. This causes work to look complete when it is not. A stalled finding remains visible. A falsely closed one leaves the backlog, the report, and leadership’s attention while the exposure remains.
It also breaks the loop. Verification is not just a quality check on one fix; it tells the program whether its decisions worked. Without it, recurring findings, fixes that fail after deployment, and remediation aimed at the wrong assets can go unnoticed. The program keeps running. It just stops learning.
The reporting consequence is just as important. Closure rates measure activity, not necessarily risk reduction. “We closed eighty-four percent of critical findings” and “critical exposure on internet-facing assets fell by sixty percent, confirmed by retest” are different claims. Only the second describes whether risk actually went down.
The pattern to watch for: a finding that closes, then reappears in the next scan cycle under a slightly different identifier. That is not a new exposure. It is the same one, and it means the fix did not survive a deployment, an image refresh, or a rollback, which is a model problem, not an engineering mistake.
“...we need to continuously improve our exposure management and validate our security controls. And that has to happen frequently. So continuous monitoring against that is extremely important. It gives you an understanding of where your vulnerabilities are, how they change on a month to month, week to week, even day to day basis.”
Al Imran HusainChief Information Security Officer, MillerKnollSee it in the transcript at 14:53 · How AI Has Elevated the Path to Compromise in Manufacturing → Connecting the Five Into One Operating Model
Read together, the five breakdowns describe one problem: the stages may have owners, but the transitions often do not. Prioritization has a team. Remediation has a team. The handoff between them has a ticket queue, and a ticket queue is not an owner.
Consistency requires each handoff to carry three things: who decides next, why the work matters, and what has to be true for it to be finished. Without them, every finding becomes a fresh negotiation. With them, verification feeds back into prioritization and risk reduction becomes a continuous loop rather than a series of individual fixes.
To test your own program, take one finding from last quarter and trace it end to end. Wherever someone had to step in to keep it moving is where the model still depends on the person rather than the process.
That is ultimately the purpose of Continuous Threat Exposure Management (CTEM). CTEM connects discovery, prioritization, validation, and remediation into a continuous operating cycle, so teams can move from finding exposures to consistently reducing and verifying risk.
From Discovery to Risk Reduction: Operationalizing CTEM in Modern Security Programs
Every breakdown in this article sits at a seam between stages. The session walks through how the stages of CTEM operate as one connected loop, and what it takes to keep prioritization, ownership, action, and verification from coming apart at the handoffs. Hosted by Avery Rozar, CEO at TrollEye Security.
Save your seat →Frequently Asked Questions
Is this a tooling problem or a process problem?+
Overwhelmingly process. Every breakdown described here can happen in an environment with excellent detection coverage, because none of them is a failure to find exposure. They are failures to move a known finding through a decision, an owner, an action, and a confirmation. Tooling can enforce a model. It cannot supply one.
Which of the five should we address first?+
Ownership, in most cases. Unresolved ownership blocks every stage downstream of it, and it is usually the cheapest to fix, because it is an inventory and accountability question rather than a capacity one. Prioritization disagreements also get easier to settle once it is clear who is disagreeing and who decides.
How do we set remediation targets that teams will actually meet?+
Set them against the change calendar, dependency chain, and standing capacity you actually have, rather than against an ideal. A structurally unachievable target is not an aspiration. It generates misses that get read as performance problems, and it erodes the credibility of every target that follows.
What should we report to the board instead of closure rates?+
Report confirmed reduction in exposure for the areas that matter most, verified by retest, scoped to the assets and attack paths leadership already cares about, alongside the count of findings that are unassigned rather than merely open. The first shows what the program bought. The second shows where the model is leaking.
Does a continuous model mean remediating more, faster?+
No. It usually means remediating about the same amount with far less variance, and spending that capacity on exposures that demonstrably reduce risk rather than on whichever findings happened to attract attention. Consistency, not volume, is what makes the outcome predictable enough to plan around.
