DORA no espera a que termine el análisis forense para activar el reporting.
La organización necesita reconocer el umbral, coordinarse y trabajar con un único reloj.
Los criterios y umbrales que determinan cuándo un incidente es grave.
El punto exacto en que se registra conocimiento, se clasifica y se activa la notificación.
Que la organización puede construir y actualizar el reporte con trazabilidad temporal.
| Clave | Qué revisar | Qué debería demostrar |
|---|---|---|
| INC-01 | Detección y conocimiento | Quién fija la hora de conocimiento y con qué evidencia. |
| INC-02 | Clasificación | Criterios, umbrales, propietario y capacidad de reevaluación. |
| INC-03 | Notificación inicial | Datos mínimos, aprobación, canal y ventana temporal. |
| INC-04 | Informe intermedio | Estado, impacto actualizado, medidas y evolución. |
| INC-05 | Informe final | Causa, resolución, impacto definitivo y acciones posteriores. |
| INC-06 | Aprendizaje | Cambios en controles, procedimientos, proveedores y pruebas. |
| Ref. | Evidencia | Qué debería demostrar |
|---|---|---|
| DI-01 | Procedimiento integrado de incidentes | Detección, clasificación, escalado y reporting conectados. |
| DI-02 | Matriz de criterios DORA | Criterios y umbrales aplicables de forma reproducible. |
| DI-03 | Línea temporal única | Conocimiento, clasificación, decisiones y envíos fechados. |
| DI-04 | Plantillas y canales | Capacidad de reportar con información incompleta y actualizar. |
| DI-05 | Cláusulas de proveedor | Escalado rápido y acceso a información sobre incidentes TIC. |
| DI-06 | Ejercicios y lecciones | Pruebas del proceso y cambios implantados tras el ejercicio. |
La clasificación regulatoria debe integrarse en el proceso de gestión de incidentes desde el primer momento. No puede depender de una revisión manual que comienza cuando el SOC ya ha cerrado la alerta o cuando el análisis forense termina. Los criterios necesitan datos que suelen estar distribuidos entre tecnología, negocio, atención al cliente, fraude, legal y proveedores.
El proceso debería separar hecho, estimación e hipótesis. Por ejemplo: número confirmado de clientes afectados, rango estimado de transacciones, sistemas potencialmente comprometidos y posible impacto transfronterizo. Esta separación permite notificar con información incompleta sin presentar como certeza lo que todavía está siendo investigado.
También conviene diseñar puntos de reevaluación. Un incidente inicialmente menor puede cruzar umbrales cuando aumenta la duración, se confirma pérdida de datos o aparece afectación a una función crítica. La clasificación no es una etiqueta fija; es una decisión viva durante todo el ciclo del incidente.
| Momento | Pregunta | Fuente de datos |
|---|---|---|
| Detección | ¿Qué servicio, activo o proveedor está implicado? | SIEM, EDR, CMDB, catálogo de servicios y monitorización. |
| Evaluación inicial | ¿Puede afectar una función crítica o importante? | BIA, mapa de dependencias y responsable de negocio. |
| Reevaluación | ¿Han cambiado duración, alcance, clientes o impacto geográfico? | War room, métricas de servicio, atención al cliente y proveedores. |
| Cierre | ¿Qué costes, pérdidas, causa y medidas deben consolidarse? | Forense, finanzas, legal, post-mortem y plan de remediación. |
Una entidad pierde el servicio de autenticación federada utilizado por banca online, aplicaciones internas y proveedores. Durante los primeros minutos se interpreta como una indisponibilidad del IdP. Después se descubre que el fallo afecta a varias regiones, impide accesos de clientes y bloquea tareas operativas internas.
La clasificación necesita responder de forma coordinada: cuántos usuarios no pueden autenticarse, qué funciones siguen disponibles mediante sesiones activas, si existen métodos alternativos, qué transacciones quedan bloqueadas y si el proveedor ha declarado un incidente propio. El equipo técnico aporta telemetría; negocio traduce la indisponibilidad a impacto; legal y cumplimiento evalúan obligaciones de comunicación.
El expediente debería conservar la cronología de decisiones, fuentes utilizadas, valores conocidos en cada momento, cambios de clasificación y comunicaciones enviadas. Así, una revisión posterior puede reconstruir por qué se notificó —o por qué no— con la información disponible entonces.
Otro equipo debería poder reconstruir la decisión usando la misma cronología, los mismos datos y los criterios definidos, incluso meses después.
Tomaría un incidente real y reconstruiría minuto a minuto detección, escalado, clasificación y comunicación. Compararía la cronología del SIEM con tickets, canal de crisis, correos y decisiones regulatorias.
Comprobaría que los criterios de clasificación están implementados en una herramienta o checklist operativa y que cada dato tiene fuente y responsable. También revisaría qué ocurre fuera de horario, cuando el incidente depende de un tercero o cuando la información inicial es contradictoria.
Finalmente ejecutaría un ejercicio con evolución progresiva: primero una caída limitada, después afectación a clientes y, por último, indicios de exfiltración. El objetivo es comprobar que el equipo reevalúa la clasificación, conserva evidencia y actualiza comunicaciones sin esperar a disponer de certeza absoluta.
La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.
En Incidentes TIC en DORA: clasificar tarde ya es llegar tarde, el análisis debería cubrir al menos servicios financieros, acuerdos contractuales, funciones TIC, proveedores directos, subcontratistas, países de prestación, criticidad y dependencia. Esto exige coordinar a Dirección, Riesgo TIC, Continuidad, Seguridad, Operaciones, Compras, Legal y propietarios del servicio y trabajar sobre servicios, funciones TIC, contratos, proveedores, subcontratistas, ubicaciones, datos, dependencias y estrategias de salida. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.
Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.
Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.
La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.
| Dimensión | Qué debe quedar definido | Evidencia esperada |
|---|---|---|
| Alcance | Procesos, servicios, sistemas y terceros incluidos en «Incidentes TIC en DORA: clasificar tarde ya es llegar tarde». | Alcance aprobado, inventario y exclusiones justificadas. |
| Responsabilidad | Quién decide, ejecuta, valida y acepta desviaciones. | RACI, actas, aprobaciones y propietarios nominativos. |
| Operación | Actividades repetibles, entradas, salidas, plazos y escalados. | Procedimiento, tickets, registros, alertas y métricas. |
| Eficacia | Cómo se comprueba que el control cambia el riesgo o el resultado. | Pruebas, tendencias, incidencias, muestreo y acciones. |
Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.
El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.