CTEM Stage 1: Scoping

Stage Summary: Scoping defines what your CTEM program will protect and how you'll measure success. Without clear scope, teams waste effort on low-priority exposures while critical assets remain at risk.

Why Scoping Matters

CTEM is an operating model for reducing material exposure, not a race to enumerate every weakness. That distinction matters because most enterprises already live with two hard constraints:

1. Exposure is effectively infinite (new assets, identities, SaaS integrations, and third-party connections appear faster than teams can document them).
2. Remediation capacity is finite (engineering bandwidth, change windows, and operational risk tolerance are limited).

Scoping is how you force CTEM to behave like a risk program rather than another high-volume technical feed. It is also the point where many initiatives fail: teams blur scoping with discovery, “boil the ocean,” and end up measuring activity (findings) instead of outcomes (risk reduction).

A good scope is not a CMDB export. It is a business risk hypothesis stated in operational terms:

• “If we continuously reduce exposures affecting these services/assets, we meaningfully reduce the likelihood and blast radius of incidents that matter to the enterprise.”

Scoping principles that hold up in real environments

• Start narrow; iterate aggressively. A first CTEM cycle should fit inside a quarter without heroic effort.
• Define scope in business terms first, technical terms second. Start with services/processes, then map to systems and identities.
• Separate “in scope” from “interesting.” Many findings are interesting. Only some are mission-relevant.
• Write down the “done” conditions up front. If success metrics aren’t explicit, the program will drift toward vanity metrics.

Practical starting scopes that tend to work

Gartner’s guidance on CTEM pilots frequently points to two areas that balance impact and tractability: external attack surface and SaaS security posture. Use one of these as a first loop unless your risk profile strongly suggests otherwise.

What Scoping Produces

Input	Output	Why it matters later
Business priorities, risk appetite, existing asset/service catalogs	CTEM Scope Charter	Prevents scope creep; aligns stakeholders
“Crown jewels” and supporting dependencies	Critical Asset Register	Enables contextual discovery and prioritization
Threat assumptions (external, insider, supplier)	Boundary & Threat Assumption Statement	Prevents mismatched validation/testing
Current exposure-management pain points	Initial Use Cases	Ensures early wins and executive support
Reporting expectations	Success Metrics & SLAs (draft)	Makes prioritization + mobilization actionable

---

Key Activities

1. Identify Critical Assets

“Critical assets” are the systems, identities, data stores, and delivery pipelines whose compromise would cause disproportionate business harm. In practice, this is rarely just “production servers.” It usually includes:

• Identity systems (IdP, SSO, privileged access pathways)
• Sensitive data stores (customer data, financials, regulated datasets)
• Customer-facing services (auth, payments, core workflows)
• Build and deployment systems (CI/CD, artifact repositories, code signing)
• SaaS tenants that hold business-critical data or control planes

A defensible way to identify critical assets is to work from impact backward:

1. Start with a business impact lens (what failure modes are unacceptable: downtime, fraud, data exposure, safety impact).
2. Map critical business services (e.g., “customer authentication,” “order processing,” “claims adjudication,” “research data platform”).
3. Trace dependencies: identity, data, network paths, third-party integrations, and administrative planes.
4. Assign business ownership: every critical asset must have an accountable owner who can accept/transfer/mitigate risk.

A useful mental model

If an attacker controlled this asset for 30 minutes, what could they do that would change your week, your quarter, or your regulatory posture?

Minimum required attributes for a “critical asset” record

• Business service supported
• Data classification / sensitivity (at least coarse: public / internal / confidential / regulated)
• Impact rating (low/moderate/high) across confidentiality, integrity, availability (CIA)
• Technical owner + business owner
• Environment (prod, pre-prod, dev) and whether it handles real data
• External reachability and administrative exposure (where applicable)

---

2. Define Attack Surface Boundaries

NIST defines attack surface as “the set of points on the boundary of a system… where an attacker can try to enter, cause an effect on, or extract data from.” Your CTEM boundary is the operational translation of that definition: it specifies which parts of that surface you will continuously measure and reduce in this cycle.

A boundary statement should answer:

• What is in scope? (asset classes, environments, business services)
• What is explicitly out of scope? (and why)
• What attacker model are we assuming? (external unauthenticated; external with stolen creds; malicious insider; supplier compromise)
• What access constraints apply? (testing limitations, production safety rules, data-handling restrictions)
• What is the timebox and refresh cadence?

Example boundary statement (copy/paste and edit)

CTEM Cycle Scope (Q2 FY26)
In Scope:
- External attack surface for Business Services A, B, and C
- Internet-facing domains/subdomains owned by the enterprise and subsidiaries
- SaaS tenants supporting those services (CRM, collaboration, CI/CD SaaS)
- Identity pathways used to administer in-scope assets (SSO, privileged roles)

Out of Scope (this cycle):
- Internal-only lab environments without customer or regulated data
- Legacy business unit X (scheduled for divestiture within 2 quarters)
- Physical security and OT networks (handled under separate program)

Threat Assumptions:
- External attacker with commodity tooling + opportunistic exploitation
- External attacker with stolen credentials (phishing/session theft)
- Third-party compromise of a SaaS integration is plausible

Safety & Constraints:
- No exploit attempts against production without explicit change approval
- Validation activities must be non-destructive and logged
- Evidence stored in approved systems; sensitive artifacts redacted