DDoS Post-Incident Review Template

Most DDoS postmortems produce a narrative and no change. The structure below is deliberately short and ends in owned actions, because a document that nobody acts on has cost an hour of several people’s time and bought nothing.

The external frame most organisations align to is NIST’s incident-handling guidance NIST SP 800 61R3; what follows is the DDoS-specific shape of it.

Header

Incident:        <short identifier>
Date and time:   <start> to <stable clean traffic>
Severity:        <your scale>
Services:        <what was affected>
Attendees:       <names, not roles>
Notification:    <was the significance threshold met? by whom decided? when?>

The six questions

1. What was the measured time from first attack packet to stable clean traffic?

Not “how long did it feel”. The number comes from the incident record, and the point of asking it every time is that it becomes a series rather than an anecdote.

2. Which step in that sequence took longest, and was it technical or human?

The distinction matters more than the total. A four-minute BGP convergence is a design constraint; a forty-minute delay reaching the person authorised to approve diversion is a matrix problem. They have entirely different fixes and are frequently confused.

3. What evidence did we want and not have?

The question most often skipped and the one that pays back most. Telemetry cannot be captured retroactively, so whatever you wished for during the incident will be missing in the next one unless it becomes an action here.

4. Which decision was hardest, and can it be pre-decided?

Anything that took a phone call to resolve is a candidate for a threshold written into the escalation matrix in peacetime.

5. What did we break ourselves?

Threshold changes made under pressure, a rule left in place, a blackhole not withdrawn, a tuning change that was never reverted. Self-inflicted damage during response is normal and worth recording precisely because everyone under-reports it.

6. What changes as a result — with an owner and a date?

An action without both is a wish.

Metrics to record every time

Recording the same set each time turns individual incidents into a trend that shows whether the programme is improving.

Metric	Why
Time to detect	Whether the telemetry is doing its job
Time to mitigate	The number every diversion decision is made against
Time to stable clean traffic	The one the business experienced
Peak attack size, in the unit that mattered	Bits, packets or requests — state which
Vectors observed	Whether the mix is changing over time
Legitimate goodput during mitigation	Whether the defence worked or just blocked
Self-inflicted rejections	The honesty metric
Escalation timings, level by level	Whether the matrix is real

The evidence checklist

Confirm during the review that these exist and are retained, because the next notification deadline depends on them:

• Start and end timestamps for the event and for each mitigation change.
• Vectors observed and the counters that identified them.
• Decisions taken, with authorisation and reason.
• Observed customer impact.
• Traffic samples the retention policy permits.
• What upstream did on your behalf, and what they told you about it.

Anything on that list that was unavailable becomes an action under question three.

Actions table

| Action | Owner | Due | Verification |
|--------|-------|-----|--------------|
|        |       |     |              |

The fourth column is the one that makes the table work: what will prove the action was completed, rather than a status field somebody updates.

Distribution

The review goes to everyone who attended, the escalation-matrix owners, and whoever holds the budget for anything in the actions table. Where the incident met a notification threshold, the compliance owner keeps a copy alongside the notification itself — a regulator asking what changed afterwards is a common follow-up and a document that already exists is a much better answer than one written in response.