Most DDoS mitigation proposals that reach a finance director arrive as a vendor deck with a threat-landscape slide, a logo wall and a monthly figure, and most of them come back with a question the IT lead cannot answer: what exactly are we buying down, and what is it worth? A strong DDoS protection business case answers that in numbers finance already recognises, not in attack statistics. It is a short paper about availability risk, priced across three surfaces, with assumptions written down so they can be argued with. This piece is the paper, not the pitch.
What a DDoS protection business case actually has to prove
Finance will ask three things, in this order: how likely is it, what does an hour of unavailability cost us, and why this line item rather than a cheaper one. Answer those and the conversation becomes a budgeting exercise. Lead with distributed denial-of-service (DDoS) attack volumes from a vendor report and it becomes a debate about whether vendors exaggerate.
“We might get attacked”fails review because it offers no decision. “Our exposure is between X and Y per hour, we have three options at three price points, and here is what each one does to our time-to-mitigate”passes, because a board can choose between options. It cannot choose between fear and no fear.
Frame the spend where it belongs. This is not a new security purchase competing with endpoint licences; it sits beside the money already approved for backups, failover, standby capacity and the availability clauses in the cyber policy. Organisations routinely pay for a second data centre they hope never to use. Scrubbing capacity is the same category of insurance, bought by the month.
One practical point that gets papers signed: co-signatures. The revenue owner (commercial or ecommerce director), the service desk lead who absorbs the call volume during an outage, and whoever holds the customer-facing service level agreements (SLAs) should all be named on the front page. A paper from IT alone reads as IT wanting a toy. A paper co-signed by the person who pays the SLA credits reads as risk management.
Costing downtime with numbers finance already owns
Start with revenue per trading hour, because that number exists in a system somebody already trusts. Annual online revenue divided by trading hours gives the baseline. For a 24/7 store, that is 8,760 hours.
Nobody should present that baseline on its own, because an average hour is a fiction. Trade concentrates, so a Black Friday or peak-campaign hour will carry a multiple of the average, and your own trading data should set that multiplier rather than a rule of thumb. Then adjust downwards for recovery: some customers come back an hour later, some do not. Apply a recovery assumption you can defend, and state it, so the net revenue loss in a peak hour is visibly lower than the gross figure.
Expect the challenge that the real loss is gross margin, not revenue. It is a fair challenge, and conceding it early buys credibility. The answer is that margin is only part of the number, because the following costs are cash out of the door regardless:
- SLA credits payable to your own customers, which for SaaS and hosting can exceed the revenue lost during the outage itself;
- Overtime, out-of-hours engineering and any third-party incident response retained at emergency rates;
- Contractual penalties and service credits in managed-service or public-sector contracts;
- Paid acquisition still running against a dead landing page;
- A sales pipeline frozen while demo environments, quoting tools or portals are unreachable.
Non-revenue organisations can run the same model with different inputs: staff hours lost multiplied by fully loaded cost, appointments or cases rescheduled, and the effort of regulatory notification if the outage is reportable. Operators in scope of the NIS Regulations 2018 and financial entities subject to the EU’s Digital Operational Resilience Act should cost the reporting work honestly, because it is real staff time.
Build the result as low, likely and high columns, with every assumption printed next to it. A single confident number invites someone to disbelieve the whole paper. A range with visible assumptions invites someone to adjust one of them, which means they are now inside the model with you.
Scoping spend across network, application and DNS
Price three surfaces separately, because attackers choose between them.
Network and transport volumetrics. UDP reflection, amplification and raw floods aimed at saturating your transit. Handled by upstream scrubbing, BGP diversion or filtering at the hosting or transit layer.
Application layer. HTTP and HTTPS request floods against search, login, checkout and API endpoints. These need far less bandwidth to hurt, and they bypass anything that only counts packets per second. A reverse proxy with rate-limiting and challenge logic is the usual control.
Authoritative DNS. The layer most often missing from both the architecture and the budget. A business case that funds network scrubbing and a proxy but leaves authoritative DNS on a single unmanaged nameserver has paid to defend two doors and left the third wide open. If resolution fails, the proxy never gets asked for anything. Price anycast, multi-provider or managed authoritative DNS as a named line in the paper, not as an afterthought for the hosting team.
A business case built on bandwidth alone leaves the cheapest attack path open. The single most useful slide in the paper is a three-column table: surface, current control, residual gap. Most readers will spot the empty cell without being told.
Budget for addressing work, too. Proxy bypass is usually an addressing problem rather than a capacity problem. Old A records, mail headers, certificate transparency logs, status pages and forgotten staging hosts leak origin IP addresses, and an attacker who finds one simply routes around the proxy. Funding a subscription without funding origin lockdown, firewall allow-lists restricted to the provider’s ranges, and in many cases re-addressing, buys a control that can be stepped over. Scope the engineering hours for that in the same paper, and work through how each attack type maps to the mitigation options that genuinely address it before you fix the architecture in a quote.
Always-on or on-demand: what the premium buys
The dividing line is simple. Always-on means traffic already passes through mitigation, so filtering starts in seconds. On-demand means detection, human or automated decision, diversion, and then route or DNS propagation, all of which happen after the attack has begun.
The always-on premium is a payment for minutes. Convert it. Take your likely hourly downtime figure, estimate realistic minutes of degraded or lost service per incident under on-demand (ask the provider for their measured detection-to-clean times, in writing, and then add your own change-approval delay), multiply, and multiply again by expected incidents per year. Twenty minutes of exposure costs a third of your peak-hour figure per incident, and three incidents a year puts the comparison in the same shape as the annual premium. That is a calculation a finance director can audit; a preference is not.
On-demand genuinely fits in some estates: little or no attack history, latency-sensitive traffic where an extra proxy hop is unacceptable, or a secondary estate with a longer agreed recovery window. Do not let a vendor shame you out of it.
Hybrid patterns are worth pricing as a fourth option. Always-on at the application layer and authoritative DNS, where attacks ramp fastest and volumes are small, with on-demand BGP scrubbing held in reserve for network-layer events. State the saving and the extra minutes of exposure it creates in the same sentence. Boards trust papers that cost their own compromises.
How UK managed DDoS pricing is structured
Quotes for managed DDoS protection in the UK are usually assembled from the same building blocks, and knowing them lets you compare two proposals that look nothing alike:
- A monthly platform or subscription fee, sometimes tiered by protected asset count;
- A clean-bandwidth commitment (Mbps or Gbps of legitimate traffic) or a request allowance for proxied services;
- Per-protected-IP or per-/24 prefix charges for BGP-based cover;
- Overage on burst, which is where surprise invoices come from;
- One-off onboarding, rule tuning and testing fees;
- Term discounts for 24 or 36 months, usually with a lock on moving providers.
Published figures move, so treat any number you are quoted as current only on the day you receive it, and ask for the overage mechanism in writing. There is a fuller breakdown of how UK DDoS protection costs are actually assembled if you need to sanity-check a quote line by line.
“Managed”is a contract term, not a service level. The paper should say in plain words who tunes policy, who is paged, who holds authority to change mitigation mid-incident without your sign-off, and what happens at 03:00 on a Sunday. If nobody on the provider’s side can change policy without waking your change manager, you have bought monitoring, not management. That distinction, not the headline capacity figure, is where two similarly priced quotes diverge.
Trace the resale chain before signing. A large share of the market resells someone else’s network and scrubbing capacity, which matters for three reasons: the board learns whose platform it is actually buying, you learn who holds the SLA when the upstream provider has an incident, and you can ask whether the capacity figure in the proposal is the reseller’s allocation or the upstream total. The same question applies to cover bundled by your access provider, and what ISP-level DDoS protection in the UK does and does not include is worth reading before you assume it is already handled.
Finish with total cost of ownership rather than the subscription: internal engineering hours for onboarding and re-addressing, DNS migration, test windows, and any change to hosting or transit contracts triggered by the new architecture.
The evidence to attach before the board signs
Judge providers on material you can check. Ask for the SLA document itself, with remedies and the measurement method for time-to-mitigate, not a marketing summary of it. Ask how capacity is measured and across how many scrubbing locations, since headline terabit numbers are frequently global aggregates rather than anything available to you in region; the practice of reading Tbps claims critically belongs in the procurement pack.
Request a redacted post-incident attack report and the onboarding and escalation runbook during procurement, not after contract signature. A provider who cannot produce a readable vector breakdown for a past incident is unlikely to produce one for yours.
Plan the proof as part of the paper: a scheduled test or simulation window in the first quarter of the term, a tabletop exercise involving the service desk and the communications lead, and agreed success measures for the first review. Boards approve pilots more readily than purchases.
Address the extortion scenario directly. A DDoS extortion ransom demand, typically an email naming a deadline and a cryptocurrency wallet, sometimes with a short demonstration attack, is not a pricing problem. Paying is not a control: it buys no capacity, no filtering and no assurance, and the National Cyber Security Centre does not encourage payment of ransom demands. Both the attacks and the demands are criminal matters in the UK under the Computer Misuse Act 1990, and the paper should name the escalation path: provider hotline first, then Action Fraud and law enforcement, with the communications line pre-agreed. The NCSC’s warnings about hacktivist DDoS activity against UK organisations are useful supporting evidence for the likelihood question, because they come from a government body rather than a sales team.
A good DDoS protection business case is short, numerate and honest about what it does not know. Hourly exposure as a range, three surfaces priced separately, the always-on premium expressed in minutes and money, the contract terms that define “managed”, and an evidence pack a non-technical reader can audit. If you want to pressure-test the architecture side before you write the figures, read up next on how colocation and hosting-level filtering fit the same three surfaces.
Frequently Asked Questions
How do you calculate the cost of downtime for a DDoS protection business case?
Divide annual revenue for the affected service by its trading hours to get a baseline hourly figure, then apply a multiplier for peak trading weeks and subtract an assumed recovery rate for orders that return later. Add costs that sit outside revenue: SLA credits to your customers, out-of-hours engineering, incident response at emergency rates and contractual penalties. Present low, likely and high columns with the assumptions printed alongside, so reviewers can adjust an input rather than reject the model.
What does managed DDoS protection typically cost in the UK, and how is the pricing structured?
Prices vary too widely by estate size and deployment model to quote a meaningful single figure, and any quote should be treated as current only on the day it is issued. The structure is more consistent: a monthly platform fee, a clean-bandwidth or request commitment, per-IP or per-prefix charges, overage on burst, one-off onboarding and tuning fees, and discounts for longer terms. Ask specifically how overage is calculated, because that is the line that produces unexpected invoices.
Is always-on mitigation worth the extra cost compared with on-demand scrubbing?
It depends on what minutes cost you. Always-on filters from the first packet; on-demand adds detection, diversion and propagation time after the attack starts. Multiply your likely hourly downtime figure by realistic minutes lost per incident and by expected incidents per year, then compare that with the annual premium. Low attack history, latency-sensitive traffic or a secondary estate with a longer recovery window can all justify on-demand.
What evidence should a board ask a DDoS mitigation provider for before signing?
The SLA document with remedies and the measurement method for time-to-mitigate, a redacted post-incident attack report, the onboarding and escalation runbook, written confirmation of whose network and scrubbing capacity sits behind the service, and an agreed test window in the first quarter of the term. Ask whether quoted capacity is the provider’s own or an allocation from an upstream platform. Sales decks are not evidence.
Does cyber insurance remove the need for a DDoS protection business case?
No. Policies may reimburse some business interruption after the fact, subject to waiting periods, deductibles and proof of loss, but they do not keep the service up, and insurers increasingly ask what availability controls are in place. The business case and the policy answer different questions: one reduces the chance and length of an outage, the other partially compensates for one.