A government service has no competitor. The people using it cannot go elsewhere, and most of them cannot choose another day.
That changes what an attack costs. A retailer that goes down loses orders to a rival; a tax office that goes down on filing day keeps every one of its users, who come back angrier, later, and all at once.
It also changes who has to act. When a public deadline is missed because a service was unreachable, the fix is rarely technical. Someone with legal authority has to extend the deadline, waive the penalties or accept another channel, and they have to decide quickly on the evidence in front of them.
What is DDoS testing for the public sector?
DDoS testing for the public sector is an authorised test of whether citizen-facing government services stay usable under attack at the moments demand is highest, and whether the organisation can prove who was turned away when they do not. It covers central, devolved and local government, agencies and arm's-length bodies.
Engagement mechanics (scoping, traffic sources, ceilings, reporting) are covered once, in the complete guide to DDoS testing. What follows is what government adds to them: fixed dates, public calendars, shared platforms and a duty to serve everyone.
| Pressure | Why government is different | What a test should produce |
|---|---|---|
| Statutory deadlines | the date is in law; only policy can move it | capacity at the projected final-hours peak |
| The fallback | an extension or waiver is a decision, not a failover | a count of who was turned away, fast |
| Hacktivist campaigns | targets follow a public political calendar | test dates and pages chosen from that calendar |
| Shared platforms | many services, one owner, one address space | a signed authorisation for each layer |
| Duty to serve | no one can be told to use a competitor | false blocks for agents, libraries, citizens abroad |
The deadline is written in law
Most commercial peaks are chosen by the business. A government peak is usually chosen by legislation, years in advance, and printed on every letter the service sends.
Penalties concentrate demand
A late-filing penalty works as intended: people file just before it applies. Online tax returns, benefit renewals, licence renewals and registration windows all bunch towards the closing date, and within the final day towards the final evening.
So the hour that matters is predictable to the minute. It is equally predictable to anyone planning to disrupt it.
An hour lost compresses, it does not disappear
When a service is unreachable for part of the final day, the people who could not get through do not abandon the obligation. They try again later the same evening, because the penalty still applies at midnight.
That turns a short outage into a harder peak afterwards. The arithmetic is simple enough to do on the back of a test plan.
Take 200,000 submissions expected on the final day, half of them between 18:00 and midnight. Spread over the whole day that is about 139 a minute. The final six hours run at about 278 a minute. Lose 18:00 to 20:00, and the same 100,000 arrive in four hours: 417 a minute. Lose four hours, and it is 833.
The model assumes nobody gives up and the deadline holds. Both are the default until someone with authority says otherwise.
Two deadline nights that failed without an attacker
On 7 June 2016, the night voter registration closed for the UK's EU referendum, the registration site failed under a late surge of legitimate demand. Parliament approved emergency regulations to keep registration open for two more days. A Commons committee later said it could not rule out outside interference, but the published account of the failure is demand, not attack.
On 17 April 2018, US Tax Day, IRS systems that process electronic returns failed for much of the day. The IRS gave taxpayers an extra day.
Neither was a DDoS. Both show the shape of the recovery: the technical fix restored the service, and a separate decision by people outside the IT team restored the deadline.
What to test
Test at the projected final-hours rate, then at the compressed rate that follows an outage, with attack traffic layered on top. If the service only survives the planned peak, a two-hour incident at 18:00 becomes a second incident at 20:00.
The fallback is a decision, and decisions need evidence
In most sectors the fallback is engineered: a second region, a scrubbing swing, a paper form. In government the decisive fallback is often legal.
Who can move the date
Depending on the service, that might be the revenue authority's leadership, a minister, an electoral authority or a legislature. Each has its own process, and each will ask the same first questions: when did it start, what was affected, and how many people were stopped.
An agency that answers "the site was slow for a while" can expect a slower, narrower decision than one that arrives with numbers.
Requests blocked at the edge never reach your logs
This is where many organisations discover a gap. During an attack, mitigation drops or challenges traffic at the provider's edge. Your application logs show fewer requests, not more refusals.
So the citizens who were turned away are counted, if at all, in the edge provider's logs, the contact centre's call volumes and the people who failed partway through a form. Those three sources sit with three different teams.
Identify the people, not only the count
A blanket extension is one option. A targeted waiver for the people who tried and failed is another, and it needs identifiers: account IDs that started a submission, reference numbers that reached a payment page, signed-in sessions that timed out.
That means logging the start of each attempt, before the expensive step that is most likely to fail under load.
What to test
During a test window, set the operations team a clock. From the moment the test begins, how long until they can hand a decision owner a one-page summary with start time, affected services and an estimate of citizens turned away, drawn from the edge, the application and the contact centre?
If it takes a day to export edge logs from the provider's portal, find that out in the test, not on deadline night. Whether a minister's office or a revenue board can actually decide on that page in an evening is a separate question, and a tabletop exercise is where to find out.
Campaigns follow the political calendar
Most publicly reported DDoS against government is hacktivist. The motive is visibility, and the targets track the news.
Documented campaigns
In April and May 2007, after the relocation of a Soviet war memorial in Tallinn, Estonian government, parliament, bank and news websites were hit by weeks of DDoS. It remains the reference case for a politically timed campaign against a state's online services.
Since 2022 the pro-Russian group NoName057(16) has run a volunteer project, DDoSia, in which supporters run attack software and receive targets, frequently government and municipal sites in countries supporting Ukraine, through Telegram channels. In July 2025 Europol coordinated an international operation against the group's infrastructure. Groups of this kind re-form, so the pattern matters more than any single name.
The target list follows the news
Campaigns of this kind announce themselves around votes on aid or sanctions, summits, elections, budget statements and court rulings. The citizen calendar and the campaign calendar are both public, and some days appear on both.
Volunteer floods aim at pages, not pipes
Volunteer tooling tends to send HTTP requests at specific URLs: home pages, search, login, a form submission. It is rarely large by bandwidth. It hurts when the chosen page is expensive to serve, which is why L7 testing and the cost per endpoint matter more here than raw capacity.
Site search is a common weak point on government sites. It is uncacheable, it is on every page, and on many council and department sites it queries a content system never sized for hostile traffic.
What to test
Mark the dates where a demand peak and a likely campaign trigger meet, and test before each one. Point the test at the pages a campaign would list: the main domain, each department's landing page, site search, and the forms citizens are trying to finish that week.
Shared platforms decide who can sign the test
Government consolidates. Departments publish on shared platforms under one domain, councils buy hosting and content management from the same handful of suppliers, and services share common components for identity, payments and notifications.
You may not own what you want to test
A department's service team can authorise traffic against its own application. It cannot authorise traffic against a cross-government publishing platform, a supplier's shared hosting estate or a national identity service, even when its own service sits on top of them.
A test plan that skips this ends in one of two ways: the test is stopped by a supplier's security team halfway through, or it runs and degrades other organisations that never agreed to it.
Shared components are tested from your side
Shared identity, payment and notification services sit under dozens of services at once, and none of their consumers has the right to load them. The technique for exercising a dependency you may not touch (cut it or slow it artificially, off production) is the one the healthcare post applies to national health services.
The government-specific question is whether there is any second route. If sign-in works only through the shared identity service, the deadline-night plan has to state what a citizen does when it is down, and who announces that.
Test the controls you have on contract
Public bodies buy through frameworks and authorisations, such as G-Cloud in the UK or FedRAMP in the US. A finding that needs a different product may take months of procurement.
So test the mitigation actually on contract, configured as it is today, and find out separately how long it takes to buy emergency capacity under the existing agreement. If the contracted service only diverts traffic once an attack is spotted, the placement trade-offs apply, and the number to compare against is the minutes left before midnight on filing day.
Nobody can be turned away to protect the service
A business can decide that some traffic is not worth serving. A public body mostly cannot. Rate limits and challenges that protect the service by refusing citizens fail the service's own purpose.
Agents submit in bulk from few addresses
Accountants, payroll bureaux and tax agents file on behalf of thousands of clients, usually through software and often from a single office connection. Their peak is the same deadline night as everyone else's.
Per-IP or per-credential limits sized for one citizen will throttle them first. Test with agent-shaped traffic: many submissions under one agent credential, from one address, at the final-hours rate.
Libraries, counters and assisted digital
Public libraries, council offices and job centres give citizens shared computers, and staff at a counter submit applications on citizens' behalf from one office network. That is the legitimate traffic most likely to look like an attack: many different people, one source address, high volume.
Mobile carrier NAT adds the same effect at larger scale, and the mobile backend post covers why per-IP limits misfire behind it. Report a false positive rate for library, counter and agent traffic on its own line, since those are the citizens a blended figure hides.
Accessibility is a legal duty
Public sector websites in the UK are covered by the Public Sector Bodies Accessibility Regulations 2018, and US federal sites by Section 508. A challenge that a screen reader cannot complete is a barrier the body is obliged not to create. The practical failure modes are already listed for patient portals in the healthcare post; for a public body, an inaccessible attack-mode page is also a compliance finding with its own reporting route.
Geo-blocking cuts off citizens abroad
Blocking foreign traffic is a tempting emergency control for a national service. Geo-blocking also blocks citizens living abroad who still file taxes, overseas voters, service personnel posted overseas and anyone travelling on deadline day.
And volunteer attack traffic is spread across many countries, including the target's own, so the block may cut more citizens than attackers. If geo-blocking is in the playbook, test it: measure what share of legitimate traffic it removes on a real peak day, and who owns the decision to switch it on.
The notice has to reach people when the site cannot
When a deadline is extended, citizens learn about it from the government's website. If that website is the thing under attack, the announcement is stuck behind the same flood.
Put the notice somewhere else
Publish incident and extension notices on infrastructure that does not share the attacked service's origin, edge configuration or DNS: a static status page with a different provider, served from a hostname whose DNS does not depend on the main zone. The DNS testing post covers what happens when the authoritative zone itself is targeted.
What to test
During a test against the main service, update the status page and check it from outside networks. Time how long it takes for a notice to reach the public, and confirm the contact centre's recorded message points to the same place.
Systems a government test leaves alone
One body's signature covers that body. A few systems stay excluded even when every signature is in place.
The exclusion list
- emergency call handling and dispatch systems
- election management, counting and results systems, and anything run by an electoral authority
- shared cross-government platforms and components, unless their owner signs the test
- other public bodies' services, including neighbours on the same hosting supplier
- live citizen accounts
Timing, reports and frameworks
Keep tests away from filing windows, election periods and announced political events. Ceilings, abort criteria and live monitoring are written up in the post on testing without disrupting production, and nothing about them changes for government.
What does change is who may read the result. Freedom-of-information law can reach a test report; security exemptions exist, but draft it on the assumption that a requester will ask.
Results showing who was refused, and how quickly the organisation could prove it, also make good evidence for NIS2 (which names public administration as a sector), the UK's GovAssure scheme for central government departments and FISMA for US federal agencies. The UK DDoS testing post goes further into the UK picture. Treat this paragraph as orientation only and confirm the obligations with your own compliance and legal teams.
A public sector DDoS testing checklist
- List every statutory deadline and renewal window the service carries, with its projected final-hours rate.
- Test at the planned peak and at the compressed peak that follows a two-hour outage.
- Mark the dates where a demand peak meets a likely campaign trigger, and test before each.
- Point L7 tests at search, landing pages and the forms citizens must finish that week.
- Get written authorisation from every layer: service, shared platform, hosting supplier, upstream provider.
- Simulate shared identity, payment and notification failures from your side only.
- Test agent-shaped, library-shaped and carrier-NAT-shaped traffic against the rate limits.
- Measure what geo-blocking would remove on a real peak day before it goes in a playbook.
- Time how long it takes to produce a turned-away count from edge, application and contact centre.
- Confirm the status page survives a flood on the main service and on its DNS.
FAQ
Why are government websites a hacktivist favourite?
A ministry offline is a headline, and the campaign wants the headline. Volunteer-run projects such as NoName057(16)'s DDoSia have repeatedly listed government and municipal sites, timed to votes, summits and elections. An afternoon's outage costs the campaign almost nothing and gets reported widely.
Can a council or department test a shared government platform?
Not on its own authority. A service team can authorise traffic against its own application, but a shared platform, hosting estate or identity service needs written agreement from its owner. Without it, test your own service's behaviour when that component is slow or unavailable, in a test environment.
How far ahead of a filing deadline is the right time to test?
Far enough to fix what the test finds, which for anything needing procurement means months. Test ahead of the highest-demand dates, such as a filing deadline or renewal window, and ahead of political events likely to attract campaigns. Never during a filing window, an election period or an announced event.
Is blocking foreign traffic a sensible emergency control for a national service?
Only after measuring what it costs. Citizens abroad, overseas voters and service personnel need access too, and volunteer attack traffic often comes from many countries, including the target's own. Test the share of legitimate peak traffic a geo-block would remove, and agree who decides to switch it on.
Which numbers belong in a government test report?
Completed submissions at the deadline peak and at the compressed peak after an outage; false blocks for agents, shared-address users and citizens abroad; and the minutes it took to hand the decision owner a count of people refused. An availability percentage tells the decision owner almost nothing they can act on.
In government, the date is the service
Most availability work treats time as the background against which a service runs. In government the timing is part of what is being provided: a return filed by midnight, a registration made before the roll closes, a renewal in before the benefit lapses.
An attack can be beaten technically and the citizen still loses, if the hour they needed went with it.
So the most useful result a government test produces is not a graph of a flood absorbed. It is a page, ready by nine in the evening, telling someone with the authority to move midnight exactly whom midnight would have punished.