Incident Response Documentation with Claude

25 min · S2
Module Objective
Incident response has a documentation problem. The investigation takes 4 hours. The report takes 6. The CISO needs both by end of business. You are simultaneously investigating, containing, and writing — and the writing is the bottleneck. Claude does not investigate for you. It drafts the documentation while you investigate — compressing timeline reconstruction, report writing, executive summaries, and stakeholder communications from hours to minutes.
Deliverable: Five IR documentation workflows — timeline reconstruction from raw notes, technical report section drafting, executive summary generation, stakeholder communication templates, and evidence documentation — with the specific prompt patterns and Project configuration that produce report-ready output.
⏱ Estimated completion: 25 minutes
IR DOCUMENTATION PIPELINE — CLAUDE AS CO-PILOTRAW NOTESTimestamps, IPs, actionsCLAUDE DRAFTSTimeline, report, summaryANALYST VERIFIESFacts, context, conclusionsREPORT READY1-2 hrs, not 4-8DELIVEREDCISO, board, regulatorInvestigation time: unchanged. Documentation time: compressed by 60-75%.

Setting up an incident-specific Project

For each significant incident, create a dedicated Claude Project (F2). The incident Project contains the case context (incident ID, affected users, timeline constraints, sanitization requirements) in the system prompt, and the investigation’s accumulated evidence exports and previous report drafts as uploaded documents. Every conversation in the incident Project inherits this context — Claude already knows the incident details when you start drafting.

Worked artifact — incident Project system prompt:

You are assisting with IR documentation for incident INC-2026-0315-001 (AiTM credential phishing — 5 accounts compromised, financial email forwarding detected).

Key context:

  • Incident detected: 2026-03-15 10:00 UTC
  • Containment completed: 2026-03-15 16:30 UTC
  • Affected users: 5 (j.morrison, s.patel, r.chen, a.williams, d.kumar — all sanitized names)
  • Patient zero: j.morrison (first token replay at 09:35 UTC)
  • Attacker infrastructure: 198.51.100.44 (VPS), hxxps://login-northgate[.]com
  • Evidence sources: Sentinel SigninLogs, Purview Unified Audit, Defender XDR Advanced Hunting, eDiscovery export
  • Report format: Ridgeline IR report template (uploaded)
  • Audience: Technical report for SOC team, Executive summary for CISO and board
  • Sanitization: All names are fictional. Do not reference any real organization.

Create a new Project for each significant incident. The system prompt becomes the investigation’s standing context — every documentation task inherits it automatically.


Workflow 1: Timeline reconstruction

You have raw investigation notes — timestamps, IP addresses, actions, and findings scattered across your notepad, Sentinel queries, and email threads. Claude organizes them into a structured chronological timeline suitable for the technical section of the IR report.

Paste your raw notes into a <raw_notes> tag. Specify the timeline format you need (chronological entries with timestamp, actor, action, evidence source, and significance). Claude produces a structured timeline that you verify against the evidence and refine.

The timeline is typically the most time-consuming section to write manually because it requires organizing disparate data points from multiple sources into a coherent narrative. Claude compresses this from an hour of manual organization to five minutes of prompt + verification.


Workflow 2: Technical report sections

Once the timeline is drafted, Claude generates the remaining technical report sections — scope of compromise, attack chain analysis, containment actions taken, evidence summary, and recommendations. Each section can be generated in a separate prompt within the incident Project.

The key to effective report section generation is providing the findings, not asking Claude to make them up. Paste the specific evidence (sanitized log excerpts, query results, containment actions) and ask Claude to write the report section. Claude structures the prose and presents the evidence clearly. You verify the facts and refine the language.


Workflow 3: Executive summary

The executive summary requires a different voice than the technical report. It must communicate impact, response actions, and residual risk in language the CISO and board understand — without technical jargon, without KQL, without log excerpts.

Ask Claude to generate the executive summary from the technical report (which is already in the Project context from previous conversations). Specify the audience (“CISO and board members who are not security practitioners”), the length (“one page, no more than 400 words”), and the structure (“incident summary, business impact, response actions, current status, recommendations”).


Workflow 4: Stakeholder communications

Different stakeholders need different communications — and the first 72 hours of an incident leave no time to craft each one from scratch.

Claude generates stakeholder-specific communications from the same investigation context: an internal notification to IT staff (technical, action-focused), an employee communication (clear, reassuring, with specific instructions), a board briefing (strategic, risk-focused), and a regulatory notification draft (structured per the reporting framework — ICO, GDPR Article 33, or your applicable regulator).

Worked artifact — stakeholder communication prompt:

<task>
Generate four stakeholder communications for INC-2026-0315-001
based on the incident context in this Project.
</task>

<output_format>
Four separate documents:

1. Internal IT notification — technical details, what happened,
   what actions IT staff should take, who to contact for questions

2. Employee communication — non-technical, what happened at a
   high level, what employees should do (change passwords, report
   suspicious emails), reassurance that containment is complete

3. Board briefing — business impact, regulatory implications,
   response timeline, residual risk, strategic recommendations

4. Regulatory notification draft — structured for ICO breach
   notification under GDPR Article 33, including nature of breach,
   categories and approximate number of individuals affected,
   likely consequences, and measures taken

Each document should be draft-ready — not a template with
placeholders but actual content based on the incident facts.
</output_format>

Claude produces four distinct communications from the same investigation context. Verify every fact in each document. The regulatory notification draft should be reviewed by legal counsel before submission.


Workflow 5: Evidence documentation

During the investigation, Claude assists with evidence log entries, chain of custody documentation, and findings summaries. Paste the evidence details (file hash, collection timestamp, source system, collection method) and ask Claude to format the evidence log entry or chain of custody record. This is pure formatting acceleration — the facts come from you, Claude structures them into the required documentation format.

Compliance Myth
"AI-generated IR reports are not admissible or credible because they were written by a machine."
Production reality: The analyst investigated the incident, collected the evidence, made the containment decisions, and verified every finding. Claude assisted with the documentation — structuring the timeline, drafting the prose, and formatting the communications. The report's credibility comes from the evidence it presents and the analyst's verification, not from the tool used to draft it. Word processors, spelling checkers, and templates have always assisted report writing without undermining credibility. Claude is a more capable writing assistant, but the analytical work and the verification remain human. The verification step is what matters — a Claude-drafted report that has been verified by the analyst is more reliable than a manually written report that was rushed due to time pressure.

Try it: Draft an IR timeline from raw notes

Create an incident Project with the system prompt template above (modify for a fictional incident). Paste a set of raw investigation notes — timestamps, IPs, user actions, and findings — into a conversation. Ask Claude to produce a chronological investigation timeline with columns for timestamp, actor, action, evidence source, and significance. Verify the timeline against your notes. Is the chronological ordering correct? Are the evidence source attributions accurate? This is the workflow you will use during every real investigation to compress timeline construction from an hour to five minutes.


Knowledge checks

Check your understanding

1. You are writing an IR report for a BEC incident. The CISO needs the executive summary by end of business. You have completed the investigation and have detailed findings. What is the fastest way to produce a CISO-ready executive summary using Claude?

Use the incident Project. The technical findings are already in the Project context from previous conversations. Ask Claude to generate a one-page executive summary specifying the audience (CISO, non-technical board), the structure (incident summary, business impact, response actions, current status, recommendations), and the length constraint. Verify every fact before sending. The Project context means Claude already knows the incident details — no re-explanation needed.
Start a new conversation and paste all the findings again
Write it manually — AI should not generate executive communications

2. Claude drafts a regulatory notification for an incident involving personal data. Before submitting to the ICO, what is required?

Submit as-is — Claude knows GDPR requirements
Legal counsel review. A regulatory notification has legal implications — the content determines your organization's compliance posture and potential liability. Claude produces a well-structured draft based on GDPR Article 33 requirements, but legal counsel must verify that the notification is accurate, complete, and appropriate for submission. Claude drafts the document. Legal approves it.
Verify the facts and submit

3. Why create a separate Claude Project for each significant incident rather than using a single Security Operations project?

Incident isolation. Each incident has its own context (affected users, timeline, evidence, containment actions) that should not contaminate other investigations. A dedicated Project ensures Claude's responses are always grounded in the correct incident's facts. It also provides a clean audit trail — every conversation in the incident Project relates to that specific case. When the investigation closes, the Project serves as the documentation archive of the AI-assisted work.
Projects have limited storage — separate projects avoid the limit
There is no advantage — use a single project for all incidents

Key takeaways

Create a dedicated Project for each significant incident. The system prompt contains the incident context. Uploaded documents contain the evidence exports and report templates. Every conversation inherits this context.

Claude compresses documentation, not investigation. The investigation takes the same time. The documentation — timeline, report, summary, communications — takes 60-75% less time.

Different stakeholders need different documents. Claude generates all four (technical, employee, board, regulatory) from the same investigation context. Verify every fact in each.

Regulatory notifications require legal review. Claude drafts the structure. Legal approves the submission.