CTEM for Enterprise: Scaling Continuous Exposure Management Across Complex Environments

For 40% of enterprises, growing through mergers, acquisitions, and strategic partnerships is a top priority in 2026, according to recent research.

Every acquisition adds an attack surface the acquiring organization didn't design, didn't inventory, and doesn't fully understand, often overnight. Continuous threat exposure management (CTEM) at enterprise scale has to account for an attack surface that arrives without warning.

CTEM at 100 assets and CTEM at 100,000 assets are fundamentally different operational challenges. The five stages, Scoping, Discovery, Prioritization, Validation, and Mobilization, stay the same. The governance model, the tooling stack, the compliance obligations, and the complexity of Mobilization do not.

Enterprise security leaders understand this framework and need to operationalize it across subsidiaries, M&A targets, siloed engineering teams, and global regulatory environments, and what works at that scale looks different from what works at a 500-person company.

Why CTEM at Enterprise Scale Is a Different Problem

Enterprise complexity breaks standard CTEM approaches in three specific ways:

1. Scope Never Stops Expanding

In a mid-market organization, the attack surface is largely knowable. In an enterprise, new assets enter scope continuously in various ways:

• Cloud infrastructure gets provisioned without security review
• SaaS tools get onboarded by individual teams
• AI systems get deployed by teams before security is ever consulted
• M&A targets arrive with entire legacy attack surfaces attached
• Fourth and fifth-party vendor integrations keep expanding the perimeter further

The Scoping stage for an enterprise runs as a continuous discovery problem, layered on top of a continuous vulnerability problem.

Consider the supply chain layer alone: The OWASP LLM05 Supply Chain Vulnerabilities saw a 22% year-over-year increase in valid AI reports on the HackerOne platform from 2024 to 2025 according to the most recent Hacker-Powered Security Report.¹ In enterprise environments, the supply chain layer of the attack surface is orders of magnitude larger than the directly managed layer.

2. Mobilization Spans Organizational Boundaries

In a standard CTEM program, Mobilization means routing findings to engineering. In an enterprise, it means routing findings to the right engineering team across dozens of product lines, geographies, and business units, many of which have no reporting relationship to the CISO at all.

A validated critical finding on a subsidiary's payment system needs to reach the right engineer, with the right SLA, and with organizational authority standing behind it. That's fundamentally a governance problem, which is why enterprise programs increasingly route findings through existing engineering tooling instead of asking every business unit to adopt a new workflow.

The H1 Platform routes findings into Jira, ServiceNow, and GitHub where engineering teams already work

3. Compliance Is Not One Framework. It's Many.

DORA applies to EU financial services. NIS2 applies to EU critical infrastructure. PCI DSS 4.0 applies to payment card environments. SEC cyber disclosure rules apply to US public companies.

Most enterprise organizations face several of these simultaneously, in different jurisdictions, with different evidence requirements and different timelines. CTEM has to produce continuous, auditable evidence, well beyond the point-in-time assessments most compliance programs still lean on.

Enterprise CTEM Governance: Who Owns What at Scale

The standard CTEM ownership model, CISO, SecOps, Offensive Security, Engineering, and Risk, works fine in a single-team environment. In an enterprise, each of those roles gets distributed across multiple teams, business units, and geographies, and the authority to hold engineering accountable for SLAs may not exist at the security team level at all.

Helvetia Group offers a real version of this problem. As the Swiss insurer's digital footprint grew across Germany, Austria, Spain, Italy, and France, fixed-interval penetration testing left long windows where newly introduced risk went undetected, and scope restrictions meant whole categories of assets sat outside regular review. 

Moving to a centrally run private bug bounty program, paired with time-bound testing surges around major launches, gave leadership a single view across jurisdictions instead of five disconnected ones.

How Snap, Shopify, and Helvetia Achieved Continuous Security Validation

CTEM and M&A: Scoping the Attack Surface You Just Acquired

Every acquisition brings an attack surface the acquiring organization didn't design and can't fully inventory on day one. Enterprise CTEM needs a defined M&A integration protocol.

Day One M&A CTEM Actions

Before an acquisition closes, commission a targeted PTaaS engagement or bug bounty scope expansion against the target's external attack surface. This is a focused CTEM Discovery exercise on high-severity, externally reachable exposures, run ahead of close. The goal is to enter the integration period already knowing where the highest-priority risks sit, rather than discovering them six months post-acquisition when they're already exploitable.

The M&A Scoping Problem

Acquired organizations typically arrive with shadow IT and unmanaged assets absent from any inventory, legacy systems that haven't been patched in years, developer tools and CI/CD pipelines running on permissive credentials, AI systems deployed without security review, and third-party integrations inherited from the target's own vendor network. The CTEM Scoping stage for an acquired organization should be treated as a first-cycle scoping exercise. Assume nothing is inventoried, and start from external asset discovery inward.

Integration Timeline

A workable phased model runs on roughly this cadence:

• Days 1 through 30 cover external attack surface discovery of the acquired entity.
• Days 31 through 90 integrate the acquired assets into the enterprise CTEM program's scope and run the first Prioritization pass. 
• From day 91 onward, Validation coverage extends to the acquired assets, and findings route through the unified Mobilization workflow.

CTEM and Supply Chain Risk: The Attack Surface You Don't Own

In enterprise environments, the supply chain layer is larger and harder to scope than the directly managed layer. 

The Enterprise supply chain attack surface runs across four layers. 

1. The software supply chain covers third-party libraries, open-source packages, AI frameworks, and SaaS APIs. 
2. The vendor network covers suppliers and partners with access to internal systems or data. 
3. Fourth and fifth-party risk covers the vendors of your vendors. 
4. The AI supply chain covers open-weight models pulled from public repositories, fine-tuning datasets, and model routing frameworks.

Most enterprise CTEM programs cover the first layer inconsistently and ignore the other three almost entirely. The NIS2 directive and DORA both mandate supply chain risk coverage as part of continuous risk management, which makes this a compliance obligation under both frameworks.

The enterprise supply chain can't be inventoried once and left alone. New dependencies show up with every code commit, every SaaS onboarding, and every AI tool adoption. 

Continuous supply chain discovery, through SBOM tooling, dependency scanning, and AI framework audits, has to feed directly into the CTEM Discovery stage so the enterprise has a current view of what it actually depends on.

H1 Bounty extends researcher-led discovery into this layer, alongside SBOM and dependency scanning data.

Mapping Enterprise CTEM to Compliance Frameworks

NIS2 (EU Critical Infrastructure)

NIS2 requires covered entities to implement security risk management measures continuously, including vulnerability handling, supply chain security, and incident reporting.

CTEM directly satisfies the continuous requirement. The Discovery and Prioritization stages produce the documented exposure management evidence NIS2 auditors look for, and the Validation stage adds control effectiveness evidence that goes past NIS2's minimum requirements, giving organizations audit evidence that holds up under real scrutiny.

DORA (EU Financial Services)

DORA's ICT risk management requirements mandate continuous monitoring, vulnerability management, and resilience testing for financial entities and their ICT service providers.

The CTEM cycle maps directly onto this: continuous Discovery for asset and vulnerability monitoring, Prioritization for ICT risk ranking, Validation through PTaaS and adversarial testing for DORA's resilience testing requirement, and Mobilization for the documented remediation workflows DORA auditors examine. DORA specifically requires that third-party ICT providers demonstrate continuous risk management, which makes this framework directly relevant to financial services organizations running CTEM.

PCI DSS 4.0

PCI DSS 4.0 introduced continuous monitoring requirements that move past the old annual-assessment model. Requirement 11.3 now mandates penetration testing of the cardholder data environment at minimum annually and after significant changes, with continuous monitoring between tests.

CTEM satisfies both halves: PTaaS provides the structured penetration testing, and continuous bug bounty discovery covers the gaps between tests.

SEC Cyber Disclosure Rules

Public companies must report material cybersecurity incidents within four business days and disclose their cybersecurity risk management processes annually.

CTEM produces the documented, continuous evidence of risk management that supports the annual disclosure. MTTR, coverage rate, and exposure reduction score data from H1 Analytics & Intelligence forms the evidence base for SEC disclosure narratives.

How AI Changes Enterprise CTEM Scope

The enterprise AI attack surface is growing faster than any other attack surface category. Prompt injection reports alone jumped 540% in 2025, and valid AI-related vulnerability reports have increased 210% since 2024.¹ Enterprise organizations that don't fold AI systems into their CTEM scope are creating a blind spot CTEM was designed to eliminate.

For enterprise organizations specifically, the challenge is that AI gets deployed at the business unit level, not centrally managed by security.

By treating AI red teaming as a centralized Validation capability and engaging a global pool of researchers through HackerOne, Snap surfaced vulnerabilities that adversarial datasets and automated tools had missed entirely, generating more than 300,000 adversarial interactions and, in Snap's words, proving that “human ingenuity often outperforms adversarial datasets or AI-generated attacks.”

The same federated governance model that applies to CTEM generally applies to AI. Central security sets AI scoping standards and owns AI red teaming as a centralized Validation capability, while business units are responsible for declaring their AI deployments to the Program Office.

CTEM for AI Systems: How to Apply the 5-Stage Framework to Your AI Attack Surface

CTEM Maturity at Enterprise Scale: The 5-Level Model

The three-level Early, Developing, Mature model in the complete CTEM guide describes individual program maturity. At enterprise scale, maturity varies by business unit. A financial services unit might sit at Mature while a recently acquired subsidiary is still at Early. The enterprise challenge is eliminating those Early-stage units, wherever they sit in the org chart, because they represent the weakest links in the overall attack surface.

That's the gap a fifth level is designed to close. At Level 5, every business unit operates at Developing or above, an M&A integration protocol is in place, the supply chain is continuously inventoried, AI systems are in scope across all units, compliance evidence generates automatically from program data, and Mobilization SLAs are enforced enterprise-wide with board-level reporting.

Getting there requires more than a mature security program at the center. It requires governance infrastructure that extends continuous validation to every corner of the enterprise, and the organizational will to hold all of it to the same standard.

Build the foundation first: Read the Complete Guide to CTEM

^{1. Hacker-Powered Security Report 2025: The Rise of the Bionic Hacker}

^{Survey methodology: HackerOne and UserEvidence surveyed 99 HackerOne customer representatives between June and August 2025. Respondents represented organizations across industries and maturity levels, including 6% from Fortune 500 companies, 43% from large enterprises, and 31% in executive or senior management roles. In parallel, HackerOne conducted a researcher survey of 1,825 active HackerOne researchers, fielded between July and August 2025. Findings were supplemented with HackerOne platform data from July 1, 2024 to June 30, 2025, covering all active customer programs. Payload analysis: HackerOne also analyzed over 45,000 payload signatures from 23,579 redacted vulnerability reports submitted during the same period.}