Compliance10 min de leitura

DORA para provedores de infraestrutura: o que realmente exige

DORA não é uma lista de verificação de compliance. É uma especificação de sistemas com implicações arquitetônicas para determinismo, rastreabilidade e resiliência.

DORA para Provedores de Infraestrutura Financeira: O Que Você Realmente Precisa Construir

Equipes de compliance escrevem políticas. Equipes de engenharia constroem sistemas. Na maioria das fintechs, os dois produzem documentos separados, apresentam para audiências separadas e raramente se reconciliam. DORA força a reconciliação.

A Lei de Resiliência Operacional Digital (Regulamento 2022/2554) está em vigor desde 17 de janeiro de 2025. Aplica-se a entidades financeiras em toda a UE, bancos, instituições de pagamento, instituições de dinheiro eletrônico, firmas de investimento. Mas também alcança seus provedores de tecnologia. O Artigo 15 estabelece requisitos de supervisão para "provedores de serviços TIC terceiros críticos." Se você constrói infraestrutura da qual entidades reguladas dependem, você está no escopo. Não como algo desejável. Como uma expectativa regulatória que seus clientes devem cumprir.

A maioria das fintechs lê DORA como um exercício de políticas: atualizar o registro de riscos, adicionar uma seção à narrativa de SOC 2, treinar a equipe. Isso perde o ponto. DORA é uma especificação de sistemas. Define propriedades arquitetônicas que sua tecnologia deve exibir. Políticas descrevem intenção. Arquitetura entrega capacidade.

Cinco Requisitos Arquitetônicos Que a Maioria das Fintechs Ignora

DORA abrange 64 artigos em 9 capítulos. Nem todos têm implicações arquitetônicas. Cinco têm.

1. Sistemas Determinísticos (Art. 5-6: Gestão de Risco TIC)

DORA requer que entidades financeiras "identifiquem, classifiquem e documentem adequadamente todas as funções de negócio suportadas por TIC" e mantenham sistemas que sejam "confiáveis e resilientes." Em termos de engenharia: seu sistema deve se comportar previsivelmente sob todas as condições, incluindo falhas.

O que isso significa para a arquitetura:

Sem pausas de coleta de lixo durante janelas de settlement. Um evento stop-the-world do GC durante um lote de pagamentos é uma falha não determinística que o framework de riscos de DORA requer que você avalie e mitigue.
Caminhos de código auditáveis. Um auditor externo deve poder rastrear uma transação específica desde a ingestão da API até o commitment no ledger. Se o caminho depende de condições de runtime que não são registradas, o sistema não está adequadamente documentado.
Orçamentos de recursos estáticos. Uso de memória, pools de threads, limites de conexão, todos limitados e previsíveis na inicialização. Um crash por falta de memória durante pico de carga é uma falha de resiliência.

Nada disso requer uma tecnologia específica. Requerem disciplina arquitetônica. Um sistema construído em qualquer linguagem pode satisfazer esses requisitos, se a equipe projetar para eles explicitamente.

2. Superfície de Ataque Mínima (Art. 9: Proteção e Prevenção)

O Artigo 9 requer "medidas de proteção e prevenção" incluindo "a segurança dos sistemas de redes e informação." A medida de proteção mais eficaz em software não é um firewall nem uma biblioteca de criptografia. É uma árvore de dependências pequena.

Cada dependência externa é um vetor de ataque potencial. O ecossistema npm demonstrou isso repetidamente: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022). Cada incidente foi um ataque à cadeia de suprimentos que afetou milhares de projetos downstream.

A comparação de dependências é contundente:

Stack	Deps externas	Deps transitivas	Esforço de auditoria
Serviço Node.js típico	80-200	1.000-5.000+	Muito alto, praticamente impossível auditar cada pacote
Serviço Go	20-50	50-150	Moderado, gerenciável com ferramentas
Serviço Rust	15-40	50-120	Moderado, cargo-audit cobre CVEs conhecidos
Serviço Zig	5-15	15-30	Baixo, cada dependência pode ser revisada individualmente

DORA não obriga uma linguagem específica. Obriga que você possa avaliar seu risco de cadeia de suprimentos. Se sua contagem de dependências transitivas é 5.000, você não pode honestamente afirmar tê-lo avaliado. O esforço de auditoria excede o que qualquer equipe pode sustentar.

Recomendação concreta: conte suas dependências transitivas. Execute npm ls | wc -l ou o equivalente para seu stack. Se o número excede o que sua equipe de segurança pode revisar anualmente, você tem uma exposição sob DORA Art. 9.

3. Rastreabilidade Completa (Art. 11-12: Resposta e Recuperação)

Os Artigos 11 e 12 requerem "gestão estrita de incidentes relacionados a TIC" com "planos de resposta e recuperação." Isso não é sobre ter um runbook. É sobre rastreabilidade arquitetônica: a capacidade de reconstruir o histórico completo de qualquer operação após uma falha.

O que a rastreabilidade requer:

IDs de correlação. Cada operação que altera estado carrega um identificador único que se propaga por cada serviço que toca. Um auditor pode rastrear um pagamento do início ao settlement, ou à compensação, a partir de um único ID.
Execução journalizada. Cada passo de um processo multi-passo é registrado antes da execução. Se o processo é interrompido (crash, timeout, queda de provedor), o journal indica exatamente onde parou e o que já foi commitado.
Recuperação determinística. "Recuperação" significa retomar do ponto exato de interrupção, não retentar desde o início, não reproduzir com efeitos colaterais potencialmente diferentes. O journal é o mecanismo de recuperação.

Os motores de execução durável fornecem as três propriedades arquitetonicamente. O journal do workflow É a trilha de auditoria. O ID de correlação É o ID do workflow. A recuperação É a reprodução do journal. Você não parafusa rastreabilidade no sistema depois, o modelo de execução a produz como subproduto.

As alternativas tradicionais, filas de retry, dead-letter queues, eventos de compensação saga, podem alcançar resultados similares, mas a rastreabilidade deve ser engenheirada separadamente. O journal é implícito na execução durável; é explícito (e frequentemente incompleto) em arquiteturas dirigidas por eventos.

4. Avaliação de Risco de Terceiros (Art. 15: Risco TIC de Terceiros)

O Artigo 15 requer que entidades financeiras avaliem e monitorem os riscos apresentados por seus provedores TIC terceiros. Esta obrigação flui downstream: seus clientes devem avaliar você, e você deve ser avaliável.

Ser avaliável significa:

Inventário de dependências publicado. Não "usamos ferramentas padrão da indústria." Uma lista concreta: estas são nossas dependências, estas são suas versões, este é o grafo transitivo.
Mecanismos de recuperação documentados. Se seu serviço cai, o que acontece com transações em voo? São perdidas? Retentadas? Enfileiradas duravelmente? A resposta deve ser arquitetônica, não aspiracional.
Evidência de resposta a incidentes. Não um documento de políticas que diz "responderemos dentro de 4 horas." Evidência de que seu sistema detecta, registra e possibilita a investigação de incidentes operacionais. Logs de auditoria com hash SHA-256 encadeado que não podem ser retroativamente modificados são um sinal forte.

A posição mais forte: facilite sua avaliação. Publique sua contagem de dependências. Documente sua arquitetura. Mostre seu formato de trilha de auditoria. Quanto mais rápido a equipe de compliance de um cliente puder avaliá-lo, mais rápido você fecha o negócio.

5. Resiliência Testável (Art. 24-27: Testes de Resiliência)

Os Artigos 24 a 27 requerem "testes de resiliência operacional digital" incluindo, para entidades financeiras significativas, "testes de penetração guiados por ameaças." Para provedores de infraestrutura, a implicação é: seu sistema deve ser testável sob condições de falha.

Isso vai além de testes unitários e testes de integração. Testes de resiliência alinhados com DORA significam:

Cenários de falha reproduzíveis. Você pode simular uma falha de banco de dados, uma partição de rede, um timeout de provedor, e verificar que o sistema se comporta corretamente? Se o cenário de falha não é reproduzível, o teste não é significativo.
Simulação determinística. O padrão ouro: injetar milhares de combinações de falhas (crashes, partições, desvio de relógio, corrupção de disco) em um ambiente simulado e verificar a correção. Se o sistema é determinístico, cada execução de simulação produz resultados idênticos para a mesma semente, tornando bugs reproduzíveis e corrigíveis.
Verificação contínua. A resiliência não é um exercício trimestral. O sistema deve ser continuamente testado sob condições de falha como parte do pipeline CI/CD. Cada release é validado contra os mesmos cenários de falha.

Poucas organizações alcançam testes de simulação determinística. Mas a direção é clara: DORA recompensa arquiteturas que são inerentemente testáveis, determinísticas, reproduzíveis e suscetíveis a injeção automatizada de falhas.

O Que "Compatível com DORA" Realmente Significa

Um provedor de tecnologia não pode afirmar "compatível com DORA." DORA se aplica a entidades financeiras reguladas e sua supervisão de provedores TIC. Não existe certificação DORA para produtos de software.

O que você pode fazer:

Demonstrar alinhamento arquitetônico. Mostrar que seu design aborda os artigos listados acima. Mapear suas decisões de arquitetura para requisitos específicos de DORA. Isso é o que as equipes de compliance dos seus clientes precisam durante a avaliação de fornecedores.
Publicar sua evidência. Inventário de dependências. Mecanismos de recuperação. Formato de trilha de auditoria. Metodologia de testes de resiliência. Disponibilize isso em um centro de confiança ou página de documentação de segurança, não atrás de uma chamada comercial.
Usar linguagem honesta. "Projetado para alinhamento com DORA" é defensável. "Compatível com DORA" não é. "Arquitetonicamente alinhado com DORA Art. 11-12" é preciso. "Atende todos os requisitos de DORA" é uma afirmação que você não pode fazer.

A honestidade é o sinal de confiança. Um provedor que reconhece o que DORA requer e demonstra como sua arquitetura o aborda, sem exagerar, é mais credível do que um que carimba "compatível com DORA" em uma landing page.

Infraestrutura financeira é um negócio de confiança. As regulações existem porque a confiança deve ser verificável. Construa sistemas que sejam verificáveis por construção. Documente o que construiu. Deixe a arquitetura falar por si mesma.

Fontes:

DORA, Regulamento (UE) 2022/2554, Art. 5-6 (Gestão de Risco TIC), Art. 9 (Proteção e Prevenção), Art. 11-12 (Resposta e Recuperação), Art. 15 (Risco de Terceiros), Art. 24-27 (Testes de Resiliência)
EUR-Lex: 2022/2554
Incidentes de cadeia de suprimentos npm: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022)