EU DORA Compliance
TThe EU Digital Operational Resilience Act (DORA) requires financial entities to test the resilience of their ICT systems.
Learn how ImmuniWeb supports DORA's vulnerability assessments and penetration testing.
EU Digital Operational Resilience Act (DORA) Compliance
What Is the EU DORA?
DORA creates a single, EU-wide framework for the digital operational resilience of financial entities. It is built on five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing.
The testing pillar is central to application security: entities must run a resilience-testing programme that includes vulnerability assessments and penetration testing, and the most significant entities must carry out advanced Threat-Led Penetration Testing (TLPT).
See how ImmuniWeb supports DORA's resilience testing - vulnerability assessments and penetration testing of your financial applications.Request a demo· or run a free Community Edition test.
Who Must Comply with DORA?
DORA applies across the EU financial sector:
- Financial entities- banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, trading venues and more.
- Critical ICT third-party providersserving the financial sector, which fall under an oversight regime.
- Entities of varying size - with proportionality applied to smaller entities.
The web, mobile and API applications these entities run are squarely within the scope of DORA's resilience testing.
Key DORA Requirements for Application Security
DORA's digital operational resilience testing pillar drives application-security work:
- Resilience testing programme (Articles 24-25): regular testing of ICT systems, including vulnerability assessments and scans and penetration testing, with findings remediated.
- Threat-Led Penetration Testing (Articles 26-27): advanced, intelligence-led penetration testing (based on TIBER-EU) for significant entities, at least every three years.
- ICT risk management & third-party risk: : identify and protect ICT assets, including those run by providers.
DORA Resilience-Testing Requirements in Depth
Digital Operational Resilience Testing (Articles 24-25)
DORA requires a risk-based testing programme covering ICT systems and applications, including vulnerability assessments, scans and penetration testing. For internet-facing financial applications, that means regular web and mobile penetration testing and scanning, with remediation and re-testing.
Threat-Led Penetration Testing (Articles 26-27)
Significant financial entities must perform advanced Threat-Led Penetration Testing - realistic, intelligence-led attacks against live production systems, based on the TIBER-EU framework, at least every three years. Manual, expert-led penetration testing is core to meeting this requirement.
Common Web & Mobile Application Risks to Address
The vulnerabilities DORA's testing programme aims to find in financial applications map closely to the OWASP Top 10:
- Broken Access Control —users reaching data or actions they should not.
- Cryptographic Failures — weak or missing encryption exposing sensitive data.
- Injection — SQL, command or other injection via unvalidated input.
- Insecure Design — missing security controls by design, not just by bug.
- Security Misconfiguration — default, incomplete or unsafe configuration.
- Vulnerable & Outdated Components — unpatched libraries and frameworks.
- Identification & Authentication Failures —weak login, session or credential handling.
- Software & Data Integrity Failures — untrusted updates, insecure CI/CD pipelines.
- Security Logging & Monitoring Failures — attacks going undetected.
- Server-Side Request Forgery (SSRF) — the server tricked into making malicious requests.
For mobile apps, the OWASP Mobile Top 10 is the equivalent reference (insecure data storage, insecure communication, weak cryptography, and so on). Reliably finding these issues requires testing the running application, not just a documentation review.
How to Approach DORA Resilience Testing with ImmuniWeb
- 1. Map ICT assets. Inventory internet-facing financial apps and APIs with ImmuniWeb Discovery.
- 2. Run vulnerability assessments (Art 24-25) with Neuron scanning.
- 3. Penetration test web and mobile applications with On-Demand and MobileSuite.
- 4. Support TLPT (Art 26-27) with expert-led, intelligence-driven manual testing.
- 5. Remediate and retest with actionable, zero-false-positive reports.
- 6. Test continuously with Continuous in CI/CD to keep resilience current.
How ImmuniWeb Helps You Achieve DORA Compliance
ImmuniWeb supports DORA's resilience-testing pillar with the vulnerability assessments and penetration testing the regulation requires.
| Requirement | What it requires | ImmuniWeb products |
|---|---|---|
| Resilience testing (Art 24-25) | Vulnerability assessments, scans and penetration testing. | On-Demand, Neuron, Continuous |
| TLPT (Art 26-27) | Advanced threat-led penetration testing. | On-Demand, MobileSuite |
| ICT asset & third-party risk | Map and monitor the external attack surface. | Discovery (ASM / Dark Web) |
ImmuniWeb On-Demand and MobileSuite deliver manual web and mobile penetration testing (including support for TLPT-style engagements); Neuron and Neuron Mobile provide automated scanning; Continuous embeds testing into CI/CD; and Discovery maps your attack surface for ICT and third-party risk.
DORA vs International Frameworks
If you already work to international standards, the same ImmuniWeb testing supports all of them:
| Framework | Application-security angle | How ImmuniWeb maps |
|---|---|---|
| EU DORA | Resilience testing: vuln assessments, pentest, TLPT | Web/mobile pentest, scanning, ASM, TLPT support |
| EU NIS 2 | Article 21 risk-management measures | Same testing supports both |
| ISO/IEC 27001 | Annex A technical controls | Testing as control evidence |
| PCI DSS 4.0.1 | Req 6 & Req 11 | Web app pentest + scanning |
Penetration Testing vs Security Scanning
Both are needed. Automated scanning (DAST) gives broad, frequent coverage and is ideal for continuous testing in CI/CD; manual penetration testing finds business-logic and complex vulnerabilities that scanners miss and produces the depth auditors and regulators expect. Combine continuous scanning with periodic manual penetration testing, and re-test after significant changes.
Compliance Checklist (Application Security)
- Inventory of internet-facing financial apps and APIs
- Vulnerability assessments and scans performed regularly (Art 24-25)
- Penetration testing of web and mobile applications
- Threat-Led Penetration Testing for significant entities (Art 26-27)
- Findings remediated and re-tested; evidence retained
- Testing embedded in CI/CD for ongoing resilience
- ICT third-party and attack-surface risk monitored
Why DORA Compliance Matters
DORA is directly supervised by financial regulators, and competent authorities can impose administrative measures and penalties for non-compliance. Resilience testing is an explicit, recurring obligation - not a best-effort exercise.
Because web, mobile and API applications are a primary attack surface for financial institutions, demonstrable testing is one of the most direct ways to meet DORA's testing pillar and reduce operational risk.