Incidente significativo in un data center: la soglia è un’ora, non un giudizio

Nella maggior parte dei capitolati, un disservizio è «rilevante» quando qualcuno lo giudica tale: il cliente si lamenta, il fornitore minimizza, e la distanza fra i due resta contrattuale. Il regolamento di esecuzione (UE) 2024/2690 della Commissione, per chi gestisce un data center, chiude questa discrezionalità con una misura: un’ora. Non «un disservizio prolungato» — un numero che si legge sull’orologio, dall’inizio della limitazione alla sua fine. Sopra quella soglia, il disservizio smette di essere una questione fra fornitore e cliente e diventa un obbligo verso l’autorità.

Un regolamento direttamente applicabile, a una lista precisa di soggetti

Il regolamento di esecuzione (UE) 2024/2690 della Commissione, del 17 ottobre 2024, dà attuazione alla direttiva (UE) 2022/2555 — la NIS2 — per i requisiti tecnici e metodologici delle misure di gestione dei rischi di cibersicurezza e per l’ulteriore specificazione di quando un incidente è significativo. Si rivolge a una lista precisa: fornitori di servizi DNS, registri dei nomi di dominio di primo livello, servizi di cloud computing, servizi di data center, reti di distribuzione dei contenuti, fornitori di servizi gestiti e di sicurezza gestiti, mercati online, motori di ricerca online, social network e prestatori di servizi fiduciari. Firmato dalla presidente Ursula von der Leyen, entra in vigore venti giorni dopo la pubblicazione in Gazzetta ufficiale UE ed è «obbligatorio in tutti i suoi elementi e direttamente applicabile in ciascuno degli Stati membri». Abroga il regolamento (UE) 2018/151.

Chi rientra fra queste categorie, e chi in Italia sia soggetto essenziale o importante, va verificato secondo la NIS2 e il suo recepimento — non presunto perché si gestisce una sala macchine. Dalla qualificazione di «significativo» discendono obblighi di notifica, con termini stretti fissati dalla direttiva, non da questo regolamento.

L’articolo 8: quattro criteri, e ne basta uno solo

Vale la pena riportarlo per intero, perché ogni lettera pesa: «Articolo 8 — Incidenti significativi riguardanti i fornitori di servizi di data center. Per quanto riguarda i fornitori di servizi di data center, un incidente è considerato significativo a norma dell’articolo 3, paragrafo 1, lettera g), se soddisfa uno o più dei criteri seguenti: a) un servizio di data center di un data center gestito dal fornitore è completamente indisponibile; b) la disponibilità di un servizio di data center di un data center gestito dal fornitore è limitata per un periodo di tempo superiore a un’ora; c) l’integrità, la riservatezza o l’autenticità dei dati conservati, trasmessi o elaborati relativi alla fornitura di un servizio di data center è compromessa in ragione di un’azione che si sospetta essere malevola; d) l’accesso fisico a un data center gestito dal fornitore è compromesso.» Quattro criteri indipendenti: ne basta uno.

a) Indisponibilità completa — il blackout totale di un servizio di data center.
b) Disponibilità limitata oltre un’ora — sposta davvero il perimetro: conta anche il degrado, non solo l’interruzione totale. Settanta minuti di degrado soddisfano questo criterio; un blackout di cinquanta minuti no, per questa lettera.
c) Integrità, riservatezza o autenticità compromesse — un accesso sospetto ai dati è un incidente significativo anche a servizio acceso.
d) Accesso fisico compromesso — una porta forzata, un varco lasciato aperto, un badge usato da chi non doveva: cibersicurezza senza che sia stato toccato un byte.

I criteri che valgono comunque, e la manutenzione che non conta

L’articolo 8 non sostituisce i criteri generali dell’articolo 3, che valgono comunque. Fra i più diretti per chi tiene i conti di una sala: una perdita finanziaria «superiore a 500 000 EUR o, se tale importo è inferiore, al 5 % del suo fatturato totale annuo dell’esercizio precedente»; «l’esfiltrazione di segreti commerciali, quali definiti all’articolo 2, punto 1), della direttiva (UE) 2016/943»; il decesso di una persona fisica o «danni considerevoli alla salute di una persona fisica»; oppure «un accesso non autorizzato ai sistemi informativi e di rete, che si sospetta essere malevolo ed è in grado di causare gravi perturbazioni operative». Vi si aggiungono i rinvii all’articolo 4 e agli articoli da 5 a 14 — fra cui l’articolo 8 stesso.

Una precisazione evita un allarme inutile, scritta nello stesso articolo 3: «Le interruzioni programmate del servizio e le conseguenze previste delle operazioni di manutenzione programmata effettuate dai soggetti pertinenti o per loro conto non sono considerate incidenti significativi.» Una finestra di manutenzione concordata, per quanto lunga, non fa scattare nulla — a patto che sia davvero programmata.

Come lo verifichiamo noi

Quando scriviamo o revisioniamo un capitolato per una sala dati, la soglia di un’ora non resta un riferimento astratto: la trasformiamo in una definizione contrattuale, con l’evento che fa partire il conteggio e lo strumento che lo misura. Verifichiamo che gli accessi fisici siano registrati in modo tracciabile — chi, quando, con quale autorizzazione — e che esista già, dal primo giorno, un registro dei guasti con la causa di fondo: è l’unico modo per applicare l’articolo 4. In accettazione controlliamo che gli strumenti dichiarati esistano, non restino una promessa sulla carta.

Vedi il servizio · Parlane con un tecnico

L’articolo 4: quando due incidenti minori ne fanno uno significativo

Restano gli incidenti che, presi singolarmente, non superano nessuna soglia: «Gli incidenti che singolarmente non sono considerati un incidente significativo ai sensi dell’articolo 3 sono considerati collettivamente come un unico incidente significativo se soddisfano tutti i criteri seguenti: a) si sono verificati almeno due volte nell’arco di sei mesi; b) presentano la stessa causa di fondo apparente; c) soddisfano collettivamente il criterio di cui all’articolo 3, paragrafo 1, lettera a).»

Tre condizioni cumulative, non alternative: servono tutte e tre insieme. Il punto pratico è nella lettera b): per accorgersi che due eventi condividono «la stessa causa di fondo apparente» serve un registro che la scriva, non solo la data del guasto. Senza, tre micro-eventi in sei mesi restano righe scollegate — e nessuno nota che, sommati, sono diventati un incidente significativo.

Da dove si conta l’ora, e chi decide che è «limitata»

Il regolamento lascia aperte domande che il capitolato deve chiudere. Da dove parte il conteggio dell’ora: dal momento in cui l’allarme scatta, da quello in cui il monitoraggio rileva il degrado, o da quando arriva il primo ticket? Se l’ora la si ricostruisce a posteriori rileggendo i ticket, non è una misura, è una stima fatta dopo — lo stesso vizio di una clausola di disponibilità senza MTTR dichiarato. Chi decide che è «limitata», e con quale soglia: il regolamento non lo definisce — deve farlo il capitolato, con una soglia misurabile concordata prima, non giudicata dopo da chi la subisce. E un accesso fisico compromesso lascia traccia solo se il controllo accessi lo registra, non se qualcuno se ne accorge per caso.

Checklist: che cosa scrivere in capitolato, che cosa verificare in accettazione

definire contrattualmente da quale evento parte il conteggio dell’ora, e con quale strumento si misura;
fissare per «disponibilità limitata» una soglia misurabile concordata, non lasciata al giudizio di chi la subisce;
richiedere che gli accessi fisici siano registrati in modo da poter dimostrare, a distanza di mesi, chi è entrato, quando e con quale autorizzazione;
tenere un registro dei guasti con la causa di fondo e la data — è l’unico modo di applicare l’articolo 4;
in accettazione, verificare che gli strumenti di misura dichiarati esistano e siano quelli promessi, e che il registro sia già popolato dal primo giorno.

I due assi valgono qui più che altrove. Adempiere: soglie, punti di misura e registrazione degli accessi diventano righe verificabili del capitolato e punti di collaudo, con la traccia da esibire. Decidere: tracce, misure e as-built smettono di essere file sparsi e diventano una mappa unica su cui un’AI fa la diagnosi e la squadra interviene, insieme a CSIDIA, l’altra società del gruppo — la stessa logica delle classi di disponibilità EN 50600 vale per il cablaggio e l’accesso fisico. Il registro delle cause di fondo non serve solo all’articolo 4: dice se un degrado si ripete sullo stesso ramo, prima che la somma superi la soglia. Sempre on-premise, su macchine autonome senza integrazione profonda nella rete del cliente, o cloud dedicato con data center in Italia; sempre con gestione condivisa, nei data center che seguiamo.

Dovete verificare se il vostro data center rientra fra i soggetti del regolamento, o tradurre la soglia di un’ora in una riga di capitolato? Parlatene con un tecnico: la prima sessione è senza costi.