Il Digital Operational Resilience Act si applica a banche, assicurazioni, istituti di pagamento, prestatori di servizi per le cripto-attività e ai loro fornitori ICT critici in tutta l'UE. A differenza di un framework che si adotta su base volontaria, DORA è un regolamento con una data precisa — si applica dal 17 gennaio 2025. La maggior parte dei team di conformità lo legge come un obbligo di registrazione e di segnalazione degli incidenti. A una lettura più attenta, è anche un obbligo probatorio, ed è proprio nella metà probatoria che si annida il divario.
Cosa richiede davvero l'Articolo 9
L'Articolo 9 di DORA impone agli enti finanziari di adottare politiche e strumenti che garantiscano «autenticità, integrità, disponibilità e riservatezza» dei dati — compresi i dati contenuti nei log e nelle piste di controllo utilizzate per ricostruire gli incidenti. L'aspettativa di vigilanza non è che abbiate conservato i registri. È che siate in grado di dimostrare che i registri sono gli originali, inalterati, quando un'autorità di vigilanza o di risoluzione lo chiede.
In gran parte delle implementazioni si nasconde un assunto silenzioso: che il sistema che ha prodotto il log sia anche un testimone affidabile della sua integrità. La prospettiva di resilienza di DORA manda in frantumi questo assunto. Se il sistema ICT è compromesso — esattamente lo scenario per cui DORA esiste — la sua stessa attestazione che i log sono intatti vale ben poco.
Dove «registriamo tutto» non basta
Una registrazione completa è necessaria e la maggior parte delle aziende regolamentate la gestisce bene. Il divario emerge nei tre momenti a cui un'autorità di vigilanza tiene di più:
- Ricostruzione dopo un incidente — DORA si aspetta che ricostruiate la sequenza degli eventi. Se i log risiedevano all'interno del sistema violato, la ricostruzione si basa su dati che un attaccante avrebbe potuto modificare.
- Registri di terze parti e fornitori ICT — DORA si estende ai fornitori critici. Dimostrare che il registro di un fornitore è intatto è molto più semplice quando entrambe le parti verificano rispetto a un riferimento esterno condiviso, anziché scambiarsi esportazioni di log.
- Dimostrazione indipendente — un'autorità di vigilanza non deve fidarsi della vostra parola sul fatto che i controlli di conservazione e immutabilità abbiano tenuto. Un'integrità verificabile da chiunque rispetto a un'ancora esterna trasforma un'affermazione in un fatto dimostrabile.
La scadenza è già passata — perché allora è ancora un fattore d'acquisto?
Gennaio 2025 era la data di applicazione, non il punto di arrivo dell'enforcement. Nel primo anno le autorità di vigilanza hanno mappato gli enti e valutato i livelli di base. Il passaggio ora in corso è dal «avete una politica?» al «mostrateci le prove» — ed è alla seconda domanda che la prova di integrità risponde direttamente.
Le aziende che si muovono per prime non sono quelle con la registrazione peggiore. Sono quelle a cui revisori e autorità di vigilanza hanno iniziato a porre la seconda domanda e che preferiscono rispondervi con un'ancora verificabile anziché con lo screenshot di una politica di conservazione.
Come la prova di integrità si innesta nel flusso di lavoro DORA
Aggiungere un livello di verifica non sostituisce il vostro SIEM, la vostra pipeline di log o il vostro processo di gestione degli incidenti. Funziona in parallelo, sigillando i registri che quei sistemi già producono:
Quando un'autorità di vigilanza vi chiede di dimostrare che un dato registro di audit è l'originale, voi producete un pacchetto di prova: l'hash del registro, la sua posizione nell'albero di Merkle e il riferimento sulla chain pubblica dove la radice è stata ancorata in un momento noto. Nulla di tutto ciò richiede che il regolatore si fidi del sistema che ha generato il log — ed è esattamente il punto di DORA.
Chi se ne occupa all'interno dell'azienda
DORA ha spostato il rischio ICT in capo all'organo di gestione, perciò chi si interroga sulle prove di integrità sempre più spesso non è un tecnico:
- Responsabile Compliance — presidia il rapporto con il regolatore e deve tradurre «abbiamo dei controlli» in «ecco le prove dimostrabili».
- CISO / Rischio ICT — presidia la postura di resilienza e sa che i log autoattestati sono l'anello debole nella ricostruzione di una violazione.
- Internal audit — presidia la linea di assurance e ne trae vantaggio quando l'integrità è verificabile senza dipendere dal sistema sottoposto a revisione.
Come impostare onestamente una conversazione su DORA
DORA non nomina blockchain, alberi di Merkle né alcuna tecnologia specifica — e dovreste diffidare di qualunque fornitore sostenga il contrario. Ciò che DORA richiede è un'integrità che possiate dimostrare a una parte indipendente. Ancorare i registri a una chain pubblica è un modo strutturalmente solido per fornirla, perché la prova non dipende dalla continuità del buon comportamento del sistema sotto esame. La domanda da portare alla vostra prossima revisione DORA è semplice: per ciascuna pista di controllo critica, siamo in grado di dimostrare a un regolatore che non è cambiata — senza chiedergli di fidarsi del sistema che l'ha prodotta?
DORA non chiede se avete conservato i registri. Chiede se potete dimostrare che sono gli originali — a qualcuno che non ha alcun motivo di fidarsi del sistema che li ha prodotti.