NIS2 Compliance per Provider Hosting 2026: Incident Reporting 24-72 Ore, Asset Management Continuo e Architetture Cloud Resiliente – La Mia Checklist Operativa

Quando ho ricevuto la prima notifica da un cliente che chiedeva se il mio hosting era NIS2-compliant, ho capito che la transizione da una semplice conformità normativa a un’operatività resiliente richiedeva un ripensamento totale della mia architettura infrastrutturale. La NIS2 Directive non è una checklist documernica—è un sistema operativo che ridefinie come i provider hosting devono rilevare, documentare e segnalare gli incident in tempo reale, mantenendo una visibilità continua su asset e dipendenze cloud.

In questa guida, vi condivido la checklist operativa che ho implementato sui miei datacenter Plesk, le pipeline di incident response che ho testato sotto pressione, e come ho ristrutturato le architetture cloud per garantire resilienza dimostrabile ai regolatori. Anticipazione: scoprirete che il 24-72 framework di NIS2 non è sulla carta—è sulla vostra capacità di operare sotto pressione.

Chi Rientra in NIS2 e Perché i Provider Hosting Sono in Prima Linea

NIS2 classifica hosting e cloud provider come entità essenziali, soggette agli obblighi più stringenti: incident reporting entro 24 ore, accountability a livello di board, requisiti di supply chain security, e multa fino a €10M o 2% del fatturato globale. Nel mio caso, operando in Italia e con clienti in tutta Europa, rientro automaticamente come entità essenziale. Non c’è ambiguità: i provider di hosting con infrastruttura cloud superano i €10M di fatturato o 50+ dipendenti.

Questo significa che non posso delegare la responsabilità ai miei clienti—se il provider hosting subisce un incident che impatta le operazioni regolate, l’obbligo NIS2 (e la timeline) rimane con voi stessi come cliente. La cascata di accountability è unidirezionale verso di me.

Il Framework 24-72-30 nella Pratica: Come Ho Implementato l’Early Warning

Allora, come funziona davvero? Entro 24 ore deve arrivare una pre-notifica; entro 72 ore una notifica incident con assessment iniziale, inclusa severità, impact e, dove disponibile, gli indicator of compromise.

Ho creato un template operativo (riutilizzabile nel vostro ambiente):

1. Ora 0:00–2:00 – Detection & Escalation: La mia SIEM (Wazuh) correla anomalie; il Security Ops Center (SOC) interno mi avvisa. Ho definito una matrice di severità per stabilire se un incident è “significativo” secondo la norma.
2. Ora 2:00–12:00 – Early Warning Compilation: Raduniamo i team (IT Ops, Security, Legal). Compiliamo il modulo early warning: se sospettiamo malware, atto malevolo, o impact cross-border. Non è perfetto—è “veloce e vero”.
3. Ora 12:00–24:00 – CSIRT Notification: Notifichiamo il CSIRT italiano (ITA-CSIRT). L’early warning è volutamente disegnato come notifica rapida—velocità sopra completezza. Ma “rapido” non significa “informale”: il report deve essere sottomesso attraverso canali ufficiali e contenere gli elementi richiesti.
4. Ore 24–72 – Incident Notification: Faccio l’investigazione tecnica vera. Raccolgo gli IoC (Indicator of Compromise), valuto severity/impact, identifico i sistemi colpiti.
5. Giorno 30 – Final Report: Root cause, misure di remediation, evidenza di contention.

La timeline inizia quando chiunque nella vostra organizzazione—staff o terze parti—rileva un evento potenzialmente reportable, non quando l’investigazione IT finisce. Questo è stato il cambio di paradigma: non potete aspettare di avere tutte le risposte. Le autorità si aspettano anche report incompleti o preliminari se la chiarezza piena non è disponibile; comunicare “quello che sapete, quando lo sapete” vi guadagna credibilità e spesso riduce le penalità.

Asset Management Continuo: Il Mio Approccio Inventory-First

Uno dei gap più comuni che ho visto nelle audit di compliance? I provider non sanno cosa hanno in esercizio. Ho avuto un incidente dove, durante il reporting, non riuscivo a mappare un carico di lavoro al suo proprietario. Non vi auguro quella esperienza.

Ecco quello che ho implementato:

Fase 1: Asset Catalog Authoritative

Mantenere una visibilità completa del vostro landscape tecnologico: implementare un inventario autorevole di hardware, software e servizi cloud; classificare gli asset in base a criticità e sensibilità; documentare le dipendenze tra sistemi e servizi; mantenere diagrammi di rete e mappe di flusso dati aggiornate. Mantenere un “regulatory pack” per ogni servizio in-scope che includa diagrammi di architettura, flussi dati, liste di fornitori, playbook di incident response e prova di testing.

Io uso un foglio di calcolo centrale (sì, ho provato strumenti enterprise—il spreadsheet è più agile). Per ogni VM, container, servizio cloud:

• ID univoco (es. `HOST-PROD-001`)
• Proprietario (persona o team)
• Criticità (C1=mission-critical, C2=business, C3=support)
• Dati sensibili? (sì/no, se sì: tipo GDPR/PCI/health)
• Dipendenze verso altri asset
• Última patch/aggiornamento config
• Compliance attestato? (sì/data audit)

Fase 2: Continuous Discovery & Change Tracking

Ho integrato il mio Plesk control panel con script bash che ogni 4 ore esportano la lista dei container, VPS attive e domini. Qualsiasi delta rispetto allo snapshot precedente trigghera un alert. Un ambiente cloud che ha passato un check di compliance 6 mesi fa potrebbe non passare oggi. Il continuous monitoring per configuration drift, nuove tecniche di attacco e vulnerabilità emergenti è essenziale. NIS2 premia le organizzazioni che possono dimostrare una vigilanza continua, non solo sforzo periodico.

Ho scritto uno script Bash (potete adattarlo):

#!/bin/bash
# NIS2 Asset Discovery & Change Tracking
INVENTORY_FILE="/opt/nis2/asset_inventory.json"
LOG_FILE="/opt/nis2/asset_changes.log"
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")

cp /tmp/current_domains.json $INVENTORY_FILE


Questo è minimalista ma effettivo—ogni drift viene loggato e l’SOC può investigare prima che diventi un problema.

Architetture Cloud Resiliente: Beyond High Availability

NIS2 non parla di “99.9% uptime”—parla di provable recovery. NIS2 esplicitamente richiede che le organizzazioni implementino misure di continuità robuste—incluse backup management, disaster recovery e crisis-response capabilities—per assicurare che le entità essenziali e importanti possano mantenere le operazioni durante incident disruptive.

Ho riprogettato la mia infrastruttura attorno a 3 pilastri:

1. Multi-Region Active-Active (dove critico)

L’infrastruttura cloud ti permette di usare multiple regioni geograficamente separate; avere multiple zone configurate dentro una regione assicura l’operazione ininterrotta della regione anche se una zona (un intero datacenter) va persa. Puoi implementare architetture che rendono le soluzioni resilient alla perdita di un’intera regione—il contingency plan può affrontare il bisogno di un ambiente disaster recovery di produzione.

Per i clienti mission-critical (healthcare, fintech), ho distribuito i carichi su EU-West (Irlanda) e EU-Central (Francoforte). La replica è sincrona per i database critici, asincrona per contenuto statico. RTO (Recovery Time Objective) = 15 minuti; RPO (Recovery Point Objective) = 5 minuti.

2. Backup Immutabile & Air-Gapped

Dopo l’attacco ransomware del 2024 (che ho descritto in un articolo precedente), ho implementato backup che sono impossibili da criptare da remoto:

• Backup giornalieri su object storage S3 con versioning enabled
• Copia settimanale su storage locale isolato (non raggiungibile dalla rete production)
• Retention: 30 giorni online, 365 giorni in cold archive
• MFA obbligatorio per delete operations

Ho testato questi backup ogni mese—e documento la prova. Cloud-native DR trasforma la resilienza su 5 dimensioni: Opex over capex (eliminate idle standby infrastructure); Automation over complexity (replace manual recovery con Infrastructure-as-Code runbooks); Elastic scale over fixed capacity; Global reach over local limits; Continuous testing over occasional drills.

3. Incident Response Architecture: From Detection to Reporting

Ho connesso una pipeline SIEM-to-SOAR che automatizza metà della investigazione:

WAZUH (log aggregation)
↓
[Alert Correlation Rules]
↓
SOAR (Shuffle/Cortex XSOAR)
↓
[Automated Evidence Collection]
↓
[Incident Ticket + Notification]
↓
Team Engagement (se severity=HIGH)
↓
[24-hour CSIRT Notification]


Quando una brutta anomalia viene rilevata (es. credential abuse, data exfiltration pattern), il SOAR automaticamente:

1. Raccoglie i log rilevanti da tutte le fonti
2. Estrae gli IoC (indirizzi IP, hash file, domain names)
3. Crea un ticket Jira con assessment preliminare
4. Mi notifica via Slack (e email se severity=CRITICAL)

Questo mi ha tagliato il tempo medio di detection-to-escalation da 4 ore a 22 minuti.

Supply Chain Security: Auditing Your Vendors

NIS2 enfatizza che le organizzazioni sono solo quanto il loro vendor più debole, poiché i cybercriminali targetano i link deboli per raggiungere entità più grandi. Le organizzazioni devono assessare tutti i terzi fornitori di prodotti, software, hardware o componenti essenziali per il funzionamento dei sistemi di rete e informazione. Le entità essenziali e importanti devono eseguire approfonditi risk assessment dei vendor, valutando la qualità dei prodotti/servizi e resilienza, come i vendor mantengono il loro risk management, e includendo clausole specifiche nei contratti riguardanti la notificazione di incident, la conformità agli standard di sicurezza, e la condivisione di rapporti di audit.

Ho creato una vendor risk matrix che valuta:

I vendor ad alto rischio vengono riauditati prima di ogni rinnovo contrattuale. Article 21(2)(d) crea obblighi diretti per third-party risk: le entità devono assessare la postura di cybersecurity dei fornitori diretti, la qualità e resilienza dei loro prodotti e servizi, e la sicurezza delle pratiche di sviluppo dei fornitori. In pratica, questo significa estendere i programmi di third-party risk management per includere clausole contrattuali equivalenti a NIS2, obblighi di notificazione incident dei fornitori che permettono all’entità di incontrare la sua finestra 24-ore, e continuous monitoring dei fornitori ICT critici.

Governance Board-Level: Accountability Non è Opzionale

NIS2 mette il board in gioco. La gestione deve approvare le politiche, supervisionare i budget, e dimostrare competenza in cybersecurity. Una role map pratica: Board di Direttori → oversight strategico e risk appetite; CISO/Compliance Lead → implementazione giornaliera e reporting; IT Operations → deployment e monitoraggio dei controlli; Legal Counsel → liaison normativa e contratti.

Ho iniziato a portare un “cybersecurity risk report” mensile al nostro board. Include:

• Vulnerabilità critiche non ancora patchate (e timeline remediation)
• Incident detection trend (numero, severity, MTTD/MTTR)
• Vendor audit status
• Test di incident response (tabletop o simulazione)
• Compliance attestation stato

Article 20 tiene le management bodies di entità essenziali e importanti direttamente responsabili per approvare e supervisionare le misure di risk management di cybersecurity. Gli stati membri possono imporre responsabilità personale—incluse band temporanee da funzioni di management per executives di entità essenziali. Nel mio caso, c’è una firma esplicita da parte del mio AD sul documento di approvazione della cybersecurity policy.

Checklist Operativa: 30 Giorni a NIS2 Baseline

Se non sapete da dove partire, ecco il roadmap che ho usato:

Settimana 1: Assessment & Scoping

• ☐ Confermare che la vostra organizzazione è in-scope (>50 dipendenti? >€10M fatturato? Hosting/cloud? Sì = siete essenziali)
• ☐ Creare un asset inventory di tutti i sistemi in produzione
• ☐ Classif i 5-10 sistemi più critici per RTO/RPO
• ☐ Elencare i vendor terzi—chi ha accesso a dati sensibili?

Settimana 2: Incident Response Planning

• ☐ Definire “significativo” incident secondo NIS2 (severity matrix con criteri chiari)
• ☐ Compilare template 24-hour early warning & 72-hour notification
• ☐ Identificare il contatto CSIRT nel vostro paese
• ☐ Creare una contact list escalation (Security, IT, Legal, Management)
• ☐ Fare un tabletop exercise (simulazione di incident)

Settimana 3: Technical Hardening

• ☐ Implementare SIEM (Wazuh, Splunk, o equivalente)
• ☐ Enable MFA su tutti gli account administrator
• ☐ Implementare backup immutabile (S3 versioning + air-gap)
• ☐ Network segmentation: isolate production, staging, development
• ☐ Patch tutti i sistemi >30 giorni di lag

Settimana 4: Governance & Documentation

• ☐ Documentare tutte le policy di cybersecurity (risk mgmt, incident response, supply chain)
• ☐ Eseguire cyber training per staff (ENISA guidelines)
• ☐ Audit vendor compliance—chiedere ISO 27001 certs & SLA incident
• ☐ Board presentation: cybersecurity governance approval
• ☐ Set up audit trail: log tutte le modifiche a sistema critico per 12 mesi

FAQ

NIS2 si applica al nostro piccolo provider hosting in Italia?

NIS2 classifica provider cloud, hosting, datacenter, CDN, e DNS provider come entità essenziali, il tier di rischio più alto, soggetto a supervisione proattiva. La soglia di dimensione è generalmente 50+ dipendenti o €10M+ di fatturato. I provider DNS e i TLD registry sono in-scope indipendentemente dalla dimensione. Se fornite hosting o cloud in EU, siete in-scope automaticamente.

Qual è la differenza tra “early warning 24-ore” e “notificazione 72-ore”?

L’early warning a 24-ore è inteso solo per allertare le autorità. L’analisi tecnica profonda è riservata ai report 72-ore e 1-mese. Il 24-ore è “veloce e grezzo”—sospettate malware? Sì/no. Cross-border? Sì/no. È il 72-ore dove dovete fornire IoC, severity assessment, e sistemi colpiti.

Posso delegare NIS2 compliance al mio cloud provider?

Se un fornitore, MSP, o cloud provider subisce un incident che impatta le vostre operazioni regolate, l’obbligo NIS2 (e la timeline) rimane con voi stessi. Potete mitigare il rischio audittando i loro controlli, ma la responsabilità finale è vostra. Se AWS ha un breach, voi dovete comunque reportare al vostro CSIRT.

Cosa succede se mancate la deadline di 24-ore?

Le entità essenziali potrebbero essere multat fino a €10 milioni o 2% del fatturato globale, a seconda di quale sia più alto. Le entità importanti potrebbero essere multat fino a €7 milioni o 1.4% del fatturato globale. A parte le penalità finanziarie, gli organismi di supervisione nazionale possono ordinare audit di sicurezza obbligatori, misure correttive, e la senior management può essere ritenuta personalmente responsabile per negligenza e può essere bandita dalle posizioni di gestione. Non è una multa da €5000—è una minaccia alla continuità aziendale.

Come faccio a “provare” che sono NIS2-compliant ai regolatori?

Mantenete un “regulatory pack” per ogni servizio in-scope che includa diagrammi di architettura, flussi dati, liste di fornitori, playbook di incident response, e prova di testing. Questo rende più facile dimostrare la conformità durante audit o inchieste normative. Nel mio caso, mantengo una dashboard audit-ready che mostra: ultime patch applicate, risultati dei tabletop exercise, evidenza di inventory updates, vendor audit status, e incident response logs.

Conclusione: NIS2 è un’Operazione, Non una Checklist

NIS2 non valuta se un piano esiste. NIS2 valuta se un’organizzazione può consegnare un early warning coordinato, basato sui fatti, alle autorità entro 24 ore—mentre l’incident è ancora in corso. Non è un problema di documentazione. È un problema di sistema operativo.

Nei miei 10 anni di hosting management, la transizione verso NIS2 è stata la più disruptive. Non è solo su “più sicurezza”—è su provability in tempo reale. I regolatori non leggono il vostro documento di cybersecurity policy di 50 pagine. Leggono i vostri log di incident, gli IoC che avete estratto in 48 ore, e se riuscite a dimostrare che i vostri backup sono realmente recuperabili.

Se siete un hosting provider e non avete ancora iniziato, la finestra di opportunità si sta chiudendo. Se avete domande sulla vostra implementazione specifica NIS2 (Plesk, cPanel, Kubernetes, multi-cloud), lasciate un commento—sarò felice di aiutare.