The SAMA Cyber Security Framework and DDoS Resilience: Architecture, Evidence and Testing

In most organisations a DDoS purchase begins as a capacity question: how many gigabits per second, how many packets, how many concurrent sessions. In a supervised financial institution those questions are real but they are not the ones that decide anything. The decision is ultimately defended somewhere else — in an internal audit report, in a maturity self-assessment returned to the supervisor, or in a conversation about an incident that has already happened. The questions asked there are of a different kind. Which risk does this control address, who owns it, who inspects your customers’ traffic and in which country, how do you know what happened during the event, and when did you last prove that any of it works?

This guide takes the DDoS architecture decision for banks, insurers, finance companies and payment institutions operating in the Kingdom and puts it in the language of that second set of questions. It is the financial-sector overlay, not the national baseline: the data residency analysis and the general control mapping are set out in the companion guide on DDoS protection and the national Essential Cybersecurity Controls, and this article does not repeat them; for institutions with entities elsewhere in the Gulf, each state’s own cross-border conditions apply on top of the Saudi position. What follows is the part that is specific to being supervised as a financial institution.

A note on how this article treats regulatory text

Everything below describes supervisory expectations qualitatively. It deliberately contains no control identifiers, no framework version references, no maturity level numbers, no reporting deadlines and no thresholds. That is not caution for its own sake; it is accuracy. Frameworks are reissued, control numbering is renumbered between editions, and a reference frozen into an article sends a reader to a document that is no longer the one they are assessed against.

So treat the headings below as the right questions rather than as the answers. The answers — which requirements apply to your category of institution, in what form, and against what expectation — come from the current text obtained from the authority and from your own compliance function. That is also the correct sequence when writing a tender: compliance states the requirement in writing first, and the technical team then converts it into a measurable acceptance criterion.

What kind of document the framework is

The Saudi Central Bank supervises the financial institutions operating in the Kingdom — banks, insurers and finance companies among them — and publishes a cyber security framework addressed to the organisations under its supervision. Two structural properties of that document shape every architecture conversation that follows.

The first is that it is organised by domain rather than by technology. Its themes run through leadership and governance, risk management and compliance, operations and technology, and the management of third-party relationships. A denial-of-service capability is not a topic in that structure; it is an implementation detail that has to answer to several of those themes at once — which is why a purely technical evaluation of a DDoS product tends to satisfy none of them.

The second is that the framework works through maturity rather than through a pass or fail line. Supervised institutions periodically assess themselves against it and report the result. A maturity model is unforgiving in a particular way: it rewards controls that are defined, owned, measured, reported and improved, and it gives very little credit to controls that merely exist. An excellent mitigation device configured by one engineer, with thresholds documented nowhere, never tested and reporting to no one, scores poorly against a modest capability that has an approved design, a written policy, a monitored alert path, an exercise record and a metric that reaches the board.

That is the single most useful thing to internalise before any vendor conversation. The framework rewards demonstrability, and demonstrability is an architectural property as much as a documentary one. Some designs generate their own evidence as a by-product of operating. Others require you to request evidence from a third party whose commercial interest lies in producing less of it.

Availability is a supervised outcome, not a service target

In a commercial business, staying up is a quality objective: miss it and you lose customers and revenue. In a supervised financial institution the same fact sits in a different register, and three consequences follow.

Availability is a security objective with equal standing. The framework rests on the settled triad of confidentiality, integrity and availability and treats the third as a protected property in its own right. A denial-of-service event is the purest possible attack on it — nothing is stolen, nothing is altered, and the objective fails completely. You therefore cannot scope a DDoS control out of relevance on the grounds that no data was exposed, and you cannot classify an internet banking outage caused by an attack as a customer experience issue. In the supervisor’s frame it is a cyber security incident.

Availability is a board-level accountability. Cyber security governance in the framework runs upward: risk is owned, reported and overseen at senior level, not delegated into the network team. “We bought an appliance” is not an answer in that structure. What is expected is a control with a named owner, an entry in the risk register, a defined measurement and a reporting line that actually carries the measurement upward.

Availability is a measured output of business continuity. Business impact analysis, recovery time objectives and recovery point objectives are long-established in financial institutions. A DDoS event is an unusual member of that family: it destroys no data and threatens the recovery time objective directly. When a continuity plan contains fire, flood and data centre loss but no denial-of-service scenario, that is one of the easiest gaps for an assessor to find — and the gap has a specific technical shape, because failing over to a secondary data centre does not resolve a DDoS event. The attack is directed at an address, not at a building.

To this, sector-specific layers are added. Institutions in the payments chain answer to the supervisor’s oversight of national payment infrastructure as well as to its cyber security framework. Card acceptance brings the PCI DSS control set. International messaging brings the SWIFT customer security programme. None of these instruments tells you to buy a DDoS device. All of them expect availability and incident management to be demonstrated.

The reference architecture: an upstream tier and a local inline tier

For a supervised financial institution there is effectively one defensible architecture, and it has two tiers whose relationship is complementary rather than redundant.

The upstream tier sits in a carrier backbone or in an independent scrubbing provider’s centres. It has exactly one job and nothing else substitutes for it: stopping volumetric floods above your access circuit, before that circuit fills. Without it, a sufficiently large attack leaves you with no options at all.

The local inline tier sits at your own boundary, on your own hardware, permanently in path. Its job is everything that stays below the circuit line and requires state and application awareness: TCP state exhaustion, slow-request attacks, low-volume campaigns aimed at login and authentication endpoints, and request floods against the APIs behind a mobile banking application.

That division is a general enterprise description and is not in itself specific to finance. What is specific to finance is why the local tier stops being negotiable, and the next three sections are exactly that argument.

Why a supervised institution needs the local layer

The outage window is the whole argument

In an upstream-only design, the interval between the start of an attack and full mitigation is a sequence: detecting the attack, deciding to divert, announcing the prefixes, waiting for routing to converge, and getting cleaned traffic back over the return path. Each of those steps takes non-zero time even in a well-run institution, and the sum is a window during which the service is degraded or unavailable.

For a retail website that window is an irritation. For a bank it is something else. Sessions cut mid-flow, payment instructions that time out, authentication journeys that cannot complete and mobile transactions abandoned halfway all leave traces in two places at once: with the customer, and in the institution’s own incident records. The window competes directly with the recovery time objective already written in the continuity plan.

An always-on local tier does not shorten that window. It prevents it from opening. Below the circuit line, mitigation is already active with no handover to negotiate. Above it, while the upstream tier is being engaged, the local tier at least keeps the stateful components at the boundary alive — and this second effect is routinely overlooked. In a volumetric event the firewall’s session table, the load balancer’s connection pool and the application servers’ thread pools can be exhausted long before the circuit itself is full. The institution can be down while the link still has headroom.

Latency: payment paths are a different sensitivity class

The standard objection to an inline device is that putting anything in the traffic path adds latency. The objection is correct and deserves an honest answer rather than a deflection.

It also gets pointed in the wrong direction more often than not. Cloud-based scrubbing does not eliminate latency; it relocates and enlarges it. Steering traffic to a scrubbing centre outside the Kingdom means the packet travels a longer geographic path, traverses an additional encapsulation and is routed a second time on the way back. That is a different order of magnitude from the microsecond-to-millisecond cost of a device at your own boundary — and, crucially, it is a cost you pay continuously rather than only while under attack.

Why this matters more in finance than elsewhere comes down to which paths exist:

• Card authorisation and settlement paths. Timeout budgets on these paths are narrow, and a breach of the budget does not produce a slow transaction — it produces a declined one. A decline is not a technical statistic; it is a service failure visible to the customer at the point of sale.
• Instant payment and transfer flows. Where the end-to-end expectation is defined below a second, every component in the path draws from the same budget, and there is no slack to donate.
• Market access and order routing. For institutions with brokerage operations, order entry and market data are the most latency-sensitive financial traffic there is, and what governs them is not the mean but the tail and the stability of the distribution.
• Internal calls between core banking and the channel layer. Because these run in chains, latency added at a single step is multiplied before the customer sees it.

The practical conclusion is that “does it add latency” cannot be an evaluation criterion, because the answer is always yes. The criterion is how much, under what load, and how stably. Acceptance testing should measure tail percentiles rather than averages, with mitigation active and attack traffic present, on your own traffic profile rather than on a vendor’s datasheet. Two further properties belong in the same test: how wide the latency distribution becomes under load, and how the device behaves when it fails. Hardware bypass — the link staying open through a power loss or a software fault — is the single most important continuity question about any inline deployment, and it is an acceptance criterion, not a feature bullet.

The honest limit of the local tier

An argument that stopped there would be selling something. The limit has to be stated as plainly as the benefit: no on-premise device can filter traffic that has already saturated the circuit delivering it.

If the circuit is 10 Gbps and 60 Gbps arrives, the link is full before the device is consulted, and whether it is rated for 20 or 200 Gbps is irrelevant above that line. So “we will buy an appliance and skip the upstream tier” is indefensible for an internet-facing financial institution — and so, symmetrically, is “we have a cloud provider, we need nothing on site”. The two tiers are designed together, and the trigger, thresholds and return path between them are designed before purchase, not discovered during an incident.

Appliance	Upstream scrubbing tier	On-premise inline tier
Floods larger than your access circuit	The only tier that can help	Cannot help — the circuit fills first
Attacks below the circuit line	Often invisible; no reason to divert	Always in scope, always on
State exhaustion at the perimeter	Only after diversion completes	Absorbed before firewall and load-balancer tables fill
Time to full mitigation	Detection, decision, announcement, convergence	No handover step to wait for
Added latency on payment paths	A longer geographic path plus a return leg	Bounded and measurable on your own premises
Custody of incident evidence	Provider's format, resolution and retention	Your own capture, your own retention policy
Who can schedule a test	Joint change with the provider	You, on your own maintenance window
Assurance chain shown to the supervisor	Provider, sub-processors, facility countries	Your own design, policy and records

The two columns are not alternatives and the table should not be read as a scorecard. Each tier answers questions the other cannot, which is why the reference design for a supervised institution contains both — and why the responsibility boundary between them belongs in the contract rather than in a conversation.

Outsourcing: what changes when the scrubbing tier sits abroad

Buying DDoS scrubbing as a service is not a network procurement in a supervised institution. The framework carries third-party and outsourcing risk as its own domain, and that domain brings its own discipline to the relationship. The detail of which arrangements are in scope, and in what form, comes from the current text and from your compliance function; the shape of the expectations is stable enough to design a tender around.

A risk assessment before the arrangement is entered into. It covers what happens to your operations if the service becomes unavailable, the provider’s financial and operational capability, and whether alternatives exist. For DDoS scrubbing the sharpest question in that assessment is: if this provider cannot deliver, what is our residual internet availability? An institution with a local tier answers “degraded but functioning”. An institution relying wholly on the upstream tier cannot answer at all.

Contractual security requirements, audit and information access rights. Internal audit and the supervisor need to reach records relating to an outsourced service. This clause quietly becomes theoretical when the provider is abroad: event records held in a foreign scrubbing centre are reached through the law of the country that centre sits in and through the provider’s willingness. Whether a contractual audit right is actually exercisable in the provider’s jurisdiction is a question to ask during procurement, not after an incident.

Where the service is performed. Three legal strands stack here. Banking secrecy applies its own regime to customer information and has a cross-border dimension. Personal data transfer outside the Kingdom is governed by the data protection regime supervised by the Saudi Data and Artificial Intelligence Authority — analysed in detail in the companion national-baseline guide and not repeated here. And supervisory expectations about where information systems may be located, and about receiving services from abroad, apply on top of both.

None of this prohibits cloud scrubbing. What it does is convert it into a choice that has to be justified, repeatedly, to more than one audience. The easiest justification to sustain is architectural: build the design so that everyday traffic stays inside the Kingdom, with the local tier always on and the upstream tier engaged only above the circuit line, under conditions written into the contract and the runbook. Cross-border processing then stops being a permanent condition and becomes a defined, bounded and documentable exception. One trap to avoid: a transfer position or privacy notice claiming that no data leaves the Kingdom is simply inaccurate in a two-tier design. Describe the diversion conditions and what is processed while diversion lasts. An accurate exceptional-transfer description survives scrutiny; an absolute claim contradicted by your own runbook does not.

Concentration and exit. The last element of outsourcing discipline is not depending on a single relationship. Where both tiers of the same defensive function come from one manufacturer or one commercial relationship, that is a concentration the risk register should carry explicitly — the engineering case is developed separately in two layers, two vendors. The point to add here is that in a supervised institution the argument is not only about common-mode failure. It is also about the exit plan the outsourcing discipline expects you to have.

Evidence and audit trail during an incident

This subject is barely discussed outside financial institutions and is among the first things an audit asks about inside one.

During a DDoS event, the logging infrastructure takes its heaviest load at precisely the moment it is most needed, for a simple reason: one attack packet produces a separate record on every component that sees it. A flow record at the edge router, a deny entry at the firewall, a signature alert on the intrusion prevention system, a rule hit at the application firewall, an error line in the application. As attack volume rises, that multiplication exceeds the processing capacity of the collection and correlation platform.

The consequences are concrete in a banking context.

• Losing records means losing evidence about the event itself. The lines showing when the attack began, where it came from, which services it affected and when mitigation engaged are exactly the lines that drop. The post-incident report loses its basis at the moment it is being written.
• Correlation between transaction records and security records breaks. When a customer says a transaction failed at a particular time, the record chain is what proves or disproves it. A gap in the chain leaves the institution unable to answer a complaint or a dispute with records.
• Timestamp and integrity expectations are affected. Obligations that assume an unbroken, integrity-protected and accurately timestamped access record cannot be met from a log stream that was interrupted.
• Source address information can change during diversion. Once the upstream tier is engaged, traffic reaches you through the provider’s network, and depending on how the return path is constructed your internal components may record the mitigation path rather than the original client. That is a break in the record chain and in post-incident analysis, and how source address information is preserved during diversion is a question that belongs explicitly in the tender.

The architectural implication is clear enough. A tier that absorbs the flood at your own boundary means the components behind it never log traffic they never saw — so the contribution of the local tier to the audit trail is not that it produces more records, but that the unnecessary records are never produced at all. Add to that the fact that the mitigation tier’s own records stay inside the institution, under its own retention policy and stamped by its own time source, and the whole record chain sits under a single legal regime and a single line of accountability.

Continuity testing: the part that is never rehearsed

Business continuity management is not new in financial institutions. What is new is placing the denial-of-service scenario explicitly inside that framework, and testing it as the framework expects plans to be tested — by exercise, with results, findings and remediation, rather than by document review.

The critical point is what the exercise should verify. It is not whether the appliance works; that is the least fragile component in the design. The parts that fail in real events are elsewhere:

1. Does the diversion trigger actually work — on whose authority, and within what elapsed time?
2. Is the prefix announcement accepted upstream, and does the address plan support diverting the affected services without dragging unaffected ones with them?
3. Is the return path for cleaned traffic still standing, and is its configuration current rather than a year stale?
4. When the circuit is completely saturated, is there a defined and working out-of-band channel for reaching the provider — and does anyone know the number?
5. Is the fail-back condition defined? Who decides when to return to normal, and against what criteria?
6. Were the records generated during the event actually collected in full?

Each of these is a point most likely to fail the first time it is attempted, and a real incident is the worst possible first attempt. That is why the exercise must include the provider, and why the provider’s obligation to participate belongs in the contract rather than in goodwill.

Metrics worth producing from exercises and real events. Time from attack onset to detection; time from detection to full mitigation; legitimate traffic loss during mitigation; time to complete diversion upstream; tail-percentile latency measured with mitigation active; and the severity distribution of findings raised by the exercise. Getting these into the cyber security risk indicators that are reported upward is the most practical way to have the control counted as operating rather than merely implemented — which, in a maturity model, is the difference that moves a score.

Incident reporting. Escalating significant cyber incidents to the supervisor is an established expectation, and a large denial-of-service event against customer-facing services is a candidate. Which events are reportable, in what form and on what timeline is a question for your compliance function against the current text. The architectural requirement that falls out of it is concrete and belongs in the tender: the mitigation tier must be able to produce, as a report rather than as a log export, the start and end time of the event, the vector distribution, the services affected and the volume mitigated.

Structuring the RFP so it survives a supervisory review

The following is the minimum set that makes a financial institution’s DDoS tender not merely technical but auditable. Every item needs a measurable acceptance criterion; a line reading “the provider offers DDoS protection” does not count as a control in any assessment.

1. Architecture and responsibility boundary. A table stating which tier is responsible for which attack class, up to which threshold, and within what elapsed time. Where the boundary is unwritten, both parties wait for each other during an incident.

2. Latency acceptance criteria. Expressed as tail percentiles, not averages; measured with mitigation active and attack traffic present; measured on your own traffic profile during proof of concept. State separately the acceptance criterion for latency variance.

3. Failure behaviour. Hardware bypass present or absent; link behaviour under power loss and under software fault; how the high-availability pair is constructed; failover time.

4. Diversion and return path. Trigger thresholds; who may invoke automatically and manually; whether the carrier can trigger independently; the technical construction of the return path; the fail-back condition; the maximum diversion duration. Tested end to end during proof of concept, with the test written into the contract as an acceptance criterion.

5. Preservation of source address information. Whether internal components see the original client address during diversion and, if not, how the record chain is compensated.

6. Where the service is performed. The countries of the scrubbing centres your prefixes will actually be steered to — not the provider’s global footprint — the sub-processor list and their locations, and a notification obligation when either changes.

7. Audit and information access rights. Access for internal audit and for the supervisor to records relating to the service, plus an explicit answer on whether that right is exercisable in practice in the provider’s jurisdiction.

8. Logging and reporting. Output in standard formats such as syslog and IPFIX; synchronisation to the institution’s own time source; defined summarisation behaviour so that log generation does not itself become a bottleneck during an attack; and a structured incident report suitable for supervisory notification.

9. Exercise obligation. At least annually, with the provider participating, covering diversion and return path end to end. The remediation window for findings belongs in the contract too.

10. Exit plan. How migration is executed at contract end or on provider failure, how data is returned or destroyed, and how the service is sustained during transition.

11. Independence criteria. Whether the local tier’s detection engine can operate without a central intelligence feed, whether its codebase is distinct from the upstream tier’s, and whether the commercial relationships are genuinely separate.

Products exist that meet the whole of this criteria set in a single device: full L3 to L7 coverage in one inline unit, a detection engine able to operate locally without dependence on a central cloud, and hardware bypass for inline deployment. Assess every manufacturer against the same criteria; what belongs in the tender is the criteria, not a product name. That is also what is defensible under supervision: not which product was chosen, but the reasoning and the measurement behind the criterion that chose it.

The decision, stated plainly

For a supervised financial institution operating in the Kingdom, the conclusion compresses into three sentences.

An upstream-only architecture brings with it both an outage window and the continuous inspection of all everyday customer traffic outside the institution. Both may be defensible, but both must be separately justified, and the justification has to be given again at every review cycle.

A local-only architecture is helpless against a flood that saturates the access circuit, which leaves a gap in the continuity plan that cannot be closed by any amount of documentation.

The local-first two-tier design — an always-on tier at your own boundary and an upstream tier engaged only above the circuit line — closes the outage window and reduces cross-border service use to a defined exception. It is the easiest configuration to defend in a supervisory review, because it demonstrates the availability control and the outsourcing discipline in the same breath.

One closing reminder, which is the opening warning repeated. The obligations described here are a qualitative frame. Determine the specific requirements applying to your institution from the current text and with your compliance function. A tender clause that rests on a written compliance opinion counts as a control under assessment; a clause resting on the technical team’s good intentions remains a preference.

Sources and further reading

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

Financial sector supervision. Obtain the cyber security framework published by the Saudi Central Bank, in its current edition, directly from the authority, along with whichever further instruments apply to your category of institution — ask specifically about business continuity, outsourcing and incident notification, since those three touch a DDoS architecture most directly. Read the current text rather than a summary: domain structure, wording and maturity expectations change between editions, and a second-hand account is not a compliance basis.

National cybersecurity baseline. Obtain the Essential Cybersecurity Controls and the authority’s further control sets from the National Cybersecurity Authority. The mapping between those controls and a DDoS architecture, and the evidence pack an assessor expects, are set out in the companion guide on the national baseline.

Data protection. Obtain the Personal Data Protection Law and its implementing instruments from the Saudi Data and Artificial Intelligence Authority, including those addressing the transfer of personal data outside the Kingdom. 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 control sets. PCI DSS from the PCI Security Standards Council for card environments, and the SWIFT Customer Security Programme with its customer security controls framework for institutions using international messaging.

International standards. ISO/IEC 27001 for information security management and ISO 22301 for business continuity management give the vocabulary most supervisory frameworks share. NIST SP 800-34 covers contingency planning for information systems and NIST SP 800-61 remains the most widely used reference for structuring incident handling so that it produces the records an assessor expects.

Technical standards. If you want the interface between your own tier and the upstream tier to be standards-based rather than proprietary — which matters for exit planning and multi-vendor designs — the relevant documents are RFC 8955 and RFC 8956 for BGP FlowSpec, RFC 5635 for remotely triggered black-hole routing, RFC 9132 and RFC 8811 for DOTS, and RFC 7011 for IPFIX flow telemetry. NIST SP 800-189 covers resilient interdomain routing.

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.

Public attack data. The periodic 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 breakdowns. CVE-2023-44487, the HTTP/2 Rapid Reset flaw, remains the clearest public example of a protocol-level weakness that no choice of topology could have isolated.