Lo que realmente dice Michael Barr sobre desregular en plena bonanza: la Fed reabre una pelea que Europa conoce demasiado bien

Hay una mala costumbre en compliance: tratar la gobernanza como la tapa bonita del expediente. Se aprueba una policy, se presenta un dashboard al consejo, se anota en acta que el riesgo se ha revisado y todos a casa. Luego llega una crisis —un incidente grave, una dependencia tecnológica que nadie había querido discutir, una cadena de externalización imposible de mapear— y aparece la pregunta que de verdad importa: ¿quién estaba decidiendo, con qué información y con qué capacidad real para cambiar el rumbo?

La respuesta regulatoria en Europa es bastante menos decorativa de lo que a muchas entidades les gustaría. DORA no convierte al órgano de dirección en espectador ilustrado del riesgo tecnológico. Lo coloca en el centro de la responsabilidad sobre la resiliencia operativa digital y lo hace de forma expresa en sus disposiciones sobre gobernanza y gestión del riesgo de las TIC. La idea material está clara aunque convenga no jugar a la ruleta con una cita milimétrica si no se tiene el texto delante: la responsabilidad última no desaparece porque una función de segunda línea redacte mejor o porque un proveedor cloud prometa alta disponibilidad.

Eso cambia la conversación. Y debería cambiarla mucho más de lo que la está cambiando.

El problema no es saber que existe el riesgo. Es quién manda cuando asumirlo deja de ser cómodo

Casi todas las entidades reguladas tienen hoy un vocabulario impecable sobre ciberresiliencia, terceros críticos, tolerancias al impacto e incidentes graves. El léxico está resuelto. Lo que sigue fallando, con una persistencia casi conmovedora, es la traducción de ese vocabulario en decisiones incómodas: cortar una dependencia rentable, frenar una migración mal secuenciada, aumentar presupuesto donde no hay glamour, o exigir al negocio que asuma un control que ralentiza ventas.

Ahí es donde la gobernanza deja de ser una foto y se convierte en un mecanismo. DORA estructura precisamente ese paso. Sus capítulos sobre gestión del riesgo relacionado con las TIC, gobernanza y tratamiento de incidentes no se limitan a pedir documentación; exigen un marco interno con funciones, responsabilidades, capacidad de supervisión y procesos de respuesta. La norma no parte de una fantasía tecnocrática. Parte de algo mucho más sobrio: si una entidad depende de sistemas digitales para prestar servicios financieros, entonces el riesgo tecnológico es riesgo de negocio, riesgo operativo, riesgo de continuidad y, en algunos casos, riesgo prudencial. Separarlo en compartimentos sirve para ordenar el organigrama, no para gestionar la realidad.

Esa es la primera corrección que muchas organizaciones todavía no han interiorizado. No basta con tener un CISO solvente, un comité de riesgos diligente y un proveedor que enseñe certificaciones. Si el órgano de dirección no entiende cuáles son las dependencias críticas, qué funciones soportan, qué nivel de interrupción es tolerable y qué decisiones están abiertas cuando una prueba sale mal, la gobernanza existe en PowerPoint, no en la entidad.

DORA no pide omnisciencia al consejo. Pide implicación demostrable

Conviene despejar un malentendido. La obligación de gobernanza en DORA no significa que los consejeros deban convertirse en arquitectos cloud ni en analistas de malware. Significa algo más exigente y, de hecho, más incómodo: deben poder dirigir y supervisar un marco de gestión del riesgo de TIC con criterio suficiente para cuestionar, priorizar y decidir.

La arquitectura jurídica de DORA va en esa dirección en varios frentes. Las disposiciones del reglamento sobre el marco de gestión del riesgo relacionado con las TIC exigen estrategias, políticas, procedimientos, mecanismos de detección, respuesta, continuidad, recuperación y revisión. Las reglas sobre gobernanza atribuyen al órgano de dirección la responsabilidad de aprobar, supervisar y mantener ese marco. Y el bloque de incidentes obliga a establecer procesos para gestionar, clasificar y notificar incidentes graves. La combinación importa más que el número exacto del artículo citado en una diapositiva: no estamos ante una recomendación vaga, sino ante un sistema normativo que conecta mando, control y rendición de cuentas.

Traducido al terreno práctico: el consejo no necesita saber configurar un SIEM, pero sí debe saber si la entidad detecta tarde, si depende en exceso de un proveedor, si los escenarios de recuperación son creíbles y si las excepciones de control se están acumulando como platos sin fregar. La diferencia parece semántica. No lo es. Una cosa es recibir información. Otra, muy distinta, es gobernar con ella.

Tu entidad ya tiene eso resuelto. ¿Seguro? Haz una prueba sencilla. Pregunta qué tres servicios financieros se verían afectados si cae el proveedor TIC más relevante durante varias horas. Pregunta quién autorizaría el plan alternativo. Pregunta cuánto tiempo tardaría en reanudarse la operación dentro de los niveles tolerables definidos por la propia entidad. Si la respuesta llega en forma de silencio elegante o de promesa de “te lo mandamos”, la gobernanza todavía no ha aterrizado.

La obsesión con el reporte confunde actividad con control

Uno de los vicios más extendidos en el sector es confundir el volumen de reporting con la calidad de la gestión. Se elevan métricas, se colorean mapas de calor, se encadenan comités. Todo eso puede ser útil. También puede ser una maquinaria perfectamente engrasada para no decidir nada.

Por eso la conversación interesante no es cuántos indicadores suben al consejo, sino cuáles provocan una reacción verificable. Si aumentan las excepciones de parcheado en activos críticos, ¿se retrasa el lanzamiento comercial que depende de ellos? Si un test de continuidad revela que los RTO reales no se parecen a los aprobados, ¿se reasigna presupuesto o se reabre el apetito de riesgo? Si la concentración en un tercero crece más deprisa que la capacidad contractual y técnica de control, ¿se detiene la expansión o se acepta el riesgo con nombre y apellidos? Ahí vive la gobernanza real.

Esta lógica encaja además con otras piezas regulatorias. NIS2, por ejemplo, en su artículo 20, introduce obligaciones de aprobación y supervisión de las medidas de gestión del riesgo de ciberseguridad por parte de los órganos de dirección de las entidades esenciales e importantes, y exige formación suficiente para evaluar esas prácticas. El artículo 21, a su vez, detalla las medidas mínimas de gestión del riesgo. No es casualidad. Europa está empujando un mismo mensaje con varias herramientas: la ciberseguridad deja de ser asunto exclusivo de especialistas y pasa a ser materia de gobierno corporativo.

GDPR hizo algo parecido, aunque con otro objeto, al obligar a notificar violaciones de seguridad de los datos personales a la autoridad de control sin dilación indebida y, cuando sea posible, en 72 horas desde que se tenga constancia, según su artículo 33. La norma de protección de datos no convierte al consejo en operador de incidentes, pero sí fuerza a la organización a tener líneas de escalado, criterio de gravedad y capacidad para decidir rápido. De nuevo, el patrón es el mismo: cuando el impacto puede afectar a clientes, operaciones o derechos, la improvisación deja de ser una opción regulatoriamente sostenible.

El punto ciego no es técnico. Es organizativo

Hay una tentación recurrente en entidades maduras: pensar que su principal brecha está en la herramienta que falta. A veces es verdad. Muchas veces no. El punto ciego más peligroso suele estar en la organización. Concretamente, en la distancia entre quien ve el riesgo y quien puede alterar la decisión que lo genera.

Un equipo de seguridad puede detectar una dependencia excesiva de un proveedor SaaS para una función crítica. Puede documentarla con precisión quirúrgica. Puede incluso advertir que la salida contractual es limitada y que la reversibilidad operativa no está probada. Si esa información no llega al nivel donde se decide seguir escalando el servicio —o llega como una nota de color, no como una condición de negocio—, el problema no es de ciberseguridad. Es de gobernanza.

DORA intenta cerrar precisamente ese hueco cuando regula la gestión del riesgo de terceros TIC y exige a las entidades mantener un registro de los acuerdos contractuales relativos al uso de servicios TIC prestados por terceros, dentro del marco establecido en su capítulo V sobre riesgo de terceros. No es burocracia ornamental. Es una forma de obligar a la organización a conocer su propia anatomía digital. Porque no se puede gobernar una dependencia que no se ha identificado bien, y no se puede reducir una concentración que nadie ha querido medir en serio.

La ironía aquí es evidente: muchas entidades tienen mapas exhaustivos para capital, liquidez o conducta, pero todavía no pueden explicar con la misma claridad qué proveedor soporta qué proceso crítico, bajo qué subcontrataciones y con qué alternativa real de salida. Luego llamamos “riesgo emergente” a lo que en realidad es falta de inventario con buena prensa.

Incidentes: la norma no te pregunta si sufriste uno, sino cómo supiste lo que estaba pasando

Otra zona donde se ve la diferencia entre cumplimiento cosmético y resiliencia material es la gestión de incidentes. DORA dedica un bloque específico a la gestión, clasificación y notificación de incidentes relacionados con las TIC y a las ciberamenazas significativas. El mensaje regulatorio no se agota en “notifique usted”. Antes de notificar hay que detectar, clasificar, escalar y entender impacto, duración, alcance y criticidad.

Eso tiene consecuencias operativas muy concretas. Si una entidad no puede distinguir con rapidez entre una incidencia técnica molesta y un incidente grave, su problema no es solo de reporting regulatorio; es de control interno. Si el equipo legal entra tarde porque nadie elevó la posible afectación a datos personales, aparece GDPR art. 33. Si el negocio minimiza una interrupción que compromete funciones críticas, la entidad puede degradar su respuesta antes incluso de valorar si existe deber de notificación sectorial. Y si varias funciones discuten durante horas quién “posee” el incidente, el atacante ya ha ganado tiempo gratis.

Por eso los procedimientos de clasificación importan tanto como la tecnología de detección. La madurez se mide menos por la elegancia del playbook y más por la velocidad con la que la organización responde a preguntas básicas: qué se ha visto, qué servicio afecta, desde cuándo, con qué impacto potencial y quién decide la siguiente acción. Parece elemental. No siempre lo es.

También aquí conviene resistir la tentación del fetichismo documental. Un runbook impecable no sirve de mucho si el primer directivo que debe autorizar una medida disruptiva no entiende el umbral para activarla. La resiliencia no falla solo por ausencia de controles. Falla porque alguien con autoridad suficiente no estaba preparado para elegir entre dos males caros en una ventana de tiempo muy corta.

El espejismo de la fortaleza formal

En supervisión financiera existe una lección vieja, aunque a menudo reaparece con ropa nueva: una organización puede proyectar solidez formal y, aun así, deteriorarse con rapidez cuando coinciden malas decisiones de gestión, concentraciones mal entendidas y una gobernanza incapaz de reaccionar a tiempo. No hace falta atribuir esa tesis a una frase exacta de un discurso concreto para reconocer su validez. La historia regulatoria reciente está llena de episodios donde el problema no era la ausencia total de métricas, sino la incapacidad de leerlas a tiempo y actuar en consecuencia.

La analogía con la resiliencia operativa digital es incómoda pero útil. Una entidad puede tener políticas aprobadas, pruebas planificadas, inventarios razonables y una función de riesgo técnicamente solvente. Puede incluso parecer madura en una revisión documental. Y, sin embargo, seguir siendo frágil si combina tres cosas: dependencia concentrada, información fragmentada y un órgano de dirección que recibe el riesgo como dato, no como dilema que exige decisión.

Ahí está una de las trampas más peligrosas del momento regulatorio actual. Como el lenguaje de la resiliencia se ha sofisticado mucho, algunas entidades parecen más avanzadas de lo que realmente están. Hablan de tolerancias al impacto, de escenarios severos pero plausibles, de supervisión de terceros críticos. Todo correcto. La pregunta que pincha el globo es otra: ¿qué decisión cambió el último hallazgo relevante? Si la respuesta es “estamos trabajando en ello”, quizá no había tanta madurez; había buena narrativa.

Qué exige de verdad un órgano de dirección bajo DORA

Conviene bajar esto a tareas concretas, porque la vaguedad es el refugio natural de la mala gobernanza. Si uno lee DORA junto con NIS2 y las prácticas supervisoras más serias, emerge un patrón bastante nítido de expectativas sobre el órgano de dirección.

Primero, debe aprobar el marco de gestión del riesgo de TIC y revisarlo periódicamente. No como rito anual, sino a la luz de cambios de arquitectura, dependencia de terceros, incidentes relevantes y resultados de pruebas. Segundo, debe asegurarse de que existen funciones con responsabilidades claras, recursos suficientes y capacidad de escalado real. Tercero, debe entender las dependencias críticas: no a nivel de diagrama ornamental, sino con criterio suficiente para preguntar por concentración, subcontratación, reversibilidad y puntos únicos de fallo. Cuarto, debe recibir información que permita decidir, no solo tomar nota. Quinto, debe poder demostrar que sus decisiones y supervisión tienen trazabilidad.

La palabra clave es demostrar. En compliance, lo que no deja huella suele terminar tratado como si no hubiera ocurrido. Actas, packs de consejo, decisiones condicionadas, escalados, reaperturas de apetito, mandatos al negocio, seguimiento de acciones correctoras: todo eso forma parte de la evidencia de gobernanza. No por fetichismo registral, sino porque la supervisión examina lo que la entidad hizo, no lo que dice que habría hecho en un escenario ideal.

Hay además un elemento que suele infravalorarse: la formación. NIS2 art. 20 lo menciona expresamente para los órganos de dirección. DORA, sin necesitar convertir la formación en eslogan, presupone un nivel de entendimiento suficiente para ejercer la responsabilidad atribuida. Traducido: no basta con sentar al consejo frente a una presentación trimestral plagada de acrónimos. Si quienes deben gobernar no entienden las implicaciones básicas de disponibilidad, integridad, dependencia de terceros o recuperación, la supervisión puede acabar viendo una estructura formalmente correcta pero materialmente hueca.

La gran coartada: “eso ya lo lleva la segunda línea”

Pocas frases resumen mejor la resistencia interna a este cambio que esa: “eso ya lo lleva la segunda línea”. Sí, la segunda línea diseña marcos, cuestiona, agrega riesgo y escala. No gobierna sola la entidad. Tampoco absorbe la responsabilidad última porque el resto prefiera mirar desde lejos.

En muchas organizaciones, esa coartada ha funcionado durante años porque permitía un reparto muy cómodo del trabajo: riesgo y seguridad producían material; negocio y dirección lo “veían”. El problema es que DORA endurece el estándar de lo que significa ver. Supervisar no es recibir. Aprobar no es bendecir sin discusión. Responsabilizarse no es aparecer en la primera página de la policy.

La prueba de fuego llega cuando existe tensión entre objetivos. Si el negocio quiere acelerar una implantación, si tecnología advierte de deuda técnica, si seguridad plantea controles adicionales y si compras empuja por eficiencia contractual, alguien tiene que arbitrar. Ese alguien no puede esconderse indefinidamente detrás de un comité técnico. La gobernanza madura se reconoce porque las tensiones afloran arriba con suficiente nitidez como para permitir una decisión consciente. La inmadura, porque todo parece alineado hasta que algo se rompe.

Terceros TIC: donde casi todas las buenas intenciones se estrellan con la realidad

Si hay un terreno en el que DORA va a separar a las entidades que se conocen de las que se cuentan cuentos, es el de terceros TIC. El reglamento dedica su capítulo V a la gestión del riesgo de terceros TIC y, dentro de ese bloque, obliga a mantener información estructurada sobre los acuerdos contractuales, a integrar ese riesgo en el marco general y a vigilar la concentración.

La dificultad no es teórica. Es brutalmente práctica. Muchas entidades han crecido mediante capas sucesivas de externalización, SaaS, integradores, servicios gestionados y subcontrataciones en cascada. El resultado es una dependencia tecnológica distribuida que a veces opera mejor de lo que está documentada. Hasta que deja de hacerlo.

El problema serio aparece cuando el registro contractual existe, pero no conversa con el inventario técnico; cuando el inventario técnico existe, pero no se vincula a procesos críticos; o cuando ambos existen, pero nadie los ha traducido en un análisis útil para el consejo. Entonces llega la paradoja: la entidad sabe mucho y entiende poco. Tiene datos, no gobierno.

DORA intenta impedir esa fragmentación exigiendo que el riesgo de terceros no viva en una urna separada del resto del marco. Y hace bien. Porque una interrupción grave en un proveedor crítico no se presenta en la realidad como “riesgo de outsourcing”. Se presenta como indisponibilidad de un servicio, afectación a clientes, presión reputacional, posibles obligaciones de notificación y horas carísimas de respuesta ejecutiva.

Lo que un supervisor probablemente mirará con más interés del que te gustaría

Cuando una autoridad revise la gobernanza de resiliencia operativa digital, no le impresionará demasiado un catálogo exuberante de políticas si luego encuentra vacíos en cuestiones básicas. Mirará, previsiblemente, cuatro cosas.

La primera: si el órgano de dirección ha aprobado y revisado de verdad el marco de riesgo de TIC, con evidencia de cambios, discusiones y seguimiento. La segunda: si la entidad identifica sus funciones críticas o importantes y puede conectarlas con activos, procesos y terceros. La tercera: si los incidentes se gestionan con criterios consistentes y escalado eficaz. La cuarta: si las decisiones de negocio reflejan la información de riesgo recibida.

Nada de esto es exótico. Todo es trabajoso. Y precisamente por eso muchas organizaciones siguen refugiándose en el confort del cumplimiento formal. Sale más barato presentar veinte documentos que resolver una dependencia mal diseñada. Sale más rápido redactar una matriz RACI que probar de verdad una reversión compleja. Sale más limpio reportar “sin incidentes materiales” que reconocer que la clasificación interna no permite saber con seguridad si el incidente era material o no.

El regulador, por desgracia para los amantes del teatro corporativo, cada vez distingue mejor entre papeles y capacidad operativa.

Qué deberías hacer mañana si este debate te afecta

Si eres consejero, secretario del consejo, CRO, CISO o responsable de compliance en una entidad dentro del perímetro de DORA, el movimiento útil no es pedir otra presentación general sobre la norma. Eso ya está amortizado. Lo útil es someter la gobernanza actual a una prueba de realidad.

Empieza por tres preguntas. Una: ¿qué decisión relevante tomó el órgano de dirección en los últimos doce meses como consecuencia directa de un riesgo TIC, un incidente o una debilidad de terceros? Dos: ¿puede la entidad explicar con trazabilidad qué servicios críticos dependen de qué terceros y con qué alternativa plausible? Tres: ¿existe un proceso de clasificación y escalado de incidentes que funcione en horas, no en debates? Si no puedes responder con evidencia, tienes trabajo de verdad, no trabajo cosmético.

Después, cruza marcos. Revisa DORA junto con NIS2 art. 20 y 21 si tu organización cae en ambos perímetros o si parte del grupo lo hace. Verifica la interacción con GDPR art. 33 para incidentes con datos personales. Alinea el lenguaje de consejo, riesgo, seguridad, legal y operaciones. Una entidad puede sobrevivir a un control mejorable; lo que no sobrevive bien es a cinco funciones hablando idiomas distintos durante una crisis.

Y una última recomendación, quizá la menos vistosa y la más rentable: lleva al órgano de dirección un caso concreto, reciente o simulado, que obligue a elegir entre velocidad comercial, coste operativo y reducción de riesgo. Si el debate es pobre, abstracto o evasivo, acabas de obtener el diagnóstico más fiable de tu gobernanza.

La conclusión incómoda

La lección de fondo no es nueva, pero DORA la hace imposible de seguir disimulando. La resiliencia operativa digital no se compra solo con tecnología ni se demuestra solo con documentación. Se gobierna. Y gobernar significa asumir que hay decisiones que no pueden quedar enterradas en la segunda línea, en el proveedor de turno o en un comité que produce actas impecables y coraje escaso.

Por eso el debate sobre artículos concretos importa, pero no debería usarse como escapatoria. Sí, conviene citar bien la norma y anclar cada obligación a su base jurídica correcta. Pero, una vez hecho eso, el mensaje sustantivo permanece intacto: DORA asigna responsabilidad real al órgano de dirección sobre el marco de riesgo TIC, exige procesos sólidos para gestionar y escalar incidentes, y obliga a tratar el riesgo de terceros como un problema de gobierno corporativo, no como un apéndice contractual.

El resto es bastante simple. Si la información de riesgo no cambia decisiones, la gobernanza falla. Si el consejo no puede explicar dependencias críticas, la supervisión acabará preguntando por ellas. Y si una entidad cree que resiliencia equivale a tener más papeles que problemas, probablemente terminará descubriendo que tenía justo lo contrario.