Documentation working example
Closing the case durably
Escalation handed the case to IR. IR contained the intrusion. The triage analyst's Documentation phase produces the record that survives the case.
Step 1. Capture the record
The nine-section event report template (see Standards) is filled, ideally in real time as the investigation ran. Sections 01-04 (event overview, timeline, root cause & scope, actions taken) carry forward from the handoff packet the analyst built during Escalation, expanded with the IR responder’s findings. Sections 05-09 (business impact, IOCs, lessons learned, post-incident recommendations, appendices) are added during the Documentation phase as the full picture becomes clear.
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 false-positive 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.
A second scenario: closing the Cursor false-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 false-positives 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 false-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, root cause & 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 false-positive-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-incident 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.
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 false-positive 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 false-positive record is reviewed by the SOC manager with the same eye an escalation record gets, perhaps with extra attention, because false-positive 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.