Giugno 2026 segna un punto di non ritorno per i provider di hosting europei. La direttiva NIS2 non è più una linea guida teorica: è compliance obbligatoria. Nella mia esperienza di System Administrator che ha configurato infrastrutture critiche su Plesk, ho dovuto affrontare esattamente questi obblighi di incident reporting in tempo reale. Questo articolo non è accademico – è basato su ciò che ho implementato nei miei sistemi e ciò che vedo nelle audit che supporto per provider medi.
Il problema che stavo affrontando sei mesi fa era semplice ma critico: come faccio a reportare un incident significativo al CSIRT italiano entro 24 ore se non ho una procedura operativa testata? Non è una domanda retorica. Centinaia di provider in Europa si trovano nella stessa posizione. La NIS2 Directive, in particolare l’Articolo 23, impone una cascata di reporting con scadenze rigide: early warning 24 ore, notifica formale 72 ore, rapporto finale entro 1 mese.
Se non sei pronto entro la fine di giugno 2026, le sanzioni non sono teoriche: €10 milioni o il 2% del fatturato globale, a seconda di quale sia maggiore. E i dirigenti possono essere personalmente responsabili.
NIS2: Cos’è Veramente e Perché i Provider di Hosting sono in Prima Linea
La NIS2 Directive (Direttiva EU 2022/2555) è il framework di cybersecurity più stringente mai implementato in Europa. La direttiva stabilisce un quadro giuridico unificato per sostenere la cybersecurity in 18 settori critici in tutta l’UE.
Qui sta il punto critico per chi come me lavora nel settore hosting: NIS2 classifica provider cloud, società di hosting, data center, operatori CDN e provider DNS come entità essenziali, il livello di rischio più alto, soggetti a supervisione proattiva. Non c’è margine di manovra. Se gestisci un server, uno spazio web, una macchina virtuale per clienti terzi, sei entro il perimetro NIS2.
La soglia di dimensione è generalmente 50+ dipendenti o €10M+ di fatturato. I provider DNS e i registrar di TLD rientrano nell’ambito di applicazione indipendentemente dalle dimensioni.
Il Framework di Incident Reporting 24-72 Ore: Come Funziona in Pratica
Prima di entrare nei dettagli tecnici, devo dire che quando ho iniziato a implementare questo framework, mi sono scontrato con una realtà: nessuno sa cosa significhi realmente “entro 24 ore” quando un incident è ancora in corso al 3 del mattino con informazioni incomplete.
Un incident significativo (come un’interruzione completa del servizio o una violazione dei dati) deve essere reportato al CSIRT nazionale entro 24 ore (early warning), con una notifica dettagliata entro 72 ore, e un rapporto completo di root-cause entro un mese.
Ma cosa significa nella pratica? Ho trovato che la cascata operativa è:
- Early Warning (24 ore): Segnalazione anticipata entro 24 ore. Rapporto di incident entro 72 ore più una valutazione iniziale dell’impatto. Questo non è un rapporto completo – è una comunicazione veloce che dici: “Abbiamo un problem, ecco cosa sappiamo finora”.
- Incident Notification (72 ore): Deve contenere una valutazione iniziale dell’incident, inclusa la sua gravità e impatto. Gli indicatori di compromissione (IoCs) dove disponibili. È qui che il reporting diventa tecnicamente esigente. L’ente deve aver progredito sufficientemente l’indagine per fornire una valutazione consapevole della gravità, identificare i sistemi interessati e condividere IoCs utilizzabili che il CSIRT può distribuire ad altri enti a rischio.
- Final Report (30 giorni): Rapporto finale non oltre 1 mese dopo l’invio del rapporto di incident.
La sfida è che NIS2 non valuta se un piano esiste. NIS2 valuta se un’organizzazione può fornire un avviso anticipato coordinato e basato su fatti alle autorità entro 24 ore – mentre l’incident è ancora in corso. Questo cambia completamente l’approccio operativo.
Vulnerability Disclosure Management e il Ruolo dei Provider
Nel 2024-2025, ho notato un cambio di paradigma: vulnerability disclosure non è più responsabilità solo del team di sviluppo. Nel contesto NIS2, è un obbligo di compliance end-to-end per i provider di hosting.
Le entità devono avere processi di vulnerability handling e disclosure in vigore, incluse valutazioni regolari delle vulnerabilità e patch tempestivi delle vulnerabilità note.
Ma qui arriviamo a un problema concreto che ho affrontato: cosa significa “disclosure” quando scopri una vulnerabilità in un componente di terze parti (ad esempio, una vulnerabilità in un plugin Plesk)? NIS2 introduce una supervisione più ristretta della supply chain del software, ampliando le responsabilità di gestione delle vulnerabilità per includere strumenti di terze parti e richiedendo valutazioni dei rischi più complete. Le organizzazioni sono tenute a identificare e valutare i rischi potenziali all’interno delle loro catene di fornitura software – come vulnerabilità nei componenti esterni – e sono incoraggiate a utilizzare Software Bills of Material (SBOMs) per acquisire una visibilità più chiara sulla composizione del software.
Ho implementato un sistema con i miei clienti dove:
- Generiamo SBOM (Software Bill of Materials) per ogni stack server
- Monitoriamo CVE in tempo reale per ogni componente
- Abbiamo una procedura di patching progressivo che non interrompe il servizio
- Tracciamo ogni disclosure in un registro audit per NIS2
Gli SBOM accelerano l’identificazione dei componenti interessati durante gli incident fornendo una visibilità immediata di dove esistono componenti vulnerabili nell’organizzazione. Quando viene annunciata una nuova vulnerabilità zero-day, le aziende con SBOM possono cercare rapidamente il loro inventario per determinare l’esposizione e dare priorità agli sforzi di remediation. Questa capacità è cruciale per soddisfare i rigorosi tempi di reporting di NIS2, poiché le organizzazioni devono sapere cosa è interessato per reportare in modo accurato e rispondere efficacemente.
Supply Chain Risk Assessment: La Cascata di Conformità
Un aspetto che molti provider sottovalutano è che NIS2 non è un silo di compliance. Crea una cascata. Se un’azienda di energia elettrica (soggetta a NIS2) utilizza i tuoi servizi di hosting, la conformità NIS2 del cliente scorre verso di te tramite contratti e audit.
La cascata della supply chain integra aziende che non rientrano direttamente nell’ambito. Banche, ospedali, società energetiche e agenzie governative sono tutte regolate da NIS2. Ora stanno trasferendo i requisiti di conformità ai loro fornitori di hosting tramite contratti.
Ho visto clienti ricevere audit richieste da loro clienti finali – organizzazioni critiche che non sapevano nemmeno della NIS2. La documentazione richiesta? Prove che il tuo provider di hosting ha:
- Asset inventory aggiornato (quali server, quali sistemi operativi, quali versioni di software)
- Vulnerability assessment continuativo (come gestisci il patching?)
- Incident response plan testato (non un documento, ma un piano esercitato)
- Business continuity measures (backup, disaster recovery, RTO/RPO definiti)
- Audit trail per 90 giorni minimo (chi ha fatto cosa e quando)
NIS2 introduce valutazioni dei rischi coordinate attraverso le catene di fornitura ICT critiche. Il Gruppo di Cooperazione NIS, supportato da ENISA e dalla Commissione Europea, può condurre valutazioni a livello UE di tecnologie specifiche, provider di servizi o rischi sistematici della catena di fornitura. Le organizzazioni devono monitorare questi risultati e adattare di conseguenza le valutazioni interne dei rischi dei fornitori. Quando le autorità UE individuano vulnerabilità in determinati servizi ICT o provider cloud, le entità regolate devono valutare l’esposizione e implementare misure di attenuazione. Questo sposta la gestione dei rischi dei fornitori verso una governance guidata dall’intelligenza piuttosto che da liste di controllo periodiche.
Come Ho Implementato la Compliance NIS2 nei Miei Sistemi Plesk
Non sto parlando in astratto. Quando ho dovuto implementare il framework NIS2 per i miei client, ho dovuto creare procedimenti concreti su infrastrutture Plesk. Ecco cosa ho fatto:
Step 1: Incident Detection e Alert Aggregation
Ho collegato Plesk al nostro SIEM (ho descritto il setup completo in questo articolo su Plesk Incident Response Automation). Ogni evento critico – accesso non autorizzato, utilizzo CPU anomalo, file integrity violation – genera un alert centralizzato.
In Plesk, ho configurato:
- File integrity monitoring per i directory critici (/etc, /usr/local/psa, /var/www/vhosts)
- Failed login alerts (threshold: 5 tentativi falliti in 10 minuti)
- Privilege escalation detection via syslog
- Anomaly detection sui consumi di risorse
Step 2: Incident Classification Automatica
Ho implementato un sistema di triage automatico che classifica se un evento è “significativo” secondo NIS2:
È significativo se:
- Interrompe la disponibilità del servizio per > 15 minuti
- Compromette l’integrità di dati di clienti (> 100 account)
- Affetta la confidenzialità (credenziali, dati personali esposti)
- Ha potenziale impatto cross-border (clienti in altri Paesi UE)
Se un evento è classificato “significativo”, il sistema trigger automaticamente:
- Notifica al team management entro 1 ora
- Avvia la procedure di early warning (24h)
- Prepara il template per la notifica formale al CSIRT (72h)
Step 3: Early Warning Template e CSIRT Notification
Ho creato un template strutturato che il team deve compilare entro 24 ore. Non è narrativo – è fattuale:
“`
EARLY WARNING TEMPLATE – NIS2 Compliance
1. NOTIFICATION TIMESTAMP
Time of awareness: [ISO 8601]
Time of notification: [ISO 8601]
Delta: [X hours]
2. INCIDENT TYPE
☐ Malware/Ransomware
☐ Data Breach
☐ DDoS/Service Disruption
☐ Unauthorized Access
☐ Supply Chain Attack
☐ Other: ___
3. SEVERITY ASSESSMENT (preliminary)
☐ Critical (> 1000 affected, cross-border impact)
☐ High (100-1000 affected, single member state)
☐ Medium (< 100 affected, localized)
4. AFFECTED SYSTEMS
– Server: [IP/Hostname]
– Services: [List]
– Client accounts affected: [#]
5. PRELIMINARY ROOT CAUSE
[Best current hypothesis]
6. IMMEDIATE ACTIONS TAKEN
– [Action 1]
– [Action 2]
– [Action 3]
7. FIRST INDICATORS OF COMPROMISE (IoCs)
[IP, domain, hash, file path]
8. CSIRT CONTACT
Italian CSIRT (if Italy): cert-pa@certspa.it
Other Member States: [contact]
“`
Questo template è stato testato in simulazioni (che consiglio a tutti di fare almeno 2 volte l’anno). La prima volta che l’hai compilato sotto pressione, capirai cosa manca nella tua procedura.
Step 4: Vulnerability Disclosure Continua
Ho automatizzato il monitoring delle vulnerabilità usando script che:
- Scaricano giornalmente gli NVD feeds (National Vulnerability Database)
- Matchano contro l’inventario dei componenti installati (Plesk version, PHP version, OpenSSL, Apache, etc.)
- Generano un report di vulnerabilità aperte classified per CVSS score
- Suggeriscono patch/aggiornamenti con analisi di impatto
- Documentano ogni azione intrapresa per l’audit trail
Questo collega direttamente ai requirements di vulnerability assessment automation che ho descritto altrove.
Supply Chain Risk Assessment: La Checklist Pratica che Ho Sviluppato
Per NIS2 supply chain, ho creato una checklist che uso con i miei clienti provider. Non è teorica – è basata su ciò che gli auditor chiedono realmente:
Supplier Risk Assessment Checklist
- ☐ Vendor Inventory
- Elenco di tutti i fornitori critici (hardware, software, servizi cloud)
- Per ciascuno: SLA, data inizio relazione, criticality rating
- Documento con firme e date di approvazione
- ☐ Security Assessment
- Ha il fornitore certificazioni ISO 27001, SOC 2, equivalente?
- Ha policies documentate di incident response?
- Quale è il suo SLA per patching di vulnerabilità critiche?
- ☐ Contractual Clauses
- Il contratto include obblighi NIS2 espliciti (incident notification, SLA di patch)?
- Chi è responsabile del breach di dati del fornitore?
- Diritto di audit sui sistemi del fornitore?
- ☐ Ongoing Monitoring
- Come monitoro se il fornitore rimane conforme?
- Frequenza di review della security posture del fornitore?
- Process per escludere un fornitore se i rischi diventano inaccettabili?
- ☐ Incident Reporting Chain
- Se il fornitore ha un breach, come mi notifica?
- SLA per la notifica (entro quanto tempo)?
- Template standard di notifica?
I corpi di gestione devono approvare e supervisionare le misure di gestione dei rischi di cybersecurity. È importante che i dirigenti senior possono essere ritenuti personalmente responsabili per i fallimenti nel implementare controlli adeguati. Questa responsabilità si estende alla supervisione della cybersecurity di terze parti. I membri del board e i leader senior devono assicurare che i programmi di gestione del rischio dei fornitori siano efficaci, documentati e adeguatamente finanziati. La direttiva consente anche divieti temporanei su funzioni manageriali nei casi gravi di non conformità. Questo eleva la gestione del rischio dei fornitori a una questione di governance strategica piuttosto che a un dettaglio operativo.
PNRR e Finanziamenti Disponibili per NIS2 Compliance
Un aspetto positivo è che l’Italia ha riconosciuto che NIS2 compliance ha un costo. I fondi PNRR (Piano Nazionale di Ripresa e Resilienza) stanno finanziando esattamente ciò che devi implementare.
Con l’aumento esponenziale delle minacce cyber, la cybersecurity è diventata una priorità top nei programmi PNRR. Le spese ammissibili includono: firewall di prossima generazione (NGFW), soluzioni EDR (Endpoint Detection and Response), sistemi di backup e disaster recovery, piattaforme di awareness training sulla sicurezza, valutazioni di vulnerabilità e penetration testing, e consulenza GDPR/NIS2.
Il 2026 rappresenta un momento chiave per la cybersecurity delle imprese italiane. I fondi PNRR sono in piena fase di erogazione, la nuova programmazione europea 2021-2027 del Digital Europe Programme sta dispiegando le sue risorse e il focus politico sulla sicurezza informatica non è mai stato così forte. Le direttive europee NIS2 e il Cyber Resilience Act stanno imponendo nuovi standard di protezione, mentre gli attacchi informatici continuano a crescere in frequenza e sofisticazione.
I bandi principali se sei un provider medio:
- MIMIT (Ministero delle Imprese e del Made in Italy): Bandi per cloud security e cyber resilience
- ACN (Agenzia per la Cybersicurezza Nazionale): Programmi di accelerazione come Fucina Cyber Lab
- Regioni: Bandi territoriali per cybersecurity (varia per regione)
Se la tua infrastruttura è su Plesk e vuoi implementare NIS2 compliance, sfrutta questi fondi per:
- SIEM integration (come ho descritto)
- EDR deployment sui server
- Backup automation e disaster recovery
- Penetration testing periodico
- Audit e compliance consulting
La Checklist Implementazione Completa NIS2 per Provider Hosting (Giugno 2026)
ASSET MANAGEMENT E INVENTARIO
- ☑ Inventario completo di tutte le infrastrutture (server, rete, storage)
- ☑ Documentazione delle versioni di software in uso (SO, applicazioni, librerie)
- ☑ Mappa delle dipendenze tra sistemi (quale servizio dipende da quale)
- ☑ Classificazione dei dati per sensibilità (PII, creditworthiness, etc.)
- ☑ Tracking delle ultime date di patch per ogni componente
VULNERABILITY MANAGEMENT
- ☑ Scansione automatica settimanale di vulnerabilità
- ☑ SLA di patching definiti: critiche entro 7 giorni, alte entro 30, medie entro 90
- ☑ SBOM (Software Bill of Materials) generato automaticamente
- ☑ CVE monitoring real-time con alert
- ☑ Test di patch in staging prima del deployment
INCIDENT DETECTION E RESPONSE
- ☑ SIEM/Log aggregation configurato (ES: Plesk + ELK stack o Splunk)
- ☑ Detection rules per incident significativi
- ☑ Incident response team designato con ruoli definiti
- ☑ 24/7 oncall rotation documentata
- ☑ Template pre-compilato per early warning (24h)
- ☑ Template per incident notification formale (72h)
- ☑ Simulation/drill almeno 2 volte l’anno
SUPPLY CHAIN SECURITY
- ☑ Vendor risk assessment completato per fornitori critici
- ☑ Contratti aggiornati con clausole NIS2
- ☑ Security assessment scorecards per ciascun fornitore
- ☑ Monitoring continuo della security posture dei fornitori
- ☑ Processo di escalation se un fornitore diventa non-conforme
GOVERNANCE E ACCOUNTABILITY
- ☑ Board/Direzione ha approvato la NIS2 compliance strategy
- ☑ Responsabile designato per cybersecurity (con chiare linee di accountability)
- ☑ Budget allocato e autorizzato
- ☑ Report trimestrale al board su KPI di security
- ☑ Training di awareness su NIS2 per tutto lo staff IT
DOCUMENTATION E AUDIT TRAIL
- ☑ Politiche di cybersecurity scritte e approvate
- ☑ Log retention per minimo 90 giorni
- ☑ Audit trail per accessi a sistemi critici
- ☑ Change management log (chi ha modificato cosa e quando)
- ☑ Backup dei log per verificare l’integrità storica
BUSINESS CONTINUITY
- ☑ RTO (Recovery Time Objective) e RPO (Recovery Point Objective) definiti
- ☑ Backup automatici con verifica di restore almeno 1 volta l’anno
- ☑ Disaster recovery plan documentato
- ☑ Replica geografica per dati critici (se applicabile)
FAQ
Se faccio incident reporting a 18 ore invece che 24, è conforme?
Sì, e in realtà è quello che dovresti fare. Secondo le statistiche di ENISA per il primo anno di implementazione di NIS2, il 73% degli avvisi anticipati è stato presentato entro 18 ore dal rilevamento, suggerendo che la maggior parte delle organizzazioni sta trattando il termine di 24 ore come massimo piuttosto che come target. Il framework dice “non oltre 24 ore”, non “esattamente a 24”. In pratica, più veloce è, meglio è.
Cosa faccio se scopro una vulnerabilità in Plesk stesso e non so se un mio cliente è interessato?
Prima cosa: non è necessario che tu sappia subito. È necessario che tu abbia una procedura per scoprirlo entro 72 ore. Se Plesk rilascia una patch per una vulnerabilità critica, tu devi: (1) Capire quali dei tuoi server Plesk sono interessati, (2) Tracciare quali clienti girano su quei server, (3) Pianificare il patching, (4) Documentare tutto. Un SBOM automatico ti aiuta enormemente qui.
Come concilio NIS2 incident reporting con GDPR se è una data breach?
Un singolo attacco ransomware su un provider di hosting potrebbe attivare sia l’early warning di 24 ore di NIS2 al CSIRT nazionale sia la notifica di 72 ore del GDPR all’autorità per la protezione dei dati. Leggi diverse, autorità diverse, scadenze diverse, entrambe applicabili contemporaneamente. Non è uno o l’altro – è parallelo. Devi avere un processo che gestisce entrambi simultaneamente. Nella pratica, io ho un unico incident ticket che genera tre notifiche diverse (NIS2, GDPR, clienti) in base al tipo di incident.
Se sono un provider piccolo (< 50 dipendenti e < €10M fatturato), devo comunque fare NIS2?
Dipende. Se sei un provider DNS o di TLD, sì, obbligatoriamente, indipendentemente da dimensione. Se sei un provider di hosting web tradizionale, tecnicamente < 50 dipendenti potresti rientrare nella categoria "important entities" anziché "essential", con obblighi leggermente meno stringenti. Ma il trend è che i clienti ti chiederanno la compliance NIS2 comunque (perché loro sono soggetti e devono auditare i loro fornitori). Consiglio: prepara la compliance full anyway.
Quale è la sanzione se un incident significativo NON viene reportato entro le scadenze?
NIS2 classifica i provider di hosting e cloud come entità essenziali, soggette agli obblighi più stringenti: incident reporting di 24 ore, responsabilità a livello di board, requisiti di sicurezza della supply chain, e ammende fino a €10M o 2% del fatturato globale. Inoltre, i dirigenti senior possono essere personalmente ritenuti responsabili per i fallimenti nell’implementare controlli adeguati. Non è solo una multa aziendale – è responsabilità personale.
Conclusione: Giugno 2026 non è una Data Lontana
La compliance NIS2 per provider di hosting non è un’aspirazione – è un obbligo operativo con deadline a Giugno 2026. Il termine per le entità in-scope per completare il primo audit di conformità NIS2 è stato fissato al 30 giugno 2026.
Nella mia esperienza di configurazione di infrastrutture su Plesk, ho visto cosa succede quando aspetti troppo: gli ultimi 3 mesi diventano caotici. Ticket di audit che arrivano, scopri buchi nella documentazione, SIEM non è davvero configurato, la procedura di incident response non è mai stata testata.
Se non hai ancora iniziato, la checklist che ho fornito è il tuo punto di partenza. Se hai clienti finali soggetti a NIS2, loro ti chiederanno questa compliance. Usa i fondi PNRR disponibili in Italia per implementare l’infrastruttura (SIEM, EDR, vulnerability scanning) che altrimenti dovrebbe uscire dal tuo budget.
E soprattutto: test il tuo incident response plan con una simulazione reale. È l’unico modo per scoprire cosa non funziona prima che accada davvero.
Se sei un System Administrator o provider che ha già iniziato la journey NIS2, il mio articolo su Plesk incident response automation potrebbe esserti utile per automatizzare la detection parte. E se hai domande sulla tua specifica compliance posture, commenta qui sotto – sono sempre disponibile a discutere le sfide reali che i provider affrontano.