Deje de buscar software de cumplimiento DORA

Si dirige riesgos o cumplimiento en un banco, una aseguradora o una empresa de inversión, su bandeja de entrada tiene un tema nuevo este año. Cada proveedor de TIC, cada plataforma GRC, cada consultora le está vendiendo software de cumplimiento DORA. El argumento es siempre el mismo: el Reglamento de Resiliencia Operativa Digital está en vigor, el plazo ya pasó y usted necesita una herramienta para esto.

No necesita una herramienta para esto. Necesita gobernar la resiliencia operativa, y si ya lo hace bien, tiene la mayor parte de DORA resuelta. Aquí explicamos por qué el instinto de salir de compras es el equivocado, y qué mirar en su lugar antes de firmar nada.

DORA no creó un problema nuevo

El Reglamento de Resiliencia Operativa Digital se aplica a las entidades financieras de la UE desde el 17 de enero de 2025. Es un reglamento real con dientes reales, y no es vago: establece requisitos de gestión del riesgo de TIC, notificación de incidentes, pruebas de resiliencia, riesgo de terceros de TIC e intercambio de información. Veinte tipos de entidad financiera están en su ámbito, desde entidades de crédito hasta proveedores de servicios de criptoactivos, junto con los proveedores de TIC de los que dependen.¹

Lea los requisitos y fíjese en lo que falta: algo nuevo. La gestión del riesgo de TIC es gestión de riesgos. La notificación de incidentes es notificación de incidentes. La supervisión de terceros es el riesgo de proveedores que ya debería estar gestionando. Lo que hizo DORA fue tomar un conjunto de prácticas que las instituciones financieras maduras ya ejecutaban y hacerlas legalmente exigibles y coherentes en todo el bloque. La novedad es la exigibilidad, no la sustancia.

Esto importa porque cambia la pregunta. "Qué producto DORA deberíamos comprar" asume que DORA es una pieza discreta que se atornilla. No lo es. Es un suelo legal bajo disciplinas que o se ejecutan o no se ejecutan. Una entidad con un marco de resiliencia operativa que funciona, un registro vivo de sus dependencias de TIC y un proceso de incidentes que ya cumple plazos de notificación estrictos está casi en la meta. Una entidad que compra una herramienta DORA en 2026 suele ser una entidad que admite que no ejecutaba esas disciplinas, y que espera que el software tape el hueco.

El software no tapa un hueco de gobernanza. Hace el hueco auditable.

El registro de información es un síntoma, no la enfermedad

El pánico más buscado de DORA es el registro de información: el inventario estructurado de todos los acuerdos contractuales de servicios de TIC, con un esquema prescrito que los supervisores pueden recopilar. Es genuinamente laborioso. Tiene campos específicos, identificadores de entidad y un formato que los reguladores esperan recibir. Los proveedores han construido productos enteros alrededor de producirlo listo para presentar, y las entidades los están pagando.

Dé un paso atrás y pregunte por qué el registro es difícil. Es difícil porque la mayoría de las entidades no conocen su parque de terceros de TIC. Tienen contratos dispersos entre compras, seguridad y unidades de negocio. No saben qué proveedores sostienen funciones críticas o importantes. No pueden decir, bajo demanda, qué cuartas partes hay detrás de sus dependencias. El registro es difícil de producir porque el riesgo de terceros de TIC subyacente nunca se gestionó como un inventario vivo.

Un producto que genera el registro desde una hoja de cálculo que usted rellena una vez resuelve el artefacto e ignora la enfermedad. El año que viene el parque habrá derivado, los contratos habrán cambiado, un proveedor habrá sido adquirido, y usted estará rellenando la hoja otra vez. El registro de información no es un documento que producir. Es el resultado de conocer continuamente sus dependencias de TIC. Si gestiona ese parque como es debido, el registro es un informe que se ejecuta. Si no, ninguna herramienta le salva, porque la herramienta solo está tan al día como la última vez que alguien la actualizó a mano.

Cómo se ve una buena gestión del riesgo de TIC

Aquí viene la parte incómoda para quien espere comprarse la salida. Cada pilar de DORA se reduce a una práctica continua, no a un entregable puntual.

La gestión del riesgo de TIC no es un documento de políticas. Es un entorno de controles vivo con responsables, evidencia y ciclos de revisión. La notificación de incidentes no es una plantilla. Es un proceso de incidentes conectado con la precisión suficiente para clasificar un incidente grave y notificar a un supervisor dentro de la ventana de notificación, que para la notificación inicial se mide en horas, no en días. Las pruebas de resiliencia no son un pentest anual. Para las entidades que designe su supervisor incluyen pruebas de penetración basadas en amenazas en un ciclo plurianual, y para todas significan un programa de pruebas cuyos hallazgos vuelven a los controles. El riesgo de terceros de TIC no es un contrato firmado. Es supervisión continua de la concentración, las estrategias de salida y los proveedores concretos detrás de las funciones críticas.

Un marco de resiliencia operativa digno de ese nombre une todo esto. Mapea los servicios de negocio importantes, identifica las dependencias de TIC y de terceros bajo cada uno, fija tolerancias de impacto y demuestra con evidencia que la entidad puede mantenerse dentro de esas tolerancias cuando algo se rompe. Esa es la disciplina que DORA pone a prueba. Una lista de verificación que se marca en diciembre y se olvida en enero no es esa disciplina. Es teatro con pista de auditoría.

Las entidades que pasarán una revisión supervisora de DORA con comodidad no son las que tienen el mejor software DORA. Son aquellas para las que DORA es una capa de reporte sobre una gobernanza que ya venían ejecutando.

El Reino Unido ya jugó esta partida

Nada de esto es especulación, porque un experimento muy similar ya ocurrió al lado. Las normas de resiliencia operativa de la FCA y la PRA exigieron a las firmas financieras británicas identificar servicios de negocio importantes, fijar tolerancias de impacto y mapear sus dependencias, con la expectativa de mantenerse dentro de las tolerancias antes del 31 de marzo de 2025. La lógica coincide casi línea por línea con DORA; solo cambia el acento regulatorio.

Las firmas que trataron el régimen británico como un ejercicio de mapeo y tolerancias, hecho una vez y archivado, acabaron rehaciéndolo. Las firmas que lo trataron como un modelo operativo, donde el mapeo de dependencias y las pruebas son continuos, absorbieron DORA con mucho menos drama, porque el trabajo duro ya era institucional. La lección se transfiere directamente. Los reguladores de distintas jurisdicciones convergen en la misma expectativa: demostrar, de forma continua, que puede resistir una disrupción y recuperarse de ella. No convergen en la expectativa de que posea un software concreto.

Si está evaluando su postura frente a DORA, la comparación más útil no es con otras herramientas DORA. Es con cómo su firma manejó la resiliencia operativa de la FCA y la PRA. Los huecos riman.

La señal: está comprando una herramienta o construyendo una disciplina

Hay un diagnóstico simple para saber si está a punto de gastar bien el dinero. Pregunte qué hace el producto entre auditorías.

Una herramienta DORA que le ayuda a producir el registro, generar un paquete de políticas y exportar un lote de evidencia para el evaluador está optimizando para el momento de la inspección. Hace la auditoría más suave. No hace nada durante las otras cincuenta y una semanas del año, mientras el parque sigue cambiando. Una herramienta así trata el cumplimiento como un evento. Entre eventos queda ociosa, mientras la gobernanza se pudre en silencio bajo el informe limpio.

La alternativa es tratar DORA como un marco más sobre una capacidad de riesgo de TIC y gobernanza de terceros que se ejecuta de forma continua. En ese modelo los requisitos se mapean a controles, los controles llevan responsables y evidencia, el parque de terceros de TIC es un inventario mantenido en lugar de una reconstrucción anual, y el registro de información es una vista sobre ese inventario en lugar de un documento que se reconstruye. Cuando aterrice una nueva regulación, y otra aterrizará, la mapea sobre el mismo entorno de controles en lugar de comprar otra herramienta puntual.

Esa es la diferencia entre comprar software de cumplimiento DORA y construir resiliencia operativa. La disciplina sobrevive a la próxima regulación; la compra de la herramienta solo le prepara el siguiente ciclo de compras.

Dónde ayuda una plataforma, y dónde no

Para ser justos con la categoría, las herramientas no son el enemigo. El error es comprar una herramienta limitada a una sola regulación. Una plataforma de gobernanza se gana su lugar cuando hace lo contrario: mantiene un solo entorno de controles sobre el que se mapean muchos marcos, conserva un inventario vivo de proveedores y dependencias de TIC, y adjunta evidencia a los controles para que la pista de auditoría sea un subproducto del trabajo y no un simulacro de fin de año.

Este es el modelo sobre el que está construido VerifyWise. Gestiona marcos como requisitos mapeados a controles con evidencia y evaluaciones, mantiene un registro de proveedores y terceros como datos vivos, y ya gobierna el riesgo de modelos en servicios financieros bajo regímenes como SR 11-7 (ahora SR 26-2), SS1/23 y OSFI E-23. El parque de terceros de TIC que le importa a DORA es el mismo parque que rastrea un módulo de riesgo de proveedores. La evidencia continua que necesita un marco de resiliencia operativa es la misma evidencia que produce un entorno de controles.

Para ser claros sobre el alcance: DORA es una regulación que la arquitectura de VerifyWise está diseñada para gobernar, no una lista de verificación preconstruida que se activa. Cualquier proveedor que le diga que su software le hace cumplir DORA por defecto le está vendiendo un producto para el día de la auditoría en una caja más bonita.

La versión honesta del argumento es más pequeña y más útil que la del mercado. Ningún software le hace resiliente. El software hace la resiliencia medible, repetible y auditable, una vez que usted ejecuta la gobernanza. Si no la ejecuta, empiece por ahí, no por un portal de compras.

Si quiere ver cómo es gobernar esto de forma continua en lugar de buscar una herramienta de una sola regulación, hable con nosotros.

Antes de comprar, pregunte esto

DORA no es la última regulación de resiliencia operativa a la que se enfrentará. Es una de un conjunto convergente, y las que vengan después harán la misma pregunta central con palabras ligeramente distintas: puede demostrar, de forma continua, que entiende sus dependencias de TIC y que puede mantener los servicios críticos dentro de sus tolerancias cuando algo falla.

Así que antes de buscar software de cumplimiento DORA, pregunte si el problema es que le falta una herramienta o que le falta la disciplina sobre la que la herramienta debe informar. Si es la disciplina, un producto puntual no la arreglará, y el registro de información será igual de doloroso el año que viene. Si de verdad es la capa de reporte, entonces compre una plataforma que gobierne la disciplina de forma continua y trate DORA como un marco entre muchos, no una herramienta de una sola regulación que reemplazará en cuanto llegue el próximo acrónimo.

Las firmas que dejan de comprar y empiezan a gobernar son aquellas para las que la próxima regulación es un ejercicio de mapeo en lugar de un simulacro de incendio.

Footnotes

1. El artículo 2 del reglamento enumera 21 categorías con letra. La vigésimo primera son los proveedores terceros de servicios de TIC, que no son entidades financieras, por lo que el recuento de tipos de entidad financiera es veinte. Algunos resúmenes públicos citan veintiuno al contar juntos todos los puntos con letra. ↩