The 5 CTEM Stages Explained With One Real Example

• What each of the five CTEM stages produces
• How one exposure moves from unknown to closed
• Which decisions belong to which stage
• What breaks when a stage is skipped

Stage 1: scoping

The team picks the customer portal as the scoped business service, because an outage or a data exposure there reaches customers directly. Scoping produces a written list of what the service is made of and who owns each part. The reporting server appears on that list only because someone in the room remembered it existed.

Stage 2: discovery

Discovery pulls the actual state of every component in scope. It finds the reporting server is reachable from the portal network segment, runs an outdated component with a known flaw, and authenticates using a service account that also has write access to the customer database. Three separate exposure types, one asset.

Stage 3: prioritization

Judged on its software flaw alone, the server ranks in the middle of a long list. Judged on business impact, reachability from a customer facing segment, and the overprivileged account, it moves to the top. Prioritization is where the combination matters more than any single finding, and it is the stage most teams shortcut.

Stage 4: validation

Validation confirms the path is real: the segment allows traffic, the component is genuinely exposed rather than blocked by a control, and the service account credentials would grant database write access if reused. The evidence is recorded with timestamps and screenshots. This is the artifact that will make the remediation request unarguable.

Stage 5: mobilization

Three owners are named: the platform lead for the network path, the application owner for the outdated component, and the identity lead for the service account scope. Each gets a deadline drawn from the validated risk. Closure is confirmed by retesting, not by a ticket status. The register records evidence of closure, and the next cycle checks whether the same class of exposure returns elsewhere.

• Write your scope down and get the service owner to agree with it
• During discovery, record exposure type alongside the asset so combinations are visible
• Rank on impact and reachability together, never on severity in isolation
• Attach validation evidence before you escalate anything
• Confirm closure by retesting rather than by ticket status

• Treating discovery output as the priority list
• Validating only the findings that are easy to test
• Assigning fixes to a team queue with no individual owner
• Closing exposures on the owner's word without retest evidence
• Never revisiting scope, so the register drifts from the real service