What stakeholders ask about DORA and how to respond

Introduction

Digital resilience is more than an IT concern. With the introduction of the Digital Operational Resilience Act (DORA), it’s become a topic for everyone in financial services, from risk and compliance teams to board members, auditors, procurement leads, and even end customers.

In fact, 94% of organisations ranked DORA as a top digital resilience priority, yet 79% admitted they’re not fully ready to comply in a survey last autumn. That has put pressure on compliance and risk professionals to translate dense regulations into meaningful action plans, answers, and updates for multiple audiences.

With this blog, we will help you prepare for the questions each stakeholder group will ask about DORA. We’ll cover what they want to know, how to respond clearly, and how to use those moments to build trust and demonstrate you’re on track.

DORA in plain English

Let’s start with a simple summary of what DORA is.

DORA is the EU’s regulation for ensuring financial firms can withstand and recover from ICT disruptions. It applies to banks, insurers, pension funds, investment firms, and ICT service providers that support them. It came into force on 17 January 2025 and focuses on these five key areas:

1. ‍ICT Risk Management: Build frameworks, policies and internal controls to manage operational and cyber risks.
2. ‍ICT Third-Party Risk: Conduct due diligence, define exit strategies, monitor vendor risks, and manage contracts with ICT providers.‍
3. Resilience Testing: Regularly test your ability to detect, respond to, and recover from ICT-related incidents, which includes advanced Threat-Led Penetration Testing (TLPT) for critical entities.‍
4. Incident Reporting: Detect and classify ICT incidents and report major ones to regulators within defined timeframes.
5. Oversight of Critical ICT Providers: Regulators will directly supervise ICT providers that are critical to the financial system, with a “Lead Overseer” assigned to coordinate scrutiny.

One key distinction with DORA is its emphasis on “end-to-end digital resilience”. It’s not enough to only protect your systems. If your outsourced IT vendor goes down, DORA sees that as your risk, not just theirs.

DORA is also aligning operational resilience expectations across the EU. For many firms that operate in multiple member states, this alignment offers an opportunity to simplify and unify their approach to third-party risk and ICT incident response.

Now let’s explore how this translates into the questions you’ll face from stakeholders, and how to respond with clarity.

What the board will ask

What are our accountability and liability risks under DORA?

This is often the board’s first and most pressing concern: are we personally liable?

The answer is yes. DORA makes the “management body” legally responsible for overseeing ICT risk management. That means board members and senior executives must not only sign off on strategies but actively oversee implementation.

Regulators have the power to fine firms up to 2% of their annual global turnover for serious non-compliance. Individual directors can face personal fines of up to €1,000,000. In some jurisdictions, civil or even criminal liability is possible if board members neglect their oversight duties.

How to answer:

• Confirm that the board is fully educated on DORA and is ready to play its part in staying compliant.
• Reference your DORA implementation plan and how it clarifies who is responsible for what within leadership
• Highlight existing governance processes, such as cybersecurity updates at the board-level risk or audit committees
• Reassure them that accountability is shared and a part of day-to-day operations

This shows DORA isn’t a separate compliance task; it’s part of business resilience, and the board is already fulfilling its role.

Are we testing resilience, such as TLPT, and how often?

Board members may have seen headlines about DORA requiring rigorous testing, including TLPT, and want to know if you’re meeting expectations.

How to answer:

• Yes, we are testing our digital resilience regularly and have a structured plan for advanced testing.
• Most organisations must conduct yearly tests: this includes business continuity, disaster recovery, backup restorations, and tabletop exercises.
• For business entities deemed critical by the regulator, TLPT is required every three years. TLPT is a red-team exercise. In simpler terms, this is a “simulated” attempt to breach and compromise, or “hack into” a business to test the security capabilities. This is observed by regulators and conducted by certified testers.

An even simpler way to explain this would be to say:

"The TLPT is like a cyber fire drill, where ethical hackers try everything they can to break in, and we test our ability to detect and respond in real time."

Board reassurance comes from knowing that: you have a testing schedule in place, there is board-level visibility of test results, and you’re coordinating with regulators if TLPT applies

Some firms go a step further and assign a board-level sponsor for ICT resilience. If your company is one of them, now is the time to highlight it.

What regulators & auditors will ask

Can you show your ICT third-party risk governance and register?

Regulators and auditors will expect more than a list of vendors. They’ll want your DORA Register of Information: a structured inventory of all ICT third-party arrangements, showing how each one is managed.

You should be able to confidently say: “Yes, here it is.”

Your register should include:

• All ICT-related third-party contracts and providers
• Tiering or classification based on criticality and risk
• Details like business owners, renewal dates, risk scores, SLA terms, subcontractors
• Evidence of due diligence, risk assessments, and performance monitoring

This register must also be:

• Centralised and version-controlled
• Reviewed and updated regularly (e.g. quarterly)
• Accessible during audits

We suggest using dedicated tooling rather than spreadsheets. For guidance, see: Practical Tips for Implementing DORA’s Register of Information.

Also expect auditors to ask questions like: Who owns the register? How often is it updated? How is it linked to procurement, legal and risk processes?

A clean, complete register is your first line of defence in proving compliance. Bonus points if you can show the register is a part of day-to-day workflows, not just a static document.

How do we monitor concentration and critical service providers?

Regulators are deeply concerned about concentration risk, a potential threat that arises when an organisation relies heavily on a single vendor. For example, multiple functions relying on one cloud provider, or many vendors using the same subcontractor.

So, you need to show that you’ve identified critical ICT providers (those whose failure could severely impact your operations). Next, you should show these are flagged in your Register of Information and that you perform enhanced due diligence on them. Lastly, you show that you assess single points of failure across your supply chain (including fourth parties)

It also helps to visualise dependencies and scenarios: “If Provider A fails, X% of our digital services would be impacted. We’ve modelled alternatives and reviewed contract exit clauses.”

Want more depth? Read Mastering DORA Compliance.

Note: under DORA, the most critical providers may be subject to direct regulatory oversight via a “Lead Overseer.” Stay informed about which vendors fall under that category.

What customers & partners will ask

Can you prove due diligence on critical vendors?

Large enterprise customers or partner banks may not reference DORA by name, but their questions reflect its requirements. Expect questions like:

• How do you vet your ICT providers?
• Do you check your critical vendors regularly?
• Can you confirm your data centre provider has industry standards like ISO 27001 or SOC2?

How to answer:

• We have a clear vendor due diligence process, which is based on risk tiering. The more critical a vendor is, the stricter our oversight.
• All critical ICT providers undergo security, financial, and operational assessments
• We maintain and regularly update this information in our DORA Register of Information

Offer summaries or redacted copies of assessments where appropriate. Demonstrating that you take resilience seriously is a competitive advantage since it helps build trust with both customers and partners.

Many firms now include a section in client due diligence responses explicitly referencing DORA-aligned processes. This shows you’re ahead of the curve.

How do you report disruption and escalation metrics?

Customers want to feel confident that you’ll tell them quickly and clearly if something breaks. Depending on the type of customer they are, they may ask:

• If there’s a disruption, how will we know?  
• What are your uptime metrics?
• How do you classify incidents?

This is where you let them know you have a DORA-aligned incident response plan. Which means you classify incidents based on predefined impact thresholds, notify affected clients within agreed SLAs (e.g. 2 hours), and you track and report on metrics such as uptime, MTTR (Mean Time to Recover), and frequency of incidents

Transparency builds trust. A clear escalation and communication plan makes all the difference. Including a communication matrix or response timeline in onboarding packs can help establish clarity from the start.

What internal teams will ask

Who owns what in incident response and escalation under DORA?

When an incident hits, internal clarity matters. DORA expects defined roles and escalation protocols, and your teams want to know who does what and when.

The best way to tackle this is by maintaining a RACI matrix (Responsible, Accountable, Consulted, Informed) for incident response. This makes it clear what everyone’s roles are. Furthermore, you should then train IT, security, risk, compliance and comms teams on their specific roles and define ownership for classifying, reporting, and communicating incidents. Running tabletop exercises to rehearse your processes helps people further understand their roles in practice.

Use internal comms to reinforce: “Here’s what to do if you’re the first to spot something”, or “If you’re informed of an incident, here’s what happens next.”

DORA compliance works best when response roles are part of everyday training, not just policy documents.

Are we relying on manual processes or spreadsheets?

Your IT, risk and vendor teams may already be feeling the strain. DORA adds structure, but without the right tools, it can feel like extra admin.

A common reality: 73% of financial firms manage vendor risk with just two or fewer full-time staff, often across hundreds of vendors.

In an ideal situation, you would tell them that you’re actively investing in Third-Party Risk Management software that includes a DORA-specific framework, which means you can use tools like workflow automation for due diligence, reassessments, and contract renewals. And finally, incident tracking systems log escalation, resolution time, and regulatory reporting automatically.

This reduces human error, saves time, and improves audit readiness. For software tips, see: DORA Compliance for Software Providers.

Also, let teams know streamlining processes isn’t just for the sake of compliance; it helps reduce burnout, increase visibility, and respond faster in a crisis.

What to prepare now (and what can wait)

With 2025 around the corner, focus on what regulators and stakeholders will expect immediately, and schedule the rest in a phased plan.

Prepare now (High Priority):

• Build or update your DORA Register of Information
• Complete risk assessments for critical ICT providers
• Review contract clauses (audit rights, exit terms, subcontractor disclosure)
• Conduct at least one resilience exercise (e.g. incident simulation, failover test)
• Define and communicate your internal escalation protocols

Can wait (Next 3–6 Months):

• Tailor your processes based on the final Regulatory Technical Standards (RTS)
• Plan for TLPT if your entity is deemed critical (you’ll need regulator coordination)
• Update contracts for lower-risk vendors
• Explore joining cyber threat information-sharing groups
• Prioritise based on risk and regulatory impact. For a full checklist, visit 3rdRisk’s best practices hub.

Conclusion

DORA is raising the bar, and rightly so. Operational resilience is more than a “nice to have”. Whether it’s an outage, a cyberattack, or a supply chain failure, stakeholders expect financial services to keep running.

By anticipating what each stakeholder will ask, and preparing strong answers with real evidence, you’re not just meeting regulatory expectations, you’re showing leadership. A solid DORA Register of Information, clear roles, tested plans, and structured oversight help you demonstrate that you’re not only compliant but truly resilient.

If you’re looking for a way to bring all these threads together, from stakeholder engagement to vendor oversight, consider mapping your resilience strategy to the five pillars of DORA. It’s a simple framework that can turn regulatory noise into clear, achievable actions.

Next time someone asks, “Are we ready for DORA?”, you can say more than just “we’re working on it”. You can say, “Here’s what we’ve already done,  and here’s what comes next.”

If you're ready to take control of your DORA compliance and discover our framework, book a demo with us today.