Si un incidente ICT mayor empieza esta noche, ¿quién decide en la primera hora?
De un vistazo
En ese punto, la pregunta central ya no es solo si el incident team puede restaurar el servicio.
Si un incidente ICT mayor empieza esta noche, ¿quién decide en la primera hora?
Board AskConfirmar si la institución puede demostrar first-hour decision rights, classification, escalation, communication y regulatory reporting triggers para major ICT-related incidents.
Situation
Supongamos la siguiente situación.
Un servicio ICT crítico se vuelve inestable tarde por la noche. Online banking, pagos, risk reporting, trading support, client service, identity access o un workflow cloud-hosted está afectado.
- La causa técnica no está clara.
- El provider está investigando.
- Los primeros updates internos son incompletos.
- Los clientes pueden estar ya afectados.
La institución todavía no sabe si el evento es un major ICT-related incident bajo DORA.
Pero el reloj ya ha empezado.
En ese punto, la pregunta central ya no es solo si el incident team puede restaurar el servicio.
La pregunta del board es si la institución puede demostrar quién decide, quién escala, quién comunica y quién clasifica el incidente antes de que se conozca el root cause.
Si un incidente ICT mayor empieza esta noche, ¿quién decide en la primera hora?
Management Summary
El ICT incident management se ha convertido en una cuestión de resiliencia a nivel board. DORA exige a las entidades financieras establecer un proceso de gestión de ICT-related incidents para detectar, gestionar y notificar ICT-related incidents; registrar incidentes y significant cyber threats; clasificar incidentes por prioridad, severity y criticality de los servicios impactados; asignar roles y responsabilidades; y establecer procedimientos internos de escalation y comunicación.
El primer annual overview DORA de major ICT-related incidents reportó 3,383 major incidents en 2025. Las ESAs indican que el impacto directo en clientes y transacciones fue generalmente limitado, mientras que system failures y external events fueron los principales drivers. Los findings también subrayan la importancia de third-party risk management, outsourced-service oversight y estrecha coordinación con service providers durante incident response y remediation.
El reloj de reporting hace crítica la first-hour decision capability. El Commission Delegated Regulation (EU) 2025/301 exige que el initial report de un major ICT-related incident se presente lo antes posible y, en cualquier caso, dentro de las cuatro horas desde la classification as major y no más tarde de 24 horas desde el momento en que la financial entity tuvo conocimiento del incidente. Si el incidente se clasifica como major solo posteriormente, la initial notification debe presentarse dentro de las cuatro horas desde la clasificación. El intermediate report vence dentro de las 72 horas desde la initial notification, y el final report no más tarde de un mes después del intermediate report o del último updated intermediate report.
Una respuesta fuerte del board no es: "We have an incident plan." Una respuesta fuerte muestra quién puede clasificar el incidente, quién owns la business impact view, quién informa al management body, quién decide la comunicación externa, quién activa el regulatory reporting y si el first-hour record puede reconstruirse.
Management Report Panel
Calibración de la calidad de respuesta
El RAG status calibra la calidad de la respuesta. No juzga a la institución.
La cadena de decisión de la primera hora
Quién debe responder
- Technology puede restaurar el servicio.
- Operations puede coordinar la recovery.
- Compliance puede reportar el incidente.
- El management body owns la resilience expectation.
Evidencias que el consejo debería solicitar
- 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
Señales de alerta
- “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.”
Ninguna de estas afirmaciones es necesariamente falsa. Simplemente no constituyen evidence suficiente para board-level reliance.
Camino hacia el verde
- Decision rights defined
- Impact path visible
- DORA clock controlled
- Communication governed
- Evidence retained
- Lessons embedded
El RAG status calibra la calidad de la respuesta.
No juzga a la institución.
Próxima pregunta sugerida
¿Qué servicio crítico o importante crearía la mayor first-hour decision pressure si fallara esta noche — y podemos demostrar quién decide antes de que se conozca el root cause?
Base de fuentes seleccionada
- 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
Comentario de experto — 7 min de lectura
Los major ICT incidents rara vez son limpios en la primera hora.
Los primeros facts son incompletos. El business impact es incierto. Los technical teams pueden seguir investigando. Un provider puede no haber confirmado todavía la causa. La institución puede no saber aún si el incidente será reportable. Los clientes pueden notar ya la disruption. Los internal stakeholders pueden pedir updates antes de que el incident team tenga una vista estable.
Precisamente por eso importa la first-hour decision capability.
La versión débil del incident management es document-centric. Pregunta si existe un incident plan.
La versión fuerte es decision-centric. Pregunta si la institución puede decidir bajo incertidumbre.
DORA refuerza esa distinción. La regulación no se limita a technical restoration. Exige un proceso para detect, manage y notify incidents; classify them; assign roles and responsibilities; establish escalation and communication procedures; inform senior management y management body; y mitigate impacts para que los servicios sean operational and secure de forma oportuna.
Esto significa que el board no debería preguntar solo si existe el incident management process.
Debería preguntar si las first-hour decisions son executable.
Estas no son preguntas administrativas. Son preguntas de resilience.
El primer DORA incident report de las ESAs hace tangible el tema. Registra 3,383 major ICT-related incidents reportados en 2025, señalando también que el impacto directo en clientes y transacciones fue generalmente limitado. Es una señal constructiva importante. Sugiere que timely detection, response y recovery pueden limitar daños incluso cuando el paisaje de incidents es complejo e interconectado.
Las ESAs también subrayan que los ICT risks son cada vez más borderless e interconectados, y que alrededor de un tercio de los major incidents se originaron por failures attributable to third parties — incluidos ICT providers, otras financial entities e infrastructure providers. Esto refuerza el punto de que los ICT incidents pueden moverse rápidamente entre entities, services, jurisdictions y shared infrastructure. Para la first-hour decision chain, sin embargo, el tema práctico para el board no es solo la geografía. Es si la institución puede coordinar technical response, provider escalation, business impact assessment, regulatory classification y management-body visibility antes de que se conozca el root cause.
Ese es el tono correcto para este briefing.
El punto no es que las instituciones fallen cuando ocurren incidents.
El punto es que los incidents prueban si decision rights, escalation y evidence son reales.
Una caída de servicio crítico puede empezar como technical event. En minutos, puede convertirse en operational resilience event. En la primera hora, puede convertirse en regulatory classification question, client communication question, provider-dependency question y management-body visibility question.
Si esas preguntas se responden secuencialmente, la institución puede perder tiempo.
Si se responden mediante una tested decision chain, la institución puede actuar mientras la incertidumbre permanece.
Ese es el insight práctico para el board.
Root cause no es la primera decisión.
Root cause suele ser el resultado de análisis posterior.
La primera decisión es si la institución sabe lo suficiente para contain impact, escalate correctly, communicate responsibly y empezar el classification path.
Para los boards, el artefacto más importante no es por tanto la incident policy.
Es el first-hour evidence trail.
Ese trail debería mostrar qué se sabía, qué se asumía, quién decidió, quién fue informado, qué se comunicó, qué aún no se sabía, qué se escaló y qué se difirió.
Un buen first-hour record no requiere conocimiento perfecto.
Requiere disciplined uncertainty.
Eso distingue un documented incident process de operational resilience.
Un incident plan describe lo que debería ocurrir.
Incident decision capability demuestra que la institución puede actuar cuando los hechos son incompletos.