CTEM Framework: Understanding the 5 Stages of Continuous Threat Exposure Management

Most security programs do not fail because they cannot find weaknesses. They fail because they find far more than they can ever fix. A modern environment produces tens of thousands of new vulnerabilities a year, on top of misconfigurations and identity weaknesses no CVE feed counts, and only a small fraction is ever exploited. The bottleneck is no longer discovery. It is deciding which exposures actually matter and acting on those before an attacker does.

The CTEM framework is a structured answer to that problem. Continuous Threat Exposure Management is a five-stage program, introduced by Gartner in 2022, for continuously identifying, prioritizing, validating, and remediating the exposures across an organization’s attack surface that pose real risk. This post explains what the framework is, why it was developed, the principles that set it apart, and each of the five stages, scoping through mobilization.

What is the CTEM framework?

The CTEM framework is an operating model for managing cyber risk continuously rather than in periodic snapshots. Gartner defines it as a program built from five stages, scoping, discovery, prioritization, validation, and mobilization, that an organization runs on a repeating cycle to keep its security posture aligned with the exposures that threaten the business. The output is a prioritized, validated, and actionable plan that system owners can execute, not a list of findings.

Two clarifications matter. First, CTEM is a framework and a program, not a product. No single tool is CTEM; the program orchestrates capabilities that mostly already exist in a security stack, including attack surface management, vulnerability scanning, breach and attack simulation, penetration testing, and identity and cloud posture analysis.

Second, an exposure is broader than a vulnerability. A vulnerability is typically a known software flaw with a CVE identifier; an exposure is anything that gives an attacker a foothold or a path: an unpatched CVE, but also a misconfigured storage bucket, an over-privileged service account, an exposed management interface, a forgotten internet-facing host, or a chain of minor issues that together reach something important. CTEM is deliberately scoped to exposures in this wider sense, because attackers are not limited to what a vulnerability scanner reports.

Why the CTEM framework was developed

CTEM emerged as a response to the widening gap between how much security teams can find and how much they can fix. In 2024, more than 40,000 CVEs were published, roughly 108 a day and a 38 percent increase over the prior year (CVE counts per the CVE Program / CVE.org, 2024). No team patches at that rate, and the CVE feed is only part of the exposure picture, so what to fix first is the decision that determines risk, not the scanning that produces the backlog.

Traditional vulnerability management handles that decision poorly, because several of its assumptions no longer hold:

Point-in-time assessment goes stale. A quarterly scan or an annual penetration test describes the environment as it was on the day it ran. Cloud resources, identities, and configurations change daily, so a snapshot is out of date almost immediately, and the gaps between assessments are exactly when drift accumulates unseen.

Raw severity is a weak proxy for risk. Prioritizing by CVSS base score treats every high-severity CVE as equally urgent, regardless of whether it is exploitable here or sits on a reachable asset. A critical CVE on an isolated internal host can matter less than a medium one on an internet-facing system next to sensitive data.

The attack surface has outgrown the model. Vulnerability management grew up around managed endpoints and servers. The surface that now needs covering includes multi-cloud infrastructure, SaaS, identities and their permissions, and short-lived workloads, where the relevant exposures are often misconfigurations and access relationships rather than CVEs.

Gartner introduced CTEM in the 2022 report “Implement a Continuous Threat Exposure Management Program” to close this gap by making exposure reduction continuous, business-aligned, and evidence-driven. The report also carried a widely cited prediction: that by 2026, organizations prioritizing security investments based on a CTEM program would be three times less likely to suffer a breach. That was a forward-looking estimate made in 2022, not a measured result, and no independent study has yet validated it; it states the framework’s intent rather than proving its outcome. The durable point is the reframing, from finding every weakness to continuously reducing the exposures that are actually exploitable and impactful.

Core principles of the CTEM framework

A few principles run through every stage and draw the clearest line between CTEM and the periodic vulnerability management it is meant to replace.

Continuous, not periodic. CTEM is a loop that runs on an ongoing cadence, not a project that completes, treating exposure management as a standing operational function rather than a recurring audit.

Business- and scope-aligned. CTEM starts from what matters to the organization, not from what is easy to scan. Each cycle is bounded by a scope tied to business-critical assets, so effort concentrates where a compromise would hurt most.

Exposure-centric, beyond CVEs. The unit of work is the exposure, including misconfigurations, identity and access weaknesses, exposed assets, and attack paths, not only cataloged vulnerabilities.

Validation-driven. CTEM does not assume a finding is dangerous because a scanner flagged it; it seeks evidence that an exposure is genuinely exploitable and reachable in this environment before treating it as urgent.

Mobilization-oriented. The program ends in coordinated action, not a report. A cycle is complete only when validated exposures have been routed to the owners who can fix them and the remediation has actually moved.

Together these point at one idea: security effort should follow exploitability and business impact, continuously. Each of the five stages turns that idea into a repeatable process.

How the CTEM framework works

CTEM works as a closed loop in which each stage consumes the output of the one before it and feeds the one after. The stages are not run in parallel; they are an ordered sequence that turns a broad scope into a small set of validated, owned, and remediated exposures, then begins again.

The flow is straightforward. Scoping sets the boundary, deciding which assets and surfaces a cycle covers. Discovery works inside that boundary to inventory assets and surface their exposures. Prioritization ranks those exposures by exploitability and business impact, turning a long list of findings into a short list of what matters. Validation tests that short list against reality, confirming which exposures are actually exploitable and which are not. Mobilization drives remediation across the teams that own the affected systems. The results of a cycle then inform the scope of the next, and the value compounds as the loop repeats, each iteration correcting for the drift since the last.

Understanding the continuous nature of CTEM

The word continuous is the load-bearing part of the name, and it is worth separating from the marketing sense of “always on.” In CTEM, continuous means the loop reruns on a cadence fast enough that its output reflects the current state of the environment rather than a past one. It has to, because an attack surface is not static: new assets appear, CVEs are disclosed daily, configurations drift, permissions are granted and never revoked, and code ships. Any of these can open an exposure between one assessment and the next.

This is the specific failure mode of point-in-time security. A scan or a penetration test captures the environment on the day it ran, and from that day its picture decays; by the time a quarterly assessment is reviewed, what it described has already moved. CTEM shrinks that decay window by rerunning its loop frequently, so prioritization and validation work against what is true now, not last quarter.

Continuous need not mean fully automated or literally constant, and most programs do not start there. Early-stage CTEM often runs the loop on a defined cadence for a defined scope, then increases frequency and automation as the program and its tooling mature. The goal is not real time for its own sake; it is keeping the gap between assessments small enough that the view of risk stays current, which is what distinguishes CTEM from the annual audit and quarterly pen test it supplements.

Overview of the five CTEM framework stages

The sections below take each of the five stages in turn, including what it produces and how it feeds the next.

Stage 1: scoping (defining the scope of a CTEM program)

Scoping defines the boundary of a cycle: which assets, systems, and attack surfaces are included, and which are not. The defining choice is that scope is set by business impact, not by what is easy to scan. A scope is most useful when drawn around something the organization actually cares about protecting, an external attack surface, a crown-jewel application and its infrastructure, a business unit, or the systems under a particular compliance regime, rather than around the entire estate at once.

Starting narrow is a feature, not a limitation. A focused first scope keeps the program tractable and produces a credible result before expanding, whereas scoping everything equally recreates the boil-the-ocean problem CTEM is meant to solve. Scope widens across later cycles. Scoping also forces a question traditional vulnerability management often skips: what would actually hurt if it were compromised. Answering it well is what makes everything downstream, especially prioritization, meaningful.

Stage 2: discovery (identifying exposures across the environment)

Discovery works inside the defined scope to inventory assets and identify their exposures. It is broader than a vulnerability scan: alongside known CVEs, it looks for misconfigurations, exposed and internet-facing services, identity and permission weaknesses, unmanaged or shadow assets, and the relationships between assets that an attacker could use. The aim is an accurate picture of what exists in scope and how it could be reached.

A common mistake is to treat discovery as the main event and equate a high finding count with a thorough program. The opposite is true. Discovery feeds prioritization rather than substituting for it, and a process that surfaces ten thousand exposures with no way to tell which fifty matter has simply moved the bottleneck downstream. Depth of context matters more than raw volume: knowing that an exposed host holds sensitive data, or that a vulnerable service is reachable from the internet, is what lets the next stage rank by real risk rather than severity alone.

Stage 3: prioritization (determining which exposures matter most)

Prioritization is the stage that gives CTEM its purpose. Discovery produces more exposures than any team can address, and prioritization decides which get attention first, judged by real-world exploitability and business impact rather than raw severity. This is the explicit break from CVSS-base-score triage: the same vulnerability can be urgent on one asset and irrelevant on another.

Several inputs feed the ranking. Exploitability asks whether a weakness can actually be exploited, drawing on signals like EPSS (the Exploit Prediction Scoring System), known-exploited-vulnerability catalogs, and threat intelligence on active campaigns. Business context weights an exposure by the value and sensitivity of the asset it sits on, so issues touching critical systems or regulated data rise above issues on disposable infrastructure. Compensating controls lower the priority of exposures an attacker could not practically reach. The result is a ranking in which a medium-severity issue on a reachable, critical asset can correctly outrank a critical CVE on an isolated one.

The deepest version of prioritization stops ranking exposures one at a time and reasons about attack paths. A core idea of the prioritization stage is to think in attack paths, not individual vulnerabilities, because attackers chain exposures: an exposed asset leads to a host, a vulnerability yields credentials, an over-privileged identity extends reach, and several unremarkable steps combine into a route to something critical. Ranking each exposure in isolation misses these chains.

Reasoning about paths is where prioritization becomes a relationship problem, and that is what makes it hard in practice. The exposures that form a path rarely live in one tool: the exposed asset is known to an attack surface management product, the host vulnerability to a scanner, the identity weakness to an identity provider, the network reachability to cloud configuration. Modeling those relationships as a graph, with assets, vulnerabilities, identities, and permissions as nodes and the connections between them as edges, makes the chains explicit, and finding the paths that reach what matters becomes a query rather than a manual cross-referencing exercise. Where that graph can be queried over the tables a security stack already populates, rather than rebuilt in a separate database, the path analysis stays close to the same data the rest of the program produces.

Stage 4: validation (verifying real-world exploitability)

Validation tests the prioritized exposures against reality before any effort is spent fixing them. Prioritization produces a ranked hypothesis of what matters; validation checks whether each high-priority exposure is genuinely exploitable and reachable here, and whether existing controls would stop an attacker who tried. The aim is to cut the list to what is provably exploitable, so mobilization spends remediation effort on real risk, not theoretical findings.

The methods produce evidence rather than assumptions. Breach and attack simulation runs automated, safe emulations of attacker techniques to test whether an exposure can be exploited and whether controls detect or block it. Penetration testing and red teaming apply human expertise to confirm exploitability and find paths automated tools miss. Attack-path validation checks that a theorized chain connects end to end and genuinely reaches the critical asset it appeared to threaten. The question throughout is not whether an exposure exists but whether it can be exploited here.

Validation routinely changes the priority order, which is its real value. A high-ranked exposure that turns out to be blocked by a control or unreachable in practice drops down or off the list, freeing effort for exposures validation confirms are live. The program then works from a shorter set of confirmed, exploitable exposures rather than suspected ones.

Stage 5: mobilization (operationalizing remediation)

Mobilization turns validated findings into fixed problems. It is the stage CTEM adds that traditional vulnerability management usually lacks, and it is organizational as much as technical: the work is getting the right teams to act on the right exposures, with clear ownership, defined workflows, and agreed expectations for how quickly things resolve. A validated list that no one acts on has not reduced any risk.

The friction mobilization removes is mostly process. Remediation usually depends on teams outside security, the infrastructure, application, cloud, and identity owners who can actually change the affected systems, so mobilization establishes the routing and accountability that move a validated exposure to the owner who can fix it: assigning ownership, integrating with the ticketing systems those teams already use, setting remediation SLAs by priority, and tracking that fixes land. Some of this can be automated, but Gartner is explicit that mobilization is not purely an automation problem; it is about reducing the human and procedural friction that stalls remediation.

Mobilization also closes the loop. The outcomes of a cycle, what was remediated, what was accepted as residual risk, what new assets surfaced, feed back into the scoping of the next, so each iteration starts from a more accurate picture than the last rather than as a disconnected assessment.

CTEM framework examples

A concrete example shows how the stages change the outcome. Consider an internet-facing web application on a cloud workload. Scoping places it in scope because it processes customer data. Discovery finds a medium-severity vulnerability on the host, a storage bucket with an overly permissive policy, and a service account with broad privileges into the data tier. Prioritization in isolation might rank the medium CVE unremarkably, but reading the relationships sees a path: the internet-facing host, the vulnerability that yields a foothold, the over-privileged account, and a reachable route to sensitive data. Validation runs a breach and attack simulation that confirms the path connects end to end with no control blocking it, elevating three moderate issues into one critical, exploitable chain. Mobilization routes the most efficient fix, tightening the service-account permissions to break the path, to the cloud team with an SLA matched to its confirmed severity.

Under raw-severity vulnerability management the same findings fare differently. The medium CVE sits in a backlog behind dozens of “critical” findings, the bucket policy and the account privileges are tracked by different tools and never connected, and the chain that threatens customer data is never seen as a chain. CTEM did not find more; it found the same things and understood how they combined. The inverse also holds: a critical CVE that tops a CVSS-ordered list may, on validation, prove unreachable and segmented off, so CTEM correctly drops it and spends the freed effort elsewhere.

Conclusion

The CTEM framework reframes security from finding every weakness to continuously reducing the exposures that are actually exploitable and impactful. Its five stages, scoping, discovery, prioritization, validation, and mobilization, form a loop that turns an unmanageable backlog into a small set of validated, owned, and remediated risks, then runs again as the environment changes. The framework’s hardest work is rarely the scanning; it is connecting signals that live in separate tools into the attack paths that prioritization and validation depend on, and getting the resulting fixes to the people who can make them.

That connecting step is a graph problem, and it is where a graph query engine fits. PuppyGraph defines a graph schema over the asset, vulnerability, identity, and configuration data that already sits in a warehouse, lakehouse, or open table format like Apache Iceberg, and queries those tables in place as a graph, with no ingestion into a separate graph store. A team writes openCypher or Gremlin queries to traverse the multi-hop paths prioritization and validation depend on, over the same tables its existing security tools already populate, rather than exporting everything into a dedicated graph database and keeping that copy in sync. PuppyGraph does not discover or scan exposures itself; it connects the ones the rest of the program produces into the paths an attacker would walk. It is used in security programs at companies including Palo Alto Networks, Datadog, Netskope, and Trend Micro.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, to reconstruct the attack paths a CTEM program prioritizes and validates against.