NIS2 in brief: who is affected and since when
Directive (EU) 2022/2555, known as NIS2, required transposition into national law by each EU member state no later than 17 October 2024. By mid-2026, 22 of the 27 member states have officially adopted their national legislation — the remaining five are still in legislative process. A first wave of enforcement actions is underway in several jurisdictions, and competent authorities have begun issuing formal requests to operators. Assuming 'this doesn't apply to us' is an increasingly risky position.
The scope question is the first one technical managers ask. NIS2 distinguishes two categories of entities: essential entities (Annex I) and important entities (Annex II). Membership in either depends on sector of activity and size. The default size rule: more than 50 employees or more than €10 million in annual turnover. Below these thresholds, an organisation is generally outside the direct scope — but note: if you are a supplier to an essential or important entity, the supply chain security requirements (Article 21, point d) reach you indirectly. Covered sectors include energy, transport, banking, health, water, digital infrastructure, and digital providers: IaaS, PaaS, SaaS, MSPs, MSSPs, DNS operators, and top-level domain (TLD) registries.
The 10 measures under Article 21 NIS2
Article 21 of the NIS2 directive defines ten cybersecurity risk-management measures that essential and important entities must implement. These measures span the full security lifecycle: from risk analysis and incident handling to business continuity and supply chain security. Each measure must be proportionate to the risk and documented to demonstrate compliance to the competent supervisory authorities.
- Policies for risk analysis and information system security
- Incident handling: detection, notification and response
- Business continuity: backups, disaster recovery, crisis management
- Supply chain security (suppliers and subcontractors)
- Security in the acquisition, development and maintenance of systems
- Policies and procedures to assess the effectiveness of cybersecurity measures
- Basic cyber hygiene practices and cybersecurity training
- Policies and procedures regarding cryptography and encryption
- Human resources security, access control and asset management
- Use of multi-factor authentication (MFA) or continuous authentication solutions
The 4 measures that directly affect your hosting
Among the ten measures of Article 21, four translate almost directly into infrastructure and hosting choices. Implementing Regulation (EU) 2024/2690 of 17 October 2024 details the technical requirements by sector for digital providers — DNS, cloud services, CDNs, MSPs, MSSPs — and is the operational reference to consult alongside the directive.
- Continuity and backups (Art. 21 §2.c): backups must be regular, encrypted, stored outside the primary system, and restoration must be tested. A provider that does not offer off-site backups or cannot supply metadata (timestamps, integrity verification) does not help you meet this obligation.
- Cryptography (Art. 21 §2.h): encryption of data in transit (TLS 1.2 minimum, TLS 1.3 recommended) and at rest (encrypted volumes, databases) must be documented. Cipher choice and key management are your responsibility, but your hosting provider must allow you to implement them.
- Access control and MFA (Art. 21 §2.i and §2.j): access to administration interfaces (hosting panel, SSH, VM management consoles) must be protected by MFA and subject to least-privilege principles. The hosting provider must offer MFA on their management panel; SSH configuration remains within your perimeter.
- Logging and detection (Art. 21 §2.b): the ability to detect an incident and reconstruct its sequence requires system logs retained over time, intact and accessible. Log retention, export to a SIEM or centralised platform, and protection against modification are concrete requirements.
What your VPS or dedicated server must satisfy in practice
Here is how each of these measures translates into operational configuration on a VPS or dedicated server.
Backups. Best practice is the 3-2-1 rule: three copies of data, on two different media, with one off-site. On a VPS, this means at minimum: daily automated snapshots from the hosting provider, plus an application-level backup exported to separate object storage (S3-compatible or equivalent). Frequency should be defined based on your RPO (Recovery Point Objective) — for most critical web applications, 24 hours is a maximum. Restoration testing must be documented and repeated at least once per quarter.
Encryption. TLS on all entry points (HTTPS, SMTP with STARTTLS, API access) with a configuration rejecting obsolete versions (SSLv3, TLS 1.0, TLS 1.1). For data at rest, volumes containing sensitive data should be encrypted — LUKS for Linux filesystems, native encryption for databases where available. TLS certificate management must be automated (ACME/Let's Encrypt or equivalent) to avoid uncontrolled expirations.
Access and MFA. Password-only SSH access must be disabled — SSH keys only, with PasswordAuthentication no in sshd_config. For high-value management interfaces (hosting panel, virtualisation consoles), MFA via TOTP application or hardware key (FIDO2) is required. Service accounts must have dedicated, independently revocable keys. The list of active accesses must be audited regularly.
Logs. Application logs (Nginx, Apache, PHP-FPM, databases) and system logs (auth, kernel, systemd) must be stored in a space that the application itself cannot modify. The minimum retention period recommended by most national CSIRTs is 90 days, with extended retention (12 months) for authentication and administration logs. Export to a centralised solution (remote syslog, Loki, Elasticsearch) is strongly recommended to preserve integrity in the event of server compromise.
Verify your NIS2 scope membership
Identify your sector in Annexes I and II of the directive. Apply the size rule (> 50 employees or > €10M turnover). If you are a supplier to an essential or important entity, review your service contract clauses — your client may contractually impose equivalent security requirements on you.
Inventory all exposed administration interfaces
Hosting panel, SSH, RDP, database interfaces (phpMyAdmin, Adminer), monitoring consoles, management API interfaces — list everything. For each interface, verify: MFA enabled, IP restriction where possible, last audit of active accounts.
Audit your backup policy
Answer these questions: what is the backup frequency? Where are they stored (same datacenter or external)? Are they encrypted? Have you tested a full restore in the last 90 days? Do you have defined RPO and RTO per critical service?
Test TLS configuration
Use an SSL analysis tool (SSL Labs, testssl.sh) to verify that your domains do not serve SSLv3 or TLS 1.0/1.1, and that the cipher suite does not contain deprecated algorithms (RC4, MD5, SHA-1 on certificates). Fix any rating below A on SSL Labs.
Check log retention and integrity
Identify the location of each log file (auth, nginx/apache, application, database). Measure current retention duration. Verify that authentication logs are not writable by the application account. Set up export to secondary storage if not already in place.
Document key and certificate management
List all TLS certificates in production with their expiration dates. Verify that renewal is automated. Inventory active SSH keys per server and remove orphaned keys (disabled accounts, former contractors). Document who has access to what.
Prepare the incident notification procedure
NIS2 requires an initial notification to the competent authority within 24 hours of detecting a significant incident, an interim report within 72 hours, and a final report within one month. Define at minimum: who decides an incident is significant, who notifies, and how you build the evidence trail (logs).
Assess your supply chain security
Inventory suppliers with access to your infrastructure (hosting provider, managed services, external developers, integrators). For each, assess the level of control you exercise over their access and their own security posture. Contracts with these suppliers must include security and incident notification clauses.
What NIS2 does not directly cover: organisations with fewer than 50 employees and less than €10 million annual turnover are generally outside the scope of the directive, unless they operate in specific sectors listed in Annex I or their size exceeds the thresholds of a 'microenterprise' as defined by EU Regulation 2003/361. This does not mean these organisations are exempt from all obligations — other regulations (GDPR, national sector regulations) apply independently — but they are not required to meet the specific requirements of Article 21 NIS2. However, if they are suppliers to an in-scope entity, their clients may contractually impose equivalent measures under supply chain security.
Scroll the table
| Criterion | Essential entities (Annex I) | Important entities (Annex II) |
|---|---|---|
| Main sectors | Energy, transport, banking/finance, health, drinking water, digital infrastructure (DNS, TLD, IXP, cloud, CDN), public administration, space | Postal services, waste management, chemical industry, food, industrial manufacturing, digital providers (marketplaces, search engines, social networks) |
| Size threshold | Medium and large enterprises (> 50 employees or > €10M turnover) in Annex I sectors; or explicit designation by member state | Medium and large enterprises (> 50 employees or > €10M turnover) in Annex II sectors |
| Supervision regime | Proactive: regular audits, on-site inspections, possible continuous monitoring | Reactive: controls triggered by incident or complaint |
| Maximum fines | €10M or 2% of global annual turnover (whichever is higher) | €7M or 1.4% of global annual turnover (whichever is higher) |
| Incident notification deadline | Initial alert within 24h, interim report within 72h, final report within 1 month | Same deadlines as essential entities under most national transpositions |
| Management liability | Managers may be held personally liable in the event of serious breach | Management liability: varies across national transpositions |
Achieving compliance: a pragmatic roadmap
NIS2 compliance is not a one-time project but an ongoing risk management programme. For an organisation starting out, a three-phase roadmap is realistic.
Phase 1 — Scoping (1 to 2 months). Confirm scope membership, identify affected systems and services (NIS2 scope ≠ entire IT estate), appoint a security lead and define roles. Produce a critical asset map and a first documented risk analysis. Identify the most critical gaps: missing MFA, non-off-site backups, absence of centralised logging.
Phase 2 — Immediate technical measures (2 to 4 months). Deploy MFA on all administration interfaces. Put in place or strengthen off-site backups with restoration testing. Audit and correct TLS configuration. Centralise logs with a minimum 90-day retention. Review supplier access and update contracts. Draft the incident notification procedure.
Phase 3 — Ongoing programme. Embed security into the development cycle (code reviews, dependency management, annual penetration tests). Implement business continuity exercises. Train teams in cyber hygiene practices. Document and test crisis management procedures. Review risk analysis at least once per year or after any major infrastructure change.
On the contractual side, verify that your hosting contract includes clauses on: incident notification (deadline and channel), respective backup responsibilities, data portability, and conditions for accessing logs during an investigation. An availability SLA does not cover these dimensions — they must be negotiated explicitly.
Conclusion
NIS2 is not an abstract regulation: it translates into concrete obligations the security practices that most technical teams have recognised as best practices for years — reliable backups, controlled access, usable logs, documented procedures. What changes is that these practices become enforceable, auditable and sanctionable. For in-scope entities, the question is not whether these practices are worth implementing, but whether they are documented as being in place, and whether the infrastructure partners they choose support that documentation.
To go deeper: the article on specific obligations for hosting providers and their clients under NIS2 ([nis2-hebergement-obligations-clients-2026](/blog/nis2-hebergement-obligations-clients-2026)), consent management and legal obligations for hosting providers ([digital-omnibus-cookies-consent-hebergeurs](/blog/digital-omnibus-cookies-consent-hebergeurs)), and application secrets security best practices on VPS ([docker-secrets-securite-vps-production](/blog/docker-secrets-securite-vps-production)).
