Expert insights, compliance guides, and the latest updates on digital operational resilience
The EBA opened a consultation on 26 August 2026 on draft RTS for the operational risk management framework under CRR3. Article 2 lets institutions rely on what they built for DORA. Here is the mapping, and the five things DORA does not give you.
For every DORA obligation, the article that imposes it and the document that proves it. A checklist built for review rather than for reassurance.
Article 9(4)(d) and Article 17 of RTS 2024/1774 make every production database change an evidence question. What a reviewer tests, and how to answer it.
DORA makes training compulsory twice: Article 13(6) for staff and Article 5(4) for the management body. Who is in scope, what evidence counts, how to build it.
Run an ISO 22301 BCMS? You are closer to DORA than you think. Clause-by-clause mapping, the deltas the standard leaves open, and the quick wins to close them.
Every entity has a list of critical or important functions. Almost none can show how each entry got there. A six-field record per function, including the ones you decided not to designate.
Identification comes before analysis. The four layers you need on paper, how granular to go, and why a mapping built from the CMDB upwards produces a register that fails its consistency checks.
Tolerance, MTPD and RTO answer three different questions, and setting them in the wrong order is why so many critical-function designations cannot be evidenced. How to write one that survives review.
No. The Commission set an indicative threshold: you only become the provider of a modified general-purpose model if your fine-tuning compute exceeds a third of the original training run. LoRA is not close. Here is what actually applies instead.
A model that quietly discriminates may not be a DORA major incident at all, and is squarely an AI Act serious incident. Two regulators, two triggers, two clocks. How to extend your DORA incident playbook rather than build a second one.
Most banks buy their scoring models and assume they are deployers with light obligations. Article 25 says otherwise: fine-tuning a bought model on your own loan book makes you its provider, with conformity assessment, CE marking and EU database registration.
The Council approved the Digital Omnibus on 29 June 2026 and the high-risk deadlines moved to December 2027. But the transparency deadline did not move at all, and the Omnibus quietly added two obligations. The calendar a bank should actually be working to.
An EU financial client just sent you DORA contract clauses or a security questionnaire. Here is what they must ask (Articles 28-30) and how to respond and win.
US, UK, Swiss or other non-EU financial firm? DORA may already apply to you - through EU branches, group entities or your EU clients. Here is how to tell.
Financial institutions using AI systems face simultaneous obligations under DORA and the EU AI Act. Here is how to map them efficiently and avoid duplicating compliance work.
When an AI can surface a 27-year-old vulnerability in hardened software, the question stops being “is our code secure?” and becomes “do we even know what is in it?” A Software Bill of Materials is now a frontline DORA control: here is how to operationalise it.
A frontier AI that finds thousands of zero-days, and the first AI-run cyber-espionage campaign against financial institutions, have put bank and insurer boards on edge. Here is what actually happened, and how DORA’s five pillars are built to answer exactly this threat.
DORA wants security and resilience designed in, not bolted on. A secure software development lifecycle. DevSecOps, bakes the controls, testing and evidence DORA expects into the way you ship software. Here is how the two line up.
DORA expects a credible, tested way to leave a critical cloud provider, and a clear view of concentration risk. Here is how engineering and procurement teams build exit strategies that are more than a clause on paper.
Your fourth parties are now in scope. DORA pushes ICT risk down the subcontracting chain, and a Software Bill of Materials (SBOM) is how engineering teams make that chain visible. Here is how supply-chain security maps to DORA third-party obligations.
DORA requires you to test resilience on critical systems, not assume it. Chaos engineering turns that obligation into evidence: deliberately injecting failure to prove your systems degrade and recover as designed. Here is how it maps to DORA Pillar 3.
DORA’s 4h/72h/1-month incident reporting and its evidence demands are far easier when monitoring and audit trails are built into your systems. Here is how to make detection, regulatory reporting and auditability automatic, not a scramble.
Resilience is an architecture decision long before it is a compliance one. Here are the design patterns (redundancy, isolation, graceful degradation, immutable backups, observability) that lower ICT risk and map directly onto DORA Articles 9 to 12.
Legacy systems are one of the biggest hidden DORA risks. This guide shows how application modernization, decoupling, cloud, observability, automated recovery: directly supports DORA Pillars 1 and 3, with a pragmatic roadmap.
If you build or sell software to EU financial entities, DORA reaches you through your clients. Here is exactly what software vendors must support (Article 30 clauses, audit rights, incident assistance, exit and subcontracting) and how being DORA-ready wins deals.
If you already run an ISO 27001 ISMS, it is the fastest roadmap to DORA. This guide maps DORA to ISO 27001:2022 control-by-control, shows exactly what the standard does not cover, and gives the priorities and quick wins to close the gap.
Almost every demanding obligation in DORA. TLPT scope, Article 30 contracts, the Register of Information, business continuity, keys off one defined term: the Critical or Important Function. Here is what Article 3(22) actually says, why CIF is the master switch, and a 5-step method to classify your functions defensibly.
DORA is not just for banks. Learn what Articles 28 to 30 require from ICT providers and software vendors, and how to turn the constraint into a commercial advantage.
BIA is the methodological engine behind a defensible CIF inventory. ISO 22317 service catalogue, 5-axis impact scoring, MTPD threshold, Article 3(22) gate.
Step-by-step methodology to build the DORA Register of Information (RoI). 9 templates, xBRL-CSV format, CIF flagging, 6-step playbook, common pitfalls.
DORA TLPT methodology: 5 TIBER-EU phases, Red/Blue/White team setup, 9-14 month timeline, EUR 270k-620k budget, vendor selection, attestation.
The Q1 2026 Register of Information submission is the most data-intensive compliance obligation under DORA, and the one regulators are scrutinising most closely. This guide covers the 15 templates, xBRL-CSV format requirements, country-specific deadlines, the most common errors from the 2025 first collection, and how to maintain a living register year-round.
The informal tolerance period that characterised 2025 DORA supervision is finished. National competent authorities are now conducting active enforcement reviews, cross-checking Register of Information data automatically, and issuing the first compulsion payments. Here is what changed, what regulators are prioritising, and what your institution needs to do now.
DORA sets no EU-wide maximum fine for financial entities: Article 50 hands the amount to national law, so your ceiling depends on your competent authority. Here is how enforcement actually works, and where the widely repeated "2% of turnover" figure comes from.
DORA mandates strict timelines for classifying and reporting ICT incidents. Missing a reporting window can trigger supervisory measures. Here is the complete breakdown of what is required.
DORA requires identified financial entities to conduct Threat-Led Penetration Testing every three years. TLPT covers your entire organisation, not just a single system. Here is what you need to know.
The second annual Register of Information submission is due March 2026. Nearly half of financial entities identified this as the single most challenging DORA requirement. Here is how to get it right.
Regulators are shifting from reviewing paperwork to demanding real-time proof of resilience. With only 50% of firms fully compliant, 2026 marks the start of active DORA enforcement across Europe.
Complete list of Critical ICT Third-Party Providers designated by ESAs under DORA. Who is on the list, what it means for contracts, and the oversight framework explained.
On November 18, 2025, the European Supervisory Authorities (ESAs) published the first official list of designated Critical Third-Party Providers (CTPPs) under DORA, including major cloud providers like AWS. Here's what this means for financial institutions.
With DORA now in full effect, non-compliance carries serious consequences. Learn about the penalty framework, enforcement mechanisms, and how to avoid sanctions under the Digital Operational Resilience Act.
The Eurosystem has updated the TIBER-EU framework to align with DORA's threat-led penetration testing (TLPT) requirements. Learn what this means for your testing program.
With DORA enforcement now active, financial institutions face significant penalties for non-compliance. Learn about the supervisory powers, penalty frameworks, and how to manage enforcement risk.
With the April 2025 deadline passed, financial institutions must now ensure their ICT service provider registers remain accurate and complete. Learn about ongoing obligations and best practices.
The European Commission and ESAs have issued important amendments to DORA technical standards. Stay informed about the latest regulatory changes affecting your compliance program.
Understand how to classify ICT incidents under DORA and meet reporting requirements. This guide covers incident thresholds, classification codes, and reporting procedures.
While DORA applies to all financial institutions, banks and insurance companies face different implementation challenges. Learn the sector-specific differences and requirements.
What's the difference between RTS (Regulatory Technical Standards) and ITS (Implementing Technical Standards) under DORA? This guide breaks down both standards and their implementation requirements.
Pillar 1 of DORA requires a comprehensive ICT risk management framework. Learn how to build one from scratch with practical examples and templates.
DORA creates specific requirements for cloud services, outsourcing partners, and critical third-party service providers. Learn what your institution must do to ensure compliance.
Small financial entities face unique challenges with DORA compliance. Learn how proportionality applies and practical steps to achieve compliance efficiently.
Using cloud services? Learn how DORA affects cloud adoption, what you need from your providers, and how to maintain compliance in multi-cloud environments.
DORA has been in force since January 2025. Financial institutions must now demonstrate full compliance. Here's what the regulation requires and where to start.
Can cyber insurance help with DORA compliance? Learn how insurance fits into your operational resilience strategy and what insurers now require.
DORA Pillar 4 introduces stringent requirements for managing ICT third-party service providers. Learn how to ensure your vendors are compliant.
Supervisory audits are coming. Learn how to prepare documentation, what auditors will look for, and how to demonstrate compliance effectively.
Both DORA and NIS2 aim to strengthen cybersecurity, but they have different scopes and requirements. Here's what you need to know about compliance with both.
DORA mandates strict incident reporting timelines and procedures. Learn how to establish compliant incident management processes.
DORA requires financial entities to conduct advanced threat-led penetration testing. Learn what TLPT involves and how to prepare.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.