How should denial-of-service impact be reported?¶
Report attack activity, exhausted resource, service effect, operational consequence, mitigation and attribution as separate conclusions. “The website was taken down” hides the evidence needed to understand causation and scale.
Describe technical effect precisely¶
State the traffic or requests observed, bottleneck, duration, degradation or outage, mitigation and recovery. Hostile traffic can be fully filtered with no user impact, while modest traffic can expose a fragile component and cause serious disruption.
Availability is not binary. A service may respond but be too slow or unreliable for its intended function. Use service standards, errors and performance records.
Evidence the operational consequence¶
Identify affected functions, regions, users, failed transactions, delays or complaints. Do not convert technical downtime directly into financial or business loss without a separate impact assessment.
Explain containment, failover and dependency failures that contributed to impact. Keep suspected botnet or infrastructure attribution separate from controller identification and state all remaining uncertainty.
Key takeaway
Report denial of service from observed attack through resource and service effect to evidenced user impact, without merging mitigation or attribution into the outage claim.
