What is an incident response report?
An incident response report is a formal document that captures the complete story of a security incident, including the who, what, when, where, why, and how of what occurred. With 12,195 confirmed breaches documented in Verizon's 2025 DBIR alone, this document serves as the single source of truth for technical remediation, executive communication, regulatory compliance, and organizational learning. Without it, teams repeat mistakes and struggle to justify security investments against a $4.88 million average breach cost.
Many people confuse an incident response plan with an incident response report. The plan describes what you will do before an incident happens. It outlines roles, escalation paths, and playbooks. The report documents what you actually did after an incident occurred. It captures findings, actions taken, and lessons learned.
IR reports serve multiple audiences simultaneously. SOC analysts need technical depth to understand attacker techniques. Executives need business impact to make resource decisions. Legal counsel needs evidence chains for potential litigation. Compliance teams need audit trails for regulatory reporting. A well-structured cyber incident report addresses all these needs in a single document.
Core components of an incident response report
Effective reports follow a predictable structure that serves multiple audiences. Consistency matters because it allows readers to quickly find what they need regardless of incident type. The table below shows each section, its purpose, and the key questions it answers.
| Component | Purpose | Key questions answered |
|---|---|---|
| Executive summary | Non-technical overview for leadership | What happened? How bad was it? What are we doing about it? |
| Incident timeline | Chronological sequence of events | When did each phase of the attack occur? |
| Technical analysis | Deep dive into attacker TTPs | How did they get in? What techniques did they use? |
| Impact analysis (blast radius) | Scope of compromise | What systems, data, and identities were affected? |
| Response and containment actions | What the team did to stop the incident | How was the threat neutralized? |
| Root cause analysis | Why the incident was possible | What vulnerability, misconfiguration, or gap enabled this? |
| Lessons learned and recommendations | Forward-looking improvements | What changes prevent recurrence? |
| Appendices | Supporting evidence | Logs, IOCs, forensic artifacts, compliance mappings |
Executive summary
The executive summary is the most-read section of any IR report. Executives, board members, and legal counsel often read only this section. It must be understandable by non-technical stakeholders while remaining accurate.
Include three essential elements in every executive summary:
Verdict: What happened in plain language
Impact: How bad it was in business terms
Status: Resolved, ongoing, or monitoring
Keep this section to one page or less. If it requires scrolling, it is too long. Write this section last, after all technical analysis is complete, to ensure accuracy.
Incident timeline
Chronology is critical for understanding attack progression and identifying where defenses failed. Modern cloud incidents require correlating multiple log sources: CloudTrail or Activity Logs for control plane events, VPC Flow Logs for network activity, runtime events from workloadsworkload runtime telemetry, and identity provider logs for authentication.
Manual correlation across these sources takes hours. Automated timeline generation reduces this dramatically by stitching events together based on identities, resources, and temporal proximity. The best timelines show not just "what happened when" but "what could have happened next," including potential lateral movement paths the attacker could have taken.
Always normalize timestamps to a single timezone. UTC is recommended to avoid confusion when multiple teams across regions review the incident response timeline.
Technical analysis
Document attacker tactics, techniques, and procedures (TTPs) mapped to frameworks like MITRE ATT&CK for consistent terminology. Cover these key areas:
Initial access vector: How did they get in?
Execution methods: What did they run?
Persistence mechanisms: How did they maintain access?
Exfiltration attempts: What did they try to take?
Cloud-specific considerations differ from traditional IR. Look for API abuse patterns, IAM privilege escalation chains, storage bucket access anomalies, cross-account movement, and serverless function manipulation. Include specific log entries, commands observed, and indicators of compromise (IOCs) with context about why they matter.
Technical analysis should be detailed enough for another analyst to reproduce the investigation. If someone reads your IT security incident report six months from now, they should understand exactly what happened.
Impact analysis and blast radius
Blast radius refers to the full scope of what the attacker touched or could have touched given their access level. A graph-based visualization showing relationships between compromised resources, sensitive data, and identity permissions is more actionable than a flat list of affected assets.
Include a one-page blast radius diagram or graph view that highlights:
Initial entry point (the first compromised resource or identity)
Privilege gained (escalation path and permissions acquired)
Sensitive data reachable (databases, storage, secrets the attacker could access)
Containment boundary (where you stopped lateral movement)
This visualization answers leadership's core question: "How bad could this have been?"
Data impact determines regulatory notification requirements. Ask: Was PII, PHI, financial data, or other regulated information exposed? Identity impact matters equally. Document which credentials were compromised, what permissions they had, and what resources they could access.
Root cause analysis
Root cause analysis must go beyond "we found a vulnerability" to explain why that vulnerability existed and was exploitable in your environment. Given that the human element factored into 68% of breaches according to Verizon's 2024 DBIR, modern RCA should trace the runtime incident back to the code commit, IaC template, or pipeline misconfiguration that created the exposure.
Without code-to-cloud tracing, remediation is reactive. You patch production but the same issue deploys again next week. With code-level tracing, you fix the source so the issue never deploys again.
Common root cause categories include:
Misconfiguration or insecure defaults
Missing patches or outdated dependencies
Overly permissive IAM policies
Exposed secrets in repositories or environment variables
Supply chain compromise
The best RCA section ends with the preventive control: the guardrail, policy, or pipeline check that would have stopped the same vulnerability or misconfiguration from shipping again. Without this, RCA remains reactive, and you fix production but the same issue redeploys next sprint.
Lessons learned and recommendations
Turn findings into actionable improvements. Recommendations should be specific and measurable, not generic.
Good: "Implement MFA on all IAM roles with admin permissions within 30 days"
Bad: "Improve security posture"
This section often becomes input for security roadmaps and budget justifications. Quantify effort and impact where possible. Assign owners and deadlines to each recommendation to ensure accountability. Share lessons learned across teams to prevent similar incidents in other parts of the organization.
Wiz's approach to incident response reporting
Wiz Defend addresses the core challenges of incident response by connecting detection, investigation, and documentation in a single platform. Rather than manually stitching together logs from CloudTrail, runtime events, and identity providers, Wiz correlates cloud API logs, runtime sensor data, and identity events into a unified incident narrative automatically.
The automated attack timeline removes hours of manual work. When an incident occurs, Wiz Defend generates a chronological view of events correlated by identity, resource, and time. Responders see the full sequence of attacker actions without switching between consoles or writing custom queries.
The Wiz Security Graph visualizes relationships between compromised resources, sensitive data, and identity permissions. Instead of creating a blast radius analysis manually, teams see the attack path and potential lateral movement immediately. This visual representation answers the "what could have happened next" question that leadership needs for prioritization decisions.
For root cause analysis, Wiz Code provides code-to-cloud correlation. The platform traces a runtime incident back to the specific repository, build artifact, and developer who introduced the vulnerability or misconfiguration. This shifts remediation from reactive patching to preventive fixes at the source.
The Wiz Runtime Sensor captures runtime telemetry from ephemeral workloads before they terminate. Containers and serverless functions that would otherwise vanish leave investigation evidence behind for appendices and post-incident review.
Get a personalized demo of Wiz Defend to see how automated investigation, attack timeline generation, and graph-based blast radius analysis can streamline incident response reporting for cloud environments.
Detect active cloud threats
Learn how Wiz Defend detects active threats using runtime signals and cloud context—so you can respond faster and with precision.
