NIS2 for Hosting & Digital Infrastructure: 2026 Compliance Checklist + Incident Runbook

The Network and Information Security Directive 2 (NIS2) entered into force across EU member states with national transpositions becoming enforceable through 2025 and into 2026. For hosting providers, DNS service operators, CDN operators, and digital infrastructure providers, NIS2 represents a significant expansion of cybersecurity obligations compared to the original NIS Directive.

This guide provides a practical compliance checklist and incident response runbook specifically tailored for hosting and digital infrastructure operators, with references to the directive's requirements and ENISA implementation guidance.

Who NIS2 applies to

NIS2 categorises entities into "essential" and "important" based on sector and size:

Digital infrastructure (essential entities)

Internet Exchange Point (IXP) providers
DNS service providers (authoritative and recursive)
TLD name registry operators
Cloud computing service providers
Data centre service providers
Content delivery network providers
Trust service providers

Digital providers (important entities)

Online marketplace providers
Online search engine providers
Social networking platform providers

Hosting providers

Hosting providers typically fall under "digital infrastructure" as cloud computing or data centre service providers. The exact classification depends on national transposition and the specific services offered. Small and micro enterprises (fewer than 50 employees and under €10M turnover) may be excluded in some member states, but this varies.

If you provide hosting services to customers in the EU, assume NIS2 may apply to you and act accordingly. The cost of compliance is manageable; the cost of non-compliance (fines up to €10M or 2% of global turnover for essential entities) is not.

Compliance checklist

1. Governance and risk management

NIS2 Article 21 requires "appropriate and proportionate" cybersecurity risk management measures.

Actions:

[ ] Designate a responsible person for NIS2 compliance (management body must be informed and accountable)
[ ] Conduct a risk assessment covering your hosting infrastructure, customer data, and dependencies
[ ] Document your risk management policy and review it annually
[ ] Ensure management body members receive cybersecurity training
[ ] Establish a risk register and track mitigation actions

2. Technical security measures

NIS2 Article 21(2) lists specific measures that must be addressed:

a) Policies on risk analysis and information system security:

[ ] Maintain written security policies covering all hosting infrastructure
[ ] Document asset inventory (servers, network equipment, software, services)
[ ] Classify assets by criticality

b) Incident handling:

[ ] Implement incident detection capabilities (monitoring, logging, alerting)
[ ] Document incident response procedures (see runbook section below)
[ ] Conduct incident response drills at least annually

c) Business continuity and crisis management:

[ ] Document backup and recovery procedures
[ ] Define RTOs and RPOs for critical services
[ ] Test backup restoration regularly
[ ] Maintain a crisis communication plan

d) Supply chain security:

[ ] Assess cybersecurity practices of critical suppliers (upstream providers, software vendors)
[ ] Include security requirements in supplier contracts
[ ] Monitor supply chain for vulnerabilities (dependency scanning, vendor advisories)

e) Security in network and information system acquisition, development, and maintenance:

[ ] Apply security-by-design principles to infrastructure changes
[ ] Perform vulnerability assessments on new deployments
[ ] Maintain a patch management process with defined timelines

f) Policies and procedures for assessing effectiveness:

[ ] Conduct regular security audits or assessments
[ ] Perform vulnerability scanning at least quarterly
[ ] Review and update policies based on assessment findings

g) Basic cyber hygiene practices and training:

[ ] Implement strong authentication (MFA for all administrative access)
[ ] Enforce least-privilege access controls
[ ] Provide cybersecurity awareness training to all staff

h) Cryptography and encryption:

[ ] Use TLS 1.2+ for all external communications (prefer TLS 1.3)
[ ] Encrypt data at rest for customer data and backups
[ ] Manage cryptographic keys securely

i) Human resources security and access control:

[ ] Implement role-based access control
[ ] Review access rights when staff change roles or leave
[ ] Use multi-factor authentication for all privileged access

j) Multi-factor authentication and secure communications:

[ ] MFA enabled for all administrative interfaces
[ ] Secure communication channels for internal operations (encrypted email, secure messaging)
[ ] Secure remote access (VPN with MFA, zero-trust network access)

3. Incident reporting obligations

NIS2 Articles 23–24 require mandatory incident reporting to the national CSIRT or competent authority:

Timeframe	Requirement
24 hours	Early warning: notify the competent authority of a significant incident
72 hours	Incident notification: provide initial assessment, severity, impact, and indicators of compromise
1 month	Final report: detailed description, root cause, mitigation applied, cross-border impact

What constitutes a "significant incident":

Causes or may cause severe operational disruption or financial loss
Has affected or may affect other natural or legal persons by causing considerable material or non-material damage

For hosting providers: an outage affecting multiple customers, a data breach involving customer data, a successful intrusion into infrastructure management systems, or a DDoS attack that degrades service beyond SLA commitments.

4. Registration and notification

[ ] Register with your national competent authority if required by national transposition
[ ] Designate a point of contact for NIS2 communications
[ ] Maintain up-to-date registration information

Incident response runbook

This runbook template covers the NIS2-aligned incident response lifecycle for hosting providers.

Phase 1: Detection and triage (0–1 hour)

Detect: monitoring alert, customer report, or third-party notification
Triage: assess severity using predefined criteria:
- Critical: infrastructure compromise, data breach, widespread service outage
- High: single-service outage, attempted intrusion with partial success
- Medium: degraded performance, failed intrusion attempt
- Low: minor issue, no customer impact
Classify: determine if this is a NIS2-reportable "significant incident"
Assemble: activate the incident response team based on severity

Phase 2: Early warning (within 24 hours for significant incidents)

Notify: submit early warning to national CSIRT/competent authority
- Include: date/time of detection, suspected type of incident, initial impact assessment
- Use the national authority's prescribed notification channel and format
Communicate: notify affected customers per your contractual obligations

Phase 3: Containment and investigation (1–72 hours)

Contain: isolate affected systems to prevent further damage
- Network isolation for compromised servers
- Credential rotation for potentially compromised accounts
- Traffic filtering for ongoing attacks
Investigate: determine scope, root cause, and indicators of compromise
- Preserve evidence (logs, disk images, network captures)
- Timeline reconstruction
- Identify affected systems and data
Submit 72-hour notification: provide initial assessment to competent authority
- Include: severity, impact scope, indicators of compromise, initial remediation steps

Phase 4: Remediation (72 hours – ongoing)

Remediate: fix the root cause
- Patch vulnerabilities
- Harden configurations
- Replace compromised credentials and certificates
Verify: confirm remediation is effective
- Re-scan for vulnerabilities
- Monitor for recurring indicators
Restore: return affected services to normal operation
- Phased restoration with monitoring
- Customer communication on service recovery

Phase 5: Post-incident (within 1 month)

Final report: submit to competent authority
- Detailed incident description
- Root cause analysis
- Remediation measures applied
- Cross-border impact assessment
Lessons learned: conduct post-incident review
- What was detected well?
- What was missed?
- What process improvements are needed?
Update procedures: apply lessons learned to policies, runbooks, and controls

Common mistakes

Assuming NIS2 doesn't apply to you. If you provide hosting, DNS, CDN, or cloud services to EU customers, it very likely does. Check with legal counsel familiar with your national transposition.

Treating NIS2 as a one-time checklist. Compliance requires ongoing risk management, regular assessments, and continuous improvement. It's a programme, not a project.

Not testing incident response before an incident. Run tabletop exercises at least annually. The first time you use your runbook should not be during a real incident.

Underestimating the 24-hour reporting requirement. Twenty-four hours from detection to initial notification is tight. Pre-prepare notification templates and ensure the on-call team knows the reporting channel and process.

Ignoring supply chain requirements. NIS2 explicitly requires assessing the security practices of your suppliers. If your upstream hosting provider or software vendor has a breach, you may be affected and required to report.

Verification

Review your NIS2 classification with legal counsel
Complete the compliance checklist above and document gaps
Test your incident response runbook with a tabletop exercise
Verify 24-hour notification process works: can you reach your national CSIRT within 24 hours on a weekend?
Review and update the checklist quarterly