NIS2 Directive and Business Continuity

When an organization treats NIS2 as merely a cybersecurity issue, it often finds itself in trouble when the first major incident occurs. The NIS2 Directive and business continuity management actually address the same governance challenge: maintaining essential services, limiting the impact of a disruption, and demonstrating a consistent response capability to stakeholders, customers, and, where applicable, authorities.

For CCOs, CISOs, risk managers, and compliance functions, the issue is therefore not simply to set a cybersecurity plan alongside a business continuity plan. Rather, it is about aligning the two, with formalized requirements, clear responsibilities, and mechanisms for demonstrating compliance. This is precisely where many organizations still need to reach the next level of maturity.

The NIS2 Directive and Business Continuity Management: A Shift in Scale

NIS2 broadens the scope of affected entities and raises the bar for risk management. In practice, this changes the nature of internal dialogue. Business continuity is no longer a separate issue, often managed to meet sector-specific requirements or for insurance purposes. It is becoming a key driver of compliance and operational resilience.

This development deserves to be understood correctly. NIS2 does not merely require the prevention of incidents; it also calls for the organization of response, recovery, and the ability to operate in degraded mode. In other words, information system security and business continuity must be viewed as a continuum.

For many organizations, the key issue is governance. Advanced organizations already have a business continuity plan (BCP), a risk recovery plan (RRP), a crisis response team, and a set of procedures. However, these elements have sometimes been developed in silos. The risk is not the absence of documentation, but the lack of coordination between these systems.

What NIS2 Means in Practical Terms for Business Continuity

An operational interpretation of NIS2 involves examining several aspects. First, the identification of critical activities and essential dependencies. Second, the ability to prevent, detect, respond, and recover. Finally, the traceability of decisions and actions taken. In all three of these areas, business continuity provides a framework that can be put to immediate use.

The primary benefit of the PCA is that it links technical incidents to their business impact. The same cyber incident can have very different consequences depending on whether it affects a supply chain, a production tool, a customer relationship, or a support function. Without a thorough impact analysis, recovery priorities remain theoretical. NIS2 therefore implicitly pushes organizations to improve the reliability oftheir BIA, update their scenarios, and identify their essential resources.

The second point concerns business continuity strategies. It is not enough to have backups or anIT disaster recovery plan. In certain contexts, technical recovery does not guarantee operational recovery. An application may be restored but remain unusable due to a lack of validated data, available staff, an accessible vendor, or a proven manual procedure. The level of expectation requires consideration of the entire service chain.

The third contribution relates to crisis governance. NIS2 strengthens expectations regarding the reporting and management of significant incidents. This requires established escalation procedures, shared criteria for classifying incidents, and coordination among cybersecurity, business units, legal, communications, and senior management. An untrained crisis response team slows down the response just as much as a technical failure.

The Most Common Areas of Conflict

In practice, several discrepancies crop up regularly. The first is a mismatch between the various maps. Cyber risk mapping, critical process mapping, and supplier mapping do not always align. As a result, when it comes time to prioritize, teams waste time reconciling disparate data sets.

The second discrepancy concerns recovery objectives. Some organizations have defined RTOs and RPOs at the IT level, but without any real business validation. Conversely, others have set very ambitious expectations without verifying their technical feasibility or cost. Meaningful compliance requires an explicit trade-off between expected service levels, necessary investments, and accepted residual risks.

The third point of contention is the management of third parties. NIS2 strongly highlights dependence on service providers, technical operators, hosting providers, and critical partners. However, business continuity is often assessed internally, without sufficient review of contractual commitments, the provider’s backup capabilities, or coordination procedures in the event of a crisis. This is a structural weakness in many outsourced environments.

Finally, testing remains a blind spot. Plans exist—sometimes well-drafted—but have not been tested under realistic conditions. Yet the gap between a documented plan and an actual, deployable capability is considerable. The exercise reveals hidden dependencies, underestimated timelines, and unprepared decisions.

How to Structure a Credible Response

The most effective approach is to start with the essential or important services provided by the organization, and then work backward to identify the assets, resources, and dependencies that are necessary to maintain them. This approach avoids building compliance based on a list of controls that are disconnected from operations.

Once this scope has been clarified, it becomes possible to coordinate multiple projects. A business impact analysis allows us to prioritize processes and define acceptable levels of disruption. The risk analysis identifies plausible scenarios, including those involving cyber threats. Business continuity strategies then translate these priorities into concrete solutions: redundancy, fallback solutions, manual procedures, substitute capabilities, crisis management, IT recovery, and communication.

We also need to formalize governance interfaces. Who classifies the incident? Who decides to switch to degraded mode? Who balances rapid recovery against preserving evidence? Who notifies, who informs, and who coordinates service providers? Without clear answers, tensions between technical, regulatory, and business requirements escalate at the worst possible moment.

From this perspective, business continuity standards—particularlyISO 22301—provide a useful framework. While they do not, on their own, cover all the requirements of NIS2, they help structure a coherent, documented, and improvable approach. Their value lies less in formal compliance than in the discipline they impose in governance, documentation, exercises, and management reviews.

NIS2 Directive and Business Continuity Management: Required Evidence

For the organizations involved, the real issue is not just doing it, but being able to demonstrate it. In the event of an inspection, audit, significant incident, or request from management, they must be able to present tangible evidence. This includes the business continuity policy, BIA results, risk analyses, response and recovery plans, exercise reports, corrective action plans, and governance decisions.

The quality of this evidence is just as important as its existence. Outdated, inconsistent, or unverified documentation undermines the credibility of the system. Conversely, a well-managed, up-to-date body of documentation linked to actual responsibilities creates a solid foundation for compliance and action. This is often what distinguishes a prepared organization from one that is merely documented.

We must also accept a reality: not everything can be treated with the same level of rigor. Priorities vary depending on the sector, the criticality of services, the size of the organization, its exposure, and its operating model. A mature approach does not seek immediate comprehensiveness. Instead, it charts a realistic path based on the most significant gaps and risks.

Train teams to move from intention to execution

The convergence of NIS2, business continuity, crisis management, and cyber resilience requires cross-functional skills. Managers must be able to interpret regulatory requirements, translate them into internal guidelines, oversee impact assessments, coordinate exercises, and engage with both technical and business stakeholders. This ability cannot be improvised.

This is why the professionalization of teams has become a top priority. In demanding environments, the quality of a program depends as much on the methods chosen as on the expertise of those who design and lead it. Structured training makes it possible to link concepts, requirements, and real-world practices with a level of rigor that meets current market and regulatory expectations. Specialized organizations such as DRI France are committed to this approach of building skills that can be directly applied in the workplace.

Taking NIS2 seriously, therefore, means accepting that business continuity is no longer a peripheral issue. It is a key component of operational governance, risk management, and institutional credibility. Organizations that make this shift early on gain more than just compliance. They gain a real ability to keep operating when an incident leaves no time for improvisation.

This post is also available in: