faaleoleo · June 2026 · Compliance
The NIS2 Directive became binding law across the European Union in October 2024. If your organisation operates in Europe and falls within scope — and the scope is broader than most executives realise — non-compliance carries fines in the tens of millions, mandatory incident disclosure, and personal liability for board members and senior management. This article is for the people who need to understand the obligation before they can act on it.
NIS2 (Directive EU 2022/2555) replaced the original NIS Directive with a mandate that is stricter, broader, and more enforceable. The European Commission introduced it because the first directive produced inconsistent implementation across member states and left critical infrastructure — energy grids, healthcare systems, financial networks, logistics chains — exposed to a threat landscape that had grown dramatically since 2016.
The core premise is simple: organisations that provide essential or important services to society carry a responsibility to protect those services from disruption. Cyber incidents are no longer an IT problem. They are a business continuity risk, a public safety risk, and now a legal risk.
NIS2 applies to any organisation that meets two conditions: it operates in one of the 18 covered sectors, and it exceeds the EU's definition of a medium-sized enterprise (50+ employees or €10M+ annual turnover). Member states may extend these thresholds downward at their discretion — some have.
The directive defines two tiers:
If you are unsure which tier applies to your organisation, the national competent authority in your member state is responsible for maintaining a register. Most have published self-assessment tools.
This is not a directive where the consequences are abstract. The enforcement mechanisms are concrete, public, and personal.
Article 20 of NIS2 is the clause that has focused boardroom attention: management bodies must approve the organisation's cybersecurity risk-management measures and oversee their implementation. If a significant incident occurs and the investigation finds that management failed in this oversight duty, member state authorities may:
This is not theoretical. Several EU member states, including Germany, have explicitly aligned their national transposition laws with this accountability standard. "We delegated it to IT" is no longer a viable defence for a CEO or a supervisory board member.
A significant cyber incident affecting your systems must be reported to the national competent authority on a mandatory timeline:
| Deadline | Requirement |
|---|---|
| Within 24 hours | Early warning — notify the authority that an incident has occurred |
| Within 72 hours | Incident notification — include severity assessment and initial impact |
| Within 1 month | Final report — full account of the incident, root cause, and remediation steps |
Failure to report — or late reporting — is itself a compliance violation subject to additional penalties.
Article 21 of NIS2 defines the minimum baseline. These are not aspirational guidelines. They are legal requirements. Your organisation must implement all ten:
Documentation under NIS2 serves two purposes: it proves you have implemented the required measures, and it provides the evidence trail an auditor or national authority will request during an inspection. Vague claims are insufficient — you need artefacts.
The minimum documentation set covers six areas:
Risk assessment and treatment records. A current risk register mapping identified threats to assets in scope. For each risk: likelihood, impact, and the control chosen to address it. A risk treatment plan showing accepted, mitigated, transferred, and avoided risks. This document needs a review date and evidence of annual (or event-driven) review.
Security policies. Formal written policies covering each of the ten Article 21 measures. Policies must be version-controlled, dated, and signed. A policy that exists only as an email or an internal wiki page without ownership and sign-off does not constitute adequate documentation.
Incident response plan. A step-by-step procedure covering detection, initial triage, escalation paths, containment actions, the 24/72-hour reporting workflow, and post-incident review. Named roles and deputies. Contact details for the national competent authority.
Business continuity and disaster recovery plan. Recovery time objectives (RTOs) and recovery point objectives (RPOs) defined per system. Backup schedules, off-site storage confirmation, and restoration test records. The test records are critical — a backup plan that has never been tested is not a compliant plan.
Supplier security assessments. For each critical supplier: the assessment methodology used, the findings, and what was done in response. This does not need to be exhaustive for every vendor, but any supplier with access to your systems or data must be documented.
Training records. Evidence that staff have completed security awareness training. Completion dates, training content covered, and next review date.
The documentation approach that maps most cleanly onto NIS2 requirements is an Information Security Management System (ISMS) aligned with ISO/IEC 27001. An ISMS is not a product — it is a structured way of owning, reviewing, and improving your security controls. NIS2 does not mandate ISO 27001 certification, but organisations that have it can use their existing controls framework as the foundation for NIS2 compliance with relatively modest additional work.
For documentation to carry legal weight under NIS2, it must be approved at the right level. The structure that national authorities expect to see:
If your organisation does not have a CISO, the responsibility falls upward. The CEO cannot delegate accountability away from management — only implementation tasks.
NIS2 transposition deadlines have already passed in most EU member states. If your organisation is in scope and has not begun, the gap between your current state and a defensible compliance posture needs to close quickly. Enforcement activity varies by member state, but the window for "we are working on it" as a risk mitigation is narrowing.
A realistic starting point for a management team:
This month: Confirm whether your organisation is in scope. Check your member state's national authority website — most have published self-assessment tools. Identify who owns NIS2 compliance internally (if no one does, appoint someone now).
Within 90 days: Commission or complete a gap assessment against the ten Article 21 measures. Engage your legal counsel to confirm which national transposition law applies to you. Begin drafting the risk assessment — it is the foundation document everything else rests on.
Within 6 months: First versions of the six core document sets completed and approved at management level. Incident response plan tested at least once in a tabletop exercise. Supplier assessment process initiated for critical vendors.
Backup management is explicitly named in Article 21(1)(c) alongside disaster recovery and crisis management. This means that having backup infrastructure is not optional for NIS2-covered organisations, and the quality of that backup programme is subject to review.
Specifically, you need to be able to demonstrate:
A backup programme that exists on paper but has not been tested is not a compliant programme. National authorities looking at business continuity documentation will ask for test records.
Working with a managed backup provider? Ensure they can provide evidence of their own NIS2 or equivalent compliance posture — supply chain security applies to them. Ask for their security policies, incident response contacts, and evidence of regular DR testing. If they cannot provide these, that is a finding in your supplier assessment.
Many organisations produce a monthly backup summary that shows job counts and a success rate. That is an operational dashboard — it is not a compliance report. The distinction matters because an auditor reviewing your Article 21(1)(c) documentation is looking for something substantially different.
The most common mistake is reporting only successful jobs. A backup report that shows 100% success rate every month either reflects a genuinely perfect operation (rare) or a report that filters out failures before management sees them (a compliance liability). Auditors are trained to look for this pattern. A report with no failures over an extended period is a red flag, not a green one.
A NIS2-compliant backup report must include:
Article 21(1)(f) requires policies and procedures to assess the effectiveness of security measures. A backup report that has been filtered to show only successes cannot demonstrate effectiveness — it demonstrates selective presentation. If a national authority or third-party auditor requests your backup records and the raw operational logs contradict the compliance reports, that discrepancy is treated as a finding in its own right, separate from whatever underlying failure was being obscured.
The standard you are being held to is: could a reasonable auditor review this report and form an accurate picture of how your backup programme actually performed? If the answer requires them to also obtain the unfiltered logs, your compliance report has failed its purpose.
A backup compliance report is a compliance document and must be treated as one:
If your managed backup provider generates these reports on your behalf, their output must meet the same standard. You remain responsible for the compliance posture — the provider's report does not transfer accountability, it supports it.
NIS2 compliance is not a project with an end date. It is an ongoing management function, the same way financial controls are. The organisations that manage it well treat it as such:
The gap between "we have the documents" and "we have a functioning programme" is exactly what an auditor or investigator is trained to find.
NIS2 is European law. If you are in scope, compliance is not optional and the consequences of non-compliance are financial, reputational, and personal. The obligation rests with management, not with IT.
The directive requires ten categories of security measure, a structured documentation programme, mandatory incident reporting on strict timelines, and active management oversight documented with evidence. The six core document sets — risk assessment, security policies, incident response plan, BC/DR plan, supplier assessments, and training records — form the backbone of any defensible programme.
If you have not started, start now. If you have started, close the documentation and approval gaps before an incident forces the issue.
Questions about how your backup and data recovery infrastructure fits into your NIS2 programme? We work with organisations across Europe on exactly this. Reach us at contact@faaleoleo.io.