faaleoleo · June 2026 · Compliance
NIS2 Compliance in Europe
What Every Executive Must Know
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.
What NIS2 is and why it exists
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.
Who must comply
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:
-
01
Essential entities Energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (DNS, TLD registries, data centres, cloud providers, CDNs), ICT service management (B2B), public administration, space.
-
02
Important entities Postal and courier services, waste management, chemicals, food production and distribution, manufacturing (medical devices, electronics, machinery, motor vehicles), digital providers (online marketplaces, search engines, social networks), research organisations.
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.
What happens if you do not comply
This is not a directive where the consequences are abstract. The enforcement mechanisms are concrete, public, and personal.
Financial penalties
-
€20M
Essential entities Fines of up to €10,000,000 or 2% of global annual turnover — whichever is higher. A €500M-turnover company faces a maximum exposure of €10M.
-
€7M
Important entities Fines of up to €7,000,000 or 1.4% of global annual turnover — whichever is higher.
Management accountability
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:
- Issue a public statement identifying the natural person responsible.
- Temporarily prohibit an individual from exercising management functions.
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.
Incident disclosure
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.
The ten security measures you must implement
Article 21 of NIS2 defines the minimum baseline. These are not aspirational guidelines. They are legal requirements. Your organisation must implement all ten:
-
01
Risk analysis and information security policies A documented risk assessment methodology. Formal policies governing how information systems are protected.
-
02
Incident handling A defined process for detecting, classifying, containing, and reporting security incidents.
-
03
Business continuity and backup management Backup procedures, disaster recovery plans, and crisis management capabilities. This is explicitly named — backup is a NIS2 requirement, not a nice-to-have. See: what a managed backup programme covers.
-
04
Supply chain security Assessment of the security posture of direct suppliers and service providers. You are responsible for the risks your vendors introduce.
-
05
Security in acquisition, development, and maintenance Security considerations built into the procurement and development lifecycle for network and information systems.
-
06
Policies for assessing security effectiveness A formal programme for testing, auditing, and reviewing your security controls — not just implementing them.
-
07
Cyber hygiene and security training Baseline security awareness training for all staff. Documented hygiene standards (patching, password policy, phishing awareness).
-
08
Cryptography and encryption policies A documented policy governing where and how encryption is applied to data in transit and at rest.
-
09
Human resources security, access control, and asset management Role-based access policies, onboarding/offboarding procedures, and a maintained inventory of systems and data assets.
-
10
Multi-factor authentication MFA or continuous authentication for all access to systems in scope. This is a hard requirement — single-factor access is not compliant.
What documentation you need
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.
How to structure and approve your documentation
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.
The approval chain that satisfies Article 20
For documentation to carry legal weight under NIS2, it must be approved at the right level. The structure that national authorities expect to see:
- CISO or Head of IT Security — authors or commissions each policy and procedure document.
- CTO or equivalent — technical sign-off confirming the measures are correctly described and operationally implemented.
- CEO or managing director — formal approval of the risk assessment and the overall security programme. This is the Article 20 signature. It records that management has reviewed and endorsed the approach.
- Supervisory board or equivalent governance body — periodic (minimum annual) oversight review. Minutes of the meeting where cybersecurity was on the agenda serve as evidence.
If your organisation does not have a CISO, the responsibility falls upward. The CEO cannot delegate accountability away from management — only implementation tasks.
Practical approval workflow
-
01
Document owner produces the draft Each document has a named owner responsible for its accuracy and review cycle.
-
02
Technical peer review A second technical stakeholder reviews for correctness before the document leaves the drafting stage.
-
03
Legal or compliance review Particularly important for incident reporting procedures and supplier contracts — a legal perspective catches gaps a technical author will miss.
-
04
Management approval and signature CEO-level sign-off on the risk assessment and security programme. Documented with a date.
-
05
Board-level oversight review Annual board or supervisory body agenda item. Minutes retained as evidence of governance oversight.
-
06
Annual review cycle Each document has a defined review date. Changes are version-controlled with an audit trail. Outdated policy documents are a compliance risk in themselves.
Where to start if you have not started yet
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. A cost analysis of in-house vs managed backup may help frame the investment decision. 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.
The backup and recovery requirement specifically
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:
- Regular backups are performed according to a defined schedule.
- Backups are stored off-site or in a logically separate environment.
- Restoration procedures are documented and tested.
- RTOs and RPOs are defined and achievable within the tested recovery capability.
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. faaleoleo can provide all of this on request.
What a NIS2 backup compliance report must contain
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.
A compliance report shows the complete picture — including failures
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:
-
01
Report period and generation date The exact date range covered, when the report was generated, and who generated it. Reports must be reproducible — if an auditor asks for last quarter's report in six months' time, you need to produce the same data.
-
02
Summary statistics — including failure rate Total jobs run, successful, failed, and terminated with warnings. Success rate as a percentage. Total data volume protected. These aggregate figures belong on the first page — a management reader should understand the health of the programme in 30 seconds.
-
03
Every failed job, with detail Job ID, job name, client hostname, start time, end time, exit code, and the full error message. A summary count of failures is not sufficient — each failure must be individually identifiable. This is the record that proves you know what went wrong.
-
04
Warnings and non-fatal errors Jobs that complete with warnings are not the same as successful jobs. A job that backed up all files but logged a permission error on a system directory, or a job that ran long and triggered a timeout warning, must appear in the report — not be absorbed into the success count.
-
05
Corrective action for each failure For every failed or warned job: what was done in response. Was the job retried and did it succeed? Was a ticket raised? Was the client team notified? Was the failure investigated and root cause identified? This column transforms a log into evidence of a managed programme.
-
06
Restoration test results Backup completeness means nothing without verified restore capability. The compliance report must include the results of restoration tests performed during the period — which systems were tested, what data was restored, whether the restore met the defined RTO, and who verified it.
-
07
Retention and schedule compliance Confirmation that retention policies were enforced as configured. Any client that missed its scheduled backup window — even if it ran successfully at a different time — should be flagged. Schedule drift is a risk that escalates silently if not tracked.
-
08
Trend data over time Compliance reporting is not just a snapshot — it must support trend analysis. A client with a 2% failure rate this month is manageable. The same client with a 2% failure rate for twelve consecutive months is a systemic problem. The report needs to make that pattern visible.
Why a "green-only" report fails NIS2 scrutiny
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.
Approval and retention of backup compliance reports
A backup compliance report is a compliance document and must be treated as one:
- Generated on a fixed schedule (monthly minimum for most organisations in scope).
- Reviewed and signed off by the named backup operations owner.
- Stored for a minimum of three years — the standard audit lookback period for NIS2 enforcement.
- Version-controlled and tamper-evident. A report that can be quietly edited after the fact provides no assurance.
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.
What a well-run compliance programme looks like in practice
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 risk assessment is reviewed when something material changes — a new supplier, a new system, an incident, a significant change in threat landscape — not only at the annual review.
- Incident response procedures are practiced, not just filed. A tabletop exercise once a year is the minimum; realistic simulations are better.
- The board receives a meaningful security briefing at least annually, not a summary designed to avoid follow-up questions.
- Suppliers are reassessed when contracts are renewed, not only when first onboarded.
- Staff training completion is tracked and non-completion addressed — not treated as optional.
The gap between "we have the documents" and "we have a functioning programme" is exactly what an auditor or investigator is trained to find.
How faaleoleo closes the NIS2 backup gap
Article 21(1)(c) names backup management explicitly — backup procedures, disaster recovery plans, and crisis management are legal requirements, not operational preferences. Getting that requirement into a defensible state is where many organisations stall: not because the technology is absent, but because maintaining a compliant backup programme at scale demands operational discipline that most in-house teams are not resourced to sustain.
faaleoleo addresses the largest part of this obligation directly. Every deployment is deployed, OS-hardened, and operated to a defined standard from day one. Backup schedules, retention policies, encryption, and logically separate storage are configured as a baseline — not retrofitted later. The technical requirements that NIS2 imposes on backup are built into the faaleoleo service by design. For most organisations in scope, choosing faaleoleo moves Article 21(1)(c) from a compliance gap to a largely closed item.
Where faaleoleo is today
faaleoleo currently uses a set of scripts and internally developed reports to extract the job-level data that a NIS2 backup compliance report requires — job outcomes, failure records, warning detail, corrective action notes, and restoration test results. The content is correct and covers what an auditor needs to see. Generating the report, however, involves manual steps: pulling data, assembling it into the required format, and reviewing it for completeness. That process is time-consuming and operationally demanding. It is work that currently requires hands-on effort from the faaleoleo operations team rather than running automatically on a schedule.
What faaleoleo is building
Automated compliance reporting is in active development and will ship as a standard component of the faaleoleo service. When it does, the monthly NIS2 backup compliance report — summary statistics, per-job failure detail, corrective actions, restoration test records, retention and schedule compliance, and trend data — will be generated and delivered without manual assembly. The gap between running a clean, auditable environment and having the documentation to prove it will close as a matter of course for every faaleoleo customer.
For organisations on a compliance timeline that cannot wait: faaleoleo produces these reports manually today and knows exactly what they need to contain. If you are working toward a NIS2 audit or internal programme review and need backup compliance documentation, we will produce what you need.
Contact us about NIS2 compliance documentation
The executive summary
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.