DORA, NIS2 e status page: trasformare la comunicazione di incidente in prova di conformità UE

⚡TL;DR

• DORA Articolo 19 impone una notifica iniziale 4 ore dopo la classificazione di un incidente grave (24 ore al massimo dopo il rilevamento), un rapporto intermedio a 72 ore e un rapporto finale a 1 mese, cifre ufficiali confermate dagli RTS/ITS JC 2024-33 pubblicati dalle ESA il 17 luglio 2024.
• NIS2 Articolo 23 impone un preallarme a 24 ore, una notifica a 72 ore e un rapporto finale a 1 mese, applicabile a 18 settori essenziali e importanti in Europa.
• Una status page pubblica marcata temporalmente, archiviata ed esportabile in JSON soddisfa le tre proprietà di una prova opponibile: marca temporale RFC 3339 UTC, audit trail immutabile, accessibilità pubblica verificabile.
• L'ACPR segnala nel suo bilancio degli 8 mesi di DORA (gennaio 2026) che le scadenze di 4 ore sono « ancora raramente rispettate ». Il 2026 segna la fine della tolleranza e l'inizio dell'enforcement attivo.
• Il rischio ICT terzo (DORA Articolo 28) impone una revisione contrattuale del fornitore di status page: giurisdizione, localizzazione dei dati, exit strategy, diritto di audit.

Il 15 gennaio 2026, l'ACPR ha pubblicato il suo bilancio dei primi otto mesi di applicazione del Regolamento DORA concludendo che le scadenze di notifica di quattro ore sono « ancora raramente rispettate » dalle entità finanziarie francesi. A Francoforte e a Lussemburgo, BaFin e CSSF osservano una constatazione equivalente. Sul fronte della Direttiva NIS2, 22 dei 27 Stati membri hanno trasposto il testo al 1° aprile 2026: la Germania ha messo in vigore il NIS2UmsuCG il 6 dicembre 2025, l'Italia applica il decreto legislativo 138/2024 dal 16 ottobre 2024, la Francia attende la promulgazione della Loi Résilience adottata il 26 febbraio 2025.

In questo scenario, una domanda operativa si ripropone a ogni audit di conformità DORA: come fornire la prova che una notifica di incidente è stata effettivamente emessa entro i termini? Le e-mail interne si perdono, i ticket ServiceNow si chiudono, gli screenshot sono contestabili. Resta un artefatto pubblico, marcato temporalmente, accessibile a qualsiasi ora dall'esterno: la status page. Tuttavia, per la maggior parte dei SaaS B2B europei, questa pagina rimane uno strumento di comunicazione marketing, non un deliverable di audit. Il ribaltamento normativo avvenuto fra il 2024 e il 2026 cambia radicalmente questo status.

Questo articolo si rivolge ai direttori tecnici, ai responsabili della sicurezza delle informazioni, ai responsabili SRE e ai responsabili della protezione dei dati che devono pilotare la conformità DORA e la conformità NIS2 di un SaaS B2B europeo. Si articola in tre tempi: una parte didattica sulle normative, una parte operativa sull'anatomia di una status page conforme, e una parte checklist per preparare un controllo. Uscirà con una mappatura unificata delle scadenze, un modello di export JSON allineato ai template RTS/ITS DORA, un framework in sette tappe e una checklist di venticinque punti.

La constatazione di partenza è semplice: la status page pubblica riunisce, senza sovraccosto tecnico, le tre proprietà di una prova documentale. Occorre però che sia concepita in tale spirito. Le sezioni che seguono mostrano come trasformare uno strumento operativo in un deliverable di audit, basandosi sui testi ufficiali (EUR-Lex, RTS/ITS ESA, ANSSI, ACPR, BaFin, CSSF, Banca d'Italia) e sui riscontri pubblici più recenti.

Perché la status page entra nel perimetro di audit UE nel 2026

La status page pubblica è stata a lungo percepita come una vetrina. Serviva a rassicurare i clienti durante un incidente, a evitare una saturazione del supporto, a segnalare una finestra di manutenzione. Nel 2026 cambia funzione. I supervisori europei, con l'ACPR in testa, ritengono ormai che una comunicazione pubblica di incidente marcata temporalmente faccia parte integrante del dossier di conformità ICT, senza nominarla formalmente « prova » nei testi, ma convocandola sistematicamente durante i controlli documentali.

Lo slittamento normativo: dalla pagina di cortesia all'artefatto di audit

Tre elementi spiegano questo ribaltamento. Anzitutto, la fine del periodo transitorio del Regolamento DORA. Il Regolamento (UE) 2022/2554 è entrato in applicazione il 17 gennaio 2025. I primi otto mesi sono serviti come periodo di osservazione, durante il quale i supervisori non hanno applicato sanzioni di massa. A partire dal primo trimestre 2026, l'ACPR, la BaFin, la Banca Centrale del Lussemburgo e la Banca d'Italia hanno confermato di essere passate alla modalità enforcement attivo. Inoltre, la trasposizione di NIS2 si generalizza. Al 1° aprile 2026, 22 Stati membri su 27 hanno adottato un testo nazionale, il che copre la maggior parte degli operatori economici europei. Infine, l'ENISA ha pubblicato nell'ottobre 2025 il suo Threat Landscape che documenta un'intensificazione degli incidenti ICT, spingendo i supervisori a inasprire la loro esigenza di trasparenza.

Tre forze convergenti: regolamentazione finanziaria, sicurezza delle reti e supply chain

DORA si applica alle entità finanziarie e ai loro fornitori ICT critici. NIS2 copre 18 settori (energia, salute, trasporti, digitale, alimentazione, infrastrutture pubbliche, eccetera). Per un editore SaaS B2B europeo coesistono due scenari. Primo scenario: l'editore è esso stesso operatore essenziale o importante ai sensi di NIS2 (ad esempio un cloud provider, un fornitore di servizi gestiti, un editore di firma elettronica qualificata). È quindi soggetto direttamente a NIS2. Secondo scenario: l'editore eroga servizi a una banca, a un assicuratore, a una fintech soggetta a DORA. Diventa quindi un fornitore ICT ai sensi dell'Articolo 28 del Regolamento DORA, e il suo cliente deve contrattualizzare obblighi di resilienza, auditabilità e reporting verso il proprio supervisore. In entrambi i casi, la status page esce dal perimetro marketing per entrare in quello contrattuale e normativo.

Anche la catena di fornitura entra in gioco. NIS2 Articolo 21 paragrafo 2 impone una gestione esplicita dei rischi legati ai fornitori e alla supply chain. Un guasto non comunicato di un subappaltatore può essere imputato all'operatore principale. La status page funge allora da meccanismo contrattuale di notifica fra gli anelli della catena.

Cosa dicono i supervisori nella pratica

Le posizioni pubbliche convergono. L'ACPR, tramite il suo portale OneGate e la sua FAQ DORA, insiste sulla tracciabilità delle notifiche. La BaFin tedesca, nel suo articolo ufficiale sul reporting DORA, richiede la coerenza fra la comunicazione pubblica e il rapporto normativo. La CSSF lussemburghese ha pubblicato le circolari 25/892 e 25/893 nel maggio 2025, che dettagliano la classificazione e il reporting. L'ANSSI, in Francia, opera il portale MonEspaceNIS2 che centralizza le notifiche NIS2 per gli operatori essenziali e importanti. Il messaggio è uniforme: occorre una traccia pubblica marcata temporalmente, e tale traccia non è opzionale. È un complemento strutturale al rapporto normativo confidenziale.

Di conseguenza, per i team operativi questo impone di ripensare la progettazione della status page come deliverable di audit fin dalla fase di architettura, e non come canale di comunicazione reattivo. È esattamente ciò che consente lo strumento status page CaptainDNS, concepito per produrre nativamente un artefatto opponibile.

Da ricordare: nel 2026 la sua status page può essere convocata come prova documentale dal supervisore. Concepirla così fin dall'inizio evita una rifacimento costoso al momento dell'audit.

Conformità DORA, l'articolo 19 nei dettagli: 4 h, 72 h, 1 mese

Il Regolamento (UE) 2022/2554, detto Regolamento DORA, si applica alle entità finanziarie europee e ai loro fornitori ICT critici. Il suo capitolo III, e più specificamente l'Articolo 19, disciplina la notifica di incidente ICT grave. Per un editore SaaS B2B che eroga servizi a una banca o a un assicuratore, la conformità DORA non è una questione giuridica astratta: è ciò che detta l'orchestrazione operativa di un incidente.

Ambito di applicazione: entità finanziarie e fornitori ICT critici

L'Articolo 2 di DORA elenca 20 categorie di entità finanziarie: enti creditizi, istituti di pagamento, prestatori di servizi di informazione sui conti, prestatori di servizi di crowdfunding, imprese di investimento, sedi di negoziazione, depositari centrali, controparti centrali, gestori di organismi di investimento collettivo, imprese di assicurazione e riassicurazione, intermediari assicurativi, fondi pensione aziendali, agenzie di rating, amministratori di indici di riferimento, prestatori di servizi su cripto-attività, repertori di cartolarizzazioni, fondi, eccetera. Tutte queste entità sono soggette direttamente a DORA.

Il capitolo V (Articoli da 28 a 44) estende per contratto gli obblighi DORA ai fornitori ICT. Se un fornitore è alla base di una funzione critica o importante (CIFA, Critical or Important Function Arrangement), le clausole contrattuali sono obbligatorie. Se un fornitore supera le soglie definite dalle ESA (European Supervisory Authorities: EBA, EIOPA, ESMA), può essere designato « fornitore terzo critico » (CTPP, Critical Third-Party Provider) e ricadere sotto vigilanza diretta.

Il trittico temporale: 4 h, 72 h, 1 mese

L'Articolo 19 impone tre scadenze per notificare un incidente ICT classificato come grave:

• Notifica iniziale: 4 ore dopo la classificazione dell'incidente come grave, con un limite massimo di 24 ore dopo il rilevamento.
• Rapporto intermedio: 72 ore dopo il rilevamento.
• Rapporto finale: 1 mese dopo il rilevamento.

Nello specifico, il dettaglio delle scadenze e dei campi obbligatori figura nel documento finale degli standard tecnici JC 2024-33 pubblicato il 17 luglio 2024 dalle tre autorità europee EBA, EIOPA ed ESMA. Si tratta di Regulatory Technical Standards (RTS) e Implementing Technical Standards (ITS) che precisano il contenuto atteso di ciascun rapporto. La notifica iniziale deve contenere nove campi: identità dell'entità, marca temporale del rilevamento, marca temporale della classificazione, descrizione preliminare, criteri di classificazione attivati (Articoli 17 e 18 DORA), impatto stimato, misure immediate adottate, prossimi passi previsti, contatto dedicato.

La classificazione si basa sui criteri dell'Articolo 18 DORA: materialità dell'impatto (numero di clienti coinvolti, durata, geografia, perdita di dati, criticità del servizio interrotto, gravità economica). La scadenza di 4 ore parte nel momento in cui l'entità conclude formalmente che l'incidente è « grave », non al rilevamento. In pratica, questa sfumatura cambia tutto: occorre documentare la catena decisionale (chi ha classificato, su quali criteri, a che ora UTC), pena la possibilità per il supervisore di riqualificare la scadenza e concludere per uno sforamento.

A chi notificare nella pratica a seconda della giurisdizione

Le entità notificano alla loro autorità nazionale competente:

• Francia: ACPR tramite il portale OneGate (formato JSON, senza firma elettronica richiesta). In caso di indisponibilità di OneGate (mezzanotte-4 h, domeniche), invio per e-mail a 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr.
• Germania: BaFin tramite il portale MVP (Meldungs- und Veröffentlichungsplattform), in formato XBRL.
• Lussemburgo: CSSF tramite il portale eDesk (Circolare 25/893), accompagnata da una matrice di classificazione standardizzata.
• Italia: Banca d'Italia tramite il suo portale dedicato agli incidenti DORA, in formato CSV o XML.

Per i CTPP designati, la vigilanza è congiunta fra ESA e supervisore nazionale, con un Joint Examination Team (JET) che può effettuare audit on site. Un editore SaaS B2B che eroga servizi a più banche europee può trovarsi a dover notificare più autorità in parallelo per uno stesso incidente, da cui l'interesse critico di un formato pivot tipo JSON sfruttato dalla propria status page, in linea con la logica del monitoring DNS resiliente documentato in precedenza.

Sanzioni Articoli da 50 a 58

DORA prevede sanzioni amministrative pesanti. Per le entità finanziarie: fino al 2 % del fatturato annuo mondiale o 10 milioni di euro (il più elevato), con sanzione individuale che può arrivare a 1 milione di euro per i responsabili. Per i CTPP: fino all'1 % del fatturato giornaliero medio mondiale, per un massimo di sei mesi. Oltre alle sanzioni pecuniarie, le sanzioni vengono pubblicate (Articolo 54), il che aggiunge un costo reputazionale significativo. Il bilancio ACPR del gennaio 2026 precisa che la fase di enforcement attivo è iniziata nel primo trimestre 2026, ma senza citare ancora alcun caso pubblico sanzionato: segnale che i supervisori preparano in silenzio i loro dossier.

Da ricordare: 4 ore dopo la classificazione, deve disporre di 9 campi obbligatori pronti per la trasmissione. Se la sua status page esporta già questi campi, ha vinto l'essenziale della corsa.

Conformità NIS2, l'articolo 23 e la cascata 24 h, 72 h, 1 mese

La Direttiva (UE) 2022/2555, detta Direttiva NIS2, completa il Regolamento DORA coprendo tutti i settori essenziali e importanti al di fuori della finanza pura. Il suo Articolo 23 fissa una cascata di notifica distinta, più ampia nel perimetro e con un punto di partenza diverso. Per un SaaS B2B europeo, la conformità NIS2 si applica spesso in parallelo a quella DORA, e orchestrare i due quadri è la sfida operativa principale del 2026.

Perimetro esteso: diciotto settori e supply chain

Gli allegati I e II della Direttiva NIS2 elencano 18 settori. L'allegato I distingue i settori altamente critici (energia, trasporti, banche, infrastruttura dei mercati finanziari, salute, acqua potabile, acque reflue, infrastruttura digitale, gestione dei servizi informatici B2B, pubblica amministrazione, spazio), l'allegato II gli altri settori critici (servizi postali e di corriere, gestione dei rifiuti, fabbricazione, produzione e distribuzione di prodotti chimici, produzione e trasformazione di alimenti, fornitori di servizi digitali, ricerca). La dimensione dell'entità (≥ 50 dipendenti e fatturato ≥ 10 milioni di euro per lo status di « importante », soglie più elevate per « essenziale ») determina se rientra in NIS2.

NIS2 Articolo 21 paragrafo 2 lettera d impone la gestione della sicurezza della supply chain, compresi gli aspetti di sicurezza relativi alle relazioni dirette fra fornitori e prestatori. Una status page mal sfruttata da un fornitore può comportare la responsabilità dell'operatore essenziale o importante cliente.

Preallarme 24 h, notifica 72 h, rapporto finale 1 mese

L'Articolo 23 della Direttiva NIS2 organizza la notifica in tre tempi:

• Preallarme entro 24 ore dalla conoscenza di un incidente significativo.
• Notifica di incidente entro 72 ore dalla conoscenza, includendo una valutazione iniziale, indicatori di compromissione e una descrizione della gravità.
• Rapporto finale entro il mese successivo alla notifica, con analisi causale dettagliata.

Il punto di partenza critico: « conoscenza » (awareness), non « rilevamento » tecnico né « classificazione » formale. Non appena un team interno è a conoscenza di un incidente significativo, il contatore parte. Un incidente è « significativo » se ha causato o è suscettibile di causare una grave perturbazione dei servizi, perdite finanziarie ingenti, o se ha pregiudicato o è suscettibile di pregiudicare terzi causando danni materiali o immateriali considerevoli.

Trasposizioni nazionali nella primavera 2026

Lo stato dell'arte al 1° aprile 2026:

• Francia: Loi Résilience adottata dall'Assemblea nazionale il 26 febbraio 2025, promulgazione attesa nel primo semestre 2026. L'ANSSI opera il portale MonEspaceNIS2 e coordina il CERT-FR come CSIRT nazionale. Periodo di adeguamento: 3 anni dopo la promulgazione. Per seguire l'evoluzione della storicizzazione delle osservazioni, si veda la tracciabilità DNS pubblicata da CaptainDNS nel novembre 2025.
• Germania: NIS2UmsuCG promulgato il 5 dicembre 2025, in vigore il 6 dicembre 2025. Il BSI ha pubblicato i dettagli operativi: circa 30 000 entità interessate, registrazione obbligatoria entro 3 mesi, sanzioni di livello « board accountability ».
• Italia: decreto legislativo 138/2024 pubblicato il 4 settembre 2024, in vigore dal 16 ottobre 2024. L'ACN (Agenzia per la Cybersicurezza Nazionale) opera il portale di notifica, completato dal DPCM 221 del 9 dicembre 2024.
• Lussemburgo, Paesi Bassi, Belgio, Spagna, Portogallo, Polonia, paesi nordici, paesi baltici: trasposizione effettiva o imminente (iter parlamentare in corso).
• Cinque Stati in ritardo al 1° aprile 2026: rischio di procedure d'infrazione ai sensi dell'Articolo 258 TFUE.

Differenza fra la direttiva e il regolamento di protezione dei dati

NIS2 e GDPR si sovrappongono parzialmente. Un incidente può essere al contempo un « incidente significativo » NIS2 e una « violazione di dati personali » GDPR. Le notifiche sono allora parallele: CSIRT nazionale per NIS2, autorità per la protezione dei dati (Garante in Italia, CNIL in Francia) per il GDPR. Il termine GDPR Articolo 33 è di 72 ore « dopo averne preso conoscenza ». NIS2 aggiunge un preallarme a 24 ore, il che crea un obbligo supplementare. Per un editore che opera un servizio di storage SaaS che subisce un'intrusione coinvolgente dati personali, possono attivarsi tre canali di reporting (NIS2 + GDPR + DORA se il cliente è finanziario), da cui l'importanza di una fonte unica marcata temporalmente, che è precisamente la status page pubblica.

Da ricordare: sotto NIS2, il contatore di 24 h parte dalla conoscenza interna, non dopo la classificazione formale. Prepari le squadre a pubblicare un messaggio pubblico nelle prime 4 ore, per non dover fare tutto alla 23ª ora.

Mappatura unificata delle tre normative europee

La complessità operativa nasce dall'incrocio fra le tre normative. Per un editore che eroga servizi simultaneamente a entità finanziarie e a operatori essenziali NIS2, uno stesso incidente può innescare tre canali di notifica, con scadenze e destinatari diversi. La status page assume allora il ruolo di denominatore comune marcato temporalmente.

Tabella incrociata delle scadenze

Normativa	Fatto generatore	Termine iniziale	Intermedio	Finale	Autorità destinataria	Sanzione massima
DORA Articolo 19	Incidente ICT classificato come grave (Art. 17-18)	4 h dopo la classificazione (24 h max dopo il rilevamento)	72 h dopo il rilevamento	1 mese dopo il rilevamento	Banca d'Italia (IT) / ACPR (FR) / BaFin (DE) / CSSF (LU)	2 % fatturato mondiale o 10 M€ (entità) / 1 % fatturato giornaliero medio 6 mesi (CTPP)
NIS2 Articolo 23	Incidente significativo	24 h preallarme	72 h notifica	1 mese rapporto finale	CSIRT nazionale (ACN / CERT-FR / BSI / eccetera)	10 M€ o 2 % fatturato mondiale (essenziale) / 7 M€ o 1,4 % fatturato mondiale (importante)
GDPR Articolo 33	Violazione di dati personali	72 h dopo la conoscenza	n/a	(a seconda dell'inchiesta)	Garante (IT) o equivalente nazionale	20 M€ o 4 % fatturato mondiale

Fatto generatore: chi parte quando

Coesistono tre punti di partenza distinti. DORA parte dalla classificazione come incidente grave (formale, documentata, datata). NIS2 parte dalla conoscenza interna di un incidente significativo. Il GDPR parte dalla presa di conoscenza di una violazione. Il termine operativo più breve è di 4 ore (DORA), ma parte tardi (dopo la classificazione). Il più precoce è il preallarme NIS2 a 24 h, che può partire diverse ore prima della classificazione DORA.

Per i team ops, questo significa che un solo incidente può essere al contempo in anticipo NIS2 e in ritardo DORA, da cui la necessità di un registro comune e di un meccanismo di classificazione rapida. Sul fronte della supervisione, lo strumento monitor di uptime HTTP multi-regione fornisce la marca temporale tecnica oggettiva su cui poggia la classificazione.

A chi notificare: la mappatura completa per giurisdizione

Per i SaaS B2B che operano in più paesi europei, ecco la matrice dei destinatari:

• Italia: Banca d'Italia (DORA, tramite portale dedicato), ACN (NIS2), Garante (GDPR).
• Francia: ACPR (DORA), CERT-FR tramite MonEspaceNIS2 (NIS2), CNIL (GDPR).
• Germania: BaFin (DORA), BSI (NIS2), BfDI o autorità del Land (GDPR).
• Lussemburgo: CSSF (DORA via eDesk), GovCERT-LU (NIS2), CNPD (GDPR).
• Spagna: Banco de España e CNMV (DORA), INCIBE-CERT (NIS2), AEPD (GDPR).
• Paesi Bassi: DNB e AFM (DORA), NCSC-NL (NIS2), AP (GDPR).

L'idea di un punto di ingresso unico europeo avanza: il pacchetto Digital Omnibus presentato da Bird & Bird prevede un'armonizzazione entro 18 mesi dall'adozione. Nel 2026 questa armonizzazione non è ancora effettiva: occorre quindi pilotare manualmente le notifiche multiple, e la status page resta l'unico deliverable coerente per tutte le giurisdizioni.

---

Crei una status page conforme a DORA e NIS2 già oggi

---

Da ricordare: quando si applicano 3 normative, vince la finestra più breve, spesso 4 h DORA. La status page pubblica marcata temporalmente serve tutte e tre in parallelo.

La status page come prova documentale: perché gli auditor la chiedono

Una prova documentale in senso giuridico combina tre proprietà: marca temporale affidabile, immutabilità, accessibilità pubblica verificabile. Nessun altro artefatto tecnico di un SaaS B2B spunta le tre caselle contemporaneamente. I log interni non sono accessibili pubblicamente. I PDF post-mortem possono essere editati a posteriori. Le e-mail ai clienti non sono marcate temporalmente in modo crittografico. La status page pubblica soddisfa le tre condizioni, a condizione di essere stata concepita in tale spirito.

Tre proprietà probatorie: marca temporale firmata, archiviazione immutabile, audience pubblica

La marca temporale deve seguire l'RFC 3339 in formato UTC. È lo standard riconosciuto dall'insieme delle giurisdizioni europee per le operazioni elettroniche (eIDAS, eIDAS 2). La marca temporale in ora locale (CET, CEST, BST) è inaccettabile in quanto ambigua attorno ai cambi d'ora. La marca temporale qualificata ai sensi dell'RFC 3161, firmata da un Trust Service Provider qualificato, è ancora più solida giuridicamente, ma resta opzionale nella pratica fintanto che la marca temporale UTC è coerente e verificabile.

L'immutabilità poggia sull'audit trail: ciascun aggiornamento dell'incidente deve essere versionato, mai sovrascritto. Se corregge un messaggio alle 14:17 UTC dopo una pubblicazione alle 14:02 UTC, le due versioni devono restare accessibili, con la dicitura « modificato alle 14:17 ». Questa disciplina editoriale assomiglia alla prassi dei media online sulle correzioni fattuali.

L'accessibilità pubblica è ciò che distingue la status page da un log interno. La pagina deve essere consultabile senza autenticazione, da qualsiasi punto di Internet. Questo impone un'infrastruttura di hosting distinta dall'applicativo principale: se l'applicativo cade, la status page deve restare in piedi. È un'esigenza architetturale rafforzata dal DNSSEC attivo sul dominio status e da HTTPS rigoroso.

Caso Cloudflare R2 del 21 marzo 2025: modello di riferimento

Cloudflare ha documentato pubblicamente un incidente sul suo servizio R2 il 21 marzo 2025. L'azienda ha pubblicato un post-mortem dettagliato tre giorni dopo l'incidente. Lo svolgimento è esemplare: annuncio sulla status page alle 14:04 UTC (poco dopo l'inizio del degrado), aggiornamenti ogni 15-30 minuti, identificazione della causa radice (problema di configurazione storage), risoluzione annunciata alle 15:11 UTC, post-mortem completo il 24 marzo con timeline dettagliata, root cause, prossimi passi correttivi. La status page funge qui da perno temporale: marca temporalmente gli impegni operativi, e il post-mortem successivo vi fa esplicito riferimento.

Per un editore SaaS B2B europeo, questo modello è direttamente trasponibile. Non richiede strumenti esotici: richiede una disciplina editoriale e un formato di export strutturato.

Quando il fornitore di status page va esso stesso in panne

OneUptime ha documentato un caso rivelatore: fra il 2 e il 23 febbraio 2026, il modulo system metrics di Atlassian Statuspage è rimasto indisponibile per 21 giorni consecutivi. L'analisi pubblicata da OneUptime il 25 febbraio 2026 sottolinea il paradosso: un fornitore di status page che non riesce a mantenere lo SLA dei propri componenti non può servire da artefatto di audit per i suoi clienti. Il rischio concentrato su un fornitore unico diventa una vulnerabilità contrattuale diretta.

Bilancio ACPR a otto mesi: la tensione normativa di fronte alla realtà operativa

Il bilancio ACPR del 15 gennaio 2026 segnala che le scadenze di 4 ore sono « ancora raramente rispettate ». Questa constatazione non è un assegno in bianco: accompagna l'annuncio del passaggio alla modalità enforcement attivo. Il messaggio implicito: l'anno 2026 segna la transizione fra la tolleranza e la sanzione. Per le entità che non dispongono ancora di una status page conforme, il rischio di sanzione è concreto. Sul piano dei principi di sicurezza TLS e catena di fiducia, il rigore della marca temporale e della firma si allinea sulle medesime esigenze crittografiche.

Da ricordare: soltanto una status page pubblica marcata temporalmente combina le tre proprietà di una prova opponibile. Concepirla così è oggi un investimento ad altissimo ritorno normativo.

Anatomia di una status page DORA-ready: dieci attributi obbligatori

Una status page concepita come deliverable di audit deve spuntare dieci caselle tecniche. L'elenco che segue sintetizza le aspettative incrociate dei supervisori europei (Banca d'Italia, ACN, ACPR, BaFin, CSSF) e le buone pratiche operative degli editori più maturi.

Attributo 1, identificazione chiara dei componenti e dei servizi. La granularità deve scendere al livello prodotto/regione. Un'etichetta « API » è insufficiente; occorre « API REST v3, regione EU-West », « API REST v3, regione US-East », « SFTP B2B », « Webhooks ». Questo consente di dichiarare un incidente parziale senza scatenare un panico ingiustificato sull'intero servizio.

Attributo 2, marca temporale RFC 3339 UTC ovunque. Nessuna data in ora locale. Nessuna data senza fuso orario. La conversione in ora locale avviene lato browser. La coerenza UTC garantisce l'opponibilità giuridica.

Attributo 3, severity codificata e stabile. Quattro livelli minimo: operational, degraded performance, partial outage, major outage. Le etichette devono essere stabili nel tempo (niente rinominazioni da parte del marketing). Il codice numerico sottostante (ad esempio 0/1/2/3) deve transitare nel flusso JSON per consentire l'automazione.

Attributo 4, link esplicito all'incidente in corso e identificativo stabile. Ogni incidente deve avere un identificativo univoco, persistente dopo la risoluzione, accessibile tramite URL canonico. I supervisori chiedono spesso: « Ci fornisca l'URL esatta della comunicazione pubblica dell'incidente XYZ. »

Attributo 5, audit trail visibile. Ciascun aggiornamento deve essere versionato, datato e identificare l'autore (almeno per ruolo o identificativo). Le modifiche successive devono restare visibili con la dicitura « modificato il… ».

Attributo 6, export strutturato in JSON, RSS, Atom, ICS. Il JSON serve all'estrazione automatizzata verso i rapporti per i supervisori. RSS e Atom servono alla sottoscrizione cliente (e al sourcing da parte di strumenti come StatusGator o IsDown). ICS serve alla manutenzione pianificata per i team clienti.

Attributo 7, indipendenza infrastrutturale. La status page deve essere ospitata al di fuori del perimetro applicativo monitorato. Se l'applicativo è su AWS Frankfurt, la status page non deve esserlo. Questa indipendenza non è negoziabile: è ciò che distingue un deliverable utile in caso di guasto maggiore da un placebo.

Attributo 8, versionamento degli aggiornamenti. Conseguenza diretta dell'attributo 5: un sistema di storage immutabile tipo Write-Once-Read-Many (WORM) o un registro firmato garantisce che nessuna riscrittura retroattiva sia tecnicamente possibile.

Attributo 9, notifiche multicanale. E-mail, webhook, RSS e SMS opzionale. I supervisori chiedono spesso di essere abbonati durante i controlli: rifiutare un canale di sottoscrizione non è proponibile.

Attributo 10, conservazione di lunga durata. L'archiviazione degli snapshot (JSON e HTML) deve coprire come minimo 6 anni, per allinearsi a DORA Articoli da 5 a 14 (ICT risk framework, registro incidenti) e alle trasposizioni nazionali NIS2. La Francia impone 6 anni nella Loi Résilience adottata. Le trasposizioni italiana e tedesca prevedono un minimo di 5 anni.

---

Aside: rischio ICT terzo e clausole contrattuali DORA Articoli 28 e 30

Il capitolo V di DORA disciplina i rapporti fra entità finanziarie e fornitori ICT. L'Articolo 28 impone la tenuta di un registro degli accordi contrattuali ICT, la classificazione delle funzioni critiche o importanti (CIFA) e la concentrazione del rischio di terzi. L'Articolo 30 elenca le clausole contrattuali minime: descrizione chiara del servizio, livelli di servizio misurabili, localizzazione dei dati, sicurezza delle informazioni, accessibilità e restituzione dei dati, diritto di audit, exit strategy.

Per un editore o un cliente SaaS B2B europeo, questi due articoli dettano un interrogarsi oggettivo al momento di scegliere un fornitore di status page:

• Localizzazione dei dati. L'hosting dei dati della status page (incidenti, commenti, metadati) è garantito contrattualmente in Europa? I subappaltatori (CDN, backup, monitoring interno) sono tutti localizzati in Europa?
• Giurisdizione del fornitore. Un fornitore la cui casa madre si trova negli Stati Uniti attiva il rischio CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), che consente alle autorità statunitensi di esigere dati conservati da un'impresa soggetta a giurisdizione statunitense, indipendentemente dal paese di archiviazione fisica. Questo non squalifica automaticamente i fornitori interessati (Atlassian Statuspage, ad esempio), ma impone SCC (Standard Contractual Clauses) GDPR rafforzate e un DPA esplicito.
• Certificazioni. SOC 2 Type II e ISO 27001 sono utili ma non sufficienti per DORA, che richiede un'auditabilità specifica del settore finanziario. Richieda esplicitamente uno Statement of Applicability che includa la clausola DORA Articolo 28.
• Registro dei subappaltatori. Un fornitore conforme a DORA deve poter fornire l'elenco aggiornato dei suoi subprocessor con la loro localizzazione e il loro ruolo. Rifiuto = segnale d'allarme.
• Exit strategy testata. La capacità di recuperare la totalità del suo storico status page in formato aperto (JSON, CSV) in meno di 72 ore deve essere contrattualizzata e testata annualmente. Un export improvvisato in caso di urgenza non regge davanti a un auditor.

I fornitori statunitensi (Atlassian Statuspage, StatusGator, alcuni BetterStack a seconda della giurisdizione contrattuale) coesistono con alternative europee (Instatus EU, CaptainDNS, OpenStatus in modalità self-hosted). La scelta non si fa sulle feature o sul pricing: si fa sull'allineamento ai DORA Articoli 28 e 30. Per il dettaglio delle clausole contrattuali, consulti la sintesi di Bird & Bird sulle clausole contrattuali DORA. Sulla stessa logica di hosting europeo contrattualizzato, si veda anche la guida MTA-STS completa.

---

Da ricordare: 10 attributi tecnici più 1 questione giuridica di giurisdizione formano la checklist anatomia. Qualsiasi falla su un attributo è un rischio di audit, non un dettaglio di prodotto.

Modello di incident report: dal JSON status page al rapporto DORA

L'obiettivo di una status page DORA-ready non è solo comunicare pubblicamente. È anche alimentare direttamente il rapporto normativo confidenziale, senza inserimenti manuali ripetuti. Il perno fra i due è un file JSON strutturato, derivato dalla status page e trasposto sui template RTS/ITS JC 2024-33.

Corrispondenza campo a campo fra l'export status page e il template del supervisore

Il rapporto iniziale DORA richiede nove campi minimo. La tabella seguente mostra la corrispondenza con un export JSON status page:

• entity_id (status page) → campo « LEI » o identificativo nazionale del rapporto DORA.
• incident.uuid (status page) → campo « Reference number » del rapporto.
• incident.detected_at (timestamp RFC 3339 UTC) → campo « Date and time of detection ».
• incident.classified_at → campo « Date and time of classification ».
• incident.preliminary_description → campo « Description of the incident ».
• incident.classification_criteria (elenco codificato Art. 18) → campo « Classification criteria activated ».
• incident.impact_estimate (clienti, durata, geografia, dati) → blocco « Estimated impact ».
• incident.immediate_actions (array di misure) → campo « Immediate measures taken ».
• incident.contact (e-mail + telefono del contatto DORA) → campo « Reporting contact ».

Esempio JSON per un incidente DDoS classificato come grave

{
  "entity": {
    "lei": "5493000F4ZO33MV32P92",
    "name": "captaindns.com",
    "ncas": ["ACPR-FR", "BaFin-DE"]
  },
  "incident": {
    "uuid": "INC-2026-05-15-001",
    "url_public": "https://status.captaindns.com/incidents/INC-2026-05-15-001",
    "detected_at": "2026-05-15T14:02:11Z",
    "classified_at": "2026-05-15T14:48:32Z",
    "classification_criteria": [
      "geographical_spread:multi_region",
      "data_loss:none",
      "duration_estimate:over_2h",
      "clients_affected:over_10000"
    ],
    "severity": "major_outage",
    "preliminary_description": "Volumetric DDoS attack (1.2 Tbps) on EU-West API ingress, mitigation engaged at T+8min, traffic partially restored T+15min, full mitigation T+47min.",
    "impact_estimate": {
      "clients_affected_estimate": 12400,
      "geography": ["EU-West", "EU-North"],
      "data_loss": false,
      "downstream_dependencies": ["bank-X", "insurer-Y"]
    },
    "immediate_actions": [
      "Activation BGP blackhole upstream",
      "Failover to APAC fallback (read-only mode)",
      "Public status page update T+11min"
    ],
    "next_steps": [
      "Continuous monitoring 24h",
      "Forensic capture preserved",
      "Intermediate report scheduled T+72h"
    ],
    "contact": {
      "name": "DORA Incident Notifier (role dedicated)",
      "email": "dora-incidents@captaindns.com",
      "phone": "+33 1 00 00 00 00"
    },
    "timestamps_audit_trail": [
      {"at": "2026-05-15T14:08:00Z", "action": "public_announce", "version": 1},
      {"at": "2026-05-15T14:23:00Z", "action": "update_severity", "version": 2},
      {"at": "2026-05-15T14:55:00Z", "action": "resolution_announced", "version": 3}
    ]
  }
}

Workflow di estrazione e trasmissione

L'industrializzazione del flusso poggia su tre mattoni. Un task cron legge la status page ogni 5 minuti, serializza gli incidenti in formato JSON, firma il file con una firma distaccata (PGP o cosign). Un secondo task, innescato da un webhook al momento della classificazione, prepara la versione per il supervisore mappando i campi sugli XSD ufficiali (XBRL per BaFin, XML per Banca d'Italia, JSON per ACPR OneGate). Un terzo mattone gestisce la trasmissione tramite le API o i portali dedicati (OneGate API, eDesk CSSF, MVP BaFin), con retry in caso di indisponibilità del portale.

Sulla messa in sicurezza del trasporto e-mail delle notifiche complementari, il rigore delle policy MTA-STS ospitate si inserisce nella stessa logica di prova crittografica utilizzabile in audit.

Da ricordare: se la sua status page esporta questo JSON, compila il rapporto DORA in 4 ore senza reinserimenti. È la differenza fra rispettare la scadenza e mancarla.

Framework pratico in sette tappe (HowTo)

Per passare dal concetto all'operativo, ecco un framework in sette tappe, applicabile in 90 giorni per un SaaS B2B europeo dotato di un team SRE di base.

Framework di adeguamento status page DORA e NIS2

Sette tappe per rendere la sua status page opponibile a un audit Banca d'Italia, ACPR, BaFin, ACN o CSSF in 90 giorni.

1. Tappa 1: inventario dei servizi e classificazione di criticità

   Stilare l'elenco esaustivo dei servizi esposti e associare a ciascuno una criticità ai sensi di DORA (CIFA / non-CIFA) o NIS2 (essenziale / importante / fuori scope). Documentare il criterio adottato e il metodo di classificazione. Questo inventario è la base di tutti gli impegni successivi. Senza un inventario pulito, è impossibile giustificare al supervisore perché un sotto-servizio non figura sulla status page.

2. Tappa 2: scelta del fornitore di status page secondo DORA Articoli 28 e 30

   Valutare ciascun candidato su cinque criteri oggettivi: giurisdizione del fornitore, localizzazione dei dati, subappaltatori documentati, exit strategy contrattualizzata, audit trail tecnico. Un fornitore senza risposta scritta su questi cinque punti deve essere scartato, indipendentemente dalle sue funzionalità. La revisione contrattuale deve essere validata dalla direzione legale prima della firma.

3. Tappa 3: architettura multi-regione e indipendenza DNS

   Ospitare la status page su un'infrastruttura strettamente distinta dal perimetro applicativo. DNS separato (sottodominio status. dedicato, autorità distinta), hosting geograficamente separato. Attivare DNSSEC, HSTS e CAA sul dominio status. L'indipendenza si verifica: spegnere artificialmente l'applicativo principale in test e controllare che la status page resti consultabile. Senza test, l'indipendenza è solo una dichiarazione.

4. Tappa 4: template di incidente per quattro livelli di gravità

   Preparare quattro modelli di annuncio pubblico: operational maintenance, degraded performance, partial outage, major outage. Ogni modello include i campi obbligatori (timestamp UTC, severity, componenti coinvolti, misure immediate, ETA stimato). I modelli devono essere validati dal DPO, dalla direzione legale e dalla direzione comunicazione. Senza pre-validazione, ogni incidente richiede una revisione urgente che costa tempo prezioso.

5. Tappa 5: pipeline di archiviazione marcato temporalmente e sigillato

   Mettere in atto uno snapshot marcato temporalmente ogni 5 minuti (JSON + HTML) depositato in uno storage immutabile (S3 Object Lock in modalità compliance, o registro firmato locale tipo sigstore). Conservazione minimo 6 anni. La firma distaccata dello snapshot deve essere depositata separatamente per consentire la verifica di integrità da parte di un terzo.

6. Tappa 6: test trimestrale in forma di tabletop exercise

   Organizzare ogni tre mesi un esercizio tabletop che simuli un incidente grave. L'obiettivo: validare che il tempo fra rilevamento e pubblicazione pubblica resti inferiore a 15 minuti, e che la classificazione DORA sia documentata in meno di 4 ore. Il test deve coinvolgere SRE, comms, legale, DPO e un membro del COMEX. Un verbale scritto del tabletop fa parte delle prove auditabili.

7. Tappa 7: revisione annuale allineata all'audit Banca d'Italia, ACPR, BaFin, CSSF

   Organizzare annualmente una revisione formale (board level) che passi in rassegna gli incidenti gravi dell'anno, verifichi la conformità delle notifiche, validi le evoluzioni della status page e arbitri gli investimenti per l'anno successivo. Questa revisione è richiesta da DORA Articolo 17 (governance e organizzazione ICT risk management). Senza traccia scritta di tale revisione, l'auditor può concludere per un difetto di governance, il che aggrava qualsiasi sanzione.

L'incatenamento delle tappe da 1 a 4 prepara l'infrastruttura; le tappe 5 e 6 mettono in sicurezza la prova e la resilienza; la tappa 7 istituzionalizza l'approccio. Per i team che non hanno mai condotto una simulazione, l'investimento iniziale appare elevato. È in realtà irrisorio rispetto al rischio di sanzione. Sul rigore dei controlli HTTPS e HSTS associati al dominio status, si veda la guida HSTS preload.

Da ricordare: senza drill trimestrale di 4 ore, scoprirà in produzione che il processo di notifica non regge. Il drill costa mezza giornata. Una notifica mancata costa 10 milioni di euro.

Domande frequenti

FAQ

Il nostro SaaS è interessato da DORA se eroghiamo un servizio a una banca?

Sì, indirettamente. DORA Articoli 28 e 30 impongono alle entità finanziarie di ribaltare contrattualmente gli obblighi sui propri fornitori ICT, in particolare quelli alla base di una CIFA (Critical or Important Function Arrangement). Sarà pertanto soggetto a clausole contrattuali obbligatorie: localizzazione dei dati, diritti di audit, exit strategy, livelli di servizio misurabili. Se è designato CTPP (Critical Third-Party Provider) dalle ESA, ricade sotto vigilanza diretta. La status page diventa allora un deliverable contrattuale quantificato e opponibile.

Qual è la scadenza esatta di una notifica DORA iniziale?

Quattro ore dopo la classificazione dell'incidente come grave, con un limite massimo di 24 ore dopo il rilevamento. La classificazione si basa su DORA Articolo 18 e sui criteri di materialità (impatto sui clienti, durata, geografia, perdita di dati, criticità del servizio). La scadenza parte dal momento del verdetto « incidente grave », non dal rilevamento. Il documento JC 2024-33 pubblicato nel luglio 2024 dalle ESA elenca i nove campi obbligatori del rapporto iniziale: identità dell'entità, marca temporale rilevamento, marca temporale classificazione, descrizione preliminare, criteri di classificazione, impatto stimato, misure immediate, prossimi passi, contatto dedicato.

Qual è la differenza operativa fra DORA e NIS2 per la nostra status page?

DORA prevale sul settore finanziario (banche, assicurazioni, fondi, prestatori di servizi di pagamento) e fa partire il cronometro 4 ore dopo la classificazione. NIS2 copre 18 settori essenziali e importanti (energia, salute, digitale, trasporti, alimentazione, eccetera) e parte 24 ore dopo la conoscenza interna dell'incidente. Le due convergono su 72 ore di notifica intermedia e 1 mese per il rapporto finale. Se rientra in entrambi i perimetri (raro ma possibile), DORA prevale a causa della scadenza più breve. La status page serve entrambe le normative con il medesimo artefatto marcato temporalmente, a condizione che il formato JSON esportato copra i campi dei due template.

La status page può davvero servire come prova documentale in audit?

Una pagina pubblica marcata temporalmente, archiviata ed esportabile in JSON, RSS o Atom soddisfa le tre proprietà di una prova opponibile: marca temporale RFC 3339 UTC, immutabilità tramite audit trail visibile, accessibilità pubblica verificabile. Nessun PDF post-mortem né log interno combina questi tre criteri. Più supervisori europei (ACPR, BaFin) considerano oramai la comunicazione pubblica di incidente come parte integrante del dossier di audit ICT, senza nominarla formalmente « prova », ma viene regolarmente convocata durante i controlli documentali. A titolo comparativo, una marca temporale qualificata RFC 3161 da parte di un Trust Service Provider apporta un livello giuridico ulteriore.

La nostra status page Atlassian Statuspage US è compatibile con DORA Articolo 28?

La questione non è di incompatibilità assoluta, ma di gestione del rischio ICT terzo e di giurisdizione. Un fornitore di status page sotto giurisdizione statunitense attiva il CLOUD Act e richiede SCC (Standard Contractual Clauses) e un DPA GDPR rafforzati. Per restare conforme a DORA Articoli da 28 a 30, esiga dal fornitore: localizzazione europea dei dati e dei log, clausole di audit, exit strategy testata annualmente, certificazioni ISO 27001 e SOC 2 Type II, registro aggiornato dei subappaltatori. Se il suo servizio è alla base di una CIFA, queste clausole sono obbligatorie, non opzionali. In caso contrario, il suo cliente finanziario dovrà arbitrare fra mantenimento del contratto e rischio normativo.

Quali sono i 5 pilastri di DORA?

DORA poggia su cinque pilastri strutturanti. Primo pilastro: ICT risk management (Articoli da 5 a 15), che impone un quadro di governance e di gestione dei rischi ICT. Secondo pilastro: ICT-related incident management, classification and reporting (Articoli da 17 a 23), che include l'Articolo 19 sul reporting. Terzo pilastro: digital operational resilience testing (Articoli da 24 a 27), di cui i TLPT (Threat-Led Penetration Testing) per le entità significative. Quarto pilastro: management of ICT third-party risk (Articoli da 28 a 44), che detta i contratti con i fornitori ICT, incluso il fornitore di status page. Quinto pilastro: information sharing arrangements (Articolo 45). Il pilastro 2 impone la status page come artefatto, il pilastro 4 ne detta le condizioni contrattuali.

A chi notificare in Italia un incidente DORA?

Banca d'Italia tramite il portale dedicato agli incidenti DORA, in formato CSV o XML. Per un incidente NIS2, il CSIRT nazionale gestito dall'ACN (Agenzia per la Cybersicurezza Nazionale), in coerenza con il decreto legislativo 138/2024 e il DPCM 221 del 9 dicembre 2024. Per un incidente GDPR che coinvolga dati personali, il Garante per la protezione dei dati personali. Un medesimo incidente può attivare due o tre canali paralleli, da cui l'interesse operativo critico di un formato pivot tipo JSON status page sfruttato una sola volta e trasposto verso ogni template del supervisore.

Per quanto tempo dobbiamo archiviare le nostre status page?

Nessun termine è fissato esplicitamente da DORA Articolo 19, ma la coerenza con gli Articoli da 5 a 14 (ICT risk framework, registro incidenti, audit trail) suggerisce un minimo di 5-6 anni. Il GDPR impone di poter dimostrare la propria conformità ai sensi dell'Articolo 5 paragrafo 2, senza scadenza fissata. I supervisori nazionali (Banca d'Italia, ACPR, BaFin) richiedono tipicamente 5 anni di archivi auditabili. La Loi Résilience francese adottata nel febbraio 2025 prevede 6 anni per NIS2. Raccomandazione prudenziale: archiviare tutti gli snapshot status page (JSON e HTML) in storage immutabile tipo WORM o registro firmato, per almeno 6 anni, con procedura documentata di restituzione entro 72 ore.

Serve una status page diversa per ogni mercato UE (IT, FR, DE)?

No, una sola status page multilingue è sufficiente, a condizione che il contenuto sia identico nella sostanza da una lingua all'altra. I supervisori nazionali accettano un deliverable unificato a condizione che sia accessibile nella lingua della giurisdizione interessata. Attenzione invece ai fusi orari: utilizzi UTC come fonte unica di verità e mostri la conversione locale lato browser (client-side). Se il servizio opera sotto più autorità (Banca d'Italia + ACPR + BaFin + CSSF), mantenga un identificativo di incidente stabile e globale, tradotto tramite mapping linguistico, mai tramite storico separato. Una duplicazione di storico comporta incoerenze temporali molto esposte in audit.

Cosa succede se manchiamo una scadenza di 4 h DORA?

Sanzioni amministrative fino al 2 % del fatturato annuo mondiale o 10 milioni di euro (il più elevato) per l'entità, e fino a 1 milione di euro di sanzione individuale per i responsabili identificati. Per i CTPP: fino all'1 % del fatturato giornaliero medio mondiale, per sei mesi. Oltre alle sanzioni pecuniarie, conseguenze reputazionali tramite la pubblicazione delle sanzioni (Articolo 54). L'ACPR, nel suo bilancio degli 8 mesi del gennaio 2026, segnala che queste scadenze di 4 ore sono « ancora raramente rispettate ». Il 2026 segna la fine della tolleranza e l'inizio dell'enforcement attivo. Conservare una traccia pubblica esaustiva (status page marcata temporalmente) è oggi la migliore assicurazione contro una riqualificazione sfavorevole.

Checklist finale: venticinque punti da validare prima dell'audit

Questa checklist sintetizza gli obblighi DORA, NIS2 e GDPR applicabili alla status page di un SaaS B2B europeo. È strutturata in tre blocchi: documentale (7 punti), tecnico (10 punti), organizzativo (8 punti). Spuntare 25 punti su 25 non garantisce l'assenza di sanzione, ma colloca l'entità in una situazione difensiva solida di fronte a un controllo di Banca d'Italia, ACPR, BaFin, ACN o CSSF.

Parte documentale (sette punti)

1. Politica di classificazione degli incidenti scritta e firmata dalla direzione (matrice severity verso reporting DORA e NIS2).
2. Procedura di notifica DORA 4 ore documentata, validata dalla direzione legale, aggiornata annualmente.
3. Procedura di notifica NIS2 24 ore documentata, allineata al portale nazionale (ACN, MonEspaceNIS2, BSI).
4. DPA GDPR firmato con il fornitore di status page, comprensivo dell'elenco dei subappaltatori.
5. Registro dei fornitori ICT aggiornato, conforme a DORA Articolo 28 paragrafo 3.
6. Exit strategy del fornitore di status page testata annualmente e documentata.
7. Piano di comunicazione di crisi validato dal COMEX (ruoli, messaggi-tipo, canali).

Parte tecnica (dieci punti)

1. Status page ospitata fuori dall'infrastruttura applicativa, con prova di indipendenza testata.
2. Marca temporale RFC 3339 UTC ovunque, senza eccezioni (interfaccia, API, export).
3. Severity codificata su 4 livelli minimo (operational, degraded, partial outage, major outage).
4. Export strutturato disponibile in JSON, RSS e Atom, completato da ICS per la manutenzione.
5. Audit trail visibile su ogni aggiornamento, identificando l'autore (ruolo minimo).
6. Versionamento degli aggiornamenti incidenti, mai sovrascrittura retroattiva.
7. Monitoring multi-regione attivo su almeno 4 zone (UE, US, APAC, UK).
8. Notifiche multicanale operative: e-mail, webhook, RSS, SMS opzionale.
9. Archiviazione immutabile WORM o registro firmato su almeno 6 anni.
10. Sicurezza del dominio status: DNSSEC attivo, HTTPS rigoroso, HSTS, CAA, test HSTS validato.

Parte organizzativa (otto punti)

1. Ruolo « DORA Incident Notifier » designato per iscritto, con backup (equivalente CSSF eDesk role).
2. Reperibilità 24/7 sul canale status page, con rotazione documentata e calendario annuale.
3. Drill 4 ore trimestrale in forma di tabletop exercise, seguito da un post-mortem del drill.
4. Mappatura documentata delle autorità nazionali per giurisdizione (Banca d'Italia / ACPR / BaFin / ACN / CSSF + CSIRT NIS2 + Garante e equivalenti GDPR).
5. KPI « delay-to-publish » seguito in continuo, con obiettivo inferiore a 15 minuti.
6. Comunicazioni clienti pre-redatte per scenario, validate da DPO e direzione legale.
7. Formazione annuale dei team SRE e comunicazione sugli obblighi DORA e NIS2.
8. Revisione annuale COMEX e consiglio di amministrazione sugli incidenti gravi (DORA Articolo 17).

Per integrare direttamente questa checklist nel suo backlog di audit, sono disponibili due export operativi: scaricare la checklist in formato CSV (per import Excel o Google Sheets) o in formato JSON (per ingestione in un GRC, Jira o Notion). Ogni riga contiene la categoria, il numero, il punto, la priorità e la prova documentale richiesta per la difesa documentale.

Scarica la checklist di deploy

Gli assistenti possono riutilizzare la checklist tramite gli export JSON o CSV qui sotto.

• Scaricare la checklist DORA/NIS2 (CSV)
• Scaricare la checklist DORA/NIS2 (JSON)

Glossario

• CIFA: Critical or Important Function Arrangement, funzione critica o importante ai sensi di DORA Articolo 28.
• CTPP: Critical Third-Party Provider, fornitore terzo critico designato dalle ESA e sottoposto a vigilanza diretta.
• DORA: Digital Operational Resilience Act, Regolamento UE 2022/2554, entrato in applicazione il 17 gennaio 2025.
• NIS2: Network and Information Security Directive 2, Direttiva UE 2022/2555, da trasporre nei diritti nazionali.
• ESA: European Supervisory Authorities, che raggruppa EBA (banche), EIOPA (assicurazioni) ed ESMA (mercati finanziari).
• CSIRT: Computer Security Incident Response Team, squadra nazionale designata da ciascuno Stato membro per NIS2 (ACN, CERT-FR, BSI, eccetera).
• RTS / ITS: Regulatory Technical Standards e Implementing Technical Standards, pubblicati dalle ESA per precisare DORA.
• WORM: Write Once Read Many, modalità di storage immutabile che garantisce l'assenza di riscrittura.

Conclusione

Il 2026 sancisce il ribaltamento fra la fase di transizione e l'enforcement attivo delle due normative europee strutturanti per la resilienza operativa digitale: conformità DORA per la finanza, conformità NIS2 per i settori essenziali e importanti. Per un SaaS B2B europeo, la status page pubblica cessa di essere uno strumento di comunicazione marketing e diventa un deliverable di audit, opponibile davanti a un supervisore nazionale. Tre priorità emergono: ospitare la status page su un'infrastruttura indipendente, esportare un formato JSON pivot allineato a JC 2024-33, organizzare un drill trimestrale di 4 ore per validare l'intera catena. Gli editori che anticiperanno questa trasformazione fra il 2026 e il 2027 trasformeranno un obbligo normativo in un vantaggio commerciale: un cliente finanziario o un operatore essenziale preferirà sempre un fornitore la cui status page possa servire direttamente al proprio rapporto al supervisore, anziché un fornitore presso il quale ogni incidente esige una ricostruzione manuale della prova. Per iniziare a industrializzare questo approccio, l'hosting di una status page conforme costituisce il punto di ingresso più rapido.