Documentation templates
Why standardized templates
A template is the difference between “what should I write?” and “fill in the next field” during an active case. The structure carries the completeness burden: every field the record needs is prompted, including the ones analysts forget under pressure, like negative findings and decision rationale. Consistency is what makes records comparable across cases; three phishing reports with the same fields can reveal a campaign, three free-form narratives cannot.
In practice that means building the templates into the case-management system rather than a separate document, validating the critical fields so a case cannot close with them blank, and keeping one specialized variant per common event type instead of one giant form.
Customize the core template by event type
While a core template structure should be universal across the organization, specialized variants must exist for common categories: Phishing Deceptive messages (usually email; sometimes SMS, voice, or chat) that impersonate a trusted sender to lure the recipient into clicking, opening, or entering credentials. The bait is the email; the line is the impersonation; the catch is initial access. , Credential Whatever the system accepts as proof of identity: a password, an API key, an OAuth token, a Kerberos ticket, an NTLM hash. Credentials are the highest-value loot in most intrusions; their theft is usually the pivot point. compromise, Ransomware Malicious software that encrypts a victim's files and demands payment (usually cryptocurrency) for the decryption key. Modern ransomware operations typically pair encryption with data theft, threatening public release if the ransom is not paid (double extortion). , insider misuse, Data Exfiltration The unauthorized transfer of data from a computer or network to an external location or system. . Phishing templates include fields for email Artifacts Digital evidence or traces left behind by system activity or security incidents, used in forensic analysis and incident investigation. , affected recipients, and delivery Infrastructure The systems, networks, and services that computing runs on. In triage the word points two directions: the organization's infrastructure is what alerts fire on, and attacker infrastructure is the set of C2 servers, domains, and staging hosts an adversary operates, which pivoting on indicators is meant to map. . Ransomware templates capture encryption details, ransom demands, and Business Continuity An organization's capacity to keep critical operations running during and after a disruptive incident such as a ransomware outbreak or a destructive attack. In triage, a credible threat to business continuity is part of what raises an alert's risk rating and escalation urgency. impacts.
The alert reporting template
A well-designed alert report template captures all essential details consistently to support rapid understanding, Event Correlation The process of analyzing multiple events across different sources to identify relationships and determine if they are part of a larger security incident. , and knowledge reuse. Each report includes the following core fields.
Seven fields is a deliberate ceiling for the universal core, not a starting point; the specialized variants above add their event-type fields on top, but the core itself does not grow. Every field added to the core raises the cost of every report the team will ever write, and the fields skipped under pressure are exactly the discriminating ones. Of the seven, two do most of the retrospective work: the initial triage outcome, because it records what the analyst believed with the evidence available at the time, and the escalation decision, because it records the judgment call a reviewer is most likely to second-guess. Fill those two with care; the rest is largely mechanical capture.
Worked example: the Cursor IDE alert report
A completed alert report for the macOS / Cursor IDE Benign True Positive An alert that fired on exactly the activity its detection logic describes, where that activity turns out to be authorized or expected in the local context: a red-team exercise, an admin's sanctioned use of a dual-use tool, a scanner doing its job. The detection worked; the context clears it. Distinct from a false positive, where the logic matched something it should not have. The close still feeds tuning, because the record is what teaches the detection about the local context. case, in the standardized format:
| Field | Content |
|---|---|
| Event title and ID | Empire-pattern behavior on developer workstation, INC-20241104-001 |
| Detection date/time | 2024-11-04T14:03:11Z |
| Detection source | CrowdStrike EDR |
| Activity summary | EDR flagged Execution The attacker successfully runs malicious code on a system, typically using interpreters, scripts, payloads, or legitimate tools. of “Cursor Helper (Plugin)” binary due to behavioral traits associated with Empire Post-Exploitation The phase where the attacker explores the environment, escalates access, exfiltrates data, or sets up long-term control. frameworks. |
| Initial triage outcome | Inconclusive. Behavioral heuristics triggered on execution via helper binaries with sandbox Evasion Techniques used by attackers to avoid detection by security tools. flags, manipulated debugger ports, TLS-encrypted high-entropy Network Traffic The data moving between hosts on a network, observed as connections, flows, and packets. In triage, traffic metadata (who talked to whom, when, how much, and over which port and protocol) is often the fastest way to confirm or rule out command and control, exfiltration, or lateral movement. , and elevated Node.js Event-driven JavaScript runtime on V8; backend services, APIs, automation scripts, and tooling. subprocesses. Matches known Empire indicators but requires contextual validation. |
| Affected systems | Single developer workstation, source of the alert. |
| Actions taken | 14:08–14:58 UTC: reviewed CrowdStrike Telemetry Collection and transmission of security-relevant data from remote sources for monitoring and analysis. ; execution patterns and network behavior aligned with expected developer activity. Traffic normal in volume / frequency, used standard ports / protocols, no signs of Exfiltration The unauthorized transfer of data from a system or network, often as part of a data breach or espionage operation. , Beaconing Periodic network communication from an infected host to a C2 server. , or tunneling. 15:10 UTC: risk verdict recorded. 15:18 UTC: closure approved by SOC manager. |
| Escalation decision | Flagged behavior appears to be benign development activity triggering a heuristic rule. No escalation required. |
| Final disposition | Benign true positive. Detection correct: the rule fired on the behavior it describes. Activity non-malicious and consistent with developer workflows. |
The same template, filled differently for the finance-team phishing case, would have produced a P1 escalation record with confirmed malicious classification.
Timeline and action tracking
Maintaining an accurate, timestamped timeline is fundamental to effective documentation. The timeline provides a sequential record of activities, decisions, and communications, supporting retrospective analysis and accountability.
Each timeline entry should contain five components. The five exist because a timeline that only answers “what happened when” is half a record. Timestamp, actor, and action reconstruct the sequence, and anyone with the raw logs could rebuild those. Rationale and outcome are the two components the logs cannot supply, and they are the reason the timeline is written by the analyst instead of exported from the SIEM: rationale preserves why the step made sense at the time, and outcome records whether reality cooperated.
Timestamp
The exact time the action occurred, using UTC for consistency across geographies. Both date and time for extended incidents.
Actor
Entity performing the action: human (analyst, engineer with name and role) or automated system (SOAR, EDR, IAM platform).
Action taken
Brief but descriptive: “isolated host via EDR,” “blocked IP in firewall,” “added hash to denylist.” Concrete and specific.
Rationale
Reasoning behind the action, especially for discretionary steps. Documents the decision-making process and justification.
Outcome / result
Observed effect: successful containment, error encountered, lack of expected response. Captures actual vs. intended.
Real-time, collaborative timelines
Timelines should be maintained in real-time and synchronized across systems involved in the event lifecycle. Modern Incident Response The organized approach to addressing and managing the aftermath of a security breach or cyberattack, including preparation, detection, analysis, containment, eradication, and recovery. platforms provide collaborative timeline features that enable multiple team members to contribute entries while preventing conflicts. These integrated timelines become the authoritative record of event progression, supporting handoffs, shift changes, and distributed-team coordination.
Copy-ready templates
Everything above describes the templates; these are the templates themselves. Each block is plain Markdown: paste it into a case management system, a ticket, or a shared doc, or download the file and drop it into the team’s template library. The timeline table inside the alert report and the handoff packet uses the five components above (timestamp, actor, action taken, rationale, outcome).
The escalation-criteria checklist is the run-at-every-phase companion to these: the four canonical categories as checkable items, with the break-glass decision rule at the bottom. The one-page reference carries the same checklist in printable form. For practicing with the templates on synthetic cases before a real one lands, the hands-on exercises provide three scenario packets with answer keys.
Level 0 pattern-close record
The five-field record from the fast path, the entire documentation burden of a Level 0 pattern close.
# Level 0 pattern-close record
## 1. Alert
- Alert ID:
- Detection source:
- Detection timestamp (UTC):
## 2. Pattern
- Pattern library entry matched (ID and name):
- Pattern owner:
- Pattern review date (must be current; a stale entry fails the gate):
## 3. Checks
### Eligibility gate (all three, each from its source system, never memory)
<!-- Unknown or unverifiable fails the gate; the alert moves to Level 1. -->
- Subject asset criticality is not crown-jewel (source):
- Subject is not a privileged identity, and not automation holding sensitive
capability: deploy, signing, secrets, repository write (source):
- No regulated data (PCI, PHI, PII) in the subject's reach (source):
### Pattern discriminators (all, with what was actually observed)
<!-- Not "matches pattern"; e.g. "signed vendor binary, expected install
path, no persistence". One line each. -->
-
## 4. Verdict
<!-- Both axes. Only benign-confirmed or authorized closes at Level 0:
malicious breaks glass, undetermined moves up the ladder. A correct
detection of benign behavior is a benign true positive, not a false
positive. -->
- Detection correctness (did the rule detect what it looks for?):
- Activity disposition (benign-confirmed / authorized / malicious /
undetermined, one line of justification):
## 5. Disposition
- Closed at Level 0 by (analyst):
- Closed at (UTC):
- Tuning ticket, if the rule keeps firing:The companion pattern-entry template is the library side of the contract: discriminators, owner, review date, and any pattern-specific eligibility constraints, written down where a wrong pattern can be corrected in one place.
Alert report
The seven core fields described above, as a fill-in skeleton.
# Alert report
## Event title and identifier
- Title:
- ID: INC-YYYYMMDD-NNN
## Detection timestamp and source
- Detected (UTC):
- Local time (optional):
- Detection source (tool or control, e.g. EDR / SIEM / CSPM):
## Activity summary
<!-- The observable behavior that triggered the alert. -->
## Initial triage outcome
- Classification, two axes: detection correctness (correct / incorrect) and activity disposition (malicious / benign / inconclusive)
- Justification:
## Affected systems
<!-- With business context: function, criticality, ownership. -->
-
## Actions taken
| Timestamp (UTC) | Actor | Action taken | Rationale | Outcome / result |
| --- | --- | --- | --- | --- |
| | | | | |
## Escalation decision and final disposition
- Escalated: yes / no; to whom, and why (or why not):
- Final disposition: benign / confirmed malicious / merged into incident:Nine-section handoff packet
The escalation packet: a case-metadata header, then the sections exactly as the Handoff page defines them. Target: readable in five minutes.
# Escalation handoff packet
## Case metadata
- Case ID:
- Prepared by (triage analyst):
- Prepared at (UTC):
- Handed to (receiving team, and the named owner of the next action):
- Escalation criterion met (canonical category or matrix cell), with a
one-line rationale citing the confirming evidence:
- Material AI use (assistant + version; which sections began as AI drafts;
"none" if unassisted):
## 1. Case summary
<!-- One paragraph: what happened, what is known, what triage recommends. -->
## 2. Timeline
| Timestamp (UTC) | Actor | Action taken | Rationale | Outcome / result |
| --- | --- | --- | --- | --- |
| | | | | |
## 3. Entities
<!-- Primary and secondary entities with assessment results:
the Subject and Scope output. -->
## 4. Evidence chain
<!-- The Uncover narrative: sources, queries used, MITRE technique mappings. -->
## 5. Risk verdict
- RATM asset criticality (H/M/L):
- RATM threat actor intent (H/M/L):
- RATM exploitation & scope (H/M/L):
- RATM business impact (H/M/L):
- Impact (criticality + business impact):
- Likelihood (intent + exploitation, weighted by evidence quality):
- Priority:
- Recommended response:
## 6. Containment actions taken
<!-- What was done AND what was deliberately not done, and why. -->
## 7. Artifacts
<!-- Log excerpts, IoCs, hashes, screenshots, queries, attached or linked.
For each: custody / preservation state (where the original lives, its
hash, who has handled it). -->
## 8. Open questions
<!-- What triage could not resolve and would have pursued next. -->
## 9. Communication record
| Time (UTC) | Who was notified | Channel | By whom |
| --- | --- | --- | --- |
| | | | |Nine-section event report
The closure-time record: a decision header (verdict, priority, confidence, provenance), then the nine sections exactly as the Standards page defines them. This is a different artifact from the handoff packet above; when a packet exists, map it in per the crosswalk on the Standards page.
# Event report
## Decision header
- Final verdict, detection correctness:
- Final verdict, activity disposition (benign-confirmed / authorized /
malicious / undetermined, one line of justification):
- Priority at close (P1-P4), with the matrix cell or named override
(break-glass, high-impact clock, documented downgrade) that produced it:
- Evidence confidence (high / medium / low, shared rubric; round down):
- Open uncertainty (what remains unresolved at close; "none" must be earned):
- Prepared by (analyst):
- Prepared at (UTC):
- Material AI use (assistant + version; which sections began as AI drafts;
"none" if unassisted):
## 1. Event overview
- Alert identifier:
- Detection date/time (UTC):
- Affected system or environment:
- Plain-language description of observed behavior:
- Current status: resolved / ongoing / escalated
## 2. Timeline of events
| Timestamp (UTC) | Actor | Action taken | Rationale | Outcome / result |
| --- | --- | --- | --- | --- |
| | | | | |
## 3. Origin and scope
<!-- As established at triage: initial access vector as observed, TTPs,
affected systems / identities, lateral movement, data exposure. For
escalated cases, link IR's root-cause analysis; do not restate it. -->
## 4. Actions taken
<!-- Tools or methods used, responsible individual or team, outcome. -->
-
## 5. Business impact
<!-- Operational, financial, regulatory, reputational, SLA, external comms. -->
## 6. Indicators of compromise
<!-- Each with confidence level and recommended detection logic. The ATT&CK
technique chain rides here, labeled as behavior, not indicators. -->
-
## 7. Lessons learned
-
## 8. Post-event recommendations
<!-- With ownership and timelines. Carry forward any handoff-packet open
questions not resolved by close. -->
-
## 9. Appendices and evidence
<!-- Sanitized log excerpts, tool outputs, the communication record
preserved verbatim, chain-of-custody documentation. -->
-For a rendered example of this report filled in, see the Documentation working example: the finance-team intrusion, the Cursor benign true positive, and the SaaS token theft all walk through filling these nine sections.
Key Takeaway
A template is not a constraint; it is scaffolding. Templates make documentation faster, more consistent, and more complete. Time invested in designing the right template saves hours of inconsistent records, and the right alert-reporting template plus a timestamped action timeline cover most of what any audit, post-mortem, or shift handoff will ask for.