ISO 27001 vs NIS2 vs DORA: Which Framework Do You Need in 2026?

NIS2 is the EU's second-generation cybersecurity directive, and it replaced the original NIS Directive in October 2024. Unlike a regulation, a directive is a baseline that the EU sets as a goal, and each of the 27 member states then writes its own national law to hit that goal. That's why NIS2 compliance can look slightly different depending on which country you're operating in.

The scale is hard to overstate, even if nobody agrees on an exact figure. Depending on the source and when the estimate was made, the number of organizations falling under NIS2 is put anywhere from roughly 100,000 to 160,000 entities across the EU, spanning 18 sectors - energy, transport, healthcare, digital infrastructure, manufacturing, and more. If your US-based company sells software, cloud services, or managed IT to clients in any of those sectors in Europe, there's a real chance NIS2 already applies to you, regardless of where your servers sit.

The directive itself is intentionally light on specifics:

• Article 20 puts accountability on senior management
• Article 21 lists broad categories of cybersecurity measures - risk management policies, incident handling, business continuity, supply chain security - without spelling out exactly how to implement them

That vagueness is deliberate. It's meant to be filled in by national law.

One document does get specific: the Commission Implementing Regulation (CIR) 2024/2690. It applies directly to a narrower group called "digital critical infrastructure" providers - think cloud computing, data centers, and DNS services. CIR spells out, almost clause by clause, what a security policy, a risk management framework, and an incident-handling process actually need to contain. Even if your company isn't legally required to follow CIR, it's worth treating as the de facto playbook, since many national NIS2 laws borrow heavily from its structure.

A working NIS2 compliance checklist usually comes down to five things:

1. A documented cybersecurity risk policy
2. Clear roles and responsibilities at the management level
3. An incident detection and reporting process that can hit the 24-hour/72-hour deadlines
4. A supply chain risk process
5. Evidence that all of it is actually being followed - not just written down

DORA - the Digital Operational Resilience Act - is a regulation, not a directive. That means it applies directly and identically across every EU member state, with no local translation needed.

Its scope is narrower than NIS2's. It covers:

• Financial entities (banks, insurers, investment firms)
• ICT third-party providers that serve them - a separate category with its own obligations

If NIS2 is a general cybersecurity baseline, DORA is a much more detailed rulebook focused on operational resilience - the ability to keep functioning, and recover fast, when something goes wrong.

The core DORA compliance requirements are built around four pillars:

1. ICT risk management
2. Incident reporting
3. Resilience testing
4. Third-party risk oversight

On top of the regulation itself, DORA comes with a stack of Regulatory Technical Standards (RTS) - appendices that go into granular detail on things like asset management policies and risk tooling. These are often far more prescriptive than anything in NIS2 or CIR 2690.

One detail that trips people up: DORA does not name ISO 27001 as a requirement. Article 28 simply says ICT providers must meet "appropriate" information security standards, leaving individual banks free to specify which ones they'll accept in a contract. In practice, ISO 27001 is the most common answer - it's internationally recognized, and most auditors already know how to assess it.

If your compliance program touches either framework, it's worth checking in on these developments every few months rather than treating either law as a fixed target.

ISO 27001 is the international standard for an Information Security Management System (ISMS) - a structured way of identifying risks, choosing controls, and continuously improving how an organization protects information. It's built on the plan-do-check-act cycle: plan your security approach, implement it, check whether it's working, then act on what you find.

That structure is exactly what NIS2 and DORA are missing. Neither law lays out how to organize a cybersecurity program logically - they mostly list requirements in something closer to legal shorthand. ISO 27001 gives you the connective tissue: a governance model that already maps reasonably well onto both.

This is also why ISO 27001 certification keeps coming up as a starting point rather than an end point. Getting certified proves you have a working ISMS and a set of ISO 27001 controls in place - it doesn't automatically prove you've met every line item in NIS2 or DORA. Think of certification as the foundation you build on, not the finished house.

Here's a simplified look at who actually has to comply with what, and where a security standard like ISO 27001 comes into play:

Notice the pattern: the companies with the most direct legal obligations (financial entities, critical infrastructure) aren't told to get Certified ISO 27001:2022 Lead Auditor. It's the suppliers feeding into that ecosystem who almost always need it, because their buyers write it into the contract.

When you compare ISO 27001 clauses against the CIR 2690 annex, the mapping is genuinely close. Clause 5.2 (policy) lines up with CIR's network security policy section. Clause 5.3 (roles and responsibilities) mirrors CIR's governance requirements. Clause 6.1 (risk treatment) covers similar ground to CIR's risk management section.

The catch is depth. CIR's requirements are considerably more detailed than the equivalent ISO 27001 clauses - an ISO 27001 risk assessment gives you the right process, but CIR may expect specific documentation, monitoring frequency, or reporting fields that ISO 27001 leaves open-ended. So if you're already ISO 27001 certified and want to layer on NIS2 (or CIR) compliance, don't assume you're done - go through each CIR section individually and check what extra detail it demands that your current ISMS doesn't yet capture.

The gap is even wider here, since DORA and its RTS are more prescriptive than CIR. Mapping ISO 27001's plan-do-check-act structure onto DORA's chapters gives you a rough skeleton: planning aligns loosely with DORA's governance and risk management articles, implementation aligns with incident management and resilience testing, and the check/act phases map to ongoing monitoring requirements.

But "rough skeleton" is the operative phrase. DORA specifies things ISO 27001 never will - exact incident classification thresholds, specific testing cadences, granular ICT asset inventory fields. Treat ISO 27001 as your organizing framework for DORA compliance, not your compliance content. It tells you how to structure a cybersecurity governance program; DORA (and its RTS) tell you exactly what has to be inside it.

That jump between 2023 and 2024 (data via the ISO Survey) lines up almost exactly with when NIS2 and DORA both came into force - a reasonable signal that regulatory pressure in Europe is a real driver of ISO 27001 compliance decisions, not just a coincidence of timing.

If you're starting from zero, here's a simplified ISO 27001 checklist that reflects how implementation typically plays out in practice. Bookmark this section - it's the part most worth coming back to once you actually start the project.

Quick-reference: 8 steps to ISO 27001 implementation

1. Get leadership buy-in first. Projects stall almost immediately without visible support from senior management - this is consistently the top reason implementations fail.
2. Run a proper ISO 27001 risk assessment. Identify assets, threats, and vulnerabilities before you write a single policy. Everything else in the standard builds on this step.
3. Define scope and roles. Decide which parts of the business the ISMS covers, and who owns which responsibility.
4. Write policies that match your actual environment. A backup policy that contradicts what your IT team is actually doing won't survive contact with reality - and nobody will follow it.
5. Implement ISO 27001 controls from Annex A that are relevant to your risk assessment findings, not the entire list by default.
6. Train employees, and make sure they understand why a control exists, not just that it exists.
7. Run an internal ISO 27001 audit before the certification audit, so gaps surface while you can still fix them.
8. Review and improve continuously. ISO 27001 isn't a one-time project; the "act" in plan-do-check-act assumes ongoing correction.

If you'd rather work through this sequence with guided instruction instead of a checklist alone, the Global Skill Development Council (GSDC) runs structured training that walks through each of these steps in practice - useful if you're doing this for the first time and want an experienced hand checking your work along the way.

Both NIS2 and DORA put heavy emphasis on supply chain security, and this is where a lot of companies get stuck - you can't directly control a vendor's internal systems. ISO 27001's approach offers a workable model: assess the risk of using a particular type of supplier first, then evaluate specific vendor proposals against that risk profile, then build contractual security clauses around whatever risks turned out to be highest (encryption standards, for instance), and finally monitor the relationship on an ongoing basis - with the intensity of that monitoring scaled to how risky the relationship actually is.

As organizations race to comply with NIS2 and DORA, demand isn't just rising for compliance software or consultants - it's rising for people who can actually implement and audit an ISMS from the inside. Every ISO 27001 implementation eventually needs someone who can run the internal audit, spot the gaps, and write findings the board will act on. That's the lead auditor role, and it's become one of the more practical entry points into cybersecurity governance work.

As of mid-2026, ZipRecruiter puts the average ISO 27001 lead auditor salary in the US at roughly $102,886, with the middle half of earners between $80,500 and $132,500. Other trackers report lower averages - Salary.com sits closer to $77,000, PayScale spans a wider $51,000–$128,000 - largely due to differences in methodology (live postings vs. self-reported pay vs. broader titles that aren't security-specific). The role increasingly shows up bundled into broader GRC titles too, with compliance directors, cybersecurity governance managers, and third-party risk leads now routinely listing lead auditor experience as preferred or required.

A typical lead auditor role covers planning and leading ISMS audits, evaluating whether controls are actually followed in practice, writing findings reports, and advising on gaps against the standard. What matters day to day is less about memorizing clause numbers and more about interviewing people effectively, spotting where written policy diverges from reality, and writing findings clearly enough for a non-technical executive to act on.

Understanding the gap between ISO 27001 and frameworks like NIS2 and DORA is one thing. Closing it - inside your own organization, or as an auditor helping others do it - takes more than a mapping table.

That's the gap the Global Skill Development Council (GSDC) built its Certified ISO 27001:2022 Lead Auditor program to address. Instead of testing clause memorization, it's structured around full ISMS audit coverage and a capstone project - built to develop the same skills this piece keeps circling back to: running a risk assessment that holds up, spotting where policy and practice diverge, and writing findings a board can act on.

If you're layering NIS2 or DORA compliance on top of an existing ISMS, or you're the one your organization is counting on to run that gap analysis, this is training built around real audit scenarios rather than practice questions.

The biggest mistake organizations make is assuming ISO 27001 automatically delivers NIS2 or DORA compliance. It doesn't. What it provides is the management framework - the governance skeleton both regulations assume you already have, even when they don't say so directly. The legal detail - CIR's specific documentation requirements, DORA's RTS-level controls - still has to be layered on top, clause by clause. Companies that understand this distinction going in are far more likely to pass their audits on the first attempt, instead of discovering the gap the hard way during a supervisory review.

For US companies with EU customers or operations, the smartest move is usually the same regardless of which framework applies: get the risk assessment right, document controls that match reality, and treat supplier risk as seriously as your own.