Documentation working example
The first scenario: closing the finance-team record
Closing the case durably
Escalation handed the case to IR, and from that moment IR owns the case: IR contains the intrusion, and IR writes the post-incident report. The triage analyst's Documentation phase finalizes the triage-side event report and links it to IR's outputs, not the other way around.
Step 1. Capture the record
The nine-section event report template (see Standards) is filled, ideally in real time as the investigation ran. The handoff packet maps into it per the crosswalk in Standards: the summary, timeline, entities, evidence chain, verdict, and containment feed sections 01-04 (event overview, timeline, origin & scope, actions taken); the open questions are carried explicitly into recommendations rather than dropped; the communication record lands verbatim in the appendices. The report covers triage’s work up to the handoff. The IR responder’s findings belong to IR’s post-incident report, which this record links to rather than absorbs. Sections 05-09 (business impact, IOCs, lessons learned, post-event recommendations, appendices) are added during the Documentation phase as the triage-side picture completes.
What a less experienced analyst could miss: the temptation to smooth the timeline in hindsight. This case’s P1 was declared hours later than the criteria justified, and the honest record keeps that gap visible. Rewriting the narrative so the escalation looks prompt would read better in review, and it would destroy the record’s two real uses: the audit trail stops matching the system-of-record timestamps, and the team loses the exact lesson (criteria as tripwires, not end-of-phase checklists) this case exists to teach.
Step 2. Sanitize for sharing
The record needs to be usable by the broader team without exposing sensitive data. PII is masked, regulated content is referenced rather than reproduced, sensitive infrastructure detail is generalized where possible. The version stored in the case-management system stays detailed; the version shared in training stays useful but safe.
Step 3. Link related artifacts
The record links to: the original alert in the SIEM, the IR ticket in the response system, the compliance notification record, the vendor request thread, the post-mortem document, and the detection-engineering ticket for the rules that need tuning. Every relevant artifact is one click away.
Step 4. Feed detection engineering
The case surfaced two detection gaps and one rule-precision opportunity. The triage analyst writes a short detection-engineering brief: which rules fired (and how usefully), which patterns were missed, and what changes would prevent or sharpen detection next time. The brief becomes a ticket in the detection-engineering queue.
Step 5. Submit for review
The record is submitted to the SOC manager for closure review. The review is not theater; it is the quality check that ensures the record meets the standard. The reviewer either accepts the record, requests clarification, or flags it as a training case for the team.
Key Takeaway
Documentation made the finance-team case durable. The record survives the analyst, the manager, and the moment. Future analysts will learn from it; future audits will rely on it.A second scenario: closing the Cursor benign true positive durably
The Cursor IDE Empire-pattern case ended in Escalation as a documented close at triage. Documentation now finalizes that record, same nine-section event report, same standards, same review. The lesson is that benign closes deserve documentation too. The event report for a “no incident” verdict carries forward into detection-engineering tickets, training, and the audit trail that proves the SOC closed for the right reasons.
Finalizing the Cursor benign-true-positive record
Escalation produced the close-at-triage record. Documentation finalizes the event report so the close survives a year of detection-rule changes and a quarterly auditor read.
Step 1. Capture the record
The nine-section event report is filled. Sections 01–04 (event overview, timeline, origin & scope, actions taken) carry forward directly from the Escalation closure record: the alert, the methodology phases, the verdict, and the explicit “no containment” justification. Sections 05–09 are filled with the benign-close-specific content: business impact is “none, legitimate activity on a developer workstation”; IOCs is the binary hash and vendor TLS endpoints, recorded as known-good rather than malicious; lessons learned is the over-broad detection rule and what changed about it; post-event recommendations is the rule-tuning ticket plus a one-line proposal to surface vendor-signing context in the EDR view; appendices hold the signature chain, peer-baseline query, and the Risk-phase reasoning.
What a less experienced analyst could miss: the known-good marking on the IOC section. A binary hash filed in an incident record without that label tends to migrate: into the intel platform, into a blocklist, into a hunt query someone writes next quarter. Then every developer running the same signed IDE lights up as “matching a known incident artifact.” Recording the hash as known-good, in the field where future correlation will find it, is what keeps this benign fire from breeding a family of new ones.
Step 2. Sanitize for sharing
The Cursor case has less sensitive content than the finance-team intrusion, but the same discipline applies. The named developer’s identity is pseudonymized in the version stored for team-wide review. The binary hash and vendor endpoints stay in the detailed version. The internal source-control repository names are generalized.
Step 3. Link related artifacts
The record links to: the original alert in the SIEM, the case in the case-management system, the detection-engineering ticket for rule tuning, the peer-baseline query saved in the analytics library, and (this one matters) the training-archive entry, the Cursor case is a textbook example of “looks like Empire, isn’t Empire,” and lives in the SOC’s onboarding curriculum.
Step 4. Feed detection engineering
The case surfaced one over-broad detection rule and one improvement opportunity. The triage analyst writes a brief: the rule that fired, why it matches on macOS Electron IDEs, what a tuned variant would incorporate (binary signature, install path, runtime context), and what the benign-fire rate trajectory should look like after tuning. The brief becomes a ticket in the detection-engineering queue, traceable back to this case and to any future cases that fire on a similarly tuned rule.
Step 5. Submit for review
The record is submitted for closure review. A benign-close record is reviewed by the SOC manager with the same eye an escalation record gets, perhaps with extra attention, because benign-close records are how the SOC’s discipline gets calibrated. The reviewer either accepts the record, requests clarification, or flags it as a training case. This one is flagged for training.
A third scenario: closing the token-theft record
The SaaS token-theft case escalated to IR mid-Uncover, so like the finance case, Documentation finalizes the triage-side record and links IR’s outputs. What is different is the evidence itself: identity artifacts are ephemeral in ways disk images are not, and the record has to capture them before the platforms age them out.
Finalizing the token-theft event report
IR owns the active case: the attacker is contained, the vendor detail on app reads is arriving, and compliance is running the GDPR determination. The triage analyst's Documentation phase closes the triage-side record while the identity evidence is still retrievable.
Step 1. Capture the record
The nine sections fill from the handoff packet, with one identity-specific discipline: the raw artifacts are exported into the case now, not merely referenced. The IdP’s sign-in records, the two session presentations, the inbox-rule definition, and the consent-grant event are all subject to platform retention windows and license tiers that the SOC does not control. A record that points at a log the tenant will age out in 90 days is a record that stops being evidence in 91. The exports, with their retrieval timestamps, go into the appendices.
Step 2. Sanitize for sharing
This case carries the most sensitive sharing surface of the three: the mailbox contents the attacker synced are customer data, and the record must describe the collection without reproducing it. The report records counts, categories, and thread types (“~1,800 items including billing correspondence”), never message bodies. rvega is pseudonymized in the training version, and the record states plainly that she is a victim, not a suspect, so the training artifact never reads as blame.
Step 3. Link related artifacts
The record links to: the SIEM alert, the IR ticket, the compliance determination thread (still open at closure; linked as pending), the vendor request and its eventual response, the finance team’s out-of-band verification confirmation, and the tenant sweep queries saved as reusable hunts. The pending links are themselves part of the record: an auditor reading it later sees what was still in motion when triage closed its side.
Step 4. Feed detection engineering
The brief credits what worked and names what was missing: the two-signal correlation rule caught the case and its design should be reused; a consent-grant alert for unverified publishers would have fired at 09:09 independent of the session signal; a session-fingerprint-mismatch detection at the IdP would have fired at 09:03, twelve minutes earlier. Each becomes a ticket. The lure domain and kit fingerprint feed the intel platform for retro-hunting across the estate.
Step 5. Submit for review
The SOC manager’s review flags this record for the training archive alongside the Cursor case: it is the SOC’s reference example of an intrusion with no endpoint evidence, and of containment whose ordering mattered more than its speed. The record closes with the compliance and vendor threads explicitly marked as continuing under their own owners.
Three cases, one durable record
The three scenarios show the same methodology applied to three verdicts. The finance-team intrusion produced an audit-quality record of a real endpoint compromise. The Cursor benign true positive produced an audit-quality record of why correctly detected behavior wasn’t malicious. The token theft produced an audit-quality record of an identity compromise, with the ephemeral evidence exported before it could expire. All three survive months later. All three train future analysts. The methodology’s value isn’t that it always reaches the same verdict; it’s that it always produces a defensible one.
Key Takeaway
Documentation closes the loop on all three cases the methodology threaded through. Future analysts will reach for the finance-team record on the next Empire-style chain, the Cursor record on the next Electron IDE pattern match, and the token-theft record on the next impossible sign-in. All three records are part of how the SOC stops re-investigating the same questions.