Implementing the NIS2 directive is a significant challenge for any organization, especially those managing complex and critical infrastructures. After six months of intensive work, I’ve had the opportunity to reflect on the strategies adopted, the successes achieved, and the mistakes made. This review is not just a retrospective analysis; it’s a practical guide for anyone embarking on similar journeys, offering concrete insights on what to replicate and what to avoid to optimize time and resources.
Tested on: Enterprise Infrastructure with 2,000 workstations and 300+ VMs · VMware vSphere 7.0 · FortiGate 7.2 · Wazuh 4.7 · August 2026
Prerequisites / Test Environment
The reference environment is a medium-to-large organization with a heterogeneous IT infrastructure, including on-premise systems (VMware vSphere, Oracle Database, Active Directory) and cloud services (OCI, PSN). NIS2 compliance required a holistic approach, touching on governance, technical security, incident management, and operational continuity. The starting point already included a certain level of security maturity, but the NIS2 directive mandated significant acceleration and standardization of practices.
The Six-Month Review
What I Would Do Again
#### 1. Detailed Mapping of Critical Assets and Dependencies
The first and most crucial step was dedicating significant resources to comprehensively map all IT and OT (Operational Technology) assets relevant to essential service delivery. This isn’t just about identifying servers and workstations; it’s about understanding interconnections, software/hardware dependencies, and data flows. This process, though lengthy and laborious, provided a solid foundation for all subsequent risk analyses and for defining security measures. Read also: NIS2 Healthcare: Technical Processing Register
# Example command for Linux asset inventory (simplified)
ssh user@host 'hostname; cat /etc/os-release; df -h; netstat -tulnp'#### 2. Top Management Engagement and Sponsorship
From the outset, securing full support from top management was fundamental. NIS2 is not just a technical problem; it’s a matter of corporate governance. Clearly presenting the risks, legal requirements, and benefits (including reputation and business continuity) helped secure necessary budgets and human resources, overcoming initial resistance. Without this sponsorship, many compliance projects would have remained unimplemented.
#### 3. Continuous Training and Staff Awareness
The human factor is often the weakest link in the security chain. We invested heavily in staff training at all levels, not just IT specialists. Simulated phishing campaigns, awareness courses on data protection, and security policies helped create a more widespread security culture. The results were tangible, with a reduction in incidents related to human error.
#### 4. Business Continuity and Disaster Recovery Testing
It’s not enough to have a plan: you must test it. We conducted comprehensive business continuity and disaster recovery exercises, simulating real incident scenarios (e.g., ransomware attack, major hardware failure). These tests revealed weaknesses in procedures, recovery time objectives (RTO), and data consistency (RPO) that no theoretical analysis could have highlighted. Read also: Disaster Recovery Testing: What Broke First
# Example script to test critical service reachability
#!/bin/bash
SERVICE_HOST="critical-service.example.com"
SERVICE_PORT="443"
if nc -z -w 5 "$SERVICE_HOST" "$SERVICE_PORT"; then
echo "[$(date)] Service $SERVICE_HOST:$SERVICE_PORT reachable."
else
echo "[$(date)] ERROR: Service $SERVICE_HOST:$SERVICE_PORT NOT reachable."
# Add email notification or SIEM alert here
fiWhat I Would Not Do Again
#### 1. Underestimating Organizational Inertia and Resistance to Change
Initially, I underestimated how difficult it was to modify established processes and ingrained habits. Often, the focus is solely on the technical aspect, but managing human change is equally complex. I should have dedicated more time to proactive communication, explaining the “why” behind the changes and involving operational teams more proactively, rather than imposing new procedures from the top down. Resistance isn’t always ill will, but often fear of the unknown or the perception of an added workload without clear benefit.
#### 2. Implementing “Big Bang” Solutions Instead of Incremental Ones
In some areas, we tried to implement complete and complex solutions in a single block. This led to delays, frustrations, and a higher risk of errors. An incremental approach, with small wins and progressive releases, would have been more effective. For example, for privileged access management (PAM), I would have started with a small group of users and critical systems, then gradually extended the solution.
Common Errors and Troubleshooting
One of the most common errors was interpreting NIS2 as a checklist to tick, rather than a framework for improving overall security posture. This leads to superficial solutions that don’t address the root cause. Another mistake was not dedicating enough time to reviewing and updating existing documentation. Many policies and procedures were obsolete and didn’t reflect the current state of the infrastructure, creating confusion and regulatory gaps.
Troubleshooting: To address these challenges, we established a cross-functional NIS2 team with representatives from IT, compliance, legal, and business. This facilitated communication and rapid resolution of roadblocks. We also adopted an iterative approach, with planning, implementation, checking, and acting (PDCA) cycles, to adapt to changes and learn from mistakes.
FAQ — Frequently Asked Questions
How long does it take for a medium-sized organization to comply with NIS2?
There’s no single answer, but for an organization with 2,000 endpoints and 300+ VMs, the journey can take a significant period for full and mature compliance. Much depends on the initial security posture and resource availability. The first six months are crucial for the analysis and planning phase.
What is the main practical difference between NIS1 and NIS2?
NIS2 significantly broadens the scope compared to NIS1, including more sectors and types of entities (even SMEs). Additionally, it introduces stricter security requirements, greater emphasis on supply chain management, and higher penalties for non-compliance. The approach is more proactive and risk-oriented.
Is it possible to implement NIS2 without investing in new tools?
Partially, yes, by optimizing the use of existing tools and improving processes. However, to achieve an adequate level of maturity, investments in solutions like SIEM/EDR, PAM, and vulnerability management tools are likely necessary. The goal is to improve visibility and incident response capabilities.
How is supply chain security managed under NIS2?
NIS2 requires organizations to assess the security risks of their supply chain. This means conducting due diligence on suppliers, including specific security contractual clauses, and continuously monitoring their compliance. It’s a complex area that requires close collaboration with procurement and legal departments.
Conclusions with Operational Takeaways
The experience of these six months has reinforced a conviction: cybersecurity is not a one-time project but a continuous process of improvement. NIS2, though complex, offers a unique opportunity to elevate organizations’ security levels. The operational takeaways are clear: invest in deep infrastructure knowledge, secure management support, continuously train personnel, and test, test, test. Avoiding “big bang” approaches and managing change with attention to human factors are equally crucial for success. Compliance is only the starting point; the ultimate goal is robust operational resilience.
References
Updated: August 2026
