Documentation templates

About 13 min read

On this page

Pillar 02 of 03

Templates make documentation fast and consistent. The structure already exists; the analyst fills in the substance. Done well, templates reduce cognitive load during high-pressure investigations and ensure nothing critical gets missed.

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

The core template ships here and stays universal across the organization; specialized variants are built on top of it, and should exist for the common categories: phishing , credential compromise, ransomware , insider misuse, data exfiltration . Two variants ship with the core. The phishing variant adds the message and its email artifacts (sender and authentication results), the recipients and delivery path through the mail infrastructure , the URL and attachment verdicts, and the click evidence. The identity-compromise variant adds the session ID, the sign-in chain, the MFA ceremony, consent grants, mailbox rules, and the revocation order. Both paste into the core alert report after the activity summary; the core’s fields do not change. Ransomware templates capture encryption details, ransom demands, and business continuity impacts.

The alert reporting template

A well-designed alert report template captures all essential details consistently to support rapid understanding, event correlation , and knowledge reuse. Each report includes the following core fields.

Eight 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 eight, 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.

Event title and identifier

Concise yet descriptive. Pairs with a unique identifier (e.g., CASE-YYYYMMDD-NNN; an INC- identifier is added only if the case is declared an incident) for chronological tracking and cross-referencing.

Detection timestamp and source

Standardized UTC timestamp with optional local time. Detection source specifies the tool or control (EDR, SIEM, CSPM) responsible for generating the alert.

Activity summary

Describes the observable behavior that triggered the alert. Balances technical clarity with readability, highlighting specific indicators and anomalies.

Initial triage outcome

Early classification on two axes: detection (true positive, false positive (logic), or false positive (data)) and activity (malicious, policy violation, authorized (benign true positive), benign-confirmed, or undetermined), with concise justification grounded in observable behaviors and detection logic.

Affected systems

Endpoints, accounts, infrastructure elements involved, with business context (function, criticality, ownership).

Risk assessment

What Risk produced: impact, likelihood that the activity is malicious or unauthorized, confidence in that judgment, the matrix cell and priority (P1-P4), and a recommended move. Risk recommends; the escalation decision below decides.

Actions taken

Investigative or containment steps with timestamps and outcomes. Telemetry reviews, process analysis, network validation, remediation.

Escalation decision and final disposition

Whether the case was escalated, to whom, and why, or why it was closed, with who decided and when (UTC). Final disposition on both axes, plus status: closed, escalated, or merged into a case.

Worked example: the Cursor IDE alert report

A completed alert report for the macOS / Cursor IDE benign-true-positive case, in the standardized format. This is the alert-level report; Case B ran at Level 2, so the same facts also open its nine-section event report. Because the case closed, the Escalation decision wrote a closure record (the decision header, the closure check with the finding behind each item, the named gaps and reopen triggers, and the communication trail), not a handoff packet: nobody inherits the case. Documentation then assembles the event report from the case record under that header, as the Escalation transition describes.

Field	Content
Event title and ID	Empire-pattern behavior on developer workstation, CASE-20260311-017
Detection date/time	2026-03-11T14:03:11Z
Detection source	CrowdStrike EDR (cross-platform behavioral rule)
Activity summary	EDR flagged a child of “Cursor Helper (Plugin)”, the Cursor IDE’s extension host, which runs without its sandbox by design. The child opened TLS connections to `repo42.cursor.sh` and `api2.cursor.sh`. The rule maps the pattern to Empire-style macOS post-exploitation behavior.
Initial triage outcome	Detection: true positive · Activity: undetermined, leaning authorized (benign true positive). The behavioral rule matched a signed helper process (Cursor Helper (Plugin)) running without its sandbox and launching a child that opened TLS sessions to Cursor-owned hosts; the pattern overlaps Empire macOS tradecraft. Requires contextual validation in Subject and Uncover.
Affected systems	One managed macOS developer workstation, `dev-mac-0417` (owner: Web Platform team; criticality High, because the user’s SSH keys reach the build environment). User `user-7f3a` (pseudonymized), frontend engineer, standard rights.
Risk assessment	Impact High · likelihood Low · confidence High · High/Low cell, P3 · recommended move: keep working to the 18:03 forward watch, then a documented close if clean.
Actions taken	See the actions log below.
Escalation decision	Not escalated. No criterion confirmed; High/Low P3 held to the 18:03 forward watch; re-score clean at 18:05; documented close by the triage analyst at 18:08; close approved by the SOC manager at 18:10.
Final disposition	Detection: true positive · Activity: authorized (benign true positive) · Status: closed.

Actions log (all times 2026-03-11 UTC)

Time (UTC)	Actor	Action	Rationale	Outcome
14:12	Analyst	Verified signature, notarization and Team ID; compared version and hash with the MDM record	Signer and path alone do not clear	Match the vendor release
14:40	Analyst	Pulled extension, MCP and workspace-task inventory from MDM	The host runs code the signature does not cover	Child ran a bundled extension; user extensions approved, none new in 14 days; one approved MCP server; no autorun tasks
14:44	Analyst	Fleet prevalence query, 30 days, counts only	Test the peer baseline	Eleven other managed developer Macs, three on the user’s team
14:52	Analyst	Reviewed the IDE’s agent-activity record for the window (read-only)	Settle who ran the terminal commands, and whether anything but the user steered the agent	One user prompt; every terminal command was the agent’s and matches EDR; workspace files only; no MCP tool calls
14:55	Analyst	EDR and proxy review, 13:03-14:48	Destinations, persistence, credential access	Allowlisted destinations only; no persistence; no credential-path reads
15:10	Analyst	Risk assessment	Score and recommend	High/Low, P3, High confidence; hold to the 18:03 forward watch
18:05	Analyst	Re-score after the forward watch	Named P3 trigger	Clean; cell unchanged
18:08-18:10	Analyst, SOC manager	Documented close; close approved	E rule at P3 after a clean trigger	Closed

The same template, filled differently for the finance-team phishing case, would have produced a P1 escalation record: detection true positive, activity malicious, status escalated to IR with the incident ID linked.

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, in UTC with the date (RFC 3339, e.g. 2026-03-03T09:11:41Z), for consistency across geographies and shifts.

Actor

Who performed the action: a named human (with role), an automated system (SOAR or platform automation, EDR, IAM), or an AI agent (product and version, plus the human who authorized the action).

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 the systems involved in the event lifecycle. Case-management and SOAR platforms (e.g. TheHive, DFIR-IRIS, Microsoft Sentinel incidents, Google SecOps cases) and forensic timeline tools (e.g. Timesketch) support shared, attributed timeline entries, so several responders can add to one incident response timeline. 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. Pick by depth and outcome:

Case	What the Escalation decision writes	What Documentation finalizes
Level 0 pattern close	The five-field pattern-close record, at close (the close is an early Escalation decision)	Nothing further: the five-field record is the whole record
Level 1 standard triage	The alert report’s escalation and disposition fields	The alert report, written as you go and finalized at close
Level 1 phishing or identity alert	The alert report’s escalation and disposition fields	The alert report with the phishing or identity-compromise variant pasted in after the activity summary
Level 2, closed	The closure record: the decision header, the closure check with its findings, the named gaps and reopen triggers, and the communication trail	The nine-section event report, assembled from the case record under that header
Any Level 2 case, while it is worked	Nothing yet: the case is still open	The case record, opened at Alert and filled phase by phase: the Subject handoff, the Scope boundary statement and the Risk verdict block land in it at each transition, and the packet or report is assembled from it
Any escalation	The handoff packet, at escalation	The triage-side event report, mapping the packet in and linking IR’s outputs
Any case still open at a shift change	Nothing yet: the case is still open	The shift handover, at every shift change (one per customer for an MSSP or MDR), linking each open case record rather than replacing it
A Level 2, P1/P2 or escalated-then-closed record before it is submitted	Nothing further	The closure review, run by a reviewer who is not the record’s author (Level 0 and 1 closes go through the weekly QA sample instead)

Whichever artifact applies, the investigative entries lock at handoff or close; corrections and reopenings are appended with author, time, and reason, never overwritten (see amending a locked record). The Cursor alert report above is the alert-level artifact; its facts later open that case’s event report. Each block below is rendered from the shipped file, so what you copy is exactly what you download. Each 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. Every field name and enum value in them is defined in the ASSURED terms glossary, and the verdict fields use its verdict vocabulary exactly. Lines marked optional (depth level, grouped member alerts, distribution, regulatory flags, the hypothesis ledger) are what make a record shareable and countable later; leave them out only when they do not apply. The optional regulatory flags block in the handoff packet and the event report records, for each regime that may apply, the data class and trigger observed, the candidate awareness timestamp, and when the owner was engaged; triage records the facts a clock may start from, and the regime’s owner decides whether it started (see the flags block on the notification-clocks page). The alert report’s timeline uses the five components above (timestamp, actor, action taken, rationale, outcome). The handoff packet’s and the event report’s timelines add a Source and a Confidence column, so each row names the record it came from and its label on the shared rubric, and their hypothesis ledgers carry a provenance column (the source and query behind the deciding evidence).

Level 0 pattern-close record (Markdown)Pattern-library entry (Markdown)Alert report (Markdown)Nine-section handoff packet (Markdown)Nine-section event report (Markdown)Escalation-criteria checklist (Markdown)Shift handover (Markdown)Tuning request (Markdown)Monthly triage report (Markdown)Case record, one section per phase (Markdown)Subject handoff (Markdown)Scope boundary statement (Markdown)Risk verdict block (Markdown)Closure review checklist (Markdown)Alert report variant: phishing (Markdown)Alert report variant: identity compromise (Markdown)

Which template when: the case record opens at Alert and gains one section per phase; the handoff packet and the event report are assembled from it, not written from scratch. Inside it, the phase records land in order: the Subject handoff at the end of Subject, the Scope boundary statement at the Scope transition, pinned above Uncover’s query window, and the Risk verdict block at the end of Risk. At Level 1 each of those is a few lines in the alert report instead, with the phishing or identity variant pasted in when the event type fits. The closure review is the reviewer’s checklist for a Level 2, P1/P2 or escalated-then-closed record before it is submitted; Level 0 and 1 closes go through the weekly QA sample instead. The shift handover goes out at every shift change, one per customer for an MSSP or MDR.

The escalation-criteria checklist is the run-at-every-phase companion to these: the four canonical categories as checkable items, with the escalation-tripwire decision rule at the bottom. The one-page reference carries the same checklist in printable form. The tuning request is what Documentation files to detection engineering after a verdict; the routing table picks its request type and owner for each verdict. The monthly triage report rolls the records’ key times and verdicts up into the team-level numbers described on Measuring triage. For practicing with the templates on synthetic cases before a real one lands, the hands-on exercises provide eight scenario packets with answer keys. Training materials (session checklist, alert set, anchors, capstone) live with the facilitator kit.

Machine-readable schemas

Every record template also ships as a JSON Schema (draft 2020-12) at /templates/schema/<name>.schema.json, linked from each template block below. The verdict, case-status, priority, matrix-cell, confidence and depth-level enums are defined once, in the shared vocabulary schema, and every template schema points at them, so a SOAR playbook or a case tool can load the fields and pick lists directly instead of retyping them. The build fails if a template, its schema and the vocabulary drift apart, so the schema always describes what the Markdown asks for.

OCSF: the schemas describe case records, not events. Keep the raw events in your OCSF store (or ECS, ASIM or UDM) and cite them from the record by event ID. Where the platform models findings in OCSF, the record’s detection-axis and activity-axis verdicts and its priority map onto the Detection Finding and Incident Finding classes; check the attribute names against the OCSF version you ingest.
STIX: the indicators-and-observables section exports as STIX 2.1 Indicator or Observed Data objects, with the record’s TLP marking carried as a STIX marking definition. ATT&CK technique IDs keep the ATT&CK version they were mapped against.
Versioning: the published schemas describe the current edition’s templates, and every template download carries a “Template version” line naming that edition. Renaming or removing a field or an enum value changes the meaning of an existing deliverable, so under the repository’s versioning policy it ships only in a major version, and the changelog lists every field change.

Level 0 pattern-close record

The five-field record from the fast path is the entire documentation burden of a Level 0 pattern close. A grouped case closes here only if every member alert passes the gate; list every member alert ID.

Level 0 pattern-close record pattern-close-record.md · 100 lines · Template version 2.0

Download pattern-close-record.md JSON Schema

# Level 0 pattern-close record

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED fast path, Level 0 (https://assured-methodology.vercel.app/docs/fast-path).
     One record per closed case. Every field is required. If a field cannot
     be filled honestly, or an eligibility check is unknown, this is not a
     Level 0 close; move the case up the ladder. Unknown fails the gate.
     A Level 0 close is an early Escalation decision, recorded here. -->

## 1. Alert

- Alert ID (or the case ID and every member alert ID):
- Detection source:
- Detection rule (name, ID, and version):
- Detection timestamp (UTC):

<!-- Grouped case: every member alert must pass the gate and match a pattern
     entry. One member that fails eligibility, or one failed discriminator on
     any member, means the whole case is not a Level 0 close. -->

## 2. Pattern

- Pattern library entry matched (ID, name and version):
- Pattern owner:
- Pattern review date (must be current; past it, the entry cannot support a
  Level 0 close and the case moves to Level 1):
- Machine-close flag on the entry (on / off):

## 3. Checks

### Eligibility gate (all three, each from its source system, never from memory)

<!-- Record the evidence, not just the conclusion. Unknown or unverifiable
     fails the gate and the case moves to Level 1. A privileged identity or
     a crown-jewel subject goes straight to Level 2. Regulated data in reach
     (standing access, even if nothing shows it was touched) fails Level 0
     and is recorded as a Scope flag; it is not by itself a Level 2 trigger. -->

- Subject asset criticality is not crown-jewel (source, e.g. asset inventory / CMDB tag):
- Subject is not a privileged identity, and not automation holding sensitive
  capability (deploy, signing, secrets, repository write) (source, e.g. role /
  group / capability inventory):
- No regulated data (PCI, PHI, PII) in the subject's reach: no standing
  access to a store the data inventory classifies as regulated (source, e.g.
  data classification):

### Entry-specific constraints

<!-- Any narrower constraint the pattern entry adds (e.g. "applies only to
     hosts tagged ephemeral-runner / nonprivileged"), with the observed value
     and its source and date. -->

-

### Pattern discriminators (all, with what was actually observed)

<!-- Not "matches pattern" but the specific observations, e.g. "child script
     inside the signed bundle, extension ID on the entry, destinations within
     the entry's set, no credential-path reads, no persistence writes".
     Signer and install path are table stakes, not discriminators. One line
     each. -->

1.
2.
3.

### Escalation criteria

- Escalation criteria checked: none confirmed or suspected (any confirmed
  criterion fires the escalation tripwire and ends the Level 0 close):

## 4. Verdict

<!-- Two axes, both required. Detection: true positive / false positive
     (logic) / false positive (data). Activity: malicious / policy violation /
     authorized (benign true positive) / benign-confirmed / undetermined, one
     line of justification. Only benign-confirmed or authorized closes at
     Level 0. Malicious leaves Level 0: it fires the escalation tripwire, or,
     when a control fully contained it, is recorded at P3 or P4. Policy
     violation and undetermined move the case up the ladder. A correct
     detection of authorized behavior is a benign true positive, not a false
     positive. -->

- Detection:
- Activity:

## 5. Closure

- Closed at Level 0 by (analyst; or the automation on a machine-close entry,
  with its named owner):
- Closed at (UTC):
- Key times (UTC): detected / acknowledged / verdict / closed / reopened:
- Material AI use (assistant and version, and which fields began as AI
  drafts; "none" if unassisted):
- Tuning or volume request, if the rule keeps firing (a scoped exception
  with an owner and expiry; the rule logic stays intact for a benign true
  positive):

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 eight core fields described above, as a fill-in skeleton, with the optional lines that make the record shareable and countable.

Alert report alert-report.md · 123 lines · Template version 2.0

Download alert-report.md JSON Schema

# Alert report

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED documentation: the core alert reporting template, used for
     Level 1 cases (https://assured-methodology.vercel.app/docs/documentation/templates).
     Universal core fields; add specialized fields per event type
     (phishing, credential compromise, ransomware, ...) as needed. Fields
     marked (optional) can be left out when they do not apply. -->

## Event title and identifier

- Title:
- Case ID: CASE-YYYYMMDD-NNN
- Related incident ID (only if declared): INC-YYYYMMDD-NNN
- Reopens case (optional: the prior case ID, when this alert reopens a
  closed case):
- Analyst:
- Depth level (0 / 1 / 2), and any upward moves with their reason (a case
  moves up the ladder, never down):
- Grouped alerts (optional: every member alert ID, when several alerts form
  this one case; the riskiest member sets the level):
- Distribution (optional: TLP, the Traffic Light Protocol, and any
  need-to-know limits):
- Regulatory flags (optional: data classes plausibly involved, candidate
  awareness timestamp, owner engaged):
- Material AI use (assistant and version, and which sections began as AI
  drafts; "none" if unassisted):

## Detection timestamp and source

- Detected (UTC):
- Local time (optional):
- Detection source (tool or control, e.g. EDR / SIEM / CSPM):
- Detection rule (name, ID, and version):
- Intake channel (detection / user report / external notification /
  bug-bounty report / hunt finding / provider escalation / internal
  referral) and source grade (optional):
- Received (UTC): when the report or notice reached the organization, when
  it reached the SOC, and who received it:

## Activity summary

<!-- The observable behavior that triggered the alert. Specific indicators
     and anomalies, technical but readable. Defang indicators in prose.
     Label each claim's confidence (high / medium / low, shared rubric). -->

## Initial triage outcome

<!-- Two axes: detection (true positive / false positive (logic) /
     false positive (data)) and activity (malicious / policy violation /
     authorized (benign true positive) / benign-confirmed / undetermined),
     with a concise justification grounded in observable behavior and
     detection logic. A correct detection of authorized behavior is a
     benign true positive, not a false positive. When no rule fired, the
     report is the detection: a report whose claim holds is a true
     positive; a misread report is a false positive (logic); a notice built
     on bad data is a false positive (data). -->

- Classification, detection axis:
- Classification, activity axis:
- Justification:

### Hypothesis ledger (optional)

| Hypothesis | Status (leading / rejected / open) | Deciding evidence | Confidence |
| --- | --- | --- | --- |
|  |  |  |  |

- ATT&CK techniques, if mapped (with the ATT&CK version, e.g. Enterprise v19):

## Affected systems

<!-- Endpoints, accounts, infrastructure involved, with business context:
     function, criticality, ownership. -->

-

## Risk assessment

<!-- Impact is the higher of asset criticality and business impact.
     Likelihood is how probable it is that the activity is malicious or
     unauthorized; confidence is your analytic confidence in that judgment.
     Unexamined evidence means low confidence, not low likelihood. -->

- Impact (H/M/L):
- Likelihood (H/M/L):
- Confidence in the likelihood judgment (high / medium / low):
- Matrix cell (impact / likelihood) and priority (P1-P4):
- Recommended move (close, escalate, or keep working to a named re-score
  trigger):

## Actions taken

<!-- One row per action. Timestamps in UTC. Actor is a named human, an
     automated system (SOAR or platform automation, EDR, IAM), or an AI
     agent (product and version, plus the human who authorized the action). -->

| Timestamp (UTC) | Actor | Action taken | Rationale | Outcome / result |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

## Escalation decision and final disposition

<!-- Escalate if a criterion is confirmed or the matrix places the case at P1
     or P2. At P3, keep working to the named re-score trigger, then close or
     escalate. Close at P4. Record the cell either way. -->

- Escalated: yes / no; to whom, and why (or why not):
- Decided by, at (UTC):
- Escalation basis, if escalated (confirmed criterion under the escalation
  tripwire / matrix cell at P1 or P2 / operational route such as capacity):
- Closure justification, if closed (the closure check: no criterion confirmed
  or suspected; the cell allows it; no persistence or credential access seen;
  the case's own alternatives checked clean; gaps bounded):
- Gaps, and the condition that would reopen the case:
- Final disposition, both axes, and status (closed / escalated / merged into case):
- Key times (UTC): detected / acknowledged / verdict / escalated or closed /
  reopened:
- Next action (tuning request, pattern-entry proposal, handoff, or "nothing
  further", with the reason):

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 handoff-packet.md · 201 lines · Template version 2.0

Download handoff-packet.md JSON Schema

# Escalation handoff packet

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED escalation: the nine-section handoff packet
     (https://assured-methodology.vercel.app/docs/escalation/handoff).
     Target: the case summary plus the Risk verdict give the receiver the
     picture in five minutes; the remaining sections are navigated by heading.
     Fields marked (optional) can be left out when they do not apply. -->

## Case metadata

<!-- The packet identifies itself before it explains itself: which case, who
     wrote it, when, who owns the next action, and why it escalated. The
     escalation basis is one of three routes: a canonical criterion confirmed
     (confirmed malicious activity not fully contained by a control / high
     impact / lateral movement or exfiltration / ongoing campaign) under the
     escalation tripwire, which makes the case P1; the triage-matrix cell
     (e.g. High/Medium: P2, escalate within 4 hours); or an operational route
     such as capacity. Confirmed means High on the shared confidence rubric. -->

- Case ID:
- Prepared by (triage analyst):
- Prepared at (UTC):
- Handed to (receiving team, and the named owner of the next action):
- Why escalated (Escalation criterion met under the escalation tripwire, the
  matrix cell at P1 or P2, or an operational route), with a one-line
  rationale citing the confirming evidence:
- Depth level at handoff (0 / 1 / 2), and any upward moves with their reason:
- Distribution restrictions (TLP, the Traffic Light Protocol, and any
  need-to-know limits):
- Insider route (yes / no; if yes, case visibility restricted, routed through
  the insider-risk process, the subject's manager and team not notified):
- Regulatory flags (yes / no; if yes, fill the block below):
- Material AI use (assistant and version, and which sections began as AI
  drafts; "none" if unassisted):

### Regulatory flags (optional, when regulated data is plausibly involved)

<!-- Each regulatory or contractual clock that may apply (e.g. GDPR Art. 33,
     a state breach law, PCI DSS, a contract). Triage records the candidate
     start; the regime's owner (privacy, legal, compliance) decides whether
     the clock started. -->

| Regime | Data class and trigger observed | Candidate awareness or trigger timestamp (UTC) | Owner engaged (who), at (UTC) | Owner's decision |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

- Estimated affected individuals and their jurisdictions (if known):
- Preservation or legal-hold status and scope (who authorized it, and when, UTC):
- Counsel handling instructions (labeling, channel, distribution), if any:

### P1 page (optional, P1 only)

<!-- On a P1, page first and let the packet complete in parallel. -->

- Paged (who, channel, time UTC):
- Acknowledged at (UTC), or no-ack fallback used at 15 minutes:
- Warm handoff held (call or bridge, time UTC):

### Receipt (filled by the receiver)

- Accepted by (name), at (UTC):
- Escalation warranted? (yes / no / partially, one line why):
- Rework requested (packet sections missing or re-investigated; "none"):

## 1. Case summary

<!-- One paragraph. What happened, what is known, what the triage analyst
     recommends. Label each claim's confidence (high / medium / low). -->

## 2. Timeline

<!-- Sequential events with timestamps, starting from the earliest known
     activity: both adversary actions and analyst actions (when notified,
     what was checked, when escalated, when each containment action ran).
     Name each row's source and its confidence label. -->

| Timestamp (UTC) | Actor | Action taken | Source | Confidence | Outcome / result |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## 3. Entities

<!-- Primary and secondary entities with their assessment results: the
     Subject and Scope output. Type each entity as the Subject handoff does:
     user / service account / host or device / application or OAuth grant /
     session or token / resource / artifact / network identifier / threat.
     Analysts record observable technical activity. HR-held context reaches
     the case only through the insider-risk route, and never as
     analyst-collected notes. -->

- Entities (each with type, role, criticality, privilege, and assessment):
- Scope boundary (entities in, time window and lookback):
- Deliberately out of scope, and the observation that would pull each in:
- Reachable but not shown to be touched (Scope flags, e.g. regulated stores
  the subject can reach):
- Visibility gaps (sources missing, retention limits, pending vendor data):

## 4. Evidence chain

<!-- The Uncover narrative, with sources and queries used. Hypotheses tested:
     the leading hypothesis, the alternatives tested and rejected (each with
     the evidence that decided it), and any still open. MITRE ATT&CK technique
     mappings with the ATT&CK version used (e.g. Enterprise v19). -->

- Leading hypothesis:
- Alternatives tested and rejected (with deciding evidence):
- Alternatives still open:
- ATT&CK techniques (version):

### Hypothesis ledger

<!-- One row per hypothesis the investigation weighed. Provenance: name the
     source and query (or artifact ID) behind each deciding item, so the
     receiver can re-run it. Label the confidence of each step. -->

| Hypothesis | Status (leading / rejected / open) | Deciding evidence | Source and query (provenance) | Confidence |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

## 5. Risk verdict

<!-- The four RATM (Risk-Based Alert Triage Matrix) dimensions, reduced to
     impact and likelihood. Impact is the higher of asset criticality and
     business impact. Likelihood is how probable it is that the activity is
     malicious or unauthorized; confidence is your analytic confidence in
     that judgment on the shared rubric. Unexamined evidence means low
     confidence, not low likelihood. -->

- Verdict, detection axis (true positive / false positive (logic) /
  false positive (data)):
- Verdict, activity axis (malicious / policy violation / authorized (benign
  true positive) / benign-confirmed / undetermined):
- RATM asset criticality (H/M/L):
- RATM business impact (H/M/L):
- RATM threat actor intent (H/M/L):
- RATM exploitation & scope (H/M/L):
- Impact (the higher of asset criticality and business impact):
- Likelihood that the activity is malicious or unauthorized (H/M/L):
- Confidence in that judgment (high / medium / low, shared rubric), and what
  would change it:
- Matrix cell (impact / likelihood) and priority (P1-P4), or the confirmed
  criterion that set P1:
- Override applied, if any (escalation tripwire, high-impact clock,
  documented downgrade), with reason:
- Recommended move:
- Open questions that would move this verdict (each also listed in section 8):

## 6. Containment actions taken

<!-- Preserve before you contain: list what was preserved first (volatile
     evidence, the artifacts a containment action would destroy). Then what
     was already done, each with its time and how it was verified. Triage
     executes only reversible pre-authorized actions; credential resets and
     OAuth grant revocations need IR or owner approval unless the protocol
     lists them for this scenario. Then what was deliberately not done, and
     why, and which actions await IR's approval. -->

- Preserved first:
- Done (time UTC, how verified):
- Deliberately not done, and why:
- Awaiting IR approval:

## 7. Artifacts

<!-- Relevant log excerpts, IoCs, hashes, screenshots, queries, attached or
     linked so the next analyst does not have to re-derive them. Defang
     indicators in prose. For each artifact, record its custody /
     preservation state: where the original lives, its identifying hash, and
     who has handled it so far. -->

- Artifact:
  - Custody / preservation state:

### Evidence at risk

<!-- Each source with its retention window and export status, and whether
     volatile evidence (memory) was captured. -->

- Source, retention window, exported (yes / no):

## 8. Open questions

<!-- What triage could not resolve and would have pursued next, each with the
     query or contact that would settle it. The IR team picks up from this
     list. -->

-

## 9. Communication record

<!-- Who has been notified so far, by whom, on which channel, when, what they
     were told (one line), and any decision they made. Prevents duplicate
     notifications and starts the audit trail for regulatory reporting. -->

| Time (UTC) | Who was notified | Channel | By whom | What they were told | Decision made |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

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 event-report.md · 173 lines · Template version 2.0

Download event-report.md JSON Schema

# Event report

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED documentation: the nine-section event report
     (https://assured-methodology.vercel.app/docs/documentation/standards#format).
     This is the closure-time record, written for the future reader. It is a
     different artifact from the escalation handoff packet; when a packet
     exists, map it in per the crosswalk on the Standards page. Fields marked
     (optional) can be left out when they do not apply. -->

## Decision header

<!-- The authoritative close-out, above the nine sections: who decided what,
     at what priority and confidence, when, and how the draft was produced.
     Detection axis: true positive / false positive (logic) / false positive
     (data). Activity axis: malicious / policy violation / authorized (benign
     true positive) / benign-confirmed / undetermined. A correct detection of
     authorized behavior is a benign true positive, not a false positive.
     "Merged into case" is a status, not a verdict. Confidence uses the shared
     high / medium / low rubric on the Standards page; between levels, round
     down. -->

- Bottom line (2-3 plain-language sentences for a non-technical reader: what
  happened, what it means for the business, what is still open):
- Final verdict, detection (true positive / false positive (logic) /
  false positive (data)):
- Final verdict, activity (malicious / policy violation / authorized (benign
  true positive) / benign-confirmed / undetermined, one line of
  justification):
- Escalation decision (close or escalate), who decided, and when (UTC):
- Status (closed / escalated / merged into case), with related case or
  incident IDs:
- Priority at close (P1-P4), with the matrix cell (e.g. High/Medium) or named
  override (escalation tripwire, high-impact clock, documented downgrade)
  that produced it:
- Confidence in the final verdict (high / medium / low, shared rubric; round
  down). Other claims carry their own labels where they appear, e.g. each
  claim in section 3 and each indicator in section 6:
- Depth level worked (0 / 1 / 2), and any upward moves with their reason:
- Open uncertainty (what remains unresolved at close; "none" must be earned):
- Reopen conditions (observable triggers that would revisit this verdict;
  required for benign and authorized closes):
- Key times (UTC): detected / acknowledged / verdict / escalated or closed /
  contained / reopened:
- Distribution (TLP, the Traffic Light Protocol, and any need-to-know
  limits, e.g. insider cases):
- Notification clocks (optional: yes / no; if yes, fill the regulatory flags
  block below):
- Prepared by (analyst):
- Prepared at (UTC):
- Material AI use (assistant and version, and which sections began as AI
  drafts; "none" if unassisted):

### Regulatory flags (optional, when regulated data is plausibly involved)

<!-- Each regulatory or contractual clock that may apply. Triage records the
     candidate start; the regime's owner decides whether the clock started. -->

| Regime | Data class and trigger observed | Candidate awareness or trigger timestamp (UTC) | Owner engaged (who), at (UTC) | Owner's decision |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

- Estimated affected individuals and their jurisdictions (if known):
- Preservation or legal-hold status and scope (who authorized it, and when, UTC):
- Counsel handling instructions (labeling, channel, distribution), if any:

## 1. Event overview

<!-- Who, what, when, where, how, at a glance. -->

- Alert identifier (or the case ID and every member alert ID):
- Detection date/time (UTC):
- Affected system or environment:
- Plain-language description of observed behavior:
- Status: closed / escalated / merged into case (related case or incident IDs):

## 2. Timeline of events

<!-- Chronological breakdown starting at the earliest known adversary
     activity, not at the alert: initial alert, investigative actions with
     UTC timestamps, response measures, phase transitions, delays or decision
     points, final resolution. Keep delays visible; do not smooth the
     timeline in hindsight. Name each row's source and its confidence. -->

| Timestamp (UTC) | Actor | Action taken | Rationale | Source | Confidence | Outcome / result |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

## 3. Origin and scope

<!-- How the event originated and its impact radius, as established at
     triage: initial access vector as observed, adversary TTPs, affected
     systems / identities, lateral movement, privilege escalation, data
     exposure, evidence references, each claim with its own confidence
     label. For escalated cases, link IR's root-cause analysis; do not
     restate it. -->

### Scope (optional)

<!-- Type each entity as the Subject handoff does: user / service account /
     host or device / application or OAuth grant / session or token /
     resource / artifact / network identifier / threat. -->

- Entities in scope, time window and lookback (each entity with its type):
- Deliberately out of scope, and the observation that would have pulled
  each in:
- Reachable but not shown to be touched (Scope flags; regulated data that
  was plausibly accessed goes in the regulatory flags block):
- Visibility gaps (sources missing, retention limits, pending vendor data):

### Hypothesis ledger (optional)

<!-- The hypotheses the investigation weighed, and how each ended, with the
     source and query (or artifact ID) behind each deciding item. -->

| Hypothesis | Status (leading / rejected / open) | Deciding evidence | Source and query (provenance) | Confidence |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

## 4. Actions taken

<!-- Investigative procedures, containment measures, remediation tasks:
     tools or methods used, responsible individual or team, outcome of each
     action. Record what was preserved before any containment, and the IR or
     owner approval for any non-reversible action. -->

-

## 5. Business impact

<!-- Technical detail translated into organizational consequence:
     operational disruption, financial impact, regulatory implications,
     reputational effects, SLA violations, external communications. -->

## 6. Indicators and observables

<!-- Every entry carries a disposition and a confidence. Defang indicators in
     prose (hxxp, [.]). Known-good entries go to the allowlist or
     warninglist, never to the IOC feed. The MITRE ATT&CK technique chain
     rides here, labeled as behavior (TTPs), not as indicators; state the
     ATT&CK version the chain was mapped against (e.g. Enterprise v19). -->

| Indicator or observable | Type | Disposition (malicious / suspicious / known-good) | Confidence | Detection logic | TLP |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

- ATT&CK chain (version):

## 7. Lessons learned

<!-- Detection gaps, process inefficiencies, response challenges,
     communication breakdowns, successful tactics, technology limitations. -->

-

## 8. Post-event recommendations

<!-- Specific, actionable improvements with ownership and timelines. Carry
     forward any open questions from the handoff packet that were not
     resolved by close. -->

-

## 9. Appendices and evidence

<!-- Log excerpts (sanitized as needed), snapshots, tool outputs, the
     communication record preserved verbatim, related case references,
     external intelligence reports, chain-of-custody documentation. -->

-

For a rendered example of this report filled in, see the finance-team record in the Documentation working example, which fills all nine sections; the Cursor and token-theft cases on the same page show what changes for a documented close and for an identity compromise. Before a record is submitted, the reviewer runs it against the closure review checklist.

Shift handover

One record per shift change, and one per customer for an MSSP or MDR. It transfers ownership of the open cases and the clocks running on them, and links each case record rather than restating it; P1 and P2 cases also transfer warm. The shift handover section explains when and how it is used.

Shift handover shift-handover.md · 112 lines · Template version 2.0

Download shift-handover.md JSON Schema

# Shift handover

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED operations: the shift handover
     (https://assured-methodology.vercel.app/docs/operating-variants).
     One record per shift change (per customer, for an MSSP or MDR). It
     transfers ownership of open cases, the clocks running on them, and the
     state of the queue. It does not replace the case records: link them.
     P1 and P2 cases also transfer warm (a live call, bridge or in-person
     handover in which the receiver confirms ownership). P3 and P4 cases may
     transfer through this record alone.
     Fields marked (optional) can be left out when they do not apply. -->

## Handover metadata

- Team (and customer, for an MSSP or MDR):
- Outgoing analyst(s), shift start and end (UTC):
- Incoming analyst(s):
- Handover held at (UTC), and how (call, bridge, in person, written only):
- Material AI use (assistant and version, and which parts began as AI
  drafts; "none" if unassisted):

### Receipt (filled by the incoming analyst)

<!-- Until this is filled in, the outgoing analyst still owns every case
     below, and every clock is still theirs to watch. -->

- Accepted by (name), at (UTC):
- Cases re-derived before the first new query (case IDs):
- Questions asked before the outgoing analyst left ("none" if none):

## 1. Open cases at P1 and P2

<!-- One block per case, P1 first. These transfer warm: the incoming analyst
     restates the leading hypothesis and the live alternative back to the
     outgoing analyst before accepting. A decision clock never crosses the
     shift boundary silently, and it does not restart at handover. -->

### Case:

- Priority, matrix cell (impact / likelihood), confidence (high / medium /
  low, shared rubric), or the confirmed criterion that set P1:
- Depth level (0 / 1 / 2), and any upward move this shift with its reason:
- Owner after handover (name):
- Hypothesis ledger (link): leading hypothesis; live alternatives; refuted
  this shift, with the deciding evidence:
- Done this shift (link the record; one line):
- Next action, and the result that would change the verdict:
- Decision clock: band, deadline (UTC), and what happens if it lapses:
- Pending pages or callbacks for this case (also in section 3):
- Warm handover held with (name), at (UTC):

## 2. Open cases at P3 and P4

<!-- One row per case. A P3 keeps its named re-score trigger and deadline;
     a case that could not be finished is handed over, not closed to clear
     the board. Insider-route cases: case ID and owner only; the details stay
     in the restricted case. -->

| Case ID | Priority and cell | Level | Owner after handover | Leading hypothesis and live alternative (or ledger link) | Next action | Re-score trigger and deadline (UTC) |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

## 3. Clocks, pages and callbacks

<!-- Every clock that will run out during the next shift, and everything
     someone is waiting on. Regulatory rows record a candidate timestamp
     only; the regime's owner (privacy, legal, compliance) decides whether
     and when a clock started. -->

| Case ID | What is running (acknowledgment, decision, re-score, page fallback, callback, vendor request, regulatory candidate) | Waiting on (who, channel) | Started at (UTC) | Due or fallback at (UTC) | Owner after handover |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## 4. Containment in effect

<!-- Each pre-authorized action still in force, with what was preserved
     first, how it was verified, and what reverses it. Actions awaiting IR
     or owner approval (including any non-reversible step) go here too. -->

| Case ID | Action | Preserved first | Taken at (UTC) | Verified how | Reverse or review by (UTC) | Approval pending (who) |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

## 5. Watches and evidence at risk

- Forward windows being watched (entity, what would trigger action, until
  when, who watches):
- Sources whose retention or export window closes before the next
  handover (source, closes at UTC, exported yes / no):

## 6. Queue and detection state

- Queue depth and oldest-item age, by priority:
- Rules firing outside their normal volume (rule, volume against normal,
  tuning ticket):
- Pattern entries suspended, past their review date, or due for review
  within 7 days (entry ID and version, owner):
- Sensors or log sources silent or degraded since (UTC):
- Capacity: escalations made on capacity this shift, and any still needed
  (optional):

## 7. Notes for the incoming analyst (optional)

<!-- One line each, for anything that does not fit above. Not a place for a
     new story about a case: the ledger carries that. Record observable
     technical activity only. -->

-

Closure review checklist

The ten checks every reviewer runs against a Level 2, P1/P2 or escalated-then-closed record before it is submitted, from the closure review on the Standards page. The reviewer is not the record’s author; every box left open gets one line under Findings.

Closure review checklist closure-review.md · 45 lines · Template version 2.0

Download closure-review.md JSON Schema

# Closure review checklist

<!-- ASSURED Methodology by Timothy Zilber, © Block, Inc., CC BY 4.0
     (https://creativecommons.org/licenses/by/4.0/). Reuse and adapt freely
     with attribution; note any changes you make.
     Template version: 2.0
     ASSURED documentation standards: the closure review
     (https://assured-methodology.vercel.app/docs/documentation/standards#closure-review).
     Every record ends in a closure review, and a review only calibrates the
     team if every reviewer checks the same things. The reviewer is not the
     record's author. Where this list and the standards page differ in
     wording, the standards page is the reference. -->

- Case ID:
- Record reviewed (event report / alert report / pattern-close record), and
  its author:
- Reviewer:
- Reviewed at (UTC):

## Checklist

<!-- Tick a box only when the record meets it as written. For every box left
     open, write one line under Findings naming the section and what is
     missing. -->

- [ ] The decision header is complete: verdict on both axes in the fixed vocabulary, the Escalation decision with who made it and when, priority with its matrix cell or override, and a bottom line a non-technical reader can follow
- [ ] Every factual claim cites its source: a query and time range, a log record ID, or an artifact hash
- [ ] Confidence is labeled per claim on the shared rubric, not once for the case
- [ ] Negative findings are recorded with what was examined, not just "nothing found"
- [ ] The timeline is in UTC with the date, and each entry has an actor, rationale, and outcome
- [ ] Every open question from the handoff packet is resolved in section 2 or 3, or carried into section 8
- [ ] Every indicator and observable has a disposition (malicious, suspicious, or known-good)
- [ ] Shared and training versions are sanitized, and people are written about neutrally
- [ ] Material AI use is declared, "none" included
- [ ] Benign and authorized closes state their reopen conditions

## Findings

-

## Outcome

- Outcome (accept / request clarification / flag as a training case):
- Clarification requested from (author), due by (UTC), and resolved at (UTC):
- Training-case note (what the case teaches, in one line; optional):

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.

Next up

Pitfalls

Read pitfalls

Technical details verified 2026-10-13. Product names, defaults and retention change; check your own tenant.

Edit this page on GitHub Report a correction