DORA Article 24 pentest requirements 2026 — the complete guide

What DORA actually mandates for pentesting

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) entered into force on January 17, 2025. It binds every EU-regulated financial entity and their critical ICT third-party providers. Two articles cover penetration testing:

• Article 24 — annual ICT security tests. Mandatory for all DORA-scoped entities. Methodology is open: vulnerability scans, source-code review, scenario-based tests, penetration tests. Annual minimum cadence. Documented remediation proportionate to risk.
• Articles 26–27 — Threat-Led Penetration Testing (TLPT). Triennial. Mandatory only for significant entities (EBA / ECB criteria). Closed-box methodology, prior authority notification, accredited test manager, strict confidentiality. TIBER-EU framework is the operational reference.

The 95% of EU financial entities — small banks, payment institutions, e-money institutions, insurance intermediaries, mid-market fintechs — fall under Article 24 only. Article 26 captures the top of the pyramid (significant banks, major insurance carriers, central counterparties).

Article 24 vs Article 26 — where SMEs land

Confusion between Articles 24 and 26 is the single most common DORA pentest mistake we see. The practical distinction:

If you don't know which one applies to you: the national competent authority (BaFin in Germany, AMF in France, AFM in the Netherlands, CONSOB / Bank of Italy, etc.) maintains the significance designation list. If you're not on it, you're Article 24.

In-scope assets, methods, and coverage

Article 24 doesn't enumerate test scope. The Regulatory Technical Standards on ICT Risk Management (RTS) and national supervisory practice fill the gap. Mainstream interpretation in 2026:

• Public-facing applications — every web app, API, customer portal, partner integration that handles customer data or financial transactions. Top priority.
• Internal critical systems — core banking, payment processing, KYC / AML, transaction monitoring. In scope, typically tested with broader-scope engagements.
• Third-party integrations — every external API the entity depends on. Findings against third-party components attribute the supplier under Article 28 (supplier register).
• Authentication endpoints — primary, second-factor, customer authentication, employee SSO. Mandatory coverage.
• Out-of-scope without explicit reason — internal documents systems, employee productivity tools, marketing infrastructure. Justify exclusion in the risk-based scoping memo.

SQUR's scope covers the first three buckets above for web + API surfaces. Internal network and infrastructure testing typically requires complementary network-validation tooling.

How often you need to test

Annual minimum is the directive. The 2026 enforcement reading is stricter:

• After every material change to critical ICT systems. Material is defined in Article 6: new public-facing endpoint, architecture migration, third-party-provider change, significant feature release.
• Sufficient evidence of recurring effectiveness assessment per Article 24(2) — auditors want a documented cadence, not just a single annual snapshot.
• Critical findings retested within 30 days of remediation (industry practice; not directive text).

SMEs with limited budget often interpret "annual" literally. The risk: an annual pentest finding lands in March, the application ships three releases through summer, and by the time the auditor opens the report in December, the evidence is stale. Quarterly is the practical floor for entities with active development. The €1,995-per-engagement model exists specifically to make quarterly viable at SME scale.

The evidence chain auditors actually check

"We have a pentest report" is no longer sufficient. The 2025–2026 audit pattern checks for the closed loop:

1. Identification — finding documented with severity, evidence artefact, affected asset.
2. Risk assessment — finding mapped to the entity's risk taxonomy; severity confirmed by the entity (not just the pentest provider).
3. Remediation plan — owner assigned, target date set, compensating control identified if remediation is delayed.
4. Remediation — actual fix implemented, evidence of the implementation (commit, config diff, deployment record).
5. Retest — provider re-runs the test, confirms the finding is closed.

Without the retest column, the evidence chain is incomplete. This is the most common DORA audit failure point we see — entities have findings, have remediation logs, but no documented retest. The SQUR report ships with retest as a first-class column for exactly this reason.

BaFin enforcement patterns (and what they reveal)

Three patterns from German DORA audits since 2025-01-17:

• Proportionality is operationalised, not abstract. "Angemessen und verhältnismäßig" (Article 24's "appropriate and proportionate") is read through MaRisk. Risk profile derives from complexity, criticality, data classification, threat landscape. Entities running non-trivial online frontends are held to concrete expectations beyond a generic vulnerability scan.
• Closed evidence chain is required. Identification → assessment → plan → fix → retest. Missing retest = incomplete evidence.
• Third-party findings flow into supplier register. Third-party component findings (Open Source dependencies, SaaS integrations, external APIs) must attribute to the relevant supplier under Article 28(3). The pentest report informs the supplier-risk review, not just the entity's own remediation backlog.

Other national authorities (AMF, AFM, Bank of Italy, CSSF) show similar patterns with national variation. The directive-text floor is universal; the enforcement texture varies.

What the report must contain

From practical audit experience:

1. Scope statement — assets tested, methodology, period, tooling.
2. Risk-profile rationale — why this scope matches the ICT risk profile (Article 6 reference).
3. Findings with CVSS — per finding: description, reproduction steps, impact, affected asset, evidence artefact.
4. Remediation guidance — concrete fix per finding, effort estimate, compensating control if applicable.
5. Status tracking — open / in-progress / closed.
6. Retest evidence — confirmation per closed finding.
7. Third-party findings separated — by supplier, with disclosure status.
8. Executive summary — one page, risk-trend vs. previous engagement.

How to meet Article 24 under €5K per engagement

The classic SME problem: budget supports €1,995–€5,000 per engagement, but the boutique pentest market starts at €10K. Three ways to bridge:

• SQUR autonomous pentest — €1,995 per engagement, 24 hours, audit-ready report. Quarterly cadence achievable on €8K annual budget.
• Boutique pentest annually + smaller cadence between — single annual €10K–€20K engagement augmented with internal vulnerability scans. Workable but creates the staleness problem above.
• Hybrid: SQUR quarterly + senior research on high-risk subscope annually — best posture if budget allows. Width from automation, depth from human research on the 20% of the application that holds 80% of risk.