A CTEM program is easy to describe: the five stages fit into a neat diagram that’s often touted in PowerPoint slides and one pagers. But turning them into an operating rhythm your team actually runs, with named owners, a real cadence, the right tooling, and one place where the work lives, takes design work that no framework diagram covers.
The Gartner CTEM framework, short for Continuous Threat Exposure Management, is an operating model for finding, proving, and reducing your organization’s exposure on a repeating cycle instead of once a year. Gartner introduced it in 2022, and predicted that organizations prioritizing security investments through a CTEM program would be three times less likely to suffer a breach by 2026.
This guide is about the part that comes after the diagram. We’ll walk through each stage the way you’d actually build it, including what to inventory, how to find the assets nobody told you about, how to sequence remediation when everything looks urgent, and what to put in your stack.
If you’re still deciding whether a CTEM program makes sense for your organization, start with our case for why every organization needs one. If you’ve already made that call, keep reading.
What Is the Gartner CTEM Framework?
TL;DR: The Gartner CTEM framework is a five-stage operating model, running from scoping through mobilization on a repeating cycle. It describes how your organization operates, so no purchase can deliver it for you.
Gartner published CTEM as a way out of the point-in-time assessment trap. A penetration test tells you what was true on a Tuesday in March. Your environment doesn’t hold still for the rest of the year, so the report ages badly and the gap between what you know and what’s actually exposed widens every week.
The framework replaces that snapshot with a loop:
| Stage | The question it answers |
|---|---|
| 01Scoping | What are we protecting, and what’s in bounds for this cycle? |
| 02Discovery | What exists across that scope, including the things we didn’t know about? |
| 03Prioritization | Of everything we found, what gets fixed first? |
| 04Validation | Which of these exposures can an attacker actually use? |
| 05Mobilization | Who fixes it, by when, and how do we prove it got fixed? |
An important thing to note is CTEM is a framework and an operating model. It isn’t a product category. Gartner has since defined specific platform categories that support the framework, including Exposure Assessment Platforms (EAP) for the assessment and prioritization side and Adversarial Exposure Validation (AEV) for the proof side. You can buy tools that power a CTEM program. You can’t buy the program itself, because it lives in your cadence, ownership model, and decisions.
That distinction is why most CTEM implementations stall. Teams purchase a platform, set it up, and wait for the program to appear. It doesn’t. The program is the work below.
Before Stage One: Establishing the Program Foundation
TL;DR: Name an owner, set a cycle length, and agree on where findings live before you scan anything. Programs that skip these three decisions tend to produce reports nobody acts on.
Three decisions come before scoping, and skipping them is the single most common reason a CTEM effort fizzles after two months.
Who owns it?
One named person, not a committee. In a large enterprise this may be the security operations lead. In a 40-person startup it’s frequently the head of engineering or the one security hire. The owner doesn’t do all the work – the owner is accountable for the loop continuing to turn.
How long does a cycle run?
Pick something you can sustain. Monthly(?) cycles work well for organizations with continuous discovery already in place. Quarterly is realistic for most teams starting from zero. The cycle length matters less than the fact that it repeats on a calendar rather than when someone remembers.
Where do findings live?
One system of record, decided up front. This becomes your mobilization backbone later, and retrofitting it after six months of findings scattered across email threads, scanner exports, and PDF reports is genuinely painful.
Write these three answers down. That document is the seed of your program charter.
Stage 1: Scoping (Build the Inventory Nobody Has)
TL;DR: Scoping means enumerating everything that could expose you, across digital assets, your security tooling, your non-security tooling, and your people. Then you choose which slice of that inventory this cycle covers.
Scoping gets treated as a formality. It’s the stage that determines the quality of everything downstream, because every blind spot you accept here gets inherited by all four stages that follow.
Real scoping happens in three passes.
Pass One: Enumerate Your Digital Assets
Take inventory of every way an attacker could reach you. Not the tidy list in your CMDB, the real one. Work through these categories and write down what you find:
- External footprint: domains, subdomains, IP ranges, > public-facing servers, VPN and remote access endpoints, DNS > records, certificates
- Internal network: Active Directory, domain controllers, file > servers, workstations, network segments, printers, IoT and OT > devices
- Cloud: AWS, Azure, and GCP accounts, storage buckets, serverless > functions, container registries, Kubernetes clusters, > cross-account trust relationships
- Email and collaboration: mail servers, Microsoft 365 or Google > Workspace tenants, shared drives, SSO configuration
- Proprietary applications: web apps, mobile apps, internal tools, > admin panels, staging and dev environments
- APIs: public APIs, partner integrations, undocumented internal > endpoints, API keys and tokens
- Code and repositories: GitHub, GitLab, Bitbucket, CI/CD > pipelines, package registries, secrets in version control
- People: employees, contractors, help desk staff, executives, and > anyone with elevated access or the authority to move money
It’s easy to forget, but that last one belongs on the list. Your staff are part of your attack surface, and social engineering remains one of the most reliable ways into an environment. A CTEM scope that covers only technology is scoped incorrectly.
Pass Two: Enumerate Your Security Stack
Now inventory the tools you’ve already bought. Every control you own is something that either works or gives you false confidence, and you can’t validate it in stage four if you never wrote it down.
Go category by category:
- Endpoint detection and response (EDR/XDR)
- SIEM and log aggregation
- SOAR and automation
- Email security and anti-phishing
- Firewalls, WAF, and network security
- Identity and access management, MFA, PAM
- Cloud security posture management (CSPM)
- Vulnerability management and scanning
- Backup and recovery
- Data loss prevention
- Security awareness training
For each one, record three things: what it covers, who administers it, and when it was last verified as working. It’s ok if that third column is empty – the emptiness is informative.
Pass Three: Enumerate Everything Else
The non-security stack is where a surprising amount of exposure hides, because it’s rarely anyone’s security responsibility.
- CRM and sales tools holding customer data and integrated with half > your other systems
- Communication platforms like Slack and Teams, including third-party > apps installed in them
- AI tools: which models your teams use, what data goes into them, > which have API access to internal systems, and what’s running > without approval
- Finance, HR, and payroll systems with access to payment rails and > personal data
- Marketing and analytics tools with tracking scripts on your > production website
- Third-party SaaS generally, including OAuth grants and service > accounts with standing access
Shadow AI deserves particular attention right now. Teams adopt AI tools faster than security reviews them, and those tools often receive broad access to documents, code, and customer records.
Then Narrow It
You’ve now got a large, uncomfortable list. Scoping means choosing what this cycle covers, not testing all of it at once. Gartner’s guidance is to scope by business impact, and there’s no cap on how many scopes you run over time.
For a first cycle, a defensible scope looks like: your entire external attack surface, plus one crown jewel system, plus the identity layer that protects both. That’s a real CTEM program. Expand from there.
Stage 2: Discovery (Find What Isn’t on the List)
TL;DR: Discovery surfaces the assets and attack paths your inventory missed, including shadow IT, forgotten infrastructure, and chained weaknesses. It also tests whether your existing controls catch any of it.
Scoping records what you know, Discovery finds what you don’t. Five things belong in this stage.
Unknown Assets and Shadow IT
Forgotten staging servers, a subdomain pointing at a decommissioned cloud instance, a marketing microsite spun up outside IT, an S3 bucket from a project that ended two years ago. These are the assets attackers find first, precisely because nobody is watching them.
Two approaches find them, and you want both. A platform like SecureIQ continuously maps your external attack surface and flags new or changed assets as they appear. Human-led testing, whether from an internal red team or an external partner, finds the things that require someone to follow a hunch: the naming convention that reveals a whole class of hosts, the acquisition whose infrastructure never got merged, the exposed credential in a public repository that unlocks something else entirely.
Attack Paths, Not Just Vulnerabilities
A list of CVEs isn’t a picture of risk, what matters is how weaknesses connect. An outdated service on a low-value host looks like a medium severity finding until you notice it shares credentials with a system that has a trust relationship with your domain controller. Individually, three medium findings. Together, a path to full compromise.
Discovery should map those chains. That’s the difference between knowing you have vulnerabilities and knowing how you get compromised.
Whether Your Controls Actually Work
You inventoried your security stack in scoping, now it’s time to test it. Is your SIEM flagging adversary techniques inside your network, or are the rules tuned in a way that misses them? Does your EDR block the tools an attacker would actually use, or only the ones in the demo? Do your access controls hold across every product, or does one legacy application accept credentials the rest of your environment rejects?
The only way to know is to run the techniques and watch what happens. A misconfigured SIEM produces the same dashboard as a working one right up until the day it matters.
Third-Party, SaaS, and Supply Chain
Your exposure includes exposure you don’t operate. Supply chain compromise, a vulnerable dependency, an over-permissioned SaaS integration, or a misconfigured security tool itself. Security products get misconfigured like any other software, and an EDR agent with excessive privileges and a weak management console is a genuinely attractive target.
Inventory OAuth grants, service accounts, and standing third-party access. Ask what each integration could reach if the vendor were compromised tomorrow.
The Human Layer
People are an entry point, and testing that means running the exercises: phishing, smishing, vishing, and increasingly deepfake voice and video impersonation of executives. The goal is not to shame employees, it’s to find where a process, rather than a person, makes compromise easy. A help desk that resets MFA on a convincing phone call is a process failure, not a training failure.
Our Take: Scoping and Discovery Need Both Machines and People
TL;DR: Automation gives you breadth and speed. Humans give you curiosity, which is what attackers rely on to get in and what no tool has ever had.
Here’s where we’ll depart from the standard framework write-up.
A lot of CTEM guidance treats discovery as a tooling problem. Buy an attack surface platform, connect your scanners, and the discovery stage is handled. Tools are genuinely good at this. They’re fast, they never get bored, and they cover ground no human team could cover manually.
What they don’t do is wonder.
A scanner checks the things it was built to check. It will never look at an odd hostname and think, “That’s strange, I wonder what happens if [blank]?” It won’t notice that your support portal and your customer portal share a session cookie domain and follow that thread for three hours. It won’t read your engineering team’s conference talk, realize which internal tool they described, and go looking for it.
Attackers do all of that. Curiosity is their real advantage, more than any exploit. The successful ones are people who kept pulling on a thread after the automated tooling reported nothing interesting.
Which is why humans in the loop matter for discovery, not only for validation. The standard framing puts automation on discovery and humans on confirmation. That undersells it. Human testers find entire categories of exposure that automation isn’t structured to look for, and they find them by being curious in ways that can’t be encoded as a rule.
The practical answer is a mix. Continuous tooling for breadth, coverage, and the always-on cadence that makes the program continuous. Human-led services for depth, creativity, and the findings nobody thought to write a check for. Organizations that pick only one end up with either a wide, shallow picture or a deep snapshot that quickly expires. Neither is a program. We’ve made the fuller argument for that mix in why automation alone won’t secure your organization.
Stage 3: Prioritization (Decide What Gets Fixed First)
TL;DR: Sequence remediation in three tiers: what hands an attacker the keys right now, what puts you out of compliance, and what your team can realistically afford to fix. Severity scores alone make a poor ranking.
You’ve scoped your environment and mapped your exposures. Now comes the hard part, because everything on the list looks urgent and you can’t address everything at once.
Work through these three questions in order.
First: what’s mission critical right now? An actively exploited zero-day on an internet-facing system. Anything that gives an attacker your internal network or your domain immediately. A path to your crown jewels that doesn’t require a chain of unlikely events. These jump the queue regardless of what a severity score says, and the presence of active exploitation in the wild should override almost any other input.
Second: what puts you out of compliance? Some exposures carry regulatory consequences that arrive faster and more predictably than an attacker does. If a finding maps to a PCI-DSS, HIPAA, CMMC, SOC 2, or ISO 27001 control you’re currently attesting to, it carries weight beyond its technical severity. Compliance mapping is one of the more useful things a platform can automate here, because manually cross-referencing findings against control sets consumes days.
Third: what’s your risk tolerance, and what can you afford? This is the question most frameworks skip and every real team confronts. Do you have the budget, people, and maintenance window to fix this? A remediation that requires replacing a system your operations run on is a different decision than a config change. Rank by business impact against the actual cost of fixing it, and be honest when the answer is not this month.
That honesty is what makes prioritization work. A long, ranked list everyone ignores is worse than a shorter list your team commits to. Generic severity scoring makes a poor proxy for either exploitability or business impact, which is why prioritization is its own stage rather than a sorting step.
Stage 4: Validation (Prove It’s Actually Exploitable)
TL;DR: Validation separates theoretical findings from exploitable ones. A large share of flagged vulnerabilities can’t be used in your environment, and knowing which is which lets a small team stop chasing noise.
Validation answers one question: can an attacker actually use this, here, in our environment?
A meaningful share of what discovery surfaces won’t survive that question. A vulnerability sitting behind three layers of network controls on a segment nothing routes to. A flagged CVE for a module you don’t have loaded. A finding that requires local access to a system nobody can physically reach. These are real findings in the abstract and non-issues in practice, and treating them as urgent burns the credibility of your whole program with the engineering teams you need on your side.
Legacy systems are where this gets most useful. Every organization has a system that can’t be patched without breaking a process the business depends on, or that would cost more to replace than the risk justifies this year. Validation tells you whether that system is genuinely reachable and exploitable, which turns an argument into a decision. If it’s exploitable, you know what compensating controls need to go around it. If it isn’t, you’ve documented why the risk is accepted, with evidence, which is exactly what an auditor and a board want to see.
AI helps here, and it helps a lot. Automated validation and agentic testing can attempt exploitation at a scale and speed human teams can’t match, and the capability is improving quickly. What we’ve consistently seen is that people still want a person to look at it. Not because the automation is wrong, but because the decision that follows validation, whether to take a production system offline, accept a risk, tell a customer, etc. is a decision people want a named expert behind. Automation finds and attempts. Humans confirm, contextualize, and sign their name off.
Stage 5: Mobilization (Get It Fixed and Prove It)
TL;DR: Mobilization routes validated findings to the people who can fix them, with named owners and deadlines. It works best from one system of record that pushes work into the ticketing tools your engineers already use.
Everything up to this point produces knowledge. Mobilization produces change, and it’s where more CTEM programs die than any other stage.
The requirement is unification. All of it in one place: platform output, penetration test results, red team findings, cloud misconfigurations, code review results, and the validation status of each. When findings live in five formats across five owners, prioritization decisions get relitigated constantly and nothing closes.
A spreadsheet can be that place. If you’re a small team running quarterly cycles, a well-maintained sheet with columns for finding, asset, validation status, owner, due date, and remediation evidence will genuinely work. Don’t let anyone tell you a program isn’t real without a platform.
What a spreadsheet can’t do is move in both directions. That’s the argument for a platform, and it’s a practical one rather than a marketing one. A spreadsheet holds findings. A platform pushes a validated finding into Jira or ServiceNow as a ticket with the right owner and the right context attached, then reads the status back when the ticket closes, then confirms the fix on the next scan. Your engineers stay in the tools they already live in, and your security team gets an accurate picture without chasing anyone for updates. That bidirectional flow is the difference between a tracker and an operating system for remediation.
Whichever you choose, three things need to be true of every validated finding: it has a named owner, it has a deadline tied to its priority tier, and closing it requires evidence rather than an assertion. And finally, retesting closes the loop. A finding marked fixed that was never verified is a finding you’ll rediscover next cycle.
Closing the Loop: Then You Start Again
TL;DR: Once remediation is verified, the cycle returns to scoping with updated context. That repetition is what makes exposure management continuous rather than periodic.
When the fixes are verified, you go back to scoping. That’s not a formality – your environment changed while you were working, and so did your understanding of it.
Each pass compounds. Scoping gets sharper because you learned which assets actually matter. Discovery gets faster because your inventory is organized better. Prioritization gets smarter as threat intelligence and business context accumulate. Validation gets cheaper because you’ve already established which systems are genuinely reachable.
And the conversation with leadership changes. After one cycle you have a list of problems, but after four, you have a trend line, evidence of exposure reduction over time, and a defensible answer to the questions an executive will likely ask: are we exposed, do our controls work, and are we improving.
Track a small number of metrics from cycle one so that trend line exists later, like:
- Time to remediate by priority tier
- Percentage of validated critical findings closed within SLA
- Number of previously unknown assets discovered per cycle
- Mean age of open validated exposures
Building Your CTEM Stack: What You Need at Each Stage
TL;DR: Every stage needs a mix of tool categories and human-led services. Map the table below against what you already own before you buy anything new.
Before buying anything, map this against your existing stack. Most organizations already own tools that cover two or three of these categories and they may or may not be connected.
| Stage | Tool categories | Human-led services |
|---|---|---|
| 01Scoping |
|
|
| 02Discovery |
|
|
| 03Prioritization |
|
|
| 04Validation |
|
|
| 05Mobilization |
|
|
Some advice here: you don’t need one product per row, and you shouldn’t try. The goal is coverage of the categories, ideally consolidated into as few systems as your environment allows. And the services column isn’t optional garnish. It’s where the depth comes from, for the reasons covered above.
Where CTEM Programs Stall
TL;DR: Four patterns account for most stalled programs: scoping too broadly, treating the platform as the program, skipping validation, and running the loop once. All four are avoidable.
Scoping the entire environment in cycle one: the inventory takes two months, nothing gets fixed, and leadership loses patience before the program produces a single win. Narrow scope, fast first cycle, expand from there.
Buying a platform and calling it a program: the tool produces findings. Without an owner, cadence, and mobilization path, the findings accumulate and the dashboard becomes something nobody opens.
Skipping validation: sending unvalidated scanner output to engineering teaches them that security findings are noise. Once that reputation sets in, the genuinely urgent finding gets the same shrug as everything else.
Running the loop only once: a single cycle is an assessment with extra steps. The value is entirely in the repetition, and the second cycle is where the compounding starts.
How SafeHill’s SecureIQ Supports Each CTEM Stage
TL;DR: SecureIQ gives you a team of AI hackers covering every stage of the loop, with SafeHill’s human ethical hackers validating what matters. The agents provide continuity and coverage, and the people provide curiosity and judgment.
SecureIQ is a Threat Exposure Management platform built as a team of AI hackers. Each one is an agent with its own specialty, and each is backed by SafeHill’s human ethical hackers. The structure is deliberate: agents give the program the continuity a CTEM loop requires, and people supply the curiosity and judgment that automation can’t.
Scoping and discovery: the External hacker continuously maps your external attack surface, monitors credential exposure and dark web activity, and correlates threat intelligence against what it finds. The Internal hacker works inside your domain on network and Active Directory auditing. The Cloud hacker covers AWS, Azure, and GCP configuration. The Web and API hacker tests your applications and endpoints, and the Code hacker reviews source for flaws before they ship. Findings from all of them flow back into SecureIQ, so your program runs off one inventory instead of five tools’ worth of separate output.
Prioritization: SecureIQ’s attack path prioritization engine ranks findings by reachability, active exploitation, and business impact, with compliance mapping that ties validated exposures to the frameworks you report against.
Validation: Sentinel, the validation agent, proves exploitability by reproducing attacks rather than inferring them from version numbers. It chains related weaknesses into attack paths and hands the result to SafeHill’s human ethical hackers, who confirm real-world impact and add the business context automation alone can’t supply. Services including penetration testing, red team, purple team, and social engineering cover what continuous tooling isn’t structured to find.
Mobilization: Remediation orchestration pushes prioritized, validated findings into the ticketing systems your teams already use, and retesting is included so closure means verified rather than asserted.
If you’re building a program from scratch and want the operating model designed with you, SafeHill’s CTEM Program Creation and Implementation engagement does exactly that over four to eight weeks. If you’d rather start by seeing what’s currently exposed, SecureIQ Lite’s free web app scan returns results within the hour.
Get the CTEM Implementation Checklist
We’ve turned everything above into a downloadable checklist, one page per stage, with the inventory prompts, questions to ask, and tool and service categories that belong at each step. It’s designed to be worked through with your team rather than read once.
Download the CTEM Program Implementation Checklist via the form below.
If you’d rather talk it through, book a call with a SafeHill expert and we’ll walk you through your environment stage by stage.
What is the first step in implementing a CTEM program?
Name an accountable owner, set a cycle length you can sustain, and decide where findings will live. Those three decisions come before any scanning. Programs that skip them tend to produce reports nobody acts on, because there is no one responsible for closing the loop.
How long does it take to build a CTEM program?
A first cycle typically runs four to eight weeks for a mid-sized organization: one to two weeks on scoping and inventory, two to three weeks on discovery and validation, and the remainder on prioritization and remediation. The program becomes genuinely useful around the third cycle, once you have trend data and a refined scope.
Who should own a CTEM program?
One named person, not a committee. In a large enterprise that is usually the security operations or exposure management lead. In a smaller company it is often the head of engineering or the first security hire. The owner does not do all the work, but is accountable for the cycle continuing to turn.
What is the minimum team required to run a CTEM program?
One accountable owner. Everything else can be sourced. Lean teams often get the most value from CTEM because the framework’s purpose is narrowing an unmanageable list to a short one, and a partner can supply the testing, validation, and remediation guidance that would otherwise require additional headcount.
What tools do you need for a CTEM program?
Each stage calls for different categories: asset inventory and attack surface management for scoping, EASM, CSPM, and code scanning for discovery, exploit intelligence and attack path analysis for prioritization, adversarial exposure validation for validation, and a threat exposure management platform with ticketing integrations for mobilization. Most organizations already own tools covering two or three of these and have never connected them.
Can you run a CTEM program on a spreadsheet?
For a small environment and a quarterly cadence, yes. Track finding, asset, validation status, owner, due date, and remediation evidence. The limitation shows up as you scale: a spreadsheet cannot push work into your ticketing system or read status back, so manual reconciliation grows until it consumes the time the program was meant to save.
How often should each CTEM stage run?
Discovery should be continuous if your tooling allows it. Prioritization and mobilization run on your cycle cadence, monthly or quarterly. Scoping gets a full review quarterly and a light review whenever something material changes: an acquisition, a cloud migration, a new product launch, or a significant headcount change.
Do you need to replace your existing security tools to implement CTEM?
No. A CTEM program is largely about making the tools you already own work together and proving they function under adversarial pressure. Consolidation tends to happen naturally as the program matures and redundancies surface, but replacement is an outcome rather than a prerequisite.
How does CTEM relate to SOC 2, ISO 27001, or PCI-DSS compliance work?
Compliance frameworks tell you which controls to have. A CTEM program tells you whether those controls actually hold when someone attacks them. They complement each other, and CTEM produces a useful byproduct for audits: validated evidence that findings were identified, prioritized, remediated, and verified, with dates attached.
Where does AI fit into a CTEM program?
AI handles discovery, coverage, and initial validation attempts, where speed and scale matter most. AI agents can test continuously in ways no human team can match. What they cannot do is exercise judgment, so validation and prioritization should stay accountable to a named person, because those stages produce decisions rather than findings.
What should a startup or small engineering team do first?
Scope to your external attack surface, your production application, and your identity layer. Run discovery against those three. Validate what looks exploitable. Fix it. That is a complete CTEM cycle and it takes weeks rather than quarters, then you widen the scope on the second pass.
Why do CTEM programs fail?
Four patterns account for many stalled programs: scoping the entire environment in the first cycle so nothing gets fixed, buying a platform and treating it as the program, skipping validation and sending raw scanner output to engineering, and running the loop only once. All four can be avoided with the decisions made at setup.
About the Author
Mike Pena is SafeHill’s co-founder and CEO, and a second-time founder with 15 years of C-suite and advisory experience across cybersecurity, financial services, and venture-backed SaaS. Before SafeHill, he led Chambers Key Cybersecurity through its 2021 acquisition by Alacrinet and advised Fortune 500 companies and government agencies on where their real risk sits.