La banca nativa en la nube en 2026 está en fase de auditoría DORA. El Reglamento (UE) 2022/2554 ⧉ está en vigor desde el 17 de enero de 2025. El régimen de designación de proveedores terceros críticos (CTPP) bajo los Articles 28-44 se ha ido abriendo durante 2025-2026, con AWS, Microsoft (Azure), Google (GCP) y Salesforce dentro o cerca del perímetro de designación. Las Autoridades Europeas de Supervisión (EBA, EIOPA, ESMA) publicaron las RTS e ITS finales sobre el Registro de Información ⧉ en 2024. El equipo de Supervisión Bancaria del BCE incluye programas explícitos sobre preparación ante interrupciones en la nube y pruebas de penetración guiadas por amenazas en las prioridades supervisoras 2026-28 ⧉. La pregunta institucional no es si alinear la estrategia de nube con DORA — eso está zanjado — sino si las primitivas de ingeniería de plataforma de la institución producen evidencia a la velocidad del pipeline de despliegue o en PDF montados la semana antes del examen.
Resumen ejecutivo / Conclusiones clave
- Resiliencia en la nube bajo DORA en aplicación activa desde el 17 de enero de 2025. Articles 6, 8, 18, 26 y 28-44 en vigor. Los hallazgos supervisores de la primera oleada de exámenes aterrizaron en el T4 de 2025. La narrativa de "preparación" lleva dos ciclos de retraso.
- Régimen de designación CTPP en apertura. AWS, Microsoft, Google, Salesforce — dentro o cerca. La designación otorga a las ESA derechos directos de supervisión, incluidas solicitudes de información, inspecciones in situ y recomendaciones supervisoras.
- La ingeniería de plataforma es el entregable. Vías pavimentadas en Kubernetes (EKS / AKS / GKE / OpenShift), portal de desarrollador estilo Backstage, GitOps (ArgoCD o Flux), Open Policy Agent en admisión, OpenTelemetry de extremo a extremo. Cinco primitivas con nombre propio; lo que falte es un hallazgo.
- La nube soberana es ingeniería, no marketing. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — cada una aborda una dimensión específica Schrems II + DORA Article 28; ninguna es una respuesta llave en mano.
- Se exige evidencia de salida probada. EBA/GL/2019/02 apartados 81 y 113-117. El simulacro trimestral es insuficiente; los supervisores esperan pruebas anuales de ejecución de salida de extremo a extremo para toda función crítica o importante.
- RTO / RPO desde el inventario de CIF. Nivel 1: 2h / 15min. Nivel 2: 4h / 1h. Nivel 3: 24h / 4h. Derivado del análisis de impacto en el negocio, no de la capacidad del equipo de plataforma.
Por qué la resiliencia en la nube bajo DORA está en fase de auditoría #
Tres razones por las que la narrativa de "preparación" es errónea en 2026.
Primera, la cronología. DORA se publicó en diciembre de 2022. El periodo de aplicación de 24 meses se cerró el 17 de enero de 2025. Las RTS e ITS finales de las ESA — incluidas las ITS sobre el Registro de Información utilizadas para la designación de CTPP — se publicaron a lo largo de 2024. La primera oleada de exámenes supervisores se desarrolló durante 2025; los hallazgos sobre la completitud del marco de gestión del riesgo TIC del Article 6 y sobre la conciliación del registro del Article 8 aterrizaron en el T4 de 2025 en múltiples instituciones de nivel 1.
Segunda, el régimen de designación CTPP. El Article 31 establece los criterios para la designación como proveedor tercero crítico: impacto sistémico en caso de fallo, criticidad de los servicios prestados, escala y complejidad de los servicios, sustituibilidad. Las ESA mantienen el registro y publican las decisiones de designación. AWS, Microsoft (Azure), Google (GCP) y Salesforce están dentro o cerca del perímetro de designación, en función de la cuota de mercado en servicios financieros por Estado miembro. La designación otorga al supervisor principal (una de las ESA, asignada por proveedor) competencia directa de supervisión: solicitudes de información al amparo del Article 37, inspecciones in situ al amparo del Article 38, recomendaciones al amparo del Article 35 y el régimen de divulgación pública del Article 41. Los bancos supervisados sobre esos CTPP quedan sujetos a las correspondientes expectativas supervisoras sobre cómo gestionan esa dependencia designada.
Tercera, las prioridades supervisoras 2026-28 del BCE. El documento de prioridades cita dos programas explícitos que afectan directamente a la banca nativa en la nube: preparación ante una interrupción mayor del servicio en la nube (los escenarios supervisores modelizados ponen a prueba la capacidad de la institución para absorber una caída sostenida de un CTPP designado) y TLPT alineado con TIBER-EU (cada ejercicio TIBER-EU define como alcance las funciones críticas o importantes de la institución, que ahora incluyen los servicios alojados en nube pública). La oleada de exámenes de 2026 producirá hallazgos en ambos frentes.
El encuadre para 2026 no es "DORA está llegando"; es "los hallazgos del examen DORA están llegando al buzón de tu institución, y las decisiones de ingeniería de plataforma que tomaste entre 2024 y 2025 son las que el supervisor examina en esos hallazgos".
La arquitectura del índice 2026 #
| Capa del índice | Cómo se ve la preparación | Métrica de preparación | Modo de fallo |
|---|---|---|---|
| Madurez de plataforma | Más del 80 % de las cargas de trabajo sobre una plataforma Kubernetes con vía pavimentada (EKS / AKS / GKE / OpenShift), con admisión basada en política como código, despliegue GitOps y pruebas automatizadas de DR | % de CIF en plataforma con vía pavimentada; recuento de despliegues en la sombra; tiempo medio para incorporar un nuevo servicio a la plataforma | Plataformas en la sombra con controles inconsistentes; CIF en infraestructura no pavimentada e invisible para la conciliación del registro del Article 8 |
| Integridad del registro del Article 8 | El Registro de Información se concilia automáticamente con el consumo de API de terceros + la lista de materiales en la nube de la plataforma; la clasificación de criticidad coherente con el inventario de CIF de la institución | % de entradas del registro conciliadas con la telemetría de la plataforma; recuento de entradas huérfanas; comprobación de integridad del perímetro CTPP | Las ESA identifican una dependencia de CTPP designado que la institución no declaró bajo el Article 8; hallazgo individual y consecuencia para el perímetro CTPP |
| Concentración en la nube | Funciones críticas mapeadas a proveedores de nube, subregiones, servicios y evaluación de sustituibilidad; exposición correlacionada entre CIF cuantificada | Puntuación de concentración por CIF; exposición correlacionada entre CIF que comparten una región del mismo CTPP designado | Una sola interrupción de IAM en AWS us-east-1 tumba cuatro CIF que la institución creía aprovisionadas con recursos independientes |
| Capacidad de salida probada | Prueba anual de ejecución de salida de extremo a extremo para cada CIF dependiente de un CTPP designado; RTO / RPO documentados que cumplen los objetivos derivados del BIA; ruta de portabilidad de datos probada | Tasa de pruebas superadas por CIF; tiempo medio de ejecución de salida frente al objetivo de RTO; latencia de la ruta de portabilidad de datos | Plan de salida que solo existe como PDF; el simulacro dice 4h de RTO, la prueba real muestra 48h en el primer intento |
| Observabilidad + notificación de incidentes | Trazas de OpenTelemetry de extremo a extremo entre servicios; ayudante automatizado de clasificación a 4 horas del Article 18 cableado en la plataforma de gestión de incidentes | % de tráfico de CIF cubierto por trazas OTel; tiempo medio desde la detección del incidente hasta la decisión de clasificación del Article 18 | Incidente grave clasificado fuera de la ventana de 4 horas porque la determinación de criticidad exigió una reunión de triaje; hallazgo del Article 18 |
| Integración TLPT | Alcance TLPT derivado del inventario de CIF y refrescado de forma continua; los hallazgos retroalimentan la política como código de la plataforma; los hallazgos cerrados generan paquetes de evidencia listos para el supervisor | Tasa de cierre de hallazgos TLPT; tiempo de ciclo de hallazgo a actualización de política | El TLPT descubre una vulnerabilidad que el equipo de ingeniería de plataforma no consigue corregir en menos de dos ciclos de versión |
Señales actuales a seguir #
| Señal | Qué significa para los bancos | Fuente |
|---|---|---|
| DORA en aplicación activa desde el 17 de enero de 2025 | Hallazgos supervisores de primera oleada aterrizados en el T4 de 2025; se esperan hallazgos de segunda oleada hasta el segundo semestre de 2026 | EUR-Lex ⧉ |
| Designación CTPP en apertura durante 2025-2026 | AWS, Microsoft, Google, Salesforce dentro o cerca del perímetro; la designación otorga a las ESA competencia directa de supervisión | EBA ⧉ |
| Las prioridades supervisoras 2026-28 del BCE citan explícitamente la interrupción de la nube | Los escenarios supervisores modelizados ponen a prueba la capacidad de absorber una caída sostenida del CTPP designado | Supervisión Bancaria del BCE ⧉ |
| TIBER-EU alineado con el DORA Article 26 | El alcance TLPT cubre las funciones críticas o importantes, incluidos los servicios alojados en la nube | TIBER-EU del BCE ⧉ |
| Las directrices de externalización de la EBA (EBA/GL/2019/02) encajan con el DORA Article 28 | Presencia sustantiva (¶64), evaluación de sustituibilidad (¶81), estrategia de salida (¶113-117) — los apartados que los supervisores realmente comprueban | EBA ⧉ |
| El borrador del Esquema Europeo de Servicios en la Nube (EUCS) avanza | Futuro esquema de certificación de nube soberana al amparo del Acta de Ciberseguridad de la UE; borrador publicado por ENISA | EUCS de ENISA ⧉ |
Ingeniería de plataforma: las cinco primitivas con nombre propio #
La madurez nativa en la nube en 2026 se reduce a cinco primitivas de ingeniería que se entrelazan para producir evidencia supervisora a la velocidad del pipeline de despliegue. Que falte cualquiera de ellas es un hallazgo esperando suceder.
1. Vías pavimentadas basadas en Kubernetes #
Cada CIF se ejecuta sobre una plataforma Kubernetes gestionada — EKS, AKS, GKE u OpenShift sobre un CTPP designado, o una alternativa gestionada por proveedor. El equipo de plataforma opera un único patrón de clúster dorado con desviación controlada: nodos a partir de una imagen base documentada; aislamiento por espacio de nombres por equipo; perfil restringido de pod-security-standards; políticas de red; inyección de service mesh (Istio o Linkerd) para autenticación y observabilidad entre servicios. Los nuevos servicios se incorporan a la vía pavimentada mediante un flujo de incorporación basado en plantillas que produce la entrada del registro del Article 8 como artefacto de despliegue.
2. Portal de desarrollador estilo Backstage #
Un portal de desarrollador central — el Backstage ⧉ de código abierto de Spotify es la implementación de referencia, con varias alternativas empresariales — proporciona el sistema de registro de qué se ejecuta dónde. El catálogo enumera cada servicio, propietario, dependencia, clasificación de criticidad, runbook y rotación de guardia. El portal se entrelaza con el registro del Article 8: cada entrada del catálogo se mapea a una entrada del registro; las entradas sin referencias al registro provocan fallo de CI; las entradas del registro sin presencia en el catálogo disparan alertas preventivas frente al supervisor.
3. Despliegue GitOps mediante ArgoCD o Flux #
El despliegue en producción se ejecuta mediante un controlador GitOps — ArgoCD o Flux es el estándar de producción en 2026 — que reconcilia un estado declarativo versionado en Git con el clúster en ejecución. El kubectl apply manual está deshabilitado; la única vía a producción es una pull request fusionada. El repositorio Git es el rastro de auditoría; los supervisores que pidan "muéstrame la configuración del servicio X en la fecha Y" obtienen una etiqueta de Git, no una captura de pantalla.
4. Open Policy Agent en admisión #
Open Policy Agent (OPA) se sitúa en la cadena de admisión del clúster aplicando la política de plataforma: cumplimiento del perfil pod-security, procedencia de la imagen, límites de recursos, presencia de política de red, replicación adecuada al nivel de criticidad, ubicación en subregión bajo restricciones de nube soberana. Las políticas se versionan en Git y se gestionan como cambio junto con las configuraciones del servicio. Los despliegues rechazados generan justificaciones revisables que alimentan el paquete de evidencia de gestión del cambio.
5. OpenTelemetry de extremo a extremo #
Cada servicio emite trazas, métricas y registros de OpenTelemetry. El equipo de plataforma opera un pipeline centralizado de observabilidad — típicamente Tempo o Jaeger para trazas, Prometheus para métricas, Loki u OpenSearch para registros — que muestra la salud de los CIF de extremo a extremo, el mapeo de dependencias y las entradas para la clasificación de incidentes. La ventana de clasificación de 4 horas del Article 18 arranca con la detección; el pipeline OTel acorta la ruta desde detección a clasificación hasta convertirla en una consulta, no en una reunión de triaje.
La nube soberana como ingeniería, no como marketing #
La estrategia de nube soberana en 2026 debe responder a cuatro preguntas específicas de externalización Schrems II + DORA + EBA:
- ¿Dónde se procesan y almacenan los datos? Ubicación en Estado miembro de la UE; subregión para los flujos de alta criticidad; compromisos de residencia de datos por escrito.
- ¿Quién tiene acceso legal a los datos? Operaciones únicamente con empleados locales; solicitudes de acceso de gobiernos extranjeros sometidas a procedimiento judicial local; respuesta probada a solicitudes de acceso legítimo.
- ¿Cuál es el perfil de sustituibilidad? Evaluación de sustituibilidad del ¶81 de EBA/GL/2019/02; ejecución de salida probada; proveedor alternativo identificado y contratado (o motivos documentados de por qué no es viable).
- ¿Cuál es el modelo de soberanía técnica? Claves controladas por el cliente; separación criptográfica; plano de gestión soberano; cadena de suministro auditable.
Las opciones de proveedor en 2026 que abordan estas preguntas:
- AWS European Sovereign Cloud (anunciada en 2023, disponibilidad general prevista para el segundo semestre de 2026): región física operada por una filial de AWS residente en la UE; operaciones y soporte residentes en la UE; claves controladas por el cliente mediante el patrón KMS-XKS. Pendiente de alinear el contenido contractual del DORA Article 28 en 2026.
- Microsoft EU Data Boundary (disponibilidad general en 2024) + Bleu (Capgemini + Orange + Microsoft, solo Francia): la Data Boundary mantiene los datos de clientes de la UE en regiones de la UE; Bleu es la nube soberana francesa alineada con SecNumCloud que opera la pila Microsoft Azure bajo control operativo francés.
- Asociaciones soberanas de Google Cloud: Thales / S3NS en Francia (equivalente a Bleu); T-Systems en Alemania.
- Oracle EU Sovereign Cloud (disponibilidad general en 2023): patrón de doble región (Fráncfort + Madrid) con operaciones residentes en la UE; conformidad limpia con Schrems II.
- Proveedores alineados con Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): proveedores nativos de la UE con etiquetado Gaia-X; menor escala y ecosistema que los hyperscalers, pero sin exposición a la Foreign Intelligence Surveillance Act.
La decisión estratégica rara vez es binaria. Los bancos de nivel 1 suelen ejecutar una configuración de hyperscaler con Data Boundary para el grueso de las cargas de trabajo, una opción de nube soberana para flujos de alta sensibilidad designados (por ejemplo, sistemas de gestión de casos de PBC / sanciones que manejan datos personales de residentes en la UE) y una ruta de contingencia y sustituibilidad probada anualmente bajo el DORA Article 28.
Ejecución de salida probada #
Los apartados 113-117 de EBA/GL/2019/02 ⧉ son las disposiciones de estrategia de salida. El texto es explícito sobre lo que se exige: "Las entidades y entidades de pago deben asegurarse de que pueden salir de los acuerdos de externalización sin interrupción indebida de sus actividades de negocio… Las estrategias de salida también deben documentarse y probarse como parte de las revisiones periódicas de los acuerdos de externalización".
La expectativa supervisora en 2026 es una prueba anual de ejecución de salida de extremo a extremo para cada CIF dependiente de un CTPP designado. Los ejercicios de simulacro y las revisiones documentales son insuficientes. La prueba debe producir:
- Medición de tiempo hasta la restauración: tiempo real transcurrido desde la declaración de salida hasta la restauración de la carga de trabajo en el proveedor alternativo, frente al objetivo de RTO derivado del BIA.
- Evidencia de portabilidad de datos: exportación probada de datos desde el origen, validada frente a la ruta de importación del proveedor de destino, con evidencia de conciliación.
- Equivalencia funcional: carga de trabajo probada ejecutándose en el proveedor alternativo con SLO equivalentes.
- Evidencia de coste: coste de ejecución de salida documentado frente a la hipótesis de coste de restauración de la planificación de contingencia de la institución.
El primer intento de prueba de salida de extremo a extremo para un CIF revela típicamente una brecha de entre 5 y 10 veces entre el RTO documentado y el RTO real. Cerrar esa brecha es un trabajo de ingeniería de meses. Los bancos que la descubren durante una inspección supervisora en lugar de durante su propio ciclo anual de pruebas se enfrentan a un ciclo de hallazgos del T3 que podrían haber evitado.
Objetivos de RTO / RPO a partir del inventario de CIF #
Cada función crítica o importante se asigna a una clasificación por niveles derivada del análisis de impacto en el negocio de la institución. El nivel determina los objetivos de RTO y RPO que el equipo de ingeniería de plataforma se compromete a entregar.
| Nivel | Ejemplos | RTO | RPO |
|---|---|---|---|
| Nivel 1 (misión crítica) | Conectividad RTGS (CHAPS / T2 / Fedwire), autorización de pagos minoristas, autenticación del cliente para canales digitales | 2 horas | 15 minutos |
| Nivel 2 (crítico) | Filtrado de PBC / sanciones, pipelines de detección de fraude, autorización de cajeros, procesamiento de pagos por lotes | 4 horas | 1 hora |
| Nivel 3 (importante) | Reporting y remisión regulatoria, bases de conocimiento de cara al cliente, plataformas internas de colaboración | 24 horas | 4 horas |
| Nivel 4 (no crítico) | Sistemas internos de RR. HH., herramientas de marketing, reporting interno sin cara al cliente | 72 horas | 24 horas |
Estas cifras son ilustrativas — el BIA de la institución produce las suyas. El entregable de ingeniería de plataforma es una capacidad probada por regresión para cumplir los objetivos derivados del BIA, evidenciada mediante pruebas automatizadas de DR por servicio y validada mediante la prueba anual de ejecución de salida para los CIF dependientes de CTPP.
Qué implica esto por tipo de banco #
Bancos sistémicamente importantes a escala global #
El problema duro es la escala entre líneas de negocio: miles de servicios, cientos de CIF, múltiples exposiciones a CTPP designados entre productos, jurisdicciones y perfiles de resiliencia. La inversión es la capacidad central de ingeniería de plataforma — vías pavimentadas en Kubernetes, portal Backstage, GitOps, OPA, OTel — que produce la conciliación del registro del Article 8, el mapa de concentración CTPP y la capacidad de ejecución de salida CIF a CIF sin construcciones a medida por línea de negocio.
Bancos universales y medianos #
La inversión en ingeniería de plataforma está justificada en este nivel, pero el alcance es restringido: elige los dos o tres CIF de mayor criticidad, construye el patrón de vía pavimentada en torno a ellos y acepta que el resto del parque heredado continúa con los controles existentes a medio plazo. El posicionamiento supervisor pesa más que la amplitud de la plataforma — poder evidenciar la integridad del registro del DORA Article 8 y la salida probada para los tres CIF principales cubre las preocupaciones primarias del supervisor.
Bancos regionales y de menor tamaño #
Selección de proveedor antes que construcción interna. Elige un proveedor de plataforma bancaria cuya arquitectura nativa Kubernetes esté documentada, cuya integración con el registro del Article 8 venga de serie y cuyos compromisos de contenido contractual del DORA Article 28 sean claros. La capacidad de ingeniería interna se concentra en configuración, monitorización y respuesta a incidentes — no en la construcción de la plataforma.
Fintechs, PSP y proveedores SaaS que prestan servicio a bancos #
La pregunta de producto para los proveedores que venden a bancos de la UE en 2026 es si la plataforma produce las entradas del registro del Article 8 y el contenido contractual del DORA Article 28 que la función de cumplimiento del banco necesita. Los proveedores con salidas estructuradas ganan los contratos empresariales; los proveedores con plantillas en PDF pierden frente a competidores con JSON estructurado.
Conclusión #
La resiliencia en la nube bajo DORA está en fase de auditoría. Las decisiones de ingeniería de plataforma tomadas entre 2024 y 2025 son las que el ciclo supervisor de 2026 examina. Las instituciones que parecen creíbles ante el BCE y la EBA en 2026-2028 son las que operan vías pavimentadas en Kubernetes con portales estilo Backstage y despliegue GitOps bajo admisión de Open Policy Agent con OpenTelemetry de extremo a extremo — produciendo la evidencia del registro del Article 8 como artefacto de despliegue y la evidencia de ejecución de salida probada como ciclo anual, no como respuesta a una solicitud supervisora.
Las instituciones que no hicieron esas inversiones descubrirán si su equipo de cumplimiento de segunda línea es capaz de absorber la primera ronda de hallazgos supervisores antes de que llegue la segunda.
Mide la plataforma como mides cualquier programa operativo: cobertura de vía pavimentada, tasa de conciliación del registro, puntuación de concentración CTPP, tiempo de salida probado frente al objetivo de RTO, tiempo medio de clasificación del Article 18, tasa de cierre TLPT. Evidencia a la velocidad del pipeline; paquetes documentales solo cuando el supervisor los pida.
Preguntas frecuentes #
¿Sigue la resiliencia en la nube bajo DORA en fase de preparación en 2026?
No. DORA está en aplicación activa desde el 17 de enero de 2025. El régimen de designación CTPP de los Articles 28-44 se está abriendo durante 2025-2026. Los hallazgos del examen del BCE sobre la gestión del riesgo TIC del Article 6 y la integridad del registro del Article 8 aterrizaron en múltiples instituciones de nivel 1 en el T4 de 2025. La pregunta supervisora de 2026 es la evidencia específica de examen por institución, no la preparación regulatoria.
¿Qué proveedores de nube están designados como CTPP?
Las ESA publican las decisiones de designación en sus webs. Las instituciones dentro o cerca del perímetro en 2026 incluyen AWS, Microsoft (Azure), Google (GCP), Salesforce y un pequeño número de otros, en función de la cuota de mercado en servicios financieros por Estado miembro. Los bancos supervisados sobre esos proveedores afrontan las expectativas supervisoras correspondientes sobre cómo gestionan esa dependencia.
¿Elimina la nube soberana la necesidad del contenido contractual del DORA Article 28?
No. La nube soberana aborda la dimensión Schrems II + residencia de datos; el contenido contractual del DORA Article 28 es una obligación independiente que aplica con independencia de dónde residan los datos. El contrato del proveedor de nube soberana debe seguir cubriendo accesibilidad a los datos, seguridad, residencia, derechos de auditoría, estrategias de salida y continuidad según el Article 28.
¿Cuál es el entregable de ingeniería que demuestra la resiliencia en la nube bajo DORA?
Cinco primitivas de ingeniería de plataforma entrelazadas: vías pavimentadas en Kubernetes (clúster gestionado con desviación controlada por política), portal de desarrollador estilo Backstage (catálogo que concilia con el registro del Article 8), despliegue GitOps (ArgoCD o Flux), Open Policy Agent en admisión, OpenTelemetry de extremo a extremo. Evidencia a la velocidad del pipeline en lugar de en el momento del examen.
¿Con qué frecuencia hay que probar la ejecución de salida?
Prueba anual de ejecución de salida de extremo a extremo por cada CIF dependiente de un CTPP designado. Los ejercicios de simulacro y las revisiones documentales son insuficientes. La prueba debe producir tiempo hasta la restauración, evidencia de portabilidad de datos, equivalencia funcional y evidencia de coste — medidos frente a los objetivos de RTO y RPO derivados del BIA.
Referencias #
- Unión Europea, (2022). Reglamento (UE) 2022/2554 — Reglamento de Resiliencia Operativa Digital (DORA) ⧉.
- Autoridad Bancaria Europea, (2019). EBA/GL/2019/02 — Directrices sobre acuerdos de externalización ⧉.
- Autoridad Bancaria Europea, (2026). Reglamento de Resiliencia Operativa Digital ⧉.
- Autoridades Europeas de Supervisión, (2024). Informe final sobre las ITS relativas al Registro de Información bajo DORA ⧉.
- Supervisión Bancaria del BCE, (2025). Prioridades supervisoras 2026-28 ⧉.
- Banco Central Europeo, (2024). Marco TIBER-EU ⧉.
- ENISA, (2024). Esquema Europeo de Ciberseguridad para Servicios en la Nube (EUCS) ⧉.
- Spotify, (2020-2024). Portal de desarrollador Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Última revisión .
Última revisión .