TR0.9 The Triage Report Template

The handoff problem

The triage report is the handoff artifact. Its purpose is to transfer everything the triage analyst learned — classification, scope, evidence, containment actions, outstanding questions — into a structured document the investigation team can act on without re-deriving any of it. A good triage report saves the investigation team 30–60 minutes. A missing or unstructured report forces them to repeat work that was already done.

The cost of a poor handoff compounds. The investigation team spends 40 minutes reconstructing scope. During that time, the attacker may still be operating in areas the triage analyst contained but the investigation team doesn't know about. Regulatory clocks keep running. The CISO is waiting for an executive summary that nobody can produce because the scope hasn't been formally documented. Each gap in the handoff creates downstream delays that multiply through the incident lifecycle.

The report is also the first legal document in the incident record. It establishes the moment of awareness (when GDPR, NIS2, and DORA notification clocks start), the initial scope assessment used for executive briefing and regulatory notification, the evidence chain where chain of custody begins, and the containment record demonstrating due diligence. A Slack message satisfies none of these requirements. It isn't timestamped reliably, isn't structured for regulatory review, and can be edited or deleted after the fact.

Writing the report during triage, not after

The critical discipline is concurrent documentation. Each section should be populated as the triage progresses, not reconstructed from memory afterward. Classification goes in at minute 3 when the TP/FP decision is made. Scope goes in at minute 8 when the cross-environment check completes. Findings accumulate throughout as each indicator is confirmed. Containment is documented action-by-action as each command executes. When containment verification passes, the analyst adds Section 5 recommendations and the report is complete. No separate documentation phase needed.

This is why the template exists — it makes concurrent documentation possible. Without a template, analysts either write the report after triage (which means reconstructing from memory and losing details) or don't write it at all (which means the investigation team starts from scratch). The template converts documentation from a separate task into a natural part of the triage workflow.

Analysts who say "I don't have time to document during triage" are describing a process problem, not a time problem. If documentation happens after triage, the analyst must reconstruct the sequence from memory — which commands were run in which order, which timestamps correspond to which actions, which findings were confirmed versus suspected. Memory is unreliable under pressure. Details are lost.

The triage report written afterward is less accurate than the one written in real time, and it takes longer to produce because reconstruction is harder than recording.

Automating Section 2 with PowerShell

For teams that maintain an asset inventory, Section 2 (Scope) can be partially automated. The following script pulls the compromised user's group memberships, assigned applications, and data access to pre-populate the scope section:

# Pre-populate triage report Section 2 — Scope
$CompromisedUser = "j.morrison@northgate-eng.com"
# What groups does this user belong to?
$Groups = Get-MgUserMemberOf -UserId $CompromisedUser |
    Select-Object -ExpandProperty AdditionalProperties |
    Where-Object { $_.'@odata.type' -eq '#microsoft.graph.group' }
# What apps can this user access?
$Apps = Get-MgUserAppRoleAssignment -UserId $CompromisedUser |
    Select-Object ResourceDisplayName, AppRoleId
# Output for Section 2
Write-Host "--- SECTION 2: SCOPE (auto-populated) ---"
Write-Host "Groups: $($Groups.Count) memberships"
$Groups | ForEach-Object { Write-Host "  - $($_.displayName)" }
Write-Host "Applications: $($Apps.Count) assigned"
$Apps | ForEach-Object { Write-Host "  - $($_.ResourceDisplayName)" }

The output tells you what the compromised identity can reach — group memberships reveal lateral movement potential, and application assignments reveal data exposure. This doesn't replace the analyst's scope assessment, but it eliminates the manual lookup step that consumes 5–10 minutes of triage time on identity-based incidents.

The worked example

The CHAIN-HARVEST SSH brute-force from Section 0.4 produces the following triage report. This is the complete document that Rachel's investigation team receives:

Notice the structure: the investigation team knows the classification and why, the full blast radius, exactly what findings were confirmed with ATT&CK mapping, every containment action with verification status, and seven specific next steps. They can start working immediately. No re-deriving scope. No hunting for evidence. No asking the triage analyst "what did you find?"

Dual-audience reporting

The full report serves the investigation team and the SOC lead. But Rachel's CISO and DPO don't need finding IDs and ATT&CK mappings. They need four things: what happened, how bad it is, what was done, and what happens next. Add a 4-line executive summary at the top of any confirmed TP report.

The executive audience makes decisions based on business risk, not technical indicators. "T1110.001 SSH brute force" means nothing to the DPO. "An attacker gained access to a database containing 85,000 customer records" drives a decision. The technical audience needs the ATT&CK mapping to plan investigation steps. The executive audience needs the regulatory implications to plan notification and communication. Both audiences receive the same underlying report — the executive summary is a lens on top, not a separate document.

This dual-audience approach also protects against a common failure mode: the triage analyst writes an executive-friendly summary and skips the technical detail. The investigation team then receives a report that tells them what happened in business terms but doesn't tell them where to look. The 5-section template prevents this by requiring both the technical detail (Sections 3–5) and the executive layer (the summary at the top). Neither can substitute for the other.

The executive summary should be written last, after the full report is complete. It distills the five sections into four sentences that can be read in 30 seconds. Every claim in the executive summary must trace back to a finding in the full report — this is not the place for speculation or unconfirmed scope.

The four-sentence structure is deliberate. Sentence one states what happened in business terms. Sentence two states the scope and potential impact. Sentence three states what containment actions were taken. Sentence four states what happens next — specifically the regulatory or business decisions that need to be made. Resist the temptation to add qualifications, hedges, or technical detail. The executive summary exists to enable a decision in 30 seconds. If the CISO needs technical detail, they read the full report.

If they need a decision briefing, they read the four sentences.

One common mistake: writing the executive summary before containment is confirmed. The CISO receives "all environments contained" and makes decisions based on that. Ten minutes later, verification reveals the containment on the Linux server failed and the C2 beacon respawned. Now the executive summary is wrong and the CISO has already briefed the board. Write the summary after verification. "Containment executed, verification in progress" is acceptable if time pressure demands an early brief — but it must be flagged as incomplete.

Report quality: the five mistakes that waste investigation time

Vague classification without evidence. "Classification: TP" without specifying which finding confirmed the TP. The investigation team cannot validate the classification without seeing the evidence. Every classification must reference at least one IF-numbered finding or specific indicator.

Incomplete scope. Listing the compromised system but not the blast radius. "SRV-NGE-BRS-DB01 compromised" without noting the 85,000 PII records, the 12 reachable Linux servers, and the CI/CD deploy key forces the investigation team to re-derive scope — 30–60 minutes of repeated work.

Missing containment verification. Documenting containment actions but not the verification results. "iptables block applied" is insufficient. The report must confirm the block is effective — "C2 connection transitioned from ESTAB to SYN-SENT, verified at 15:23." Unverified containment may leave the attacker operating while the investigation team believes the environment is contained.

Timestamps without timezone. "Alert fired at 15:10" — is that UTC, BST, or local server time? All timestamps in the triage report must specify UTC. If the original alert was in local time, convert to UTC in the report and note the conversion. Ambiguous timestamps create confusion during cross-environment correlation and become a serious problem during regulatory review when the notification clock depends on the exact moment of awareness.

Narrative without structure. A free-text description of what happened without the 5-section format. Even FP classifications use the template: "Section 1: FP — Legitimate admin activity from authorized IP. Section 2: N/A. Section 3: Alert triggered by scheduled maintenance script. Section 4: No containment required. Section 5: Tune the analytics rule to exclude this maintenance window." The structure is the discipline. Unstructured reports force the investigation team to parse prose to extract classification, scope, and containment status — work the template eliminates entirely.

FP reports are shorter but equally important. They build the tuning backlog. If every FP report includes a Section 5 recommendation ("tune this rule to exclude scheduled maintenance from the svc-backup account"), the detection engineering team accumulates a prioritized list of rules to refine. FP reports without recommendations leave the same alert firing next week, consuming another 15 minutes of analyst time on the same false positive.

KQL: generating the report header automatically

For teams using Sentinel, the report header fields can be pulled directly from the incident:

// Generate triage report header from Sentinel incident
let IncidentId = "INC-NE-2026-0406-001";
SecurityIncident
| where IncidentNumber == IncidentId
| project
    IncidentNumber,
    Title,
    Severity,
    CreatedTime,
    FirstActivityTime,
    LastActivityTime,
    // Scope: entities involved
    AlertCount = array_length(AlertIds),
    Owner = Owner.assignedTo,
    Status,
    Classification
| extend
    AlertWindow = LastActivityTime - FirstActivityTime,
    TriageDuration = now() - CreatedTime

The query returns the incident metadata — reference number, alert source, severity, timeline, and current owner. This eliminates transcription errors in the report header and ensures the timestamp is in UTC from the source.