Resiliencia operativa y cumplimiento técnico de DORA y NIS2
DORA (Reglamento UE 2022/2554, aplicable desde el 17 de enero de 2025) y NIS2 (Directiva UE 2022/2555) piden algo que no se resuelve con un documento: gestionar y clasificar incidentes, probar que la recuperación funciona, saber de qué proveedores dependéis y poder demostrarlo con evidencias. Esa parte es trabajo de ingeniería, y es la que hacemos: montamos el proceso, las pruebas y la recogida automática de evidencias sobre vuestra infraestructura. Es un servicio técnico que complementa, y no sustituye, el asesoramiento jurídico o de cumplimiento.
Última actualización:
Lo que pide la norma y no cabe en un documento
Para quién es
Para entidades financieras y sus proveedores tecnológicos, y para empresas de energía, transporte, salud, agua, administraciones y resto de sectores que NIS2 considera esenciales o importantes. En la práctica, para cualquiera que tenga que responder por escrito a un supervisor, a un auditor o al departamento de riesgos de un cliente grande.
Qué problema resuelve
Que la parte técnica del cumplimiento se improvisa. Hay política de continuidad, pero nadie ha probado nunca a restaurar; hay registro de incidentes, pero sin criterios de clasificación que dos personas apliquen igual; hay lista de proveedores, pero no un mapa de qué servicio cae si cae cada uno. Cuando llega la petición de evidencias, el equipo pasa tres semanas haciendo capturas de pantalla.
Dónde está el límite de lo que hacemos
No somos asesores jurídicos y no interpretamos la norma por vosotros: no decimos si sois entidad esencial o importante, ni redactamos las políticas que firma la dirección, ni representamos a nadie ante un supervisor. Trabajamos con quien lleve vuestro cumplimiento, cogemos los requisitos técnicos que nos pase y los convertimos en procesos, pruebas y evidencias que existen de verdad.
Qué se construye
Incidentes clasificables
Criterios de severidad y de materialidad escritos, con el árbol de decisión, los plazos de notificación y las plantillas. Para que dos personas distintas clasifiquen igual el mismo incidente.
Recuperación probada
Pruebas de restauración y de conmutación con calendario, objetivos de tiempo y de punto de recuperación medidos, y el resultado registrado. Probar es la evidencia; tener copias no.
Dependencias mapeadas
Inventario de activos y de proveedores TIC, con qué servicio depende de cada uno, qué pasa si falla y cuál es la salida. Incluidas las dependencias de cuarta parte que nadie suele mirar.
Qué entregamos
Gestión y clasificación de incidentes
Proceso escrito y en funcionamiento: detección, clasificación por severidad y por materialidad, roles, plazos, comunicación interna y externa, y registro con todo lo que luego se pide. Con la plantilla de notificación preparada de antemano, porque el día del incidente no es el día de redactarla.
Pruebas de resiliencia y de recuperación
Calendario de pruebas con su alcance: restauración de copias, conmutación entre zonas o proveedores, pérdida de una dependencia externa y degradación controlada. Cada prueba deja objetivos medidos, desviaciones y acciones, firmadas y archivadas.
Inventario y mapa de dependencias
Activos, servicios y proveedores TIC con su criticidad, la función de negocio que soportan y la estrategia de salida de cada uno. Mantenido como código, no como una hoja de cálculo que se queda vieja en tres meses.
Evidencias automáticas
La recogida de evidencias se automatiza: registros de cambios, resultados de pruebas, estado de las copias, parcheado, accesos y revisiones periódicas se recopilan solos en un repositorio con fecha y trazabilidad. Es la diferencia entre una auditoría de tres semanas y una de tres días.
Qué queda fuera, dicho claro
El análisis jurídico, la calificación de la entidad, las políticas que firma el órgano de dirección, la relación con el supervisor y las pruebas de penetración guiadas por amenazas del marco TIBER, que exigen proveedor acreditado. Para lo primero, vuestro asesor; para una auditoría técnica o un pentest convencional, tenemos servicio propio.
Cómo trabajamos
Brecha técnica
Qué piden los requisitos que nos paséis, qué hay montado y qué falta. Por escrito, requisito a requisito, sin interpretar la norma.
Procesos y criterios
Clasificación de incidentes, plazos, plantillas y roles. Se prueban con incidentes pasados para ver si de verdad se aplican igual.
Pruebas y mapa
Primera ronda de pruebas de recuperación con resultados medidos, e inventario de dependencias mantenido como código.
Evidencias y ciclo
Automatización de la recogida, calendario de pruebas y revisión periódica. Lo que no se repite solo se deja de hacer al segundo trimestre.
Preguntas frecuentes
¿Esto nos deja conformes con DORA o con NIS2?
No por sí solo, y nadie puede prometerlo. El cumplimiento incluye gobernanza, análisis jurídico y decisiones del órgano de dirección que no son trabajo de ingeniería. Lo que hacemos es la parte técnica —procesos, pruebas, inventario y evidencias— que sin esto se queda en una política sin nada detrás.
¿Sustituye a nuestro asesor de cumplimiento?
No, trabajamos con él. Lo habitual es que nos pase los requisitos aplicables y nosotros devolvamos cómo quedan cubiertos técnicamente, con las evidencias que lo demuestran.
¿Hacéis las pruebas de penetración que pide DORA?
Hacemos auditorías técnicas y pentesting como servicio propio. Las pruebas avanzadas guiadas por amenazas del marco TIBER-EU exigen un proveedor acreditado para ello, y no lo somos: si os las piden, hay que contratarlas a quien lo sea.
Somos proveedor de un banco y nos exigen esto a nosotros.
Es el caso más frecuente. La cadena de requisitos de DORA llega a los proveedores tecnológicos a través del contrato, y lo que os van a pedir es casi siempre esto mismo: clasificación de incidentes, pruebas de recuperación, mapa de dependencias y evidencias. Se puede preparar antes de que llegue la primera auditoría del cliente.
¿Hace falta cambiar de proveedor de cloud para empezar?
No. El trabajo de fiabilidad se hace sobre lo que ya tenéis, sea AWS, Azure, Google Cloud, un proveedor europeo o vuestro propio hardware. La migración es otro servicio y solo tiene sentido si hay una razón para hacerla.
¿Cuánto tardamos en notar algo?
Lo primero que se nota es el ruido: una revisión de alertas suele dar resultado en las primeras semanas, porque buena parte de las que suenan no son accionables. Los SLOs tardan más, porque antes hay que medir, y no sirven de nada hasta que hay unas semanas de datos detrás.
¿Firmáis un acuerdo de confidencialidad?
Sí, si lo queréis, y nada de lo que veamos se usa como ejemplo en ningún sitio sin permiso por escrito. Los accesos se piden al mínimo necesario y se documentan.
¿Qué pasa si decidimos dejarlo?
Os quedáis con todo: los SLOs definidos, los runbooks, el código de infraestructura en vuestro repositorio, los paneles y la documentación. No hay permanencia ni nada que solo sepamos nosotros.
Cuéntanos qué os están pidiendo
Si tenéis un cuestionario de un cliente, una lista de requisitos o un informe de brecha, con eso basta para empezar. Respondemos en menos de 24 horas laborables.
o escríbenos a info@esdis.es