How should organisers defend major events against coordinated DDoS campaigns across government and mobility services?

Organisers should treat event defence as an ecosystem problem, not a single-site problem. Prioritise threat intelligence, coordinated incident response, and real-time monitoring across transportation, government, and sponsor-facing services. Build traffic filtering, capacity planning, and escalation paths before the event begins, then rehearse them under realistic attack assumptions. The goal is to preserve service continuity when disruption is designed to spread quickly across critical dependencies.

Why coordinated event DDoS defence has to span multiple services

Major-event DDoS defence fails when teams protect one brand-facing site but ignore the rest of the service graph. Attackers often aim for the most visible public entry point, then exploit shared dependencies such as transport updates, ticketing, government advisories, DNS, or sponsor portals. Defence has to be coordinated across owners because availability problems propagate faster than org charts.

That means the event plan should identify which services are truly critical, which ones can degrade safely, and which external dependencies need explicit contacts and escalation triggers. The practical question is not whether one website survives, but whether the event can keep operating when multiple public services are under pressure at the same time.

Organisers should also follow the ENISA Threat Landscape for the current picture of DDoS pressure on critical services, because the attack pattern is rarely isolated to a single destination.

What controls matter before the event begins

Preparation is mostly about removing avoidable fragility. Traffic filtering, rate limiting, upstream scrubbing, CDN and anycast capacity, and tested fallback paths should be in place before opening day, not improvised during an incident. The organiser should require each participating service owner to confirm who can change rules, who can accept temporary degradation, and who can authorise emergency rerouting.

Capacity planning needs to be specific to the event profile, including expected spikes from transit disruption, media attention, and user retry behaviour. A control that works for normal traffic may fail when multiple services are hit together. Capacity, monitoring thresholds, and incident playbooks should therefore be sized around aggregate demand, not a single service baseline.

Where public-sector and mobility partners are involved, the operating model should include named escalation contacts and shared response assumptions. If one provider must absorb sudden traffic while another service is unavailable, teams need a pre-agreed way to communicate status, publish user-facing guidance, and prevent conflicting remediation actions.

How to run response when the campaign is already spreading

During the event, the priority is coordinated containment, not perfect diagnosis. Real-time monitoring should watch for changes in request mix, geography, protocol behaviour, upstream saturation, and failures in adjacent services. If one control plane is already overloaded, the response must shift traffic management as close to the edge as possible and preserve the most operationally important user paths first.

Response discipline matters because coordinated DDoS often creates noise that masks secondary issues such as misrouted traffic, overloaded third parties, or a failed failover path. Rehearsed comms should distinguish between service impairment, full outage, and partial degradation so teams do not overreact in one place while missing the real choke point elsewhere. Organisers should make sure that transport, government, venue, and sponsor communications all tell the same operational story.

Teams considering response playbooks can use the NIST Cybersecurity Framework 2.0 to structure detect, respond, and recover responsibilities, and the NIST AI Risk Management Framework is not the right fit here; instead, the event should be run as a resilience and service-continuity exercise.

What coordinated event defenders often underestimate

The hardest part is usually not raw bandwidth, it is dependency management. A mobility service outage can increase retry traffic, a government advisory site can become a public trust signal, and sponsor-facing pages can become high-value distraction points. If those services are owned by different organisations, the incident can become a coordination problem before it becomes a technical one.

Another common mistake is treating communications as an afterthought. In a major event, external stakeholders will infer status from whatever remains reachable. If official channels are inconsistent, attackers and outage conditions both win because users move to unverified sources and internal teams waste time correcting the narrative.

NCSC UK Advice and Guidance is useful here because it reinforces the operational side of resilience, not just the technical filtering side, and ISO/IEC 27002:2022 Information Security Controls gives a broader control baseline for supplier, continuity, and monitoring disciplines that matter during events.

Risk and Threat Considerations

Coordinated DDoS during a major event creates more than temporary slowdown. The main risk is correlated failure across transport, government, and sponsor services, where one saturated dependency can cascade into public confusion, service abandonment, and wider operational disruption.

Failure mechanism: Attackers or heavy synthetic demand push edge capacity, upstream links, or shared application dependencies past their safe operating point, while retry storms and failover chatter amplify the load.

Impact: Users lose access to critical information at the exact moment they need it, incident teams lose time to mixed signals, and organisers may have to degrade public services or change event operations to preserve core continuity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Networks and information systems are monitored to detect potentially adverse events	Event DDoS defence depends on live monitoring of service degradation and traffic anomalies.
	RS.MA-1 — Incident response plan is executed	Coordinated DDoS requires rehearsed response actions across multiple service owners.
	RC.RP-1 — Recovery plan is executed during or after an incident	Major-event availability depends on recovery steps that restore service continuity quickly.
Recommendation — Monitor critical services continuously and alert on abnormal traffic or availability shifts. Execute the incident response plan with preassigned roles and escalation triggers. Activate recovery procedures that restore the most critical event services first.
CIS Controls v8	CIS-8 — Audit Log Management	Attack detection and coordination improve when service and edge telemetry are retained and reviewed.
	CIS-13 — Network Monitoring and Defense	Traffic filtering, anomaly detection, and upstream defense are core to DDoS resilience.
Recommendation — Centralise logs and review them for traffic spikes and service degradation. Deploy network monitoring and defensive filtering at the edge and upstream.
ISO/IEC 27001:2022	A.5.29 — Information security during disruption	Major-event DDoS is a disruption scenario requiring continuity-oriented security actions.
	A.5.30 — ICT readiness for business continuity	Event defence needs tested readiness, fallback paths, and recovery coordination.
	A.5.22 — Monitoring, review and change management of supplier services	Coordinated DDoS often crosses third-party transport, cloud, and sponsor dependencies.
Recommendation — Plan security controls that preserve critical services during disruption. Test ICT continuity arrangements before the event and rehearse fallback paths. Track supplier service changes and verify their incident contacts and capacity plans.

Practitioner Guidance

What to prioritise: Build the response around the few services that keep the event functioning, then map every external dependency that can change user behaviour if it fails. If a service feeds public trust or movement, treat it as operationally critical even if it is not venue-owned.

What to verify: Confirm that filtering, rerouting, and escalation can be activated by named people within minutes, and that status messaging has one owner. A playbook that depends on reaching consensus during the attack is too slow.

Decision rule: If the event depends on shared public services, rehearse the failure of those services as part of the tabletop, not as an appendix. The test is whether continuity still works when the first-choice path is unavailable.

Practitioner takeaway: The best DDoS defence for a major event is coordinated resilience, because the real adversary is often the chain reaction between services, not one site under load.