NIS2 e DORA são marcos regulatórios da UE que afetam empresas brasileiras de duas formas distintas. Direta: se a empresa brasileira tem subsidiária ou prestação de serviços diretamente em território UE. Indireta (e bem mais comum): se a empresa brasileira é fornecedora de cliente final UE sujeito a NIS2 ou DORA, e o cliente final precisa documentar a cadeia de sub-processadores TIC. Em paralelo, o cenário regulatório brasileiro evoluiu rápido durante 2025-2026: as Resoluções CMN nº 5.274/2025 e BCB nº 538/2025, publicadas em 18 de dezembro de 2025 e vigentes desde 1º de março de 2026, elevaram significativamente o padrão de cibersegurança para bancos, cooperativas, instituições de pagamento e fintechs autorizadas pelo BCB. Para Q2 2026, fintechs brasileiras servindo cliente final brasileiro estão sob regime BCB 538; e fintechs brasileiras servindo cliente final UE estão sob BCB 538 mais o reflexo de DORA via cliente.
Este artigo conecta os três marcos: o que NIS2/DORA exigem em camada de email infrastructure, o que BCB 538/2025 exige para fintechs brasileiras, e onde se sobrepõem.
NIS2 em linguagem plana para senders brasileiros
NIS2 é a diretiva UE de segurança de redes e sistemas de informação (o “2” porque substitui a NIS de 2016). Aplica-se a “entidades essenciais e importantes” em 18 setores: energia, transporte, banca, saúde, infraestrutura digital, gestão de serviços TIC, fabricação, e outros. A maioria de SaaS B2B, a maioria de provedores de serviços gerenciados, a maioria de organizações de saúde e a maioria de entidades financeiras europeias estão cobertas.
O artigo relevante para infraestrutura email é o Artigo 21, que exige “medidas técnicas, operacionais e organizativas apropriadas e proporcionais para gerir os riscos colocados à segurança das redes e sistemas de informação”. Essa frase é deliberadamente ampla. Os detalhes de implementação vêm das transposições nacionais dos Estados-Membros e da orientação técnica emitida pelas autoridades competentes (BSI na Alemanha, ANSSI na França, INCIBE na Espanha).
Para empresa brasileira, NIS2 aplica indiretamente quando o cliente final UE precisa documentar fornecedores no inventário de sub-processadores. As exigências práticas que cascadam:
- Autenticação email (SPF, DKIM, DMARC) para comunicações enviadas, para evitar que seu domínio seja usado em phishing.
- Inventário de sub-processadores documentado, com jurisdição e DPA assinado.
- Procedimentos de notificação de incidentes, para que o cliente final UE possa cumprir os prazos NIS2 (24h alerta / 72h notificação / 1 mês relatório).
- Logging e monitoramento de sistemas email, para detecção e perícia.
DORA em linguagem plana para fintechs brasileiras
DORA é o Regulamento de Resiliência Operacional Digital, aplicável a entidades financeiras (bancos, empresas de serviços de investimento, seguros, provedores de serviços cripto-ativos, entidades de pagamento, etc.) desde o 17 de janeiro de 2025. Como regulamento (não diretiva), aplica-se diretamente nos 27 Estados-Membros UE sem necessidade de transposição.
Para fintech brasileira, DORA aplica indiretamente quando seu cliente final é entidade financeira UE sob DORA. Casos típicos que vimos durante 2025-2026:
Caso 1: SaaS de cobrança brasileiro vendendo a banco francês. O banco francês incluiu o SaaS brasileiro no registro de fornecedores TIC remetido às autoridades europeias em março de 2026. O banco francês exige cláusulas DORA no contrato (cooperação auditoria, plano de saída, portabilidade de dados, notificação de incidentes alinhada com prazos DORA).
Caso 2: SaaS de KYC brasileiro vendendo a corretora de seguros holandesa. A corretora exige documentação de continuidade operacional e backup geográfico. SaaS brasileiro com data center único em São Paulo precisou estabelecer backup secundário em região UE.
Caso 3: Plataforma de Open Finance brasileira com expansão UE. Para entrar em mercado UE, a plataforma teve que se autoreconhecer como sujeita a DORA e cumprir o pacote completo: marco de gestão de risco TIC, notificação de incidentes 4h/72h/1 mês, registro de provedores TIC, gestão de risco de terceiros.
A novidade brasileira: Resoluções BCB 538/2025 e CMN 5.274/2025
Em 18 de dezembro de 2025, BCB e CMN publicaram normativos que elevaram significativamente o padrão de cibersegurança para bancos, cooperativas de crédito, instituições de pagamento e fintechs autorizadas pelo BCB. Vigentes desde 1º de março de 2026.
A mudança estrutural: transição de modelo baseado em políticas declaratórias para modelo baseado em evidência técnica comprovável. O regulador passa a exigir não apenas a existência de controles formais, mas comprovação documentada de que estão implementados, operando e sendo monitorados.
O Art. 3º expandido: 14 procedimentos obrigatórios
A versão anterior (Resolução BCB nº 85/2021) exigia 5 procedimentos genéricos. A Resolução BCB nº 538/2025 expandiu para 14 procedimentos e controles obrigatórios, incluindo:
- Inventário e classificação de ativos TIC
- Controles de identidade e acesso (MFA obrigatório para acessos privilegiados)
- Cifragem em repouso e em trânsito para dados sensíveis
- Backup e plano de continuidade testado anualmente
- Monitoramento contínuo de eventos de segurança
- Resposta a incidentes com prazos definidos
- Testes de intrusão anuais e independentes (novidade significativa)
- Rastreabilidade de atividades em sistemas críticos
- Gestão de vulnerabilidades com SLA de remediação
- Treinamento e conscientização contínuos
- Política de governo de identidades de máquina (incluindo APIs)
- Avaliação periódica de prestadores de serviços TIC
- Plano de comunicação com BCB em caso de incidentes
- Relatório anual de cibersegurança ao BCB
A Resolução BCB nº 547 e a credenciação de PSTIs
Em janeiro de 2026, a Resolução BCB nº 547 ajustou a disciplina aplicável aos Provedores de Serviços de Tecnologia da Informação (PSTIs), tornando mais rigorosos os requisitos para credenciamento. PSTIs incluem provedores de cloud, datacenter, e serviços críticos de TI usados por instituições financeiras, e em muitos casos incluem provedores de email infrastructure.
Para fintechs brasileiras, a implicação é direta: terceirizar execução não reduz responsabilidade, amplia o dever de supervisão sobre dependências críticas. Se sua infraestrutura email é provida por terceiro, você precisa documentar:
- Quem é o PSTI
- Que dados são processados pelo PSTI
- Que controles você implementou para supervisionar o PSTI
- Como você responderia se o PSTI tivesse incidente
A interseção: empresa brasileira sob BCB 538 + cliente final UE
Para fintech brasileira que tem cliente final UE (não raro: open banking via PIX para usuário UE, gateway de pagamento para e-commerce brasileiro vendendo internacional, processamento KYC para multinacional), você está em interseção de regimes.
| Tipo de requisito | BCB 538/2025 (Brasil) | NIS2/DORA (UE) |
|---|---|---|
| Cobertura | Bancos, fintechs, IPs, cooperativas BR | Entidades financeiras UE + sub-processadores via cliente |
| Mandato autenticação email | Implícito via Art. 3º (controles preventivos) | Implícito via Art. 21 NIS2 / Arts. 5-15 DORA |
| Prazo notificação incidentes | Definido por instituição, BCB pode exigir | 24h alerta / 72h notif. / 1 mês relatório (NIS2); 4h / 72h / 1 mês (DORA) |
| Multa máxima | Sanções administrativas BCB (variável) | 10M€ ou 2% faturamento (NIS2) |
| Auditoria periódica | Auditoria externa anual + testes de intrusão anuais | Auditoria TIC anual + TLPT para entidades significativas |
| Registro fornecedores | Política de gestão de PSTIs (BCB 547) | Registro consolidado fornecedores TIC (Reg. UE 2024/2956) |
| Autoridades | BCB, CMN, ANPD para dados | Autoridades nacionais sectoriais por Estado-Membro |
Os dois regimes podem aplicar simultaneamente. Para fintech brasileira com cliente UE significativo, o caminho operacional limpo é cumprir o regime mais exigente em cada categoria, que tipicamente significa cumprir DORA na camada onde DORA é mais exigente (notificação 4h, TLPT) e BCB 538 na camada onde BCB 538 é mais específico (testes de intrusão anuais, 14 procedimentos).
O que seu provedor de infraestrutura email deveria entregar
Se seu provedor email não te entrega o seguinte sem que você precise perseguir, ele não está equipado para clientes brasileiros sob BCB 538 nem para cliente final UE sob NIS2/DORA:
1. DPA assinado com cláusulas LGPD adequadas Padrão Art. 39 e seguintes da LGPD, atualizado para refletir a Resolução CD/ANPD nº 19/2024 (cláusulas-padrão contratuais brasileiras) e a Resolução nº 32/2026 (UE adequada).
2. Lista de sub-processadores atualizada Com datas de qualquer mudança, jurisdições de cada sub-processador, e mecanismo de notificação de mudanças que exija sua aceitação.
3. Relatórios SOC 2 Type II ou ISO 27001 Não apenas selos de certificação, os relatórios reais para revisão pelos seus auditores. A maioria dos provedores os protege via NDA, o que está bem; “não temos um” não.
4. Documentação do procedimento de resposta a incidentes O que acontece quando o MTA cai? Quando um cliente reporta phishing usando seu domínio? Quando uma credencial é comprometida? Procedimentos documentados, não promessas.
5. SLA com compromissos mensuráveis 99,9% uptime é o piso para infraestrutura email produtiva. Provedores que oferecem “melhor esforço” não cumprem os requisitos do Art. 30 de DORA para provedores de serviços críticos, e não atendem aos critérios BCB 538 para PSTI credenciados.
6. Compromissos geográficos de residência de dados Onde seus dados são armazenados, onde transitam, onde vivem os backups. Para a sobreposição LGPD + NIS2 + DORA, somente-UE ou Brasil são as respostas mais seguras conforme o caso.
7. Cláusula de cooperação com auditorias no contrato É possível que precise levar seus auditores BCB ou os auditores do cliente UE para revisar os controles do seu provedor. O contrato deve permiti-lo, com pré-aviso razoável e proteções de confidencialidade.
Como se vê um setup email NIS2/DORA/BCB 538 alinhado em 2026
Para uma fintech brasileira hipotética sujeita a BCB 538/2025 e servindo cliente UE com exposição DORA:
Lado de envio:
- DMARC em
p=quarantinemínimo em todos os domínios de envio, com o caminho ap=rejectdocumentado - BIMI desplegado em domínio de comunicação com cliente (sinal de que DMARC está em enforcement)
- Política de rotação DKIM documentada e executando-se (típico: trimestral)
- Sub-processador para infraestrutura email é UE-incorporado ou regional Brasil com cadeia de sub-processadores documentada
- Relatórios mensais de placement retidos durante 12 meses (pedido de auditor)
- Procedimento de resposta a incidente para “domínio usado em phishing” documentado e testado
Lado de recepção:
- Gateway email entrante com validação SPF/DKIM/DMARC
- Autenticação resistente a phishing (chaves FIDO2, não somente SMS-OTP) para contas executivas
- Política de retenção email alinhada com requisitos sectoriais
- Logging para SIEM com casos de uso específicos documentados (detecção de account takeover, regras de reencaminhamento suspeitas, etc.)
Governança:
- Revisão anual de controles de infraestrutura email
- Revisão trimestral de lista de sub-processadores e mudanças contratuais
- Teste de penetração anual de sistemas email (ou como parte de pentest mais amplo, exigência BCB 538)
- Estratégia de saída documentada se a relação com provedor email terminar
Isso não é exótico. A maior parte é higiene padrão que já deveria existir. A pressão BCB 538 + NIS2 + DORA torna explícita a documentação onde antes era implícita.
Quando externalizar compliance vs construir interno
Para fintechs brasileiras enfrentando BCB 538 pela primeira vez, a pergunta prática é: contratamos compliance internamente, contratamos consultoria Big-4, ou usamos serviço gerenciado para a camada operacional?
Contratação interna (responsável de compliance + engenharia email): funciona para organizações com necessidades de compliance permanente e capacidade de engenharia email existente. Custo aproximado R$ 600.000-R$ 900.000 fully-loaded anuais para a camada operacional. O responsável de compliance é contratação separada.
Consultoria Big-4 (PwC, EY, KPMG, Deloitte): funciona para análise de gap único e preparação de auditoria. Excelente para a camada estratégica. Ferramenta errada para a camada operacional. Custo: R$ 200.000-R$ 800.000 por projeto.
Serviços gerenciados para a camada operacional: funcionam para organizações que têm responsável de compliance (interno ou frativo) mas precisam externalizar a execução operacional. Nossos produtos de DMARC gerenciado e monitoramento de deliverability encaixam aqui, com documentação que mapeia diretamente aos requisitos do Art. 3º BCB 538/2025 e dos Artigos 28-44 de DORA.
O modelo híbrido, responsável compliance fracional mais camada operacional gerenciada, é o que vemos com mais frequência para fintechs mid-market brasileiras. O responsável compliance fracional (R$ 8.000-R$ 25.000 mensais de retainer através de boutiques especialistas em fintech) gerencia a camada estratégica; o serviço gerenciado gerencia a execução operacional.
Linha final
NIS2 e DORA não são “leis de enforcement DMARC”, e BCB 538/2025 não é “lei de email infrastructure”. Mas os três criam urgência operacional ao redor do enforcement DMARC e da segurança email mais ampla que as organizações não podem evitar dizendo “não aplica regulação específica de email a nós”.
A primeira onda de inspeções formais BCB sob a Resolução 538/2025 começou em maio-junho de 2026, e o feedback inicial da comunidade fintech é que os auditores estão sendo menos punitivos que o temido mas mais prescritivos do que esperado. As organizações que fizeram a higiene operacional (DMARC em enforcement, inventário de sub-processadores, resposta a incidentes documentada) passaram limpas. As que fizeram compliance checkbox (“temos DMARC publicado”, em p=none) receberam achados parciais.
Para fintechs brasileiras tentando fazer isso direito sem sobreconstruir, o caminho é: leve DMARC ao enforcement, documente o que fez, garanta que seu provedor de infraestrutura email é auditável e (UE-incorporado ou Brasil), e trate o monitoramento contínuo como disciplina operacional ao invés de projeto. BCB 538, NIS2 e DORA recompensam a higiene operacional permanente; não recompensam projetos heroicos de último minuto pré-auditoria.