Continuous Threat Exposure Management (CTEM)
the five-stage exposure programme, run on one record
CTEM is the programme model Gartner uses to describe how mature security organisations move from a backlog of vulnerabilities to a continuous, business-aligned exposure reduction programme. This page covers the five stages (Scoping, Discovery, Prioritisation, Validation, Mobilisation), how CTEM differs from risk-based vulnerability management, attack surface management, and threat and vulnerability management, the operating cadence, the evidence pack a CTEM cycle keeps, and how a workspace-driven approach turns the model into a programme rather than a slide deck.
No credit card required. Free plan available forever.
CTEM: a continuous, programme-level model for exposure reduction, not a tool category
Continuous Threat Exposure Management (CTEM) is the programme model Gartner uses to describe how mature security organisations move from a backlog of vulnerabilities to a continuous, business-aligned exposure reduction programme. CTEM is not a product category and is not a replacement for vulnerability management, attack surface management, or threat and vulnerability management. It is the cycle that sequences scope, discovery, prioritisation, validation, and mobilisation as a single programme with a defined cadence and a documented evidence trail. Where the OWASP and NIST CSF 2.0 frameworks describe what good security looks like, CTEM describes how a programme operates the work that produces it.
CTEM is most useful when an organisation needs to talk about exposure reduction in the same operational language across engineering, security, leadership, audit, and the buyer side. A statement like “our programme is risk-based” is hard to falsify. A statement like “in this cycle we scoped these four customer-facing surfaces, ran these discovery sources, prioritised the queue against EPSS and KEV, validated the top tier, and closed twelve of the eighteen prioritised exposures with two carried to next cycle” is operational. CTEM is the language that makes that operational statement possible. The vulnerability prioritisation workflow and the security leadership reporting workflow cover two of the operating pieces a CTEM cycle leans on; this page covers the framework that sequences them as a programme rather than as separate disciplines.
The five CTEM stages, in order
CTEM organises the programme into five stages that run in sequence inside a cycle and on a cadence across cycles. The five stages are the unit of operation: each carries an entry criterion, an output, an owner, and an evidence artefact. The cycle is the unit of communication: leadership cares about the cycle outcome, engineering cares about the per-stage work.
Stage 1: Scoping
Define what the cycle is responsible for and tie each in-scope surface to a business owner.
Scoping is the leadership decision that opens the cycle. The programme names the in-scope business processes, customer-facing systems, regulated data flows, third-party connections, and identity surfaces that carry material exposure for this cycle, then ties each surface to a business owner and a success criterion. Scoping is deliberately narrower than asset inventory: the goal is exposure reduction on what matters this cycle, not coverage of every asset. The output of Scoping is a documented surface list, the criticality calibration, the cycle objectives, and the cadence the cycle will run on, captured before any discovery work starts.
Stage 2: Discovery
Enumerate assets, vulnerabilities, misconfigurations, identity weaknesses, and third-party exposures inside the scoped surfaces.
Discovery enumerates the assets, vulnerabilities, misconfigurations, identity weaknesses, and third-party exposures inside the scoped surfaces. Discovery uses external scanning, authenticated scanning, code scanning, configuration review, identity review, and human-led testing in combination, because no single source covers the full surface. The discovery output is a deduplicated finding set tied to assets, owners, and the source signal that generated each item, with the coverage record captured so absence can be distinguished from non-coverage. Discovery quality is the input to every later stage; gaps in discovery propagate as gaps in prioritisation and validation, which is why Discovery carries its own coverage evidence rather than only producing a list of findings.
Stage 3: Prioritisation
Rank the discovery output by exploitability, exposure, and business impact rather than by raw severity.
Prioritisation ranks the discovery output by exploitability, exposure, and business impact rather than by raw severity. The prioritisation logic combines CVSS technical severity, EPSS exploit likelihood, CISA KEV active exploitation status, asset criticality, and the compensating controls already in place. Prioritisation converts a backlog into a queue: the first items in the queue are the exposures the team will mobilise around in this cycle, with rationale captured per item so the queue is defensible at audit and at leadership review. Prioritisation that does not record rationale becomes unfalsifiable; CTEM treats the rationale as part of the cycle artefact, not a private spreadsheet column.
Stage 4: Validation
Test whether the prioritised exposures are actually exploitable and whether the proposed remediation will close them.
Validation tests whether the prioritised exposures are actually exploitable, whether the proposed remediation closes them, and whether the compensating controls behave as claimed. Validation uses targeted manual testing, attack-path analysis, exploit reproduction, and post-remediation retesting. Validation is the stage that separates real exposures from theoretical ones, because the prioritisation queue inherits scanner false positives and severity drift unless validation re-tests the assumptions. The validation output updates the queue, the SLA, and the closure record, and the validation evidence becomes part of the cycle artefact rather than a one-off verification screenshot.
Stage 5: Mobilisation
Turn the validated queue into closure with named owners, deadlines, dependencies, and verification steps.
Mobilisation turns the validated queue into closure. The stage names the remediation owner, the deadline, the change record, the dependency, and the verification step for each exposure, and it drives the cycle of remediation, retest, and closure. Mobilisation is the stage that fails most often in immature programmes, because the previous four stages produce a strong queue but the organisation does not have the operating model to act on it. CTEM treats Mobilisation as a first-class stage rather than an implicit follow-on, which is what separates an exposure programme from a backlog of unactioned scanner output.
For programmes whose Discovery already runs authenticated scanning and code scanning, the authenticated scanning and code scanning features feed the same engagement record that carries the cycle queue, so Discovery output and Mobilisation closure read from one source rather than two.
How CTEM relates to RBVM, ASM, TVM, and vulnerability scanning
CTEM is rarely the first discipline a programme adopts. It is the programme layer that sequences disciplines the organisation already runs (or is in the process of building) into a single operating story. The contrast below is a working view, not a buying decision: the practitioner question is which CTEM stage each adjacent discipline contributes to, not which discipline replaces CTEM.
CTEM vs RBVM (Risk-Based Vulnerability Management)
RBVM is the prioritisation discipline that ranks vulnerabilities by exploitability and business impact rather than by raw severity. CTEM uses RBVM logic inside its Prioritisation stage, but CTEM is a wider programme model: it adds Scoping (so the cycle has a defined surface), Validation (so the queue is real rather than theoretical), and Mobilisation (so the queue closes rather than ages). RBVM answers what to fix first; CTEM answers how the programme runs on a continuous cadence and what evidence the cycle leaves behind.
CTEM vs ASM (Attack Surface Management)
ASM is the discipline that enumerates internet-facing assets, exposures, and shadow systems on a continuous basis. CTEM uses ASM output as part of its Discovery stage, but CTEM is broader: Discovery in CTEM also pulls authenticated scanning, code scanning, identity review, configuration review, and human-led testing, then carries the deduplicated finding set forward into Prioritisation, Validation, and Mobilisation. ASM produces the surface; CTEM produces the cycle that acts on the surface.
CTEM vs TVM (Threat and Vulnerability Management)
TVM is the operational discipline that intakes vulnerability findings, triages them, drives remediation, and reports closure. CTEM uses TVM mechanics inside Mobilisation, but CTEM frames the work as a cycle with a defined scope, a defined cadence, a validation step, and a cycle evidence pack rather than as a continuous queue. A mature TVM operation is the foundation a CTEM programme builds on; CTEM does not replace TVM, it sequences it inside a programme story leadership can read.
CTEM vs vulnerability scanning
Vulnerability scanning is a tool category that produces findings. CTEM is a programme model that consumes findings (alongside other discovery sources), validates them, and closes them on a cadence. A scanner that runs continuously is a discovery input to CTEM, not a substitute for the framework. Programmes that conflate scanning cadence with CTEM cadence end up with high-volume scan output and low-volume exposure reduction, which is the failure mode the framework is designed to prevent.
For the prioritisation logic CTEM uses inside Stage 3, the vulnerability prioritisation framework guide covers the CVSS, EPSS, KEV, and business-context combination, and the EPSS score explainer covers the exploit-likelihood signal that converts a backlog of high findings into the dozen the cycle has to address first. For an operator-focused walkthrough of the same five stages with adoption pitfalls and a phased rollout, the continuous threat exposure management explainer covers the practical operating shape of a CTEM cycle.
The continuous cadence: cycle length, checkpoints, and handover
The continuous in CTEM is the cadence, not a marketing modifier. A cycle has a defined length, scheduled checkpoints inside the cycle, and a handover that carries residual work and surface changes into the next cycle. Cadence is the property that distinguishes CTEM from a yearly assessment and is what makes the framework defensible to leadership and to auditors as an operating programme.
Cycle length
A common cadence is one CTEM cycle per scope per quarter, with weekly or bi-weekly checkpoints inside the cycle. Longer cycles allow deeper validation; shorter cycles drive faster mobilisation. The right length is the one the programme can sustain on the surface in scope, not the one a vendor deck recommends.
Checkpoint cadence
Inside the cycle, the programme runs scheduled checkpoints that read discovery progress, prioritisation calibration, validation results, and mobilisation closure. Checkpoints are the mechanism that catches a stalled cycle before the cycle closes; a cycle that only reads its outcome at the end has lost the chance to reroute.
Cycle handover
At cycle close, the residual queue, the surface change log, and the next-cycle scope candidates carry forward to the next cycle. Cycle handover is what makes CTEM continuous rather than episodic; without it, each cycle starts from a blank slate and the programme cannot defend a year-on-year trajectory.
For the operating-throughput context that calibrates a defensible cycle length, see the vulnerability remediation throughput research and the vulnerability management programme maturity model, which together cover the throughput and maturity inputs that should shape the cycle length the programme can sustain rather than the cycle length a slide deck recommends.
The CTEM evidence pack: what a defensible cycle leaves behind
A CTEM cycle is reviewable when the artefacts the cycle generated read as one record rather than as a folder of attachments. The evidence pack is what makes the cycle defensible at leadership review and at audit, and it is what lets the next cycle start from a calibrated baseline rather than from a clean spreadsheet.
- Scoping document that names the in-scope business processes, the customer-facing systems, the regulated data flows, the identity surfaces, and the business owner per surface, with the cycle objectives and the success criteria recorded before discovery starts
- Discovery coverage record that names every source that fed the cycle (external scanner, authenticated scanner, code scanner, configuration review, identity review, manual testing) and the surface coverage per source, so absence can be distinguished from non-coverage at the next cycle
- Deduplicated finding set tied to assets and owners, with each finding carrying the source signal, the CVSS vector, the EPSS reading, the KEV status where applicable, and the asset criticality calibration that drove its rank
- Prioritisation rationale recorded per queue item rather than only summarised at the cycle level, so a future review can read why a specific exposure ranked above or below another rather than reverse-engineering the logic
- Validation evidence per queue item, including reproduction notes, attack-path analysis, exploit confirmation or refutation, and the post-remediation retest result that proves closure rather than asserts it
- Mobilisation register naming the owner, the deadline, the change record, the dependency, and the verification step per exposure, with the closure trail visible for the cycle review and for audit
- Cycle closure summary covering what the cycle delivered, what carried over to the next cycle, what changed in the surface during the cycle, and what the next cycle inherits as residual queue
- Cadence record that names the cycle start, the planned checkpoints, the actual checkpoints, the cycle closure, and the input scope for the next cycle, so the programme is reviewable as a continuous operating story rather than as a one-off assessment
For the underlying findings discipline that supports Discovery deduplication and Validation evidence, see the findings management workflow and the security findings deduplication guide, which together cover the data hygiene that turns scanner output into defensible Discovery and Validation evidence.
CTEM for vulnerability management teams, AppSec teams, and security leadership
CTEM is read differently depending on which side of the cycle you sit on. Vulnerability management teams read CTEM as the programme model that sequences the work the team already owns: discovery, prioritisation, retest, closure. AppSec teams read CTEM as the model that ties code-side findings into the same cycle as infrastructure and identity findings, so the cycle scope reflects how attackers actually move rather than how internal teams are organised. Security leadership reads CTEM as the operating story that makes a residual risk number defensible: the cycle says what was scoped, what was found, what was validated, what was closed, and what was carried, on a cadence that a board committee can track. The same cycle record carries all three views.
The audience-specific entry points are SecPortal for vulnerability management teams, SecPortal for AppSec teams, SecPortal for CISOs, and SecPortal for security operations leaders. Each anchors a different reading of the same CTEM cycle record.
Where SecPortal fits in a CTEM cycle
SecPortal is the operating layer for a CTEM cycle. The platform handles Scoping (engagement scope and surface ownership), Discovery (external, authenticated, and code scanning plus manual finding intake), Prioritisation (CVSS, severity calibration, asset context), Validation (retest workflow and finding state transitions), and Mobilisation (owner, deadline, closure trail), with the cycle record carrying the artefact set. The cycle runs as one workspace record rather than as a long email thread with attached spreadsheets, which is what makes the cycle reviewable at the next iteration and at audit.
- Engagement management captures the CTEM cycle as a structured record covering the scoped surfaces, the cycle objectives, the participants, the cadence, and the closure summary, so the cycle is reproducible at the next iteration rather than reconstructed from a slide deck or shared inbox
- Findings management holds the deduplicated discovery output with each finding carrying a CVSS 3.1 vector, an owner, severity calibration, evidence, and status (open, in_progress, resolved, verified, reopened), so the cycle queue is the live record rather than a frozen export
- External scanning, authenticated scanning, and code scanning feed the Discovery stage from the same workspace; authenticated scanning runs DAST behind the login screen with credentials stored encrypted at rest, and code scanning runs SAST and SCA against connected Git repositories under an OAuth connection, so the discovery surface is not limited to an external view
- Continuous monitoring runs scheduled scans on the in-scope surfaces between cycles, so the next cycle starts with current discovery rather than discovery harvested only at cycle start; the schedule lives on the engagement and is visible in the activity log
- Activity log records the append-only trail of every change to the cycle (scope changes, finding state transitions, validation outcomes, retest results, owner reassignments), so the cycle review and any subsequent audit reads from a defensible record rather than a reconstructed narrative
- AI-assisted reports compose the cycle summary, the per-stage breakdown, the residual queue, and the recommended next-cycle scope from the underlying engagement, findings, and activity log, so the deliverable cites the live cycle rather than starting from a blank template
- Compliance tracking lets one CTEM cycle feed framework mappings to ISO 27001 Annex A.8.8 (technical vulnerability management), SOC 2 CC3.2 and CC7.1, PCI DSS Requirement 6.3.1, and NIST CSF Identify and Respond functions, so the cycle evidence pack doubles as audit evidence without rebuilding the bundle for each auditor
- Notifications and team management keep the named owner per exposure on the cycle queue with role-based access; mobilisation runs as a workflow on the same record rather than as a parallel ticketing process, with the closure trail visible to leadership and to the auditor without context switching
Looking for the operating cycle that runs the five stages end-to-end on one engagement record? The CTEM cycle workflow sequences Scoping, Discovery, Prioritisation, Validation, and Mobilisation as a single record with cycle scope, discovery coverage, prioritisation rationale, validation evidence, Mobilisation closure, and cycle handover all derived from the same engagement the team operates against. The vulnerability backlog management workflow and the scanner-to-ticket handoff governance workflow cover the Mobilisation mechanics that close the cycle, and the retesting workflow covers the Validation cadence that proves closure rather than asserts it.
For programme-level context on how exposure programmes fit into the wider security delivery operating model, see the security workflow orchestration research and the risk-based vulnerability management buyer guide, which together cover the operating-model thinking that turns CTEM stages into a sustained programme rather than a one-off slide deck.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Stage 1: Scoping
Scoping defines what the cycle is responsible for. The programme names the in-scope business processes, customer-facing systems, regulated data flows, third-party connections, and identity systems that carry material exposure for the cycle. Scoping is a leadership decision rather than a tooling decision: the output is a list of attack surfaces tied to business owners, with the criticality calibration and the success criteria documented before discovery starts. CTEM scoping is deliberately narrower than asset inventory, because the goal is exposure reduction on what matters this cycle, not coverage of every asset.
Stage 2: Discovery
Discovery enumerates the assets, vulnerabilities, misconfigurations, identity weaknesses, and third-party exposures inside the scoped surfaces. Discovery uses external scanning, authenticated scanning, code scanning, configuration review, identity review, and human-led testing in combination, because no single source covers the full surface. The discovery output is a deduplicated finding set tied to assets, owners, and the source signal. Discovery quality is the input to every later stage; gaps in discovery propagate as gaps in prioritisation and validation.
Stage 3: Prioritisation
Prioritisation ranks the discovery output by exploitability, exposure, and business impact rather than by raw severity. The prioritisation logic combines CVSS technical severity, EPSS exploit likelihood, CISA KEV active exploitation status, asset criticality, and the compensating controls already in place. Prioritisation is the stage that converts a backlog into a queue: the first items in the queue are the exposures the team is going to mobilise around in this cycle, with rationale captured per item so the queue is defensible at audit and at leadership review.
Stage 4: Validation
Validation tests whether the prioritised exposures are actually exploitable, whether the proposed remediation closes them, and whether the compensating controls behave as claimed. Validation uses targeted manual testing, attack-path analysis, exploit reproduction, and post-remediation retesting. Validation is the stage that separates real exposures from theoretical ones, because the prioritisation queue inherits scanner false positives and severity drift unless validation re-tests the assumptions. The validation output updates the queue, the SLA, and the closure record.
Stage 5: Mobilisation
Mobilisation turns the validated queue into closure. The stage names the remediation owner, the deadline, the change record, the dependency, and the verification step for each exposure, and it drives the cycle of remediation, retest, and closure. Mobilisation is the stage that fails most often in immature programmes, because the previous four stages produce a strong queue but the organisation does not have the operating model to act on it. CTEM treats mobilisation as a first-class stage rather than an implicit follow-on.
Cycle cadence and continuity
CTEM is continuous rather than annual. The cycle runs on a defined cadence (commonly quarterly per scope, with weekly or monthly progress checkpoints inside the cycle) and the next cycle inherits the residual queue from the previous one. Continuous cadence is the property that distinguishes CTEM from a yearly assessment, and it is what makes the framework defensible to leadership and auditors as an operating programme. The cadence record names the start, the checkpoints, the closure, and the input scope for the next cycle.
CTEM vs adjacent disciplines
CTEM is not a replacement for vulnerability management, attack surface management, or threat and vulnerability management; it is the programme layer that uses each. RBVM provides the prioritisation logic. ASM provides part of the discovery surface. TVM provides the operational mechanics. CTEM is the cycle that sequences scope, discovery, prioritisation, validation, and mobilisation as a single programme rather than as overlapping tools. A workspace that already runs the underlying disciplines becomes the operating layer for the CTEM cycle.
CTEM evidence pack
A defensible CTEM cycle keeps the scoped surfaces, the discovery sources and coverage record, the prioritised queue with rationale per item, the validation evidence (including reproduction notes and retest results), the mobilisation owner and SLA per exposure, and the cycle closure summary. The evidence pack is what makes the cycle reviewable at the next cycle and at audit. CTEM is a programme story; the evidence pack is the programme story written down.
Related features
Vulnerability management software that tracks every finding
Orchestrate every security engagement from start to finish
Test web apps behind the login
Find vulnerabilities before they ship
Monitor continuously catch regressions early
Every action recorded across the workspace
AI-powered reports in seconds, not days
Compliance tracking without a full GRC platform
Run a continuous CTEM cycle on one defensible record
Hold scope, discovery, prioritisation, validation, mobilisation, and the cycle evidence pack on one workspace, then re-run the cadence on the next cycle without rebuilding the bundle. Start free.
No credit card required. Free plan available forever.