The Question
Your organization has deployed the CTEM tool stack. EASM is running continuous discovery on internet-facing assets. The VM platform is producing risk-scored findings with EPSS and CISA KEV integration. BAS is running monthly simulations. Attack path analysis has mapped fourteen paths to crown jewel systems. The platforms are generating better threat exposure intelligence than the organization has ever had.
Four months in, six of the fourteen attack paths remain open. Three CISA KEV findings on internet-facing systems are aging past thirty days. The BAS pass rate has not improved. The security team is producing findings. Findings are routing to IT operations as tickets. IT operations is closing some tickets and deprioritizing others. The IAM team received attack path findings implicating Active Directory misconfigurations and is reviewing them in their quarterly backlog cycle. The developers who own the cloud workloads with misconfigured storage are not in any of these workflows.
The program has a tool problem only in the sense that the tools are producing outputs that the organization's operating model is not structured to act on. The actual problem is organizational: CTEM requires a cross-functional operating model with defined ownership, defined cadences, and defined escalation authority. Most organizations deploy the tools and discover — sometimes months in — that the operating model was never designed.
A CTEM program without an explicit operating model — defined owners, defined cadence, defined SLAs — is a set of security tools generating findings that flow into a gap between security and IT operations and produce no remediation.
Why This Matters Now
In mid-2025, a global professional services firm deployed a CTEM platform that its CISO described at a public industry conference as "the most complete threat exposure visibility we've ever had." Eighteen months later, the firm suffered a breach in which attackers exploited an attack path that had been identified and documented in the CTEM platform's attack path analysis module from the program's first assessment cycle.
The finding had been reported. It had been assigned to the infrastructure team that owned the affected systems. The infrastructure team's backlog prioritization process — which operated on a quarterly planning cycle — had ranked the remediation below several platform migrations with firm delivery commitments. No escalation mechanism existed within the CTEM operating model to elevate findings that were aging past acceptable risk thresholds. The finding sat in the infrastructure team's backlog for eight months.
The breach was not a technology failure. The CTEM platform had done exactly what it was designed to do: identify the attack path, assess its severity, and report the finding. The operating model had no mechanism to ensure that a finding of this severity was acted on within a timeframe commensurate with the risk. The firm's CISO, in his post-incident statement, said: "We had the intelligence. We did not have the operating infrastructure to translate intelligence into action fast enough."
This pattern — correct detection, insufficient operating model — is the primary CTEM failure mode in enterprise programs.
What the CURVE™ Data Shows
The 2026 Stackcurve CTEM CURVE™ Report assessed CTEM programs on operating model maturity alongside platform capability, finding that operating model maturity is the stronger predictor of program outcomes.
Programs rated as having mature operating models — defined ownership, documented SLAs, ITSM integration, regular program reviews — showed significantly better attack path closure rates and BAS pass rate improvement trends than programs with equivalent tool investments but underdeveloped operating models.
On the platform side, Tenable One and Qualys TruRisk rated highest for built-in operating model support: role-based dashboards for different stakeholders (security, IT operations, executive), ITSM ticketing integration with SLA tracking, and program governance reporting that surfaces aging findings and coverage gaps to program managers. XM Cyber rated highest for attack path lifecycle management — tracking path status from initial identification through remediation validation with clear ownership assignment at each stage.
ServiceNow Vulnerability Response rated as the strongest ITSM-layer operating model tool for organizations that want to centralize CTEM program governance in their existing service management infrastructure, aggregating findings from multiple CTEM sources into a single remediation workflow with unified SLA management.
The full vendor rankings are in the 2026 Stackcurve CTEM CURVE™ Report — free to download.
The Gap Most Buyers Miss
The gap most buyers miss is treating the CTEM operating model as something that emerges naturally from deploying CTEM tools — that once the platforms are configured and generating findings, the organizational response will organize itself around those findings. It does not. Organizational response to security findings is governed by existing workflows, existing priorities, and existing authority structures. CTEM findings that don't map cleanly into those existing structures fall through the gaps.
The CTEM operating model has four explicitly designed components:
Program ownership: the CTEM program manager. A designated CTEM program manager — typically housed in the security architecture or vulnerability management function — owns the full five-stage CTEM cycle. This role is not a technical operator; it is a program coordinator who owns the governance layer: tracking stage completion across all scope segments, managing vendor relationships, coordinating cross-team remediation, reporting program metrics to the CISO, and escalating findings that are aging past SLA thresholds. Without this role, CTEM is a set of tools generating outputs with no single accountable owner for program outcomes.
Scoping and discovery: owned by security. Decisions about which scope segments to include in the current CTEM cycle, which discovery tools to use, and how to interpret and validate discovery findings belong to the security team. This is the expertise domain of security: what does the attack surface look like, what is the threat actor priority, what scope segment has the highest current risk. Scoping decisions should be reviewed on a defined cadence — continuous automated discovery running always, with quarterly scope expansion decisions that add new business units, acquisitions, or newly identified asset classes to the program.
Prioritization and validation: owned jointly by security and platform teams. Prioritization — determining which findings represent the highest remediation priority — requires input from both security (risk context, threat intelligence, attack path analysis) and the platform teams who own the affected assets (compensating control status, system criticality, patch dependency constraints). Neither team can make good prioritization decisions alone. Security without platform context over-prioritizes findings that have existing compensating controls. Platform teams without security context under-prioritize findings that security understands as active exploitation vectors.
BAS validation runs on a defined cadence as the output of this joint prioritization process: monthly for internet-facing and crown jewel scope segments, quarterly for the broader environment. Validation results are reviewed jointly by security and platform teams.
Mobilization: owned by IT operations with security SLAs. Remediation execution belongs to IT operations, which has the patch deployment authority, the change management relationships, and the platform access to implement fixes. Security's role in mobilization is SLA definition, ticket routing, and closure validation — not patch deployment. ITSM tickets are created automatically from CTEM platform findings. SLA clocks start at ticket creation. Security validates closure via BAS rescan or targeted vulnerability rescan after IT operations marks findings as remediated.
The operating cadence. The CTEM operating cadence runs at five temporal layers. Continuous discovery runs always — cloud EASM, CSPM, and agent-based scanning provide real-time asset inventory updates without human intervention. Weekly prioritization reviews cover CISA KEV additions and newly discovered high-risk findings that require immediate action outside the monthly cycle. Monthly BAS validation cycles cover internet-facing and crown jewel scope segments — the highest priority scope runs every 30 days. Quarterly program reviews bring together CISO, IT leadership, and business stakeholders to review program metrics, scope decisions, and SLA performance. Annual red team exercises provide novel attack path discovery by human adversary simulation that BAS automation does not replicate.
The escalation mechanism. The operating model must include explicit escalation paths for findings that breach SLA without resolution. An aging high-risk finding that cannot be remediated within SLA — due to vendor patch availability, legacy system constraints, or competing IT priorities — must escalate to a defined authority level (CISO level for critical findings, IT VP level for high-priority findings) that has organizational authority to either mandate faster remediation or formally accept the risk with documented rationale and compensating controls. Without this mechanism, SLAs are advisory.
Questions Your Buying Team Should Be Asking
1. Who is the designated CTEM program manager in our organization, and does this role have explicit authority to escalate aging high-risk findings to IT operations leadership and, if necessary, to the CISO? If there is no designated program manager, the answer identifies the first organizational change required before additional tool investment adds value. If the program manager exists but lacks escalation authority, the operating model has governance without teeth — findings can be escalated in name only.
2. Has our CTEM program produced a documented scope map that defines which asset categories are in-scope for the current program cycle, which are planned for future cycles, and which are explicitly out-of-scope with documented rationale? A scope map forces the organizational conversation about prioritization that most programs avoid. Leaving scope undefined means the program defaults to whatever assets happen to be covered by the existing VM scan configuration — which may not align with actual risk priorities.
3. Do we have a joint security-IT operations operating agreement that defines remediation SLAs, escalation paths, and compensating control procedures — and was this agreement reviewed and endorsed by both the CISO and the relevant IT operations leadership? The operating agreement is the organizational foundation of the CTEM program. Without it, SLAs are aspirational. With it, SLAs have organizational authority. The level of endorsement matters: an agreement between a security manager and an IT operations manager is less durable than one between the CISO and the CITO or equivalent.
4. When our CTEM program generates attack path findings implicating teams outside the traditional security-IT operations workflow — IAM, cloud platform, application development, OT — what is the mechanism for routing those findings to the responsible team and tracking remediation to closure? Attack path findings frequently implicate organizational owners who are not part of the existing VM-to-patch workflow. Active Directory misconfigurations belong to IAM teams. Cloud storage misconfigurations belong to developer teams. OT network segmentation issues belong to operational technology teams. If the CTEM operating model routes all findings to IT operations regardless of the actual responsible owner, a significant proportion of findings will be assigned to teams without the authority or knowledge to act on them.
5. What is the current mean age of open attack path findings on crown jewel systems, and what is the escalation trigger — if any — for findings that age past thirty days without documented compensating controls? This question tests whether the operating model is functional under pressure. An attack path finding on a crown jewel system that ages past thirty days without resolution or documented compensating control is a program failure that should be visible and escalated. If no escalation trigger exists, the operating model relies on individual team motivation rather than structural accountability.
The Stackcurve Take
The organizations running the most effective CTEM programs in our research have one thing in common that distinguishes them from programs with equivalent tool investments and worse outcomes: they made the organizational design decisions before they finalized the tool purchases.
They designated a program manager with explicit authority before deployment. They drafted the security-IT operations operating agreement before the first assessment cycle. They mapped their crown jewel systems and defined their scope priorities before configuring the first scan. They established board-level metrics before they had data to report.
The tool choices followed from the operating model requirements, not the reverse. CTEM platforms are evaluated on their ability to support the operating model — does it integrate with our ITSM system, does it support the escalation workflow we've defined, does it produce the metrics our stakeholders need — rather than the program being organized around whatever the platform's default workflow happens to be.
This sequence — operating model first, tool selection second — is the consistent predictor of CTEM program success. It is also the sequence that most vendor sales processes are designed to short-circuit: vendors lead with platform demos, not organizational design workshops. The buyer's job is to insist on answering the operating model questions before the platform decision closes.
The 2026 Stackcurve CTEM CURVE™ Report covers CTEM program governance frameworks, operating model maturity benchmarks, and platform support for cross-functional CTEM operating models across all major vendors. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.