DORA: lecciones del primer año

Por Jonas Osman Abdelghafour.

Un ciclo completo de notificación de incidentes bajo la Ley de Resiliencia Operativa Digital (DORA) ha dejado un patrón claro: la restricción vinculante rara vez es la tecnología de detección. Es la capacidad de clasificar correctamente un incidente, reunir datos de impacto precisos y presentar el informe dentro de plazos ajustados mientras el incidente aún se está gestionando. Las entidades que tuvieron dificultades lo hicieron por razones organizativas, no técnicas.

La clasificación es la parte difícil

Los criterios de clasificación de DORA —clientes y contrapartes afectados, duración e indisponibilidad del servicio, alcance geográfico, pérdidas de datos, criticidad de los servicios afectados e impacto económico— son razonables por separado y exigentes en conjunto bajo presión de tiempo. Evaluarlos requiere saber qué servicios de negocio dependen del componente afectado, cuántos clientes hay detrás de esos servicios y cuál fue realmente la indisponibilidad.

Las entidades con un mapa mantenido de servicios de negocio a aplicaciones e infraestructura respondieron en horas. Las que no lo tenían dedicaron la ventana de notificación a reconstruir el mapa a partir del conocimiento tácito, lo cual es a la vez lento y poco fiable. La inversión más valiosa que sale del primer año no son las herramientas; es un mapa de dependencias de servicio que se mantiene actualizado como un control, y no que se refresca para una auditoría.

La segunda lección de clasificación tiene que ver con la agregación. Los incidentes recurrentes que individualmente quedan por debajo de los umbrales pueden llegar a ser notificables cuando se vinculan entre sí. Eso requiere un registro de incidentes estructurado para identificar la causa raíz común, algo que muchos sistemas de tickets no admiten por defecto.

Los plazos obligan a tener un proceso preconstruido

El modelo de notificación por fases —notificación inicial, informe intermedio, informe final— presupone que una entidad puede producir rápidamente una visión preliminar defendible y refinarla después. Dos comportamientos provocan el fallo. El primero es esperar a tener certeza antes de notificar; el marco no exige certeza en la fase inicial. El segundo es una cadena de revisión legal y de comunicaciones diseñada para una divulgación meditada y no para plazos regulatorios.

El remedio es aburrido y eficaz: plantillas precargadas con datos fijos de la entidad, un aprobador delegado con autoridad para presentar el informe fuera de horario, un responsable de notificación de incidentes designado y separado del responsable de gestión del incidente, y un ensayo en cada ejercicio de resiliencia importante. Las entidades que ensayaron su proceso de notificación en una simulación antes de necesitarlo tuvieron el primer año más fluido.

El registro de terceros justifica su coste

El registro de información sobre acuerdos con proveedores externos de TIC se percibió ampliamente como una carga de recopilación de datos. Se convierte en un activo en el momento en que un incidente involucra a un proveedor, porque responde de inmediato qué contratos, qué servicios, qué criticidad y qué acuerdos de salida aplican. Los problemas recurrentes de calidad de datos no fueron sorprendentes: identificadores de entidad inconsistentes, cadenas de subcontratación registradas solo hasta el primer nivel, y evaluaciones de criticidad heredadas en lugar de evaluadas.

La concentración en cuartos proveedores es el riesgo que este ejercicio expone y que pocas entidades han abordado. Varios proveedores que descansan sobre la misma región de nube o el mismo proveedor de identidad constituyen un punto único de fallo que la evaluación por proveedor individual no puede ver. El análisis debe realizarse a través de todo el registro, no dentro de cada entrada.

Pruebas que producen hallazgos que merecen la pena

Las pruebas de resiliencia bajo DORA solo son útiles cuando los escenarios son graves y verosímiles: pérdida de un proveedor crítico, corrupción y no solo indisponibilidad de datos, y compromiso de las propias herramientas usadas para responder. Las pruebas de penetración basadas en amenazas, para las entidades dentro del alcance, deben apuntar a los servicios de negocio, no solo a la infraestructura. Los hallazgos deben seguirse hasta su cierre con la misma disciplina que los hallazgos de validación, y los supuestos de tiempo de recuperación usados en la planificación de resiliencia deben probarse, no simplemente afirmarse.

Prioridades para el segundo año

• Mantener el mapa de dependencias de servicio a activo como un control vivo con un responsable.
• Automatizar la extracción de datos de clasificación desde fuentes de monitorización y CRM.
• Delegar la autoridad de presentación y ensayar la vía de notificación fuera de horario.
• Depurar el registro de terceros y analizar la concentración a través de él, incluidos los subcontratistas.
• Probar escenarios de corrupción de datos y pérdida de proveedores, y validar los tiempos de recuperación declarados.
• Reportar la postura de resiliencia al consejo en términos de servicios de negocio, no de recuentos de sistemas.

La pregunta subyacente de DORA es si una entidad puede seguir prestando servicios críticos a través de una disrupción. El régimen de notificación es simplemente el mecanismo que hace visible la respuesta honesta.

Fuentes primarias: Reglamento (UE) 2022/2554 (DORA) y las RTS/ITS relacionadas sobre clasificación, notificación de incidentes y el registro de información; Informe de Evaluación de Riesgos de la EBA, junio de 2026.