Se un major ICT incident inizia stanotte, chi decide nella prima ora?
In sintesi
A quel punto, la domanda centrale non è più solo se l'incident team possa ripristinare il servizio.
Se un major ICT incident inizia stanotte, chi decide nella prima ora?
Board AskConfermare se l'istituzione può dimostrare first-hour decision rights, classification, escalation, communication e regulatory reporting triggers per major ICT-related incidents.
Situation
Assumiamo la seguente situazione.
Un servizio ICT critico diventa instabile a tarda sera. Online banking, pagamenti, risk reporting, trading support, client service, identity access o un workflow cloud-hosted è impattato.
- La causa tecnica non è chiara.
- Il provider sta investigando.
- I primi update interni sono incompleti.
- I clienti potrebbero già essere impattati.
L'istituzione non sa ancora se l'evento sia un major ICT-related incident sotto DORA.
Ma l'orologio è già partito.
A quel punto, la domanda centrale non è più solo se l'incident team possa ripristinare il servizio.
La domanda del board è se l'istituzione possa dimostrare chi decide, chi escala, chi comunica e chi classifica l'incident prima che il root cause sia noto.
Se un major ICT incident inizia stanotte, chi decide nella prima ora?
Management Summary
L'ICT incident management è diventato una questione di resilienza a livello di board. DORA richiede alle entità finanziarie di istituire un processo di gestione degli ICT-related incidents per rilevare, gestire e notificare ICT-related incidents; registrare incidenti e significant cyber threats; classificare gli incidenti per priorità, severity e criticality dei servizi impattati; assegnare ruoli e responsabilità; e stabilire procedure interne di escalation e comunicazione.
Il primo overview annuale DORA sui major ICT-related incidents ha riportato 3,383 major incidents nel 2025. Le ESAs affermano che l'impatto diretto su clienti e transazioni è stato generalmente limitato, mentre system failures ed external events sono stati i principali driver. I findings sottolineano inoltre l'importanza di third-party risk management, outsourced-service oversight e stretta coordinazione con service providers durante incident response e remediation.
L'orologio del reporting rende critica la first-hour decision capability. Il Commission Delegated Regulation (EU) 2025/301 richiede che l'initial report per un major ICT-related incident sia presentato il prima possibile, e in ogni caso entro quattro ore dalla classification as major e non oltre 24 ore dal momento in cui la financial entity è venuta a conoscenza dell'incident. Se l'incident viene classificato come major solo successivamente, l'initial notification deve essere presentata entro quattro ore dalla classificazione. L'intermediate report è dovuto entro 72 ore dall'initial notification, e il final report non oltre un mese dall'intermediate o dall'ultimo updated intermediate report.
Una risposta forte del board non è: "We have an incident plan." Una risposta forte mostra chi può classificare l'incident, chi owns la business impact view, chi informa il management body, chi decide la comunicazione esterna, chi attiva il regulatory reporting e se il first-hour record può essere ricostruito.
Management Report Panel
Calibrazione della qualità della risposta
Il RAG status calibra la qualità della risposta. Non giudica l'istituzione.
La catena decisionale della prima ora
Chi dovrebbe rispondere
- Technology può ripristinare il servizio.
- Operations può coordinare la recovery.
- Compliance può reportare l'incident.
- Il management body owns la resilience expectation.
Prove che il consiglio dovrebbe richiedere
- 01First-Hour Decision Matrix
- 02DORA Classification Path
- 03Incident Command Record
- 04War-Room Timeline
- 05Business Impact Assessment
- 06Management-Body Notification Trigger
- 07Regulator Notification Evidence
- 08Client and External Communication Protocol
- 09Provider Escalation and Dependency Log
- 10Post-Incident Review Pack
Segnali di allarme
- “IT is handling it.”
- “We are waiting for root cause.”
- “The provider is still investigating.”
- “We will inform the board once it is confirmed as major.”
- “The incident plan is documented.”
- “The service owner will know what to do.”
- “The regulator will be notified if required.”
- “Clients will be informed after we understand the impact.”
Nessuna di queste affermazioni è necessariamente falsa. Semplicemente, non costituiscono evidence sufficiente per board-level reliance.
Percorso verso il verde
- Decision rights defined
- Impact path visible
- DORA clock controlled
- Communication governed
- Evidence retained
- Lessons embedded
Il RAG status calibra la qualità della risposta.
Non giudica l'istituzione.
Prossima domanda suggerita
Quale servizio critico o importante creerebbe la maggiore first-hour decision pressure se fallisse stanotte — e possiamo dimostrare chi decide prima che il root cause sia noto?
Base di fonti selezionata
- European Union — Regulation (EU) 2022/2554, Digital Operational Resilience Act
- Commission Delegated Regulation (EU) 2024/1772 — ICT Incident Classification Criteria and Materiality Thresholds
- Commission Delegated Regulation (EU) 2025/301 — Time Limits and Content for Major ICT Incident Notifications and Reports
- ESAs — 2025 Report on Major ICT-Related Incidents under DORA
- ESMA / ESAs — First Annual Overview of Major ICT-Related Incidents under DORA, 3 June 2026
- EBA — Joint Technical Standards on Major Incident Reporting
- ECB Banking Supervision — Supervisory Priorities 2026–28
- NIST — SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- BCBS — Principles for Operational Resilience
- FSB — Cyber Incident Reporting: Achieving Greater Convergence
- FSB — Format for Incident Reporting Exchange
Commento dell'esperto — 7 min di lettura
I major ICT incidents raramente sono puliti nella prima ora.
I primi facts sono incompleti. Il business impact è incerto. I technical teams possono ancora investigare. Un provider potrebbe non aver ancora confermato la causa. L'istituzione potrebbe non sapere ancora se l'incident diventerà reportable. I clienti potrebbero già notare disruption. Gli internal stakeholders possono chiedere updates prima che l'incident team abbia una vista stabile.
È esattamente per questo che la first-hour decision capability conta.
La versione debole dell'incident management è document-centric. Chiede se esista un incident plan.
La versione più forte è decision-centric. Chiede se l'istituzione può decidere sotto incertezza.
DORA rafforza questa distinzione. La regolamentazione non è limitata alla technical restoration. Richiede un processo per detect, manage e notify incidents; classify them; assign roles and responsibilities; establish escalation and communication procedures; inform senior management e management body; e mitigate impacts affinché i servizi diventino operational and secure in modo tempestivo.
Questo significa che il board non dovrebbe chiedere solo se esiste l'incident management process.
Dovrebbe chiedere se le first-hour decisions sono executable.
Queste non sono domande amministrative. Sono domande di resilience.
Il primo DORA incident report delle ESAs rende il tema tangibile. Registra 3,383 major ICT-related incidents riportati nel 2025, notando anche che l'impatto diretto su clienti e transazioni è stato generalmente limitato. Questo è un segnale costruttivo importante. Suggerisce che timely detection, response e recovery possono limitare il danno anche dove il panorama degli incidents è complesso e interconnesso.
Le ESAs sottolineano inoltre che gli ICT risks sono sempre più borderless e interconnessi, e che circa un terzo dei major incidents ha avuto origine da failures attributable to third parties — inclusi ICT providers, altre financial entities e infrastructure providers. Questo rafforza il punto che gli ICT incidents possono muoversi rapidamente tra entities, services, jurisdictions e shared infrastructure. Per la first-hour decision chain, tuttavia, il punto più pratico per il board non è la geografia da sola. È se l'istituzione può coordinare technical response, provider escalation, business impact assessment, regulatory classification e management-body visibility prima che il root cause sia noto.
Questo è il tono giusto per questo briefing.
Il punto non è che le istituzioni falliscono quando si verificano incidents.
Il punto è che gli incidents testano se decision rights, escalation ed evidence sono reali.
Un critical service outage può iniziare come technical event. In pochi minuti può diventare un operational resilience event. Nella prima ora può diventare una regulatory classification question, una client communication question, una provider-dependency question e una management-body visibility question.
Se queste domande vengono risposte in sequenza, l'istituzione può perdere tempo.
Se vengono risposte tramite una tested decision chain, l'istituzione può agire mentre l'incertezza rimane.
Questo è l'insight pratico per il board.
Root cause non è la prima decisione.
Root cause è spesso il risultato di analisi successive.
La prima decisione è se l'istituzione sa abbastanza per contain impact, escalate correctly, communicate responsibly e avviare il classification path.
Per i board, l'artefatto più importante non è quindi l'incident policy.
È il first-hour evidence trail.
Quel trail dovrebbe mostrare cosa era noto, cosa era assunto, chi ha deciso, chi è stato informato, cosa è stato comunicato, cosa non era ancora noto, cosa è stato escalated e cosa è stato deferred.
Un buon first-hour record non richiede conoscenza perfetta.
Richiede disciplined uncertainty.
Questo distingue un documented incident process dall'operational resilience.
Un incident plan descrive cosa dovrebbe accadere.
Incident decision capability dimostra che l'istituzione può agire quando i fatti sono incompleti.