Most security program reviews celebrate high coverage and compliance scores, while the real risk sits in the remaining 1 to 3 percent. Attackers don't need most of your environment. They need one workable path through whatever's left outside the number. The metrics we rely on reward activity, things like tickets closed and SLAs met, over risk reduction. Cyber leaders, along with Audit, Risk, and Compliance, need to stop treating coverage and closure rates as sufficient progress. Where to focus the attention instead: ranked residual exposures, clear ownership, and documented decisions about what they are willing to live with. Green Dashboards and high coverage scores are a distraction from realizing acceptable residual risk.

This is the same trick as a product claiming “97% effective.” The honest version of that claim is “3% ineffective.” That’s the number that should get your attention. High performers naturally ask what to do about the remaining 3%. That 3% may hold the one workable path a threat actor needs to take down the environment.

Look at almost any security program review and the numbers tell the same story:

• Vulnerability scanning coverage: 99%
• Critical patch compliance: 97%
• Endpoint protection coverage: 98%
• MFA adoption: 99%
• Security awareness training: 100%

Everything is green. Leadership signs off. The board moves on.

What those numbers overlook matters more. The 3% remaining unpatched includes an internet-facing system somewhere. The 2% without EDR is a privileged workstation somewhere. The 1% still outside MFA is a legacy remote access path nobody fully retired. That combination is where the exposure lives.

We've already seen this play out. Colonial Pipeline's disruption started with an inactive VPN account that didn't have MFA. The Change Healthcare incident that stopped claims processing across large parts of the healthcare system began with stolen credentials on a remote access portal that also lacked MFA. In both cases the broader metrics looked solid. The residual gap was what counted.

Reachability is only one way in. It gets the attention because it is easy to picture. A scanner finds an exposed system, someone maps the path, the story writes itself. But it is not how most attackers get their first foothold. Recent threat reporting is consistent on this point: the initial compromise is usually a person, not a port. Phishing. Stolen or reused credentials. Identity and access management that was deployed fast and never tightened. A secret checked into a repo or left in a config file. A SaaS tenant with no MFA that nobody counts as part of the estate, because no server sits behind it.

None of that turns red on a coverage dashboard. Your MFA number can read 99 percent while the one account outside it is the account that matters. Your leaked secrets are not in the vulnerability scanner's results at all. The gap is not only the unpatched internet-facing host. It is the contractor's login, the service account with a static key, the marketing team's SaaS instance. Same principle, wider surface. The small slice you did not cover is where the intrusion happens.

A scanner showing 99% coverage can't tell you anything about the systems it never found.

We're measuring activity, not effectiveness

Security has never lacked metrics. Vulnerability counts, patch rates, alert volumes, phishing results, MTTD, MTTR, SLA performance. Most of these are useful.

The problem is activity masquerading as effectiveness.

A 97% critical remediation rate within SLA is a fine operational number. However, it tells you nothing about whether the remaining 3% is internet-reachable, leads to a critical application, or ties to privileged access. Attackers don't need 97% of the environment. They need one path through the 3%.

The metrics aren't the problem

Dashboards, frameworks, KPIs, SLAs. None of that is the enemy. The issue is what we're asking them to prove.

Most vulnerability management programs still run the same loop: find it, ticket it, fix it, close it. That loop produces volume and speed metrics. Those answer operational questions. They don't answer the one that matters:

Did the work reduce residual risk in a meaningful way?

The above question needs context, prioritization, and ownership. Activity numbers give you none of them.

Volume isn't risk reduction

Two organizations can both find 10,000 vulnerabilities.

One closes 9,500 and reports a strong remediation rate. The other finds the much smaller set that's internet-facing, being exploited, or tied to privileged access, and drives those to resolution first.

The first team has the cleaner dashboard. The second team made the better risk decision. Mature programs go for the second outcome.

Manage the decisions and the residual risk, not just the findings

Buying a scanner doesn't give you a vulnerability management program. Buying MFA doesn't give you an identity program. Tools provide capabilities. A program needs: governance, process, judgment, technology, and evidence it's actually working. Skip or overlook any one of those and the control weakens, no matter how good the tool is.

The usual workflow is scan, find, ticket, patch, close. A program built to reduce risk asks more: What do we actually have? Where's the exposure? What's exploitable? What business processes or data does it touch? What identities and privileges connect to it? What's threat intel saying right now? What goes first? What's the right treatment? Did the action actually reduce the exposure? This is the operating model behind Continuous Threat Exposure Management (CTEM).

Strip that down and it comes down to four stages.

Find it. Understand it. Decide on it. Prove it worked.

Patching is one option. Sometimes the better move is a compensating control, better segmentation, killing external exposure, retiring the asset, or formally accepting the risk. The measure of the program is the quality of the decisions on residual risk, not the count of findings produced or closed.

Limited resources make prioritization matter more, not less. Treating everything the same way is the expensive, less effective approach.

The answers we should stop accepting

"How many critical vulnerabilities do we have?" is the wrong lead question. "Which residual exposures create a realistic path to material impact?" is the right one.

Stop treating percentage-based closure rates as sufficient. Get the list of open high-impact items that are internet-reachable, privileged, or actively exploited. Rank them by impact. Require named owners and treatment decisions: remediate, compensate, accept, or retire.

Stop accepting coverage percentages on their own. Get visibility into the assets and identities sitting outside key controls, with a straight statement of the residual risk.

Don't just ask if the SLA was met. Ask what material risk is still sitting outside it, why, and who makes that call.

The operational metrics stay. They just stop being the whole answer.

Know the attacker. Know yourself.

"If you know the enemy and know yourself, you need not fear the result of a hundred battles." - Sun Tzu, The Art of War

There is an older premise supporting this: You cannot defend an environment well if the only thing you understand is the environment. You also have to understand the attackers trying to get into it. What they actually do in the wild right now, which techniques they favor, which they have abandoned, and what a real intrusion against an organization like yours looks like from initial access to exploitation.

Half of the job is knowing the adversary's playbook. The other half is taking an honest look, and knowing your own weak points before someone else finds them for you. A program that does both can see the plausible path coming and decide, on purpose, what to do about it. A program that does neither is reacting, and reacting is a losing position when the environment is contested. Col. John Boyd's point about getting inside the opponent's decision loop applies directly: you do not get there by watching your own dashboard turn green. You get there by understanding the fight you are actually in and what the adversary is likely to try next.

Changing the operating rhythm

Most people agree with the problem. Changing how the conversation flows is the task at hand.

Start here:

These four steps are the four stages in practice: find it, understand it, decide on it, prove it worked.

1. Change the standing agenda item: Replace "Dashboard / Metrics Review" with "Residual Exposure Review." The first part of any program, risk, or assurance review should focus on what's still sitting outside the green numbers.

2. Require a simple residual risk view: Before each review: Which systems or identities sit outside critical controls? Which of those create a plausible path to material impact? What's the current treatment decision, and who owns it? What residual risk remains if nothing further happens?

3. Make the plausible path conversation mandatory: Once a quarter, or after any significant change, the security team walks through the single most realistic attacker path that still exists through current gaps. Entry point, what's reachable, business and regulatory impact, and whether that risk has been explicitly accepted, and if so by whom and for how long.

4. Require real ownership: Every material residual exposure gets a named owner and a recorded decision. "It's in the ticket queue" is not ownership. "We're tracking it" is not acceptance. 

This doesn't necessarily require new tools. It does take different questions, clearer accountability, and sets a higher bar for how residual risks are handled and documented.

Green has to mean more than "the process ran"

There's a real difference between having a control and running a process against it versus reducing the risk the control was meant to address. Most programs can show the first two. Few can show the third with evidence.

A control can be in place. A process can be operating. An SLA can be met. The dashboard can be green. The residual risk can still be too high. All of that can be true at once.

Even though the dashboard is green, you have to ask what's still exposed, and whether anyone's signed their name to that answer.

If your team can't say with confidence what's still exposed behind the green, Arctiq's Cybersecurity Advisory Services can help you find it, rank it, and assign ownership. Connect with us to get started.