The Decision, the Evidence and the Answer: DDoS Readiness for a Knowledge Economy

Qatar’s national development vision is built on human and institutional development as much as on infrastructure — the transition toward a knowledge-based economy in which the capability that matters sits in people and organisations rather than in a resource. That framing is stated consistently and this guide needs nothing more specific from it.

Applied to a single, narrow operational question — what happens when a serious denial-of-service attack lands on a nationally significant service — it produces a checklist most organisations have never run. Not a technical checklist. Three questions about where things are.

The three things that have to be in the country

The decision. At some point during a large attack, someone has to choose. Divert or hold. Shed one service to protect the rest, or accept degradation across the board. Terminate TLS at the mitigation tier so the application layer can be classified, or leave a class of attack undetectable. Every one of those is a business decision wearing technical clothes, and every one has to be made while the attack is running by someone who is awake, reachable and authorised.

The evidence. Afterwards — and it is always afterwards, usually weeks — someone asks what happened. To which service, between which times, caused by the attack or by the response, observed how. Answering requires a record with enough detail to address a question nobody anticipated at the time, held long enough to still exist when it is asked for.

The answer. Someone stands in front of a regulator, a board, a customer or a public and accounts for it. That is not a technical artefact. It is an organisational position, and it belongs to the organisation whose name is on the service.

Three things. The third cannot be transferred to anyone, under any commercial arrangement. The first two can be, easily, and are — often without the decision to transfer them ever being made explicitly.

What an offshore default actually relocates

This is where the architecture question and the readiness question turn out to be the same question.

If everyday traffic is inspected in another country by another organisation, then during an attack the observation happens there, the first-order decisions about classification and thresholds happen there, and the detailed record accumulates there. Your team is notified. It receives a graph, an alert, later a summary. It makes the decisions that remain — whether to accept the impact, what to tell customers — but it makes them on information that has already been reduced by someone else, about traffic it did not watch.

Then, weeks later, the questions arrive and land entirely on you. You hold the accountability without having held the observation.

This is not an argument that providers are unreliable. Large scrubbing providers are competent, see far more attacks than any single organisation, and generally supply what is asked for. It is an argument about a structural mismatch: the party that must answer is not the party that observed, and the gap between them is a support queue.

The decision is the part nobody rehearses

Of the three, the decision is where organisations are weakest, and it is the cheapest to fix.

Almost every organisation with a mitigation capability has a technical runbook. Very few have settled, in writing, who may decide at three in the morning to take one service off the air to protect the others. The result is one of two failures, both of which are the policy’s fault rather than the engineer’s: hesitation while the incident develops, or an unauthorised decision made under pressure that becomes contentious afterwards.

Rehearsing this costs an afternoon and needs no equipment. Take a scenario in which a sacrifice is required and run it against the people:

• Who believes they may make the call? Ask three people separately and compare the answers.
• Who must be informed, and within what period? How long does it actually take to reach them?
• What is the time limit on the decision, and who revisits it?
• What gets written down, by whom, while it is happening?

Most organisations find the technical answers are fine and the authority question has never been settled. That is the finding, and it is worth the afternoon.

Evidence is a by-product, not a product

The second question has a cleaner answer, because evidence custody follows inspection custody mechanically. You can only capture what passes through equipment you operate.

Where the inspection point is local, producing an incident record is a query against your own storage, on a retention period your compliance function chose, with original source addresses and local timestamps intact. You can pull a full capture without asking permission, at the moment the question is asked rather than several days later, and you can answer a follow-up question that requires detail nobody thought to summarise.

Where inspection is offshore, each of those becomes a request. Within their retention window, which is a term in a contract rather than a decision you made. In their format. On their support model’s timescale, while your reviewer waits.

An organisation can bridge this by keeping a local tap purely for evidence while inspecting elsewhere — and occasionally that is the right design. More often it is a sign that the architecture was chosen before anyone asked what the evidence obligation would be, and the organisation is now paying for two inspection points to satisfy one requirement.

Two structural notes about the market

This guide’s companion piece argues that in a market where international capacity arrives through few physical systems, the local tier has to carry more load than a continental template assumes. That is a structural argument about paths. The argument here is about institutions, and the two support each other without repeating: the first says the offshore tier is less dependable here than the diagram implies, the second says that even when it works perfectly, it takes the decision and the record with it.

The classification analysis is a third, separate lens, and for many organisations it will be the binding one — see the classification guide for why the class of the data can rule out an architecture before any of this is weighed.

What the equipment has to support

Three properties, and they are testable in a proof of concept rather than assessable from a datasheet.

A record granular enough to answer an unanticipated question. Aggregate counters prove the device is working and cannot reconstruct an incident. Ask the vendor to produce, for one named service and one named hour, what was detected, what was dropped and what was forwarded — and to show the query rather than a screenshot.

Retention under your control. Whether the period is yours to set, whether export is a supported operation, and what the storage cost of a realistic retention period actually is. This is frequently the item that changes a design after it has been chosen.

Detection that does not depend on reachability of something outside the country. During a national-scale event the international path is one of the things that may be degraded, and a mitigation tier whose classification quality depends on reaching a manufacturer-operated service has placed a dependency outside the border inside a duty that sits inside it. An appliance that runs detection on the customer’s own infrastructure makes a degraded border a capacity problem rather than a detection problem, and manufacturers differ on this point — it is a question for the tender, not an assumption. Products that do consult an external service should be assessed on how far they degrade and against which attack classes, not on whether they degrade — most degrade gracefully, and the honest question is how gracefully, for how long.

Appliance	The decision	The evidence	The answer
What it is	Authority to act while the attack is running	The packet-level record of what occurred	Accountability to the regulator, board or public
Offshore inspection	Held by a provider's operations centre	Held by a provider, in their retention window	Still yours
In-country inspection	Held by your team, on your escalation path	Held by you, on your retention policy	Still yours
What determines the timescale	Provider's runbook and change window	Provider's support queue	The reviewer's calendar, either way
Can it be outsourced	Yes, and often sensibly	Yes, at a cost in latency and detail	No
What happens if the relationship ends	Reverts to you, unrehearsed	Reverts to whatever you exported	Unchanged — it was never theirs

Read the last two rows together. The only column that cannot be transferred is the one whose inputs are the easiest to transfer, which is what makes this an architecture question rather than a governance one.

The honest limit

Capacity is not affected by any of this. An attack larger than your access circuit has already succeeded before your equipment sees a packet, and no amount of local readiness changes that arithmetic. The upstream tier remains necessary; what this guide argues is that it should be an exception with a rehearsed procedure rather than the default path, so that the decision and the record live locally on ordinary days as well as extraordinary ones.

And a small organisation with no security operations function should be honest about which of the three columns it can actually hold. An organisation that will not staff, train or rehearse is better served by a competent provider than by equipment nobody operates — and the useful version of this guide, for that organisation, is the list of questions to ask the provider about evidence custody and response authority before signing.

Sources and further reading

The national vision’s objectives are published by the state and are the right primary source for any policy framing; nothing here depends on a specific target, timeline or figure. For the regional threat picture that motivates the exercise, see the Middle East threat landscape guide. For the state-level version of the capability question, see sovereign cyber defence in the Gulf.