An insider’s look at the NIS2 directive and DORA | Very Important Questions

Introduction

The European Union’s cybersecurity regulatory landscape has undergone a significant transformation with the implementation of two major frameworks: the NIS2 directive for critical infrastructure and DORA (Digital Operational Resilience Act) for the financial sector. For security leaders operating in or with European organizations, understanding these regulations—and their practical implications—has become essential.

In this episode of Very Important Questions, Ben Baker sits down with Pierre Noel, Field CISO at Expel, to explore the realities of NIS2 directive compliance and DORA implementation. Pierre brings decades of experience as a CISO across global organizations including Microsoft and major international banks, along with his work advising the Swiss government on financial sector cybersecurity.

This conversation goes beyond checkbox compliance to examine what these regulations actually mean for security programs—including the uncomfortable truth that compliance frameworks can sometimes lower the bar rather than raise it. Pierre shares real stories from the regulatory front lines and offers practical guidance for leaders navigating this complex landscape.

The geopolitical forces driving NIS2 directive and DORA

Understanding why these regulations exist helps organizations approach compliance more strategically. Both frameworks emerged from a recognition that Europe’s cybersecurity posture needed strengthening, though they address different sectors with different mechanisms.

Why Europe needed stronger cybersecurity standards

Pierre Noel: “There is a geopolitical dynamic. The truth is DORA started before we had this war in Ukraine and all these kinds of things. But there was a recognition that from a geopolitical point of view, Europe is not ready to sustain significant cybersecurity attacks, especially at a critical infrastructure level.”

The NIS2 directive addresses critical infrastructure across multiple sectors, while DORA focuses specifically on financial services. Both recognize that modern economies depend on interconnected digital systems, and a weakness in one organization can create cascading effects across entire sectors.

The small organization problem

While major banks and large enterprises typically have robust security programs, the regulatory focus extends far beyond these organizations. DORA, for example, covers not just major financial institutions but also insurance brokers, investment advisors, and smaller banks—organizations that historically haven’t prioritized cybersecurity investment.

Pierre Noel: “When we speak about finance, we also have the small insurance brokers. They are handling some of your personal information. You have the advisers. You also have the small banks. We concluded very easily that if there was a problem in one of these tiny banks because they don’t really pay too much attention on cyber, that would have a domino effect.”

This interconnected risk is precisely why regulators have expanded their scope. A security incident at a small financial services firm can trigger regulatory intervention that affects the entire sector.

When compliance becomes a ceiling instead of a floor

One of the most counterintuitive findings from DORA implementation is that compliance frameworks can actually reduce security investment at well-resourced organizations. This represents a significant challenge for the NIS2 directive as EU member states continue their transposition efforts.

The dangerous “good enough” mentality

Pierre Noel: “Increasingly, DORA is becoming an excuse for tick-in-the-box type of exercise. Banks that used to do proper cybersecurity, that used to invest—now the board says, ‘Well, actually, as long as we meet the DORA requirement, we should be okay, shouldn’t we?’ And so it somewhat lowers the bar.”

This phenomenon represents a fundamental misunderstanding of what compliance frameworks are designed to achieve. Regulations like the NIS2 directive establish minimum baselines, not optimal security postures. Organizations that previously exceeded these baselines may find themselves under pressure to reduce investment to “just enough” levels.

The quality of regulatory oversight matters

Not all regulators are created equal. The effectiveness of frameworks like the NIS2 directive depends heavily on how individual countries implement and enforce them. Some national regulatory bodies have deep technical expertise and ask probing questions during audits. Others rely on junior staff following scripted checklists.

Pierre Noel: “In some countries, your financial regulator is really on top of the game—really knows what they are talking about. I can name FINMA in Switzerland. They’re on top of the game. MAS in Singapore. They’re on top of the game. I will not name the ones that are not on top of their game.”

The disparity in regulatory quality creates uneven compliance landscapes across Europe, which the NIS2 directive’s national transposition requirements may perpetuate.

Real stories from the regulatory front lines

Sometimes the best way to understand regulatory challenges is through stories that illustrate the gap between theoretical compliance and practical security.

When regulators ask the wrong questions

Pierre Noel: “They asked me some silly questions about encryption. They wanted to know the small details about encryption. They completely forgot to ask me if I knew exactly how many machines were running in my department—because I’ve got no clue whatsoever. I don’t have a CMDB in place.”

This example highlights a critical problem: regulators often focus on technical details that sound sophisticated but miss fundamental security hygiene questions. Knowing your asset inventory is far more important than cryptographic key lengths, yet auditors frequently prioritize the latter.

The result? Organizations pass compliance audits while maintaining significant security gaps. In this case, the bank later discovered thirty unknown servers in their DMZ—a finding that should have emerged during any competent security review.

The penetration test that wasn’t

In perhaps the most striking example of regulatory misunderstanding, Pierre shared a story of regulators requesting that banks lower their firewalls to facilitate penetration testing.

Pierre Noel: “One day, the regulator contacted all the banks in that country and said, ‘We are going to conduct a pen test. We want you to lower your firewall so that we can do a pen test.’ And all the CISOs said, ‘No, we’re not going to do that.'”

The entire purpose of penetration testing is to evaluate defenses as they actually exist. Requesting that organizations disable their security controls fundamentally misunderstands the exercise—and demonstrates why security leaders sometimes struggle to take regulatory guidance seriously.

The challenge of pushing back on regulators

One of the most significant structural problems in the compliance landscape is the power imbalance between regulators and regulated entities. Security leaders often recognize problematic requirements but feel unable to challenge them.

Fear of regulatory retaliation

Pierre Noel: “If a regulator comes to you and comes with a new regulation and you know this is rubbish—this makes no sense whatsoever, this does not apply in the real world—you don’t dare raising your hand and telling that to the regulator. Because you know well, if you raise your hand, the next audit would be for your organization.”

This dynamic creates a compliance environment where problematic requirements persist because no one feels safe challenging them. The result is a disconnect between what regulations require and what actually improves security.

Building anonymous feedback mechanisms

In Switzerland, Pierre helped establish a community approach that allowed CISOs to provide collective feedback to regulators without individual attribution. By appointing a representative who wasn’t directly affiliated with any specific bank, the community could safely communicate that certain requirements didn’t make practical sense.

Pierre Noel: “We could safely tell the regulator this and that does not make sense. And then we knew that the regulator would not come and attack the origin.”

This model offers a potential path forward for organizations struggling with NIS2 directive implementation challenges. Industry associations and peer communities can aggregate concerns and present them to national regulators without exposing individual organizations to retaliation risk.

Incident reporting requirements under DORA and NIS2

Both DORA and the NIS2 directive impose strict incident reporting timelines. Meeting these requirements demands robust monitoring and detection capabilities that many organizations currently lack.

The hard numbers that matter

Pierre Noel: “You’ve got some hard numbers that you have to meet under DORA, and either you meet them or you don’t. This hard number is how much time do you have to disclose to the regulator that you had an incident. If you don’t make it because your infrastructure is not able to tell you that you have an incident, then you are in breach.”

For DORA-regulated entities, this means having 24×7 monitoring capabilities that can detect incidents and initiate notification processes within the required timeframes. Organizations that rely on periodic log reviews or delayed alert triage will struggle to meet these obligations.

Beyond detection: incident response readiness

Meeting notification deadlines is only the first challenge. Organizations also face scrutiny for how they respond to incidents. Poor response execution can result in regulatory penalties and reputational damage regardless of how quickly the initial notification occurred.

Pierre Noel: “When you have an incident, you will be judged on the way you react. Usually, you are not judged on whether the incident took place or not—you will be judged on how did you react to that incident.”

This reality underscores the importance of incident response planning and practice. Organizations that can demonstrate mature, well-rehearsed response capabilities are better positioned to weather regulatory scrutiny.

Why tabletop exercises are non-negotiable

Regular tabletop exercises have become essential for NIS2 directive and DORA compliance—not as a checkbox activity, but as genuine preparation for incident response under pressure.

The first exercise will be a disaster

Pierre Noel: “If you’ve never had a tabletop exercise, I’m telling you the first one will be a major disaster. Everybody will be frantic and screaming and saying this is the end of the world because I don’t know how to react. But perhaps by the second or the third exercise, people will start growing that special muscle that makes you a little bit more resilient.”

This insight is critical for organizations just beginning their compliance journey. The value of tabletop exercises comes from repeated practice, not from a single event. Building incident response capability requires ongoing investment in exercises that stress-test different scenarios.

Cybersecurity incidents are business problems

One of the most common misconceptions Pierre encounters is the belief that cybersecurity incidents are purely technical problems that the security team should handle independently. In reality, incident response quickly escalates to involve legal, finance, communications, and executive leadership.

Pierre Noel: “They truly believe that a cybersecurity problem is constrained to the cybersecurity team to have all the answers. In fact, it’s not true. Let’s say I have ransomware and the bad guys are asking me the equivalent of a million dollars. It’s not the CISO to decide. The CISO will have to go to the board.”

Questions that arise during real incidents—whether to pay ransoms, when to notify customers, how to communicate with regulators—require input from across the organization. If executives have never confronted these decisions in a practice environment, they’ll struggle when facing them under pressure.

The case for a chief resilience officer

Pierre advocates for organizations to consider a new executive role that sits above the traditional CISO: a chief resilience officer focused on overall organizational resilience rather than cybersecurity alone.

Digital resilience extends beyond cybersecurity

Pierre Noel: “I could have a cybersecurity incident. I could also place too much trust on my AI strategy. Perhaps I could give too much information to Gemini or ChatGPT. I could have some other problems such as one of my employees has disclosed some private information about my customers. These are not cybersecurity issues, but they significantly impact the organization.”

The NIS2 directive’s focus on “digital operational resilience” reflects this broader perspective. Organizations need coordinated approaches to all forms of digital risk, not just traditional cybersecurity threats.

Bridging the communication gap

Many CISOs struggle to communicate effectively with boards and executive committees because they come from technical backgrounds. A chief resilience officer can translate technical risk into business terms and maintain closer relationships with organizational leadership.

Pierre Noel: “Most CISOs—and God bless us, I’m one of them—we come with a technical background, and usually we have great difficulty in communicating effectively to non-technical people. The reality is that most of the CISOs are not very good at explaining why we need an increase of our budget by ten percent.”

This communication gap perpetuates a cycle where CISOs can’t secure adequate resources, leading to firefighting rather than strategic security improvement, which further limits their ability to engage with leadership on strategic issues.

Information sharing requirements under NIS2

The NIS2 directive includes provisions encouraging information sharing among regulated entities. While this sounds straightforward, implementing effective information sharing requires overcoming significant cultural and competitive barriers.

The value of shared threat intelligence

Pierre Noel: “You have a bank located somewhere in the world that gets attacked on a trading floor with a very specific, very fine-tuned type of phishing attack. Well, it would be very useful for all the other banks who have a trading floor to learn about that incident just right now, so that they can prepare themselves.”

Timely threat intelligence sharing can dramatically improve collective defense. When one organization experiences a novel attack, that knowledge can help others prepare before the same attackers target them.

Cultural barriers to sharing

Despite the clear benefits, information sharing often fails in practice. Organizations worry that disclosing vulnerabilities or incidents could expose them to competitive disadvantage or regulatory scrutiny.

Pierre Noel: “When I built these ISACs, nobody would speak. They would not dare speaking because they were worried that if they were to speak about a weakness they have, some people would use that against them.”

Effective information sharing requires building trust within communities and keeping regulators at arm’s length from the sharing mechanisms. When organizations fear that shared information could trigger regulatory action, they stop sharing.

AI governance: the emerging compliance gap

While much attention focuses on established requirements, Pierre identifies AI governance as a critical emerging gap that most organizations haven’t adequately addressed.

The AI policy imperative

Pierre Noel: “How many organizations have got an AI policy in place that indicates very clearly the dos and the don’ts? If you don’t have an AI policy in place, you’re not ready for an AI incident.”

As organizations rapidly adopt AI and automation capabilities, they’re often doing so without clear governance frameworks. This creates risks ranging from data leakage through AI assistants to decisions based on hallucinated information.

Testing AI in complex environments

The challenge extends beyond policy to practical security testing. Modern systems increasingly combine multiple technologies—cloud services, AI tools, traditional applications—in ways that make isolated testing insufficient.

Pierre Noel: “You test a 5G network. But in reality, this 5G network is used in combination with some agentic AI, with some cloud, with some this, some that. So just testing in isolation will never give you a proper understanding of what is really happening.”

This complexity creates significant blind spots for organizations trying to understand their true risk exposure.

Practical advice for leaders starting their compliance journey

For security leaders early in their NIS2 directive or DORA compliance efforts, Pierre offers straightforward guidance grounded in risk management fundamentals.

Start with documented risks

Pierre Noel: “Be very logical. Don’t come up with a solution unless you’ve been able to demonstrate that there was a problem. Start by looking at your risks. Document those risks. What could go wrong? What is the likelihood it will go wrong? Did it go wrong in the past? Did you know a company in the same business where it went wrong?”

This risk-based approach ensures that compliance investments address actual organizational vulnerabilities rather than generic requirements that may not apply to your specific context.

Maintain discipline when vendors come calling

With compliance deadlines creating urgency, organizations often face pressure to purchase solutions quickly. Pierre recommends maintaining rigorous evaluation criteria tied to documented risks.

Pierre Noel: “Every time you speak to a vendor, every time someone is trying to sell you something, you have to look at: is it addressing one of these risks? If it’s not, I love you, but I will see you next year because I don’t have a need for you.”

This discipline prevents compliance initiatives from becoming unfocused spending exercises that don’t actually improve security.

What organizations overprepare for—and what they ignore

Pierre offers a contrarian perspective on where organizations misallocate their compliance and security resources.

The data classification illusion

Many organizations invest heavily in elaborate data classification schemes with multiple levels—public, confidential, secret, top secret—that sound sophisticated but rarely work in practice.

Pierre Noel: “Most organizations in the world, if you ask them, ‘Do you have a data classification?’ they’ll say ‘Oh, yeah, we have a data classification.’ Can you bring me an assistant or secretary? I’d like to understand how she can determine the difference between a secret and a confidential document. Because most likely, she has no clue whatsoever.”

Complex classification schemes that employees can’t actually implement create false confidence while providing little real protection. Organizations would often be better served by simpler approaches that people actually follow.

AI risk and board readiness gaps

Conversely, organizations consistently underinvest in AI governance and board-level incident response preparation. Both represent significant risks that compliance frameworks are only beginning to address.

Key takeaways for NIS2 directive and DORA compliance

This conversation reveals several critical insights for organizations navigating European cybersecurity regulations:

1. Compliance is a floor, not a ceiling. The NIS2 directive and DORA establish minimum baselines. Organizations with mature security programs should resist pressure to reduce investment to “just compliant” levels.
2. Regulatory quality varies significantly. National implementation of the NIS2 directive will differ across EU member states. Organizations operating in multiple countries need to understand each jurisdiction’s approach.
3. Incident reporting requires robust monitoring. Meeting notification deadlines under DORA and NIS2 demands continuous monitoring capabilities and well-practiced incident response processes.
4. Tabletop exercises build critical muscle memory. Regular practice—not one-time events—creates the organizational capability to respond effectively under pressure.
5. Cybersecurity incidents are business problems. Executives, legal, and communications teams need to be involved in incident response planning, not just security staff.
6. Information sharing faces cultural barriers. Despite regulatory encouragement, effective threat intelligence sharing requires building trust and maintaining separation from regulatory oversight.
7. AI governance represents an emerging gap. Most organizations lack adequate policies and testing approaches for AI-related risks.
8. Risk documentation should drive investment. Compliance spending should address documented organizational risks, not generic requirements or vendor pitches.

Frequently asked questions about the NIS2 directive

Q: What is the NIS2 directive and who does it affect?

A: The NIS2 directive is EU legislation that establishes cybersecurity requirements for organizations operating critical infrastructure and essential services. It covers sectors including energy, transport, healthcare, digital infrastructure, and public administration. Unlike DORA, which is a regulation that applies directly, NIS2 is a directive that requires each EU member state to transpose it into national law, leading to some variation in implementation across countries.

Q: What’s the difference between NIS2 and DORA?

A: DORA focuses specifically on financial services entities and their technology providers, while the NIS2 directive covers a broader range of critical infrastructure sectors. DORA is an EU regulation that applies directly across all member states, whereas NIS2 must be transposed into national law by each country. Both frameworks share similar principles around incident reporting, risk management, and third-party oversight.

Q: What are the penalties for NIS2 directive non-compliance?

A: Penalties under the NIS2 directive vary by member state and entity classification. Essential entities can face fines up to €10 million or 2% of global annual revenue, whichever is higher. Important entities face lower maximum penalties of €7 million or 1.4% of revenue. The directive also introduces personal liability for management bodies that fail to ensure compliance with cybersecurity requirements.

Q: How quickly must incidents be reported under NIS2?

A: The NIS2 directive requires organizations to submit an early warning within 24 hours of becoming aware of a significant incident, followed by a more detailed notification within 72 hours, and a final report within one month. Some member states have implemented even stricter timelines—Cyprus, for example, requires early warnings within six hours.

Q: How should organizations prepare for NIS2 directive compliance?

A: Organizations should start by assessing their risk exposure and documenting potential threats relevant to their operations. Key preparation steps include implementing continuous monitoring capabilities, developing and practicing incident response procedures through tabletop exercises, establishing reporting mechanisms that can meet notification deadlines, and ensuring board-level awareness of cybersecurity responsibilities.

Q: Does the NIS2 directive require information sharing between organizations?

A: The NIS2 directive encourages voluntary information sharing among regulated entities to improve collective cybersecurity. However, effective information sharing requires building trust within industry communities. Organizations should consider participating in sector-specific information sharing groups while being mindful that overly formal or regulator-adjacent sharing mechanisms may inhibit candid participation.

This transcript has been edited for clarity and readability. The regulatory guidance discussed reflects the perspectives of an experienced security practitioner and should not be considered legal advice. Organizations should consult with legal counsel regarding specific compliance obligations in their jurisdictions.

For more compliance and security operations insights, visit expel.com/blog or follow our LinkedIn page for updates on security trends and best practices.