Use Case

Continuous Threat Exposure Management
cycle on one record, not five disconnected disciplines

A CTEM cycle is the programme layer that bounds continuous exposure work into a defined scope, deduplicated Discovery, defensible Prioritisation, first-class Validation, and Mobilisation closure that hands residual work into the next cycle. Run the cycle on the engagement record so scope, discovery coverage, prioritisation rationale, validation evidence, and closure summary derive from the same source the team operates against, rather than from a folder of attachments and three parallel scanner extracts.

Get Started Free

No credit card required. Free plan available forever.

Run the CTEM cycle as one engagement record, not as five disconnected disciplines

Continuous Threat Exposure Management succeeds when the five stages live as a single cycle record with leadership-set scope, deduplicated discovery, defensible prioritisation rationale, first-class validation, and a closure summary that hands residual work into the next cycle. It fails when each stage runs as a separate tool, when prioritisation rationale lives in meeting notes, when validation is skipped to save time, and when Mobilisation closes outside the cycle record. Internal security teams, vulnerability management teams, AppSec teams, and security leadership all read the same cycle artefact when CTEM is run on the engagement record; they read three different views when the stages live in three different systems.

This page is the operating-cycle workflow. For the framework explanation behind the model, read the CTEM framework reference. For the prioritisation policy that runs inside Stage 3, read the vulnerability prioritisation workflow. For the threat intelligence ingest that feeds Stage 3 signals, read the threat intelligence driven prioritisation workflow. For the asset tier classification Stage 1 depends on, read the asset criticality scoring workflow. For the leadership cadence that reads cycle posture between iterations, read the security leadership reporting workflow.

Five stages and how the cycle plays out at each one

Each CTEM stage has a healthy posture (the cycle records the artefact that makes the stage defensible) and a default failure (the stage happens but the cycle record never captures it). The split below is the operating starting point internal security teams, vulnerability management teams, and AppSec teams can run against.

Stage	Healthy posture	Default failure
Stage 1: Scoping	The cycle opens with a documented scope decision: the in-scope business processes, customer-facing systems, regulated data flows, third-party connections, and identity surfaces, each tied to a named business owner and a written success criterion. The scope lives on the engagement record so the cycle starts from a calibrated surface rather than from a tool view of every asset the organisation owns. Scoping is a leadership decision the cycle inherits, not a tooling default.	Scope is implicit. The cycle starts because a scanner finished or because the calendar said so, not because a leadership decision named the surface. The cycle ends with a list of findings nobody can tie back to a defined surface or a business owner. The next cycle re-litigates scope from scratch and the residual queue has nowhere to anchor because scope was never recorded as a cycle artefact.
Stage 2: Discovery	Discovery enumerates assets, vulnerabilities, misconfigurations, identity weaknesses, and third-party exposures inside the scoped surfaces using external scanning, authenticated scanning, code scanning, configuration review, identity review, and human-led testing in combination. The deduplicated finding set lands on the engagement record with the source signal, the asset, the owner, and the coverage record per source so absence can be distinguished from non-coverage at the next cycle.	Each tool produces its own finding view and the cycle never builds a deduplicated record. The same exposure shows up in three tools with three identifiers and three severities, and the cycle treats that as three findings rather than as one finding with three signals. Discovery coverage is not derivable from the cycle record because the coverage source list lives in a Slack thread the cycle review will not retrieve.
Stage 3: Prioritisation	Prioritisation ranks the discovery output by exploitability, exposure, and business impact rather than by raw severity. The logic combines CVSS technical severity, EPSS exploit likelihood, CISA KEV active exploitation status, asset criticality from the tier classification, and the compensating controls already in place. Each queue item carries the rationale on the record so the cycle review and the audit lookback can read why an exposure ranked above or below another rather than reverse-engineering the logic from spreadsheets.	Prioritisation is a meeting that produces a ranked list that lives in the meeting notes. The rationale is not on the finding record, the queue order is not derivable at the next review, and the prioritisation logic shifts between cycles because the policy is implicit rather than recorded. The audit lookback reads a final list with no way to verify it came from a defensible policy.
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. Targeted manual testing, attack-path analysis, exploit reproduction, and post-remediation retesting all land on the finding record with reproduction notes and retest evidence. Validation separates real exposures from theoretical ones and the validation evidence becomes part of the cycle artefact rather than a one-off screenshot.	Validation is skipped because Discovery already produced a list. The cycle pushes scanner findings straight into Mobilisation. Severity drift, false positives, and theoretical exposures consume remediation capacity, and the cycle closes with a list of items marked closed against work that was not the real exposure. The next cycle inherits a residual queue that overstates closure progress.
Stage 5: Mobilisation	Mobilisation turns the validated queue into closure. Each exposure carries the named remediation owner, the deadline, the change record, the dependency, and the verification step on the engagement record. Continuous monitoring, retest, and the activity log together drive the cycle of remediation, retest, and closure. The cycle review reads which exposures closed, which carried over, and why, against the same record the team operated against during the cycle.	Mobilisation is implicit. The prioritised queue produces tickets in a separate system, the cycle record loses sight of closure, and the next review reads ticket counts rather than exposure reduction. Closure trail and remediation evidence sit in three systems with three timestamps. The cycle artefact does not include the closure record because the closure work happened outside the engagement.

Six failure modes that quietly break a CTEM cycle

CTEM cycles rarely fail at a single moment. They fail in small accommodations: an implicit scope, a missing coverage record, a skipped validation, a closure that happened in tickets. The cost arrives at the next cycle review when the residual queue cannot be reconstructed from the cycle artefact and at the next audit when the prioritisation rationale cannot be recovered from the meeting calendar.

CTEM is a slide deck rather than a cadence

A team adopts the language of CTEM, runs a single quarterly review against the framework, and then continues operating as a backlog cleanup against scanner output. The cycle has a name but no cadence, no closure record, and no input to the next cycle. The fix is binding the cycle to the engagement record so each iteration starts from a defined scope, ends with a closure summary, and hands the residual queue forward as the next cycle input rather than as a fresh start.

Discovery is one tool rather than a combined surface

Discovery is whatever the external scanner returned. Authenticated scanning, code scanning, configuration review, identity review, and manual testing never reach the cycle record so the surface coverage is partial and the prioritisation queue inherits the gap. The fix is sourcing Discovery from external scanning, authenticated DAST, code scanning, configuration review, and human-led testing in combination, with the coverage record per source on the engagement so absence is auditable.

Prioritisation rationale lives in a meeting

The prioritisation queue exists, but the rationale per item lives in meeting notes that the cycle record does not capture. The audit lookback reads a queue order with no defensible derivation. The fix is recording the prioritisation rationale per finding on the engagement record so the queue order can be reconstructed from the record rather than from the calendar of meetings the cycle held.

Validation is skipped to save time

The team pushes prioritised findings straight into Mobilisation without validation. Severity drift, scanner false positives, and theoretical exposures consume remediation capacity. The cycle closes with high closure counts against work that was not the real exposure. The fix is treating validation as a first-class stage with reproduction notes and post-remediation retest evidence on each queue item, not an optional efficiency.

Mobilisation closes outside the cycle record

Remediation work happens in tickets, change requests, and pipeline runs that do not feed back to the engagement. The cycle reads ticket counts rather than exposure reduction, and the closure trail is reconstructed from a Jira export at the next audit. The fix is keeping the closure trail on the engagement: status transitions, retest results, and the named owner per exposure are events on the record rather than only events in the ticket system.

Residual queue resets every cycle

The cycle ends without a defined handover. The next cycle starts with a clean slate even though carried-over exposures and surface changes should anchor the new scope. The fix is closing the cycle with a documented closure summary that names what closed, what carried over, what changed in the surface, and what the next cycle inherits as starting state, so the programme is reviewable as continuous work rather than as a series of disconnected sprints.

Six fields every CTEM cycle has to record on the engagement

A defensible cycle is six concrete fields on the engagement record, not an abstract paragraph in a security strategy document. Anything missing from the list below is a known gap in the cycle artefact rather than a detail that surfaces later as an audit finding or as a leadership-review question the team cannot answer from the record.

Cycle scope and surface ownership

The named in-scope business processes, customer-facing systems, regulated data flows, third-party connections, and identity surfaces for the cycle, each tied to a named business owner. Scope is recorded before Discovery starts so the cycle is bounded and the next cycle can compare scope drift against the previous one.

Cycle objectives and success criteria

What the cycle exists to reduce (KEV exposure on tier-zero surfaces, secret exposure across paved-road services, identity weakness inside the regulated data flow). Success criteria are written in exposure-reduction terms rather than in scan-completion terms so the cycle review reads against outcomes rather than against tool output.

Discovery source list and coverage record

The discovery sources the cycle used (external scanner, authenticated scanner, code scanner, configuration review, identity review, manual testing) and the surface coverage per source. The coverage record makes absence auditable: the next cycle can distinguish a gap that was never scanned from a surface that was scanned and produced no findings.

Prioritisation policy and rationale per item

The signal weighting (CVSS, EPSS, KEV, asset criticality, compensating controls) the cycle applied and the per-item rationale that drove its rank. The policy lives on the engagement; the rationale lives on each finding. The audit lookback can reconstruct the queue order from the record without rebuilding the meeting calendar.

Validation evidence and retest result

Reproduction notes, attack-path analysis, exploit confirmation or refutation, and the post-remediation retest result per queue item. Validation evidence sits on the finding so closure is proven rather than asserted, and severity recalibration based on validation lands as a state event with the named approver and timestamp.

Cycle cadence, closure summary, and handover

The cycle start, the planned and actual checkpoints, the cycle closure date, the residual queue carried into the next cycle, the surface changes during the cycle, and the input scope for the next cycle. Cadence and closure together turn the cycle into a continuous operating story rather than a one-off assessment.

CTEM cycle operating checklist

At cycle kickoff, at each checkpoint, and at cycle close, the programme owner, the prioritisation lead, and the Mobilisation lead walk a short checklist together. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.

Open a workspace engagement for the cycle and record the scoped surfaces, the named business owner per surface, the cycle objectives in exposure-reduction terms, and the planned cadence before any discovery work starts
Wire external scanning, authenticated scanning, code scanning, and configuration review against the in-scope surfaces, and capture the discovery source list and the coverage record per source on the engagement so absence can be distinguished from non-coverage
Stamp every finding with the CVSS 3.1 vector, the EPSS percentile against the underlying CVE, the CISA KEV exploitation status, the asset criticality tier, the exposure annotation from the scanner module, and the named owner inherited from the asset ownership map
Calibrate residual severity for compensating controls with rule, segment, or query references on the finding so prioritisation orders by residual rather than by base, and so the audit lookback can verify the residual claim from the same record
Record the prioritisation rationale per queue item rather than only at the cycle level, so the cycle review can reconstruct the queue order from the engagement record rather than from meeting notes
Run validation on every queue item with reproduction notes, attack-path analysis, exploit confirmation or refutation, and post-remediation retest evidence on the finding record before the item moves into Mobilisation
Drive Mobilisation through the engagement: named remediation owner, deadline, change record, dependency, and verification step per exposure, with retest results and status transitions on the same record the team operates against during the cycle
Re-prioritise on trigger events (new KEV listing, EPSS percentile crossing the programme threshold, compensating-control change, asset re-tiering, regression at retest) with each reordering captured on the activity log with timestamp and user attribution
Close the cycle with a documented summary covering what closed, what carried over, what changed in the surface, and what the next cycle inherits as starting state, so the programme reads as continuous work rather than as disconnected iterations

How the CTEM cycle looks in SecPortal

Cycle governance runs on the same feature surfaces the rest of the security programme already uses: the engagement record, findings management, code scanning, repository connections, authenticated and external scanning, continuous monitoring, AI reporting, and the activity log. The discipline is binding the five stages to a single record so scope, discovery coverage, prioritisation rationale, validation evidence, and closure summary derive from the same surface internal security teams already operate against.

Cycle as engagement record

The cycle scope, surface ownership, objectives, cadence, and closure summary live on the engagement record. Findings logged against the engagement inherit the cycle policy so cycle artefacts are reproducible at the next iteration rather than reassembled from a folder of attachments.

Discovery from combined sources

External scanning, authenticated scanning, and code scanning (Semgrep SAST and dependency analysis against repositories connected through GitHub, GitLab, or Bitbucket OAuth) feed Discovery. The coverage record per source lives on the engagement so absence is auditable.

Findings as queue items

Findings management stamps every queue item with the CVSS 3.1 vector, the EPSS percentile, the KEV status, the asset criticality tier, the exposure annotation, and the named owner. Bulk import from Nessus, Burp Suite, or CSV feeds the deduplicated finding set Discovery hands to Prioritisation.

Continuous monitoring schedules

Continuous monitoring schedules (daily, weekly, biweekly, or monthly) keep the discovery surface fresh between cycles so the next cycle starts with current Discovery rather than with the snapshot the previous cycle closed against. Drift between cycles lands as state events on the engagement.

AI report generation as cycle narrative

AI report generation derives the cycle narrative from the live engagement record. Scope, discovery coverage, prioritisation rationale, validation evidence, and closure summary feed the draft. The named approver edits the draft instead of writing from a blank page, and the headline figures reconcile to the underlying record.

RBAC and MFA on cycle decisions

Team management with owner, admin, member, viewer, and billing roles separates programme ownership from queue execution, and MFA enforcement keeps approver identity defensible on prioritisation policy changes, severity recalibrations, and risk acceptances inside the cycle.

Activity log as the cycle audit trail

Every scope change, discovery source addition, prioritisation rationale update, validation evidence entry, severity recalibration, risk acceptance, and closure transition lands on the activity log with timestamp and user attribution. The CSV export is the trail behind the headline cycle numbers and the evidence ISO 27001, SOC 2, NIST CSF 2.0, PCI DSS, and CISA CPGs assessors expect.

Compliance tracking against the cycle

Compliance tracking maps cycle artefacts to ISO 27001, SOC 2, NIST CSF 2.0, PCI DSS, NIST SP 800-53, and CISA CPGs control statements so the cycle reads as the operating evidence behind framework adoption rather than as a parallel deliverable.

Encrypted credentials for authenticated discovery

AES-256-GCM encrypted credential storage holds the credentials authenticated DAST uses inside Discovery so paths behind the login screen contribute findings to the cycle queue alongside external coverage. The credential lifecycle event trail lands on the activity log.

Six views the CTEM cycle operating model actually drives

The cycle reports that drive CTEM governance are not the static slide that lands at a quarterly review. They are the live views the programme owner, the prioritisation lead, and security leadership read between cycles. The six below are the ones every meaningful CTEM programme settles on, and they all derive from the live engagement record rather than from a parallel scanner extract or a hand-built spreadsheet.

Cycle scope and surface coverage view

In-scope surfaces, named business owners, discovery source list per surface, and the coverage record per source. The view leadership reads to understand what the cycle accepted as scope and what it deliberately excluded, against which the next cycle scope decisions are calibrated.

Prioritisation queue with rationale

Queue ordered by residual risk with CVSS, EPSS, KEV, asset criticality, and compensating-control state visible per item. The rationale per queue item is on the finding record, so the cycle review reads why the order is what it is rather than restating the order.

Validation evidence trail

Reproduction notes, attack-path analysis, exploit confirmation, and retest results per queue item. The view that distinguishes a real exposure from a scanner false positive and that the audit lookback reads as evidence behind the closure claim.

Mobilisation closure progress

Owner, deadline, change record, dependency, and verification step per exposure with status transitions on the engagement. The view leadership reads between cycles to see whether Mobilisation is keeping up with the prioritised queue or falling behind.

Cycle closure and residual handover

Closure summary covering what closed, what carried over, what changed in the surface during the cycle, and what the next cycle inherits. The artefact that turns each cycle into a calibrated input for the next one rather than a fresh start.

Activity log and audit trail

Every scope change, discovery event, prioritisation rationale update, validation evidence entry, severity recalibration, risk acceptance, and closure transition with timestamp and user attribution. The CSV export is the trail behind the headline cycle numbers, ready for ISO 27001, SOC 2, NIST CSF 2.0, PCI DSS, and CISA CPGs audit reads.

What auditors expect from a CTEM cycle

Cycle evidence shows up in audit reads whenever an external assessor reviews the vulnerability management or security operations programme. The frameworks below all expect the programme to demonstrate that scope is defined, discovery is defensible, prioritisation is rational, validation is evidenced, and closure is recorded. A cycle artefact pack that reads as one record satisfies the audit ask without the post-hoc reconstruction sprint.

Framework	What the audit expects
ISO 27001 Annex A	A.5.7 (threat intelligence) for the EPSS, KEV, and CTI signals the cycle uses, A.8.8 (management of technical vulnerabilities) for the cycle as a continuous operating model, A.8.16 (monitoring) for continuous monitoring inside the cycle, and A.5.36 (compliance with policies) for the recorded prioritisation policy and exception register. The cycle scope, the prioritisation rationale, the validation evidence, and the closure summary together carry the evidence behind these clauses.
SOC 2 (TSC)	CC3.2 (risk identification and assessment) for the cycle scope and discovery coverage record, CC3.4 (managing change) for surface and scope drift across cycles, CC4.1 (monitoring activities) for the validation and retest cadence, and CC7.1 (system monitoring) for the discovery sources and coverage per source. The cycle artefact pack reads as the operating evidence behind the trust services criteria.
NIST CSF 2.0	GOVERN (the cycle as the programme model), IDENTIFY (Scoping and Discovery stages), PROTECT (Mobilisation and compensating-control discipline), DETECT (continuous monitoring inside the cycle), and RESPOND (Validation and retest) outcome subcategories. The cycle record is the evidence the assessor reads against the function-level outcomes.
NIST SP 800-53 Rev. 5	RA-3 and RA-5 for the discovery and risk assessment cadence, CA-7 for continuous monitoring inside the cycle, SI-2 and SI-5 for the validation and remediation discipline, and PM-15 and PM-16 for the threat intelligence inputs the prioritisation policy uses. The cycle closure summary maps to the periodic review evidence the controls expect.
PCI DSS v4.0	6.3.1 (vulnerability identification and rating using authoritative sources), 6.3.3 (vulnerability remediation cadence), 11.3 (continuous monitoring of internal and external surfaces), 12.10 (incident response readiness), and the broader risk-based posture that PCI DSS expects mature programmes to demonstrate. The cycle evidence pack reads as the programme-level evidence the assessor expects.
CISA Cybersecurity Performance Goals	CPG 2.O (KEV vulnerability mitigation cadence) for the KEV-driven floor inside Prioritisation, alongside the broader IDENTIFY, PROTECT, and DETECT goals that read against a continuous operating cycle. The cycle scope, discovery coverage, and closure summary carry the evidence behind the goal-level adoption claims.

Where the CTEM cycle sits in the wider security programme

The cycle composes with the rest of the security programme on the same engagement record so the programme layer stays connected to the per-finding, per-control, and per-release work that runs alongside it.

Upstream and adjacent

CTEM cycles depend on asset criticality scoring for the tier classification scope inherits, asset ownership mapping for the named owners scope ties surfaces to, scanner result triage for the inbound discovery hygiene, threat intelligence driven prioritisation for the CTI signals Stage 3 reads, and internal developer platform security guardrails for the paved-road context Discovery inherits inside AppSec scope.

Downstream and reporting

Cycle evidence rolls into vulnerability prioritisation for the policy that orders Stage 3, vulnerability acceptance and exception management for the structured exception flow validation rationalises, retesting for the validation cadence that proves closure, security leadership reporting for the cadence leadership reads cycle posture against, and audit evidence retention and disposal for the long-tail evidence chain.

Pair the cycle workflow with the framework references and the operating research

The cycle is operational; the surrounding framework and research material explain the programme expectations the cycle has to satisfy and the throughput inputs the cycle has to calibrate against. Pair this workflow with the CTEM framework reference for the model definition, NIST CSF 2.0 for the GOVERN, IDENTIFY, PROTECT, DETECT, and RESPOND outcome subcategories, CISA Cybersecurity Performance Goals for the prioritised baseline goals, ISO 27001 for the Annex A controls the cycle evidence reads against, and SOC 2 for the Trust Services Criteria the cycle artefact pack supports. The buyer-side material that explains the operating-model thinking includes the continuous threat exposure management explainer, the risk-based vulnerability management buyer guide, the vulnerability prioritisation framework guide, the EPSS score explainer, and the CISA KEV catalog vulnerability management guide. The throughput inputs that calibrate cycle length live in the vulnerability remediation throughput research and the vulnerability management programme maturity model research.

Buyer and operator pairing

The CTEM cycle is the workflow vulnerability management teams run as the spine of the exposure programme, AppSec teams run alongside as the code-side discovery and validation owner, internal security teams run as the cycle programme operator, security engineering teams run when continuous monitoring and detection content overlap the cycle, and security operations leaders run as the cadence owner. CISOs read cycle scope, prioritisation rationale, validation evidence, Mobilisation closure, and residual handover as the operating story behind the residual risk number leadership and the board read between iterations.

What good CTEM cycle governance feels like

Scope is leadership-set, not tool-set

The cycle opens with a documented scope decision. In-scope surfaces, named business owners, and exposure-reduction objectives live on the engagement before any discovery work starts. The cycle starts from a calibrated surface rather than from a tool view of every asset.

Discovery coverage is auditable

The discovery source list and the per-source coverage record live on the engagement. Absence is auditable: the next cycle distinguishes a gap that was never scanned from a surface that was scanned and produced no findings, and the cycle review reads the coverage as evidence rather than as assumption.

Prioritisation rationale is recorded

Every queue item carries the prioritisation rationale on the finding record. The cycle review and the audit lookback can reconstruct the queue order from the engagement rather than from meeting notes or a private spreadsheet.

Cycle handover is the artefact

The cycle closes with a documented summary covering what closed, what carried over, what changed in the surface, and what the next cycle inherits. The handover turns each cycle into a calibrated input for the next one rather than a fresh start.

A CTEM cycle is the operating layer between exposure-management intent and reduction evidence. Run it on the engagement record so scope is leadership-set, discovery coverage is auditable, prioritisation rationale is recorded per item, validation is first-class, Mobilisation closes inside the record, and the cycle handover is an artefact the next cycle inherits. For the framework explanation, pair this workflow with the CTEM framework reference; for the prioritisation policy that runs Stage 3, pair it with the vulnerability prioritisation workflow; for the leadership cadence that reads cycle posture between iterations, pair it with the security leadership reporting workflow.

Frequently asked questions about running a CTEM cycle

How is a CTEM cycle different from continuous vulnerability management?

Continuous vulnerability management is the operational discipline that intakes scanner output, triages it, drives remediation, and reports closure. A CTEM cycle is the programme layer that bounds the continuous work into a defined scope with leadership-set objectives, runs Validation as a first-class stage so the queue is real rather than theoretical, and closes with a documented summary that hands residual work into the next cycle. Continuous vulnerability management lives inside Mobilisation; CTEM is the cycle that sequences Scoping, Discovery, Prioritisation, Validation, and Mobilisation as one operating story.

How long should a CTEM cycle run?

There is no universal cycle length. The cycle should be short enough that residual exposure is reduced inside the cycle rather than only documented, and long enough that Validation and Mobilisation can complete on the queue Prioritisation produced. Quarterly cycles with weekly or monthly checkpoints are a common starting point. The throughput evidence on the engagement record (mean time to remediate, retest cadence, closure rate per cycle) is the input that calibrates a defensible cycle length over time, and the cadence record makes the choice reviewable rather than implicit.

Does CTEM replace ASM, RBVM, or TVM?

CTEM does not replace any of them. ASM is part of Discovery and produces the external surface inventory. RBVM is the prioritisation logic CTEM applies inside Stage 3. TVM is the operating mechanics inside Mobilisation. CTEM is the programme model that sequences these disciplines into a single cycle with a defined scope, a Validation stage, and a closure summary. A workspace that already runs the underlying disciplines becomes the operating layer for a CTEM cycle without rebuilding the toolset.

How does scoping balance focus against coverage?

CTEM scope is deliberately narrower than asset inventory. The scope names the surfaces that carry material exposure for the cycle (regulated data flows, customer-facing systems, identity surfaces, third-party connections, business-critical workloads), each tied to a business owner and a success criterion. Continuous monitoring still runs against the wider surface so out-of-scope discovery is captured, but the cycle drives reduction work against the scoped surfaces. Coverage of the wider surface is a CISO-level metric; reduction inside scope is a cycle metric.

How does Validation differ from a retest?

A retest verifies that a specific finding was closed by a specific remediation. Validation tests whether the prioritised exposures are exploitable in the first place, whether the proposed remediation actually closes them, and whether the compensating controls behave as claimed. Validation runs before Mobilisation chooses how to remediate. The retest then verifies closure after remediation. Programmes that skip Validation often discover the exposure they remediated was a scanner false positive, an attack path that did not connect, or a finding that a compensating control already mitigated.

What evidence does AI report generation produce for a CTEM cycle?

AI report generation derives the cycle narrative from the live engagement record. The cycle scope, the discovery source list and coverage record, the prioritised queue with rationale, the validation evidence per item, the Mobilisation closure trail, and the closure summary all feed into the report draft. The named approver edits the draft instead of writing from a blank page, and the headline cycle figures reconcile to the underlying record because the report is generated against the same engagement record the team operated on during the cycle.

How does the cycle hand off to the next cycle?

The cycle closes with a documented summary on the engagement covering what closed, what carried over as residual queue, what changed in the surface during the cycle (new assets, retired services, scope additions or contractions), and what the next cycle inherits as starting scope and starting queue. The handover is the artefact that turns each cycle into a calibrated input for the next one. Programmes that close cycles without a recorded handover restart from scratch each iteration and lose the continuous-operating property the framework exists to provide.

How does CTEM map to ISO 27001, SOC 2, and NIST CSF 2.0?

ISO 27001 reads CTEM as evidence behind A.5.7 threat intelligence, A.8.8 management of technical vulnerabilities, and A.8.16 monitoring. SOC 2 reads CTEM as CC3.2 risk identification, CC3.4 change management, CC4.1 monitoring activities, and CC7.1 system monitoring. NIST CSF 2.0 reads CTEM as a programme that delivers GOVERN, IDENTIFY, PROTECT, DETECT, and RESPOND outcome subcategories on a cadence. The cycle scope, discovery coverage, prioritisation rationale, validation evidence, and closure summary together carry the evidence the audit lookback expects.

How it works in SecPortal

A streamlined workflow from start to finish.

Open the cycle as an engagement and record the scope decision

Open a workspace engagement for the cycle. Record the in-scope business processes, customer-facing systems, regulated data flows, third-party connections, and identity surfaces. Tie each surface to a named business owner. Record the cycle objectives in exposure-reduction terms, the success criteria, and the planned cadence before any discovery work starts. Scope is a leadership decision that lives on the engagement, not a tooling default.

Run combined Discovery and capture the coverage record per source

Wire external scanning, authenticated scanning, code scanning (Semgrep SAST and dependency analysis against repositories connected through GitHub, GitLab, or Bitbucket OAuth), configuration review, identity review, and human-led testing against the in-scope surfaces. Land the deduplicated finding set on the engagement with the source signal, the asset, the owner, and the coverage record per source so absence can be distinguished from non-coverage at the next cycle.

Prioritise with CVSS, EPSS, KEV, asset criticality, and compensating controls

Stamp each finding with the CVSS 3.1 vector, the EPSS percentile, the CISA KEV exploitation status, the asset criticality tier inherited from the asset ownership map, the exposure annotation from the scanner module, and the named owner. Calibrate residual severity for compensating controls with rule, segment, or query references. Record the prioritisation rationale per queue item on the finding so the cycle review reconstructs the queue order from the record rather than from meeting notes.

Validate the prioritised queue before Mobilisation

Run targeted manual testing, attack-path analysis, exploit reproduction, and post-remediation retesting on every queue item. Land reproduction notes, attack-path analysis, exploit confirmation or refutation, and retest results on the finding record. Validation separates real exposures from theoretical ones, recalibrates severity where compensating controls already mitigate, and turns scanner findings into the queue Mobilisation actually closes.

Drive Mobilisation through the engagement record

For each validated exposure, name the remediation owner, the deadline, the change record, the dependency, and the verification step on the engagement. Status transitions (open, in_progress, resolved, verified, reopened) live on the finding. Continuous monitoring schedules (daily, weekly, biweekly, or monthly) run between cycles to keep the discovery surface fresh. The closure trail lives on the same record the team operates against, not in a parallel ticket export.

Re-prioritise on trigger events with the activity log as the trail

Trigger-driven re-prioritisation keeps the queue accurate between cycle checkpoints. A new KEV listing, an EPSS percentile crossing the programme threshold, a compensating-control change, an asset re-tiering, or a regression at retest forces a fresh tier evaluation. Each reordering, severity recalibration, and risk acceptance lands on the activity log with timestamp and user attribution so the trail is reconstructable later for cycle review and audit.

Close the cycle and hand the residual queue forward

Close the cycle with a documented summary on the engagement covering what closed, what carried over as residual queue, what changed in the surface during the cycle, and what the next cycle inherits as starting scope and starting queue. AI report generation derives the closure narrative from the live record so the headline figures reconcile to the underlying engagement. Cycle handover is the artefact that turns each cycle into a calibrated input for the next one.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Vulnerability scanning tools that map your attack surface

Test web apps behind the login

Find vulnerabilities before they ship

Monitor continuously catch regressions early

AI-powered reports in seconds, not days

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Encrypted credential storage for authenticated scans

Run a continuous CTEM cycle on one defensible record

Scope, discovery coverage, prioritisation rationale, validation evidence, Mobilisation closure, and cycle handover on a single auditable engagement. Start free.