8 min. read<\/p>\n
On 16 April 2026, the UK’s Financial Conduct Authority published new Operational Incident and Third-Party Reporting rules, marking the first post-DORA regulatory wave across Europe. The FCA is requiring financial institutions and their ICT third-party providers to adopt new classification and notification timelines that go further than DORA in both depth and scrutiny. In Brussels, preparations are simultaneously underway for a DORA evaluation due to feed into a review report by the end of 2026 \u2014 one that makes a tightening of requirements in 2027 increasingly likely. Security teams should not wait for DORA 2.0: they need to stress-test their architecture against the known gaps right now.<\/strong><\/p>\n Key Takeaways<\/p>\n Related<\/span>ASP.NET Core CVE: Compliance Implications under DORA and NIS2<\/a> \/<\/span> OT Security 2026: IEC 62443 and the Cyber Resilience Act<\/a><\/p>\n The Financial Conduct Authority published its Policy Statement on Operational Incident and Third-Party Reporting Rules on 16 April 2026. The core tightening is a new two-tier reporting obligation: every operationally significant ICT disruption above a quantified impact threshold must be reported as an Initial Notification within six hours, followed by a detailed post-incident analysis within 30 days. Notably, the third-party reporting element extends this further \u2014 financial institutions must now report not only their own incidents but also material incidents at their ICT third-party providers, where those incidents affect UK financial services.<\/p>\n DORA in its current form also requires incident reporting, but leaves the classification thresholds considerably more open to interpretation. The ESA RTS from 2024 define qualitative criteria, yet practice across the first 15 months shows that institutions in identical situations reach very different assessments. The UK has clearly taken note and quantified the classification catalogue in its successor framework.<\/p>\n For DACH financial institutions, the UK wave matters for three reasons. First, most major banks and insurers operate significant UK businesses and must implement the rules regardless. Second, the UK text effectively serves as a blueprint for the DORA review the European Commission is due to complete by end of 2026. Third, the UK thresholds set a new benchmark against which supervisors in EU member states will calibrate their expectations \u2014 well before any formal DORA revision arrives.<\/p>\n What is DORA 2.0?<\/strong> DORA 2.0 is not a enacted legal act but the industry shorthand for the anticipated revision of EU Regulation 2022\/2554. The European Commission is legally required to submit an evaluation of the DORA implementation by 17 January 2028. However, early ESA working documents already point to a tightening of Technical Standards in 2026 \u2014 particularly around incident classification, TLPT scoping, and ICT third-party risk. Institutions should treat the term as a placeholder for a combination of revised RTS and potential amendments to the regulation itself.<\/p>\n Anyone reviewing the first supervisory feedback from Germany, France and the Netherlands will find the same three gaps every time. These are the most likely focus of any DORA tightening to come.<\/p>\n Incident classification without consistency.<\/strong> The RTS define impact criteria qualitatively: customer impact, duration, data protection dimension, reputational effect. That sounds clean, but in practice it produces inconsistent decisions. Two institutions experiencing the same cloud outage frequently arrive at different classifications. Incident reviews have repeatedly shown cases where an event was classified internally as “major” but reported to BaFin as “significant” \u2014 because the reporting obligation kicks in earlier at the “major” level. The UK approach with hard thresholds is a direct answer to exactly this problem.<\/p>\n TLPT scoping too narrow.<\/strong> Threat-Led Penetration Testing is mandatory under DORA for systemically relevant institutions, and the TIBER-EU framework is the de facto standard. In the first TLPT rounds of 2025, many institutions narrowed the scope to their own digital channels. ICT supply chains were frequently excluded. ESMA flagged this in a Q1 2026 quarterly report, noting that future examinations must cover the entire critical ICT chain. This is technically a significant leap: running red-team scenarios against managed service providers and their infrastructure requires contractual frameworks and a willingness to cooperate that is rarely documented today.<\/p>\n ICT third-party registers incomplete.<\/strong> The DORA ICT register is, in theory, a comprehensive picture of all critical ICT services. In practice, sub-processor relationships are often not captured. The Commvault push to Google Cloud on 22 April is a good illustration: anyone currently listing Commvault as a backup provider in their register may now need to add Google Cloud as a sub-processor following the integration. When these shifts are not reflected in real time, a gap opens between operational reality and the register \u2014 one that will surface at the next examination.<\/p>\n \nAny institution maintaining an ICT register like an inventory list updated once a year has understood neither the UK rule nor the coming DORA tightening. Registers in 2026 are operational \u2014 or they are worthless.\n<\/p><\/blockquote>\n The European supervisory authorities EBA, ESMA and EIOPA published a joint evaluation of the first DORA application phase in early 2026. Their core findings largely align with those of individual national supervisors such as BaFin and the Dutch DNB. Three conclusions run consistently through all the reports.<\/p>\n First: reporting quality is uneven. For the same incident type, impact figures vary between institutions by a factor of three to five. This is less a problem of bad faith than one of methodology. The RTS define qualitative criteria without a concrete calculation model; incident managers at banks have no standardised template to work from. The result: supervisors struggle to draw cross-institutional comparisons, even though enabling exactly that is the point of a pan-European regulation.<\/p>\n Second: visibility into third parties almost always stops at the first tier. An institution knows its direct ICT service providers, but rarely the second or third layer. This runs counter to DORA’s intent \u2014 the regulation demands chain transparency down to critical sub-processors. Compliance practice has not caught up with the regulatory expectation. When a major incident at a sub-processor hits the bank, retrospective reconstruction is laborious at best, impossible at worst.<\/p>\n Third: TLPT findings are frequently treated internally as a one-off event. The RTS require that insights feed into ongoing risk analysis. In practice, they often end up in a thick report presented once to the board, without systematically informing architecture decisions thereafter. The learning effect falls well short of what the regulation envisioned.<\/p>\n Further tightening is coming, but not today. The useful response is not to wait, but to do targeted groundwork that makes sense regardless of the exact wording of a DORA 2 RTS. Five priorities that should be addressed in the next 120 days.<\/p>\n First: Unified Incident Taxonomy.<\/strong> Align internal classification with FCA thresholds, even if the institution does not operate in the UK. Quantitative criteria reduce variance between different incident managers and provide a defensible line of argument with supervisors. The effort: one week of workshops plus tooling adjustments.<\/p>\n Second: Expand the TLPT scope.<\/strong> When the next TLPT window arrives in 2026 or 2027, the ICT supply chain should be included. Concretely, that means explicitly incorporating at least one central managed service provider into the red-team scenario, with contractual consent. Even if DORA 2.0 does not yet require it, the insight gained for your own architecture is substantial.<\/p>\n Third: Keep the ICT register operational.<\/strong> Treat the register not as a compliance document but as a live database with automated integrations to contract management and CMDB. Every new ICT service provider onboarding should trigger a register update automatically. A quarterly review whenever changes occur in the sub-processor chain.<\/p>\n Fourth: Third-party monitoring.<\/strong> The UK rule requires reporting on incidents at third-party providers. That only works if the institution has active monitoring in place for its critical service providers \u2014 specifically: incident APIs, status-page scraping, and regular SOC coordination calls. Many institutions have this for their core systems, but not for sub-processors.<\/p>\n Fifth: Revise runbooks.<\/strong> The FCA’s six-hour reporting deadline is only realistically achievable if the internal runbook strictly defines the first 90 minutes. Any institution still debating who calls the BaFin hotline in the middle of a major incident will miss the deadline.<\/p>\n One detail that often gets lost in the debate: both DORA and the UK rule require no simultaneous public disclosure. The notification goes to the supervisor; communications with customers and press remain the institution’s own business. Confusing the two creates unnecessary reputational risk. For the three lines of defence, this means compliance, communications, and IT security must have clearly defined, non-overlapping roles in the incident response playbook. That sounds trivial \u2014 in practice, it is one of the most common sources of failure.<\/p>\n The discipline gap between DORA’s ambitions and actual implementation also explains why some institutions suddenly face disproportionately high remediation costs after a single incident. Those who write clean runbooks in advance and run tabletop exercises three or four times a year stay in the mid-five-figure range. Those who react only after a major incident has been documented can quickly find themselves paying several hundred thousand euros in external consulting fees, because every adjustment happens under time pressure.<\/p>\n Experience also shows that coordination with critical ICT service providers goes better when your own house has clean internal processes. A provider receiving three contradictory requests from a bank client about the same incident will become defensive and share minimal information. A bank client with a clear single point of contact and an unambiguous escalation path receives significantly more comprehensive cooperation. That is not a regulatory argument \u2014 it is operational experience, and it is frequently confirmed in informal conversations with supervisors.<\/p>\n For 2027 budget planning, a straightforward reality check is worthwhile. Institutions that have so far viewed their DORA architecture as a cost centre should use the next twelve months to make its operational value visible. A well-maintained ICT register integrated with CMDB and contract management is not just compliance work \u2014 it is the foundation for sound vendor management. An operationalised incident taxonomy accelerates post-mortems and reduces mean time to resolution. Frame that case compellingly, and phase-two budgets become considerably easier to secure.<\/p>\n There is no confirmed date. The European Commission must submit an evaluation by 17 January 2028. Initial RTS adjustments are likely between 2026 and 2027. The term DORA 2.0 is widely used in the industry to describe these refinements, but it is not an official legal act.<\/p>\n Only if an institution operates within the UK perimeter \u2014 in that case, yes. For purely EU-based institutions, they carry signal value. Supervisors on the continent align their expectations with the neighbourhood; FCA thresholds will likely be used as a benchmark for future RTS revisions.<\/p>\n Threat-Led Penetration Testing is a comprehensive red-team exercise conducted under real-world attacker conditions. The ECB’s TIBER-EU framework is the European standard. Scope, ruleset and execution are significantly more rigorous than conventional penetration tests. For systemically important institutions, TLPT is mandatory under DORA.<\/p>\n At minimum quarterly, and immediately whenever there are changes in the critical service provider chain. As a rule of thumb: when a new sub-processor is added, or an existing one migrates its infrastructure, the register must be updated in sync. Tools such as OneTrust or Archer offer dedicated workflows for this.<\/p>\n For a mid-sized financial institution, additional costs in the first year range from \u20ac150,000 to \u20ac400,000, depending on the maturity of existing ICT risk management. The bulk of the effort lies in extending the TLPT scope; taxonomy alignment accounts for the smallest share.<\/p>\n Editor’s Reading Tips<\/p>\n\n
What the UK FCA Changed on 16 April \u2014 In Detail<\/h2>\n
The Three Weaknesses DORA Audits Consistently Uncover in 2025\/2026<\/h2>\n
What the First ESA Assessments of 2025\/26 Soberly Reveal<\/h2>\n
Five Steps Security Teams Should Take Now<\/h2>\n
Frequently Asked Questions<\/h2>\n
When is DORA 2.0 coming?<\/h3>\n
Are UK rules binding for EU institutions?<\/h3>\n
What exactly is TLPT?<\/h3>\n
How often should the ICT register be updated?<\/h3>\n
What are realistic costs for the five steps?<\/h3>\n