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.
Conformité au Règlement européen sur la résilience opérationnelle numérique (DORA)
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.
- Gestion des risques ICT et risques tiers: : identifier et protéger les actifs ICT, y compris ceux exploités par des prestataires.
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)
Les entités financières d’importance doivent réaliser, au moins tous les trois ans, des tests d’intrusion avancés axés sur les menaces — des attaques réalistes, guidées par le renseignement, menées contre des systèmes de production actifs, conformément au cadre TIBER-EU. Les tests d’intrusion manuels, menés par des experts, sont essentiels pour répondre à cette exigence.
Risques courants des applications Web et mobiles à remédier
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 — des contrôles de sécurité manquants par conception, et non pas seulement par bug.
- Mauvaise configuration de sécurité — configuration par défaut, incomplète ou non sécurisée.
- Composants vulnérables et obsolètes — bibliothèques et frameworks non patchés.
- Échecs d'identification et d'authentification —gestion faible des connexions, des sessions ou des identifiants.
- Échecs d'intégrité des logiciels et des données — mises à jour non fiables, pipelines CI/CD non sécurisés.
- Échecs de la journalisation et de la surveillance de la sécurité — attaques non détectées.
- 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. Test de pénétration des applications web et mobiles avec On-Demand et 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 soutient le pilier des tests de résilience de la DORA grâce aux évaluations de vulnérabilité et aux tests d’intrusion requis par le règlement.
| Exigence | Ce que cela nécessite | Produits ImmuniWeb |
|---|---|---|
| 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 face aux cadres internationaux
Si vous respectez déjà des normes internationales, les mêmes tests ImmuniWeb les couvrent toutes:
| Framework | Perspective sécurité des applications | Comment ImmuniWeb s'aligne |
|---|---|---|
| EU DORA | Tests de résilience: évaluations de vulnérabilité, tests d'intrusion, TLPT | Web/mobile pentest, scanning, ASM, TLPT support |
| EU NIS 2 | Mesures de gestion des risques de l'article 21 | Les mêmes tests couvrent les deux |
| ISO/IEC 27001 | Annexe A: contrôles techniques | Tests comme preuve de contrôle |
| PCI DSS 4.0.1 | Exigences 6 et 11 | Web app pentest + scanning |
Tests d'intrusion vs scans de sécurité
Les deux sont nécessaires. Le scan automatisé (DAST) offre une couverture large et fréquente et est idéal pour les tests continus dans le CI/CD ; le penetration testing manuel trouve les vulnérabilités de logique métier et complexes que les scanners manquent et produit la profondeur attendue par les auditeurs et les régulateurs. Combinez le scanning continu avec du penetration testing manuel périodique, et re-testez après des changements significatifs.
Liste de contrôle de conformité (Sécurité des applications)
- 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.