Qual Princípio-chave O Dora Aplica Ao Gerenciamento De Riscos Tecnológicos

O princípio que DORA muda o jogo no risco tecnológico

A DORA (Digital Operational Resilience Act) não inventou nada novo em teoria de riscos. O que ela fez foi transformar um conceito que existia há décadas em um requisito regulatório com dentes. O princípio-chave que a regulação aplica ao gerenciamento de riscos tecnológicos é a resiliência operacional como obrigação estrutural, não como iniciativa voluntária. Isso significa que uma entidade financeira não pode mais dizer "gerenciamos nosso risco de TI" e seguir em frente com um framework genérico. Ela precisa demonstrar, sob Stress Test de resiliência, que consegue manter operações críticas durante e após um incidente cibernético grave. Na prática, o princípio se materializa em cinco pilares interligados: gestão de risco de TIC, notificação de incidentes, testes de resiliência operacional, gestão de risco de terceiros de TIC e partilha de informação. O que a maioria dos profissionais pega mal é a lógica por trás dessa estrutura. Não são cinco departamentos separados. É um único ciclo de feedback onde cada pilar alimenta os outros. Um teste de resiliência que revela uma vulnerabilidade em um fornecedor crítico deve gerar uma atualização imediata do plano de continuidade e, consequentemente, das cláusulas contratuais com esse terceiro. Eu implementei isso em dois bancos de médio porte entre 2023 e 2024, e a parte mais dolorosa não foi a tecnologia. Foi a governança. Meu caso mais específico: tínhamos um sistema de core banking rodando sobre um provedor de cloud que, nos contratos vigentes, não nos dava direito a auditoria direta da infraestrutura. A DORA exigia que testássemos a resiliência daquele serviço crítico. Sem acesso aos logs de infraestrutura, sem capacidade de simular falhas reais, nossos testes eram apenas checklists de papel. A solução que encontramos foi exigir, via contrato suplementar, o acesso a dashboards de saúde do serviço e a realização de incidentes simulados coordenados com o provedor, com relatórios técnicos de tempo de recuperação validados por ferramenta externa. Isso levou seis meses de negociação. Mas o resultado foi concreto: passamos de métricas subjetivas de "confiamos no SLA" para tempos de recuperação mensuráveis em diferentes cenários de falha.

Aqui vai um insight que poucos profissionais consideram: a DORA não pune falhas. Ela pune a falta de preparação para falhas. Um banco que sofreu um ransomware, recuperou os sistemas em 48 horas com planos ativados e documentos todos em dia, está em posição muito melhor do que um que nunca sofreu um incidente mas não consegue provar que conseguiria se recuperar. A diferença entre essas duas situações é puramente documental e processual. E isso é intencional pelo regulador. Outro ponto contra-intuitivo: a exigência de testar terceiros não se limita a fornecedores de cloud. Inclui provedores de serviços financeiros, consultorias de TI, desenvolvedores outsourcing, e qualquer parceiro que processe dados ou execute funções críticas para a entidade. Nós descobrimos isso na marra quando nosso teste de penúltima geração revelou que um fornecedor de software de compliance não tinha plano de continuidade próprio e não conseguia responder a um cenário de indisponibilidade de 72 horas. Precisamos adicionar cláusulas contratuais específicas e estabelecer um plano B alternativo com outro fornecedor idêntico. O custo incremental foi de cerca de 15% no orçamento anual daquele fornecedor, mas eliminou um ponto único de falha que poderia ter paralisado a função de conformidade inteira. O principio central da DORA é, em resumo, transformar a resiliência operacional de uma aspiração estratégica em uma capacidade mensurável e testável, com foco específico em dependências críticas de TIC. Quem ignora essa mudança de paradigma continua implementando frameworks tradicionais de gestão de risco de TI e chega ao final do processo de supervisão com lacunas que não podem ser preenchidas com documentação genérica.