DORA: lo que su RSSI no le contó.

La mayoría de las entidades financieras no empezaron DORA desde cero. Tenían un ISMS, un plan de continuidad de negocio, una política de externalización, y un inventario de terceros que eran en su mayoría contratos de compras. DORA no descarta eso. Lo reformula, eleva el listón en dos pilares en particular, y desplaza la conversación de "¿tiene usted un control?" a "¿puede demostrar que su servicio sigue funcionando cuando un proveedor de TIC falla?". Esta página trata sobre esa brecha: cómo aterrizan realmente los cinco pilares en las operaciones, qué abre primero un supervisor, y dónde pierden tiempo los equipos.

Los cinco pilares, y quién es auditado en cada uno

El reglamento se construye sobre cinco pilares. No tienen el mismo peso en la práctica. El Pilar 1 es fundamental pero familiar para cualquiera que opere un ISMS. Los Pilares 3 y 4 son donde se concentra la atención supervisora, porque producen evidencia difícil de falsificar y fácil de poner a prueba. La tabla siguiente es la versión que utilizamos para informar a un consejo: qué exige cada pilar, y quién dentro de la entidad acaba más expuesto cuando el regulador pide pruebas.

Qué hacer primero

El error es empezar por la actualización de políticas, porque ese es el trabajo cómodo. Empiece en cambio por los dos artefactos que un supervisor puede pedir por escrito y que más tardan en construirse correctamente: el registro de terceros de TIC y el mapeo de las funciones críticas o importantes a los activos y proveedores de TIC que las sustentan. Todo lo demás depende de ese mapeo. No puede delimitar el alcance de las pruebas de resiliencia, no puede clasificar la gravedad de los incidentes, y no puede razonar sobre el riesgo de concentración hasta que sepa qué funciones son críticas y de qué dependen.

Una secuencia viable para los primeros 90 días:

1. Defina sus funciones críticas o importantes. Esta es una decisión de negocio, no de seguridad. Determina el alcance de casi todas las demás obligaciones.
2. Mapee cada función crítica a los servicios de TIC, internos y externalizados, de los que depende. Este es su grafo de dependencias.
3. Construya el registro de terceros a partir de ese grafo, no a partir de la hoja de cálculo de compras. El registro debe describir los acuerdos que sustentan funciones, incluidos los subcontratistas de la cadena.
4. Cierre primero las brechas contractuales que DORA exige (derechos de auditoría, estrategias de salida, transparencia de la subcontratación, cooperación en incidentes) sobre los acuerdos que sustentan funciones críticas.
5. Solo entonces formalice el marco de gestión del riesgo de TIC y el programa de pruebas, porque ambos tienen ya un alcance definido contra el cual trabajar.

El registro de terceros de TIC (Pilar 4) en la práctica

El registro no es una lista de proveedores. Es un conjunto estructurado de registros de información que la entidad mantiene y que las autoridades competentes recopilan, en una plantilla definida, para ver la concentración de TIC en todo el sector financiero. Eso cambia cómo se construye. Un campo que es "suficientemente bueno" para uso interno se convierte en un problema de calidad de datos cuando se agrega a nivel nacional y de la UE. Tres cosas causan la mayor parte del dolor.

Primero, la unidad es el acuerdo contractual, no el proveedor. Un mismo proveedor puede situarse detrás de varios acuerdos, y un mismo acuerdo puede sustentar varias funciones. Está describiendo un grafo de muchos a muchos, y aplanarlo en una fila por proveedor no sobrevivirá a la revisión.

Segundo, tiene que seguir la cadena. El registro debe capturar los subcontratistas que efectivamente sustentan una función crítica o importante, lo que significa que su visibilidad sobre el proveedor tiene que llegar más allá de su contraparte directa. Si su contrato no le da el derecho a saber quién es el cuarto tercero, esa es una brecha contractual que cerrar, no un campo que dejar en blanco.

Tercero, el indicador de criticidad de función en cada acuerdo es el campo del que todo lo demás depende. Marque demasiado como crítico y ahogará sus propias pruebas y remediación contractual; marque demasiado poco y subestimará el riesgo de concentración y engañará al supervisor. Acierte la evaluación de criticidad una vez, a nivel de función, y deje que se propague.

Pruebas de penetración basadas en amenazas (Pilar 3): cómo es realmente la sala

El TLPT es el pilar que sorprende a la gente, porque no se parece a una prueba de penetración rutinaria. Está dirigido por inteligencia, se ejecuta contra sistemas de producción en vivo, está delimitado a las funciones críticas o importantes, y se realiza conforme a la metodología TIBER-EU con la autoridad nacional involucrada. Las entidades significativas lo ejecutan al menos en un ciclo de tres años. Está más cerca de un ejercicio de red team supervisado que de un escaneo de vulnerabilidades, y el entregable que importa no es la lista de hallazgos; es la evidencia de que la detección y la respuesta funcionaron, o el relato honesto de por qué no lo hicieron.

Tres realidades que los equipos subestiman:

• El alcance lo determinan las funciones críticas, no lo que es conveniente probar. Si una función abarca un proveedor externalizado, ese proveedor puede tener que estar dentro del alcance, lo que significa que la cooperación del proveedor tiene que asegurarse contractualmente por adelantado.
• Por lo general no se avisa al blue team. El valor está en probar la detección y la respuesta reales, así que un TLPT del que se haya advertido a los defensores ha perdido la mayor parte de su sentido. Eso tiene consecuencias organizativas que se planifican, no se descubren a mitad del ejercicio.
• Los probadores y los proveedores de inteligencia de amenazas deben cumplir requisitos de competencia e independencia, y la autoridad revisa el proceso. No puede simplemente reetiquetar el pentest anual del año pasado como TLPT.

Si su entidad está por debajo del umbral de significatividad, no ejecutará TLPT, pero aun así debe un programa de pruebas basado en el riesgo: evaluaciones de vulnerabilidad, pruebas basadas en escenarios, y pruebas de resiliencia de la vía de recuperación. El curso Lead Operational Resilience Manager está construido en torno exactamente a esta capa de pruebas y evidencia orientada al supervisor, y el curso DORA Lead Manager cubre cómo se gobierna el programa completo de extremo a extremo.

DORA como lex specialis sobre NIS 2 para los bancos

Los bancos, y la mayoría de las demás entidades financieras, caen dentro del ámbito tanto de NIS 2 como de DORA. Los dos se solapan en gran medida en el riesgo de TIC, la notificación de incidentes y la seguridad de la cadena de suministro, lo que plantea el temor evidente de hacerlo todo dos veces. DORA lo resuelve: en las materias de TIC que rige, DORA es lex specialis. La norma específica desplaza a la general. Allí donde DORA establece la obligación de gestión del riesgo de TIC y de notificación de incidentes, una entidad financiera sigue DORA, y las autoridades competentes no deberían aplicar el requisito equivalente de NIS 2 por encima de ella para la misma materia de TIC.

Lo que esto no significa: no desactiva por completo NIS 2 para una entidad financiera, y no cambia cuál es su autoridad competente para las materias no relacionadas con las TIC. La decisión práctica para un banco es mapear cada obligación a su instrumento rector: la resiliencia operativa de TIC, la notificación de incidentes y el riesgo de terceros de TIC se rigen por DORA; cualquier cosa fuera de DORA es un alcance que evalúa por separado. Documente ese mapeo. Es la respuesta a la pregunta de "¿está contando dos veces o de menos?" que tanto los examinadores como los auditores plantean.

Errores comunes y dónde construir la competencia

Los fallos recurrentes no son exóticos. El registro se construye por proveedor en lugar de por acuerdo y se rompe en cuanto la subcontratación importa. La criticidad de las funciones críticas la evalúa el área de TI en lugar del negocio, de modo que el alcance de todo lo que viene después es erróneo. Los umbrales de clasificación de incidentes se redactan pero nunca se prueban contra un incidente real, de modo que el primer evento grave se convierte en el primer ensayo del calendario de notificación. Y la continuidad de negocio se trata como un proyecto ISO 22301 separado en lugar de como el músculo de recuperación que las pruebas de DORA están destinadas a ejercitar.

Ese último punto importa: DORA no reemplaza un sistema de gestión de continuidad de negocio, lo presupone. Los objetivos de recuperación y la vía de recuperación probada que le da un BCMS son lo que las pruebas de resiliencia validan. Construya el BCMS correctamente con el curso ISO 22301 Lead Implementer, y se convierte en el sustrato sobre el que se apoyan las obligaciones de resiliencia operativa en lugar de un archivador paralelo que nadie abre.

Si parte del reglamento en sí, el curso DORA Foundation da a todo el equipo una lectura compartida y exacta de los cinco pilares y del ámbito antes de que nadie toque el registro o el programa de pruebas. A partir de ahí, el curso DORA Lead Manager es la capa de implementación y gobernanza para las personas que serán propietarias del marco, y el curso Lead Operational Resilience Manager es para la función que tiene que presentarse ante el supervisor y demostrar que la resiliencia es real, no documentada.