Blog
How to start a CTEM program in 90 days
Ninety days is enough to run one complete exposure cycle on a narrow scope and come out with evidence that the approach works. It is not enough to build a program, buy a platform and cover the estate, and any plan that promises that is a plan to fail slowly.
The goal by day 90 is modest and concrete: a signed scope, a reconciled inventory for that scope, a ranked list of exposures, ten of them validated, most of those fixed, and a one-page report with numbers on it. In the terms of our maturity model, that is a Defined program for one slice of the organisation.
Before week one: the decision that matters most
Pick a scope that is bounded, visible and has an obvious business owner. The external attack surface is the usual choice because you can enumerate it from outside, the owner is easy to find, and the findings are easy to explain. The alternative is the systems behind one revenue process, which is harder to enumerate but produces a better conversation with the business.
Do not pick “the estate”. Do not pick “critical assets” until someone outside security has said which those are.
Resist buying anything before week eight. You will learn what tooling you actually lack by running the first cycle with what you have, and the tools guide will make more sense afterwards.
The plan
| Weeks | Stage | What gets done | Output |
|---|---|---|---|
| 1 to 2 | Scoping | Name the scope, the sponsor, the business owner and the fix owners. Write it down. | One-page scope statement, signed |
| 3 to 4 | Discovery | Pull every source that sees the scope. Reconcile. Chase unknowns. | Inventory with source counts and a list of unknowns |
| 5 to 6 | Prioritisation | Rank by reachability, path to a critical asset, active exploitation, controls in place. By hand. | Ranked list with reasons, top ten agreed |
| 7 to 8 | Validation | Test the top ten safely. Record what was exploitable and what fired. | Validation log, downgrades documented |
| 9 to 11 | Mobilisation | Tickets with owner and date. Track to closure. Re-test the fixes. | Closed tickets, time-to-close per item |
| 12 to 13 | Measure and report | Five numbers, one page, and the scope for cycle two. | Leadership report, next-cycle scope |
Weeks 1 to 2: scoping
Write a scope statement of one page. It names the systems and environments in scope, the business process they support, the sponsor, the business owner who agreed the criticality ranking, and the fix owners for each system class. It also lists what is out: SaaS, identity, third-party access, whichever you are deferring, and why.
Get the business owner to sign it. This sounds ceremonial and is not. It is the thing you will point at in week ten when a remediation ticket is disputed.
The people you need in the room: a sponsor with budget, usually the CISO; a program lead who owns the cycle; whoever runs vulnerability management today; the infrastructure or platform owner for the scope; and the business owner. For an external scope, add whoever manages DNS and the cloud accounts.
Weeks 3 to 4: discovery
Collect every source that sees the scope: the vulnerability scanner, the cloud provider’s inventory and posture findings, EDR agent lists, the CMDB, DNS records, certificate transparency logs, and for an external scope, an outside-in scan. Free and low-cost tools are adequate for a first cycle.
Reconcile. The number to write down is the count of assets seen by one source and not another. It will be larger than anyone expected, and it is your first honest metric. Every unknown becomes a ticket to classify or retire.
Include non-CVE exposures from the start: exposed management interfaces, default credentials, over-permissive cloud roles, stale admin accounts. If discovery only produces CVEs, the cycle will only ever fix CVEs.
Weeks 5 to 6: prioritisation
Rank by hand for the first cycle. It is slow, and it teaches you exactly what data you are missing.
For each finding, record four things: is it reachable from where an attacker would start; does it sit on a path to something the business owner ranked as critical; is it being exploited in the wild, using the CISA KEV catalogue and EPSS; and is there a control in place that would block it. Sort on those before looking at CVSS.
Agree the top ten with the business owner and the fix owners. Their disagreement is useful information; write down why.
Weeks 7 to 8: validation
Validate the top ten. For an external scope this is a targeted test of each exposed service: can it be reached, can it be exploited, what does it give access to. For internal scopes, a short engagement with a tester, or a trial of an automated tool, does the job.
Record two results per item: was it exploitable, and did anything fire. A validated exposure that nobody detected is two findings, and the second one is often the more important.
Expect surprises in both directions. Some of the top ten will not be exploitable, and downgrading them is a win. Some will be worse than the scanner suggested.
Weeks 9 to 11: mobilisation
Open a ticket for each validated exposure in the fix owner’s own workflow tool. Every ticket has a named owner outside security and a target date. Refuse to open one without both.
Track weekly. When a fix is reported closed, re-test it before it counts. Record days from validation to verified closure for each item; that is your time-to-close baseline.
Some fixes will not land in the window. That is fine. Record why, and whether it was capacity, disagreement or a change freeze. Those reasons are the design brief for cycle two.
Weeks 12 to 13: measure, report, widen
Write one page. Five numbers: validated exposures open, median time to close, critical processes with no validated attack path, coverage of scope, and validation rate. The metrics post defines each. Add one paragraph on what changed and one on what cycle two will cover.
Then widen. Add one adjacent scope, not five. Add one discovery source you lacked. Decide, on evidence from the cycle, whether you need a tool and for which stage.
Common failure modes
Scope creep in week one. Someone adds identity, SaaS and the cloud estate because they are important. They are, and they will be in cycle three.
Buying the platform first. The platform arrives, integration takes a quarter, and the program becomes the platform rollout. Run a cycle with what you have and buy for the gap.
Skipping validation because there is no tool. Ten items can be validated by a person in two weeks. The stage is not optional; it is the one that separates the program from vulnerability management.
Tickets without owners. Security opens them, security tracks them, security closes them. Nothing changes.
Reporting counts. “We found 3,400 findings and fixed 900” tells leadership nothing they can act on. Report the five numbers.
Treating it as a project. Cycle one ends on day 90. Cycle two starts on day 91 with a wider scope. If the calendar does not already have cycle two on it, it was a project.
Next
Take the quick check before week one to find which stage will be hardest for you, and read What is CTEM if any of the five stages is unfamiliar. The full assessment scores all five stages, and the vendor directory helps once you know which gap to fill.