What is CTEM (Continuous Threat Exposure Management)?

1. Scoping — define the slice of the attack surface in focus this cycle. External-facing assets, a critical business unit, a recently merged subsidiary, an AI pipeline, the SaaS edge — scope is business-driven, not asset-driven.

2. Discovery — enumerate everything in scope: hosts, services, identities, secrets, third-party connections, data flows. Modern discovery includes shadow IT, ephemeral cloud workloads, and SaaS-to-SaaS OAuth grants that classical asset inventories miss.

3. Prioritization — rank exposures by *exploitability in your environment*, not by isolated CVSS. A CVSS 9.8 behind two layers of segmentation and an MFA wall is lower priority than a CVSS 6.5 reachable from the internet by an unauthenticated endpoint.

4. Validation — prove the finding is exploitable. This is the stage tool-chain decisions live or die on: a vulnerability scanner produces a list, an automated red-team / Breach and Attack Simulation (BAS) / generative pentest produces evidence. Boards and regulators ask for the second.

5. Mobilization — convert validated findings into tracked, time-boxed remediation. Ticket creation, SLO definition, retest gating, and closure with cryptographic evidence are all in scope. A program that stops at "we found these" is not a CTEM program.

Classical vulnerability management produces a finding list ranked by CVSS. Classical pentesting produces a point-in-time report. CTEM produces a continuously updated exposure ledger with proof-of-exploitability per item and a measurable downward trend.

The practical procurement consequence: a CISO presenting "we paid €40k for a pentest in March" no longer satisfies a board that has read the 2025 EBA RTS or Gartner CTEM guidance. The board now expects a quarterly exposure-reduction chart with signed evidence behind each closed item. CTEM is the operational model that produces that chart by construction.

The other practical shift is the validation gate. A vulnerability scanner can claim 10,000 issues; without validation, most of them are noise. A board asked to fund 10,000 fixes will fund none. A board shown 47 *validated exploitable* exposures will fund the program — and the operational data backs this in published incident-cost studies through 2025.

NIS2 — Art. 21 requires "appropriate and proportionate" technical and organisational measures, with continuous testing implicit. National transpositions (notably Italy's Decreto Legislativo 138/2024) attach personal liability to top management for ensuring effectiveness — not paper-existence — of controls. CTEM's exposure-trend metric is the operational reporting unit boards actually need.

DORA Art. 25 — explicitly requires continuous testing of critical ICT systems for significant financial entities. The EBA RTS 2025 makes it clear: "continuous" means continuous, informed by current threat intelligence. CTEM's scoping + discovery + validation loop is the reference implementation; TLPT is the formal exercise that confirms the loop is working.

AI Act — Art. 72 post-market monitoring for high-risk AI systems requires continuous tracking of performance and incident exposure. Where the AI system itself is a security tool, CTEM applies recursively: the tool must be continuously validated, just like the assets it monitors.

In all three regimes, the auditable artefact is the same: a signed, time-stamped exposure-reduction ledger covering the regulator-required period. Programs that ship this as a byproduct of normal operation pass internal audit on first attempt; programs that assemble it manually at audit time fail.

A practical starting model used by the operators we work with:

• Days 1–14 — scoping. Pick one business-critical slice. External attack surface for an SMB; a single regulated business unit for a larger org. Define the metric (exposure count, weighted by exploitability and business impact) and the cadence (weekly or fortnightly discovery, monthly review).
• Days 15–30 — discovery + baseline. Run an automated continuous discovery against the scope; produce the first baseline exposure ledger. Expect to be surprised — most first-baseline runs uncover assets the asset inventory did not list.
• Days 31–60 — validation cycle 1. Pick the top 50 prioritized exposures; validate each (BAS, generative pentest agents, manual where required). Most will not be exploitable in the real environment; the ones that are become the first remediation batch with a signed proof-of-exploit artefact attached.
• Days 61–90 — mobilization + first board readout. Tickets for validated items; SLOs by severity; retest gating; first signed exposure-reduction chart. Present this to the board as the new operating cadence and retire the annual-pentest line item from next year's budget.

The trap most programs fall into: trying to start with full scope. Scope a single slice, prove the loop closes, then expand. Programs that try to boil the ocean stall at the discovery stage and never reach validation, producing nothing the board can use.