DORA became enforceable on 17 January 2025 with no transition period. For European banks, insurers and wealth managers, the regulation mandates network segmentation, least-privilege access, strong authentication and continuous monitoring across all ICT systems. These are not aspirational targets. They are auditable requirements backed by fines of up to 1% of average daily global turnover.
Most mid-market financial institutions still run fragmented security stacks: separate VPN concentrators, standalone firewalls at each branch, web filtering from one vendor, endpoint protection from another. That approach worked when employees sat in the office and applications lived in the data centre. It does not work when advisors connect from home, compliance tools run in the cloud, and regulators demand a unified audit trail that traces every access decision back to a verified identity.
A Secure Access Service Edge (SASE) platform consolidates these controls into a single cloud-managed service. This guide explains how each SASE component maps to specific DORA obligations, what the threat landscape looks like for European financial services right now, and how mid-market institutions can implement SASE without the complexity of enterprise mega-vendor projects.
Why DORA changes the security equation for financial services
Previous EU financial regulations addressed cybersecurity indirectly. DORA is different. It is the first harmonised framework that prescribes technical ICT controls for more than 22,000 financial entities and their ICT service providers across the EU.
The regulation rests on five pillars: ICT risk management, incident reporting, digital operational resilience testing, third-party ICT risk management, and information sharing. Each pillar maps to capabilities that a unified SASE platform delivers natively.
Article 9 is the most relevant for network security. It requires financial entities to design network infrastructure that can be “instantaneously severed or segmented” to prevent contagion during an incident. The same article mandates that access to ICT assets be limited to “what is required for legitimate and approved functions only” and that entities deploy “strong authentication mechanisms” with cryptographic controls. Article 10 requires detection mechanisms with “multiple layers of control” and monitoring of “user activity, ICT anomalies, and ICT-related incidents.”
The incident reporting obligations are aggressive. Financial entities must submit an initial notification within four hours of classifying a major ICT incident, an intermediate report within 72 hours, and a final report upon completing root cause analysis. Without centralised logging that correlates access events across all users, devices and applications, meeting these timelines is impractical.
Third-party ICT risk management (Articles 28 to 44) adds another layer. Financial entities must maintain a Register of Information documenting all ICT third-party contracts. Article 30 requires contractual provisions covering data locations, SLAs, termination conditions, and unrestricted audit rights. For institutions using US-headquartered security vendors, this raises uncomfortable questions about jurisdictional exposure under the CLOUD Act.
| DORA requirement | Relevant article | SASE component |
|---|---|---|
| Least-privilege access with strong authentication | Art. 9(4)(c), 9(4)(d) | ZTNA with MFA and device posture |
| Network segmentation and automated isolation | Art. 9(4)(b) | FWaaS with micro-segmentation |
| Data protection in transit and at rest | Art. 9(2), 9(3)(a) | SWG with TLS inspection and DLP |
| Multi-layered detection and user activity monitoring | Art. 10(1), 10(3) | Centralised SASE logging and analytics |
| Business continuity with switchover capability | Art. 11(6)(a) | SD-WAN with link failover |
| Third-party access control and audit | Art. 28, 30 | ZTNA with session recording and time-bound access |
| 4-hour incident classification and notification | Art. 19 | Unified logging with SIEM integration |
The threat landscape demands action, not planning
The numbers speak clearly. ENISA’s Finance Sector Threat Landscape report, published in February 2025, documented 488 publicly reported incidents affecting European financial services between January 2023 and June 2024. Banks absorbed 46% of all attacks. DDoS was the most prevalent threat type, with attacks reaching 1 Tbps against targets including European banks and financial associations.
The third-party risk vector that DORA specifically targets is already the dominant attack path. Banco Santander disclosed in May 2024 that a third-party-hosted database exposed customer data from three countries. ABN Amro suffered a supply chain ransomware attack through provider AddComm the same month. The CrowdStrike outage of July 2024 affected banks including UBS and Deutsche Bank, exposing ICT concentration risk at scale.
Belgian institutions face the same pressures. Crelan Bank lost approximately €70 million in a BEC fraud that remains one of Europe’s largest. Degroof Petercam experienced an insider data leak in 2022 when a former employee exfiltrated client information. Belgium’s Centre for Cybersecurity recorded 120 unique ransomware cases in 2024, up 24% year-over-year.
The financial impact reinforces urgency. IBM’s Cost of Data Breach report puts financial services breaches at an average of $6.08 million, 22% above the global mean. Ransomware hit 65% of financial firms in 2024 according to Sophos, with average recovery costs of $1.53 million excluding ransom payments.
These are not abstract risk scenarios. They are the operational reality that DORA was designed to address.
How each SASE component solves a financial services problem
ZTNA replaces VPN for regulated access
Traditional VPNs grant broad network-level access. Once connected, a user or attacker can move laterally across trading systems, core banking databases and customer records. ZTNA provides application-level access: each session is individually authenticated with MFA and device posture verification, then granted access only to the specific application requested.
For a wealth management firm, this means advisors connect directly to their portfolio management system and CRM without ever joining the corporate network. Core banking systems become invisible to port scanners. Admin access to network infrastructure requires separate roles with step-up authentication and time-limited sessions. One Belgian wealth manager reduced remote access latency from 85ms to 12ms after migrating from VPN to SASE.
Third-party access is particularly important under DORA. External auditors and regulators can access specific applications through browser-based portals. No VPN client, no agent installation, no corporate device required. Sessions are recorded and time-bounded. When the engagement ends, access revokes automatically.
SWG protects against data exfiltration and phishing
Financial services phishing campaigns are highly targeted. Attackers impersonate internal wire transfer approval workflows, banking portals and regulatory bodies. A Secure Web Gateway inspects all web traffic, blocks known malicious domains and uses ML-based analysis to identify zero-day credential harvesting pages.
Integrated DLP capabilities detect financial data patterns in transit: account numbers, PII, proprietary trading models and client correspondence. Instance-aware controls distinguish between the corporate SharePoint instance and a personal Dropbox account, blocking sensitive data movement to unsanctioned destinations. This directly addresses shadow IT, a problem where enterprises average over 2,000 applications with more than 60% unapproved by IT.
SD-WAN transforms branch connectivity
Financial institutions with multiple advisory offices, bank branches or regional headquarters typically rely on expensive MPLS circuits. SD-WAN provides transport diversity by augmenting or replacing MPLS with broadband and 4G/5G connections, with financial institutions reporting 30 to 50% connectivity cost reduction.
Application-aware routing ensures quality of service for trading applications with strict latency requirements, video conferencing for client meetings, and VoIP for call centre operations. For most mid-market financial firms, the recommended approach is retaining MPLS for mission-critical flows like SWIFT messaging while SD-WAN handles everyday traffic.
Device posture creates tiered access
DORA requires access limited to legitimate and approved functions. Device posture enforcement translates this into practice with a tiered model. Fully managed, compliant devices get full access to authorised applications. Managed but non-compliant devices receive limited access with remediation prompts. Unmanaged BYOD devices, common when auditors or regulators visit, connect through browser-based portals with no data download and full session recording. Non-compliant devices are denied entirely.
The data sovereignty question financial services cannot ignore
DORA Article 30 requires contractual transparency on data locations and processing jurisdictions. For institutions using US-headquartered SASE vendors, this creates a structural tension. The US CLOUD Act compels American companies to produce data stored anywhere in the world when served with a valid US law enforcement request.
The distinction between “EU-hosted” and “EU-controlled” is becoming a procurement requirement in European financial services. Data processed on EU servers operated by a US parent company still falls under US jurisdictional reach. A European-headquartered SASE provider eliminates this exposure entirely. This is not a political statement. It is straightforward risk management under DORA’s third-party provisions.
The European regulatory trend reinforces this direction. The EU’s November 2025 Declaration for European Digital Sovereignty, ongoing scrutiny of US cloud providers under the Digital Markets Act, and the operational reality of DORA third-party audits all point the same way.
Phased SASE implementation for mid-market financial services
Deploying SASE does not require replacing everything at once. A phased approach delivers compliance improvements at each stage while keeping client-facing operations running. For mid-market institutions with 50 to 400 users, the timeline typically spans six to twelve months.
Phase 1: Assessment and identity integration (4 to 6 weeks)
Map existing network architecture, security tools and user access patterns. Inventory all financial applications: core banking, trading, SWIFT, CRM, compliance and reporting systems. Integrate your identity provider and synchronise user groups aligned with business roles. Define device posture baselines for managed devices.
Phase 2: Pilot with remote access (4 to 8 weeks)
Publish two to three high-usage applications through ZTNA for remote advisors and employees. Run VPN and ZTNA in parallel during the pilot. Enable a baseline Secure Web Gateway policy that blocks known malicious domains. Measure latency, authentication success rates and support ticket volume.
Phase 3: Expand to branches and web security (8 to 16 weeks)
Deploy SD-WAN at branch offices, starting with non-critical locations. Extend ZTNA to cover all business applications. Activate full SWG with TLS inspection where lawful and appropriate, plus DLP policies for sensitive financial data. Deploy inline isolation for agentless devices: printers, scanners and meeting room equipment in shared office spaces.
Phase 4: Legacy decommissioning and compliance reporting (4 to 8 weeks)
Retire VPN concentrators after ZTNA coverage is complete. Phase out MPLS circuits as SD-WAN proves stable, retaining dedicated circuits for SWIFT if required. Decommission on-premises firewall appliances. Configure SIEM integration and automated compliance reports aligned with DORA’s incident reporting timelines.
A Belgian wealth management firm completed this migration in eight weeks, achieving a 58% reduction in total security costs while simplifying DORA and NIS2 compliance.
DORA compliance evidence that SASE generates automatically
Auditors expect evidence, not promises. A unified SASE platform generates the documentation that DORA requires without manual log correlation across multiple systems.
ICT risk management (Articles 5 to 16). The platform provides a documented framework covering identification, protection, detection, response and recovery. Access control policies, device posture rules and web security configurations are version-controlled with timestamps and approver identities.
Incident reporting (Articles 17 to 23). Centralised logging with real-time alerting makes rapid incident classification practical. When something happens, the team pulls a single event timeline showing which user, from which device, accessed which application, at what time and from what location. This supports the four-hour initial notification requirement.
Resilience testing (Articles 24 to 27). Cloud-managed security with continuous updates reduces the attack surface that needs testing. Centralised visibility simplifies the scoping and reporting process for annual vulnerability assessments and, for systemically important institutions, threat-led penetration testing under TIBER-EU.
Third-party risk management (Articles 28 to 44). The Register of Information submission, first due 30 April 2025, requires documenting all ICT third-party contracts. A single-vendor SASE platform simplifies this by consolidating multiple point-product contracts into one. Session recording and audit trails for third-party access support DORA’s oversight requirements.
Information sharing (Article 45). SIEM integration enables participation in sector-specific threat intelligence sharing without exposing raw client data.
The Belgian financial services context
Belgium’s “Twin Peaks” model divides financial supervision between the NBB and the FSMA. Five significant institutions are directly ECB-supervised, while 17 less significant institutions fall under NBB oversight. Beyond the large banks, a substantial mid-market tier exists: private banks like Delen, J. Van Breda and Degroof Petercam; cooperative banks like Crelan; and a range of insurers and financial intermediaries.
Belgium was the first EU member state to transpose NIS2 into national law. The DORA implementation bill was adopted on 30 January 2025, with fines of up to 10% of company turnover or €5 million. The NBB issued circulars for incident reporting and Register of Information submissions in February 2025.
FSMA surveys found progress in ICT risk assessment but persistent gaps in incident response, testing, and third-party risk management. These are precisely the capabilities that a unified SASE platform delivers. For Belgian financial institutions preparing for their first DORA conformity assessment, the NIS2 compliance checklist provides a practical starting framework, as many NIS2 controls overlap with DORA requirements.
Belgian household financial assets exceed €1.5 trillion, making wealth management a substantial segment. Private banks and independent wealth managers handling €100 million to €1 billion in client assets are the classic mid-market profile: regulated, managing sensitive data, operating hybrid workforces across multiple advisory offices, and increasingly targeted by sophisticated threat actors.
How Jimber makes SASE workable for financial services
Jimber delivers Real SASE in a single cloud-managed platform designed for European mid-market organisations and the service partners that support them.
Zero Trust Network Access provides granular per-application access with identity and device posture verification. Advisors reach their portfolio system. Compliance officers reach their reporting tools. Nobody reaches the network.
Secure Web Gateway and Firewall-as-a-Service enforce consistent web controls with threat blocking, TLS inspection and DLP. Policies follow users whether they connect from the head office, a branch or home.
SD-WAN delivers resilient, high-performance connectivity between advisory offices and branches without the cost of dedicated MPLS at every location.
NIAC hardware provides inline isolation for agentless devices. Printers, scanners and meeting room systems in shared financial services offices are common blind spots. Without isolation, they sit on the same network as workstations processing client data. Jimber closes this gap without requiring agents on devices that cannot run them.
The platform is headquartered in Belgium with data processing within EU borders. No US parent company. No CLOUD Act jurisdictional exposure. For financial institutions where DORA’s third-party provisions make data sovereignty a procurement requirement, this matters.
Transparent per-user pricing makes three-year TCO projections straightforward. No bandwidth surcharges, no hidden add-ons. Service partners can build managed security packages with clear margins and predictable economics.
Ready to see how Jimber maps to your DORA compliance requirements? Book a demo and walk through a deployment plan for your financial services environment.
FAQ
Is SASE suitable for mid-market banks and wealth managers?
Yes. Mid-market financial institutions are often better positioned for SASE than large banks because they have less legacy complexity to untangle. A unified platform replaces the fragmented stacks that small IT teams struggle to manage. Deployment typically takes six to twelve months with a phased approach.
How does SASE support DORA compliance specifically?
SASE addresses all five DORA pillars. ZTNA and device posture enforcement satisfy Article 9’s access control requirements. FWaaS delivers the network segmentation Article 9 mandates. Centralised logging supports the four-hour incident notification timeline. And a single-vendor European platform simplifies the Register of Information and third-party risk management obligations under Articles 28 to 44.
Does SASE replace our existing firewalls?
Not necessarily on day one. Most financial institutions run SASE alongside existing firewalls during the transition. Cloud-delivered FWaaS gradually takes over policy enforcement as ZTNA removes the need for network-level access. Firewalls at branch locations are typically the first to be decommissioned as SD-WAN provides secure connectivity.
What about SWIFT and trading system integration?
The recommended approach retains dedicated circuits for SWIFT messaging transport while SASE handles user access control and policy enforcement. ZTNA provides least-privilege access to SWIFT interfaces (Alliance Access, Alliance Lite2) with step-up authentication and session recording, supporting SWIFT CSP 2025 controls.
How does European data sovereignty affect SASE vendor selection under DORA?
DORA Article 30 requires contractual transparency on data processing locations and mandates exit strategies. US-headquartered SASE vendors are subject to the CLOUD Act, which can compel data production regardless of where data is stored. A European-headquartered provider eliminates this jurisdictional conflict, simplifying the third-party risk assessment and Register of Information documentation.
Can our MSP manage SASE for us?
Yes. A multi-tenant SASE platform allows service partners to manage security across multiple financial services clients from a single console. This model is common in the mid-market, where about 63% of organisations use an MSP for SASE deployment. The transparent pricing model and API-first architecture support scalable managed services.
