Transition to Subject
One phase complete. The next begins.
Alert told the analyst what fired and gave the signal structured shape. Subject is the next step: who acted, with what credentials, and in what context. Done well, the transition is invisible. The work flows from one phase to the next without the analyst having to re-derive what they already knew.
What the transition is for
The handoff between phases is where investigations either gather momentum or stall. A clean Alert-to-Subject transition does three things:
Hands forward structured alert data
Parsed metadata, validated signal, detection mechanism context.
Identifies the entities
Primary, secondary, and high-value targets that need Subject-phase analysis.
Frames investigative parameters
Analysis depth, time window, escalation thresholds.
What Alert hands off, and what it only flags
One of Alert’s three deliverables is finished work; the other two are honest lead lists. Alert does not classify assets, reconstruct attack chains, or score business impact; those verdicts belong to Subject, Scope, Uncover, and Risk. What Alert owes them is the validated alert plus every flag worth carrying forward, so no later phase starts from a cold read.
🔧 Finished: the validated alert
- Detection mechanism analysis, what fired, by what logic, with what confidence per the trust-calibration table.
- Structured alert data, normalized fields: processes, commands, hashes, identifiers.
- Validation results, the four-dimensional check on signal fidelity.
- Telemetry correlation, cross-platform context tying the alert to its environment.
🧭 Leads for Subject and Uncover
- Baseline anomalies noticed, anything that looked off against casual knowledge of the entity. Subject owns the real behavioral analysis.
- Correlations spotted in validation, related events worth chasing. Uncover owns the attack-chain reconstruction.
- Intel hits captured, IOC or TTP matches recorded as leads, not conclusions. Uncover owns the fusion and attribution.
- Temporal anchors, the timestamps that fix the chronology later phases build on.
🚩 Flags for Scope, Risk, and Escalation
- Possibly critical assets named, systems that look important. Scope classifies criticality; Alert just raises the flag.
- Regulated-data proximity noted, signs the case may touch PCI, PHI, or PII scope. Scope’s regulatory pillar does the mapping.
- Early severity signals, observations Risk will weigh. No impact score is assigned here.
- Escalation criteria in sight, if any pre-defined criterion already looks close to confirmed, say so now: a criterion confirmed at any phase escalates immediately under the break-glass rule.
Preparing for Subject analysis
Alert told you what fired. Subject asks who acted. To make that question answerable, organize three things before you start.
Entity identification
From the parsed Alert data, list every Entity Any discrete actor or object that evidence can attach to during an investigation: a user account, a host, a process, an IP address, a domain, a file. Triage decomposes an alert into its entities and asks what each one was doing; the same idea gives UEBA its E. that touched the activity:
- Primary entities: users, systems, services directly named in the detection.
- Secondary entities: related accounts, connected systems, dependent services that may have been affected.
- High-value targets: critical assets or privileged accounts that could become targets for Lateral Movement Adversary traversal from the initial-access host to other hosts inside the environment. Each hop expands the blast radius and adds new entities for Subject analysis. Often piggybacks on legitimate authentication, which is what makes it hard to detect. .
Context requirements
The Subject phase needs organizational context the Alert phase didn’t have to assemble:
- User The identity behind activity on a system: the account that authenticated, launched the process, or received the email. In triage the user field names an account, not necessarily a person; whether the legitimate owner was actually behind the activity is exactly the question stolen credentials raise. role information: job functions, department, business responsibilities.
- System classifications: criticality ratings, data sensitivity, operational importance.
- Relationship mappings: network connectivity, access dependencies, trust relationships.
Investigation parameters
Set the shape of the Subject-phase work before you start:
- Analysis depth: how much behavioral, authorization, authentication, and relationship analysis is the alert worth?
- Time boundaries: historical window for baseline comparison and pattern detection.
- Escalation thresholds: what would the Subject phase need to find to confirm an escalation criterion? Name it now, because confirmation at any phase fires the break-glass rule immediately, without waiting for Risk.
The handoff is the artifact
If a peer picked up this alert tomorrow, would the Alert-phase work give them a clean starting point? That’s the test. The transition isn’t ceremony, it’s quality assurance for everything downstream.
Key Takeaway
A clean Alert phase ends with its three deliverables: the validated alert (finished work), the leads for Subject and Uncover, and the flags for Scope, Risk, and Escalation. The Subject phase doesn’t re-derive that work. It builds on it.
Worked examples live on the Example page
The full three-case walkthrough, Case A (the finance-team phishing intrusion), Case B (the Cursor IDE Empire-pattern benign true positive), and Case C (the SaaS-tenant token theft), is on the Alert working example page. All three cases continue on every later chapter’s example page, so you can follow the same investigations all the way through Documentation.
Haven’t taken the chapter quiz yet?
Nine questions test how you would apply what you have learned to fresh scenarios. Worth doing before you move on to Subject.
Where you are in the methodology
Continue to Subject
You’ve finished Alert. The principles above describe what Alert hands forward; the next chapter, Subject, picks up the work of identifying every entity in play.