CTEM Assessment: Continuous Threat Exposure Management
Continuous Threat Exposure Management is the programmatic approach to reducing your organisation's exploitable attack surface on a continuous basis — not just at scan time. This guide covers the Gartner CTEM framework, how it differs from traditional vulnerability management, where BAS and ASM fit, and how to assess and advance your CTEM maturity.
What Is CTEM?
Continuous Threat Exposure Management (CTEM) is a cyclical security programme that continuously discovers, prioritises, validates, and remediates exploitable exposures across an organisation's attack surface. It was defined by Gartner analysts Pete Shoard and Jeremy D'Hoinne in 2022 and has rapidly become the dominant framework for modernising exposure and vulnerability management programmes.
The critical word is "continuous". Traditional vulnerability management is a periodic activity: scan, report, remediate, repeat on a monthly or quarterly cycle. In modern cloud-native environments — where infrastructure changes daily and attackers move in hours — periodic scanning creates unacceptable windows of unknown exposure. CTEM replaces the scan cycle with a continuous programme.
CTEM also expands scope. Traditional vulnerability management focuses on CVE-assigned software vulnerabilities. CTEM encompasses all exploitable exposures: cloud misconfigurations, identity and access issues, sensitive data exposure, software supply chain risks, and security control gaps — all prioritised by real-world exploitability and business impact rather than theoretical severity scores.
Gartner Definition
"CTEM is a pragmatic and systemic approach to continuously refine the priorities of a set of exposures and drive remediation. It starts with setting the scope based on business context, then discovers the assets, then prioritises them, then validates whether they are actually exploitable, and then mobilises fixing actions."
— Gartner, Implement a Continuous Threat Exposure Management Programme, 2022
The 5-Stage CTEM Cycle
Gartner defines CTEM as a five-stage cycle that runs continuously — not as a linear project with a start and end date. Each stage feeds the next, and the cycle repeats as the environment, threat landscape, and business context evolve.
Scoping
Defining what matters and what is at risk
Scoping establishes which assets, business processes, and digital surfaces are in scope for the CTEM programme. This is not a technical exercise — it requires business context. Which systems would cause material business impact if compromised? Which assets are externally reachable? What do adversaries targeting your industry sector most commonly pursue?
Key Activities
- Identify critical business processes and their technology dependencies
- Map externally-facing attack surface: internet-exposed assets, cloud infrastructure, SaaS, third-party integrations
- Classify assets by business criticality, data sensitivity, and regulatory relevance
- Align scope with threat intelligence: what do known adversaries targeting your sector target?
- Define CTEM programme boundaries and cadence (continuous vs sprint-based)
Tools: Attack Surface Management (ASM), CMDB/asset inventory, business impact analysis
Discovery
Finding every exposure across the defined scope
Discovery enumerates all exposures within scope: vulnerabilities (CVEs), misconfigurations, excessive permissions, weak credentials, exposed sensitive data, software supply chain risks, and control gaps. Unlike traditional vulnerability scanning, CTEM discovery covers the full spectrum of exploitable exposures — not just CVE-assigned software flaws.
Key Activities
- Continuous authenticated vulnerability scanning (Tenable, Qualys, Rapid7)
- External ASM: subdomain enumeration, cloud asset discovery, shadow IT identification
- Cloud security posture scanning (CSPM): misconfiguration detection in AWS/Azure/GCP
- Identity and access review: over-permissioned accounts, stale credentials, exposed service accounts
- Sensitive data exposure: publicly accessible S3 buckets, exposed databases, leaked credentials in code repositories
- Software supply chain: SBOMs, dependency scanning, compromised package detection
Tools: Tenable One, Qualys TruRisk, Rapid7 InsightVM, Wiz, Orca Security, Cyberpion
Prioritisation
Ranking exposures by actual exploitability and business impact
Traditional vulnerability management prioritises by CVSS score — a theoretical severity rating that bears limited correlation to actual exploitation risk. CTEM prioritisation uses contextual signals: is the vulnerability actively exploited in the wild? Is the vulnerable asset internet-exposed? Does an exploit exist in Metasploit or on GitHub? What is the blast radius if this exposure is used as an initial access vector?
Key Activities
- Apply EPSS (Exploit Prediction Scoring System) to rank by exploitation probability
- Cross-reference against CISA KEV (Known Exploited Vulnerabilities) catalogue
- Contextualise by asset criticality and exposure: internet-facing vs internal-only
- Model attack paths: which exposures enable multi-step exploitation chains to crown jewels?
- Incorporate threat intelligence: which TTPs are adversaries targeting your sector using?
- Produce risk-ranked remediation queue for security and IT operations teams
Tools: EPSS scores, CISA KEV, Tenable VPR, Qualys TruRisk, XM Cyber, Skybox
Validation
Testing whether exposures are actually exploitable and controls actually work
Validation answers the question that traditional vulnerability management ignores: even if this vulnerability exists, can it actually be exploited in our environment? And if it is exploited, do our security controls detect and stop it? This is where Breach and Attack Simulation (BAS) and adversary simulation exercises play their critical role.
Key Activities
- BAS platform execution: automated adversary emulation against deployed controls (Picus, AttackIQ, SafeBreach)
- MITRE ATT&CK coverage testing: which techniques does your current detection stack cover?
- Manual penetration testing: targeted tests against highest-priority attack paths
- Control efficacy validation: does your EDR catch this lateral movement technique? Does your SIEM generate an alert?
- Firewall and network segmentation verification: can an attacker actually traverse between segments?
- Compensating control identification: which compensating controls reduce exploitability even without patching?
Tools: Picus Security, AttackIQ, SafeBreach, Cymulate, Pentera, manual red team
Mobilisation
Systematically closing exposures and tracking to completion
Mobilisation is where CTEM findings translate into remediation action and the loop closes. This requires cross-functional coordination: security identifies and prioritises exposures, IT operations patches and hardens systems, development teams fix code vulnerabilities, and identity teams remediate access issues. Mobilisation without strong process integration — and leadership accountability — is where most CTEM programmes stall.
Key Activities
- Integration with ITSM (ServiceNow, Jira) for remediation ticket creation and tracking
- Risk acceptance workflow for lower-priority exposures where remediation cost exceeds risk
- Developer workflow integration: vulnerability findings flowing into CI/CD security gates
- Metrics and SLA tracking: remediation velocity by severity class, mean time to remediate (MTTR)
- Re-validation cycle: confirm exposures are closed and controls now detect the associated technique
- Executive reporting: risk posture trends, SLA compliance, programme effectiveness metrics
Tools: ServiceNow VR, Jira, Plexicus, remediation workflow in Tenable/Qualys, ASPM platforms
CTEM vs Traditional Vulnerability Management
CTEM is not a replacement for vulnerability management — it is an evolution of it. The table below shows the key differences between traditional VM programmes and a mature CTEM approach.
| Dimension | Traditional VM | CTEM |
|---|---|---|
| Scope | CVE-assigned software vulnerabilities | All exploitable exposures: CVEs, misconfigs, identity risks, data exposure, supply chain |
| Prioritisation basis | CVSS score (static severity) | EPSS + KEV + asset criticality + attack path analysis + threat intel |
| Validation | Assumed: if patch exists, apply it | Tested: BAS confirms exploitability and control efficacy |
| Frequency | Periodic scans (monthly/quarterly) | Continuous discovery and prioritisation |
| Coverage | Known assets in scan scope | Includes unknown assets, shadow IT, cloud sprawl via ASM |
| Output | Vulnerability list ranked by CVSS | Risk-ranked attack paths with business impact context |
| Remediation tracking | Ticket created; not always verified closed | Re-validation confirms closure; controls tested post-remediation |
| SOC integration | Minimal — separate from SOC workflow | Detection gaps from validation feed directly into SOC content updates |
| Business context | Asset owner; limited criticality weighting | Business process impact; crown jewel asset mapping |
| Regulatory alignment | Checklist compliance | Risk-driven; demonstrable exposure reduction for regulators |
Breach and Attack Simulation (BAS) in CTEM
BAS is the Validation stage engine of CTEM. It provides the automated, continuous adversary emulation capability that answers the core CTEM validation question: "Can this exposure actually be exploited, and would our controls detect it?"
Automated Adversary Emulation
BAS platforms execute thousands of ATT&CK technique simulations against your live environment — endpoint, email gateway, network controls, web application firewall — and report which attacks succeed and which are detected and blocked. Unlike manual pen tests, BAS runs continuously and on demand.
MITRE ATT&CK Coverage Mapping
BAS output maps directly to the ATT&CK matrix: which techniques are your controls covering, and which have blind spots? This coverage map drives detection engineering — SOC teams add or tune detection rules specifically for techniques where BAS found gaps.
Control Drift Detection
Security controls degrade over time: configuration changes, software updates, new cloud resources, and EDR policy exceptions all erode coverage. BAS run on a regular schedule detects when previously-blocking controls have stopped blocking — catching drift before attackers exploit it.
Continuous Red Team as a Service
BAS effectively provides on-demand red team capability between full adversary simulation exercises. It does not replace skilled red teamers — creativity, social engineering, and novel technique development still require humans — but it provides daily validation of control efficacy that human teams cannot match in frequency.
Leading BAS Platforms in 2026
Picus Security
Strong ATT&CK coverage, SOC integration
AttackIQ
MITRE-aligned, enterprise-grade
SafeBreach
Broad scenario library, cloud coverage
Cymulate
ASM + BAS combined platform
Pentera
Autonomous pentest + BAS hybrid
Mandiant Advantage
Intel-led validation
Attack Surface Management (ASM) in CTEM
ASM is the Discovery stage engine — the capability that ensures CTEM finds exposures across the full attack surface, including assets the organisation doesn't know about. Without ASM, CTEM is limited to known inventory: you can only discover exposures on assets you know to scan.
External Attack Surface Discovery
ASM continuously enumerates your organisation's internet-facing attack surface: domains, subdomains, IP ranges, certificates, open ports, exposed services, cloud storage buckets, code repositories, and technology stack fingerprints. This finds assets your internal inventory doesn't know about — the shadow IT and forgotten infrastructure that attackers find through automated scanning.
Shadow IT and Subsidiary Risk
Large enterprises accumulate hundreds of subdomains, cloud accounts, and SaaS applications outside central IT visibility. ASM discovers these continuously and flags risks: expired SSL certificates, running vulnerable software versions, exposed admin interfaces, and services with default credentials.
Supply Chain and Third-Party Exposure
ASM tools increasingly extend to third-party attack surface: the technology risk profile of your vendors, partners, and supply chain. If a critical supplier is running unpatched systems or has exposed RDP, that is your risk too — and ASM quantifies it before it becomes an incident.
Continuous Monitoring, Not Point-in-Time
Traditional penetration tests take a point-in-time snapshot. Your attack surface changes daily — new cloud resources spin up, developers push code to GitHub, marketing launches new subdomains. ASM provides the continuous monitoring that matches the pace of change in modern cloud-native environments.
CTEM Maturity Model: 0–4 Scale
This maturity model aligns with the RateMySOC 0–4 scoring methodology. Each level describes the actual capabilities present — not intentions or plans.
No structured exposure management programme. Vulnerability scanning may be conducted ad-hoc but results are not consistently remediated or tracked. No ASM, no BAS, no formal CTEM cycle. The organisation discovers its exposures primarily when they are exploited.
Regular vulnerability scanning in place (monthly or quarterly). Results are tracked in a basic system. Prioritisation is primarily by CVSS score. No external ASM, no BAS, and no formal attack path analysis. Remediation is driven by scan schedule rather than business risk.
Continuous vulnerability scanning with EPSS and CISA KEV-based prioritisation. External ASM tool in place for internet-facing surface discovery. First BAS platform deployed for MITRE ATT&CK coverage testing. CTEM findings begin to inform SOC detection content. Remediation SLAs defined and tracked.
Full CTEM cycle operational: continuous scoping updates, ASM-driven discovery, attack path-based prioritisation, regular BAS validation, and integrated mobilisation workflow. BAS findings automatically create detection engineering tickets. CTEM metrics reported to board. Third-party risk included in scope.
AI-native CTEM: automated exposure discovery and prioritisation using ML risk models. Agentic BAS that dynamically generates novel attack paths. CTEM findings automatically update SIEM detection rules via detection-as-code pipeline. Adversary emulation is continuous and self-updating based on current threat intelligence.
How CTEM Integrates with SOC Operations
CTEM is sometimes treated as a separate "red side" programme disconnected from the SOC's "blue side" detection and response mission. This is a significant missed opportunity. The most mature security organisations run CTEM and SOC operations as a tight feedback loop.
Detection Gap Closure
BAS validation identifies techniques that are not detected by the current SIEM ruleset. These gaps feed directly into the detection engineering backlog — creating new Sigma rules, tuning existing alerts, and deploying them through the detection-as-code pipeline. CTEM closes the loop between "known attack technique" and "active detection coverage".
Threat Intelligence Operationalisation
CTEM's prioritisation stage consumes threat intelligence to weight exposures by active exploitation probability. The same threat intel that informs CTEM prioritisation should update SOC detection rules — ensuring that when an adversary is actively exploiting a technique against your sector, your SOC has detections running for it.
Incident Context Enrichment
When the SOC detects an incident, CTEM exposure data provides immediate context: which known exposures exist on the affected asset? Which attack paths could have led here? This context accelerates root cause analysis and scoping — analysts spend less time investigating what could have happened and more time confirming what did.
Post-Incident Exposure Review
Every confirmed incident should trigger an immediate CTEM scope review: were there known exposures on the initial access path? Were they in the remediation queue? Did validation confirm they were blocked? Post-incident CTEM review is the highest-signal feedback loop for improving the programme.
Frequently Asked Questions
- Is CTEM a Gartner proprietary framework or an industry standard?
- CTEM originated as a Gartner concept, first published in 2022 and elevated to a Top 10 Strategic Technology Trend in 2023–2024. It is not a certification or standard — it is a programme model that synthesises existing practices (vulnerability management, red teaming, ASM, BAS) into a continuous cycle. Vendors and consultancies have adopted the CTEM terminology, so you will encounter it broadly, though implementation specifics vary.
- Do we need to buy all-new tooling to implement CTEM?
- No. CTEM is primarily a programme model — many organisations already have the underlying tools (vulnerability scanner, penetration testing vendor, threat intelligence feeds) and can implement CTEM by connecting these into a continuous cycle with improved prioritisation logic and cross-team workflows. Dedicated CTEM platforms and BAS tools add significant value but are not mandatory starting points.
- How does CTEM relate to CVSS scores and traditional risk ratings?
- CTEM explicitly moves away from CVSS as a primary prioritisation signal because CVSS measures theoretical severity, not real-world exploitation risk. A CVSS 9.8 vulnerability on an internal-only, air-gapped system with no available exploit is less urgent than a CVSS 6.5 vulnerability that is actively being exploited in the wild, on an internet-facing system, with a public PoC. EPSS and CISA KEV provide much stronger prioritisation signals than CVSS alone.
- What is the relationship between CTEM and zero-day management?
- CTEM primarily addresses known exposures — CVEs, misconfigurations, and control gaps that can be discovered and prioritised before exploitation. Zero-day vulnerabilities (unknown, unpatched) require complementary controls: threat intelligence monitoring for emerging exploitation, BAS-based control efficacy validation (does your EDR catch the exploitation behaviour even without a signature?), and detection engineering aligned to post-exploitation TTPs. CTEM and zero-day response are complementary, not competing.
- How long does it take to implement a CTEM programme?
- A basic CTEM programme (Stages 1–3 of the cycle with continuous scanning and improved prioritisation) can be operational within 60–90 days if tooling is already in place. Full CTEM maturity — including BAS-based validation and integrated mobilisation workflows — typically requires 6–12 months. The bottleneck is usually not tooling but the cross-functional coordination required for Stage 5 (Mobilisation): getting IT operations, development, and security aligned on remediation SLAs and accountability.
Assess your SOC's CTEM integration
The RateMySOC assessment evaluates whether your vulnerability management, BAS, and ASM capabilities are integrated into a continuous exposure management programme — a key differentiator between Level II and Level III SOC maturity.
Benchmark Your CTEM Maturity →