The Digital Operational Resilience Act became directly applicable across the EU on January 17, 2025, and eighteen months on, plenty of banks, payment institutions, and insurers are still treating it as a compliance checkbox rather than what it actually is – a mandate to prove your systems keep running when things break, including the network layer most teams never think about. DORA and operational resilience for financial systems means one specific thing in practice: regulators now expect ICT risk management to cover the full attack surface, and that includes every port a critical or important function exposes to the internet.
What DORA Actually Requires From ICT Infrastructure
DORA (Regulation (EU) 2022/2554) applies to roughly 22,000 financial entities and their ICT third-party providers across the EU. It rests on five pillars: ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing.
Article 9 is the one that matters most for network exposure. It requires entities to identify, classify, and adequately document all ICT-supported business functions, and to continuously monitor the ICT systems and tools that support them. A payment processor running a public-facing API gateway or a core banking platform with an exposed admin console isn’t optional reading here – it’s the literal scope of the article.
The Regulatory Technical Standards on ICT risk management tools (adopted by the European Supervisory Authorities in January 2024) go further, specifying that network security controls must include mechanisms to detect anomalous configurations and unauthorized changes to network perimeters. An open port that wasn’t there last week is exactly the kind of anomaly the RTS has in mind.
Where Operational Resilience Breaks Down in Practice
A mid-sized German Sparkasse doesn’t need a novel attack to fail an examination – it needs a forgotten staging server. A common pattern: a load-balanced payment gateway gets a temporary debug port opened during a Q4 2025 incident, the change ticket closes, and nobody schedules the port closure. Six months later an examiner or a red team finds port 8080 exposed with a Jenkins instance still running default credentials.
That single miss touches three DORA pillars at once. It’s an ICT risk management failure (Article 6-9), it would trigger mandatory incident reporting if exploited (Article 19), and if Jenkins was managed by a third party, it implicates the third-party risk register under Article 28. This is exactly the kind of gap covered in how to decommission old servers without leaving ports open – decommissioning isn’t a one-time task, it’s a control that has to survive staff turnover and incident response chaos.
A related and more damaging misconception: operational resilience is treated as an application-layer problem. Firewalls get audited, WAFs get tuned, but nobody asks what’s actually listening on the public IP right now versus what the architecture diagram says should be there. Firewall rule review confirms intent; it doesn’t confirm reality. A misapplied security group in AWS or a NAT rule left over from a migration will happily contradict the documented rule set for months.
Busting the “We Have a Firewall, So We’re Covered” Myth
This is the single most common misconception among IT leads facing their first DORA resilience testing cycle: a properly configured firewall is treated as equivalent to continuous monitoring. It isn’t, and examiners under the RTS on ICT risk management tools have started calling this out directly.
Firewalls encode intended state. They don’t tell you when a cloud auto-scaling event spins up a new instance with a default security group, when a developer opens port 5432 on a database instance to debug something on a Friday afternoon, or when a third-party SaaS integration silently adds an outbound listener for a webhook callback. None of that shows up in a firewall rule review unless someone is actively scanning the external attack surface and diffing it against a baseline.
An experienced SOC analyst treats the firewall configuration as the hypothesis and an external scan as the test of that hypothesis. When the two disagree, the scan wins, because it reflects what an attacker on the internet actually sees. This distinction is covered at length in why external port scans beat internal security checks, and it’s the crux of what separates paper compliance from operational resilience under DORA.
Building a Resilience Testing Program Around Exposed Services
DORA’s Chapter IV requires proportionate testing – basic entities need annual vulnerability assessments and scenario-based testing, while entities designated for advanced testing (generally larger banks and critical infrastructure providers) must run threat-led penetration testing (TLPT) at least every three years, aligned with the TIBER-EU framework.
A workable program for the basic tier looks like this in practice:
– Establish a documented baseline of every port and service each critical function is permitted to expose, tied to a named owner
– Run continuous external scans against production and staging ranges, not quarterly snapshots
– Alert on any deviation from baseline within hours, not at the next audit cycle
– Feed confirmed findings into the incident classification process under Article 19’s significant-incident thresholds
– Retain scan history for the full audit trail examiners will request during on-site inspections
Baselining is the part most teams underinvest in. Without a documented “should be open” list, every scan result becomes a judgment call about severity, which is how alert fatigue sets in and real findings get triaged as noise. The approach in how to create port security baselines for your servers maps directly onto what an examiner will ask to see: not just that you scan, but that you know what “normal” looks like well enough to spot what isn’t.
Mapping Third-Party Risk to Network Exposure
Article 28 through 30 of DORA impose direct obligations around ICT third-party providers, including a requirement to maintain a register of information covering every contractual arrangement. What frequently gets missed is that this register needs to extend to the network footprint those providers introduce – a managed database vendor, a payment gateway integration, a cloud WAF provider all add exposed services that the financial entity remains accountable for under the regulation, even though a vendor operates them.
A practical control here is treating vendor-introduced ports the same as internally managed ones inside the same monitoring program, with clear ownership recorded for each. Without that, incident response during an actual event stalls while people figure out who even has admin access to the box that’s compromised.
Frequently Asked Questions
Does DORA apply to smaller fintechs and payment institutions, or only large banks?
DORA applies proportionally but broadly – it covers banks, insurers, payment institutions, e-money institutions, investment firms, crypto-asset service providers under MiCA, and their critical ICT third-party providers. A ten-person payment startup with an EU passporting license is in scope, though the intensity of required testing (basic vulnerability assessment versus full TLPT) scales with size and criticality.
What counts as a reportable incident under DORA if it stems from an exposed port?
Article 19 requires reporting of major ICT-related incidents based on criteria set by the ESAs, including client impact, duration, and data loss. An exposed port itself isn’t reportable, but successful exploitation that disrupts a critical function or exposes data typically crosses the significant-incident threshold and triggers the initial notification requirement within 4 hours of classification.
How does DORA resilience testing differ from a standard penetration test?
Standard pentests are often scoped narrowly and run once a year for compliance. DORA’s TLPT requirement under TIBER-EU is intelligence-led, simulates real threat actor behavior against live production systems, and must be repeated at least every three years for entities designated by their competent authority – it’s meant to validate actual resilience, not just find vulnerabilities on a list.
Operational resilience under DORA isn’t a document you file once – it’s the gap between what your architecture diagram claims is exposed and what’s actually reachable from the internet on any given Tuesday. Close that gap with continuous, baselined external monitoring rather than annual snapshots, and most of the DORA testing and incident-reporting obligations become far easier to satisfy because there are simply fewer surprises to report.