What does DORA Article 9 actually require for network segmentation?

Article 9(4)(b) of Regulation (EU) 2022/2554 requires financial entities to design their network connection infrastructure so it can be instantaneously severed or segmented, to minimize contagion across interconnected financial processes, using automated isolation mechanisms. That's a stricter bar than 'segmented' as most teams use the word — it's not enough to have documented VLANs and firewall rules between zones; the entity has to be able to actually cut a segment loose in real time, not via a change ticket.

Isn't this the same network-segmentation requirement covered in 'Hardening a Fintech Payment Platform'?

No — different regulation, different mechanism, and often a different entity type. That post's network-first ranking comes from PCI DSS 4.0.1's cardholder-data-environment scoping rule: segmentation there determines which systems fall under the full standard and which don't, and it only applies if you're handling card data at all. DORA Article 9's severability requirement applies to any DORA-scoped financial entity — a digital bank with no card-present business is fully in scope for this even if PCI DSS never touches it. A network can satisfy PCI's scoping requirement — documented, audited firewall rules between the CDE and everything else — and still fail DORA's bar, because 'documented and audited' isn't the same claim as 'can be cut off in seconds without a maintenance window.'

How do you test whether segmentation is actually severable, not just documented?

The same way you'd validate any control you're claiming works under stress: try to use it. A game-day exercise that isolates a specific segment — the payments-processing zone, a compromised branch network, a third-party integration — and measures how long it actually takes, end to end, from decision to isolation confirmed. If the answer involves paging a network engineer, opening a change request, and waiting for an approval window, that's a segmented network with a manual isolation procedure, not a severable one. AnySec's hardening engagements validate this the same way they validate any other control: re-testing against the same failure mode the requirement is meant to survive, not just reviewing the topology diagram.

Does DORA specify a maximum time for 'instantaneous' severance?

No, and that's worth being direct about. Unlike SCT Inst's explicit 10-second maximum execution time or DORA's own 4-hour/72-hour/1-month incident-notification clock, Article 9 doesn't attach a number to 'instantaneously' — it's a qualitative bar, not a benchmark to test against a stopwatch. In practice that means an examiner or auditor is going to ask you to demonstrate it, not just cite a number you hit once. Automated, pre-authorized isolation (a script or orchestration rule that executes without a human approval step) is what actually clears that bar; a documented four-hour emergency-change procedure very likely doesn't, even though nobody has defined the exact cutoff in writing.

Where does this fit inside a standard hardening engagement?

As a specific requirement inside the network category of the same five-category process — current-state assessment, threat-model the paths most likely to hit the stack, apply changes in change-windowed phases, then retest against the same attack paths. For a DORA-scoped digital bank, the network phase has to include an explicit severability test, not just a review of segmentation rules, before it can be signed off. It doesn't replace the identity, application, cloud-configuration, or server/OS categories — it's an additional bar the network category has to clear that most other verticals on this site don't have to meet.

Security Hardening for a Digital Bank: When 'Segmented' Isn't 'Severable'

The short answer

DORA Article 9(4)(b) requires a financial entity's network to be designed so it can be instantaneously severed or segmented during a live incident — not just divided into documented zones with firewall rules between them. Most banks that call their network "segmented" mean the second thing: a topology diagram, a set of VLANs, and change-managed firewall rules that took a security review to approve and would take another one to touch. That's a real control, and it's necessary. It is not the same claim as "we can cut this segment loose in real time without a change ticket," which is what the regulation actually asks for.

Who this is for

This is for a Head of Infrastructure, CISO, or DORA compliance owner at a digital bank — an entity operating under its own banking license, not a payment institution or PSP whose primary regulatory anchor is PCI DSS and PSD2. If your platform's segmentation question is "which systems fall inside our cardholder-data scope," hardening a fintech payment platform: what comes first answers that one. This post is for the narrower and less commonly asked question that comes after a bank has already segmented its network on paper: can that segmentation actually be executed as an emergency action, on demand, during an incident — or does isolating a compromised zone still require a human to open a ticket and wait for a window.

What "segmented" usually means in practice

A typical bank network review finds real segmentation: a payments-processing zone, a core-banking zone, a branch-network zone, third-party integration zones for open-banking APIs, each separated by firewall rules that were reviewed, approved, and documented against a topology diagram. That satisfies most generic segmentation requirements — a documented, audited boundary between zones with different risk profiles.

What it usually doesn't establish is whether any one of those boundaries can be turned into a hard cut in real time. Firewall rule changes at most banks go through the same change-management process as any other production change: a request, an approval, a scheduled window. That process exists for a good reason — an unreviewed firewall change is a common way to cause an outage — but it is exactly the mechanism DORA Article 9 is asking a financial entity to be able to bypass, in a controlled way, when containing an active incident.

What DORA Article 9 actually requires

Article 9(4)(b) of Regulation (EU) 2022/2554 requires financial entities to "design the network connection infrastructure in a way that allows it to be instantaneously severed or segmented," specifically to minimize contagion across interconnected financial processes, using appropriate automated isolation mechanisms. The requirement sits inside a broader set of Article 9 protection-and-prevention obligations — documented patch and update policies, access limited to what's needed for legitimate functions, strong authentication and encryption for data in transit and at rest, and documented change-management controls for anything touching security parameters — but the severability clause is the one that specifically targets network architecture, not policy or process.

What a typical "segmented" bank network has	What Article 9(4)(b) is actually asking for
Documented zones (payments, core banking, branch, third-party integrations)	The same zones, but each one individually isolatable
Firewall rules reviewed and approved through change management	Isolation that executes without waiting for that same change-management cycle
A topology diagram an auditor can review	A demonstrated isolation action an auditor (or an incident) can actually trigger
Manual runbook: page network engineer, raise emergency change, execute	Automated or pre-authorized mechanism: a script or orchestration rule that runs on decision, not on approval

The distinction matters because "segmented" and "severable" are both true statements a bank can make about the same network, and only one of them is what the regulation is checking for.

Why this isn't the same requirement as PCI DSS segmentation

Hardening a fintech payment platform: what comes first puts network segmentation first for a payment platform, but for a structurally different reason: PCI DSS 4.0.1 makes segmentation the control that defines cardholder-data-environment scope — get it wrong and every other control's audit scope expands to the whole estate. That's a scoping question, answered by whether the boundary is documented and enforced, and it only applies at all if the platform handles card data.

DORA Article 9(4)(b) doesn't ask what's in scope for an audit. It asks whether the network can be operated as an incident-containment tool in real time. A digital bank with no card-present business can be fully DORA-scoped — and therefore fully subject to this requirement — while never triggering PCI DSS at all. And a payment platform that has correctly scoped its cardholder-data environment under PCI can still fail DORA's severability bar on the exact same network, because "the boundary is correctly documented and audited" and "the boundary can be cut in real time without a change window" are independent claims. A hardening engagement that treats "we passed our PCI segmentation review" as evidence the DORA requirement is also satisfied is checking the wrong box.

This also isn't the same ground as private Anycast for a digital bank: when a single CDN becomes a DORA concentration risk, which addresses Article 29's third-party concentration-risk requirement — a governance question about vendor dependency, not a technical question about your own internal network architecture. Both sit inside DORA, and both apply to the same bank, but they're different articles answering different questions.

How to tell whether your segmentation is severable

The only reliable test is to try to use it. A game-day exercise that picks one real zone — the third-party open-banking integration segment is a reasonable first target, since it's externally reachable — and measures the actual time from "decision to isolate" to "isolation confirmed," under conditions that don't allow a human to skip the normal change process just because it's a drill. If the honest answer involves paging someone, opening a ticket, and waiting for an approval, the network is segmented with a manual isolation procedure, not severable in the sense Article 9(4)(b) means.

What clears the bar in practice is pre-authorized: an automated isolation mechanism — a scripted route withdrawal, a firewall policy that flips on a triggered condition, an orchestration rule tied to a detection signal — that a responder can execute without waiting on a separate approval cycle, because the approval already happened when the mechanism itself was built, reviewed, and signed off. The change-management rigor moves earlier, into building and testing the isolation mechanism, instead of sitting in the way of using it during an incident.

What this looks like in an actual engagement

This sits inside the network category of the same five-category hardening process used for every vertical on this site: current-state assessment, threat-model the paths most likely to hit the stack, apply changes in change-windowed phases with staging validation, then retest against the same failure mode the original requirement targets. For a DORA-scoped digital bank, the network phase specifically includes building and testing an automated isolation mechanism for each zone that would need to be cut off in a real incident, not just reviewing whether the zones themselves are documented and firewalled. Our Security Hardening engagements hand back a reproducible baseline — the same automation that made the segment severable during the engagement is what a responder triggers during a real one.

Limitations

Severability is one requirement inside one paragraph of one DORA article — it doesn't replace the rest of Article 9 (patch management, access controls, encryption, change management), and it isn't a detection control: an isolation mechanism only matters once something has already been detected and a decision has been made to use it, which is what a Managed SOC detection layer and an Incident Response retainer's containment authority are for. This also isn't legal or regulatory-examination advice — whether a specific isolation mechanism satisfies an examiner's read of Article 9(4)(b) for your entity depends on your national competent authority and the specifics of your architecture, not a generic pass/fail from this post.

What to do next

If your network is segmented on paper and you haven't tested whether any zone can actually be cut off without a change window, that's the gap a DORA-scoped bank is most likely to be carrying without knowing it. Tell us what your current segmentation looks like and we'll scope the game-day test and the automated isolation build around your actual zones, rather than a generic checklist.

Sources and review

DORA Article 9(4)(b)'s requirement that financial entities design network connection infrastructure to be instantaneously severed or segmented, using automated isolation mechanisms, to minimize contagion across interconnected financial processes, is drawn from the official text of Regulation (EU) 2022/2554 as mirrored at digital-operational-resilience-act.com — the same source previously used and verified for Article 29 in private Anycast for a digital bank and for Articles 24–27 in DDoS stress testing sign-off for a digital bank. The PCI DSS 4.0.1 cardholder-data-environment scoping comparison references AnySec's own prior published analysis in hardening a fintech payment platform rather than re-verifying the PCI Security Standards Council source a second time. SCT Inst's 10-second execution time, cited only as a contrast for how DORA does not attach a number to "instantaneous," was previously verified directly from the EPC's official scheme rulebook in incident response for a digital bank and isn't re-fetched here. Hardening methodology, deliverables, and baseline format are AnySec's own published Security Hardening service terms; no third-party vendor pricing, customer result, or examiner outcome is cited as fact. Author: AnySec Engineering. Published 2026-09-07; last reviewed 2026-09-07.