CTEM: the five stages explained

Continuous threat exposure management, or CTEM, has moved in three years from analysts' vocabulary to the requirements of security leaders. The term is often reduced to "vulnerability management, but better". That is a misreading: CTEM is a cycle of five stages, two of which, scoping and validation, do not exist in a classic patching program.

What the sources say

The SANS Institute, in a white paper by Jonathan Risto published on July 16, 2024, sets the frame: "CTEM is built on five core process steps: scoping, discovery, prioritization, validation, and mobilization". The same document specifies that CTEM does not replace attack surface management but builds on and expands it, and that it "succeeds only when treated as an ongoing organizational discipline rather than a one-time deployment or a product purchase".

A year later, on July 22, 2025, the same author publishes at SANS a maturity model that describes each stage. Scoping consists of "understand[ing] business context, threat landscape, and regulatory environment". Discovery identifies "internal and external assets, exposures, misconfigurations, and third-party risks". Prioritization "map[s] exposures to business impact, attack paths, threat actors, and exploitability". Validation "test[s] controls, validate[s] remediation, simulate[s] attacks, and inform[s] detection". The model reminds us that CTEM "isn't just about scanning more often or shifting remediation left".

The Cloud Security Alliance, in a post dated May 24, 2024, describes mobilization as the stage where remediation tasks are assigned and resources allocated, in collaboration between IT, security and business teams. It cites Gartner's prediction that, by 2026, organizations that prioritize their security investments based on a CTEM program would be three times less likely to suffer a breach. The post also underlines what CTEM integrates: automated penetration testing, breach simulation, external attack surface management and vulnerability management, previously handled separately.

Finally, CTEM.org presents itself as an open standard: a public, version-controlled catalog of numbered identifiers to label exposures, defined as anything that puts data, identity or infrastructure at risk.

Why it matters

A vulnerability management program starts from the scanner and works upward toward the business; it almost never gets there. CTEM starts from the business and works downward toward the patches. That inversion changes three things.

Scoping limits the perimeter to what matters. Instead of treating the whole estate, the cycle starts with the assets whose compromise would hurt: the systems that carry revenue, regulated data, the accesses of critical suppliers.

Discovery goes beyond CVEs. A non-human identity with no owner, an open storage bucket, a supplier access never revoked are exposures just like a software vulnerability, and often easier to exploit.

Validation turns a list into proof. Before mobilization, you verify that the attack path exists and that the controls in place do not stop it. That is what lets you ask an operations team for a fix without being told "theoretical".

For ISO 27001, the cycle feeds directly into the risk assessment (clause 6.1.2) and control 8.8; for NIS2, it documents the risk management measures that article 21 requires.

What we think at Sentrix

The CTEM module of our platform follows these five stages, and our experience is that organizations almost always get stuck at the first and the fourth. In order:

1. Scope on one page: ten assets or processes whose loss would be serious, with a business owner for each. Without that document, the cycle becomes a scan again.
2. Discover from every source: scanner, cloud inventory, identity directory, supplier register, results of the last penetration test. An exposure with no attached asset goes back to step 1.
3. Prioritize with a written rule that combines business impact, exposure and exploitability, for instance the KEV catalog and EPSS for the software part.
4. Validate the top ten exposures with a targeted test rather than a general report: a reproduced attack path is worth more than a score.
5. Mobilize with an owner and a date per exposure, in the ticketing tool of the teams that fix things, not in a security spreadsheet.
6. Start again on a fixed date and measure one thing only: the delay between discovery and closure of validated exposures.

The next step

If your current program starts with the scanner, write the scoping page first. It takes one meeting with the business owners and it changes the order of everything that follows. Talk to us about your first cycle if you want an outside look at that scoping.