The Compliance Lie: Why ISO 27001, NIS2, DORA and NIST CSF Are Not the Same Thing

Most corporate compliance programs are built backwards. They start with a template, devolve into a document scramble and end with an unmanaged risk register. Then, eventually, the question that should have come first: What are we actually trying to control?

I have seen organizations spend enormous amounts of money producing policies that nobody reads, procedures nobody follows and evidence nobody understands.

The documents look impressive. The system underneath them is often much less impressive. That is compliance theatre.

The problem is not that companies have too much governance. It is that they mistake documentation for governance. And one of the clearest examples is the way organizations treat NIS2, DORA, ISO 27001, NIST CSF and ENS as though they were competing versions of the same checklist.

They are not. They solve different problems.

In the image below you can see a simple overview of how the different frameworks, regulations, systems and guidelines relate to each other. The relationship between these regulatory layers is straightforward when mapped as a unified architecture. One thing to remember is that there is no real need to implement all the frameworks or follow all of the regulations. Some regulations like DORA are not applicable to say the medical sector. And you can perfectly run your ISMS or Information Security Management System purely on the ISO-standard with a few slight specifications that make you compliant with the NIS2 like the public sector.

Start with the law

NIS2 and DORA are not management systems. They create regulatory obligations.

For an organization in scope of NIS2, those obligations include risk-management measures, governance responsibilities and incident reporting. For significant incidents, NIS2 requires an early warning within 24 hours, an incident notification within 72 hours of becoming aware of the incident and a final report within a month after the early warning.

DORA approaches the problem from the financial sector. It requires financial entities to maintain an ICT risk-management framework, places ultimate responsibility for ICT risk with the management body and establishes requirements for ICT incident management, reporting, resilience testing and third-party risk.

The important point is simple:

The law defines the obligations.

It does not become your operating model just because you downloaded the regulation.

Then build the management system

This is where ISO/IEC 27001 belongs.

ISO 27001 is an information security management system standard. It defines requirements for establishing, implementing, maintaining and continually improving an ISMS.

That distinction matters.

ISO 27001 does not say, “Buy this firewall.”

It asks whether the organization has a disciplined system for understanding risk, deciding what matters, assigning responsibility, selecting controls and improving the system as circumstances change.

That is why I think of ISO 27001 as the operating system for governance.

The value is not the certificate. The value is the management discipline behind it. A certificate sitting beside an unmanaged risk register is nothing more than a paper tiger: looks menacing and with sharp teeth, but crumples with the least amount of pressure.

Then give the operating teams a language

This is where NIST CSF 2.0 is useful. NIST CSF 2.0 organizes cybersecurity outcomes around six Functions:

Govern. Identify. Protect. Detect. Respond. Recover.

NIST is explicit that the CSF Core is not a checklist of actions. The actions required to achieve the outcomes depend on the organization, its risk and its circumstances.

That makes it useful as an operational language. The board can ask where the organization is weak. The CISO can translate that into risk. Engineering can translate it into architecture and controls.

The framework helps the organization speak one language.

It does not replace the law. It does not replace the management system. And it certainly does not make an organization compliant simply because someone mapped a spreadsheet to it.

Then there is ENS

Spain’s Esquema Nacional de Seguridad is where simplistic comparisons start to break down and for good reason.
ENS is not simply another voluntary framework.

Under Royal Decree 311/2022, systems are categorized according to the impact of security incidents and the applicable security measures are selected according to the system’s security category and relevant security dimensions. The framework includes organizational, operational and protection measures, with additional reinforcements depending on the category.

That makes ENS more prescriptive in important areas than a purely risk-selected control framework.

It behaves more like a building code. You still need to understand the structure you are protecting. But once the building falls into a particular category, certain requirements follow.

That is very different from saying:

“ISO 27001 is our certification, so we are done.”

You are not done. Not by a long shot. You have simply solved one part of the problem.

Stop making them compete

The mistake is trying to choose one framework and eliminate the others. That is the wrong architecture.
A better model is straightforward.

• NIS2 and DORA establish the regulatory obligations.
   They tell you what the organization is accountable for.

• ISO 27001 establishes the management system.
   It gives those obligations somewhere to live.

• NIST CSF gives the organization an operational language.
   It helps translate governance and risk into outcomes that security teams can execute.

• ENS adds jurisdiction-specific requirements where it applies.
   It becomes another set of requirements that the underlying governance system needs to absorb.

The point is not to create five compliance programs. The point is to build one system that can carry multiple obligations.

That is the difference between architecture and paperwork.

Your policies are not your controls

This is where most organizations lose the plot. They create a policy for access control. Then another for incident management. Then another for suppliers. Then another for business continuity. Soon there are hundreds of pages in SharePoint. Everyone feels productive.

But ask a simple question: Who owns the control?
  Silence. Everyone looks sheepishly at their screen and hopes someone will answer in their stead.

Ask: What evidence demonstrates that it operates?
  More silence. It starts to feel like a classroom where the teacher asked the class a basic question and no one answers.

Ask: What happens when the control fails?

Now you have found the real governance problem. A policy is not a control merely because it exists. A control has an owner. It has an objective. It operates in the real world. It produces evidence. And someone makes a decision when it does not work. That is governance. Everything else is decoration.

Build architecture, not binders

A strong governance system should be smaller than most organizations expect. Not because the requirements are simple. Because the architecture is clear.

The objective is not to produce the largest documentation library.

The objective is to identify the small number of documents, decisions, controls and evidence streams that carry the weight of the system.

That is the discipline. Complexity is easy to create.

Anyone can add another policy. Another committee. Another spreadsheet. Another 80-page procedure.

Simplicity is harder.

It requires knowing what can be removed without weakening the system. That is the standard we apply at Elyrion. Every piece of governance needs a reason to exist.

It must do at least one of three things:

1. Enable a control.
2. Support an executive decision.
3. Satisfy a legal or regulatory obligation.

If it does none of those things, it does not belong in the architecture.

Kill the paper tiger.

The board does not need more paper

Executives do not need another compliance presentation explaining how many policies were reviewed this quarter.

They need to know where the organization is exposed. They need to know which risks are accepted. They need to know who owns them. They need to know which controls are actually operating. They need to know what the organization could defend when the regulator, auditor or incident arrives.

That is a very different conversation.

The boardroom should not be a theatre for proving that governance exists. It should be the place where governance decisions are made.

That is why we prefer a small number of load-bearing artifacts over a library of shelf-weight.

The system should be understandable without a consultant standing beside it. It should survive personnel changes. It should survive an audit.

Most importantly, it should survive reality.

The standard is simple

Do not build your security program around the audit. Build it around the risk.

Do not treat ISO 27001 as a substitute for NIS2 or DORA.

Do not treat NIST CSF as a certification.

Do not treat ENS as another generic framework.

And do not mistake documentation for control.

The best governance architecture is the one where the law, management system, operational framework and technical controls reinforce one another without creating four separate bureaucracies.

That is the work.

Build architecture, not binders.

Build clarity.

Ready to map your true regulatory exposure?

Most executive teams do not need another 300-page assessment.

They need clarity.

At Elyrion, the Elyrion Clarity™ Rapid Executive Diagnostic maps regulatory obligations against the organization’s actual governance, technical environment and control architecture.

Over 2–3 weeks, we identify the material gaps, separate legal requirements from framework preferences and give the executive team a prioritized remediation roadmap.

No promise of instant compliance.

No paper tiger.

Just a clear view of what matters, what does not and what needs to be fixed first.