DORA (Regulamento UE 2022/2554) Regulamento europeu

37 controles, organizados por grupo, com resumo em português.

Digital Operational Resilience Act — regulamento europeu de resiliência operacional digital pro setor financeiro (bancos, seguradoras, corretoras, instituições de pagamento, provedores de cripto-ativos) e seus fornecedores terceiros de TIC. Em vigor e diretamente aplicável desde 17/01/2025. Organizado em 5 pilares: gestão de risco de TIC, gestão e reporte de incidentes, testes de resiliência operacional (incluindo TLPT alinhado ao TIBER-EU), gestão de risco de terceiros de TIC, e compartilhamento de informação entre entidades financeiras.

Fonte oficial · A cor indica o perfil em que cada controle entra: Básico Intermediário Avançado.

É regulamento da União Europeia (texto de acesso público via EUR-Lex). A checklist é temática (5 pilares oficiais), não artigo por artigo — os capítulos sobre poderes de autoridade supervisora e processo legislativo (Art. 31-44, 46-64) ficam de fora por não serem controle que a entidade avaliada implementa. Números de artigo citados são referência factual; descrições em português são checklist prática da InfoCuestaSec, no mesmo padrão temático dos módulos de LGPD/GDPR. Divisão em perfis é didática.

GOV Governança e Organização de Risco de TIC

GOV.1
Atribuir ao órgão de administração responsabilidade final e não delegável pela gestão de risco de TIC (Art. 5). Responsabilidade que pode ser empurrada pra baixo na hierarquia tende a ficar sem dono de verdade quando o risco vira incidente real.
Básico
GOV.2
Manter uma estrutura de gestão de risco de TIC documentada, abrangente e proporcional ao porte e perfil de risco da entidade (Art. 6). Estrutura genérica demais (ou grande demais pro porte da entidade) não orienta decisão prática de risco no dia a dia.
Básico
GOV.3
Revisar a estrutura de gestão de risco de TIC pelo menos uma vez por ano e após incidente relevante (Art. 6). Uma estrutura de risco nunca revisada fica desatualizada em relação à infraestrutura e às ameaças reais que evoluíram desde a criação dela.
Intermediário
GOV.4
Submeter a estrutura de gestão de risco de TIC a auditoria interna independente periodicamente (Art. 6). Auditoria feita por quem desenhou o próprio controle tem viés estrutural — auditoria independente pega o que a autoavaliação não pega.
Intermediário
GOV.5
Manter sistemas, protocolos e ferramentas de TIC atualizados, confiáveis e com capacidade suficiente para as operações (Art. 7). Sistema de TIC desatualizado ou sem capacidade suficiente é a base de boa parte dos incidentes evitáveis.
Intermediário

ID Identificação e Proteção

ID.1
Identificar, classificar e documentar todas as funções de negócio, ativos de informação e ativos de TIC que as suportam (Art. 8). Não dá pra proteger o que não está mapeado — ativo desconhecido é risco não gerenciado por definição.
Básico
ID.2
Realizar avaliação de risco de TIC pelo menos uma vez por ano e a cada mudança relevante na infraestrutura (Art. 8). Avaliação de risco pontual, feita uma vez e nunca revisitada, perde mudança relevante de infraestrutura ou ameaça ao longo do tempo.
Básico
ID.3
Identificar as fontes de risco de TIC decorrentes de dependência de fornecedores terceiros (Art. 8). Dependência de terceiro sem mapeamento explícito é risco herdado sem que a entidade tenha decidido conscientemente aceitá-lo.
Intermediário
ID.4
Implementar políticas de segurança da informação que definam regras para proteger disponibilidade, autenticidade, integridade e confidencialidade do dado (Art. 9). Sem política clara de proteção do dado, cada equipe decide seu próprio nível de segurança, geralmente inconsistente e insuficiente.
Básico
ID.5
Aplicar controle de acesso baseado no princípio do menor privilégio e em segregação de funções (Art. 9). Acesso além do necessário aumenta o dano possível de uma credencial comprometida, mesmo sem nenhuma falha adicional.
Intermediário

DET Detecção

DET.1
Manter mecanismos que permitam detecção pronta de atividade anômala e de incidentes de TIC (Art. 10). Incidente que demora pra ser detectado já causou mais dano quando finalmente é percebido.
Intermediário
DET.2
Dimensionar os mecanismos de detecção conforme o perfil de risco e a criticidade dos ativos protegidos (Art. 10). Mecanismo de detecção genérico demais gera ruído (falso positivo) ou lacuna (falso negativo) dependendo do ativo protegido.
Intermediário
DET.3
Estabelecer múltiplas camadas de controle com limites de alerta e critérios claros para acionar resposta a incidente (Art. 10). Uma única camada de controle é um único ponto de falha — múltiplas camadas com limite de alerta claro pegam o que uma sozinha deixaria passar.
Avançado

RESP Resposta e Recuperação

RESP.1
Manter política de continuidade de negócio de TIC dedicada, integrada à política geral de continuidade (Art. 11). Continuidade de negócio sem o componente de TIC integrado deixa exatamente a parte mais provável de falhar fora do plano.
Básico
RESP.2
Implementar plano de resposta e recuperação de TIC com RTO/RPO definidos por função crítica (Art. 11). Sem RTO/RPO definidos por função crítica, a recuperação não tem meta clara pra saber se está no prazo ou já em atraso.
Intermediário
RESP.3
Manter política e procedimentos de backup, com restauração e recuperação testadas (Art. 12). Backup nunca testado é uma suposição de que funciona, não uma garantia — só o teste de restauração revela isso de verdade.
Básico
RESP.4
Manter capacidade de recuperação redundante em local separado do sistema primário, com risco de correlação mínimo (Art. 12). Recuperação no mesmo local do sistema primário falha exatamente no cenário em que mais seria necessária (desastre físico, queda regional).
Intermediário
RESP.5
Incorporar lições aprendidas de incidentes e exercícios de teste na estrutura de gestão de risco de TIC (Art. 13). Incidente que não vira aprendizado formal tende a se repetir, porque a causa raiz nunca chega a ser corrigida na estrutura.
Intermediário
RESP.6
Manter programa de conscientização e treinamento em segurança de TIC para todo o pessoal, incluindo a alta administração (Art. 13). Pessoal sem treinamento é o elo mais comum explorado em incidente real (phishing, engenharia social) — treinar reduz essa superfície.
Intermediário

COM Comunicação

COM.1
Manter plano de comunicação de crise para divulgação responsável de incidente a clientes, contrapartes e ao público (Art. 14). Comunicação de crise inventada na hora do incidente tende a ser tardia, inconsistente ou a piorar a percepção do público.
Básico
COM.2
Designar pessoa responsável por implementar a estratégia de comunicação de incidente (Art. 14). Sem responsável designado, a comunicação de um incidente real fica sem dono na hora em que mais precisa ser rápida e coordenada.
Intermediário

INC Gestão de Incidentes de TIC

INC.1
Manter processo de gestão de incidentes de TIC com procedimentos pra detectar, gerenciar e notificar incidentes (Art. 17). Processo de incidente informal produz resposta inconsistente a cada ocorrência, dependendo de quem está de plantão naquele dia.
Básico
INC.2
Classificar incidentes de TIC e ameaças cibernéticas significativas conforme critérios de criticidade, clientes afetados, duração e área geográfica (Art. 18). Sem critério de classificação, não dá pra saber quais incidentes exigem reporte regulatório e quais não — decisão vira subjetiva.
Básico
INC.3
Manter registro de todo incidente de TIC e ameaça cibernética significativa, independente da gravidade (Art. 17). Sem registro completo (mesmo dos incidentes menores), a entidade perde a visão de padrão e tendência ao longo do tempo.
Intermediário

REP Reporte de Incidentes

REP.1
Notificar incidente de TIC grave à autoridade competente dentro dos prazos regulatórios (notificação inicial, intermediária e relatório final) (Art. 19). Reporte fora do prazo regulatório é, por si só, uma não conformidade adicional além do próprio incidente.
Básico
REP.2
Notificar voluntariamente ameaça cibernética significativa à autoridade competente, quando relevante (Art. 19). Ameaça cibernética significativa não reportada tira do regulador e de outras entidades a chance de reagir antes de virar incidente real em outro lugar.
Intermediário
REP.3
Usar os modelos e formatos harmonizados definidos pelas autoridades europeias de supervisão para o reporte (Art. 20). Formato de reporte fora do padrão harmonizado atrasa a análise pela autoridade e dificulta comparação entre entidades diferentes.
Intermediário

TEST Testes de Resiliência Operacional Digital

TEST.1
Manter programa de testes de resiliência operacional digital proporcional ao porte, perfil de risco e criticidade dos serviços (Art. 24). Programa de teste desproporcional ao porte real da entidade é ou excesso de custo sem retorno, ou proteção insuficiente pro risco de verdade.
Básico
TEST.2
Realizar testes básicos anuais de ferramentas e sistemas de TIC: avaliação de vulnerabilidade, teste de segurança de código, teste de cenário, teste de desempenho, teste ponta a ponta (Art. 25). Sem teste técnico regular, vulnerabilidade real só é descoberta quando alguém de fora a explora primeiro.
Básico
TEST.3
Realizar Teste de Penetração Orientado por Ameaça (TLPT), alinhado ao framework TIBER-EU, a cada 3 anos, se a entidade for identificada como significativa pelo regulador (Art. 26). Teste de penetração comum não simula um atacante real motivado e persistente — o TLPT é desenhado especificamente pra isso.
Avançado
TEST.4
Usar só testadores internos ou externos certificados/qualificados na condução do TLPT (Art. 27). Testador sem qualificação formal pode não ter o rigor metodológico nem a ética profissional que um teste desse nível de risco exige.
Avançado

TERC Risco de Terceiros de TIC

TERC.1
Gerenciar o risco de terceiros de TIC como parte integrante da estrutura de gestão de risco de TIC, não separado dela (Art. 28). Risco de fornecedor tratado à parte do resto do risco de TIC cria um ponto cego que a estrutura geral deveria cobrir.
Básico
TERC.2
Manter registro de informação atualizado sobre todo acordo contratual com provedor terceiro de TIC (Art. 28). Sem registro atualizado, a entidade não sabe, na prática, de quantos fornecedores ela depende nem para quê.
Básico
TERC.3
Realizar avaliação prévia de risco de concentração antes de contratar provedor de TIC que suporte função crítica (Art. 29). Contratar novo fornecedor pra função crítica sem checar concentração pode aprofundar uma dependência já arriscada sem perceber.
Intermediário
TERC.4
Incluir nos contratos com provedores de TIC as disposições contratuais-chave exigidas: direito de acesso, auditoria, inspeção, plano de saída, SLA claro (Art. 30). Contrato sem direito de auditoria/inspeção deixa a entidade sem visibilidade real sobre como o fornecedor de fato opera o serviço.
Intermediário
TERC.5
Manter estratégia de saída documentada para cada função crítica terceirizada de TIC, evitando dependência excessiva de um único fornecedor (Art. 28). Sem estratégia de saída, trocar de fornecedor crítico (por escolha ou por falha dele) vira crise operacional em vez de projeto planejado.
Avançado

INFO Compartilhamento de Informação

INFO.1
Participar de acordo de compartilhamento de informação sobre ameaça cibernética com outras entidades financeiras, quando disponível (Art. 45). Ameaça que já atingiu outra entidade financeira pode ser detectada mais rápido na sua se a informação for compartilhada a tempo.
Avançado