Blog

Understanding NIS2 means taking responsibility – why compliance alone isn’t enough

Adapting to a new reality

For many executives, NIS2 initially feels like just another regulatory obligation: a new set of requirements, new deadlines and new responsibilities. But anyone who takes a closer look at the directive quickly realises that NIS2 fundamentally changes how organisations take responsibility for digital resilience. 

NIS2 is not aimed solely at IT departments or information security officers. The directive addresses the organisation as a whole – with clear expectations regarding structure, decision-making capabilities and traceability. For many organisations, this is precisely where the greatest challenge lies. 


Understanding NIS2 as a framework for responsibility

NIS2 is a European regulatory framework that requires organisations to treat digital resilience as a management responsibility. It focuses on clearly defined responsibilities, transparent decision-making and structured risk management as part of modern governance. 

This shifts the focus: NIS2 responsibility lies not with individual functions but with the organisation as a whole. Executives are tasked with systematically managing risks and documenting decisions in a robust manner. 

From IT security to organisational resilience

The original NIS directive focused on operations of critical infrastructure. NIS2 significantly expands this scope to include far more industries, company sizes and dependencies. But even more crucial is the substantive requirement: it calls for structured, cross-threat ICT management that takes technical, organisational and human factors into account equally. 

This makes cybersecurity an integral part of corporate management. Risks must not only be identified but also consciously classified, prioritised and addressed – in a proportionate, documented and verifiable manner. Organisations that have previously relied heavily on individual experience-based knowledge are reaching their limits here. 

The invisible risk of historically grown working methods

In many organisations, employees have been compensating for a lack of structures for years through personal dedication and experience. Processes work because “someone knows what to do”. Incidents are resolved without systematic documentation, and suppliers are considered trustworthy simply because they have been long-standing partners.  

NIS2 makes these implicit dependencies visible – and critical. Because in an emergency, what counts is not only whether action was taken but whether risks, measures and decisions were clearly defined in advance. 

When structures are lacking, gaps in transparency emerge. And a lack of transparency makes it difficult to justify decisions with sound reasoning. 

Mandatory reporting as a stress test for organisations

This becomes particularly evident in ICT incident reporting. NIS2 sets clear timeframes: an early warning within 24 hours, a detailed report after 72 hours and a final or progress report within one month. These deadlines can only be met if processes, roles and information are clearly defined in advance. 

Organisations must be able to answer:  

  • When is an incident considered significant? 
  • Who makes that assessment? 
  • What information is available and when?  
  • How is communication with CERTs or CSIRTs handled? 

Without this clarity, every incident quickly becomes an organisational risk. 

Supply chains: responsibility does not end at the company’s boundaries

Another key component of NIS2 compliance requirements is the risk management of third-party ICT providers. Cloud services, software vendors and managed security providers are deeply integrated into operational processes. Accordingly, NIS2 requires systematic due diligence assessments, ongoing monitoring and robust contingency plans. 

Security therefore does not end at the company’s boundaries. Organisations must view their supply chains as part of their own attack surface – driven by responsibility, not mistrust. 

Supervision, sanctions and personal accountability

NIS-2 significantly strengthens the powers of supervisory authorities. It provides for on-site inspections, targeted audits, extensive information requests and substantial fines. 

For executives, this means that decisions must be explainable and defensible. 

If governance structures are not clearly defined, uncertainty arises in decision-making. Clear responsibilities, on the other hand, provide guidance and transparency. 

From compliance to decision-making capability

Organisations that successfully implement NIS2 follow a structured approach. They use the directive as a framework to design security in a systematic way. 

Digital GRC platforms such as BIC GRC support this by providing integrated and audit-proof management of risks, incidents, suppliers and evidence. 

This creates transparency regarding interdependencies and makes decisions traceable. Responsibility is not delegated but made visible. 

Conclusion

NIS2 encourages organisations to act more consciously without slowing down. 

Those who assume responsibility in a structured manner create clarity in decision-making processes, strengthen their own resilience and build trust – both internally and externally. 

Find out how BIC GRC can help you with your NIS 2 implementation


Frequently Asked Questions

What responsibilities do executives have under NIS2?

Executives are responsible for systematically managing risks, ensuring decisions are traceable and establishing governance structures. 

Why is compliance alone not sufficient for NIS2?

Pure compliance does not create resilience. What matters is the ability to assess risks in a structured way and make well-founded decisions. 

What does organisational resilience mean in the context of NIS2?

Organisations are able to identify, manage and adapt to risks and changing conditions – based on clear processes and responsibilities. 

How do you document decisions for NIS2?

Through structured processes, clear responsibilities and systems that reliably capture decisions, measures and risks. 

What are implicit dependencies in organisations?

Dependencies that are not formally documented but are based on experience or informal structures, making them difficult to verify.