El Reglamento de Resiliencia Operativa Digital (DORA) entró en plena vigencia el 17 de enero de 2025. Entre sus obligaciones principales se encuentra el requisito de que las entidades financieras mantengan un Registro de Información estructurado — un inventario completo de todos los acuerdos de servicios TIC con terceros, incluidos los subcontratistas y los servicios intragrupo.
Esta guía explica qué es el Registro de Información DORA, qué organizaciones están obligadas a mantenerlo, qué campos de datos son obligatorios y cómo estructurar un modelo operativo sostenible. Tanto si usted es un responsable de cumplimiento que prepara su primera presentación, un gestor de riesgos que revisa la calidad de los datos o un gestor de proveedores que navega la propiedad interdepartamental, esta guía le acompaña en cada paso.
Aprenderá: qué esperan los reguladores, qué entidades están dentro del ámbito de aplicación, cuáles son las categorías de datos obligatorias, quién debe ser responsable de cada campo, los siete pasos para construir su registro, los errores más comunes que provocan fallos en la presentación y cómo las herramientas específicas pueden simplificar el mantenimiento continuo.
¿Qué es el Registro de Información DORA?
El Registro de Información DORA (RdI) es un conjunto de datos estructurado que las entidades financieras deben compilar y mantener en virtud del artículo 28(3) del Reglamento (UE) 2022/2554. Registra cada acuerdo de servicios TIC con terceros vigente — desde proveedores de infraestructura en la nube hasta plataformas SaaS, servicios de seguridad gestionados, procesadores de pagos y relaciones TIC intragrupo.
El propósito del registro es supervisor. Las Autoridades Nacionales Competentes (ANC) y las Autoridades de Supervisión Europeas (ABE, AESPJ, AEVM) utilizan el registro para evaluar el panorama de dependencia TIC de una entidad, identificar el riesgo de concentración y supervisar la postura de resiliencia operativa del sector financiero en su conjunto. Las AES publican un informe agregado anual basado en los datos presentados por las empresas de toda la UE.
Finalidad regulatoria
DORA va más allá de los registros tradicionales de externalización. Los requisitos del Registro de Información están definidos en las RTS Conjuntas sobre el registro de información en virtud de los artículos 28(9) y 30(5) de DORA (JC 2023 84). Las RTS especifican los campos de datos exactos, la cardinalidad y las reglas de validación. También establece que el registro debe mantenerse continuamente actualizado — no solo en el momento de la presentación.
Informes supervisores
Las entidades financieras están obligadas a proporcionar su registro a su ANC de forma anual y a petición en cualquier momento. La ANC puede transmitir los datos a la AES correspondiente. Las presentaciones deben ajustarse a las plantillas de datos prescritas (normalmente en formato CSV o XBRL), y la validación detectará campos ausentes, identificadores inconsistentes y errores de integridad referencial.
Supervisión del riesgo TIC de terceros
El registro alimenta otras obligaciones de DORA. Las evaluaciones de criticidad, las estrategias de salida y las revisiones contractuales referencian el mismo inventario de terceros. Por tanto, lograr que el registro sea correcto no es un ejercicio aislado — ancla todo su marco de gestión del riesgo TIC de terceros.
Resiliencia operativa
En esencia, el Registro de Información DORA es un instrumento de resiliencia operativa. Al obligar a las entidades a mapear y documentar cada dependencia TIC — incluidas las cuartas partes — crea visibilidad que la dirección y los reguladores pueden utilizar para evaluar si el fallo de un único proveedor podría causar una perturbación sistémica. El registro no es solo documentación de cumplimiento; es una herramienta de gestión de riesgos que respalda sus obligaciones de planificación de continuidad y salida.
¿Quién debe mantener un Registro DORA?
DORA se aplica a una amplia gama de entidades financieras que operan en la Unión Europea. El artículo 2 del Reglamento define el ámbito de aplicación, que abarca la mayoría de las instituciones financieras reguladas.
Entidades de crédito
Bancos y prestamistas hipotecarios autorizados al amparo de la DRC.
Empresas de inversión
Empresas de inversión autorizadas por MiFID II que prestan servicios financieros.
Entidades de pago
Entidades de pago y de dinero electrónico con licencia PSD2.
Empresas aseguradoras
Aseguradoras y reaseguradoras autorizadas por Solvencia II.
Proveedores de servicios de criptoactivos
PSCA autorizados por MiCA a partir de su incorporación supervisada.
ECC, DCV y repositorios de operaciones
Entidades de contrapartida central, depositarios centrales de valores y proveedores de servicios de suministro de datos.
El principio de proporcionalidad
DORA reconoce que no se puede esperar que una pequeña entidad de pago mantenga la misma infraestructura de resiliencia operativa que un banco de importancia sistémica. El artículo 4 introduce la proporcionalidad: las microempresas y las entidades pequeñas se benefician de un régimen simplificado que reduce ciertos requisitos de documentación y gobernanza, manteniendo la obligación principal del registro.
Exenciones
Las microempresas (menos de 10 empleados y volumen de negocios anual o balance inferior a 2 millones de euros) se acogen a un régimen DORA simplificado. Siguen estando obligadas a mantener un registro, pero los requisitos de gobernanza, pruebas e informes son más ligeros. Incluso las microempresas deben identificar los servicios TIC críticos y garantizar que existen las protecciones contractuales básicas.
Las entidades que operan fuera de la UE pero que prestan servicios a entidades financieras de la UE no están directamente sujetas a DORA — pero sí lo están sus clientes, que deben garantizar que existen contratos y evaluaciones de riesgos conformes con DORA para dichos acuerdos.
¿Qué información debe incluirse?
Las RTS Conjuntas especifican un modelo de datos detallado para el Registro de Información. La siguiente tabla resume las principales categorías de datos y ejemplos de lo que requiere cada una.
| Categoría | Ejemplos |
|---|---|
| Información del proveedor | Nombre de la entidad jurídica, LEI, país de constitución, pertenencia a grupo |
| Servicios TIC | Alojamiento, SaaS, MSP, soporte TI, servicios en la nube, procesamiento de pagos |
| Clasificación de criticidad | Crítico / No crítico, función o proceso de apoyo |
| Detalles del contrato | Fecha de inicio, fecha de fin, condiciones de renovación, período de preaviso de rescisión |
| Subcontratistas | Proveedores TIC de cuarta parte, cadenas de subcontratación, país de operación |
| Estrategia de salida | Estado del plan de salida, proveedores alternativos identificados, calendario de migración |
| Evaluación de riesgos | Evaluaciones de riesgo vinculadas, calificación de riesgo, fecha de la última evaluación |
Información del proveedor
Cada tercero TIC debe identificarse mediante un identificador de entidad jurídica (LEI) cuando exista uno disponible. El nombre jurídico, el país y la estructura del grupo del proveedor deben registrarse. El uso de identificadores de entidad coherentes y validados es fundamental — los supervisores los utilizan para agregar datos entre empresas e identificar el riesgo de concentración. Los nombres informales, nombres comerciales o abreviaturas no son suficientes.
Servicios TIC
Para cada acuerdo, debe describir los servicios TIC prestados. Las RTS utilizan un vocabulario controlado para los tipos de servicio. Las categorías más comunes incluyen: servicios de computación en la nube, análisis de datos, colocación en centros de datos, mantenimiento y soporte de software, servicios TI gestionados, servicios de ciberseguridad y servicios de pago. Cada acuerdo de servicio se registra por separado, aunque lo preste el mismo proveedor.
Clasificación de criticidad
Determinar si un servicio TIC apoya una función crítica o importante (FCI) es una de las decisiones más relevantes del registro. Los servicios críticos atraen una supervisión más estricta, requisitos contractuales más exigentes y documentación obligatoria de la estrategia de salida. La clasificación debe basarse en una evaluación de impacto documentada — no en un juicio general — y revisarse al menos anualmente o cuando se produzcan cambios materiales.
Detalles del contrato
Las fechas de inicio y fin del contrato, las condiciones de renovación y los períodos de preaviso deben ser precisos y coincidir con los registros de gestión contractual. Los supervisores utilizan estos datos para evaluar el riesgo de dependencia y la concentración. Los contratos que han caducado o se han renovado automáticamente sin revisión son un fallo de calidad habitual.
Subcontratistas
DORA extiende el requisito del registro a los subcontratistas — denominados frecuentemente cuartas partes — que apoyan la prestación de un servicio TIC crítico o importante. Debe identificar a estos subcontratistas, su país de operación y señalar cualquier dependencia material. Esto requiere un compromiso activo con sus proveedores principales para obtener la divulgación de sus cadenas de suministro.
Estrategia de salida
Para cada acuerdo que respalde una función crítica o importante, el registro debe reflejar si existe una estrategia de salida documentada, el estado de la identificación de proveedores alternativos y si el plan de salida ha sido probado. Muchas organizaciones tienen estrategias de salida como concepto, pero carecen del detalle específico por servicio y probado que exige DORA.
Evaluación de riesgos
El registro debe vincular cada acuerdo a una evaluación de riesgos. Esto incluye la calificación de riesgo global, la fecha de la evaluación más reciente y cualquier acción de remediación abierta. El registro de riesgos proporciona a los auditores y supervisores evidencia de que la entidad gestiona activamente — y no solo documenta — sus dependencias TIC.
Modelo de responsabilidad del Registro DORA
Una de las causas raíz más habituales de la baja calidad del registro es la ausencia de un modelo de responsabilidad claro. El Registro de Información DORA es transversal por naturaleza: los datos que requiere abarcan los departamentos jurídico, de compras, de riesgos, de seguridad de la información y de operaciones empresariales. Ningún departamento puede mantenerlo por sí solo.
Jurídico
Titularidad de los contratos, ley aplicable, cláusulas de rescisión y derechos contractuales de acceso y auditoría. El departamento jurídico debe validar las fechas de los contratos, los períodos de preaviso y confirmar si las disposiciones exigidas por DORA están presentes en cada acuerdo.
Compras y gestión de proveedores
Identificación de proveedores, verificación de LEI, solicitudes de divulgación de subcontratistas y seguimiento de renovaciones. Compras suele mantener el maestro de proveedores y está en mejor posición para identificar nuevos acuerdos antes de que aparezcan en el registro.
Seguridad de la información
Calificaciones de riesgo, evaluaciones de seguridad, vinculación de incidentes y postura de seguridad de los subcontratistas. Los equipos de seguridad de la información poseen los resultados más recientes de la diligencia debida con proveedores y son responsables de validar los datos de riesgo técnico.
Responsables de negocio
Criticidad del servicio, funciones de apoyo y dependencias operativas. Los responsables de negocio están en mejor posición para evaluar si un servicio apoya una función crítica o importante — esta valoración no puede realizarse de forma centralizada sin la aportación del negocio.
Cumplimiento y supervisión regulatoria
Completitud global del registro, preparación de presentaciones y coordinación con la ANC. Cumplimiento debe ser el propietario del marco de gobernanza — las reglas de calidad, los ciclos de revisión y las rutas de escalado — aunque no sea propietario de campos de datos individuales.
Un modelo de responsabilidad eficaz define, para cada campo de datos, qué departamento proporciona los datos, qué departamento los valida y con qué frecuencia. Esto se documenta habitualmente en una matriz RACI. Sin esta claridad, el registro se deteriorará: los campos quedarán obsoletos, surgirán conflictos entre fuentes y nadie asumirá la responsabilidad de los fallos de calidad.
Errores habituales en el Registro DORA
Estas son las causas más frecuentes de fallos en la calidad del registro y rechazos en la presentación, basadas en la experiencia de implementación en entidades financieras.
1. Subcontratistas ausentes
La mayoría de las empresas tienen una imagen clara de sus proveedores TIC directos, pero una imagen deficiente de las cuartas partes. Si su proveedor de nube subcontrata el procesamiento de datos a un subencargado, esa relación debe aparecer en su registro para los servicios críticos. No registrar los subcontratistas es uno de los fallos de validación más frecuentes señalados por los supervisores.
2. Entradas duplicadas de proveedores
El mismo proveedor apareciendo bajo diferentes nombres, identificadores o entidades jurídicas es un problema de calidad de datos que se propaga por todo el registro. Los cálculos de riesgo de concentración se vuelven poco fiables. Utilice códigos LEI validados y un maestro de proveedores canónico para evitar la proliferación de duplicados.
3. Clasificaciones de criticidad incorrectas
Clasificar en exceso los servicios como no críticos reduce la carga de supervisión pero crea riesgo regulatorio. Clasificar insuficientemente los servicios críticos es un incumplimiento material. Las clasificaciones deben estar respaldadas por evaluaciones de impacto documentadas — no realizadas informalmente por quien esté rellenando la hoja de cálculo.
4. Datos contractuales desactualizados
Fechas de vencimiento de contratos que ya han pasado, condiciones de renovación que ya no reflejan el acuerdo vigente y períodos de preaviso de rescisión ausentes indican un registro que no se está manteniendo. Esto es especialmente frecuente cuando el registro se construyó una sola vez como proyecto y no se integró en los procesos continuos de gestión contractual.
5. Ausencia de un modelo de responsabilidad claro
Sin una propiedad de datos documentada, el registro se convierte en responsabilidad de nadie. Cuando los campos son incorrectos o están incompletos, no hay un camino claro hacia la remediación. Las organizaciones que construyeron su registro como un proyecto de cumplimiento en lugar de una herramienta operativa viva casi siempre se enfrentan a este problema.
6. Planes de salida ausentes
La documentación de la estrategia de salida es obligatoria para los servicios críticos, pero muchas organizaciones solo tienen una política genérica de salida en lugar de planes específicos por servicio. DORA exige que pueda demostrar una vía de transición plausible para cada acuerdo crítico — una declaración general de que encontraría un proveedor alternativo no es suficiente.
Cómo construir un Registro DORA paso a paso
Construir un Registro de Información DORA listo para su presentación es un proyecto con siete fases diferenciadas. Cada fase tiene entregables y dependencias claros.
Paso 1
Definir el ámbito de aplicación
Identifique qué entidades jurídicas de su grupo están dentro del ámbito de aplicación de DORA y si se requiere un informe consolidado o por entidad. Confirme con su ANC el formato de presentación requerido. Documente los servicios dentro del ámbito, incluidos los acuerdos intragrupo, y establezca qué funciones son candidatas a la clasificación de criticidad. La definición del ámbito es la base — los errores aquí se propagan a cada paso posterior.
Paso 2
Inventariar los proveedores TIC
Compile una lista completa de todos los acuerdos de servicios TIC con terceros. Las fuentes incluyen: registros de contratos, sistemas de cuentas a pagar, inventarios de activos TI, listas de proveedores de seguridad y entrevistas con responsables de negocio. Valide los nombres de las entidades jurídicas en los registros LEI. Identifique los proveedores intragrupo y confirme si están cubiertos por acuerdos de servicios internos. En esta etapa, la exhaustividad importa más que la exactitud — puede corregir datos; no puede reportar lo que no ha encontrado.
Paso 3
Clasificar los servicios
Para cada acuerdo, determine si apoya una función crítica o importante. Trabaje con los responsables de negocio para evaluar el impacto de una interrupción del servicio. Documente la justificación. Aplique el vocabulario controlado de tipos de servicio de las RTS. Cuando un mismo contrato incluya varios servicios, registre cada servicio por separado. Marque los acuerdos que requieran divulgación de subcontratistas e inicie las solicitudes a los proveedores.
Paso 4
Asignar responsabilidades
Cree una matriz RACI que asigne cada campo de datos a un propietario responsable. Confirme la propiedad con cada departamento. Establezca el ciclo de revisión de cada campo — algunos campos (como las fechas de los contratos) solo cambian en la renovación; otros (como las calificaciones de riesgo) deben revisarse trimestralmente. Integre las actualizaciones del registro en los procesos existentes: firma de contratos, aprobación de compras, ciclos de revisión de proveedores. La responsabilidad sin integración en los procesos no sobrevivirá al primer ciclo anual.
Paso 5
Validar la calidad de los datos
Realice controles de calidad sistemáticos en todos los campos de datos antes de considerar el registro listo para su presentación. Los controles deben cubrir: completitud de los campos obligatorios, valores de vocabulario controlado válidos, lógica de fechas (la fecha de fin debe ser posterior a la de inicio, sin contratos caducados sin registros de renovación), integridad referencial (cada servicio crítico debe vincularse a un registro de estrategia de salida), detección de proveedores duplicados y completitud de subcontratistas para los servicios críticos.
Paso 6
Establecer la gobernanza
Defina el modelo de gobernanza continua. Esto incluye: una revisión de calidad mensual o trimestral con todos los propietarios de datos; una ruta de escalado para los problemas de calidad no resueltos; un proceso de gestión del cambio para acuerdos nuevos, modificados o rescindidos; una revisión anual completa de las clasificaciones de criticidad; y un sprint de validación previo a la presentación antes de cada ventana de informes regulatorios. La gobernanza debe documentarse en una política o procedimiento operativo que sobreviva a la rotación del personal.
Paso 7
Preparar las presentaciones regulatorias
Exporte el registro en el formato requerido por su ANC (normalmente CSV alineado con las plantillas de datos JTS o XBRL). Ejecute el conjunto de reglas de validación de las AES sobre su exportación antes de la presentación — los errores detectados internamente son mucho menos costosos que los señalados por su supervisor. Conserve el artefacto de presentación y una marca de tiempo. Tras la presentación, trate cualquier comentario de la ANC como un impulso de mejora de la calidad y actualice su proceso de gobernanza en consecuencia.
Ejemplo de plantilla del Registro DORA
La siguiente estructura muestra una fila representativa de un Registro de Información DORA. Cada fila representa un único acuerdo de servicio TIC. Un mismo proveedor puede aparecer en múltiples filas si presta varios servicios distintos.
| Campo | Valor de ejemplo |
|---|---|
| Proveedor | Acme Cloud Services B.V. |
| LEI | 5493001KJTIIGC8Y1R12 |
| Servicio | Infraestructura en la nube (IaaS) |
| Criticidad | Crítico |
| Responsable de negocio | Head of IT Operations |
| Inicio del contrato | 2022-01-01 |
| Fin del contrato | 2027-12-31 |
| Subcontratistas | DataStore GmbH (DE), NetOps Ltd (IE) |
| Estrategia de salida | Documentada — alternativa identificada, plan probado por última vez en 2024-11 |
| Calificación de riesgo | Alta |
| Fecha de última revisión | 2025-03-15 |
Registro DORA frente a registros de externalización tradicionales
Muchas entidades financieras ya mantienen algún tipo de registro de externalización o de proveedores — a menudo construido para cumplir las directrices de externalización de la ABE o los requisitos internos de compras. El Registro de Información DORA es significativamente más exigente. La siguiente tabla destaca las diferencias clave.
| Dimensión | Registro tradicional | Registro DORA |
|---|---|---|
| Finalidad principal | Seguimiento de proveedores y gestión del gasto | Resiliencia operativa e informes supervisores |
| Ámbito de aplicación | Todos los proveedores o servicios externalizados | Todos los acuerdos TIC, incluidos los intragrupo |
| Profundidad de datos | Enfoque en contratos y costes | Datos de riesgo, dependencia, subcontratistas y salida |
| Informes | Solo interno | Presentación supervisora anual obligatoria |
| Formato | Formato libre (Word, Excel) | Plantillas prescritas con reglas de validación |
| Cuartas partes | Generalmente no registradas | Obligatorio para servicios críticos |
| Criticidad | Limitada o informal | Evaluada y documentada formalmente |
| Frecuencia de actualización | Anual o por proyecto | Continua, impulsada por eventos más revisión periódica |
Si su organización ya mantiene un registro de externalización ABE, este constituye un punto de partida útil — pero normalmente solo cubrirá entre el 60 y el 70 % de lo que exige DORA. Las carencias suelen estar en los datos de subcontratistas, la vinculación con la estrategia de salida, la formalidad de la criticidad y el formato de presentación regulatoria. Un análisis de brechas frente al modelo de datos de las RTS es el primer paso recomendado.
Cómo RiskNow ayuda a mantener un Registro DORA
RiskNow es una plataforma GRC construida por profesionales que han implementado programas DORA en entidades financieras. La plataforma ofrece un módulo dedicado de Registro de Información que le ayuda a mantener un inventario completo de terceros, rastrear las dependencias de la cadena de suministro y preparar outputs regulatorios listos para su presentación.
Registro de terceros
Mantenga un registro estructurado de terceros TIC con datos de entidades jurídicas, LEIs, mapeos de servicios, clasificación de criticidad, detalles del ciclo de vida contractual y propietarios de campos responsables.
Visibilidad de la cadena de suministro
Mapee subcontratistas y cuartas partes en toda su cadena de suministro TIC, vincule las dependencias a los servicios críticos y mantenga un registro auditable de dónde se concentran los riesgos de concentración y resiliencia.
Informes de calidad de datos (más de 100 controles)
Ejecute informes de calidad de datos con más de 100 controles automatizados que cubren completitud, valores controlados, detección de duplicados, lógica de fechas e integridad referencial antes de la presentación.
Exportaciones regulatorias (XBRL / CSV)
Exporte los datos del registro a formatos XBRL y CSV listos para el regulador, alineados con las plantillas supervisoras, con validación previa a la exportación para detectar problemas antes de la presentación.
Al conectar terceros, relaciones de la cadena de suministro, contratos, evaluaciones de riesgos e incidentes en un único modelo, RiskNow reduce la reconciliación manual y ayuda a los equipos a mantener el registro actualizado entre los ciclos de presentación anuales.
Preguntas frecuentes
¿Qué es el Registro de Información DORA?
El Registro de Información DORA es un inventario estructurado de todos los acuerdos de servicios TIC con terceros mantenido por una entidad financiera en virtud del artículo 28(3) del Reglamento (UE) 2022/2554. Cubre proveedores, servicios, criticidad, contratos, subcontratistas y evaluaciones de riesgos.
¿Es obligatorio el Registro DORA?
Sí. Todas las entidades financieras dentro del ámbito de aplicación deben mantener un Registro de Información y proporcionarlo a su autoridad nacional competente anualmente o a petición. El incumplimiento puede dar lugar a medidas supervisoras, incluida la divulgación pública, multas y órdenes de remediación.
¿Con qué frecuencia debe actualizarse el registro DORA?
El registro debe mantenerse continuamente actualizado. En la práctica, esto implica actualizaciones impulsadas por eventos para nuevos acuerdos, cambios contractuales materiales y servicios rescindidos — complementadas por una revisión de calidad periódica (mensual o trimestral) y una actualización completa anual antes de la ventana de presentación supervisora.
¿Qué son los servicios TIC críticos?
Los servicios TIC críticos son aquellos que apoyan una función crítica o importante (FCI) — cuyo fallo o degradación perjudicaría materialmente el cumplimiento normativo, la solidez financiera o la prestación de servicios de la entidad. La criticidad debe evaluarse mediante un análisis de impacto documentado y revisarse al menos anualmente.
¿Deben incluirse los subcontratistas en el registro?
Sí, para los servicios críticos e importantes. Debe identificar los subcontratistas (cuartas partes) que forman parte de la cadena de prestación de un servicio crítico e incluirlos en el registro. Esto requiere un compromiso proactivo con los proveedores principales para obtener la divulgación de los subcontratistas.
¿En qué se diferencia DORA de las directrices de externalización de la ABE?
Las directrices de externalización de la ABE se centran principalmente en la gobernanza, los requisitos contractuales y las obligaciones de notificación para la externalización material. DORA va más lejos: cubre todos los acuerdos TIC (no solo la externalización material), exige la divulgación de subcontratistas para los servicios críticos, requiere estrategias de salida formalmente documentadas e introduce un registro de informes supervisores estandarizado con campos de datos prescritos.
¿Se puede utilizar Excel para mantener el registro DORA?
Técnicamente sí, pero en la práctica crea un riesgo operativo significativo. Los registros en Excel tienen dificultades con el control de acceso, la gestión de versiones, la integridad referencial entre tablas y los registros de auditoría. Para entidades pequeñas con menos de 20-30 acuerdos, una hoja de cálculo estructurada puede ser suficiente a corto plazo. Para entidades más grandes, se recomienda encarecidamente una plataforma específica.
¿Qué campos de datos exige el registro DORA?
Las RTS Conjuntas especifican los campos obligatorios, entre los que se incluyen: nombre de la entidad jurídica del proveedor y LEI, tipo de servicio TIC, función de apoyo, clasificación de criticidad, fechas de inicio y fin del contrato, período de preaviso de rescisión, datos de subcontratistas (para servicios críticos), estado de la estrategia de salida y vinculación de la evaluación de riesgos. Consulte la sección "¿Qué información debe incluirse?" más arriba para ver un desglose completo.
¿Qué ocurre si el registro DORA está incompleto en el momento de la presentación?
Un registro incompleto o inexacto puede dar lugar a: la devolución de la presentación por parte de la ANC para su corrección, un diálogo supervisor formal sobre las deficiencias en la gobernanza de datos o — en casos persistentes — medidas supervisoras escaladas. Los fallos reiterados se tratan como evidencia de deficiencias más amplias en la resiliencia operativa.