Lo más revelador del primer diseño de DORA: Bruselas ya sabía en 2020 que el problema era el proveedor, no solo el banco

Hay documentos que nacen para una reunión de trabajo y acaban explicando mejor una ley que muchos discursos solemnes posteriores. La presentación que la Comisión Europea llevó al primer grupo de trabajo del Consejo el 24 de septiembre de 2020 es uno de ellos. No porque descubra un giro desconocido —a estas alturas, en 2026, DORA ya está plenamente en vigor y las entidades conviven con sus obligaciones— sino porque enseña, sin maquillaje, qué preocupaba de verdad a Bruselas cuando el reglamento todavía era un proyecto: la fragmentación regulatoria, la debilidad en la notificación de incidentes y, sobre todo, la dependencia del sector financiero respecto de terceros tecnológicos capaces de concentrar riesgo sistémico.

Aquí está el quid. La presentación no vende una abstracción sobre “resiliencia digital”. Pone sobre la mesa una arquitectura regulatoria muy concreta: gobierno interno, gestión del riesgo ICT, notificación armonizada de incidentes, pruebas de resiliencia, intercambio voluntario de inteligencia y un marco de supervisión para terceros tecnológicos críticos. Si hoy muchas entidades siguen tratando DORA como una obligación documental más, este material demuestra que la lógica original del reglamento iba en sentido contrario: dejar de gestionar el riesgo operativo digital como un apéndice técnico y asumir que forma parte de la estabilidad financiera.

Y eso importa en 2026 por una razón bastante menos académica de lo que parece. El mercado ya ha comprobado que un fallo relevante en un proveedor cloud, un servicio de autenticación, una pasarela de pagos o una plataforma de mensajería crítica puede bloquear operaciones simultáneamente en varias entidades y varios Estados miembros. La Comisión lo intuyó pronto. Lo notable es que lo dejó escrito antes incluso de que DORA tomara su forma final.

Qué dice realmente esa presentación de 2020 y por qué sigue importando hoy

La fuente es una presentación de la Comisión Europea sobre la propuesta de reglamento de resiliencia operativa digital para el sector financiero, presentada el 24 de septiembre de 2020 en el primer Council Working Party. Es material preparatorio, no texto normativo definitivo. Conviene aclararlo porque una cosa es la intención política inicial y otra el articulado final que terminó aprobándose en el Reglamento (UE) 2022/2554. Pero precisamente por eso el documento tiene valor: permite ver qué problemas se querían corregir y qué soluciones se consideraban preferibles antes del compromiso legislativo.

La Comisión resumía el paquete de finanzas digitales con una tesis sencilla: todos los tipos de entidades financieras debían quedar sujetos a requisitos de resiliencia operativa para evitar reacciones en cadena entre sectores. Ese “todos” no era retórico. En la presentación se hablaba de 20 tipos de entidades financieras dentro del ámbito de aplicación del entonces artículo 2 de la propuesta. Ya en la fase embrionaria, DORA no se concebía como una norma para bancos tradicionales y poco más; se pensó desde el inicio como un marco transversal para banca, pagos, seguros, inversión y otros intermediarios regulados.

La consulta pública previa había recibido 99 respuestas. El dato no impresiona por volumen —Bruselas ha visto consultas mucho más concurridas—, pero sí por convergencia: la presentación señala un apoyo amplio a cuatro bloques básicos, que en realidad eran cinco si uno lee bien las diapositivas. Primero, un marco común de gestión del riesgo ICT. Segundo, notificación de incidentes con criterios, plantillas y mecanismos uniformes a una autoridad única. Tercero, intercambio voluntario de inteligencia de amenazas. Cuarto, pruebas periódicas de resiliencia. Quinto, gestión del riesgo de terceros con reglas de externalización y un marco de supervisión directa a nivel de la UE.

Es difícil no sonreír con cierta ironía: seis años después, muchas organizaciones siguen actuando como si estos pilares les hubieran caído del cielo en el último trimestre. No. La Comisión los enseñó con toda claridad en septiembre de 2020.

La verdadera obsesión de DORA no era el ciberincidente, sino la coherencia regulatoria

El gran error al leer DORA solo como normativa de ciberseguridad es que reduce su alcance. DORA es una norma de resiliencia operativa para el sistema financiero. El ciberincidente es una parte, visible y a veces espectacular, del problema. La raíz regulatoria era otra: la Comisión detectaba un mosaico de normas sectoriales, guías supervisoras y reglas nacionales que generaban coberturas desiguales según el tipo de entidad y según el Estado miembro.

La presentación lo expresa de forma implícita en el análisis de opciones. El escenario de “no hacer nada” mantenía el statu quo de las reglas financieras de la UE más la Directiva NIS entonces vigente. La opción 1 apostaba por algo casi quirúrgico, con colchones de capital y pruebas de estrés paneuropeas. La opción 2 —la preferida— combinaba reglas exhaustivas de la UE en servicios financieros con la NIS, pruebas armonizadas, reconocimiento mutuo y un marco de supervisión europeo para terceros. La opción 3 iba más lejos: sacar completamente al sector financiero de NIS y crear incluso una nueva autoridad de supervisión directa.

La elección de la opción 2 dice mucho. Bruselas quería armonización fuerte, pero no una revolución institucional innecesaria. Quería evitar la duplicidad total con NIS, pero no abrir una guerra de competencias creando una autoridad completamente nueva para sustituir a los supervisores financieros. En términos políticos fue una jugada bastante pragmática: reforzar a las Autoridades Europeas de Supervisión y construir un régimen propio para finanzas sin romper el ecosistema regulatorio europeo a martillazos.

Visto desde 2026, esa decisión ha resultado más sofisticada de lo que parecía. La convivencia entre DORA y NIS2 sigue obligando a mapear solapamientos, especialmente en grupos con actividades mixtas o infraestructuras críticas. Pero el planteamiento de base se mantiene: el sector financiero necesita un régimen más específico que el de la ciberseguridad horizontal generalista, porque el problema no es solo proteger sistemas, sino sostener servicios críticos bajo presión operativa real.

La diapositiva más importante era la de los terceros ICT

Si hay una idea que atraviesa toda la presentación y que en 2026 ya nadie puede fingir no entender, es esta: externalizar no externaliza la responsabilidad. El documento anticipaba un “EU direct oversight framework” para proveedores terceros de ICT críticos y, al mismo tiempo, un refuerzo de las reglas de outsourcing y de las herramientas supervisoras. Eso acabaría cristalizando en el núcleo de DORA sobre gestión del riesgo de terceros y en el régimen de supervisión de proveedores críticos.

La intuición de Bruselas era correcta y brutalmente actual. El riesgo tecnológico relevante en finanzas no se agota en el perímetro de la entidad. Vive en las cadenas de suministro digitales, en la concentración de determinados servicios cloud, en los integradores, en los proveedores de software esencial, en servicios de conectividad, autenticación, analítica o procesamiento. Un banco puede tener un SOC impecable y una política de parches presentable; si comparte dependencias críticas con medio mercado, el riesgo sistémico no desaparece. Solo se desplaza.

Eso explica por qué DORA dedica tanta energía a la gestión contractual, al registro de información de terceros, a la evaluación precontractual, a los derechos de acceso, auditoría e inspección y a la estrategia de salida. En el texto final del reglamento, el bloque de gestión del riesgo de terceros ICT arranca en el artículo 28. No es un apéndice. Es uno de los centros de gravedad de la norma.

Quien siga viendo esto como un ejercicio de “vendor management” algo más fino está leyendo la mitad del problema. DORA parte de una realidad incómoda: hay proveedores cuya interrupción no es un incidente de compras ni una incidencia tecnológica; es una amenaza de estabilidad operativa. Por eso la supervisión europea sobre determinados terceros críticos dejó de ser una idea exótica para convertirse en política regulatoria.

Gobierno interno: la Comisión ya apuntaba al consejo de administración

Otro aspecto que la presentación deja diáfano es la insistencia en la responsabilidad del órgano de dirección. La diapositiva sobre gobierno ICT, vinculada entonces al artículo 4 de la propuesta, habla de definición, aprobación, control y rendición de cuentas para implantar el marco de gestión del riesgo ICT. Añade algo que algunas entidades todavía intentaron tratar como una novedad de última hora: la “full responsibility and accountability of the management body”. Plena responsabilidad y rendición de cuentas del órgano de dirección.

No hay mucho margen para el autoengaño. Desde la fase inicial del proyecto, DORA se diseñó para sacar el riesgo ICT del sótano técnico y llevarlo a la sala del consejo. No como invitado decorativo, sino como asunto de gobierno corporativo. Eso encaja con la redacción final del artículo 5 de DORA, que hace responsable al órgano de dirección de definir, aprobar, supervisar y asumir la responsabilidad de la aplicación del marco de gestión del riesgo relacionado con las TIC. También exige que dedique tiempo suficiente, apruebe políticas de resiliencia, supervise la estrategia de continuidad y reciba formación suficiente.

La implicación práctica en 2026 ya no es teórica. Si una entidad no puede demostrar que su consejo entiende dependencias críticas, escenarios de interrupción, tolerancias al riesgo ICT, resultados de pruebas de resiliencia y exposición a terceros, no tiene un problema de estilo documental. Tiene un problema de gobierno. Y eso, frente al supervisor, suele ser bastante más feo que un control técnico mal configurado, porque indica falta de control estructural.

Hay una segunda derivada menos comentada. Cuando el órgano de dirección asume responsabilidad explícita, cambian también las expectativas sobre la calidad del reporting interno. Si el comité recibe cuadros de mando cosméticos, con semáforos tranquilizadores y sin traducción al impacto en servicios críticos, la entidad está saboteando su propia defensa. DORA no exige literatura de PowerPoint. Exige capacidad de decisión informada.

La gestión del riesgo ICT no nació para IT: nació para funciones críticas

La presentación desglosa el entonces bloque de requisitos de gestión del riesgo ICT en una secuencia reconocible: identificar, proteger y prevenir, detectar, responder y recuperar, aprender y evolucionar, y comunicar. Esa lógica se parece a marcos maduros de ciberseguridad y resiliencia, incluido el NIST CSF, pero con un enfoque más regulatorio y operacional para entidades financieras.

La parte más instructiva está en la diapositiva de “Identify”, asociada al artículo 7 de la propuesta. La Comisión no se limita a pedir inventarios de sistemas. Enumera funciones de negocio, activos de información de soporte, configuraciones de sistemas ICT, interconexiones con sistemas internos y externos, fuentes de riesgo ICT, cuentas de todos los sistemas, recursos de red y hardware, equipos físicos críticos y procesos dependientes de proveedores terceros. Es una lista muy reveladora porque demuestra que el objetivo no era construir un CMDB bonito para auditoría. Era entender cómo fluye el servicio financiero real a través de tecnología, personas y dependencias externas.

Ese punto sigue siendo uno de los más difíciles en la práctica. Muchas entidades tienen inventarios razonables de infraestructura y, al mismo tiempo, una visibilidad mediocre sobre procesos de negocio críticos, dependencias lógicas entre aplicaciones, cuentas privilegiadas heredadas o flujos de datos con terceros. DORA aprieta precisamente ahí: obliga a unir el mapa tecnológico con el mapa operativo.

La presentación también incluía, desde el origen, un régimen de proporcionalidad para microempresas. Por ejemplo, indicaba que no tendrían que realizar evaluación de riesgo tras cambios importantes en la infraestructura de red y sistemas de información, ni una evaluación específica de todos los sistemas legacy. Ese detalle es interesante por dos razones. Primero, confirma que DORA nunca fue un ejercicio ciego de “one size fits all”. Segundo, aclara que la proporcionalidad no equivale a barra libre. Incluso bajo un régimen más ligero, la obligación de controlar el riesgo no desaparece; se adapta.

Notificación de incidentes: la Comisión detectó pronto el caos de los formularios

Uno de los mejores aciertos del diseño inicial de DORA fue identificar que la notificación de incidentes estaba rota por fragmentación. La presentación proponía reforzar y extender el reporte de incidentes relacionados con ICT, con plantillas comunes, plazos comunes y una sola autoridad competente receptora. Dicho sin rodeos: Bruselas vio que pedir a entidades transfronterizas que informaran de un mismo incidente con lógicas diferentes según el sector o el país era una receta regulatoria bastante absurda.

La lógica final de DORA consolidó esta prioridad. El reglamento, en sus artículos 17 a 23, crea el marco de clasificación y notificación de incidentes graves relacionados con las TIC, complementado posteriormente por normas técnicas. La filosofía es clara: criterios homogéneos, umbrales, ventanas temporales y una secuencia de informes iniciales, intermedios y finales que permitan al supervisor entender tanto el impacto como la respuesta.

La gran cuestión para 2026 no es si hay que notificar. Eso ya está descontado. La cuestión es si las entidades han conectado de verdad tres mundos que suelen vivir separados: operaciones de seguridad, gestión de incidentes empresariales y reporting regulatorio. Cuando no están integrados, aparecen los clásicos problemas: incidentes clasificados tarde, métricas inconsistentes, falta de trazabilidad sobre servicios afectados, contradicciones entre la comunicación al supervisor y la que recibe el consejo, o una ausencia total de criterio para decidir cuándo un incidente tecnológico se convierte en incidente DORA.

La presentación de 2020 ya apuntaba una pista que hoy conviene recuperar: el objetivo no era solo reportar mejor, sino reportar de forma útil y comparable. Si la notificación acaba siendo un ritual formalista, la armonización habrá producido más papeles y poca inteligencia supervisora. La calidad del dato importa tanto como el plazo.

Pruebas de resiliencia: el regulador quería algo más que pentests de escaparate

Otra línea de la propuesta inicial que ha envejecido bastante bien es la relativa a las pruebas. La Comisión distinguía entre pruebas básicas para todas las entidades y pruebas avanzadas para entidades significativas, con reconocimiento de resultados por autoridades competentes de distintos Estados miembros. Esa idea anticipa el actual enfoque de DORA sobre pruebas de resiliencia operativa digital, incluyendo marcos más exigentes para determinadas entidades y, en el caso de las pruebas avanzadas basadas en amenazas, una lógica cercana al threat-led penetration testing.

Lo interesante no es solo la obligación de probar, sino qué se intenta probar. DORA no nació para multiplicar tests técnicos desconectados de la prestación del servicio. Nació para verificar si la entidad puede seguir operando, responder y recuperarse frente a perturbaciones plausibles. Eso desplaza el énfasis desde el hallazgo puntual de vulnerabilidades hacia la resistencia del servicio crítico.

En 2026, muchas organizaciones ya han descubierto algo poco glamuroso: las pruebas avanzadas son duras no tanto por la técnica, sino por la coordinación interna. Hace falta cerrar el perímetro, definir funciones críticas, alinear equipos de seguridad, continuidad, riesgo, arquitectura, legal, proveedores y negocio, y decidir por adelantado cómo se gestionarán hallazgos que afectan a terceros. La parte complicada no es contratar un ejercicio; es tener una organización capaz de absorberlo sin entrar en negación.

La Comisión, en 2020, ya hablaba de compartir y reconocer resultados entre autoridades competentes. La intención era reducir duplicidades y facilitar un mercado financiero más integrado. Si eso se aplica bien, evita que una entidad multinacional tenga que demostrar cinco veces lo mismo a cinco supervisores distintos. Si se aplica mal, solo añade capas de coordinación burocrática. El potencial estaba ahí desde el principio. La ejecución, como siempre en Europa, depende de la letra pequeña y de la disciplina supervisora.

DORA y NIS: la tensión que ya aparecía antes de NIS2

Una frase de la consulta pública recogida en la presentación merece atención especial: había que explicar bien y abordar la interacción con la Directiva NIS. No era un detalle de redacción. Era un problema de frontera regulatoria. En 2020 todavía estaba vigente la NIS original, la Directiva (UE) 2016/1148. Hoy, en 2026, el paisaje ha cambiado con NIS2, la Directiva (UE) 2022/2555, que elevó exigencias de gestión de riesgos, gobernanza y notificación de incidentes para entidades esenciales e importantes.

La preocupación inicial de la Comisión resultó profética. DORA y NIS2 comparten ADN en materias como gestión del riesgo, responsabilidad de la alta dirección y notificación de incidentes, pero no persiguen exactamente lo mismo ni se aplican del mismo modo. DORA es lex specialis para gran parte del sector financiero regulado por la UE. NIS2 tiene un alcance horizontal más amplio y opera a través de transposición nacional. Esa combinación genera preguntas muy prácticas: qué régimen prevalece para una entidad financiera concreta, cómo se coordinan notificaciones si un grupo tiene filiales dentro y fuera de DORA, o qué ocurre con proveedores críticos que están simultáneamente bajo expectativas NIS2 y bajo la cadena de obligaciones DORA de sus clientes financieros.

La respuesta corta es que no conviene esperar a que un supervisor resuelva por arte de magia la arquitectura interna de cumplimiento. Las entidades tienen que mapear obligaciones por entidad jurídica, servicio crítico y cadena de suministro. No basta con decir “somos DORA” o “somos NIS2”. En grupos diversificados, ambas cosas pueden ser ciertas a la vez, pero para sujetos diferentes o para procesos distintos.

La ironía es evidente: Europa lleva años prometiendo simplificación y luego obliga a construir matrices de aplicabilidad cada vez más sofisticadas. En este caso, al menos, la complejidad responde a un problema real.

Lo que el documento anticipó mejor que muchos análisis posteriores

Hay tres intuiciones de la presentación de 2020 que hoy merecen ser reconocidas porque dieron en el blanco.

La primera: la resiliencia digital es un problema intersectorial dentro de finanzas. La Comisión no planteó desde el inicio una norma limitada a banca sistémica. Apostó por un marco común para múltiples tipos de entidades, con ajustes de proporcionalidad. Esa decisión importó porque buena parte del riesgo operativo digital circula precisamente entre sectores: pagos, custodia, gestión de activos, seguros, intermediación, infraestructuras y servicios auxiliares.

La segunda: el consejo de administración tenía que quedar enganchado jurídicamente al problema. Sin esa palanca, muchas obligaciones habrían terminado aparcadas en el departamento de seguridad o cumplimiento tecnológico. DORA cambió la conversación al convertir el riesgo ICT en cuestión de gobierno corporativo.

La tercera, y probablemente la más decisiva: el mayor agujero regulatorio estaba en los terceros ICT críticos. No por ausencia absoluta de reglas —ya existían marcos de outsourcing, directrices de las ESAs y expectativas supervisoras—, sino porque faltaba una visión europea coherente sobre concentración de dependencias, auditabilidad real y supervisión del proveedor como actor con impacto sistémico.

Si alguien busca la frase más actual de todo el documento, probablemente esté en la idea de evitar una reacción dominó. No era hipérbole. Era diagnóstico.

Lo que la presentación no resolvía —y que en 2026 sigue dando trabajo

También conviene evitar la tentación de convertir este material en profecía perfecta. La presentación señalaba la dirección política, pero no resolvía varios problemas que la práctica regulatoria ha tenido que gestionar después.

Uno de ellos es la definición operativa de “significativo” para algunas obligaciones más intensas, especialmente en pruebas avanzadas. Otro es la coordinación entre autoridades nacionales y europeas cuando hay incidentes transfronterizos que afectan a varias entidades por una dependencia común. Un tercero, nada menor, es la ejecución real de derechos contractuales frente a proveedores dominantes. Sobre el papel, auditar, acceder, inspeccionar y disponer de planes de salida suena impecable. En la negociación comercial con determinados grandes proveedores, la partitura cambia bastante.

El documento tampoco entraba en un dilema que hoy es central: la tensión entre resiliencia y complejidad. Cuantas más capas de control, más dependencias de herramientas, integradores, MSSP, telemetría y automatización acumula la entidad. Eso mejora visibilidad y respuesta, sí, pero también multiplica puntos de fallo y cadenas de suministro. DORA no causa ese problema; lo hace visible. Y obliga a gestionarlo con una disciplina que muchas organizaciones todavía no tenían interiorizada.

Hay además una cuestión cultural. El reglamento presupone que las entidades conocen sus servicios críticos, sus interdependencias y sus tolerancias. En la realidad, algunas empezaron la carrera de cumplimiento sin una taxonomía interna madura de funciones críticas ni una cartografía fiable de activos y terceros. No era un defecto de DORA. Era la foto del mercado.

Implicaciones para entidades financieras españolas en 2026

Para entidades financieras españolas, la lectura de esta presentación tiene un valor muy concreto: recuerda que DORA no debe implantarse como proyecto aislado de cumplimiento, sino como mecanismo de gobierno sobre operaciones críticas, incidentes y terceros. En España, donde conviven grandes grupos transfronterizos, aseguradoras, entidades de pago, fintech reguladas y una red densa de proveedores tecnológicos, el foco en concentración y subcontratación no es teórico.

Si tu entidad opera en España y además presta servicios en varios Estados miembros, hay cuatro implicaciones bastante directas.

La primera es de gobierno. El consejo y las comisiones delegadas tienen que recibir reporting que enlace riesgo ICT con impacto en servicios regulados. No basta con un listado de vulnerabilidades o con indicadores de disponibilidad genéricos. Hace falta una narrativa ejecutiva basada en funciones críticas, tiempos de recuperación, dependencias de terceros y resultados de pruebas.

La segunda es de inventario y trazabilidad. Las exigencias que la Comisión ya adelantaba en 2020 y que el texto final consolidó obligan a poder responder preguntas simples que a veces no tienen respuesta simple: qué procesos dependen de qué proveedor, qué activos soportan cada servicio crítico, qué cuentas privilegiadas intervienen, qué datos se procesan y dónde están los puntos de fallo únicos.

La tercera es contractual. Muchos programas DORA en España han descubierto que el mayor retraso no estaba en redactar políticas, sino en renegociar anexos con proveedores, recabar información de subencargados, asegurar derechos de auditoría utilizables y ordenar estrategias de salida creíbles. La normativa no te pide fantasías heroicas; te pide capacidad de control demostrable.

La cuarta es de coordinación regulatoria. Entidades financieras españolas con filiales tecnológicas, aseguradoras, proveedores internos de grupo o negocios fuera del núcleo financiero han tenido que alinear DORA con GDPR —piénsese en las obligaciones de notificación de violaciones de seguridad del artículo 33 del RGPD—, con NIS2 cuando procede, y con expectativas nacionales supervisoras. El reto no es acumular marcos, sino evitar contradicciones entre ellos.

Qué debería revisar ahora cualquier entidad que crea tener DORA “ya resuelto”

Si algo enseña este documento es que la resiliencia no se demuestra por el número de políticas aprobadas, sino por la calidad de cuatro engranajes.

El primero es la identificación de funciones críticas y servicios importantes, con sus activos, datos, interdependencias y terceros. Si esa base está mal, todo lo demás —clasificación de incidentes, pruebas, continuidad y reporting— se degrada.

El segundo es la gobernanza real. ¿El órgano de dirección entiende el mapa de dependencias y toma decisiones sobre tolerancia al riesgo ICT, inversión, continuidad y terceros, o solo ratifica papeles? La respuesta importa más de lo que muchas organizaciones quisieran.

El tercero es el mecanismo de incidentes. ¿Existe un flujo claro desde detección técnica hasta clasificación regulatoria, escalado ejecutivo, notificación y lecciones aprendidas? Si seguridad, continuidad, cumplimiento y negocio siguen operando por carriles separados, el incidente serio los unirá de la peor manera posible.

El cuarto es la disciplina sobre terceros. No hablo solo de due diligence inicial. Hablo de inventario vivo, clasificación por criticidad, cláusulas utilizables, métricas de servicio relevantes para resiliencia, pruebas conjuntas cuando proceda y escenarios de salida que no sean puro teatro de procurement.

Quien tenga esos cuatro engranajes razonablemente maduros está cerca de la lógica original de DORA. Quien no, probablemente tiene un expediente bonito y una exposición operativa más fea de lo que parece.

La lección política de fondo: DORA se diseñó para la concentración tecnológica europea

La lectura más útil de esta presentación, seis años después, no es histórica. Es estratégica. DORA no se pensó solo para mejorar la higiene cibernética de las entidades financieras. Se diseñó para responder a una transformación del mercado: servicios financieros cada vez más digitales, dependientes de terceros, conectados entre sí y expuestos a efectos de contagio operacional.

Por eso la Comisión encuadraba la propuesta dentro de una estrategia de finanzas digitales para Europa, con referencias al mercado único digital, la innovación, el espacio europeo de datos financieros y la autonomía estratégica abierta. Sonaba ambicioso, sí. A ratos incluso un poco grandilocuente. Pero debajo había una constatación muy práctica: si Europa quería más digitalización financiera, también necesitaba una forma más seria de gobernar el fallo tecnológico.

Eso explica por qué la presentación no trataba el riesgo ICT como un asunto periférico de seguridad informática. Lo trataba como un componente de estabilidad, integración de mercado y supervisión transfronteriza. Ahí estaba la novedad de verdad.

En 2026, cuando DORA ya forma parte del paisaje y empieza la fase menos vistosa —la de demostrar madurez sostenida ante supervisores, auditoría interna y realidad operativa—, volver a este documento tiene utilidad. Recuerda la intención original del legislador antes de que el cumplimiento se convierta en rutina. Y la intención era bastante menos burocrática de lo que algunos han querido creer.

La Comisión, en septiembre de 2020, dejó caer un mensaje que hoy sigue incómodamente vigente: el riesgo digital de una entidad financiera no termina en su firewall ni en su SOC. Termina, si acaso, donde termina su capacidad real de seguir prestando servicios críticos cuando el proveedor falla, el incidente escala y el mercado mira.

Lo demás son diapositivas. Y ya hemos tenido suficientes.