Transition to Scope
What the transition is for
Subject ends with a map of identities. Scope’s job is to draw lines around that map: which entities are in the investigation, what time window each gets, what depth of analysis each warrants. A clean Subject-to-Scope handoff does three things.
Hands forward the entity map
Primary entities, secondary entities, high-value paths. Every identity Subject profiled, with the per-dimension assessment attached.
Surfaces investigation pressure points
Which entities most reward deeper investigation, which are confirmed clean and can be deprioritized, where the highest-impact lateral movement risks live.
Frames the parameters Scope formalizes
Time window, environmental footprint, user context. Scope turns each into an explicit boundary the rest of the investigation respects.
Four deliverables from Subject
By the time the analyst leaves the Subject phase, they should be carrying four Artifacts Digital evidence or traces left behind by system activity or security incidents, used in forensic analysis and incident investigation. . Each one feeds directly into Scope.
🗺️ The entity map
- Primary entities, identities directly named or implicated by the alert.
- Secondary entities, identities the primary entities are connected to (service accounts, federated SSO identities, peers on the same host).
- Downstream entities, systems and data the implicated identities can reach.
- Per-entity dimension assessment, authentication, authorization, behavior, relationships for each.
📊 Baselines and deviations
- Which baseline informed each verdict, individual, peer-group, or system.
- The actual values at the time of triage. Critical for defending decisions in later review.
- Confidence levels, high, medium, low. Captures the gap between “we know” and “we believe.”
- Open questions, what the baseline could not answer. These become Uncover work.
🔗 The relationship graph
- Trust paths, which identities can authenticate as which others (via SSO, role assumption, shared credentials).
- Communication patterns, who emailed whom, who shared what, who joined which call.
- Access dependencies, which systems each identity can reach if compromised.
- Lateral movement candidates, the relationships most worth Uncover-phase investigation.
🟡 Insider indicators
- Risk or threat patterns observed, mapped to the Insider Threat Matrix A community-maintained framework at insiderthreatmatrix.org that catalogs insider techniques across motivation, means, preparation, infringement, and anti-forensics. Subject uses it as a shared lens. where applicable.
- None observed is itself a worth-recording verdict. It documents the check happened.
- Escalation triggers, anything that requires HR, legal, or insider-threat program coordination.
- Behavioral signals separate from technical evidence (stress indicators, recent role changes, expressed grievance) where relevant.
Three parameters Scope needs
Subject’s map is the input. Scope formalizes it across three dimensions. Anticipating those dimensions during Subject is how the handoff stays clean.
Time boundaries
The alert has a timestamp. Investigation does not. Scope decides how far back to look (for preparation, staging, access changes that preceded the activity) and how far forward (for cascading effects, follow-on behavior, persistence).
- Pre-event window. Subject already surfaced relevant baselines and recent changes. Scope formalizes “look back N days” as a hard boundary.
- Post-event window. Has the activity continued? Stopped? Resumed under a different identity? Scope sets the watching window.
- Per-entity windows. Different entities deserve different lookbacks. A service account with stable baseline needs less history than a user whose role recently changed.
Environmental scope
Subject identified which systems each entity touches. Scope decides which of those systems are actually in the investigation. The line is rarely “everything connected to the entity” because most modern environments are too interconnected for that to be useful.
- Direct systems. Hosts the implicated identities authenticated against during the relevant window.
- Connected systems. Services the direct systems integrate with: APIs, identity providers, deployment pipelines, ticketing systems.
- Trust-adjacent systems. Systems that share credentials or trust the same identity provider. May be in scope even if the implicated identity never touched them directly.
- Out of scope. What is explicitly NOT being investigated. This is just as important. Without it, the investigation drifts indefinitely.
User context
Subject profiled the named entities. Scope decides which other users to investigate, which can be ruled out, and which need to be informed (without compromising the investigation).
- Implicated users. Subject’s primary entities, profile already complete.
- Adjacent users. Peer-group members, team-mates on the same workflows, others on the same host. Worth a baseline comparison even if no direct evidence ties them in.
- Affected users. Anyone whose data or accounts might be exposed by the activity. These often drive notification and regulatory obligations.
- Notification posture. Whether to tell users they were involved depends on the investigation type. For insider work, the default is no until coordinated with HR and legal.
The handoff itself
A complete Subject-to-Scope handoff usually fits in a structured artifact the next analyst can act on without re-deriving Subject’s work.
What the Subject deliverable looks like in practice
A clean handoff document has six sections:
-
Investigation header. Alert ID, Subject analyst, timestamp, scenario summary in two sentences.
-
Entity A person, system, or organization that interacts with or affects a security incident. inventory. Table of every identity Subject profiled. Columns: name, type ( User An individual who interacts with a system, network, or application. / service / role / host / network), classification (primary / secondary / downstream), per-dimension verdict.
-
Confidence summary. For each implicated entity, what the analyst concluded and how confident they are. Critical for Scope to know which entities are settled and which need more work.
-
Open questions. What Subject could not resolve. These become explicit Uncover-phase targets.
-
Recommended scope parameters. First-pass time window, environmental boundary, user context. Scope will refine these but the recommendation accelerates the work.
-
Insider posture. Risk or Threat An actor (or capability) with intent and means to cause harm. A vulnerability is what they exploit; risk is the product of threat, vulnerability, and impact. indicators observed, escalation triggered or not, who else needs to be in the conversation.
A handoff under one page is the goal. Most of the work is structured selection from Subject’s data, not new writing.
Common Subject-to-Scope failure modes
Subject can be done well and still fail at handoff. The following patterns reduce the value of the work.
📋 Missing the secondary identities
Subject profiled the named user thoroughly but did not surface the service account, the federated cloud identity, or the SSO trust path. Scope inherits a narrower picture than the data actually supported.
🤐 No confidence statement
”Authentication: normal” without a confidence level. Scope cannot tell whether the verdict is “we checked and verified” or “we did not see anything obviously wrong.” These are different states with different implications.
🪤 Implicit out-of-scope
Subject narrowed the investigation by silently not investigating obvious adjacent entities. Scope then has to re-discover those entities and decide whether to include them, often after time has passed.
📭 Missing insider posture
Subject’s verdict on insider risk or threat went unrecorded. Scope inherits ambiguity on whether the investigation needs HR/legal coordination, often the wrong moment to be making that call.