Preparación para DORA de las entidades financieras y sus proveedores de TIC

DORA, el Reglamento sobre la resiliencia operativa digital del sector financiero, es aplicable desde el 17 de enero de 2025. Para las entidades financieras, estar preparado significa ahora mantener un modelo operativo de resiliencia operativa digital, no prepararse para un plazo futuro. Para los proveedores de tecnología, significa entender sus responsabilidades frente a los clientes y si les es aplicable un régimen independiente de supervisión directa.

La pregunta para la dirección es práctica: ¿puede la organización explicar qué servicios financieros dependen de qué sistemas de TIC, cómo se gestionará una interrupción y qué evidencias respaldan sus supuestos de recuperación? Las políticas importan, pero no pueden responder solas a esa pregunta. La dirección necesita una visión conectada de responsabilidades, dependencias, contratos, pruebas, incidentes y riesgos sin resolver.

Determine su papel antes de elaborar la lista de verificación

Empiece por una decisión de aplicabilidad documentada para cada entidad jurídica pertinente. El artículo 2 de DORA identifica las categorías incluidas y las exclusiones. Que una empresa se describa como fintech, startup o pyme no la incluye ni la excluye automáticamente.

Entre los ejemplos de entidades financieras incluidas figuran las entidades de crédito, las entidades de pago, las empresas de servicios de inversión y las empresas de seguros, con sujeción a las reglas detalladas de ámbito del reglamento. Registre la categoría aplicable, cualquier exclusión o exención, la autoridad competente correspondiente y el razonamiento que sustenta su conclusión.

Para los proveedores, distinga tres posiciones:

Un proveedor que da soporte a una función financiera esencial o importante no es, solo por ello, un proveedor tercero crítico de servicios TIC designado. Las entidades financieras evalúan la importancia de sus funciones y dependencias; la designación de los proveedores críticos se realiza a través del marco de supervisión del artículo 31.

La ubicación no resuelve la cuestión del proveedor. Un proveedor de nube o de software con sede en EE. UU. puede tener que atender requisitos de clientes relacionados con DORA cuando presta servicio a entidades financieras de la UE. Esa relación comercial no lo somete automáticamente a todas las obligaciones impuestas a una entidad financiera.

La proporcionalidad también requiere una evaluación razonada. El artículo 4 tiene en cuenta factores como el tamaño, el perfil de riesgo global y la naturaleza, escala y complejidad de los servicios. El artículo 16 establece un marco simplificado de gestión del riesgo de TIC para determinadas categorías. No son conceptos intercambiables, y la condición de pyme ordinaria no es un atajo universal. Conserve el análisis de elegibilidad junto con la decisión de ámbito.

Haga visible la responsabilidad de la dirección

Según el artículo 5 de DORA, el órgano de dirección asume la responsabilidad última de la gestión del riesgo de TIC de la entidad financiera. Delegar la implantación en un CISO, en un equipo tecnológico o en un proveedor externo no transfiere esa responsabilidad.

La dirección debe establecer quién propone las decisiones, quién las aprueba y quién comprueba si la implantación funciona. El modelo operativo debe abarcar la continuidad de negocio, la respuesta y recuperación ante incidentes, los acuerdos con terceros, el presupuesto y los conocimientos necesarios para una supervisión efectiva.

Una recomendación práctica es entregar a la dirección un paquete de información orientado a decisiones en lugar de un cuadro de mando con porcentajes de avance. Incluya:

• Funciones esenciales o importantes con supuestos de recuperación sin probar.
• Incidentes relevantes, efectos en los clientes y acciones correctivas pendientes.
• Dependencias de proveedores con contratos incompletos u opciones de salida débiles.
• Carencias de control significativas, responsables y fechas de corrección.
• Decisiones que requieren financiación, un cambio de proveedor o una respuesta explícita al riesgo.

Cada carencia debe distinguir el requisito normativo, la debilidad operativa actual y la solución propuesta. La falta de un registro de aprobación no es lo mismo que una copia de seguridad que no puede restaurarse. Ambas pueden requerir actuaciones, pero con responsables y prioridades diferentes.

La aprobación por la dirección de un plan de corrección no es un permiso para aplazar indefinidamente las obligaciones aplicables. Cuando una carencia sea relevante, considere salvaguardas inmediatas, el escalado y cualquier implicación ante el supervisor junto con la solución a más largo plazo.

Construya el programa en torno a las funciones financieras

Un inventario de activos es necesario, pero la planificación de la resiliencia debe empezar por el servicio que tiene que continuar. Identifique la función financiera, su responsable de negocio, las consecuencias de una interrupción y los sistemas y proveedores que la soportan.

Para un servicio de pago, trace la identidad, la infraestructura en la nube, el procesamiento de transacciones, la monitorización y el escalado a los proveedores. Incluya dependencias menos visibles como el DNS, la conectividad, el acceso privilegiado, las claves de cifrado y las herramientas de soporte. Un entorno de producción alternativo puede quedar inutilizable si depende del mismo servicio de identidad que ha fallado.

El mapa resultante debe conectar cada función con:

• Las aplicaciones, la infraestructura, los activos de información y los servicios externos que la soportan.
• Los contratos y responsables de servicio pertinentes.
• Los objetivos de recuperación y el análisis de impacto en el negocio que los respalda.
• Los mecanismos de detección, respuesta, recuperación y comunicación.
• Las pruebas, los hallazgos y los riesgos de dependencia sin resolver.

Valide el mapa con los equipos de operaciones y de negocio. Los registros de compras muestran lo que se adquirió; no muestran necesariamente cómo funciona hoy un servicio.

Utilice este modelo para organizar la gestión del riesgo de TIC, la gestión y notificación de incidentes, las pruebas de resiliencia y el riesgo de terceros proveedores de TIC. DORA también contiene disposiciones sobre el intercambio voluntario de información sobre ciberamenazas. Si participa, defina la pertenencia, la confidencialidad, el uso permitido y las normas de tratamiento, en lugar de tratar el intercambio como un trasvase sin restricciones de datos sobre incidentes.

Convierta la gestión del riesgo de TIC en trabajo financiado

Las disposiciones de DORA sobre gestión del riesgo de TIC abarcan la identificación, la protección y prevención, la detección, la respuesta y recuperación, el aprendizaje y la comunicación. El marco debe conectar estas actividades en lugar de dejarlas como colecciones de políticas separadas.

Empiece el análisis de carencias por las funciones trazadas. Pregunte si los controles de acceso protegen sus sistemas, si se tratan las vulnerabilidades, si los cambios están controlados, si se detecta la actividad sospechosa y si los mecanismos de recuperación reflejan fallos realistas. Considere los fallos técnicos y los errores operativos además de los ataques malintencionados.

Para cada debilidad relevante, cree un registro de corrección que contenga un responsable, el impacto en el negocio, la acción necesaria, los criterios de finalización y la evidencia de cierre. Las dependencias importan: mejorar los procedimientos de restauración puede exigir cambios en el acceso a las copias de seguridad, en los compromisos de los proveedores y en la formación del personal antes de que sea posible una prueba satisfactoria.

Los objetivos de recuperación deben derivarse de las necesidades del negocio y del análisis de impacto, no de lo que ofrezca el nivel de servicio estándar de un proveedor. Cuando la capacidad técnica no pueda cumplir el objetivo, la dirección debe decidir si mejora la arquitectura, cambia las condiciones del servicio o replantea el modelo operativo. Un objetivo escrito en un plan de continuidad no es una evidencia de recuperabilidad.

Prepare las decisiones sobre incidentes antes de la interrupción

DORA exige a las entidades financieras gestionar los incidentes relacionados con las TIC y notificar los incidentes graves a la autoridad competente correspondiente. Los artículos 17 a 23 establecen el marco; las normas técnicas de regulación y de ejecución aplicables aportan los criterios detallados de clasificación, los umbrales, el contenido de las notificaciones y los procedimientos.

No confíe en una lista de verificación genérica de incidentes para el calendario detallado de notificación. Mantenga una matriz de notificación actualizada que identifique las normas aplicables, las instrucciones de la autoridad, el canal de presentación, las fases de notificación y el cómputo de los plazos. Asigne la responsabilidad de mantenerla al día.

El proceso de respuesta debe hacer ejecutables bajo presión varias decisiones:

• ¿Quién registra las marcas de tiempo de detección, evaluación y clasificación?
• ¿Quién obtiene la información de impacto de operaciones y de los proveedores?
• ¿Quién decide si se cumplen los criterios de incidente grave?
• ¿Quién aprueba y presenta las notificaciones, también fuera del horario laboral habitual?
• ¿Quién gestiona la comunicación con los clientes y otras notificaciones aplicables?

Registre el razonamiento de la clasificación aunque un incidente no se notifique como grave. Una imagen inicial incompleta debe dar lugar a una nueva evaluación a medida que avanza la información, no a la suposición permanente de que el evento es menor.

Los compromisos de notificación de los proveedores deben dejar a la entidad financiera tiempo suficiente para evaluar y cumplir sus propias obligaciones. Las tareas de notificación pueden externalizarse cuando esté permitido, pero la responsabilidad sigue recayendo en la entidad financiera.

Cuando un incidente grave relacionado con las TIC afecte a los intereses financieros de los clientes, DORA exige a las entidades financieras informar a esos clientes sin dilación indebida sobre el incidente y las medidas adoptadas para mitigar sus efectos adversos. Evalúe por separado las obligaciones relativas a las violaciones de la seguridad de los datos personales y otras normas aplicables. Una misma interrupción puede generar varias decisiones de notificación, con destinatarios y criterios jurídicos diferentes.

Pruebe los supuestos en los que se apoya la dirección

Un programa de pruebas de resiliencia operativa digital debe ser proporcionado y basado en el riesgo. Las evaluaciones de vulnerabilidades, los ejercicios de escenarios, las pruebas de seguridad y las pruebas de recuperación responden a preguntas distintas; ninguna debe tratarse como sustituto universal de las demás.

Un ejercicio de mesa puede determinar si los responsables de decidir entienden el escalado. No puede demostrar que los datos de las transacciones se restauren con exactitud. Una prueba de penetración puede poner de manifiesto debilidades explotables sin demostrar que un proveedor alternativo pueda hacerse cargo de un servicio.

Para cada prueba, defina la función, el escenario, el alcance, los criterios de éxito, las garantías de independencia cuando se exijan y las evidencias esperadas. Conserve los resultados, los hallazgos, las decisiones de corrección y los resultados de las nuevas pruebas. Contraste la cobertura y la frecuencia exigidas con DORA y las normas pertinentes, incluidas las exenciones o las disposiciones del marco simplificado.

Las pruebas de penetración basadas en amenazas (TLPT) son un requisito de supervisión independiente para determinadas entidades financieras según el artículo 26. No son una obligación general para todas las empresas financieras o proveedores de TIC.

La dirección debe revisar los supuestos que han fallado, no solo si las pruebas se realizaron. Si un ejercicio revela que la restauración depende de un único administrador que no está disponible, el resultado es un riesgo operativo que requiere actuación, no un hito de pruebas completado.

Trate el riesgo de terceros como una cuestión de continuidad del servicio

Según DORA, una entidad financiera sigue siendo responsable de sus obligaciones cuando utiliza proveedores de TIC. Los artículos 28 a 30 conectan la evaluación del riesgo de terceros, los acuerdos contractuales, la supervisión y la planificación de la salida.

Mantenga el registro y la imagen operativa

Las entidades financieras deben mantener un registro de información sobre los acuerdos contractuales de TIC en los niveles individual, subconsolidado y consolidado exigidos. Utilice las normas de ejecución aplicables para su estructura. Una hoja de cálculo de compras o una lista de proveedores aprobados no es automáticamente suficiente.

Concilie el registro con los contratos, la responsabilidad de los servicios y los mapas de dependencias. Mantenga las distinciones exigidas para los servicios que soportan funciones esenciales o importantes. Un nuevo subcontratista, una nueva ubicación del servicio o una ampliación del alcance pueden cambiar la imagen de riesgo aunque el nombre del proveedor siga siendo el mismo.

Revise los contratos frente al servicio real

Evalúe los requisitos contractuales aplicables, incluidas las descripciones de los servicios, las ubicaciones, la protección de datos, el acceso a los datos y su recuperación, la asistencia ante incidentes, la cooperación, los derechos de terminación y los niveles de servicio. Los acuerdos que soportan funciones esenciales o importantes requieren disposiciones adicionales, entre ellas las relativas a la información, la continuidad, el acceso, la inspección, la auditoría y la salida.

Los responsables jurídicos, de compras, de tecnología y de negocio deben revisarlos conjuntamente. Un derecho contractual de auditoría puede ser difícil de ejercer en la práctica; un mecanismo de recuperación prometido puede no cubrir toda la cadena de servicio del cliente. Identifique esas limitaciones antes de aceptar el acuerdo.

Examine la concentración y la capacidad de salida

El riesgo de concentración no se limita a contratar varios servicios a una misma empresa. Distintos proveedores pueden depender de la misma plataforma en la nube, región, red o subcontratista. Evalúe la sustituibilidad, la complejidad de la migración y las consecuencias de un fallo común.

Un plan de salida debe abordar los formatos de datos, la extracción, el acceso, las dependencias de la migración, el apoyo en la transición, la supresión y la continuidad durante el traslado. En las funciones esenciales o importantes, trate la prueba y la revisión de la salida como un trabajo sustantivo, no como un ejercicio de redacción de documentos.

Los proveedores pueden preparar un paquete de aseguramiento coherente que contenga el alcance del servicio, los límites de responsabilidad, los contactos para incidentes, las evidencias de continuidad, la información sobre subcontratación y sus posiciones contractuales. Los requisitos específicos de cada cliente siguen necesitando revisión; un certificado no los sustituye.

Entienda dónde se encuentran DORA y NIS2

DORA es un reglamento de la UE directamente aplicable. NIS2 es una directiva que se aplica mediante legislación nacional, y su aplicabilidad depende del sector, el tamaño, el servicio y las reglas de inclusión. Su plazo de transposición nacional venció el 17 de octubre de 2024; las organizaciones deben examinar la transposición nacional aplicable en lugar de suponer un único régimen operativo idéntico.

El artículo 1, apartado 2, de DORA, junto con el artículo 4 de NIS2, establece la relación sectorial para las entidades financieras incluidas en los ámbitos pertinentes. No lo interprete como una instrucción de duplicar controles equivalentes de gestión de riesgos y notificación de incidentes. Tampoco suponga que elimina las obligaciones de todas las empresas de un grupo financiero o de su cadena de suministro.

Un proveedor de servicios gestionados que presta servicio a un banco puede necesitar su propia evaluación de NIS2 mientras cumple compromisos contractuales relacionados con DORA. Una matriz de obligaciones por entidad debe registrar la base jurídica, el ámbito, la autoridad, la vía de notificación y las evidencias exigidas.

Los controles compartidos pueden servir para DORA, ISO 27001, las obligaciones de privacidad y el aseguramiento ante clientes cuando el alcance y las evidencias coinciden. Reutilice una revisión de accesos o una prueba de recuperación cuando respalde realmente varios requisitos, conservando los detalles propios del sector financiero. Un certificado ISO 27001 no acredita el cumplimiento de DORA.

El régimen sancionador también difiere. Las facultades de supervisión y las sanciones de DORA para las entidades financieras dependen de sus disposiciones y de las medidas nacionales aplicables; los proveedores críticos designados tienen un régimen de supervisión independiente. No presupueste el riesgo en torno a una supuesta multa universal de DORA. Evalúe la exposición jurídica pertinente y las consecuencias operativas de una resiliencia insuficiente.

Ejemplo práctico: revisión de las dependencias de un servicio de pago

Pensemos, a modo ilustrativo, en una entidad de pago que utiliza una plataforma en la nube, un proveedor de identidades y un servicio de monitorización externalizado. Supongamos que la entidad está en el ámbito de DORA y que la ejecución de pagos está clasificada como función esencial o importante.

La primera revisión detecta tres debilidades: los entornos de producción y de recuperación comparten la misma dependencia de identidad; el proceso de escalado de incidentes del proveedor de monitorización no está claro; y el plan de salida de la nube menciona un proveedor alternativo sin demostrar la extracción y la migración de los datos.

La dirección encarga tres paquetes de trabajo vinculados:

El responsable de negocio comprueba si los objetivos de recuperación de pagos siguen siendo alcanzables. Cumplimiento verifica que los procedimientos de notificación y las entradas del registro reflejan los acuerdos. La dirección aprueba la financiación necesaria y revisa las limitaciones que persisten.

Este ejemplo no acredita por sí solo el cumplimiento. Muestra cómo una sola función puede sacar a la luz decisiones que permanecerían ocultas en listas de verificación separadas de políticas, proveedores y pruebas.

Establezca un ritmo de revisión basado en evidencias

DORA no tiene un proceso de certificación universal que sustituya a las obligaciones continuas. El aseguramiento independiente puede informar a la dirección, pero la preparación debe demostrarse mediante controles en funcionamiento, registros y, cuando se exija, la relación con el supervisor.

Un siguiente paso práctico es seleccionar una función esencial o importante y reunir su decisión de ámbito, el mapa de dependencias, la evaluación de riesgos, los contratos, los procedimientos de incidentes, los resultados de las pruebas y las acciones abiertas. Revise si esos registros cuentan una historia coherente.

Secani apoya este flujo de trabajo modelando sistemas y servicios, conectando dependencias y manteniendo en contexto los requisitos, las evidencias, los responsables, las tareas y las decisiones de revisión. Suba el material existente vinculado a los objetos pertinentes, convierta las carencias en trabajo asignado y conserve la aprobación humana explícita de las sugerencias y conclusiones asistidas por IA.

Amplíe a partir de esa primera función una vez que estén claros los responsables y las vías de evidencia. La dirección debe poder ver qué se ha demostrado, qué sigue siendo incierto y qué decisión hace falta a continuación.