O banking cloud-native em 2026 está em fase de auditoria DORA. O Regulamento (UE) 2022/2554 ⧉ está em vigor desde 17 de janeiro de 2025. O regime de designação do provedor terceiro crítico (CTPP) sob os Artigos 28-44 vem se abrindo ao longo de 2025-2026, com AWS, Microsoft (Azure), Google (GCP) e Salesforce dentro ou perto do perímetro de designação. As Autoridades Europeias de Supervisão (EBA, EIOPA, ESMA) publicaram os RTS e ITS finais sobre o Registro de Informações ⧉ em 2024. A equipe de Supervisão Bancária do BCE tem programas explícitos sobre preparação para disrupção de nuvem e testes de penetração orientados por ameaças nas prioridades supervisoras 2026-28 ⧉. A pergunta institucional não é se a estratégia de nuvem deve estar alinhada ao DORA — isso está resolvido — mas se as primitivas de engenharia de plataforma da instituição produzem evidência na velocidade do pipeline de deploy e não em PDFs montados na semana do exame.
Resumo Executivo / Pontos-Chave
- Resiliência de nuvem DORA em execução ativa desde 17 de janeiro de 2025. Artigos 6, 8, 18, 26 e 28-44 todos em vigor. As constatações supervisoras da primeira onda de exames chegaram no 4T 2025. O enquadramento de "preparação" está dois ciclos atrás.
- Regime de designação CTPP em abertura. AWS, Microsoft, Google, Salesforce — dentro ou perto. A designação confere às ESAs direitos diretos de fiscalização incluindo requisições de informação, inspeções in loco e recomendações supervisoras.
- Engenharia de plataforma é o entregável. Paved roads Kubernetes (EKS / AKS / GKE / OpenShift), portal de desenvolvedor estilo Backstage, GitOps (ArgoCD ou Flux), Open Policy Agent na admissão, OpenTelemetry ponta a ponta. Cinco primitivas nomeadas; qualquer ausência é uma constatação.
- Nuvem soberana é engenharia, não marca. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — cada uma trata uma dimensão específica de Schrems II + Artigo 28 do DORA; nenhuma é resposta pronta.
- Evidência testada de saída exigida. EBA/GL/2019/02 parágrafos 81 e 113-117. Tabletop trimestral é insuficiente; supervisores esperam teste anual ponta a ponta de execução de saída para cada função crítica ou importante.
- RTO / RPO a partir do inventário de CIF. Tier 1: 2h / 15min. Tier 2: 4h / 1h. Tier 3: 24h / 4h. Derivados da análise de impacto no negócio, não da capacidade da equipe de plataforma.
Por que a Resiliência de Nuvem DORA Está em Fase de Auditoria #
Três razões pelas quais o enquadramento de "preparação" está errado em 2026.
Primeiro, o cronograma. O DORA foi publicado em dezembro de 2022. O período de aplicação de 24 meses se encerrou em 17 de janeiro de 2025. Os RTS e ITS finais das ESAs — incluindo o ITS sobre o Registro de Informações usado para designação de CTPP — foram publicados ao longo de 2024. A primeira onda de exames supervisores correu durante 2025; constatações sobre a integralidade do framework de gestão de risco TIC do Artigo 6 e sobre a reconciliação do registro do Artigo 8 chegaram no 4T 2025 em múltiplas instituições tier-1.
Segundo, o regime de designação CTPP. O Artigo 31 fixa os critérios para designação como provedor terceiro crítico: impacto sistêmico em caso de falha, criticidade dos serviços prestados, escala e complexidade dos serviços, substituibilidade. As ESAs mantêm o registro e publicam as decisões de designação. AWS, Microsoft (Azure), Google (GCP) e Salesforce estão dentro ou perto do perímetro de designação, conforme a participação de mercado em serviços financeiros por Estado-membro. A designação confere ao supervisor líder (uma das ESAs, alocada por provedor) autoridade direta de fiscalização: requisições de informação sob o Artigo 37, inspeções in loco sob o Artigo 38, recomendações sob o Artigo 35 e o regime de divulgação pública sob o Artigo 41. Os bancos supervisionados sobre esses CTPPs estão sujeitos a expectativas supervisoras correspondentes sobre como gerenciam essa dependência designada.
Terceiro, as prioridades supervisoras 2026-28 do BCE. O documento de prioridades nomeia dois programas explícitos que afetam diretamente o banking cloud-native: preparação para grandes disrupções de serviço de nuvem (cenários supervisores modelados testam a capacidade da instituição de absorver uma indisponibilidade prolongada de um CTPP designado) e TLPT alinhado ao TIBER-EU (cada exercício TIBER-EU escopa as funções críticas e importantes da instituição, o que agora inclui serviços hospedados em nuvem pública). A onda de exames de 2026 produzirá constatações em ambos.
O enquadramento para 2026 não é "o DORA vem aí"; é "as constatações de exame DORA estão chegando à caixa de entrada da sua instituição, e as decisões de engenharia de plataforma tomadas entre 2024-2025 são o que o supervisor examina nessas constatações".
A Arquitetura do Índice 2026 #
| Camada do Índice | Como é "Pronto" | Métrica de Prontidão | Modo de Falha |
|---|---|---|---|
| Maturidade de plataforma | >80% das cargas em plataforma Kubernetes paved road (EKS / AKS / GKE / OpenShift) com admissão por policy-as-code, deploy GitOps, teste de DR automatizado | % de CIFs em plataforma paved road; contagem de deploys-sombra; tempo médio para incorporar um novo serviço à plataforma | Plataformas-sombra com controles inconsistentes; CIFs rodando em infraestrutura não pavimentada, invisíveis à reconciliação do registro do Artigo 8 |
| Integridade do registro do Artigo 8 | O Registro de Informações reconcilia automaticamente com o consumo de APIs de terceiros da plataforma + bill-of-materials de nuvem; classificação de criticidade consistente com o inventário de CIF da instituição | % de entradas do registro reconciliadas à telemetria da plataforma; contagem de entradas órfãs; checagem de integridade do perímetro CTPP | As ESAs identificam uma dependência de CTPP designada que a instituição deixou de declarar sob o Artigo 8; constatação individual e consequência no perímetro CTPP |
| Concentração em nuvem | Funções críticas mapeadas para provedores de nuvem E sub-regiões E serviços E avaliação de substituibilidade; exposição correlacionada entre CIFs quantificada | Score de concentração por CIF; exposição correlacionada entre CIFs que compartilham uma região de CTPP designada | Uma única queda de IAM em AWS us-east-1 derruba quatro CIFs que a instituição supunha provisionadas de forma independente |
| Capacidade de saída testada | Teste anual ponta a ponta de execução de saída para cada CIF dependente de CTPP designado; RTO / RPO documentado cumpre metas derivadas da BIA; trilha de portabilidade de dados testada | Taxa de aprovação de teste por CIF; tempo médio de execução de saída vs meta de RTO; latência da trilha de portabilidade de dados | Plano de saída que existe só em PDF; tabletop diz 4h de RTO, teste real mostra 48h na primeira tentativa |
| Observabilidade + notificação de incidentes | Traces OpenTelemetry ponta a ponta entre serviços; auxiliar automatizado de classificação de 4 horas do Artigo 18 integrado à plataforma de gestão de incidentes | % de tráfego de CIF coberto por traces OTel; tempo médio da detecção do incidente até a decisão de classificação do Artigo 18 | Incidente grave classificado fora da janela de 4 horas porque a determinação de criticidade exigiu uma reunião de triagem; constatação do Artigo 18 |
| Integração TLPT | Escopo TLPT derivado do inventário de CIF e atualizado continuamente; constatações realimentam o policy-as-code da plataforma; constatações encerradas produzem pacotes de evidência prontos para o supervisor | Taxa de encerramento de constatações TLPT; tempo de ciclo entre constatação e atualização de política | TLPT descobre uma vulnerabilidade que a equipe de engenharia de plataforma da instituição não consegue corrigir em menos de dois ciclos de release |
Sinais Atuais para Acompanhar #
| Sinal | O que Significa para os Bancos | Fonte |
|---|---|---|
| DORA em execução ativa desde 17 de janeiro de 2025 | Constatações supervisoras de primeira onda chegaram no 4T 2025; segunda onda esperada ao longo do 2S 2026 | EUR-Lex ⧉ |
| Designação CTPP em abertura ao longo de 2025-2026 | AWS, Microsoft, Google, Salesforce dentro ou perto do perímetro; designação confere às ESAs direitos diretos de fiscalização | EBA ⧉ |
| Prioridades supervisoras 2026-28 do BCE nomeiam disrupção de nuvem explicitamente | Cenários supervisores modelados testam capacidade de absorver indisponibilidade prolongada de CTPP designado | Supervisão Bancária do BCE ⧉ |
| TIBER-EU alinhado ao Artigo 26 do DORA | Escopo TLPT cobre funções críticas / importantes incluindo serviços hospedados em nuvem | TIBER-EU do BCE ⧉ |
| Diretrizes de terceirização da EBA (EBA/GL/2019/02) se conectam ao Artigo 28 do DORA | Presença substantiva (¶64), avaliação de substituibilidade (¶81), estratégia de saída (¶113-117) — os parágrafos que os supervisores efetivamente testam | EBA ⧉ |
| Esquema EU Cloud Services (EUCS) em progresso | Futuro esquema de certificação de nuvem soberana sob o EU Cybersecurity Act; rascunho publicado pela ENISA | ENISA EUCS ⧉ |
Engenharia de Plataforma: As Cinco Primitivas Nomeadas #
A maturidade cloud-native em 2026 se reduz a cinco primitivas de engenharia que se entrelaçam para produzir evidência supervisora na velocidade do pipeline de deploy. A falta de qualquer uma é uma constatação esperando para acontecer.
1. Paved Roads Baseadas em Kubernetes #
Cada CIF roda em uma plataforma Kubernetes gerenciada — EKS, AKS, GKE ou OpenShift em um CTPP designado, ou alternativa gerenciada por fornecedor. A equipe de plataforma opera um único padrão de cluster golden com desvio controlado: nós a partir de uma imagem base documentada; isolamento namespace-por-equipe; perfil pod-security-standards-restricted; políticas de rede; injeção de service mesh (Istio ou Linkerd) para autenticação e observabilidade entre serviços. Novos serviços entram na paved road por um fluxo de onboarding por template que produz a entrada de registro do Artigo 8 como artefato de deploy.
2. Portal de Desenvolvedor Estilo Backstage #
Um portal central de desenvolvedor — o Backstage ⧉ open-source da Spotify é a implementação de referência, com várias alternativas corporativas — provê o sistema de registro de o que roda onde. O catálogo lista cada serviço, owner, dependência, classificação de criticidade, runbook, escala de plantão. O portal se entrelaça com o registro do Artigo 8: cada entrada de catálogo mapeia para uma entrada do registro; entradas sem referência ao registro disparam falha em CI; entradas de registro sem presença no catálogo disparam alertas que se antecipam ao supervisor.
3. Deploy GitOps via ArgoCD ou Flux #
O deploy em produção corre por um controlador GitOps — ArgoCD ou Flux é o padrão de produção em 2026 — que reconcilia um estado declarativo versionado em Git ao cluster em execução. O kubectl apply manual fica desabilitado; o único caminho para produção é um pull request mergeado. O repositório Git é a trilha de auditoria; supervisores que pedem "me mostre a configuração do serviço X na data Y" recebem uma tag Git, não um screenshot.
4. Open Policy Agent na Admissão #
O Open Policy Agent (OPA) fica na cadeia de admissão do cluster impondo política de plataforma: conformidade ao perfil pod-security, proveniência de imagem, limites de recurso, presença de network policy, replicação adequada ao tier de criticidade, colocação por sub-região sob restrições de nuvem soberana. As políticas são versionadas em Git e gerenciadas como mudança junto às configurações de serviço. Deploys rejeitados produzem racionais auditáveis que alimentam o pacote de evidência de gestão de mudança.
5. OpenTelemetry Ponta a Ponta #
Cada serviço emite traces, métricas e logs OpenTelemetry. A equipe de plataforma opera um pipeline centralizado de observabilidade — tipicamente Tempo ou Jaeger para traces, Prometheus para métricas, Loki ou OpenSearch para logs — que expõe saúde de CIF ponta a ponta, mapeamento de dependências e entradas para classificação de incidentes. A janela de 4 horas para classificação do Artigo 18 começa na detecção; o pipeline OTel encurta o caminho da detecção até a classificação para uma consulta, e não para uma reunião de triagem.
Nuvem Soberana como Engenharia, Não como Marca #
A estratégia de nuvem soberana em 2026 precisa responder a quatro perguntas específicas de Schrems II + DORA + terceirização EBA:
- Onde os dados são processados e armazenados? Localização em Estado-membro da UE; sub-região para fluxos de alta criticidade; compromissos de residência de dados por escrito.
- Quem tem acesso legal aos dados? Operações apenas por funcionários locais; pedidos de acesso de governo estrangeiro sujeitos a processo judicial local; resposta testada a pedidos de acesso legal.
- Qual o perfil de substituibilidade? Avaliação de substituibilidade do EBA/GL/2019/02 ¶81; execução de saída testada; provedor alternativo identificado e contratado (ou documentação do motivo de não ser viável).
- Qual o modelo técnico de soberania? Chaves controladas pelo cliente; separação criptográfica; plano de gestão soberano; cadeia de suprimentos auditável.
As opções de fornecedor em 2026 que respondem a essas perguntas:
- AWS European Sovereign Cloud (anunciada em 2023, GA prevista para o 2S 2026): região física operada por subsidiária da AWS residente na UE; operações e suporte residentes na UE; chaves controladas pelo cliente via padrão KMS-XKS. Alinhamento de conteúdo contratual do Artigo 28 do DORA pendente em 2026.
- Microsoft EU Data Boundary (GA em 2024) + Bleu (Capgemini + Orange + Microsoft, apenas França): o Data Boundary mantém dados de clientes da UE em regiões da UE; o Bleu é a nuvem soberana francesa alinhada ao SecNumCloud rodando a stack Microsoft Azure sob controle operacional francês.
- Parcerias soberanas do Google Cloud: Thales / S3NS na França (equivalente ao Bleu); T-Systems na Alemanha.
- Oracle EU Sovereign Cloud (GA em 2023): padrão de região dupla (Frankfurt + Madrid) com operações residentes na UE; conformidade limpa com Schrems II.
- Provedores alinhados ao Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): provedores nativamente europeus com rotulagem Gaia-X; escala e ecossistema menores que os hyperscalers, mas sem exposição ao Foreign Intelligence Surveillance Act.
A decisão estratégica raramente é binária. Bancos tier-1 tipicamente rodam uma configuração hyperscaler-com-Data-Boundary para o grosso das cargas, uma opção de nuvem soberana para fluxos designados de alta sensibilidade (p. ex., sistemas de gestão de casos AML / sanções que tratam dados pessoais de residentes da UE) e uma trilha de substituibilidade de contingência testada anualmente sob o Artigo 28 do DORA.
Execução de Saída Testada #
Os parágrafos 113-117 da EBA/GL/2019/02 ⧉ são as disposições sobre estratégia de saída. O texto é explícito quanto ao exigido: "As instituições e instituições de pagamento devem assegurar que conseguem sair de acordos de terceirização sem disrupção indevida das suas atividades de negócio… As estratégias de saída também devem ser documentadas e testadas como parte das revisões regulares dos acordos de terceirização."
A expectativa supervisora em 2026 é teste anual ponta a ponta de execução de saída para cada CIF dependente de um CTPP designado. Exercícios de tabletop e revisões documentais são insuficientes. O teste tem de produzir:
- Medição de time-to-restore: tempo decorrido efetivo desde a declaração de saída até a restauração da carga no provedor alternativo, contra a meta de RTO derivada da BIA.
- Evidência de portabilidade de dados: exportação testada de dados a partir do primário, validada contra a trilha de importação do provedor de destino, com evidência de reconciliação.
- Equivalência funcional: carga testada rodando no provedor alternativo com SLOs equivalentes.
- Evidência de custo: custo documentado da execução de saída vs a hipótese de custo-de-restauração no planejamento de contingência da instituição.
A primeira tentativa de teste ponta a ponta de saída para um CIF tipicamente revela uma diferença de 5-10× entre o RTO documentado e o RTO real. Fechar essa diferença é trabalho de engenharia que leva meses. Bancos que descobrem isso durante uma inspeção supervisora, e não durante seu próprio ciclo anual de teste, encaram um ciclo de constatações no 3T que poderiam ter evitado.
Metas de RTO / RPO a Partir do Inventário de CIF #
Cada função crítica ou importante mapeia para uma classificação por tier derivada da análise de impacto no negócio da instituição. O tier dirige as metas de RTO e RPO que a equipe de engenharia de plataforma se compromete a entregar.
| Tier | Exemplos | RTO | RPO |
|---|---|---|---|
| Tier 1 (missão crítica) | Conectividade RTGS (CHAPS / T2 / Fedwire), autorização de pagamentos de varejo, autenticação de cliente para canais digitais | 2 horas | 15 minutos |
| Tier 2 (crítico) | Triagem AML / sanções, pipelines de detecção de fraude, autorização de ATM, processamento de pagamento em lote | 4 horas | 1 hora |
| Tier 3 (importante) | Reporte e submissão regulatória, bases de conhecimento voltadas ao cliente, plataformas internas de colaboração | 24 horas | 4 horas |
| Tier 4 (não crítico) | Sistemas de RH internos, ferramentas de marketing, reporte interno sem face para o cliente | 72 horas | 24 horas |
Os números são ilustrativos — a BIA da instituição produz os seus. O entregável da engenharia de plataforma é uma capacidade testada por regressão de cumprir as metas derivadas da BIA, evidenciada por teste de DR automatizado por serviço e validada pelo teste anual de execução de saída para CIFs dependentes de CTPP.
O que Isso Significa por Tipo de Banco #
Bancos Globais Sistemicamente Importantes #
O problema duro é escala entre linhas de negócio: milhares de serviços, centenas de CIFs, múltiplas exposições a CTPP designados em produtos, jurisdições e perfis de resiliência. O investimento é a capacidade central de engenharia de plataforma — paved roads Kubernetes, portal Backstage, GitOps, OPA, OTel — que produz a reconciliação do registro do Artigo 8, o mapa de concentração CTPP e a capacidade de execução de saída CIF a CIF sem construção sob medida por linha de negócio.
Bancos Universais e de Médio Porte #
O investimento em engenharia de plataforma se justifica nesse tier, mas o escopo é limitado: escolha os dois ou três CIFs de mais alta criticidade, construa o padrão paved road em torno deles, aceite que o estate legado continua sob os controles existentes no médio prazo. O posicionamento supervisor importa mais que a amplitude da plataforma — conseguir evidenciar a integridade do registro do Artigo 8 do DORA e a saída testada para os três principais CIFs cobre as preocupações primárias do supervisor.
Bancos Regionais e Menores #
Seleção de fornecedor em vez de build interno. Escolha um fornecedor de plataforma bancária cuja arquitetura Kubernetes-native esteja documentada, cuja integração com o registro do Artigo 8 esteja embutida e cujos compromissos de conteúdo contratual do Artigo 28 do DORA sejam claros. A capacidade de engenharia interna gira em torno de configuração, monitoramento e resposta a incidentes — não construção de plataforma.
Fintechs, PSPs e Provedores SaaS que Atendem Bancos #
A pergunta de produto para fornecedores que vendem para bancos da UE em 2026 é se a plataforma produz as entradas de registro do Artigo 8 e o conteúdo contratual do Artigo 28 do DORA que a função de compliance do banco precisa. Fornecedores com saídas estruturadas vencem deals corporativos; fornecedores com templates em PDF perdem para concorrentes com JSON estruturado.
Conclusão #
A resiliência de nuvem DORA está em fase de auditoria. As decisões de engenharia de plataforma tomadas entre 2024-2025 são o que o ciclo supervisor de 2026 examina. As instituições que parecem críveis ao BCE e à EBA em 2026-2028 são as que rodam paved roads Kubernetes com portais estilo Backstage e deploy GitOps sob admissão Open Policy Agent com OpenTelemetry ponta a ponta — produzindo evidência de registro do Artigo 8 como artefato de deploy e evidência testada de execução de saída como ciclo anual, e não como resposta a pedido supervisor.
As instituições que não fizeram esses investimentos descobrirão se sua equipe de compliance de segunda linha consegue absorver a primeira rodada de constatações supervisoras antes que a segunda chegue.
Meça a plataforma como mede qualquer programa operacional: cobertura de paved road, taxa de reconciliação do registro, score de concentração CTPP, tempo testado de saída vs meta de RTO, tempo médio de classificação do Artigo 18, taxa de encerramento TLPT. Evidência na velocidade do pipeline; pacotes documentais apenas quando o supervisor pede um.
Perguntas Frequentes #
A resiliência de nuvem DORA ainda está em fase de preparação em 2026?
Não. O DORA está em execução ativa desde 17 de janeiro de 2025. O regime de designação CTPP sob os Artigos 28-44 vem se abrindo ao longo de 2025-2026. Constatações de exame do BCE sobre gestão de risco TIC do Artigo 6 e integridade do registro do Artigo 8 chegaram em múltiplas instituições tier-1 no 4T 2025. A pergunta supervisora de 2026 é evidência específica de exame por instituição, não prontidão regulatória.
Quais provedores de nuvem estão designados como CTPPs?
As ESAs publicam decisões de designação em seus sites. As instituições dentro ou perto do perímetro em 2026 incluem AWS, Microsoft (Azure), Google (GCP), Salesforce e um pequeno número de outras conforme a participação de mercado em serviços financeiros por Estado-membro. Os bancos supervisionados sobre esses provedores enfrentam expectativas supervisoras correspondentes sobre como gerenciam essa dependência.
Nuvem soberana elimina a necessidade do conteúdo contratual do Artigo 28 do DORA?
Não. A nuvem soberana trata a dimensão Schrems II + residência de dados; o conteúdo contratual do Artigo 28 do DORA é obrigação separada que se aplica independentemente de onde os dados residam. O contrato do provedor de nuvem soberana ainda precisa cobrir acessibilidade de dados, segurança, residência, direitos de auditoria, estratégias de saída e continuidade conforme o Artigo 28.
Qual o entregável de engenharia que demonstra resiliência de nuvem DORA?
Cinco primitivas de engenharia de plataforma entrelaçadas: paved roads Kubernetes (cluster gerenciado com desvio controlado por política), portal de desenvolvedor estilo Backstage (catálogo reconciliando ao registro do Artigo 8), deploy GitOps (ArgoCD ou Flux), Open Policy Agent na admissão, OpenTelemetry ponta a ponta. Evidência na velocidade do pipeline em vez de em hora de exame.
Com que frequência a execução de saída precisa ser testada?
Teste anual ponta a ponta de execução de saída por CIF dependente de um CTPP designado. Exercícios de tabletop e revisões documentais são insuficientes. O teste tem de produzir time-to-restore, evidência de portabilidade de dados, equivalência funcional e evidência de custo — medidos contra as metas de RTO e RPO derivadas da BIA.
Referências #
- União Europeia, (2022). Regulamento (UE) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- Autoridade Bancária Europeia, (2019). EBA/GL/2019/02 — Diretrizes sobre acordos de terceirização ⧉.
- Autoridade Bancária Europeia, (2026). Digital Operational Resilience Act ⧉.
- Autoridades Europeias de Supervisão, (2024). Relatório final sobre o ITS do Registro de Informações sob o DORA ⧉.
- Supervisão Bancária do BCE, (2025). Prioridades supervisoras 2026-28 ⧉.
- Banco Central Europeu, (2024). Framework TIBER-EU ⧉.
- ENISA, (2024). Esquema de Cibersegurança da UE para Serviços de Nuvem (EUCS) ⧉.
- Spotify, (2020-2024). Portal de desenvolvedor Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Última revisão .
Última revisão .