Part 2 of a three-part series based on a session by Ruchit Deshpande, The Missing Link's Security Solutions Director at Tenable ExposureCon, "Operationalising CTEM," on what it really takes to operationalise exposure management and reduce measurable cyber risk.
Part 1 of this series argued that more visibility alone doesn't reduce risk. Buying the technology is the easy part. What happens after it's switched on, once visibility has to turn into actual operational capability, is where most exposure management programs stall.
Key takeaways
-
-
Technology doesn't operationalise exposure management. People and process do.
-
Programs stall because ownership breaks down between finding a problem and someone fixing it.
-
Advisory, engineering, offensive security and managed services must operate as one capability, not four separate purchases.
-
Validation proves business risk. A severity score only estimates it.
-
Why do exposure management programs stall after the technology is in?
One client put it to me plainly:
"Too many vulnerabilities as backlog items being presented to the patch management team without any business prioritisation... Please help."
Different tools were producing disparate results, some pointing to configuration fixes, others to patching, others to something that needed a technology change entirely, with nothing to say which mattered most. In my experience, it usually comes back to the same four gaps:
-
-
Too many findings, not enough prioritisation. Severity becomes the priority instead of exploitability, business impact, asset criticality and attack paths.
-
Unknown and unmanaged assets. Discovery stops at the assets people remember exist, not cloud posture, identity exposures, shadow IT and misconfigurations.
-
Weak remediation ownership. Findings get raised, nobody owns closing them, and the backlog just accumulates.
-
Limited executive visibility. Leaders get a spreadsheet of counts, not a trend line, a heatmap or a business-context view they can act on.
-
Traditional vulnerability management is reaching its limits
Figure 1: Ten places traditional vulnerability management breaks down, and the business impact that follows: large backlogs, missed critical risks, inefficient remediation and poor risk visibility.
If you recognise two or three of these in your own organisation, you're not behind. You're normal. In my experience, these gaps rarely show up alone. I've seen them appear at every stage of the cycle: discovery that stops at known assets, prioritisation still driven by CVSS instead of real-world risk, validation that happens too late to matter, or remediation that stalls because the business context was never agreed in the first place.
What does an operationalised exposure management program look like?
Operationalised exposure management means continuously identifying, prioritising, validating, remediating and measuring exposures through a coordinated operating model, rather than treating vulnerability management as a series of disconnected technical activities.
Treating advisory, engineering, offensive security and managed services as four things you buy separately, on four different contracts, from possibly four different vendors, is the mistake. They're really one continuous loop: Advisory → Engineering → Offensive Security → Managed Services → Continuous Improvement, feeding back into itself. Few organisations have one team capable of covering the entire loop, and that's usually where the handoffs break down, and the backlog starts building again.
Underneath that sits the operational cycle every finding moves through: identify, prioritise, validate, remediate and measure. The first loop describes who owns the capability. This one describes how exposure gets reduced. Both need to run continuously.
Figure 2: The CTEM operating model: a continuous, business-driven exposure reduction program running through identify, discover, prioritise, validate, remediate and measure.
Together, these two loops are what operationalising CTEM looks like inside an organisation: two operating cycles running at the same time, with clear ownership at every handoff.
I rarely see customers fail because they chose the wrong technology. They struggle because advisory identifies the risk, engineering implements the controls, offensive security validates the outcome, and managed services maintains it over time, but each team is measured differently and often works to different priorities. Exposure management only works when those activities become one operational capability instead of four disconnected functions reporting to different scorecards.
I put it to clients this way: saying "we integrate with ServiceNow" describes a technical feature, but what actually matters is that we help security and infrastructure teams work from the same prioritised remediation queue.
The distinction is what changes an organisation's risk posture, because it means the people fixing things and the people deciding what's urgent are finally looking at the same list, in the same order, for the same reasons.
Every week, organisations I work with receive thousands of new findings. What we're there to do is help determine which findings are genuinely exploitable, prioritise remediation against business context, fold those actions into the workflows people already use, and measure whether risk is going down over time. A program that can't measure its own effect on risk is just generating activity.
Why does offensive security matter to exposure management?
This is where many exposure management programs stop, and it's where I'd argue the biggest opportunity still exists.
A vulnerability score is a prediction. It tells you what might happen. At The Missing Link, we don't simply trust the score. We validate whether an attacker could exploit it, using penetration testing, red teaming, attack path validation, and breach and attack simulation, depending on what the finding and the environment call for.
That distinction changes the conversation you can have with a board. "We found a vulnerability" is a technical statement. "We proved whether it could be exploited" is a business risk statement, and it's the one that tells a CISO where to spend limited remediation capacity first.
It also changes how you report success to the board. Closing 4,000 vulnerabilities is an activity count. Reducing exploitable attack paths by 42% is a risk trend, and it's the number that tells a board whether the organisation is becoming harder to attack. Boards don't want a count of tickets closed. They want a risk trend line moving in the right direction, and that only comes from validating exposure, not just counting it.
Technology gives you visibility, but running the program day to day comes down to people and process. CTEM works the same way any operational capability does, with clear ownership, a repeatable process, and a way to prove it's working, not as a project with a finish line.
Continue to Part 3: Exposure management case study: From 10,000 critical findings to a 3–7 day remediation cycle
If you're unsure whether your highest-priority findings represent genuine business risk or simply high severity scores, a Threat Validation Workshop is a practical place to start.
