Why Incident Documentation Matters
Most organizations focus entirely on stopping DDoS attacks and give little thought to documenting them. That approach works until you need to file a cyber insurance claim, request SLA credits from your hosting provider, provide evidence in legal proceedings, or demonstrate compliance during an audit. At that point, the quality of your documentation determines whether your claim is approved, your credits are granted, or your audit passes.
The challenge is that collecting evidence during an attack is difficult. Your team is focused on keeping services running, not on preserving forensic data. Logs get rotated. Packet captures fill up disk space and get deleted. Traffic graphs show the spike, but nobody screenshots them before the monitoring tool ages out the high-resolution data. Two weeks later, when the insurance adjuster asks for proof, you are scrambling to reconstruct what happened from fragments.
Proper documentation must be automatic, comprehensive, and tamper-evident. If you rely on manual collection during the chaos of an active attack, you will miss critical evidence every time.
The best time to set up DDoS incident documentation is before an attack happens. Automated collection systems capture everything in real time, producing evidence that is both complete and verifiable.
What Evidence You Need to Collect
Every DDoS incident report needs the same core evidence, regardless of whether it is for an insurance claim, a compliance audit, or a legal proceeding. The specifics vary by audience, but the foundation is identical.
Timestamps and duration
Every event must be timestamped in UTC with sub-second precision. This includes: when the attack was first detected, when each mitigation action was taken, when the attack peaked, when the attack ended, and when mitigation was withdrawn. Inconsistent or missing timestamps are the number one reason incident reports fail to withstand scrutiny.
- Detection timestamp: When your monitoring system first identified anomalous traffic.
- Alert timestamp: When the first notification was sent to your team.
- Mitigation timestamps: When each mitigation action was deployed (firewall rules, BGP announcements, scrubbing activation).
- Peak timestamp: When the attack reached its maximum volume.
- Resolution timestamp: When attack traffic ceased or was fully mitigated.
- All-clear timestamp: When mitigation rules were removed and normal operations resumed.
Traffic volumes and attack classification
You need quantitative data about the attack: peak bits per second, peak packets per second, total bytes transferred during the attack window, and the attack classification (SYN flood, UDP amplification, DNS reflection, HTTP flood, multi-vector, etc.). This data must come from your monitoring tools, not from estimates or recollections.
# Essential traffic metrics to capture: Peak inbound bandwidth: 47.3 Gbps (at 2026-05-20T14:23:17Z) Peak packet rate: 31.2 Mpps (at 2026-05-20T14:23:19Z) Total attack duration: 2 hours 17 minutes Total attack volume: 38.4 TB Attack vectors: UDP amplification (DNS, NTP), SYN flood Source IPs observed: 142,847 unique addresses Source ASNs: 1,247 unique ASNs Targeted destination: 198.51.100.10:443
Source IP addresses and ASN data
A list of source IPs (or at least the top contributors) and their associated autonomous system numbers. This data is critical for ISP abuse reports and for demonstrating the distributed nature of the attack. If the attack used spoofed source IPs (common in amplification attacks), document the reflector IPs and the spoofed source characteristics.
PCAP samples
Packet captures provide the most granular evidence of an attack. A full PCAP of a multi-gigabit flood is impractical (it would be terabytes), but representative samples are essential. Capture 30 to 60 seconds of traffic at the beginning of the attack, at peak, and at the end. These samples allow forensic analysis of the attack characteristics and serve as verifiable proof of the traffic patterns.
# Capture a 30-second PCAP sample during an attack tcpdump -i eth0 -w /evidence/attack-sample-$(date +%s).pcap \ -c 1000000 -s 128 'not port 22' # Capture only attack traffic (UDP amplification example) tcpdump -i eth0 -w /evidence/udp-amp-sample.pcap \ -c 500000 -s 128 'udp and (src port 53 or src port 123)'
Mitigation actions with timestamps
Every action taken to mitigate the attack must be logged: firewall rules deployed, BGP announcements made, scrubbing services activated, services taken offline, and any manual interventions. Each entry needs a timestamp, the person or system that initiated the action, and the specific parameters of the action.
Automated logging is critical. Flowtriq logs every detection event, mitigation action, escalation decision, and de-escalation with UTC timestamps and the exact rules deployed. This audit trail is generated automatically, so no evidence is lost during the chaos of an active attack.
Chain of Custody for Digital Evidence
If your documentation might be used in legal proceedings, chain of custody matters. Digital evidence must be collected, stored, and handled in a way that proves it has not been tampered with. This is not just a legal formality; insurance underwriters and auditors also look for evidence integrity.
Hashing and integrity verification
Every PCAP file, log extract, and traffic report should be hashed immediately upon creation using SHA-256. Store the hashes separately from the evidence files. This allows anyone to verify later that the evidence has not been modified since collection.
# Hash evidence files immediately after capture sha256sum /evidence/attack-sample-1716220800.pcap \ >> /evidence/checksums.sha256 # Verify integrity later sha256sum -c /evidence/checksums.sha256
Immutable storage
Store evidence in a location where it cannot be modified or deleted. AWS S3 with object lock, Azure Blob Storage with immutability policies, or a dedicated write-once storage system. The goal is to demonstrate that evidence was captured at a specific time and has not been altered since. Timestamps from the storage system itself serve as corroborating evidence of when files were created.
Access logging
Log every access to the evidence repository. If someone downloads a PCAP file for analysis, that access should be recorded. This demonstrates that the evidence was handled properly and that only authorized personnel accessed it.
Structuring the Incident Report
A well-structured incident report follows a standard format that satisfies multiple audiences. Whether you are submitting to an insurance company, presenting to auditors, or filing with law enforcement, the same structure works with minor adjustments for each audience.
Executive summary
A one-paragraph overview: what happened, when, how long it lasted, what was affected, and what was done about it. This is for executives and non-technical stakeholders who need the high-level picture.
Timeline of events
A detailed chronological timeline with UTC timestamps for every significant event. Start from the first anomalous traffic and end at full service restoration. Include detection, notification, each mitigation action, escalation decisions, and de-escalation. This is the backbone of the report and must be precise.
Impact assessment
Quantify the damage. This includes: services affected, duration of outage or degradation, number of users impacted, revenue lost (if calculable), SLA violations triggered, and any downstream effects on partners or customers. Be specific and factual. Insurance adjusters and auditors want numbers, not vague statements about "significant impact."
Technical analysis
The detailed technical breakdown: attack vectors, traffic volumes, source analysis, mitigation techniques used, and their effectiveness. This section references the raw evidence (PCAPs, traffic graphs, log extracts) and is written for a technical audience.
Response evaluation
An honest assessment of how the response went: what worked, what did not, what took longer than expected, and what improvements are needed. This section demonstrates maturity to auditors and helps with continuous improvement internally.
What Different Audiences Need
ISP abuse reports
When filing abuse reports with ISPs whose networks are sourcing attack traffic, you need PCAP evidence showing the attack packets with source IPs from their network, traffic volume data, timestamps, and a clear statement of impact. ISPs receive thousands of abuse reports; the ones with concrete evidence get acted on. Include at minimum: PCAP samples, source IP lists mapped to the ISP's ASN, traffic graphs, and a formal request for investigation.
Insurance underwriters
Cyber insurance claims for DDoS require proof that an attack occurred, proof of the financial impact, and documentation that you had reasonable security measures in place. Underwriters typically want: the incident report, traffic evidence showing the attack, a timeline demonstrating timely response, evidence of pre-existing DDoS protection measures, and a financial impact statement backed by data (lost transactions, SLA penalty payments, emergency response costs).
Many cyber insurance policies require that you had "reasonable" DDoS protection in place at the time of the attack. If you cannot document your detection and mitigation capabilities, the claim may be denied even if the attack is well-documented.
Compliance auditors (PCI DSS, SOC 2, DORA)
Each compliance framework has specific requirements around incident documentation:
- PCI DSS (Requirement 12.10): Requires an incident response plan that is tested annually, with documentation of all security incidents. DDoS attacks affecting cardholder data environments must be documented with root cause analysis and remediation actions.
- SOC 2 (CC7.4, CC7.5): Requires that security incidents are identified, reported, and responded to using a defined process. Auditors want to see the incident report, the response timeline, and evidence that your incident response procedures were followed.
- DORA (Digital Operational Resilience Act): EU financial sector regulation requiring detailed incident classification, reporting to authorities within specific timeframes (initial notification within 4 hours for major ICT incidents), and post-incident reviews. DDoS attacks that disrupt critical financial services are reportable incidents under DORA.
DORA compliance note: Under DORA, financial entities must classify ICT-related incidents based on impact criteria including duration, number of clients affected, and data loss. A DDoS attack causing service disruption for more than 2 hours to more than 10% of clients is likely classified as a "major" incident requiring regulatory notification.
Legal proceedings
If the attack leads to litigation (against the attacker, or from customers who suffered damages), evidence must meet a higher standard. Chain of custody documentation becomes essential. Evidence must be collected by personnel who can testify about the collection process. PCAP files must have verified integrity hashes. The timeline must be corroborated by multiple independent sources (your monitoring system, your ISP's logs, your cloud provider's dashboards).
How Automated Detection Platforms Generate Documentation
The fundamental challenge with DDoS documentation is that attacks happen fast, under stressful conditions, and your team is focused on mitigation, not record-keeping. Automated detection platforms solve this by generating documentation as a byproduct of their normal operation.
Flowtriq produces the following automatically for every detected incident:
- Attack timeline: Detection, classification, escalation, and resolution timestamps with sub-second precision.
- Traffic analysis: Peak BPS, peak PPS, attack vectors, protocol breakdown, source IP distribution, and ASN mapping.
- Mitigation log: Every rule deployed, every BGP announcement made, every escalation decision, with timestamps and the triggering metrics.
- Historical baselines: What normal traffic looked like before the attack, providing context for the anomaly.
- Exportable reports: PDF and JSON incident reports that can be submitted to insurers, auditors, or legal teams without manual compilation.
This automated approach means that by the time the attack is over, the documentation already exists. There is no scramble to collect evidence after the fact, no reliance on team members remembering to take screenshots during a crisis, and no gaps caused by log rotation or monitoring data expiration.
Evidence retention
Different compliance frameworks and insurance policies have different retention requirements. PCI DSS requires one year of audit trail history. SOC 2 typically requires retention for the audit period (usually 12 months). DORA requires retention for at least 5 years. Insurance policies may require evidence to be available for the duration of the policy plus a claims tail period.
Configure your evidence retention policies before an attack happens. Ensure that traffic data, logs, and PCAP samples are stored in immutable storage with retention periods that meet your compliance obligations. Automated systems like Flowtriq can be configured to export incident data to your long-term storage automatically.
Building Your Documentation Checklist
Use this checklist to ensure you are capturing everything you need, whether manually or through automated tools:
- Pre-incident: Document your DDoS detection and mitigation capabilities. This proves "reasonable measures" for insurance and demonstrates compliance posture for auditors.
- During incident: Capture traffic data (BPS, PPS, protocol breakdown), PCAP samples, source IP lists, mitigation actions with timestamps, and service impact metrics.
- Post-incident: Compile the incident report with executive summary, timeline, impact assessment, technical analysis, and response evaluation. Hash all evidence files. Store in immutable storage.
- Retention: Archive the complete incident package according to your compliance and insurance retention requirements (minimum 1 year, up to 5+ years for DORA).
- Review: Conduct a post-incident review within 72 hours. Document lessons learned and update your response procedures.
Start building your incident documentation capability before the next attack. Try Flowtriq free for 7 days and see how automated detection generates compliance-ready incident reports from day one.
Back to Blog