How to Build a CTEM Program: A 90-Day Implementation Roadmap
A gap exists between how many vulnerabilities are being found and how many are actually getting resolved.
Vulnerability submissions grew 76% last year and monthly resolutions fell 46%. The backlog of unresolved critical vulnerabilities grew 25x. The queue is winning.
Most security programs are built to find more, not to confirm what's real. That distinction is exactly what separates Continuous Threat Exposure Management (CTEM) from the vulnerability management programs most teams are already running.
This 90-day roadmap will help you get your CTEM program up-and-running. Built around what mature HackerOne programs look like in practice, the guide covers everything from governance setup and tooling decisions to common failure modes at each phase, and underscores what good looks like at Day 90.
Think of this less as a finite project and more as a new way of working that gets faster and more precise the longer you run it. The first 90 days build the foundation, and everything after gets easier because of it.
Week Zero: Sponsorship, Scope, and State
A note on timing: this roadmap assumes a single program and a focused starting scope. Organizations launching a bug bounty program face different considerations than those standing up a VDP first: VDPs typically launch faster because they don't require bounty funding and cast a wider net for initial coverage. If you're running both, expect a staggered approach. Organizational factors like funding cycles, engineering bandwidth, and existing tooling will also affect pace. Use this timeline as a target, not a guarantee.
Start with our Complete Guide to Continuous Threat Exposure Management (CTEM) to understand how this adaptive security framework combines automation, validation, and prioritization into a single operating motion.
Executive buy-in, a defined scope, and a clear baseline are the structural decisions every subsequent stage of this 90-day roadmap builds on. The more solid they are, the faster the program compounds. Before you get started, take the time to get these three S’s in solid shape.
1. Executive Sponsorship
Without an executive sponsor, the CTEM program you’re building will stay isolated as a security team initiative rather than an organizational operating model. Because CTEM requires Engineering to fix what Security finds, ideally you want an executive sponsor who owns both functions, or has the authority to hold both accountable.
Identify one executive who owns the program outcome before any tooling is procured or any scope is defined, and frame the business case around Gartner's prediction: organizations implementing CTEM will be three times less likely to suffer a breach by 20261 and around what a breach costs when it happens: $4.88M on average.
2. A Defined Starting Scope: The Crown Jewel
You’ll be tempted to cover everything from day one. Resist that temptation. Teams that start too broad stall out in Stage 1.
Instead, start with the one business-critical system or service whose compromise would cause the most damage. Define that crown jewel and map the assets and identities that support it. You’ll run the first CTEM cycle there and expand the scope after that first cycle is complete.
3. A Baseline of Your Current State
If you don’t know where you’re starting, it’s impossible to know where you want to go (and measure the ROI).
Before building a CTEM program, take stock:
- What scanning and vulnerability management (VM) tooling is already running?
- What does the current Mean Time to Remediate (MTTR) look like?
- How many open critical findings exist?
- What percentage of the attack surface is currently monitored?
Documenting these answers will give you a good baseline for measuring CTEM progress against.
To start: Confirm executive sponsorship, define your starting crown jewel, and document your current MTTR and open critical count before Week 1 begins. These three inputs determine whether the 90 days produces a running program or a stalled pilot. |
The First 30 Days
Getting clarity in the first 30 days is critical. While this may seem like common sense, take the time to explicitly document what your attack surface looks like, who owns what, and how you’re measuring success. It’s not enough to have a general idea. Map it out and make the document accessible to all stakeholders. Shared visibility is shared accountability.
Weeks 1–2: Governance Setup
Governance here means one thing specifically: who is accountable when a validated finding is not remediated within the agreed SLA? That accountability must be established in writing before the program begins. For each CTEM stage, these are the owners and their broad responsibilities. Tailor these to your organization’s structure and needs.
CISO | Owns program strategy, success metrics, and board reporting |
SecOps | Runs discovery and alert triage |
Offensive Security | Owns Validation |
Engineering | Owns Mobilization |
Risk and Compliance | Owns executive reporting and compliance mapping |
When everyone knows their role and no one is guessing about who owns what, the program has the clarity it needs to move. Your governance absolutely must be set up before Week 3.
Weeks 2–3: Attack Surface Inventory and Scoping
Most organizations think they know how big their attack surface is, but discover that it is larger than their asset inventory suggests.
To get a clear and accurate picture, start by documenting what you know exists in the scope you defined as your pre-work in Week Zero. This could include:
- External-facing systems
- Cloud infrastructure
- SaaS applications
- Identity systems
- AI and ML deployments
- Third-party integrations
Don’t be surprised if shadow IT and unmanaged assets surface during the first inventory pass, they invariably do. This isn’t a problem you need to solve before Discovery begins, but rather a first finding in a constantly evolving, and improving, inventory cycle.
The goal is to scope what matters to the business, then determine what tooling is needed to cover it, not the other way around.
Weeks 3–4: Establish Success Metrics
What does success look like? Define 3-4 metrics that will demonstrate to leadership CTEM progress and capture a baseline snapshot of what those look like now.
This before-state is what every subsequent cycle will get measured against. Here are the baseline metrics we recommend establishing before you begin (even if current values are zero or unknown):
- Mean Time to Validate (MTTV)
- Mean Time to Remediate (MTTR)
- Total Exposure Backlog
By the end of Week 4: Governance owners are documented in writing, the starting scope is defined to one business-critical service, and baseline MTTR and open critical count are pulled from the ticketing system. If any of these three are missing, you may not be ready to move to Weeks 5 through 8. |
The First 60 Days
The second thirty days are about finding exposures and building the prioritization logic that determines what gets worked on first.
Weeks 5–8: Discovery and Prioritization Workflows
Discovery Tooling Integration
The goal in this stage isn't to buy more tools or run more scans. It's to make the tools you have work better together.
- Integrate existing scanning tools, vulnerability scanners, EASM platforms, and CSPM tools into a unified view of the defined scope
- Connect what you have so findings flow into a single queue rather than sitting in separate tool-specific dashboards
- Map each tool to the asset types it covers to identify gaps, or things in scope not covered by any current tool
- Fill those gaps with bug bounty, PTaaS, and manual discovery
A successful discovery phase ensures every asset in scope has a discovery mechanism assigned to it, and that findings from all mechanisms flow into the same prioritization workflow.
Building the Prioritization Framework
Using CVSS as the primary ranking signal puts you at risk of getting the prioritization queue wrong from the start. A critical CVSS score on an internal system with no external reachability is a lower priority than a medium CVSS score on an externally reachable system with sensitive data access. CVSS scores both identically.
Instead, build a prioritization matrix that scores each finding across three dimensions:
- Exploitability: Has this been validated, or is it theoretical?
- Business impact: Does compromising this asset affect a critical business process?
- Reachability: Can an attacker actually reach this from an external entry point?
HackerOne's Hai applies this multi-dimensional prioritization automatically, achieving 95% accuracy and 40% signal improvement over raw scanner output, reducing manual triage time from hours to minutes.
Establishing the First Validation Queue
By Week 8, the prioritization framework should have produced a short list of five to ten findings where business impact and reachability scores are high enough to justify committing validation resources before remediation effort is spent.
- These are the first candidates for a PTaaS engagement or bug bounty scope expansion
- Keep the list short: validation is a focused exercise, not a second round of scanning
- Do not skip this step in favor of immediately remediating scanner output
This is exactly where most programs fail to achieve CTEM and instead run expensive, better-labeled VM. Discovery and Prioritization produce a queue. Validation is what determines whether that queue reflects real risk.
- 74% of prioritized findings across HackerOne programs turn out to be dead ends after triage
- Programs that skip Validation commit remediation resources to roughly three findings for every one that actually required it
By the end of Week 8: All tools in the defined scope are feeding a single prioritization queue, the prioritization matrix is documented, and a list of five to ten findings is ready for validation. Do not route findings directly to Engineering until Validation has run. |
Closing in on 90 Days
The final 30 days are where the model earns its name. Validation moves from spot-checking to a standing practice: every fix confirmed against the exploit path it was meant to close, not just the ticket status.
Weeks 9–13: Validation, Mobilization, and First Cycle Completion
Remediation shifts from security chasing engineering to engineering owning the queue as part of its own workflow. By Week 12, the program completes its first full cycle and produces a measurable baseline and a defensible answer to the question: what is actually exploitable right now, and how do we know?
That answer is the line between CTEM and VM. One counts vulnerabilities while the other closes exposure.
Adding the Validation Layer
The path you choose for standing up the Validation mechanism for the prioritized findings queue built in Weeks 5 through 8 depends on program maturity:
Option 1: Bug bounty expansion | If a H1 Bounty program is already running, expand scope or add a targeted bonus to direct researcher attention toward the highest-priority findings. Researchers validate exploitability with real-world attacker techniques rather than scanner pattern-matching. |
Option 2: PTaaS engagement | Commission a structured PTaaS engagement focused on the five to ten highest-priority findings. Hai Triage reduces false positives before the engagement begins, so researcher time is focused on real risk rather than noise. |
Option 3: Both | For organizations with AI systems in scope, add AI red teaming as a parallel Validation track. AI-specific vulnerabilities, including prompt injection, jailbreaks, and insecure agentic behaviors, have no CVE assignment and don't surface in any scanner. They require human adversarial testing to find. |
A finding is validated when a researcher or tester has demonstrated a working exploit path, not when a scanner has rated it critical and not when a developer has assessed it as likely exploitable. Validated means proven.
Mobilization: Routing Findings to Engineering
A validated finding that arrives in Engineering as a generic ticket gets treated like every other ticket: it’s triaged, queued, and worked when capacity allows. That's just adding an extra step to vulnerability management.
For true Mobilization, each validated finding needs to arrive with the confirmed exploit path documented (not just the vulnerability class), the specific fix required, a severity-based SLA, and a re-validation requirement after the fix is applied. The ticket is the handoff, and the quality of the handoff determines how quickly and effectively Engineering can act.
It’s essential to route tickets directly to the engineering team or developer who owns the affected system. The most common Mobilization failure is security teams owning the remediation ticket. When that happens, Engineering picks from the queue at its own pace and MTTR never moves.
For CTEM to work, Engineering must own the remediation ticket and the SLA. Security must own the verified finding, the fix guidance, and the re-validation.
HackerOne's 36+ platform integrations, including Jira, ServiceNow, GitHub, and Azure DevOps, support this routing directly from the H1 Platform into engineering workflows.
First Cycle Completion and Retrospective
At Week 13, the roadmap closes its first loop. Pull the four metrics against the baselines set in Weeks 3 and 4.
- How did MTTR change?
- What was the difference between validated exploitable risk count on Day 90 versus Day 1?
- What was the actual attack surface coverage compared to the defined scope?
- What did the cycle reveal about blind spots the original inventory missed?
This is the moment ninety days of work shifts from an expected outcome to a measured one, with a Day 1 baseline to prove it against. Most security programs never get to point at a before-and-after this concrete.
But instead of a retrospective, this is the input that defines what Cycle 2 covers. Every blind spot the first cycle surfaces becomes a scoping decision for the second. That feedback loop is what makes CTEM continuous rather than a more rigorous version of what you were already doing.
By the end of Week 13: Every finding in the prioritized queue has a validation status (confirmed or deprioritized), all confirmed findings have engineering-owned tickets with SLAs, and the retrospective has produced a defined scope for Cycle 2. |
The 5 Most Common CTEM Implementation Mistakes
Mistake 1: Starting With Tooling Instead of Governance
Most teams buy a CTEM platform before assigning ownership. The tool cannot fix the organizational question of who is accountable when a validated finding sits unresolved for three weeks past its SLA. No amount of product capability closes the gap that undefined accountability creates. Get governance in place before a single tool is evaluated.
Mistake 2: Scoping Too Broadly on the First Cycle
Trying to cover the entire attack surface in Cycle 1 means Scoping never finishes cleanly enough to run Discovery well. The inventory is incomplete, the prioritization queue has no meaningful ranking, and the Validation list is too long to take action. Start with one business-critical service, run a clean cycle, then expand after.
Mistake 3: Skipping Validation
Most of what most programs treat as urgent is not actually exploitable. Programs that route scanner findings directly to Engineering without Validation are committing remediation resources to findings that will be closed as not-exploitable after Engineering has already spent time on them. Validation is the stage that makes CTEM worth the investment. Skipping it produces expensive, better-labeled VM.
Mistake 4: Security Team Owns Mobilization
If Security owns the remediation ticket and Engineering picks from the queue on their own schedule, MTTR never improves. The accountability gap between Security flagging a finding and Engineering resolving it is exactly what an unresolved SLA exploits. Engineering must own remediation with a defined SLA. Security provides the validated finding and re-validates the fix.
Mistake 5: Declaring Success After One Cycle
CTEM compounds. The second cycle is faster than the first because the inventory is already built, governance established. The third cycle is faster than the second. Organizations that run one cycle and revert to periodic scanning lose all the compounding value the framework is designed to generate. The goal of Day 90 is a cadence the team knows how to run again.
What the First 90 Days Should Produce: Benchmarks
What should a team expect after 90 days? The honest answer is that the first cycle's output is a baseline, not a result. The value of CTEM is comparative, and the comparison requires a before-state to measure against. Here is what mature HackerOne programs show across the three metrics established in Weeks 1 through 4.
- Mean Time to Remediate (MTTR): mature HackerOne programs see meaningful MTTR reduction between Cycle 1 and Cycle 3 as the routing from validated finding to engineering owner becomes operationalized and SLAs become enforced. Cycle 1 rarely produces dramatic MTTR improvement because governance is still being established. Cycle 1 MTTR is the benchmark. The win comes in Cycle 2 and 3 when that number moves.
- Validated Exploitable Risk: after one full cycle, teams with active Validation typically confirm that roughly 26% of their prioritized findings are genuinely exploitable and require immediate remediation, consistent with the 74% dead-end rate cited earlier.
- Attack Surface Coverage: by Week 13, the defined starting scope should be under continuous discovery coverage. Every shadow IT or unmanaged asset discovered during the first cycle becomes the scoping input for Cycle 2, which means the inventory improves with each cycle rather than requiring a periodic audit to refresh it.
These benchmarks are starting points, not guarantees. The most important output of the first 90 days is a repeatable operating cadence the team knows how to run again.
Beyond 90 Days: What Cycle 2 Looks Like
By the end of Cycle 1, the program includes real data about what its attack surface actually looks like, where the inventory was wrong, and which finding types its current tooling misses.
Cycle 2 uses all of it. Scope expands based on what the first cycle surfaced rather than what seemed important before any testing ran. AI systems come into scope if they weren't already.
Validation goes deeper on the new scope areas through expanded bug bounty coverage or a more targeted PTaaS engagement. Each cycle is faster than the last because the foundation it's building on is more solid.
See how H1 Platform enables CTEM across discovery, validation, and mobilization
1. Gartner, "How to Manage Cybersecurity Threats, Not Episodes," 21 August 2023
