DORA compliance EU
financial sector supply chain security
DORA vulnerability management
ICT third-party risk
DORA third-party risk management
digital operational resilience act
outsourced software security SLAs
DORA vendor compliance
DORA audit trails
ICT service provider risk
financial sector TPRM
DORA regulatory compliance
tracking supplier security SLAs
DORA continuous monitoring
EU financial regulation 2026
InstaSLA DORA compliance
managing ICT third-party risk
third-party vulnerability SLAs
outsourced dev security SLAs
DORA supply chain risk
DORA Compliance in 2026 Enforcing Supplier Security SLAs in Finance
Back to blog
The Weight of ICT Third-Party Risk Management
The Penalty Regime — and a Correction Worth Making
Who's Now Under Direct EU Oversight: The First 19 CTPPs
DORA Vulnerability Management: The Outsourcing Challenge
Enforcing Supplier Security SLAs with InstaSLA
Where Enforcement Actually Stands in 2026
The Path Forward: Operationalizing Resilience
Sources
DORA Compliance in 2026: Enforcing Supplier Security SLAs in Finance
The EU's Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — has been fully applicable since January 17, 2025. But 2025 and 2026 have not been the same regulatory environment. Supervisors across the EU treated 2025 largely as a transition year: readiness assessments, supervisory dialogue, and remediation letters rather than formal sanctions. That tolerance period is over. National competent authorities are now conducting active enforcement reviews, cross-checking Registers of Information, and — according to industry trackers — preparing the first wave of formal fines for the second half of 2026. Static PDF policies and annual vendor questionnaires no longer satisfy supervisors who expect continuous, timestamped evidence that ICT risk, resilience testing, and third-party controls are actually operating.
This shift lands hardest on outsourced software development. Financial institutions lean on external vendors, microservices, cloud providers, and third-party APIs to stay agile — but under DORA, delegating development does not delegate risk. Financial entities remain accountable for their suppliers' security posture, which means the vulnerability-management SLAs governing outsourced codebases need to be enforced, not just written down.
The Weight of ICT Third-Party Risk Management
DORA is built on five pillars, but the one drawing the most 2026 scrutiny is ICT third-party risk management (Chapter V, Articles 28–44). It requires financial entities to map their entire ICT supply chain and identify every system supporting a "critical or important function" — under Article 3(22), any activity whose disruption would materially impair the entity's soundness, continuity, or regulatory compliance.
To evidence this, financial entities must maintain a Register of Information: a living inventory connecting providers, services, contracts, and the functions they support. This is the single artifact supervisors check first. Because DORA is a regulation rather than a directive, the core obligation is EU-wide, but the register's submission cadence and exact format are set by each national competent authority rather than a single harmonized calendar date — treat it as a standing national-supervisor obligation, not a one-time annual filing.
The European Supervisory Authorities (EBA, EIOPA, ESMA) also require entities to tier vendors by criticality and apply continuous — not point-in-time — monitoring to providers touching critical systems, verifying that vendors meet the security, resilience, and incident-reporting terms baked into their contracts.
The Penalty Regime — and a Correction Worth Making
Most DORA explainers online repeat a specific figure: fines "up to 2% of total annual worldwide turnover" (sometimes "up to 10% for serious breaches") for financial entities. That figure does not actually appear in DORA. A close read of the Regulation turns up only two mentions of turnover at all — the micro-enterprise definition in Article 3, and oversight fees in Article 43 — and neither is a penalty provision.
What Article 50 actually says is narrower: it requires Member States to ensure penalties for financial entities are "effective, proportionate and dissuasive," and stops there. No amount, no percentage, no EU-wide ceiling. The exact monetary exposure — and whether it's turnover-based, a fixed cap, or both — is set by each national regime, and national ceilings genuinely vary (analysis by DLA Piper found turnover-based caps ranging roughly from 5% in Spain to 10% in Sweden, layered with fixed caps from around €2 million to €20 million depending on the member state). Article 50(5) similarly leaves individual liability for management-body members to national law, rather than a fixed EU-wide number — figures like "€500,000" or "€1 million" circulating online are national or illustrative, not statutory EU maximums.
The "2%" figure most likely migrated from a neighboring regulation: NIS2 (Directive (EU) 2022/2555), Article 34, which does set an EU floor of at least 2% of worldwide annual turnover or €10 million (whichever is higher) for essential entities. DORA and NIS2 share a legislative vintage and subject matter, and DORA operates as lex specialis over NIS2 for in-scope financial entities — which is probably how the number crossed over in so much secondary commentary.
Where DORA does legislate a specific percentage is for Critical ICT Third-Party Providers (CTPPs) under the direct oversight regime:
Periodic penalty payments up to 1% of average daily worldwide turnover (calculated on the preceding business year), charged daily until compliance, for a maximum of six months (Article 35(7)–(8)).
Separate fixed penalties and business restrictions can apply depending on the severity and duration of non-compliance.
In short: enforceable, real, and severe — but the specifics depend on which regime (national DORA transposition vs. the EU-level CTPP oversight framework) is doing the penalizing, not a single uniform EU-wide percentage.
Who's Now Under Direct EU Oversight: The First 19 CTPPs
On November 18–19, 2025, the ESAs (EBA, EIOPA, ESMA) published the first official list of Critical ICT Third-Party Providers designated under Article 31 — a concrete, checkable fact that didn't exist when earlier drafts of this kind of article were written. The 19 providers include the European arms of Amazon Web Services, Microsoft, Google Cloud, IBM, Oracle, SAP, Deutsche Telekom, Bloomberg, the London Stock Exchange Group, Orange, and Tata Consultancy Services, among others — selected via a methodology assessing systemic impact, substitutability, and concentration risk, drawing on the same Registers of Information financial entities were required to submit.
Designation brings those providers under direct joint supervision by the ESAs — Joint Examination Teams review their governance, subcontracting chains, and resilience practices, and each CTPP must appoint an EU coordination point and pay annual oversight fees. Two things worth noting for compliance officers: the list is refreshed annually, so it isn't static, and designation is not a substitute for a financial entity's own due diligence — firms remain fully accountable for their outsourcing arrangements regardless of whether their vendor now also answers to the ESAs directly.
DORA Vulnerability Management: The Outsourcing Challenge
When a financial entity outsources software development, the vendor's code — and its dependencies, open-source libraries, and vulnerabilities — becomes part of the entity's own environment. Periodic scanning followed by ad-hoc developer ticketing doesn't hold up under DORA's incident classification and reporting regime.
Article 19, sharpened by the implementing technical standard (RTS (EU) 2025/301), sets a genuinely tight cascade once an incident is classified as "major" under Article 18's criteria: an initial notification within 4 hours of classification (and no later than 24 hours from the entity becoming aware of the incident), an intermediate report within 72 hours of that initial notification, and a final report within one month of the latest intermediate update. If a vendor introduces a critical vulnerability into an application supporting a critical function, there is no multi-week grace period once that vulnerability escalates into a major incident — the clock starts at classification, and classification itself has to happen without undue delay.
Article 30 requires that contracts for critical or important functions include termination rights, minimum notice periods, and a documented exit strategy with a mandatory transition period — this is a mandatory contractual clause, not an automatic statutory trigger DORA pulls on the entity's behalf. To actually use that termination right — or avoid needing to — compliance officers need auditable data: exactly when a vulnerability was introduced, when it was flagged, and whether it was remediated inside the contractual SLA. That's an operational shift from passive vendor management to active, evidenced SLA enforcement.
Enforcing Supplier Security SLAs with InstaSLA
To meet this bar, IT risk and compliance officers are replacing spreadsheets and manual ticketing with centralized SLA tracking platforms like InstaSLA, which turns vulnerability tracking from a manual chore into a continuously auditable discipline. A few notes on how this kind of tooling maps to DORA's actual requirements (as opposed to requirements sometimes attributed to DORA that it doesn't itself specify):
Continuous monitoring of the provider's security posture. DORA requires ongoing, not point-in-time, third-party monitoring. As an outsourced team commits code, automated scanners identify vulnerabilities; InstaSLA maps each finding to the vendor, repository, and business function it touches — feeding directly into the Register of Information's living risk picture.
Risk-based SLA enforcement. DORA requires risk-based assessment of vulnerabilities but doesn't itself prescribe specific remediation-hour SLAs — those are operational commitments a financial entity sets contractually with its vendors, informed by the criticality of the affected system. A compliance team might reasonably set a 24-hour internal SLA for flaws in payment-critical code and a 14-day SLA for a low-risk internal dashboard; InstaSLA enforces whatever thresholds the entity has actually contracted for, and escalates before a deadline lapses rather than after.
Evidencing incident classification and remediation. Given the 4-hour/72-hour/1-month cascade under Article 19, an incident process needs exact timestamps for detection, classification, notification, and remediation. InstaSLA generates an immutable log for each tracked vulnerability — detection time, risk classification, assigned SLA, and remediation timestamp — which is the kind of evidence a supervisor or auditor will ask for first.
Backing contractual terminations with data. Exercising an Article 30 termination right is a legal procedure that needs hard evidence, not a subjective complaint. A historical performance baseline — showing a vendor has repeatedly left critical vulnerabilities unpatched past agreed SLAs — turns third-party risk management into an objective, data-driven basis for invoking exit clauses.
Where Enforcement Actually Stands in 2026
It's worth being precise about where the "enforcement year" narrative stands rather than treating it as a settled fact. Industry surveys taken at the end of 2025 (widely attributed to Deloitte) put full DORA compliance at only around 50% of financial institutions, with a further chunk pushing their target into 2026. National authorities that spent 2025 issuing remediation letters — commonly with 60-day windows for incomplete Registers of Information — are now running formal supervisory reviews, and the ECB has folded DORA into its 2025 and 2026 SREP cycle for significant credit institutions. Multiple compliance trackers expect the first formal administrative fines to land in the second half of 2026, targeting entities that show no demonstrable compliance effort rather than firms with good-faith gaps.
The Path Forward: Operationalizing Resilience
In 2026, the European financial sector can't treat DORA as a checkbox exercise completed once at go-live. The regulation requires that digital resilience be governed, tested, and embedded into daily workflows — and outsourced software development is one of the largest surfaces for systemic risk in that picture. Without automated enforcement mechanisms, financial entities risk falling behind the speed of modern software delivery, accumulating unpatched vulnerabilities, and facing penalties that — however they're finally calculated under national law — are designed to be genuinely painful.
Platforms like InstaSLA won't make the underlying legal exposure disappear, but they close the gap between third-party development velocity and what regulators actually want to see: vulnerability tracking, enforced remediation timelines, and an audit trail immutable enough to survive a supervisory review.
Sources
Regulation (EU) 2022/2554 (DORA) — official text, Article 30
DORA Penalties and Fines 2026: What Happens If You're Not Compliant? — Regulation DORA
DORA Penalty Regimes: Overview of Divergence Among Member States — DLA Piper
EU regulators designate critical ICT third-party providers under DORA — Lexology
EU names 19 'critical' tech providers under DORA — FStech
AWS designated as a critical third-party provider under EU's DORA regulation — AWS
DORA reporting deadlines: the 4-hour rule for major ICT incidents — Horizon Scanner
Article 19 DORA — Reporting of major ICT-related incidents — Luxgap
DORA Compliance Guide: Requirements & Deadlines 2026 — Surecloud
Top comments (0)