Scope and Severity

What is it?

Scope is the blast radius: every asset, account and dataset the intrusion actually reached or plausibly could reach. Severity is how bad that is, expressed with a separate, honest confidence in how sure you are.

Why it matters

Response is sized to scope: contain one host and you miss the three it pivoted to; declare a company-wide breach on one host and you waste the whole team. Severity drives priority, and separating severity from confidence stops 'we are not sure' from downgrading a genuinely critical incident.

Where you see it

In the scope list on the case (assets/accounts/data, each marked confirmed or suspected) and in the severity/confidence fields that drive the escalation and the response team's size.

What normal looks like

A clean scope separates confirmed reach (evidence shows the attacker touched it) from potential reach (the account had access, so it must be checked), and severity is stated with its own confidence, not blended into one hedged number.

What suspicious looks like

A scope stated as a single host when the compromised account had domain-wide rights, or a severity quietly lowered because the analyst was unsure — hiding a critical incident behind low confidence.

How analysts investigate

Start from the compromised entity and ask what it could reach (its access), then what evidence shows it did reach (confirmed). List both. Rate severity on impact if the potential reach is real, and state confidence separately so 'critical but uncertain' escalates as critical.

Common beginner mistakes

Scoping to only what is confirmed, ignoring what the compromised account could still reach and must be checked.
Blending severity and confidence into one number, so an uncertain-but-critical incident is triaged as medium.

Confirmed reach vs potential reach

  compromised: account svc-backup (domain-wide read on file servers)
  ┌─ CONFIRMED reach (evidence) ─────┬─ POTENTIAL reach (access) ──────────┐
  │ FS-02  (archive built + upload)  │ FS-01, FS-03 … FS-09 (same rights)  │
  │ WS-19  (initial foothold)        │ any share svc-backup can read       │
  └──────────────────────────────────┴─────────────────────────────────────┘
  severity = impact IF potential reach is real   |   confidence = how sure (separate)

Scope lists confirmed reach and potential reach separately; severity is rated on impact, with confidence stated on its own.

Worked example. The compromised account is svc-backup, which can read every finance file server. Confirmed reach: WS-19 (foothold) and FS-02 (archive + upload). Potential reach: FS-01 through FS-09, because the same account can read them and they have not yet been checked. Severity: high — the data at risk is the finance share, regardless of how much is confirmed exfiltrated. Confidence: medium on the full extent (only FS-02 confirmed). You escalate as a high-severity incident and hand IR a check-list of the potential-reach hosts, rather than under-scoping to 'one server' or hiding the severity behind the uncertainty.

Quick check

A compromised service account has read access to 40 servers; you have confirmed attacker activity on 2. How do you scope it?

A quick self-check — it doesn't affect your XP or progress.