Ciberseguridad

Qué es DORA y por qué importa ahora

DORA, el Reglamento de Resiliencia Operativa Digital de la Unión Europea, establece un marco común para que el sector financiero gestione mejor los riesgos vinculados a tecnologías de la información y comunicación. Su objetivo no es solo reforzar la ciberseguridad, sino asegurar que las entidades puedan mantener servicios críticos, responder a incidentes y recuperarse ante interrupciones digitales.

La norma importa ahora porque la dependencia tecnológica del sector financiero es cada vez mayor. Banca, seguros, inversión, pagos, fintech y otros actores operan sobre infraestructuras digitales complejas, conectadas con proveedores externos y expuestas a incidentes que pueden afectar a clientes, mercados y continuidad del negocio.

Reglamento DORA: objetivo y alcance

El Reglamento DORA busca armonizar las exigencias de resiliencia operativa digital en el sector financiero europeo. Hasta su llegada, muchas entidades gestionaban ciberseguridad, continuidad, terceros, incidentes y pruebas con enfoques separados o con criterios distintos según país, supervisor o tipo de entidad.

La diferencia está en que DORA reúne esas piezas dentro de un marco común. Obliga a mirar el riesgo TIC de forma integrada: gobierno interno, gestión de incidentes, pruebas de resiliencia, control de proveedores, intercambio de información y supervisión. No se trata solo de proteger sistemas, sino de asegurar que la organización puede seguir operando aunque falle una parte crítica de su entorno digital.

En la práctica, esto implica que las entidades deben ser capaces de identificar activos críticos, evaluar riesgos tecnológicos, definir responsabilidades, documentar decisiones, probar escenarios y mejorar después de cada incidente. El cumplimiento existe, pero el fondo de la norma apunta a una capacidad más exigente: operar bajo presión sin perder control.

A quién afecta dentro del sector financiero

DORA afecta a una amplia variedad de entidades financieras dentro de la Unión Europea. No se limita a bancos tradicionales, porque el ecosistema financiero actual depende de muchos actores conectados entre sí.

Entre los perfiles incluidos están:

• Entidades financieras reguladas: bancos, entidades de pago, entidades de dinero electrónico, empresas de servicios de inversión, aseguradoras y reaseguradoras.
• Infraestructura y mercados: centros de negociación, gestores de fondos y otros actores vinculados a servicios financieros críticos.
• Nuevos operadores financieros: proveedores de criptoactivos y organizaciones que prestan servicios digitales dentro del ecosistema financiero.
• Proveedores externos TIC: empresas que prestan servicios críticos de cloud, software, comunicaciones, ciberseguridad, procesamiento de datos o infraestructura tecnológica.

Para los equipos internos, DORA no es responsabilidad exclusiva de compliance. Tecnología, ciberseguridad, riesgo, legal, compras, operaciones, negocio y dirección deben coordinarse. ¿Qué ocurre si cada área interpreta la norma desde su propio silo? Que la organización puede tener documentación correcta y, aun así, una respuesta débil ante incidentes reales. La resiliencia operativa necesita lenguaje común, criterios compartidos y responsabilidades claras.

Del cumplimiento formal a la resiliencia operativa digital

Cumplir DORA no debería limitarse a tener políticas, evidencias y procedimientos preparados para una revisión. Esa parte es necesaria, pero no suficiente. La resiliencia operativa digital se demuestra cuando una entidad puede mantener servicios críticos, coordinar equipos y recuperarse con rapidez ante un fallo tecnológico, un ciberincidente o una interrupción de un proveedor TIC.

La diferencia es importante porque muchas organizaciones pueden parecer preparadas sobre el papel y, aun así, responder mal bajo presión. DORA empuja a cerrar esa brecha entre documentación y capacidad real: no basta con describir cómo se gestionaría un incidente, hay que poder ejecutarlo con roles claros, información fiable, comunicación coordinada y aprendizaje posterior.

Por qué cumplir no siempre significa estar preparado

El cumplimiento formal suele mirar si existen políticas, controles, inventarios, contratos, registros de incidentes y evidencias. Todo eso importa, pero puede quedarse corto si no refleja cómo trabaja la organización en situaciones reales. Una entidad puede tener un procedimiento de continuidad actualizado y descubrir durante una caída que los equipos no saben quién decide, qué proveedor escalar o qué mensaje trasladar al negocio.

La preparación real exige algo más que documentación. Requiere que las personas conozcan sus responsabilidades, que los escenarios se hayan probado, que los proveedores críticos estén identificados y que la dirección entienda qué decisiones debe tomar cuando la operación está bajo presión. La resiliencia operativa no se valida en un documento, sino en la capacidad de actuar cuando el servicio falla.

La pregunta útil es sencilla: si mañana se interrumpe una plataforma crítica, ¿la entidad sabría qué hacer en la primera hora? Si la respuesta depende de improvisar, buscar contactos, interpretar contratos o reunir comités de urgencia sin reglas claras, el cumplimiento todavía no se ha convertido en resiliencia.

Cumplimiento vs resiliencia operativa

DORA obliga a cumplir, pero su valor práctico aparece cuando ese cumplimiento se traduce en una forma más madura de gestionar el riesgo digital. La diferencia no está en hacer más documentos, sino en conectar controles con decisiones, pruebas, responsables y continuidad del negocio.

Enfoque de cumplimiento	Enfoque de resiliencia operativa
Documentar políticas y procedimientos	Probar si los equipos pueden ejecutarlos bajo presión
Registrar proveedores TIC	Evaluar criticidad, dependencia y capacidad de sustitución
Notificar incidentes según obligación	Coordinar respuesta, comunicación y aprendizaje posterior
Tener planes de continuidad	Validar escenarios realistas de interrupción
Revisar controles de forma periódica	Ajustar procesos según fallos, pruebas e incidentes reales

Este cambio de enfoque evita que DORA se convierta en un ejercicio administrativo. El objetivo no es solo superar una revisión, sino reducir la fragilidad operativa de la entidad. Cumplir ayuda a ordenar el sistema, pero la resiliencia se demuestra cuando ese sistema responde.

Riesgo TIC, incidentes y continuidad: el núcleo operativo de DORA

La resiliencia operativa digital no se construye solo con políticas generales. Se construye cuando la entidad sabe qué activos son críticos, qué riesgos tecnológicos pueden afectar a la continuidad, quién debe decidir ante un incidente y cómo se recupera el servicio sin improvisar. Ahí está el núcleo operativo de DORA.

Este bloque es especialmente importante porque conecta la norma con la operación diaria. El riesgo TIC deja de ser una categoría abstracta y pasa a convertirse en una forma concreta de gestionar dependencias, vulnerabilidades, interrupciones, comunicación y recuperación. La resiliencia se juega en la capacidad de ejecutar bajo presión, no en la existencia aislada de procedimientos.

Gobierno del riesgo TIC y responsabilidades internas

El gobierno del riesgo TIC empieza por saber qué se está protegiendo y por qué importa. No todos los sistemas tienen la misma criticidad, ni todos los fallos afectan igual al negocio. Una caída en una herramienta interna puede ser incómoda; una interrupción en pagos, trading, atención a clientes o reporting regulatorio puede convertirse en un problema operativo, reputacional y supervisor.

Por eso DORA exige una visión integrada del riesgo tecnológico. La entidad necesita identificar activos críticos, mapear dependencias, asignar responsabilidades y conectar las decisiones técnicas con impacto de negocio. El riesgo TIC no puede quedar encerrado en tecnología, porque sus consecuencias afectan a continuidad, clientes, cumplimiento y dirección.

En la práctica, esto implica definir quién decide ante escenarios concretos, qué riesgos se aceptan, qué controles son prioritarios y qué información necesita cada nivel de responsabilidad. Sin esa claridad, los equipos pueden duplicar esfuerzos, escalar tarde o tomar decisiones contradictorias cuando el tiempo aprieta.

Gestión de incidentes TIC y comunicación coordinada

La gestión de incidentes TIC es uno de los puntos donde más se nota la diferencia entre cumplimiento y resiliencia. Una entidad puede tener un procedimiento de respuesta y, aun así, fallar si no sabe clasificar el incidente, activar equipos, comunicar a negocio, informar a supervisores o coordinar a proveedores en el momento adecuado.

DORA obliga a reforzar esa capacidad de respuesta. No se trata solo de registrar incidentes, sino de entender su impacto, priorizar acciones y asegurar que la comunicación interna y externa no agrava el problema. En un incidente real, la descoordinación puede ser tan dañina como el fallo técnico.

Aquí conviene revisar tres preguntas operativas:

• Qué se considera incidente relevante: criterios para distinguir un fallo menor de un evento que exige escalado, comunicación o notificación.
• Quién coordina la respuesta: responsabilidades entre seguridad, tecnología, negocio, compliance, comunicación y dirección.
• Qué se aprende después: revisión posterior para corregir causas, ajustar controles y mejorar la respuesta futura.

La gestión madura no termina cuando el servicio vuelve a funcionar. Termina cuando la entidad entiende qué ocurrió, qué decisiones funcionaron, qué dependencias fallaron y qué debe cambiar para reducir la probabilidad o el impacto de un nuevo incidente.

Continuidad operativa y pruebas de resiliencia

La continuidad operativa exige preparar escenarios antes de que ocurran. No basta con tener planes de recuperación escritos si nadie los ha probado, si los responsables no conocen su papel o si los proveedores críticos no están integrados en el ejercicio. Un plan no probado suele ser una hipótesis, no una capacidad real.

Las pruebas de resiliencia ayudan a comprobar si los sistemas, procesos y equipos pueden sostener la operación en condiciones adversas. Pueden incluir simulacros, pruebas técnicas, ejercicios de mesa, escenarios de caída de proveedor o validaciones de recuperación. Lo importante es que no se conviertan en ejercicios formales sin aprendizaje.

DORA empuja a que estas pruebas sean útiles para mejorar. Cada ejercicio debería responder preguntas concretas: cuánto tarda la entidad en detectar el problema, qué decisiones se bloquean, qué información falta, qué proveedor responde tarde, qué área no conoce su rol y qué cambios deben aplicarse. La resiliencia operativa mejora cuando las pruebas revelan fricciones reales y la organización las corrige.

Proveedores TIC: el punto crítico que muchas entidades subestiman

Uno de los cambios más relevantes de DORA está en la mirada sobre terceros. Muchas entidades financieras dependen de proveedores TIC para servicios cloud, comunicaciones, ciberseguridad, procesamiento de datos, software crítico o continuidad operativa. Esa dependencia puede ser eficiente, pero también introduce riesgos que no desaparecen por estar fuera de la organización.

El problema aparece cuando el proveedor se gestiona solo como una relación contractual. En resiliencia operativa, un tercero crítico no es solo un proveedor: es parte del sistema que permite operar. Si falla, se degrada, tarda en responder o concentra demasiada dependencia, el impacto puede llegar al cliente, al negocio y al supervisor.

Dependencia tecnológica y concentración de riesgos

La dependencia tecnológica no es negativa por sí misma. Muchas entidades necesitan proveedores especializados para operar con seguridad, escalar infraestructura o acceder a capacidades que no tendría sentido construir internamente. El riesgo aparece cuando la entidad no sabe con suficiente claridad qué servicios dependen de cada proveedor, qué alternativas existen y cuánto tardaría en recuperar la operación si ese tercero falla.

La concentración de riesgos es especialmente delicada. Si varios servicios críticos dependen del mismo proveedor, de la misma región cloud, del mismo integrador o de una misma cadena de subcontratación, la entidad puede tener una fragilidad mayor de la que muestran sus controles internos. La resiliencia operativa exige mirar la dependencia completa, no solo el contrato principal.

Por eso DORA obliga a revisar criticidad, continuidad, subcontratación, ubicación de datos, niveles de servicio, capacidad de auditoría y escenarios de salida. La pregunta clave no es si el proveedor cumple sobre el papel, sino si la entidad puede seguir operando cuando ese proveedor no responde como se esperaba.

Contratos, supervisión y capacidad de salida

Los contratos con proveedores TIC deben reflejar algo más que precios, servicios y responsabilidades generales. En un contexto DORA, deben permitir entender qué se presta, con qué nivel de criticidad, qué ocurre ante un incidente, cómo se comunica, qué derechos de acceso o auditoría existen y qué condiciones permiten terminar o sustituir el servicio.

La supervisión tampoco puede limitarse a una revisión inicial. Un proveedor puede ser adecuado en el momento de contratación y convertirse después en un riesgo por cambios técnicos, subcontratación, incidentes repetidos, pérdida de calidad o aumento de dependencia. Supervisar proveedores críticos significa observar su evolución, no archivarlos como “aprobados”.

La capacidad de salida es uno de los puntos que más separa cumplimiento de resiliencia. ¿Puede la entidad sustituir un servicio crítico sin afectar gravemente a clientes, operación o cumplimiento? Si la respuesta no está probada, la cláusula contractual sirve de poco. La entidad necesita escenarios realistas: qué datos habría que mover, qué equipos participarían, qué tiempos serían aceptables, qué alternativas existen y qué impacto tendría la transición.

Cómo preparar equipos y procesos para aplicar DORA con impacto real

Aplicar DORA con impacto real exige preparar a la organización, no solo actualizar documentación. La resiliencia operativa digital depende de procesos, responsabilidades, tecnología y proveedores, pero también de equipos capaces de actuar cuando un incidente afecta a servicios críticos.

Esto implica desarrollar capacidades internas. Los equipos deben entender qué exige la norma, cómo se conecta con su trabajo y qué decisiones deben tomar bajo presión. Para profundizar en ese marco, puede ser útil apoyarse en una formación específica como el curso sobre la Ley de Resiliencia Operativa Digital DORA, especialmente si tecnología, seguridad, compliance y negocio necesitan compartir lenguaje, criterios y responsabilidades.

Coordinación entre tecnología, seguridad, compliance y negocio

DORA no puede gestionarse desde un único departamento. Tecnología conoce sistemas, dependencias e infraestructura; seguridad entiende amenazas, controles e incidentes; compliance interpreta obligaciones regulatorias; negocio sabe qué servicios son críticos para clientes y operación. Si esas áreas no trabajan coordinadas, la entidad puede tener controles correctos y una respuesta fragmentada.

La coordinación empieza por definir responsabilidades antes del incidente. Quién clasifica el evento, quién activa el plan, quién contacta con proveedores, quién informa a dirección, quién comunica a negocio y quién documenta decisiones. En un escenario real, esas preguntas no pueden resolverse improvisando.

También conviene acordar criterios compartidos. No todas las interrupciones tienen el mismo impacto ni todas requieren el mismo nivel de escalado. La organización necesita saber qué eventos afectan a servicios críticos, qué umbrales activan comunicación interna, qué evidencias deben recogerse y qué decisiones requieren participación de dirección. La resiliencia depende tanto del proceso como de la coordinación entre áreas.

Formación, simulacros y cultura de ciberresiliencia

La formación en DORA no debería limitarse a explicar la norma. Debe ayudar a cada perfil a entender su papel: qué debe hacer, qué información necesita, cómo debe coordinarse y qué errores pueden aumentar el impacto de un incidente. Un equipo formado solo en teoría puede conocer las obligaciones y aun así fallar cuando la operación se degrada.

Los simulacros son clave porque convierten la resiliencia en práctica. Permiten comprobar si los contactos están actualizados, si los proveedores responden, si la información fluye, si los responsables conocen su rol y si la dirección recibe datos suficientes para decidir. Un simulacro útil no busca confirmar que todo está bien, sino encontrar fricciones antes de que aparezcan en un incidente real.

La cultura de ciberresiliencia aparece cuando la organización deja de ver DORA como una carga externa y empieza a integrarla en su forma de operar. Eso significa aprender de incidentes, revisar dependencias, actualizar planes, cuestionar supuestos y mantener conversaciones incómodas sobre riesgo. Cumplir la norma es necesario, pero sostener resiliencia exige práctica, criterio y mejora continua.

Conclusiones

DORA ya forma parte del presente operativo del sector financiero. Cumplir el reglamento es necesario, pero quedarse en políticas, evidencias y procedimientos puede generar una falsa sensación de preparación si la organización no sabe responder cuando un servicio crítico se interrumpe.

La resiliencia operativa digital exige convertir los requisitos de la norma en capacidades reales: gobierno del riesgo TIC, gestión coordinada de incidentes, pruebas útiles, continuidad operativa y control efectivo de proveedores. La diferencia se nota cuando los equipos tienen roles claros, criterios compartidos y capacidad para actuar bajo presión.

Para tecnología, seguridad, compliance, riesgo, negocio y dirección, el reto está en trabajar con una visión común. DORA no puede quedarse en un proyecto regulatorio aislado. Debe integrarse en la forma en que la entidad opera, decide, aprende de incidentes y reduce dependencias críticas. La resiliencia no se demuestra en el documento, sino en la respuesta real de la organización.