When the revised NIS2 Directive came across my desk last year, I’ll admit it didn’t initially feel urgent. I’d survived GDPR. I’d handled PCI-DSS. But as I dug into its scope, particularly the hefty obligations for essential and important entities, a familiar sense of regulatory gravity set in. This wasn’t just another checkbox exercise. This was a structural rethinking of digital operational resilience, and it demanded a different kind of readiness.
So, I took a step back and asked the most important question: What does compliance actually look like for us? That’s where the impact assessment began.
Understanding the scope before jumping in
The NIS2 Directive expands both the sectors and the entities it covers, moving beyond the original NIS scope to include providers in sectors like manufacturing, space, food, and postal services. The first challenge? Determining whether your organization falls under essential or important entity classification.
If you operate in the EU or provide services to EU-based critical infrastructure, you’re likely in scope. But classification isn’t just academic. It affects your reporting obligations, supervisory measures, and even potential penalties.
To bring clarity to this stage, I created a matrix for our internal review team to assess eligibility based on activity type, size thresholds, and cross-border relevance.
NIS2 applicability matrix
| Criteria | Essential entity | Important entity |
| Sector type | Energy, transport, health | Waste, postal, chemicals |
| Company size (as per EU thresholds) | Large enterprises | Medium-sized enterprises |
| Cross-border impact of disruption | High | Moderate |
| Subject to proactive supervision | Yes | No (reactive only) |
| Reporting obligations | Within 24 hours | Within 24-72 hours |
By mapping operations against this framework, we immediately saw which business units needed to elevate their compliance posture. It also helped cut through internal debates by grounding the conversation in facts.
Mapping the operational landscape
Once we identified our exposure, the next step was understanding where the directive’s teeth would bite hardest. Unlike older directives, NIS2 integrates detailed expectations around risk management, incident reporting, business continuity, and supply chain security.
To avoid shallow analysis, I worked with ICT leads, compliance officers, and legal to break down operational components into five key domains. This enabled a structured walk-through of how we manage risk in each area and highlighted where gaps could jeopardize compliance.
Operational domain review table
| Domain | Current Maturity Level | NIS2 Requirements Met | Priority Actions |
| Risk management | Moderate | Partial | Establish central risk register |
| Incident handling | Low | No | Develop 24/7 escalation protocol |
| Business continuity | Moderate | Partial | Formalize resilience testing schedule |
| Supply chain management | Low | No | Implement third-party risk assessments |
| Technical and organizational measures | High | Yes | Maintain and update policies quarterly |
Having this table in our assessment report became a conversation starter with our board. It moved the discussion from abstract policy compliance to clear, tangible tasks.
Estimating resources and assigning responsibility
Once you’ve visualized your gaps, the next pragmatic step is figuring out who’s going to do what, and how much it’ll cost. The directive is heavy on accountability, especially regarding executive liability, so vague assignments aren’t just risky, they’re non-compliant.
We crafted a resource matrix to align responsibilities across departments and define a basic project budget. This made it easier to defend our resourcing needs to management and clarify ownership early on.
Responsibility and resource matrix
| Task | Department lead | Estimated resource (hrs/month) | External support needed | Deadline |
| Cyber risk register development | IT Security | 40 | Yes (consultants) | Q2 2025 |
| Incident response framework update | Operations | 30 | No | Q2 2025 |
| Legal review of reporting process | Legal & Compliance | 15 | No | Q1 2025 |
| Vendor risk management program | Procurement | 25 | Yes (external auditors) | Q3 2025 |
When mapped this way, even reluctant departments understood their stake in the process. Resistance turned into planning.
Creating a living risk register
A core requirement of NIS2 is that entities must maintain a risk-based approach across all systems and processes. That meant going beyond static risk reports and building a living risk register—a continuously updated record of threat scenarios, control effectiveness, and remediation timelines.
To achieve this, we adopted a tiered structure: critical risks (requiring exec oversight), operational risks (tracked monthly), and vendor-related risks (updated quarterly). We also embedded automated reminders and change logs to ensure version control and accountability.
Sample structure of a NIS2 risk register
| Risk ID | Risk description | Impact level | Likelihood | Owner | Controls In place | Review frequency |
| R001 | Ransomware attack on CRM system | High | Medium | CIO | Backup + EDR + MFA | Monthly |
| R002 | Vendor API downtime | Medium | High | Procurement | SLA + Monitoring | Quarterly |
| R003 | Unpatched software vulnerability | High | High | IT Security | Patch management policy | Bi-weekly |
This format helped demonstrate due diligence in supervisory audits and made internal risk conversations far more precise.
Building resilience from insight, not fear
One thing became clear as we wrapped up our assessment: NIS2 isn’t just about compliance. It’s about digital trust. It forces you to get honest about your operational weaknesses and finally address the risk debt that’s easy to ignore in quieter quarters.
Yes, the penalties are steep. Yes, there are many obligations. But the directive is also an opportunity to mature. If you approach the impact assessment not just as a requirement but as a blueprint for resilience, the return on effort is well worth it.
If you’re still staring at a blank impact assessment document, start with this: understand your classification, map your risks, assign your champions, and make the risks visible. The rest will follow.
