DDoS Protection and the NCA Essential Cybersecurity Controls: An Architecture and Evidence Guide

Most organisations in scope of Saudi Arabia’s Essential Cybersecurity Controls approach DDoS protection as a procurement item: a line in the security budget, resolved by comparing throughput figures and monthly prices. Then an assessment arrives, and the question is not which product was bought but something the datasheet never addressed — show us the design, show us who approved it, show us that it works, and show us where our users’ traffic is inspected.

That gap is the subject of this guide. The ECC is not a shopping list, and reading it looking for the word “DDoS” teaches you almost nothing. Reading it for the outcomes that a denial-of-service event destroys, on the other hand, finds the topic almost everywhere: in availability, in network security, in logging and monitoring, in incident management, in resilience and continuity, and — the moment you outsource any of it — in the third-party and cloud computing theme as well.

What follows maps those themes onto the three DDoS architectures, sets out the data residency question the PDPL raises when scrubbing happens abroad, and ends with the evidence pack an assessor will actually ask to see.

What the ECC asks of any control

Before mapping anything, it is worth being precise about what kind of document the ECC is, because it determines the shape of every answer you will give.

The National Cybersecurity Authority publishes the Essential Cybersecurity Controls as a national minimum baseline. Its scope reaches government organisations and their subsidiaries, and private-sector organisations that own, operate or host critical national infrastructure; the authority presents it as a floor that other organisations are encouraged to adopt, not a ceiling. It sits alongside further control sets the authority has issued for narrower purposes — notably controls for critical systems and for cloud computing — and it does not displace obligations that arrive from other regulators.

The controls are grouped into main domains covering governance, cybersecurity defence, resilience, third-party and cloud computing, and industrial control systems. Within them, the same demand recurs with almost mechanical regularity: a measure must be defined, documented and approved; it must be implemented; and it must be reviewed periodically. That triple is the single most useful thing to internalise before a DDoS architecture discussion, because it tells you that the assessor’s questions will not be about capability. They will be about artefacts.

A perfectly configured mitigation device that nobody approved, whose thresholds live only in an engineer’s head and which has never been tested against a scenario, is a technically excellent control and an evidentially empty one. Conversely, a modest capability with an approved design, a documented threshold policy, monitored alerting and an annual exercise record passes comfortably. The framework rewards demonstrability, and demonstrability is an architectural property as much as a paperwork one — some designs generate their own evidence, and some designs require you to request it from a third party.

Where a denial-of-service event lands in the control set

A flood is unusual among security incidents in how many control themes it touches at once. It is worth walking through them, because each one implies a different artefact.

Availability as a protected property. Security frameworks are often read as confidentiality documents, but the ECC treats the availability of systems and services as a protected objective in its own right. A denial-of-service event is the purest possible attack on that objective: nothing is stolen, nothing is altered, and the control fails completely. This matters for scoping — you cannot argue a DDoS control out of relevance on the grounds that no data was exposed.

Networks security management. The defence domain expects network protection to be designed, segmented, configured according to approved policy and reviewed. A mitigation tier is a network security component, so it inherits the whole pattern: an approved topology showing where it sits, a documented policy for what it drops, change control over that policy, and a review cycle.

Event logs and monitoring. Controls in this area expect security events to be logged, retained and actively monitored rather than merely collected. A DDoS control that silently absorbs traffic and produces no reviewed alerting satisfies the engineering objective while failing the control objective. Note the second-order effect too: a flood that reaches your estate generates log volume on every device that sees it, which is one of the quieter ways a volumetric attack degrades a monitoring capability you have already paid for.

Incident and threat management. You need a defined classification for a denial-of-service event, a defined escalation path, a defined reporting route to the authority in the form it specifies, and a record of what actually happened when one occurred. The last item is where architecture starts to bite: your ability to reconstruct an incident depends on what your equipment captured and what your provider is contractually willing to hand over.

Resilience and business continuity. The resilience domain expects cybersecurity requirements to be part of business continuity management — not a separate exercise. A DDoS scenario is one of the few threats that maps cleanly onto continuity planning, because the impact is exactly the impact continuity planning already models: the service is unavailable. This is where a recovery objective for a public-facing service and a mitigation design should be shown to agree with one another.

Vulnerability management, penetration testing and web application security. Application-layer floods exploit the gap between what a service accepts and what it can afford to process. A login endpoint that performs an expensive cryptographic operation on every request, a search endpoint with an unbounded result set, an API without rate limiting — each is a resource asymmetry, and each is discoverable by the testing regime the framework already expects you to run.

Third-party and cloud computing cybersecurity. The moment any part of the mitigation tier is a service rather than a device, this theme applies in full: selection, contractual security requirements, assurance over the provider, and clarity on what remains your responsibility.

Look at the top row of that diagram carefully. In a cloud-only design, it is not just attack traffic that is inspected abroad. It is every legitimate session, every day, attack or no attack. That is not a flaw in cloud scrubbing — it is a structural property of it, and it is the property that turns an architecture question into a data protection question.

What a scrubbing tier must process to do its job

The marketing formulation is “we clean the bad traffic”. That sentence conceals the mechanism. To separate an attacker from a customer, a mitigation tier has to inspect traffic, and inspection is data processing. There is no filtering technology that works without looking.

At minimum, a scrubbing tier processes:

• Source IP addresses, for every packet. An address on its own may look like network metadata; combined with access logs, session records or account activity, it is capable of pointing at an identifiable individual, which is exactly the test a broad personal data definition applies.
• Request headers and user agent strings. Language preference, referrer, client hints. The combination is rich enough to function as a device fingerprint, which is why bot detection uses it.
• Session cookies and tokens, wherever application-layer protection is in play. Without them there is no way to distinguish a signed-in customer from a browser-emulating bot.
• Request bodies, wherever the provider terminates TLS — which is a precondition for meaningful HTTP flood protection. That means form submissions and API payloads pass through the provider’s systems in the clear.

The consequence is uncomfortable but unavoidable: “we use cloud scrubbing but no personal data is processed” is not a position you can hold. The only genuine variables are which categories are processed, where, by which legal entity, and for how long.

The PDPL question this creates

Saudi Arabia’s Personal Data Protection Law, supervised by the Saudi Data and Artificial Intelligence Authority, is the second half of this decision, and compliance leads should be clear that it raises three distinct issues that are easy to conflate.

First, whether personal data is being processed at all. The law works from a broad notion of data that identifies an individual directly or indirectly. Applying that test to the four categories above is an assessment you must actually make and record rather than assume away; in a scrubbing context, source addresses tied to session identifiers and request content make the identifiability argument difficult to avoid.

Second, transfer outside the Kingdom. Where inspection happens abroad, personal data leaves the Kingdom. For a group with entities in more than one Gulf state, the conditions to be satisfied are set out state by state in the regional residency guide. The framework does not prohibit that: it conditions it, and SDAIA has issued implementing instruments dealing specifically with transferring personal data outside the Kingdom. Obtain those instruments and read the conditions they impose rather than relying on a summary — including a vendor’s summary. The practical point for an architecture decision is that a lawful transfer is available, and it is work: a documented basis, an assessment, contractual instruments and a position you can defend twice — once to the data protection supervisor and once to the cybersecurity assessor, who will ask a related but differently framed question.

Third, processor and sub-processor governance. A scrubbing provider processes on your behalf, which means written terms covering purpose, categories, retention and security. The clause most often skipped is sub-processing. Global providers frequently lease points of presence from third-party data centre operators and use third-party services for parts of the delivery path, so the country list you were shown at the sales stage may not be the full set of entities that touch your traffic.

Two further practical notes. The law’s reach extends to processing of the personal data of individuals in the Kingdom even where the processing entity sits outside it, so a foreign provider is not automatically beyond the regime — but that is a statement about the provider’s exposure, not a substitute for your own compliance position as the controller. And the answer “we do not store anything, we only pass traffic through” does not close the question: processing is broader than storage, and in practice retention is rarely zero, because attack telemetry, sampled packets and event records are precisely what the provider’s incident reports are built from. The right question is never “do you store it” but what, for how long, and in which country.

Why in-country inspection is easier to evidence

The sovereignty argument for keeping inspection in the Kingdom is usually made in political or contractual terms. The more persuasive version, for a compliance lead preparing for an assessment, is operational: an in-country, self-operated tier generates its own evidence, whereas an outsourced tier requires you to request evidence from someone whose commercial interest is in producing less of it.

Compare the artefacts you will be asked for.

Design and approval. For equipment you own, the topology diagram, the placement decision and the sign-off are internal documents you can produce on demand and update under your own change control. For a scrubbing service, the equivalent artefact describes a network you have not seen, whose topology changes without notifying you and whose configuration you cannot fully inspect.

Policy and thresholds. Your own device holds an exportable configuration with a change history mapping to change tickets. A provider’s detection policy is usually a portal with a narrower set of controls and no equivalent export.

Monitoring and alerting. Locally generated logs flow into your own monitoring platform at the fidelity you choose. Provider-side telemetry arrives at whatever granularity and cadence the service tier provides, and often summarised.

Retention. You set your own retention period to match your regulatory position. With a provider you inherit theirs, and it is frequently shorter than the window in which an investigation, dispute or regulatory query actually lands.

Incident reconstruction. After a significant event, the assessor’s question is what happened, minute by minute. Full packet capture from your own equipment answers it directly. A provider-supplied report answers it at the provider’s chosen resolution, in the provider’s format, on the provider’s timetable.

Log chain integrity. This one is subtle and it matters. When traffic is diverted through a scrubbing tier, what reaches your servers has passed through the provider’s network. Depending on how client addresses are conveyed, your own access logs may record the mitigation path rather than the original source, or may depend on a forwarded-header convention that must itself be trusted and documented. Any logging obligation that assumes an unbroken, locally timestamped record of who connected to your service is easier to satisfy when nothing sits in front of you.

Testing. Perhaps the most underrated difference. You can schedule a test of your own appliance for a Thursday night in the assessment run-up. A diversion test with an upstream provider is a joint change requiring their agreement, their window and their engineers — which is why so many organisations that “have hybrid” have never actually exercised the handover.

None of this makes outsourced mitigation non-compliant. It makes the evidence pack longer, the dependencies external, and the review cycle slower.

The honest limit of an on-premise tier

An article that stopped there would be selling something. The constraint has to be stated plainly: an on-premise appliance cannot filter traffic that has already saturated the circuit delivering it.

If your access circuit is 10 Gbps and 40 Gbps arrives, the circuit is full before the appliance is consulted. Whether the appliance is rated for 20 Gbps or 200 Gbps is irrelevant above that line, because the bottleneck sits upstream of it. Any vendor conversation that avoids this point should be treated as a warning sign.

So “we will buy an appliance for residency reasons and skip the upstream tier” is only correct for organisations whose exposure is genuinely not volumetric: internal services, segments behind an already protected perimeter, environments where the threat model is application abuse rather than bandwidth exhaustion. Any public-facing service of consequence will eventually meet an attack larger than its circuit, and rented flood capacity is neither scarce nor expensive.

The design that satisfies both constraints is on-premise-first hybrid: everyday traffic — all of it, attack or no attack — is inspected in country on equipment you control, and an upstream tier engages only above the circuit line, under conditions written into the contract and the runbook. Cross-border processing then stops being a permanent state of affairs and becomes an exceptional, bounded, documentable event, which is a far easier thing to describe in a transfer position and in a privacy notice. Appliances built for full L3–L7 coverage in a single in-line device fit that shape directly, because they keep the everyday inspection, and therefore the everyday evidence, inside one jurisdiction.

One trap to avoid: a privacy notice or transfer assessment that says “no data is transferred abroad” is simply inaccurate in a hybrid design. State the conditions under which diversion occurs and what is processed while it lasts. An accurate exceptional-transfer description survives scrutiny; an absolute claim contradicted by a runbook does not.

Appliance	Cloud scrubbing only	On-premise only	On-premise-first hybrid
Where everyday traffic is inspected	Provider points of presence, wherever they sit	Your facility, on hardware you own	Your facility by default; upstream only during diversion
Cross-border transfer question	Arises continuously, for all users	Does not arise	Arises only for defined diversion windows
Packet-level evidence after an incident	Provider summaries, within their retention window	Your own capture, your own retention policy	Local by default; provider's for the diverted period
Access-log chain during an attack	Source addresses reach you via the provider path	Unbroken and locally timestamped	Unbroken except during diversion
Capacity ceiling	Provider backbone	Your access circuit	Circuit locally, backbone above it
Third-party assurance burden	Full — provider, sub-processors, PoP locations	Limited to the hardware supply chain	Scoped to the diversion service
Continuity exercise you can schedule yourself	Only what the provider will agree to run	Fully self-scheduled	Local tests self-scheduled; diversion drill joint

Rows describe architecture classes, not specific products. The two rows that decide most regulated purchases are the first and the last — where inspection happens, and whether you can rehearse the control without asking permission.

The audit-facing checklist

This is the pack to assemble before an assessment, and equally the pack to build backwards from when designing. Each item corresponds to something an assessor can ask for and you can hand over.

1. An approved architecture document showing where DDoS inspection occurs, on whose equipment, in which country, and how traffic reaches it — with a dated approval by whoever owns that decision in your governance structure.
2. A written mitigation policy: what is dropped, what is rate-limited, what is challenged, which thresholds apply to which services, and who may change them. Configuration alone is not a policy.
3. Change control records covering threshold and rule changes, tied to your standard change process rather than to an engineer’s discretion.
4. Monitoring evidence: sample alerts, the destination they route to, the roster that responds, and proof that alerts were acted upon rather than merely raised.
5. A retention statement covering mitigation logs, telemetry and any packet capture — the period, the storage location, and the access control over it.
6. At least one exercised test with a scenario, date, participants, result and remediation actions. For hybrid designs this must include a diversion and, critically, a fail-back.
7. Incident classification and reporting procedure for denial-of-service events, including the route by which a significant incident is reported to the authority in the form it specifies, with defined ownership.
8. Continuity linkage: the recovery objective for each public-facing service, and a demonstration that the mitigation design is consistent with it rather than a separate document.
9. The third-party file, if any tier is outsourced: due diligence record, contractual security requirements, current assurance reports, sub-processor list, and the notification obligation when it changes.
10. A data-flow and transfer position naming the personal data categories processed by each tier, the country of processing, the legal entity involved, and the transfer basis where processing occurs outside the Kingdom.
11. Application-layer hardening evidence: rate limits, resource-asymmetry findings from testing, and their remediation status — this connects the DDoS control to the vulnerability management and application security expectations rather than leaving it isolated in the network domain.
12. Periodic review record for all of the above, because the review cycle is itself a control and its absence is the most common finding against otherwise sound implementations.

Clauses to put in the tender

If any tier is bought as a service, the following belong in the requirements document rather than in a conversation. A presentation slide is not an artefact.

The countries of the scrubbing centres that will handle your prefixes — not the provider’s global footprint, but the specific facilities your traffic will be steered to, in the contract, with a notification obligation on change.

Whether TLS is terminated, where, and by which legal entity, along with key custody. If it is terminated, request bodies are processed, and your transfer position must say so.

Data categories and retention, itemised — attack telemetry, sampled packets, event records and reporting data separately, each with a period and a country.

The sub-processor list, the data centre operators behind the points of presence, and the change notification mechanism.

Evidence rights: what logs, captures and reports you may obtain after an incident, in what format, within what time, and at what cost. Silence here is the single most common reason an organisation cannot reconstruct its own incident.

Diversion and fail-back terms for hybrid designs: the trigger thresholds, who may invoke them, the out-of-band channel for invoking them when your circuit is saturated, the maximum duration, and the conditions for returning to normal. This is simultaneously an operational requirement and the technical definition of your exceptional-transfer window.

Testing rights: your entitlement to schedule a diversion exercise, the notice period, and the frequency. Without it, the exercised-test evidence item above is not within your control.

A decision framework

Two axes, taken together rather than separately.

The regulatory axis. If you are a government organisation, a critical infrastructure operator, a financially supervised institution or a processor of sensitive personal data, having all everyday traffic inspected outside the Kingdom is a defensible position that you will nonetheless spend real effort defending — repeatedly, to more than one supervisor, at every review cycle. For this segment an in-country inspection tier is effectively settled, and the only live question is how the upstream tier is arranged.

The threat axis. If a plausible attack against you exceeds your access circuit — and for any prominent public-facing service it does — an in-country tier alone is insufficient, regardless of how well it evidences.

For most organisations in scope of the ECC, both axes point to the same design: on-premise-first hybrid. Everything in country by default; upstream engagement exceptional, contractually bounded and rehearsed. The inverse arrangement — a cloud-first design with an appliance behind it — costs more, since you pay for continuous clean bandwidth and hardware, and it concedes the residency argument anyway.

Cloud-first remains a sensible answer for small organisations outside the ECC’s mandatory scope, with no regulated data and no team to operate an appliance. The correct response there is not to obscure the transfer but to document it properly.

Sources and further reading

We do not paraphrase paywalled analyst research or attribute figures to it, and we do not reproduce regulatory text from memory. The list below is what to obtain, and from whom.

National cybersecurity framework. Obtain the Essential Cybersecurity Controls directly from the National Cybersecurity Authority, in the current edition, in the language your assessors will use — control wording, structure and numbering change between editions, and a second-hand summary is not a compliance basis. From the same source, obtain the authority’s additional control sets where they apply to you: the controls addressed to critical systems, and the controls addressed to cloud computing, which speak to service providers and to their subscribing organisations separately. Also obtain the authority’s current guidance on incident reporting, since the route, the form and the timing are set by the authority rather than by the control document.

Data protection. Obtain the Personal Data Protection Law and its implementing regulations from the Saudi Data and Artificial Intelligence Authority, including the instruments dealing specifically with transferring personal data outside the Kingdom. Read the conditions and the assessment expectations in the source text; this is the area where vendor summaries are least reliable, because a provider has no incentive to characterise its own architecture as a transfer.

Sector regulators. Financially supervised entities should read the Saudi Central Bank’s cybersecurity framework alongside the national baseline, particularly its outsourcing and resilience expectations. Organisations procuring cloud services should also obtain the cloud computing regulatory framework published by the Communications, Space and Technology Commission, which addresses the service relationship from the telecommunications and IT services side.

Technical standards. If you want the interface between your own tier and an upstream tier to be standards-based rather than proprietary — which matters for exit planning and for multi-vendor designs — the relevant documents are RFC 8955 and RFC 8956 for BGP FlowSpec, and RFC 9132 and RFC 8811 for DOTS, the standardised signalling protocol for cross-organisation mitigation requests. NIST SP 800-189 covers resilient interdomain routing, and NIST SP 800-61 remains the most widely used reference for structuring incident handling in a way that produces the records an assessor expects.

Analyst coverage. The category is covered in Gartner’s Market Guide for DDoS Mitigation Solutions, Forrester’s The Forrester Wave: DDoS Mitigation Solutions and IDC’s IDC MarketScape for the segment. Where a vendor claims analyst recognition, ask for the current edition rather than a screenshot; positions move between editions, and Gartner restricts public quotation of its research, so a vendor quoting it publicly should be able to show reprint rights.

Public attack data. The quarterly DDoS reports published by Cloudflare and Akamai are the most widely cited open sources for attack volumes and vector mix. Both are compiled from their own customer bases, which is worth holding in mind when reading their regional distributions. CVE-2023-44487, the HTTP/2 Rapid Reset flaw, remains the clearest public example of a protocol-level weakness that no architectural choice could have isolated — a useful corrective to any assumption that the right topology alone closes this risk.