Gartner introduced Continuous Threat Exposure Management in 2022 as one of the top strategic technology trends, and named it again in 2023, 2024, and 2025 as a priority for security leaders. The repetition matters: CTEM is not a product category or a vendor term. It is an analyst framework for how security programmes should operate, and Gartner's continued emphasis signals that they consider the gap between how most organisations manage exposure and how they should manage it to be both real and widening.
Understanding CTEM requires understanding what problem it was designed to solve, how its five-stage cycle works in practice, and where specific security tools and capabilities fit within it. The most important gap in how most organisations implement CTEM (and the most important mapping the security industry has not yet made clearly) is where agentic continuous pentesting fits within the validation stage.
This post covers both: the complete CTEM framework with depth, and the agentic pentesting mapping that makes the validation stage work.
Security programmes have historically operated on a reactive cycle: scan for vulnerabilities, generate a findings list, prioritise and patch, repeat. This cycle has two structural failures.
The coverage failure: vulnerability scanners find vulnerabilities in systems they know about and scan. Shadow IT assets, newly provisioned cloud services, and assets outside the formal inventory are not scanned. The finding list is comprehensive for the known environment but incomplete for the actual attack surface.
The prioritisation failure: vulnerability scanners generate thousands of findings. Most organisations cannot remediate thousands of vulnerabilities within any reasonable timeframe. The question is not "what vulnerabilities exist?" but "which vulnerabilities would an attacker actually exploit to cause damage?" CVSS scores are a poor proxy for this question: a critical CVSS score does not mean the vulnerability is reachable, and a medium CVSS score does not mean it cannot be chained into a serious breach.
CTEM addresses both failures by reframing the security programme objective. Instead of asking "what vulnerabilities do we have?", CTEM asks "what exposure do we have that an attacker could realistically exploit, and can we validate that our controls actually prevent them from doing so?"
The shift from vulnerability management to exposure management is a shift from potential risk to confirmed risk. CTEM is the operational framework for achieving that shift continuously rather than periodically.
Gartner defines CTEM as a five-stage continuous cycle. Understanding each stage (what it requires, what it produces, and what tools serve it) is the prerequisite for understanding how agentic pentesting fits.
Scoping defines what surfaces the CTEM programme evaluates in each cycle. This is not the same as traditional vulnerability management scoping, which starts from an asset inventory. CTEM scoping starts from the attacker's perspective: what would an attacker target? What systems, if compromised, would cause significant business harm?
What scoping covers: Internet-facing applications and APIs. Customer data systems. Critical business processes. M&A and third-party connected environments. Cloud infrastructure. Development and deployment pipelines that could serve as software supply chain vectors.
Why scoping cycles: The threat landscape changes. A new cloud service that was not a target six months ago may be a target today because of new functionality. An acquired company's infrastructure may represent a new attack surface that was not in the previous cycle's scope. CTEM's continuous cycle means scoping is revisited regularly rather than defined once.
What tools serve scoping: Threat intelligence platforms that track attacker targeting of specific asset types and industries. Business context input from security leadership about which systems represent the highest-value targets. Historical incident data identifying previously attacked surfaces.
Discovery finds all assets within the defined scope, including unknown and unmanaged assets. This is where EASM (External Attack Surface Management) and CAASM (Cyber Asset Attack Surface Management) tools are the primary mechanism.
What discovery covers: All internet-facing assets associated with the organisation's domains and IP ranges, including those not in the formal asset inventory. Cloud infrastructure across all cloud providers and regions in use. SaaS applications connected to corporate identity. Third-party vendor environments with access to organisational systems.
The unknown asset problem: Organisations consistently underestimate their external attack surface. Shadow IT provisioned outside formal processes, forgotten subdomains from discontinued projects, developer environments exposed to the internet, and cloud assets provisioned during acquisitions: all of these are real attack surface that does not appear in the formal inventory. CTEM's discovery stage specifically addresses this gap.
What tools serve discovery: Attack surface management platforms that continuously discover internet-facing assets through DNS enumeration, certificate transparency monitoring, and passive reconnaissance. EASM platforms that map the full external attack surface from the attacker's perspective. Cloud security posture management (CSPM) for cloud asset discovery.
Prioritisation answers the question that CVSS scores cannot: which discovered vulnerabilities and exposures should be addressed first, given the organisation's specific threat context?
Effective CTEM prioritisation considers three factors simultaneously:
Exploitability: Is this vulnerability actually exploitable in this environment's specific configuration? A vulnerability that is technically critical in its base CVSS score may be unexploitable in a given environment due to network segmentation, compensating controls, or environmental factors that prevent the attack from reaching the vulnerable component.
Business impact: If this vulnerability were exploited, what is the business impact? A critical vulnerability in an isolated test system has lower business impact than a medium vulnerability in the system that processes all customer transactions.
Threat intelligence alignment: Are attackers currently targeting this vulnerability class? Is this a vulnerability used in active campaigns against organisations in this industry? Threat intelligence converts theoretical risk into empirical risk.
The output of effective prioritisation is not a list ranked by CVSS score. It is a list ranked by "which of these vulnerabilities does an attacker most likely use to reach what we care most about protecting?"
What tools serve prioritisation: Threat intelligence platforms. Attack path analysis tools that model how vulnerabilities chain together toward critical assets. Risk-based vulnerability management platforms that incorporate business context into prioritisation scoring.
Validation is where CTEM becomes fundamentally different from traditional vulnerability management, and where the gap between how most organisations implement this stage and how they should implement it is widest.
Validation answers the question: "We believe we are exposed to this risk. Are we actually exposed? Would a real attacker be able to exploit this?"
Traditional vulnerability management skips this step. It identifies potential vulnerabilities and moves directly to remediation. CTEM requires confirming exploitability before reporting exposure as validated risk.
Why validation matters:
A vulnerability scanner reports that a web application may have SQL injection in a login form. Is this vulnerability actually exploitable? Does the input reach a database query without sanitisation? Can it be exploited to extract data, modify records, or escalate privileges? Without validation, the finding is a potential risk that requires developer time to investigate before remediation can begin. With validation, the finding is a confirmed exploitable vulnerability with demonstrated business impact: the developer knows what to fix and why it matters.
Validation is also the stage where compensating controls are tested. The organisation may believe that WAF rules prevent SQL injection against the login form. Validation tests whether that belief is accurate. Compensating controls that are configured but not validated are security theatre, not security.
The three validation mechanisms:
Breach and Attack Simulation (BAS) tests whether defensive controls detect and block known attack techniques. BAS validates the detection layer: would this attack be caught by our SIEM and EDR? It does not validate whether the application itself is exploitable: it validates whether the detection controls work.
Point-in-time penetration testing provides deep validation through expert human testing, confirming exploitability with proof-of-exploitation evidence. Its limitation is cadence: annual or quarterly engagements create long windows between validations, during which the environment changes significantly.
Agentic continuous penetration testing is the validation mechanism that addresses the cadence limitation while maintaining the depth of expert testing. Agentic systems conduct the reasoning work of penetration testing continuously, triggered by deployment events, covering the full defined scope on every cycle. Agentic pentesting and continuous security validation covers the architecture in depth.
What tools serve validation: BAS platforms for defensive control validation. Agentic continuous penetration testing platforms for application-layer exploitability validation. Human-led penetration testing for deep validation of complex attack paths, compliance evidence, and scenarios requiring domain-specific expertise.
Mobilisation is the stage where CTEM findings translate into remediation action, and the stage most often treated as a downstream appendage rather than an integral part of the programme.
Effective mobilisation requires more than delivering a findings list. It requires: clear ownership assignment for each finding, SLA-based prioritisation that reflects the business risk of the finding, evidence that remediation actually resolved the vulnerability (retest confirmation rather than mark-as-closed), and feedback into the prioritisation stage to confirm that the exposure is resolved.
The evidence standard: Mobilisation requires evidence that a finding has been remediated: not just that the remediation action was taken. was taken. A WAF rule added to block SQL injection should be validated against the original exploit path to confirm the rule actually closes the vulnerability. A library updated to patch a CVE should be confirmed not to have introduced new vulnerabilities in the process.
What's in a penetration testing report: a buyer's breakdown covers the evidence standard for individual findings. For CTEM mobilisation, the same standard applies at the programme level: each finding in the CTEM cycle requires remediation evidence before the cycle is considered complete.
What tools serve mobilisation: Issue tracking integration (Jira, ServiceNow, GitHub Issues) to route findings into engineering workflows. Remediation tracking in the validation platform that records finding status, owner, and retest results. Security metrics dashboards that report on mean time to remediate by severity and trend over time.
The five-stage mapping clarifies precisely where agentic continuous pentesting sits within the CTEM programme, and why it is the validation mechanism most aligned with CTEM's design intent.
CTEM requires continuous validation. The framework's name is explicit: continuous threat exposure management. The validation stage is not an annual event: it is a continuous process that keeps pace with the rate at which the environment changes. Continuous penetration testing and how it differs from annual pentests covers the cadence comparison in detail. Annual or quarterly point-in-time testing creates windows measured in months during which new exposures are discovered and prioritised but not validated. Agentic continuous testing compresses this window to hours.
CTEM requires confirmed exploitability, not potential risk. The CTEM framework specifically distinguishes between discovered vulnerability (the output of discovery and prioritisation) and validated exposure (the output of validation). Validation requires confirming that discovered vulnerabilities are actually exploitable. Agentic penetration testing produces confirmed exploitable findings with proof-of-exploitation evidence: the same standard as expert human penetration testing. The security gaps DAST and standard testing misses covers why scanner-based tools cannot provide this confirmation.
CTEM requires coverage of the full attack surface. The discovery stage identifies the full attack surface including unknown assets. The validation stage must cover the same surface, but point-in-time penetration testing engagements are scoped to a defined subset of assets. Agentic continuous testing covers the defined scope on every run, and can be configured to include newly discovered assets from the EASM/CAASM discovery layer automatically.
CTEM requires remediation validation. The mobilisation stage requires retest evidence that remediation was effective. Agentic continuous testing provides automatic retest on every deployment, confirming that fixes held and that remediation did not introduce new vulnerabilities. AI in penetration testing: how automation is changing security testing covers how automation changes the remediation feedback loop.
A complete CTEM implementation requires tools across each stage. The map below shows where different technology categories serve each stage:
| CTEM Stage | Primary Technology | Examples |
|---|---|---|
| Scoping | Threat intelligence, business risk frameworks | TI platforms, security leadership input |
| Discovery | EASM, CAASM, CSPM | ASM platforms, cloud security tools |
| Prioritisation | Risk-based VM, attack path analysis | RBVM platforms, exposure prioritisation |
| Validation | Agentic pentesting, BAS, manual pentest | 10x Pentest, BAS platforms, human-led testing |
| Mobilisation | Issue tracking, remediation workflow | Jira, ServiceNow, security dashboards |
The validation stage is where most CTEM implementations are weakest. Organisations that have invested in EASM for discovery and RBVM for prioritisation frequently reach validation with either BAS (which validates the detection layer, not application exploitability) or periodic manual penetration testing (which validates at insufficient cadence).
Agentic continuous pentesting fills the gap: continuous, deployment-triggered, exploit-confirmed validation of application-layer exposure that keeps pace with both the discovery layer's new findings and the development team's deployment cadence.
The distinction that security leaders most frequently ask about is how CTEM relates to existing vulnerability management programmes.
Vulnerability management identifies CVEs in known assets, scores them by CVSS, and tracks remediation against SLAs. It answers: what CVEs exist in my environment?
CTEM discovers the full attack surface including unknown assets, validates which exposures are actually exploitable in context, and prioritises based on real-world attacker behaviour rather than base CVSS scores. It answers: what can an attacker actually exploit against us right now?
CTEM is not a replacement for vulnerability management: it is an elevation of the programme's objective. Vulnerability management data feeds the discovery and prioritisation stages. CTEM extends beyond it into validation and mobilisation with confirmed exploitability rather than theoretical risk.
The attack surface management companion post covers where ASM sits in this stack, and agentic AI security covers the AI layer that enables continuous validation at the required scale.
A mature CTEM programme is not built overnight. It develops across several phases:
Phase 1: Discovery foundation. Deploy EASM and CAASM tooling to establish continuous asset discovery. Integrate threat intelligence for scoping. The objective is: always know what your full attack surface is.
Phase 2: Prioritisation improvement. Move from CVSS-based prioritisation to attack path-informed prioritisation. Incorporate threat intelligence into finding ranking. The objective is: fix what matters most first, not what scores highest in the scanner.
Phase 3: Validation capability. Introduce continuous validation through agentic penetration testing and BAS. The objective is: confirm that prioritised exposures are actually exploitable, and confirm that remediations held.
Phase 4: Mobilisation integration. Integrate validation findings into engineering workflows with automated routing, owner assignment, and retest triggering. The objective is: reduce mean time to remediation by making remediation workflow frictionless.
Phase 5: Full cycle continuity. All five stages operate continuously and feed each other. New assets discovered in Stage 2 are automatically scoped into Stage 3 prioritisation and Stage 4 validation. Remediated findings in Stage 5 trigger automatic retest in Stage 4.
For penetration testing services in the US as the validation stage for organisations building CTEM programmes, agentic penetration testing for the continuous validation layer that keeps pace with CTEM's continuous cycle, and PTaaS for the deployment-triggered model, the 10x Pentest platform covers the validation stage. See pricing or get in touch to discuss how continuous agentic testing fits into your CTEM programme.
Q1. What is Continuous Threat Exposure Management (CTEM)?
CTEM is a five-stage security programme framework introduced by Gartner in 2022 that moves organisations from periodic vulnerability management to continuous exposure validation. The five stages are: scoping (defining what surfaces to evaluate based on attacker targeting and business risk), discovery (finding all assets in scope including unknown and unmanaged assets), prioritisation (ranking exposures based on real-world exploitability and business impact rather than CVSS scores alone), validation (confirming which exposures are actually exploitable through penetration testing and breach simulation), and mobilisation (translating validated findings into remediation actions with tracking and retest evidence). CTEM's defining characteristic is the shift from "what vulnerabilities do we have?" to "what can an attacker actually exploit against us right now?"
Q2. How does agentic penetration testing fit into CTEM?
Agentic continuous penetration testing is the validation mechanism for the CTEM validation stage. The validation stage requires confirming which discovered and prioritised exposures are actually exploitable (not just potentially vulnerable) and requires this confirmation to run continuously to match CTEM's continuous cycle. Agentic penetration testing conducts the reasoning work of expert penetration testing continuously, triggered by deployment events, covering the full defined scope on each run, and producing exploit-confirmed findings with proof-of-exploitation evidence. This provides the continuous, deployment-triggered, exploit-confirmed validation that annual or quarterly point-in-time penetration testing cannot match.
Q3. What is the difference between CTEM and vulnerability management?
Traditional vulnerability management identifies CVEs in known assets, scores them using CVSS, and tracks remediation against SLAs. CTEM extends this in three ways: discovery is expanded to include unknown and unmanaged assets beyond the formal inventory; prioritisation incorporates real-world attacker behaviour and business impact rather than relying solely on CVSS base scores; and validation confirms actual exploitability through active testing rather than accepting potential risk as reported risk. CTEM is not a replacement for vulnerability management: it is an elevation of the programme objective that incorporates VM data as input to a broader continuous cycle.
Q4. What is the CTEM validation stage and what tools serve it?
The validation stage is where CTEM programmes confirm that discovered and prioritised exposures are actually exploitable in the organisation's specific environment. Three tool categories serve validation: breach and attack simulation (BAS) platforms validate whether defensive controls detect and block known attack techniques; point-in-time penetration testing provides deep expert validation with confirmed exploitability evidence but at insufficient cadence for CTEM's continuous cycle; and agentic continuous penetration testing platforms provide deployment-triggered validation with expert-level depth across the full application attack surface continuously. The validation gap in most CTEM implementations is the absence of continuous application-layer exploitation validation: most programmes use BAS for detection validation and point-in-time testing for application validation, leaving long windows of unvalidated application exposure between testing cycles.
Q5. How does CTEM relate to EASM and ASM?
External Attack Surface Management (EASM) and Cyber Asset Attack Surface Management (CAASM) are the primary tools for CTEM's discovery stage. EASM discovers all internet-facing assets including those not in the formal inventory, continuously monitoring for new assets and configuration changes. CAASM normalises asset data from multiple internal sources into a unified inventory. Both feed the discovery stage with comprehensive, continuously updated asset information that vulnerability management scanners operating only against the known inventory cannot provide. CTEM uses ASM discovery data as input to prioritisation (which assets should be prioritised for validation?) and validation (what is the full scope that needs to be validated continuously?).
Cyber insurers now require penetration testing as a condition of coverage but not every pentest satisfies underwriting requirements. This guide maps what underwriters actually review and why it matters.
Tejas Dhokane Sep 9, 2026 
An AI agent conducting penetration testing has credentials, tool access, and exploit capabilities. These raise legitimate security questions. This guide maps five risk categories and the design controls that address each.
Tejas Dhokane Sep 8, 2026 
Most "automated penetration testing" is scripted scanning with a different label. This guide maps the full automation spectrum scanners, DAST, BAS, and agentic testing and what each actually does.
Tejas Dhokane Sep 8, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
