How CTEM Works in Real Life: A Practical End-to-End Scenario

• What a first CTEM cycle actually looks like day by day
• How each stage hands off to the next in practice
• What outputs look like in a real cycle
• Where cycles usually get stuck and how to unblock them
• How the second cycle improves on the first

Day 1 to Day 3: Scope

The program manager meets the head of e-commerce and the checkout service owner. They agree the checkout service is the first cycle's scope because it handles card data and is customer-facing. The team writes a one-page scope brief listing the checkout web application, its API, its primary database, a payments integration, the storage bucket used for receipts, the deployment pipeline, and the on-call team.

Output: Scope brief signed by security leadership and the service owner.

Day 3 to Day 8: Discover

Security engineering pulls data from the vulnerability scanner, cloud posture tool, identity governance tool, external attack surface tool, and secrets scanner. Everything found in scope lands in a single exposure register. Duplicate findings are merged. Each row records source, asset, exposure category, and initial context.

What they find. Sixteen exposures across the seven scoped assets: two unpatched CVEs on the checkout web app, one public storage bucket, three excess-privilege service accounts, one leaked API key in an old commit, two exposed staging endpoints, one third-party library with a known issue, one microservice with no listed owner, and five lower-severity misconfigurations.

Output: Exposure register with sixteen rows.

Day 8 to Day 11: Prioritize

The exposure analyst applies business impact, reachability, exploitability, and threat context. Severity score is one input, not the ranking. The register is filtered to a short ranked list.

Output: Ranked short list with reasoning.

Day 11 to Day 14: Validate

Each top-five exposure is validated. The bucket is confirmed world readable through a safe read-only request. The leaked API key is proven still valid against a sandboxed endpoint. The excess-privilege account is walked from its trust zone to a database read, documented with screenshots. The CVE is confirmed present at the reported version. The third-party library is confirmed loaded in the payment path via dependency graph.

Result. Four of the five are confirmed real and exploitable. One is downgraded because a WAF rule blocks the CVE payload in production; that context is captured in the register.

Output: Validation evidence per item.

Day 14 to Day 21: Mobilize

The program manager routes each validated exposure to its owner with an SLA based on severity. Progress is tracked in the ticket system linked to the exposure register.

Output: Closed tickets with owner, timestamp, and evidence.

Day 21: Measure and report

The program manager writes a one-page report for the service owner and security leadership. It shows: exposures found, exposures closed with evidence, current critical exposure count on the checkout service, mean age at closure, reopened exposure rate, exceptions taken with reasons, and top three improvements for the next cycle.

Improvements identified. Add automated bucket policy checks to the deployment pipeline, expand secrets scanning to all repositories in the organization, and assign an owner to the unowned microservice discovered during scope. All three go on the roadmap for the next cycle.

Where cycles usually get stuck

How the second cycle differs

The second cycle is faster because the register exists, ownership is clearer, and the retrospective from the first cycle is baked into the process. A common pattern is that cycle two either takes half the calendar time, or covers twice the scope in the same time. Cycle three usually enables continuous overlapping cycles across several services.

To try this on your own environment, see How to Start a CTEM Program or work through The 5 Stages of CTEM.

• Copy this 21-day plan and adapt dates to your own calendar
• Pick a single business service that ranks highly for business impact
• Publish a scope brief before writing a single scanner query
• Cap the first ranked list at five exposures
• Insist on evidence for every closure, even when it feels slow

• Scoping the whole company on the first cycle
• Copying scanner output into the register without merging duplicates
• Skipping validation because a scanner already said the finding exists
• Closing tickets before retest
• Skipping the retrospective and treating the cycle as a one-off project