DORA: What Is It, How Does It Compare to NIS 2, and How Will It Be Regulated?

Andrew Pattison has 30 years’ experience in information security and risk management, having worked in GRC (governance, risk and compliance) since 1994. He also holds an MSc in Information Systems Management, as well as CISM® and CRISC® certifications.

Now, he’s the head of GRC consultancy at IT Governance Europe, where, among other responsibilities, he leads product development relating to DORA (the Digital Operational Resilience Act).

In this interview

  • What DORA is
  • The difference between DORA and NIS 2
  • The importance of risk management in both NIS 2 and DORA
  • What the one, three or five DORA pillars are (depending on how you count them)
  • How DORA will be regulated, and whether non-EU organisations have to comply with it

What have you been up to recently?

I’ve been working a lot with DORA, or the ‘Digital Operational Resilience Act’. This is an incredibly exciting thing, and it’s nice to see more hits on this regulation when you google for ‘DORA’, as opposed to hits on Dora the Explorer.

But the name is interesting – DORA calls itself an ‘Act’ but is actually a regulation. So, in terms of its impact or regulatory position, it’s a bit like the GDPR [General Data Protection Regulation].

In other words, DORA doesn’t need to be transposed into national law for each of the 27 member states. From 17 January 2025, the Regulation has direct legal weight throughout the EU.

What’s DORA about?

DORA relates to operational resilience for financial services operating in the EU.

Resilience is a concept that’s been gaining traction in the EU for a while now, particularly for critical national infrastructure. The NIS Directive – soon to be replaced by NIS 2 – is a good example.

It’s this idea that if your systems are disrupted, whether by a cyber attack or anything else, critical services across the EU can continue to function – in the case of DORA, specifically financial entities and their ICT supply chains.

But at its core, DORA is all about risk and proportionality. That’s nothing new – the NIS Directive [and NIS 2] does the same, as does ISO 27001.

Interviewer note

Andrew has previously talked about how ISO 27001 can help simplify DORA compliance, because “ISO 27001 gives organisations the structure and the building blocks to enable them to comply with DORA, while taking that risk-based approach so fundamental to the Regulation.”

In a different interview, he talked about how to conduct ISO 27001 risk assessments in a simple and pragmatic way.

Andrew’s knack for simplifying the complex is a big reason I always enjoy chatting to him.

How does DORA differ from the NIS Directive and NIS 2?

Fundamentally, not all that much.

The point of NIS 2 [compared to the first NIS Directive] was to simplify implementation. The NIS Directive was very inconsistently implemented across the EU. NIS 2 tries to make things simpler by using terms like ‘essential’ and ‘important entities’.

DORA makes implementation simpler still by being a regulation, and not a directive. And the EU regulators could have made things simpler still by including extra requirements for financial entities [DORA’s scope] in NIS 2 so that you didn’t need an entirely new law.

It may have been to ensure that DORA could be directly enforced at member state level, but then I wonder why NIS 2 wasn’t introduced as a regulation.

Could you elaborate on those extra requirements?

Both NIS 2 and DORA are about managing risk. Along with incident reporting and business continuity.

DORA takes things a step further by requiring operational resilience. It goes beyond business continuity because it’s a lot more proactive:

  • Operational resilience is about being able to carry on as normal, even if you’ve suffered an incident.
  • Business continuity is more about continuing core activities while dealing with that incident.

Here’s a concrete example: DORA requires threat-based testing every three years. That goes beyond just probing for vulnerabilities in your networks and systems: it actively considers whether someone would exploit them based on your threats.

Whereas standard penetration testing only runs standard scans, etc., looking for known vulnerabilities. The tester will also try to exploit them as a proof of concept, but not while actively taking your threats into account. Standard penetration testing is great in many scenarios – but it’s not operational resilience.

As to which is the better for a given organisation, assuming it isn’t legally obliged to be resilient, this always comes down to risk. At its essence, everything in information or cyber security is about risk. Risk treatments and other measures should always fall out of that.

Do risk right, then everything else should automatically follow. It’s for good reason that risk management is a key ‘pillar’ in DORA.

What are the DORA pillars?

There’s a bit of controversy over that.

You could talk about just one pillar: risk management.

Others refer to three: risk management, incident response and ICT supply chain security.

When you go by the chapters in the Regulation itself, there are five pillars:

  1. Risk management
  2. Incident response and reporting
  3. Digital operational resilience testing
  4. ICT third-party risk management
  5. Information and intelligence sharing

However you count the pillars, organisations must report incidents and share information. Supply chain security is also a big one, which we’ve already discussed.

How will DORA be regulated?

By the competent authority in each member state. Which is where things can get tricky.

Even though this is a regulation, so directly applicable in each member state, each regulator will interpret things a little differently. We’ll just need to wait for them to start enforcing to find out the specifics around regulation.

As to the fines themselves – these are supposed to be “dissuasive”. So, they can potentially be very large, but we won’t know exactly until an organisation is fined under DORA.

Does DORA affect organisations outside the EU?

It may do. For example, if you’re a UK financial services provider with a part of your business, or a subsidiary, in the EU, you must meet the DORA requirements.

You must also meet them if you’re supplying ICT services to EU financial institutions. If nothing else, those institutions will be contractually enforcing this, as that’s a pretty big DORA requirement – one of its key ‘pillars’, in fact.

Organisations have to understand that outsourcing – like by using ICT services – isn’t making the risk someone else’s problem. You’re sharing the risk. You’re changing its nature. DORA makes very clear that the organisation is still accountable for it – which, of course, it is.

Andrew went into more detail in this interview.

Still have more DORA questions?

We’re always happy to help! Please get in touch, and we’ll get back to you as soon as possible.

Making risk assessment easy

Clunky spreadsheets are a thing of the past. Instead, save time and money by using CyberComply for your risk assessments.

This SaaS software – with its intuitive, easy-to-use risk manager tool – is specifically designed to help quickly identify and treat data security risks before they become critical concerns.

Speed up your risk assessments by up to 80% with CyberComply.

Take advantage of its built-in control sets from a large range of best-practice standards, including ISO 27001. CyberComply also makes keeping track of your data security compliance requirements easy.

We hope you enjoyed this edition of our ‘Expert Insight’ series. We’ll be back soon, chatting to another expert within GRC International Group.

In the meantime, why not check out our previous interview with Andrew on using ISO 27001 to simplify DORA compliance?

Alternatively, explore our full index of interviews here.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.