CTEM for MSPs: How to Build a Continuous Threat Exposure Management Service Line

Vulnerability scanning is not a security programme. Running Nessus once a quarter and emailing the report to a client who ignores it is not a security programme either. Most MSPs know this. The problem is knowing what to replace it with — and how to sell and deliver it profitably.

Continuous Threat Exposure Management is the answer. CTEM is not a product — it is a structured operational cycle that tells an organisation exactly where it is exposed, which of those exposures actually matter, and whether the work it is doing to fix them is moving the needle. Gartner named it a top strategic security priority for 2024 and 2025. Enterprise security teams are standing up CTEM programmes with dedicated tooling and headcount. SMBs cannot afford to do that internally. Their MSP can do it for them.

This guide covers what CTEM is, how to scope and deliver it as a managed service, what tooling you need, and how to price it.

What CTEM Actually Is

Gartner’s CTEM framework is a five-stage cycle:

1. Scoping — Define what you are trying to protect and what attackers would target. This is not “all the assets.” It is a prioritised list of business-critical systems, external-facing infrastructure, identity infrastructure, SaaS applications with sensitive data, and third-party connections. Scope changes as the business changes.

2. Discovery — Find everything in scope. This includes known assets but also shadow IT, cloud resources the client spun up without telling anyone, expired certificates, misconfigured S3 buckets, forgotten RDP endpoints. Discovery is the layer where most vulnerability management programmes fail — they scan what they know about and miss everything else.

3. Prioritisation — Rank what matters. Not by CVSS score alone — a critical CVE on a system with no internet exposure and no lateral movement path is less urgent than a medium CVE on a VPN endpoint with a known public exploit. Prioritisation combines exploitability, exposure, asset criticality, and attacker incentive.

4. Validation — Confirm the exposure is actually exploitable. This is where breach and attack simulation (BAS) and manual adversary simulation fit. Validation separates theoretical risk from actual risk. For many SMB clients, full BAS is overkill — but even basic validation steps (confirming that a misconfiguration is reachable, verifying that a patched vulnerability was actually fixed) belong in every cycle.

5. Mobilisation — Fix things, track it, and report it. Mobilisation is the handoff from security analysis to IT operations. It includes remediation tracking, exception logging for things that cannot be fixed immediately, and the executive report that shows the client their risk posture improved since last cycle.

The five stages repeat. Monthly. Or quarterly. The cycle is the programme.

Why CTEM Is a Better MSP Service Than Vulnerability Management

Traditional vulnerability management sells poorly because it is hard to explain and hard to justify renewal. You scan, you produce a list of CVEs, the client patches some of them, you scan again. The risk score may go up or down depending on new CVEs — the client cannot tell whether the programme is working.

CTEM sells differently. It is scoped to business-critical assets the client already cares about. It tells a story each cycle: here is what we found, here is what matters, here is what we fixed, here is how your exposure profile changed. Clients understand that narrative. They renew because they can see the programme working.

CTEM also expands the scope of what you are selling. Vulnerability management covers patching. CTEM covers:

• External attack surface (the internet-facing footprint the client often does not fully know)
• Identity exposure (leaked credentials, overprivileged accounts, MFA gaps)
• Cloud misconfiguration (S3 buckets, public snapshots, open security groups)
• Third-party SaaS (OAuth permissions, shadow apps)
• Physical and network segmentation gaps

Each of those is a line on the scope document — and a justification for the monthly retainer.

Scoping a CTEM Engagement for SMB and Mid-Market Clients

Start with the business, not the technology. The scoping conversation is not “what IP ranges do you have?” It is “what would hurt you most if it were compromised?”

For most SMB clients, the answer is three to five things: their ERP or line-of-business application, their email environment, their remote access infrastructure, their billing or payment systems, and their client data. Those are your Tier 1 scope items.

Layer in external attack surface: all domains they own, IP ranges that resolve publicly, cloud accounts. This is your Tier 2 scope — high-value targets for an external attacker.

Everything else — internal workstations, file servers, printers — is Tier 3. You may scan it, but it is not where the CTEM programme focuses its analytical attention.

Document this in a scope definition document the client signs off on. The scope document is not just good practice — it is your protection when a client asks why you did not find a vulnerability on a system that was out of scope.

Tooling for an MSP CTEM Stack

You do not need a $200,000 BAS platform to deliver CTEM. A practical MSP CTEM stack for SMB clients looks like this:

External Attack Surface Management (EASM): Censys, Silently, or even a well-configured combination of Shodan API and DNS enumeration tools. EASM tools continuously monitor what is exposed on the internet — open ports, certificates, exposed admin interfaces, shadow domains. This is the discovery engine for Tier 1 and Tier 2 scope.

Vulnerability Scanner: Tenable (Nessus Pro or Tenable.io), Qualys, or Rapid7 InsightVM. You likely already have this. The difference in a CTEM programme is that you are not just running the scanner — you are using its prioritisation output as one input into a broader risk narrative.

Prioritisation Logic: Use CVSS v3 combined with EPSS (Exploit Prediction Scoring System, available free from FIRST.org) to rank findings. EPSS scores predict the probability that a CVE will be exploited in the wild within 30 days. A CVE with CVSS 9.8 and EPSS 0.02 is less urgent than a CVE with CVSS 6.5 and EPSS 0.81. This combination filters the noise and makes your prioritised shortlist defensible.

Reporting Layer: This is where most MSPs fall down. Scan output is not a report. A CTEM executive report shows scope, discovery summary, prioritised findings with business context, validation status, remediation progress, and trend comparison against prior cycles. GetCybr’s vCISO platform handles this layer — turning raw scan data into the structured, board-readable risk narrative that justifies the programme.

Validation (Optional for Smaller Clients): For clients with budget for it, Cymulate, Picus, or AttackIQ provide automated breach and attack simulation that validates whether your defensive controls would stop a real attack. For smaller clients, manual validation steps — confirming exploitability of top-five findings before reporting them — accomplish the same goal at lower cost.

Delivery Model: What the Cycle Looks Like

A monthly CTEM cycle for an SMB client runs roughly as follows:

Week 1: Automated scanning — EASM discovery, vulnerability scan, credential exposure check. Tooling does the work; your analyst reviews the delta from last month.

Week 2: Prioritisation and validation. Take the new findings, score them using your prioritisation logic, and validate the top five to ten manually. Document exploitability, lateral movement potential, and business impact for each.

Week 3: Remediation coordination. Send prioritised findings to the client’s IT team with clear remediation guidance. Track tickets. Follow up on items carried over from prior cycles.

Week 4: Reporting. Generate the executive report. Schedule the monthly review call — 30 minutes, focused on three things: what we found, what we fixed, what we are watching next month.

A quarterly CTEM programme compresses this into one intensive cycle per quarter with monthly automated scanning and lightweight update reports in between. This suits smaller clients with less complex environments and tighter budgets.

Pricing the Service

Structure CTEM as a monthly retainer with an onboarding project fee.

Onboarding project fee: $5,000–$12,000. Covers scope definition, baseline EASM discovery, initial vulnerability scan, first prioritised findings report, and scope sign-off. This is the work you cannot scale across clients — it is specific to their environment and their business.

Monthly retainer tiers:

• Essentials (monthly scanning, quarterly CTEM cycle, 1 executive report per quarter): $1,200–$1,800/month. Appropriate for 25–75 endpoint clients with limited external attack surface.
• Standard (monthly scanning, monthly CTEM cycle, monthly report, monthly review call): $2,200–$3,200/month. Appropriate for 75–200 endpoint clients with cloud infrastructure and external-facing applications.
• Advanced (continuous EASM, monthly CTEM cycle, validation exercises, compliance mapping): $3,500–$5,000/month. Appropriate for mid-market clients with compliance requirements, multiple cloud accounts, or M&A activity.

These numbers are conservative. MSPs who position CTEM as a vCISO programme component — linking it to compliance obligations under SOC 2, NIST CSF, or ISO 27001 — can charge at the top of these ranges and beyond.

Selling CTEM to Clients Who Already Have Vulnerability Scanning

Most clients will say “we already do vulnerability scanning.” The right response is not to argue that CTEM is different — it is to show them.

Pull three months of their existing scan reports and ask: what did you fix? What is your risk exposure today compared to three months ago? Can you show me your external attack surface and confirm nothing unexpected is exposed?

Most cannot answer any of those questions. That is the gap CTEM fills. The pitch writes itself.

Tying CTEM to Compliance

CTEM evidence maps directly to security controls across the major frameworks your clients care about. If a client has a SOC 2 requirement, CTEM covers the Availability and Risk Assessment criteria. NIST CSF maps to Identify (asset discovery, risk assessment) and Detect (continuous monitoring). NIST 800-171 maps to configuration management, risk assessment, and system and communications protection controls.

GetCybr’s GRC automation layer imports CTEM findings and maps them to framework controls automatically. MSPs who run CTEM programmes for compliance-obligated clients get double value from the same operational work — security programme delivery and compliance evidence in one cycle.

Getting Started

The fastest path to a CTEM service line is to pilot it with one existing client you know well. Run a scoping conversation, do an EASM baseline, run your vulnerability scanner against their Tier 1 assets, and generate a prioritised findings report using the prioritisation logic above. That first report — showing them what is actually exposed on the internet, ranked by exploitability — is usually enough to close the retainer conversation.

You do not need a full tooling stack before you start. Start with what you have. Add EASM as your first new tool investment. Add reporting structure via GetCybr. Build the validation layer once you have three clients on retainer and the recurring revenue to support tooling investment.

CTEM is a service clients renew because they can see it working. That is the rarest thing in managed security — a programme where the value is visible and measurable every cycle. Build it now, before your competitors figure out how to explain it.

---

Ready to structure your CTEM delivery around GetCybr’s vCISO platform? Book a demo and see how MSPs are using GetCybr to run CTEM cycles, generate executive reports, and map findings to compliance frameworks — all from one platform.