The first incident report should fit on one page

Start the clock and name the impact

A useful incident record begins with the observation time and time zone, not with a confident root-cause label. State what a user cannot do: open the public site, download a file or complete a particular application operation. Note whether the failure is continuous or intermittent. Assign one person to maintain the record so that later updates do not contradict the first report. Keep the original observation even if the working explanation changes.

Keep evidence proportional to the question

Record the public URL, response status if available and a small set of representative timestamps. Ask the receiving support team which additional logs it needs. Avoid pasting a complete configuration or a large log archive into a public thread; those files can contain details unrelated to the incident. Preserve originals privately and share only the relevant, appropriately redacted material through the agreed support route. The aim is to make investigation possible without creating a second problem.

Distinguish observation from classification

An unavailable service can have several causes. CISA’s joint DDoS guidance describes attacks aimed at exhausting availability and the need for preparation and response planning. An operator should still establish what the current evidence supports. A traffic increase, an application exception and a recent configuration change are separate observations. Mark a proposed explanation as provisional, and record which party will investigate it. That makes the handover more useful than a subject line that declares an attack before anybody has checked.

Escalate through the arrangement you actually bought

If the service uses KoDDoS DDoS mitigation, keep the appropriate support route, covered service and agreed scope in the private runbook. Supply the affected address and the evidence requested by the provider, then retain the case reference. Confirm which party handles the application while the traffic path is being investigated. Avoid changing unrelated firewall, DNS and application settings simultaneously: each additional change makes it harder to compare the next observation with the original failure.

Define what recovery will look like

Choose the same user operation named in the first report and repeat it after the proposed fix. Check a representative interval rather than declaring success from one lucky refresh. Record the result, remaining limitations and who will follow up. If the cause is still uncertain, say so in the closing note. A complete operational record can describe an observed recovery without claiming that every technical question has already been answered.

Put it into practice