Why NIS2 affects your clients and your projects
NIS2 does not stop at the entities it targets: it extends to their supply chain. Article 21 requires every essential or important entity to address the security of its relationships with its direct suppliers and service providers, taking into account each one's specific vulnerabilities, the quality of their products and their secure development practices. A hospital, an energy network, a transport operator or a public administration must therefore assess and document the security of every provider that touches its digital infrastructure — the website's host, the application platform, the integrated SaaS tools.
An agency delivering a project to a client subject to NIS2 thus falls indirectly within scope: if it cannot provide documented guarantees about the chosen hosting, its client cannot meet its obligation to control the chain. And if the agency itself administers its clients' infrastructure, it may become a managed service provider, a category NIS2 targets directly from medium size upwards.
What NIS2 concretely requires
- Ten minimum risk management measures (Article 21) — including incident handling, business continuity, supply chain security, access control, cryptography and multi-factor authentication.
- Early warning within 24 hours — every significant incident is reported to the CSIRT or competent authority within 24 hours of becoming aware of it, stating whether it appears malicious or cross-border.
- Incident notification within 72 hours — an initial assessment of severity, impact and, where available, indicators of compromise.
- Final report within one month — detailed description, likely root cause, mitigation measures; an intermediate report may be requested in between.
- Documented supply chain security — every direct supplier is assessed and security commitments are formalised in contracts.
- Regular assessment of the effectiveness of measures — tests, vulnerability scans and continuity exercises at defined intervals.
- Governance at management level (Article 20) — management bodies approve the measures, oversee their implementation, follow mandatory training and can be held liable for infringements.
Who is affected: essential and important entities
NIS2 applies to public or private entities in the sectors listed in its two annexes, from medium size upwards as defined by Recommendation 2003/361/EC: 50 employees or more, or more than €10M in both annual turnover and balance sheet total. Annex I covers eleven highly critical sectors: energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management (business-to-business), public administration and space. Annex II covers seven more: postal services, waste management, chemicals, food, manufacturing, digital providers (online marketplaces, search engines, social networks) and research.
The category depends on the annex and on size. Essential entities are Annex I entities exceeding the medium-sized enterprise ceilings (250 employees or more, or more than €50M turnover and more than €43M balance sheet), plus, regardless of size, qualified trust service providers, top-level domain registries and DNS service providers. Important entities are all the other in-scope entities of both annexes — for example a medium-sized cloud provider. Member States may also designate a smaller entity if it plays a critical role.
On the hosting side, Annex I explicitly names cloud computing service providers, data centre service providers, content delivery networks (CDN), DNS service providers, as well as managed service providers and managed security service providers. Member States had to establish the list of their essential and important entities by 17 April 2025: depending on the country, registration with the authority relies on the entity's own declaration.
Essential and important entities: what changes
Scroll the table
| Criterion | Essential entities | Important entities |
|---|---|---|
| Who | Annex I entities above the medium-sized enterprise ceilings; TLD registries, DNS providers and qualified trust service providers regardless of size; entities designated by the State | Other entities of Annexes I and II from medium size upwards, and entities designated by the State |
| Digital examples | Large cloud, data centre or CDN provider; any DNS provider or TLD registry | Medium-sized cloud or managed service provider; online marketplace, search engine, social network |
| Supervision regime | Ex ante: inspections, regular and targeted audits, information requests without any prior incident | Ex post: checks triggered by evidence of non-compliance |
| Maximum fines | Ceiling of at least €10M or 2% of worldwide annual turnover, whichever is higher | Ceiling of at least €7M or 1.4% of worldwide annual turnover, whichever is higher |
| Incident notification | Early warning within 24 h, notification within 72 h, final report within one month | Same deadlines: Article 23 covers both categories |
| Management liability | Liability under Article 20, and a possible temporary ban from managerial functions | Liability under Article 20; no temporary ban provided for by the Directive |
What NIS2 does not directly cover
An organisation with fewer than 50 employees whose annual turnover or balance sheet total does not exceed €10M — a small enterprise in the EU sense — is in principle outside the Directive's scope, with exceptions: DNS providers, TLD registries, trust service providers, certain electronic communications networks, or an entity designated by its State for its critical role. That does not exempt it from any other obligation: the GDPR and sector-specific regulations apply independently.
However, if it supplies an in-scope entity, its client can contractually impose equivalent measures under supply chain security. That is the most common case for a web agency: not subject to NIS2 itself, but bound by the clauses of those who are.
The ten measures of Article 21
Article 21 of the Directive requires essential and important entities to take "appropriate and proportionate" technical, operational and organisational measures, based on an all-hazards approach that also protects the physical environment of systems. It sets a minimum list of ten areas covering the whole security lifecycle: from risk analysis to incident handling, through business continuity and the supply chain. Each measure must be proportionate to the entity's exposure, its size and the potential severity of incidents, and documented so it can be demonstrated to supervisory authorities. An entity that finds a gap must take the necessary corrective measures without undue delay.
The ten minimum measures (Article 21(2))
- Policies on risk analysis and information system security
- Incident handling
- Business continuity: backup management, disaster recovery and crisis management
- Supply chain security, including relationships with direct suppliers and service providers
- Security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure
- Policies and procedures to assess the effectiveness of risk management measures
- Basic cyber hygiene practices and cybersecurity training
- Policies and procedures on the use of cryptography and, where appropriate, encryption
- Human resources security, access control policies and asset management
- Multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communications, where appropriate
The measures that directly affect your hosting
Of the ten measures, four translate almost directly into infrastructure choices. For digital players, the Commission set out the technical requirements in Implementing Regulation (EU) 2024/2690 of 17 October 2024. It applies to DNS service providers, TLD registries, cloud, data centre and CDN providers, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers. If you are not one of them, it remains the most precise operational reference for what an auditor will expect from your host — and from you, if you administer your clients' infrastructure.
Four measures, translated into hosting choices
- Continuity and backups (Article 21(2)(c)): the implementing regulation calls for backup plans with a recovery time, proof that copies are complete, storage outside the system's network and far enough from the main site to survive a disaster, regular integrity checks and recorded restore tests. A provider that allows neither off-site backups nor proof of integrity does not help you meet this obligation.
- Cryptography (Article 21(2)(h)): a written policy sets the protocols, algorithms and key management practices, for data in transit as well as at rest. The choice of encryption is yours, but your host must let you implement it: TLS on every entry point, encrypted volumes, keys under your control.
- Access control and multi-factor authentication (Article 21(2)(i) and (j)): administration interfaces (hosting panel, SSH, virtualisation consoles) are protected by MFA and subject to least privilege. The host must offer MFA on its panel; SSH configuration is within your scope.
- Logging and detection (incident handling, Article 21(2)(b)): the implementing regulation requires logs kept and backed up for a predefined period, protected against unauthorised access or modification, synchronised clocks to correlate systems, and regular review with alarm thresholds. Retention, export to a SIEM or central platform, and log integrity are therefore concrete requirements.
What your VPS or dedicated server must concretely meet
Here is how these measures translate into configuration on a VPS or dedicated server.
Backups. The 3-2-1 rule remains good practice: three copies of the data, on two different media, one of them off-site. On a VPS, this means at least regular snapshots, plus an application backup exported to separate object storage, S3-compatible for example — a tool such as Restic does this while encrypting the data. Frequency follows from your RPO (Recovery Point Objective): for most critical web applications, 24 hours is a maximum. Document every restore test and repeat it at least once a quarter.
Encryption. TLS on every entry point (HTTPS, SMTP with STARTTLS, APIs), with a configuration that rejects obsolete versions (SSLv3, TLS 1.0, TLS 1.1); TLS 1.2 at minimum, TLS 1.3 preferably. At rest, encrypt the volumes holding sensitive data — LUKS for a Linux file system, native database encryption where available. Automate certificate renewal (ACME, Let's Encrypt or equivalent) to avoid uncontrolled expiry.
Access and MFA. Disable SSH password authentication — keys only, with PasswordAuthentication no in sshd_config. For high-value interfaces (hosting panel, virtualisation consoles), use MFA through a TOTP app or a FIDO2 hardware key. Give service accounts dedicated keys that can be revoked one by one, and audit the list of active access regularly. An SSH bastion centralises this access and its traceability.
Logs. Keep application logs (Nginx, Apache, PHP-FPM, databases) and system logs (auth, kernel, systemd) in a location the application itself cannot modify. Set in writing a retention period suited to your risks and detection times, longer for authentication and administration logs. Exporting to a central solution (remote syslog, Loki, Elasticsearch) preserves their integrity if the server is compromised.
Preparing for NIS2 compliance
Identify whether you or your clients are in scope
Locate each client's sector in Annexes I and II, then apply the size thresholds (headcount, turnover, balance sheet). National transposition laws and each State's competent authorities set out the exact scope and registration arrangements. If you supply an in-scope entity, reread your contract: your client can impose equivalent security requirements on you.
Inventory assets and suppliers
List the systems, applications and third-party services that process critical data, as well as the providers with access to the infrastructure (host, managed services, external developers, integrators). For each one, document the available security commitments — data location, certifications, incident procedures — and how much control you have over its access.
List every exposed administration interface
Hosting panel, SSH, RDP, database interfaces (phpMyAdmin, Adminer), monitoring consoles, management APIs: list everything. For each interface, check that MFA is enabled, that access is restricted by IP where possible, and date the last audit of active accounts.
Audit the backup policy
Answer the following questions: how often are backups taken? Where are they stored — same data centre or a separate site? Are they encrypted? Have you fully restored a service in the last 90 days? Do you have an RPO and RTO defined for each critical service?
Test the TLS configuration and certificates
Scan your domains with SSL Labs or
testssl.sh: no SSLv3, TLS 1.0 or 1.1, no deprecated algorithms (RC4, MD5, SHA-1 on certificates). Fix any grade below A. List production certificates with their expiry dates, check that renewal is automated, then remove orphaned SSH keys (disabled accounts, former contractors).Check log retention and integrity
Locate every log file (auth, nginx/apache, application, database) and measure its actual retention period. Check that authentication logs are not writable by the application account, that clocks are synchronised, and set up an export to secondary storage if not already done.
Set up incident handling
Define the detection, escalation and notification chain: who decides an incident is significant, who sends the early warning within 24 hours, who drafts the notification within 72 hours and the final report within one month, and through which channel you reach the CSIRT or national authority. Plan how you will reconstruct the course of events from the logs.
Choose providers with documented commitments
Favour hosts whose servers are located in the European Union, who produce security documentation (ISO 27001 or equivalent) and whose contracts clearly define responsibilities in the event of an incident. Require clauses on notification time and channel, the split of backup responsibilities, data portability and access to logs during an investigation.
Test and verify regularly
Schedule penetration tests, vulnerability scans and continuity exercises at defined intervals. Keep the reports and the proof of remediation: they are the documentary evidence expected during a NIS2 inspection, and the basis of the effectiveness assessment required by Article 21.
Your hosting provider is part of the NIS2 supply chain
For a client subject to NIS2, the host is not a provider like any other. Server location in the EU, contractual security commitments and documented incident notification procedures weigh directly in its compliance assessment. An availability SLA does not cover these dimensions: they have to be negotiated explicitly.
Choosing a host able to produce these elements simplifies your client's work and strengthens your agency's position as a trusted partner. If your client also belongs to the financial sector, the DORA regulation adds its own contractual requirements: see what DORA requires of ICT contracts.
Compliance: a three-phase roadmap
NIS2 compliance is not a one-off project but an ongoing risk management programme. For an organisation starting out, three phases are realistic.
Phase 1 — Scoping (1 to 2 months). Confirm you are in scope, identify the systems and services concerned (the NIS2 scope is not necessarily the whole information system), appoint a security lead and define roles. Produce a map of critical assets and a first documented risk analysis. Spot the most serious gaps: missing MFA, backups not stored off-site, no centralised logging.
Phase 2 — Priority technical measures (2 to 4 months). Deploy MFA on every administration interface. Set up or strengthen off-site backups, with a restore test. Audit and fix the TLS configuration. Centralise logs with a retention period defined in writing. Review provider access, update contracts and write the incident notification procedure.
Phase 3 — Ongoing programme. Build security into the development cycle (code reviews, dependency management, annual penetration tests). Run business continuity exercises. Train teams in cyber hygiene — and management, for whom training is mandatory. Document and test crisis management. Review the risk analysis at least once a year or after any major infrastructure change.
NIS2: a constraint that builds client trust
NIS2 is not an abstract regulation: it turns into obligations practices that most technical teams have recognised as sound for years — reliable backups, controlled access, usable logs, documented procedures. What changes is that they become enforceable, verifiable and punishable. The Directive requires States to provide, for infringements of Articles 21 and 23, fines with a ceiling of at least €10M or 2% of worldwide annual turnover for essential entities, and at least €7M or 1.4% for important entities.
For agencies delivering projects to these entities, it is also a concrete commercial argument: being able to show that the chosen hosting meets what the Directive requires — data location, security, incident handling — sets a serious offer apart from a generic one. Entities subject to NIS2 need providers who understand their constraints and let them document their choices. If you also publish software, the Cyber Resilience Act adds to NIS2 without replacing it: see what the CRA changes for your agency.
