A small team can start continuous threat exposure management in 90 days by scoping a handful of critical services, ranking exposures with public exploitation data, validating the top ones, and fixing on a fixed weekly cadence. Skip platform shopping until you know which stage hurts.
What are we starting?
CTEM is a repeating cycle. Gartner introduced it; its page was blocked to us, so check its text at the source. The commonly cited stages are scoping, discovery, prioritization, validation and mobilization. Our plan runs one small loop quickly, then repeats it. A first loop that finishes beats a perfect plan that does not.
Days 1 to 15: scope
Pick five services or systems whose compromise would hurt most: the customer facing app, billing, the identity provider, the source code platform, the main data store. For each, write a one line impact statement ("exposes customer records") and name an owner.
Agree the unit of work: an exposure is anything that lets an attacker reach or misuse the service, including vulnerable software, exposed interfaces, weak access and misconfiguration. Write down what "fixed" means: patched, mitigated, or accepted with an expiry.
Days 16 to 35: discover
For each of the five, gather what you already have: cloud inventory, DNS and certificates, dependency lists, scanner output, identity roles. Put them in one sheet per service. Add what an outsider can see with free or built in tools.
Do not buy anything in this window. The aim is to find where data is missing. Mark each gap: no inventory of dependencies, no owner for an admin interface, no visibility into one cloud account.
Days 36 to 55: prioritize
Rank with three public inputs. CISA's Known Exploited Vulnerabilities catalog marks vulnerabilities with observed exploitation. EPSS estimates the chance of exploitation in the next 30 days. CISA's SSVC model combines exploitation, technical impact and other factors into Track, Attend or Act style outcomes. FIRST states EPSS is not a complete risk score, and the CVSS guidance says Base scores should not be used alone to assess risk, so add your own context: is the service internet facing, what data does it hold?
Make a ranked list of the top fifteen exposures across the five services. Keep to fifteen.
Days 56 to 70: validate
For each of the fifteen, ask whether it is usable. For vulnerable software, is the vulnerable code reached? For an exposed interface, is there a path from the internet, and is it protected? For a misconfiguration, can you show what an attacker would gain? Where you cannot tell, a short controlled test by your team, or an authorized tester, settles it.
Expect the list to shrink. Record what you dropped and why, because that record is the program's first proof of value.
Days 71 to 90: mobilize
Run a fixed weekly thirty minute meeting with owners. Agenda: new items, items past due, blockers. Fixes are tickets in the owners' own queue, with a due date based on tier. Put tier definitions in writing, such as "exploited and reachable: this week".
At day 90, hold a review. Show how many exposures were found, validated, fixed, mitigated or accepted, and the median time to fix. Choose the next five services. Decide where tools would help, using your sheets as the trial's ground truth.
What to measure
Share of scoped services with an owner. Time from discovery to fix for validated exposures. Number of exposures dropped at validation, which shows noise removed. Number of accepted exceptions past review date.
Common traps
Scoping the whole company. Treating scanner output as the exposure list. Skipping validation and sending engineers every finding. Counting fixes instead of reduced risk. Letting the weekly meeting lapse.
NIST SP 800-137 describes continuous monitoring as ongoing visibility into assets and control effectiveness. Your weekly cadence is a small version of that.
Where Safeguard fits
CTEM as a platform category is not sold by Safeguard, and we do not replace it. We focus on the application and software supply chain side. Reachability analysis supports the validation stage for dependencies, and policies, gates and guardrails can enforce fixes at build, CI and release.
What to do
- Scope five services and name owners.
- Gather existing inventories and mark the gaps.
- Rank with KEV, EPSS, SSVC style rules and your own context.
- Validate the top fifteen and record what you drop.
- Run a weekly fix meeting with tiered due dates.
- Review at day 90 and pick the next scope.
Quick check
Do we need a CTEM platform to start?
No. Sheets, existing scanners and public exploitation data are enough for a first loop. Buy tools when you know which stage is slow.
Why validate before fixing?
Validation removes exposures that cannot be used, so engineers spend time on real ones and trust the list.
Sources
Gartner's CTEM material could not be fetched and should be read at the source.
Last reviewed: 18 October 2026.
