The handoff packet

About 5 min read

On this page

Pillar 05 of 05

When the Escalation decision is escalate, the handoff packet is the artifact the triage analyst hands to the next tier. Done well, it lets the next analyst start where this one stopped. A close produces a closure record instead, held to the same standard.

What the packet contains

Case metadata

The header above the nine sections: case ID, author, handoff time (UTC), who owns the next action, the escalation route that fired (a confirmed criterion, the matrix cell, or an operational route such as capacity) with a one-line rationale, the depth level, distribution limits (TLP, and the insider route if it applies), regulatory flags (the regime table plus three lines under it: estimated affected individuals and their jurisdictions; preservation or legal-hold status and scope; counsel’s handling instructions), material AI use, and on a P1 the page, its acknowledgment, and the warm handoff. Then the receipt: accepted by whom, at what time (UTC). The packet identifies itself before it explains itself, and the handoff is not complete until someone has accepted it.

1. Case summary

One paragraph. What happened, what is known, what the triage analyst recommends.

2. Timeline

Sequential events with UTC timestamps, each row naming its source and its confidence label on the shared rubric. Includes both adversary actions and analyst actions (when notified, what was checked, when escalated, when each containment action ran).

3. Entities

Primary and secondary entities with their assessment results. The Subject and Scope output.

4. Evidence chain

The Uncover narrative with sources, queries used, and ATT&CK technique mappings, with the ATT&CK version used (for example, Enterprise v19). The rejected hypotheses: each alternative tested and ruled out, with the evidence that decided it, so IR does not spend an hour re-testing it.

5. Risk verdict

The verdict on both axes (detection: true positive, false positive (logic), or false positive (data); activity: malicious, policy violation, authorized (benign true positive), benign-confirmed, or undetermined). Then impact, likelihood, confidence on the shared rubric, the matrix cell and priority, any override applied, and the recommended move.

6. Containment actions taken

What was preserved before containment, then what containment was already done from the reversible pre-authorized list (host isolated, account disabled, sessions revoked) and how each action was verified, each with its time; what was deliberately not done and why; and which actions await IR or owner approval, including every non-reversible step such as a credential reset or a consent-grant removal.

7. Artifacts

Relevant log excerpts, IOCs , hashes, screenshots, queries. Attached or linked so the next analyst does not have to re-derive them. Each artifact carries its custody and preservation state: where the original lives, its identifying hash, and who has handled it, per the chain-of-custody procedure. Evidence at risk is listed too: each source with its retention window and export status, and whether volatile evidence (memory) was captured. If the case ends up in front of a regulator or a court, this field is what keeps the evidence usable.

8. Open questions

What the triage analyst could not resolve and would have pursued next. 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. For example: IR on-call paged at 14:01. SOC manager paged at 14:02. Compliance updated at 14:18. Vendor request escalated at 14:35. Prevents duplicate notifications and contradictory messages, gives IR an instant view of who already knows, and starts the audit trail for regulatory reporting. How to word those notifications is on the language card, which channels to trust is under out-of-band communication, and the communication record shows the row format.

The fields above match the shipped template, which also carries the optional P1 page block and the receipt:

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 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

The packet is documentation

The handoff packet is also the documentation record. Months later, this packet is what an auditor or a post-incident reviewer will read. Writing it for clarity (not just brevity) pays off the moment someone needs to understand the case without the analyst present.

Handoff acceptance: the receipt

The packet is sent by triage but completed by the receiver. Whoever accepts the case fills in three lines at the top:

Accepted by and at: the named owner of the next action, and the time (UTC). Until this is filled in, triage still owns the case, and the acknowledgment fallback is still running.
Escalation warranted: yes, no, or partially, with one line of why. A “no” is a handback with a named reason, not a silent close (see De-escalation). Case D shows a worked receipt for a handback.
Rework requested: the sections that were missing or had to be re-investigated, or “none”.

A shift change uses the same receipt: until the incoming analyst fills in the receipt line, the outgoing analyst still owns every open case and its clock (see shift handover). The receipt is how a SOC learns whether its packets work. Rework requests and handback reasons, counted over a quarter, point at the sections analysts most often leave thin.

What makes a packet actionable

A complete packet still fails if it does not pass a few practical tests. The methodology asks the analyst to verify three properties before declaring a packet ready for handoff.

Can be read in five minutes

The case summary plus the Risk verdict should give the receiving tier the picture in under five minutes. Detail lives in the remaining sections, which the reader navigates by heading. The opening should orient, not exhaust.

Names the next decision

A good packet does not just describe the case; it tees up the decision the next tier needs to make. “Isolate the second host,” “engage compliance,” “contain the federated session”: concrete recommendations.

Survives the cold read

An analyst who was not involved should be able to open the packet, understand the case, and continue the work. If the packet requires the triage analyst’s presence to interpret, it is not actionable yet.

A packet that fails the cold-read test

A common anti-pattern: the packet reads as a sequence of analyst thoughts (“I checked X, looked OK, then I checked Y, found something weird”). The narrative makes sense to the person who wrote it. Someone reading it cold has no idea what was concluded.

The fix is structural. Replace the analyst-narrative voice with the nine-section format above. Each section answers a specific question; the reader can navigate them without reading the others. The case summary at the top tells the reader whether they need to read the rest at all.

Test the packet by handing it to a peer who has no context on the case. If they cannot summarize the verdict in one sentence after five minutes, the packet is not done. On a P1, the receiving responder is the cold reader: page first, and treat their first questions as the test results.

Key takeaway

When a case escalates, the handoff packet is the triage analyst’s deliverable. A metadata header with the receipt, then nine named sections, each one a documented answer to a question the next tier would otherwise have to ask. Three practical tests: readable in five minutes, names the next decision, survives the cold read.

Next up

Escalation working example

See the example

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

Edit this page on GitHub Report a correction