The questions that separate a real CTEM vendor from a scanner on a schedule.
Continuous Threat Exposure Management is a good idea with a crowded badge. Plenty of vendors stamp “CTEM” on a vulnerability scanner and a quarterly cadence. This guide gives you the questions that pull the two apart, and for each one, the answer that should reassure you and the one that should end the meeting.
CTEM is a program. Most badges are a scanner.
Gartner coined Continuous Threat Exposure Management to describe something larger than a tool: a repeating program that runs across five stages, end to end. Scope what matters. Discover the exposures. Prioritize by what an attacker could actually reach. Validate that it’s exploitable. Mobilize the fix. The order is deliberate, and the value is in finishing the loop, not in any single stage.
Here’s the catch. A great many products wearing the CTEM badge do discovery, slap a CVSS score on the output, and call the rest of the loop your job. They skip validation because validation needs real attack technique, and they skip mobilization because routing a fix to its owner is unglamorous work. What you’re left with is a scanner running on a timer. The questions below exist to find out, in one meeting, which kind of vendor is sitting across the table.
- 1
Scoping
You decide what part of the business actually matters: the systems that, if breached, would hurt. Not the whole estate at once. The crown jewels and the paths to them.
- 2
Discovery
Find the assets and the exposures inside that scope. Hosts, apps, identities, cloud, the things nobody documented. This is where most tools live, and most stop.
- 3
Prioritization
Rank what you found by how reachable it is and what it would cost you, not by a number a scanner printed. Most exposures never get touched by an attacker. A few are the whole game.
- 4
Validation
Prove it. Can this actually be exploited, and how far does it go? This is the stage the scanner-on-a-schedule crowd quietly skips, because it needs real attack technique.
- 5
Mobilization
Get the fix done. Route it to the owner, track it, confirm it held. A finding nobody acts on is just a more expensive way of being breached.
Which surfaces do you actually test?
Ask them to name the surfaces, out loud, one by one. External perimeter, internal network, cloud configuration, identity and Active Directory, web and API, mobile. A serious vendor knows exactly where its depth is and where it isn’t, and will tell you both.
Ask “Which of my attack surfaces do you test, and which do you not?”
A specific list, with honest gaps. “We go deep on external, web, API and identity. Cloud config we cover; mobile we partner out.” Named surfaces, named limits.
“Everything.” One word, no detail. Nobody covers everything to the same depth, and the vendor who claims to is either selling a scanner or hasn’t thought about it.
Do you prove it’s exploitable, or just report it?
This is the question that separates exposure management from a vulnerability feed with better branding. A scanner sees a version number and infers a CVE. Validation is someone, or something, actually reaching the asset and demonstrating the impact.
Ask “When you flag a finding, have you confirmed it can be exploited in my environment?”
Validated findings, with the steps shown. “We reached it, here’s the path, here’s what it gave us.” Exploitability is proven before it reaches your queue, not assumed.
Severity scores and a CVE list, with no demonstration. If the answer is some version of “the scanner detected it,” you are buying a scan and paying CTEM prices.
Ranked by reachability, or by raw CVSS?
A flat list of two hundred criticals is not a priority list. It’s a way of making someone else decide. Good prioritization weighs whether an attacker can actually reach the thing, what sits behind it, and what it would cost the business if they did.
Ask “How do you decide what I fix first, and is business context part of that decision?”
A short, ordered list with reasoning. The critical on an isolated box ranks below the medium that exposes a path to customer data. Reachability and blast radius drive the order.
Findings sorted by CVSS, descending. Forty criticals, all “urgent,” no sense of which one an attacker would actually use. That’s a spreadsheet, not a program.
When the tool stops, can a person keep going?
Automation is excellent at breadth and terrible at the last ten yards: the chained logic flaw, the business-logic abuse, the foothold that only matters because of where it sits. A platform without people hits a ceiling. The question is whether anyone is standing at it.
Ask “When the automation can’t go further, who picks it up, and are they yours or mine?”
Real operators on staff who take over where the tooling tops out, dig by hand, and chain findings the way an attacker would. The platform is the floor, not the ceiling.
Pure SaaS, no people. “The platform handles it.” The platform handles what it was programmed to find. Everything past that is your problem now.
Who triages the noise, you or them?
Every automated system generates false positives. The only question that matters is where they land. If the vendor ships you raw output, you’ve hired a tool that makes work. If the vendor triages first, you’ve hired one that removes it.
Ask “Before a finding reaches my team, has a human confirmed it’s real?”
They triage. What lands on your desk has been checked, and the false positives were filtered out before you ever saw them. Your team works findings, not noise.
The queue lands on you, unfiltered. “You can tune the rules.” Translation: you’ll spend your week dismissing false positives the vendor could have caught.
What proof do you get, and can you reproduce it?
A finding your own engineers can’t reproduce is a finding they won’t trust, and won’t fix. Evidence has to be concrete enough to hand to the person who owns the system, so they can see it for themselves and close it without an argument.
Ask “What evidence comes with each finding, and can my team reproduce it from your report?”
Reproduction steps, the request and response, screenshots, the exact path. Enough that your engineer reproduces the issue in ten minutes and stops debating whether it’s real.
A PDF of scanner output. Plugin IDs, severity bands, a description copied from a CVE database. Nothing your team can act on without doing the validation themselves.
Does it route to owners, or just another dashboard?
Findings die in dashboards. The work happens in Jira, in ServiceNow, in the ticket queue your engineers already live in. A program that mobilizes pushes the finding to the owner inside their tools and tracks it to done. Anything else adds a portal to your morning.
Ask “Does this push findings into my existing workflow tools, or do I check a new portal?”
Native routing into your ticketing, with ownership assigned and status tracked back. The finding shows up where the work already happens. Remediation is visible end to end.
Yet another portal to check. A login, a dashboard, a list someone is supposed to remember to look at. If it doesn’t reach the owner where they work, it doesn’t get fixed.
Is the fix re-tested, and is drift caught?
Continuous means continuous. A fix that isn’t re-tested is a fix you’re taking on faith. And between any two snapshots, your environment changes: a new host, a misconfigured bucket, an expired control. The whole promise of CTEM is catching that drift before an attacker does.
Ask “When I fix something, do you re-test it, and what happens to changes between scans?”
Automatic re-test on remediation, with the fix confirmed or kicked back. Continuous monitoring for drift, so a new exposure is caught when it appears, not at the next quarterly window.
Point-in-time only. A scan, a report, silence until the next one. That’s a penetration test on a calendar reminder, sold as a continuous program.
If you hear these, say thank you and leave.
None of these is a small wrinkle to negotiate. Each one tells you the vendor is selling detection and calling it management. You’ll do the validation, you’ll do the triage, you’ll do the routing, and you’ll pay them for the privilege.
- “We test everything.” No vendor covers every surface to real depth. This is a sales line, not a capability.
- “The scanner detected it.” Detection isn’t validation. You’re being sold a vulnerability feed with a CTEM label.
- “It’s all automated, no people needed.” The automation stops where the interesting attacks begin. Someone has to be there when it does.
- “You can triage the false positives in the console.” That’s the vendor handing you the work they were paid to do.
- “Here’s a sample PDF.” (and it’s scanner output) If your engineers can’t reproduce a finding, they won’t fix it. Evidence is the product.
- “Everything lives in our dashboard.” Findings that don’t reach the owner’s queue don’t get remediated. Routing is the difference.
The checklist. Print it. Use it.
Ten questions, in order. Run them in the demo, not after the contract. The answers you get, and how quickly the vendor reaches for specifics, will tell you most of what you need to know.
- Name every attack surface you test, and every one you don’t.
- Is each finding validated as exploitable in my environment before it reaches me?
- Are findings ranked by reachability and business impact, not raw CVSS?
- When the automation can’t go further, does a real operator take over?
- Who triages false positives, your team or mine?
- Does every finding come with evidence my engineers can reproduce?
- Do findings route into my ticketing and track to remediation?
- Is every fix re-tested automatically, and is drift caught between scans?
- Can I see a real report from a live engagement, not a sanitised sample?
- Who, by name and seniority, will actually be looking at my environment?
Two references worth your time.
Read these before the vendor meetings, not after. The first gives you the model in its original words. The second is the map of how real attackers operate, which is exactly what a validation vendor should be able to speak to.
- GartnerHow to Manage Cybersecurity Threats, Not Episodes →
The original framing of Continuous Threat Exposure Management and its five stages. Worth reading before any vendor explains their version of it.
- MITRE ATT&CKThe adversary technique knowledge base →
The reference for how real attackers actually operate. A validation vendor worth its fee can map findings to the techniques here.