NIS2 and DORA Compliance for Security Teams

NIS2 and DORA compliance can look like two separate projects, but they have a lot in common. Both ask you to know where your risk is, fix what matters, report problems on time, and show what you did.

If you run security in-house, that is one environment to get right. If you run an MSSP, it is the same work across every client you serve. Either way, this guide explains what each regulation asks for, where they overlap, and how to handle both together.

What Is NIS2 and Who Must Comply?

NIS2 is the European Union’s cybersecurity law for essential and important services. It replaces an earlier directive from 2016, widens the list of sectors it covers, and has applied since October 2024, once each member state wrote it into national law. The aim is straightforward. It lifts the level of security across the organizations that daily life depends on, and it makes sure serious incidents get reported quickly.

Because NIS2 is a directive, the exact wording lands a little differently from one country to the next. The core duties are the same everywhere, so a team that meets them in one member state has already done most of the work for another.

Who NIS2 Applies To

NIS2 sorts the organizations it covers into two groups. Essential entities include sectors such as energy, transport, banking, health, water, and digital infrastructure. Important entities include areas such as postal services, waste management, food, manufacturing, and digital providers. Most medium and large organizations in these sectors are in scope, and smaller ones can be too where they play a critical role.

One group is worth calling out. Managed Service Providers and Managed Security Service Providers (MSSPs) are named in the law itself. So if you run an MSSP, NIS2 applies to you, and not just the clients you protect. You end up on both sides of the same rules, which helps, because the way you meet them for yourself is the way you can meet them for your clients.

The Core NIS2 Requirements

NIS2 asks for a set of basic, sensible measures. In short, you need to:

• know what you run and where your risk sits
• handle incidents in a defined, repeatable way
• keep the business running and recover after disruption
• manage the security of your suppliers and service providers
• control who has access, and use strong authentication
• protect data with encryption where it helps
• train your people, and check that the measures work

There’s also a point about ownership that matters. Senior leaders have to approve these measures and oversee them, and they can be held responsible if the organization falls short. Security is no longer only the security team’s concern.

The Incident Reporting Deadlines

NIS2 sets a clear timeline for reporting a significant incident. You send an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. That timeline is comfortable when your team can already see what happened and pull the details together, which is why the daily work of knowing your environment matters as much as the report itself.

What Is DORA and Who Must Comply?

DORA, the Digital Operational Resilience Act, is the EU’s rulebook for technology resilience in finance. It has applied since January 2025. Where NIS2 spreads across many sectors, DORA goes deep into one, and it sets a single, detailed standard for how financial firms manage technology risk and keep running when something breaks.

Who DORA Applies To

DORA covers financial entities of almost every kind, from banks and insurers to investment firms, payment and electronic money firms, and crypto-asset service providers. If you secure a regulated financial business, DORA is your framework. It also reaches the technology companies these firms depend on, because the most important ICT providers to the sector fall under a dedicated EU oversight regime.

The Five Pillars of DORA

DORA is built on five areas of work:

• ICT risk management, with a clear framework and senior ownership
• Incident management and reporting, using one shared way to classify and report major incidents
• Resilience testing, run regularly to confirm that defenses hold
• Third-party risk management, covering the ICT providers a firm relies on, including contract terms and oversight
• Information sharing, so firms can exchange threat intelligence when they choose to

Threat-Led Penetration Testing (TLPT)

Not every financial firm has to run threat-led penetration testing. Under Article 26, the competent authorities “shall identify financial entities that are required to perform TLPT” based on how far a firm’s activities “impact the financial sector,” on its “systemic character,” and on its ICT risk profile and maturity, so the larger and more systemically important the firm, the more likely it is to be named.

Those that are named “shall carry out at least every 3 years advanced testing by means of TLPT,” and that testing “shall…be performed on live production systems,” which means a genuine, adversary-style exercise against the live systems the business depends on rather than a safe copy.

The test follows the TIBER-EU framework, the ECB’s model for this kind of testing, which DORA builds on. It’s worth understanding even if it doesn’t apply to you, because it shows how seriously DORA treats proof. Being able to demonstrate that your defenses hold, on live systems, is written into the law itself.

NIS2 vs DORA

Side by side, the two have more in common than not. They were written for different audiences, yet they ask for a similar core of security work.

Reading down the columns, the real differences sit in the details, the scope, the deadlines and the extra testing DORA adds, while the security work underneath stays much the same, so you can approach both together rather than as two separate projects.

What NIS2 and DORA Have in Common

Both want you to manage risk with a real framework, report significant incidents on a deadline, test your defenses, take responsibility for the security of the providers you depend on, and give senior leaders a role in oversight. Do that work once, and it counts for both.

How NIS2 and DORA Differ

The differences are mostly scope and depth. NIS2 is broad, reaching many sectors across the economy. DORA is narrow and deep, focused on finance, with an extra layer of EU oversight for the most critical technology providers and a specific testing duty for the largest firms. The reporting regimes differ in their detail too, so a firm caught by both still files under each.

NIS2 and DORA Compliance Checklist

A quick way to see where you stand is to ask whether you could answer these today, without a rush:

• Do you know which systems and data matter most, and where they are?
• Can you tell what is genuinely exposed right now, rather than what might be?
• Could you produce a clear timeline of an incident within 72 hours?
• Can you show that a fix worked, with a record that proves it?
• Could you do all of this for each client or entity you cover, not only once overall?

If any answer is “not quickly,” the gap is operational rather than legal. Operational gaps are the ones a security team can close.

Do NIS2 and DORA Apply Outside the EU?

NIS2 and DORA are EU laws, so they apply mainly to organizations based in the EU. But if you are based outside the EU and work with EU customers or partners, parts of them can still apply to you.

The UK, the US, and Global Operations

If your organization sits outside the EU yet serves EU customers, runs operations there, or supplies a company that does, these rules can still shape what is expected of you. NIS2 pushes its members to manage supply-chain security, so an EU client may pass those expectations to a supplier anywhere in the world.

DORA works in a similar way for finance, since a critical technology provider to EU financial firms can be brought under its oversight wherever it is based. The UK runs its own rules for essential services and is updating them, so UK teams face the same kind of duties under a different name.

Latin America and the Direction of Regulation

Latin America is not covered by NIS2 or DORA, yet the direction of regulation across the region looks familiar. Chile has gone furthest on the cybersecurity side, and its framework law, Ley 21.663, sets up a national authority, defines the services that matter most, and requires organizations to manage risk and report incidents, much as NIS2 does in Europe.

Elsewhere in the region the most active lawmaking has been on data privacy rather than cybersecurity, which we cover separately in our guide to data privacy compliance. For a security team in the region, or one serving clients there, the work that satisfies NIS2 today is good preparation for what local law is moving toward.

NIS2 and DORA for MSSPs

An MSSP lives with these rules every day. You answer to a different regulator for each client, and because NIS2 names MSSPs directly, you answer for your own business as well.

Delivering Compliance Across a Client Portfolio

For an MSSP, the hard part is rarely understanding the rules, because the same requirements repeat for every client, and each new client has to be set up from the beginning, with the controls, reports and evidence that each country they work in expects. When you do that by hand, the work grows with every client you add, and the cost grows with it, so each new account earns a little less than it should.

The answer is to build the compliance work once and run it for each client separately, so that a new client means applying something you already have instead of starting again. Multitenancy and delivery automation make that possible, and our platform for MSSPs is built for exactly this.

Turning Compliance Into a Service Line

There’s a commercial side to this, too. When a prospect asks whether you can keep them compliant across every country and sector they operate in, that question often decides the deal. An MSSP that can answer yes, from one operation, is offering something many competitors cannot. Compliance handled this way becomes a service you can sell, and demand for it grows every year as more regions bring in rules of their own.

How to Meet NIS2 and DORA Requirements

Meeting either regulation takes more than a set of written policies. The systems you run and the suppliers you depend on keep changing, so anything you write down once is out of date by the next audit. The way to manage it is to turn the security work into a routine you repeat, one that finds what matters, deals with it, and records what you did, for a single organization or a whole portfolio of clients.

Understand, Validate, Reduce, Verify

Start by understanding what you have and where the risk sits, across the systems, services, and suppliers in scope. Then validate what is genuinely exploitable, so effort goes to the exposures that matter and not a long list that doesn’t. Reduce those exposures, and verify that the fix held. That last step is the one regulators care about most, because it turns a claim into evidence.

Governed Automation and the Audit Trail

Speed and control often work against each other, and a regulated environment needs both. This is where automation with human oversight earns its place. When a finding needs action, NINA, our multi-agent engine, can run it through a defined workflow, with confidence-scored steps and clear approval points, so a person stays in charge of anything significant. Every step is visible and recorded, which leaves the audit trail a regulator asks to see, from the first finding to the confirmed fix.

None of this replaces your compliance or legal team. It gives them proof they can trust at any moment, a current record of what was found, what was done, and that it worked, rather than a report pulled together once a year. Keeping that evidence current reflects the same thinking as the metric we watch most closely, MTRER, which measures how long an exposure stays usable.

First Steps for Security Teams

You don’t have to do everything at once, so work in this order:

• Map your systems, services and suppliers first, so you know what is in scope.
• Practice how you would report an incident before one happens, so the 72-hour deadline is manageable.
• Build to the stricter standard where the two overlap, so you cover both at once.
• Produce your evidence as the work happens, so it is ready the moment someone asks.

Our platform for enterprise security teams is built to support this, and it’s the same capability an MSSP uses across many clients, applied to one organization instead.