O quadro de gestão do risco das tecnologias da informação e comunicação previsto no DORA deve ligar as funções financeiras aos sistemas de que dependem, aos riscos, aos controlos e às decisões de gestão. Uma coleção de políticas de segurança não demonstra, por si só, que a entidade consegue detetar uma falha, manter uma função importante e recuperar com dados íntegros.
Este guia ajuda a construir esse encadeamento e a preparar um relatório de revisão utilizável pelo órgão de administração. Inclui um exemplo fictício de dependência tecnológica, critérios de aceitação e uma forma de acompanhar lacunas. O ponto de partida é confirmar o regime aplicável à entidade, incluindo exclusões e regras de proporcionalidade.
Confirmar o âmbito e o regime de gestão do risco
O Regulamento 2022/2554, DORA, é aplicável desde 17 de janeiro de 2025. O artigo 2.º identifica as categorias abrangidas e as exclusões. Não se deve concluir que qualquer empresa com atividade relacionada com finanças está sujeita ao mesmo conjunto de obrigações.
Para o quadro geral de gestão do risco TIC, os artigos 5.º a 15.º estabelecem governação, identificação, proteção, deteção, resposta, recuperação, aprendizagem e comunicação. O artigo 16.º prevê um quadro simplificado para categorias especificamente identificadas. Inclui, por exemplo, empresas de investimento de pequena dimensão e não interligadas e determinadas instituições isentas nos termos aí indicados.
Ter menos de dez trabalhadores não basta para entrar no artigo 16.º. A categoria de microempresa beneficia de disposições próprias em vários artigos, mas não deve ser confundida com o conjunto das entidades elegíveis para o quadro simplificado. Registe a classificação jurídica, a norma utilizada e quem a validou antes de escolher a matriz de requisitos.
O princípio da proporcionalidade exige considerar dimensão, perfil de risco e natureza, escala e complexidade das atividades. Permite calibrar a implementação nos termos do regulamento; não constitui uma autorização genérica para eliminar controlos essenciais porque a equipa é pequena.
Tornar a governação uma sequência de decisões
No quadro geral, o artigo 5.º atribui ao órgão de administração responsabilidades de definição, aprovação e supervisão dos mecanismos de gestão do risco TIC. A execução quotidiana pode ser distribuída, mas essa distribuição não retira a responsabilidade última prevista no artigo.
Prepare uma matriz que identifique quem propõe a tolerância ao risco, quem executa medidas, quem verifica resultados e quem decide sobre exceções. Defina também como a administração recebe informação sobre incidentes relevantes, alterações de prestadores e lacunas que afetam funções críticas ou importantes.
Uma reunião útil termina com decisões verificáveis. Por exemplo: aprovar uma medida de recuperação, atribuir recursos, exigir uma demonstração em determinada data ou recusar a manutenção de uma exposição. «Tomou conhecimento» não descreve adequadamente uma decisão quando a informação exige escolha sobre um risco material.
Os membros do órgão de administração devem manter conhecimentos e competências suficientes para compreender o risco TIC, incluindo formação regular proporcional. Um programa pode partir dos riscos efetivamente apresentados nas reuniões: dependência de um prestador, falha de autenticação ou limites de recuperação. Registe conteúdos e participação, mas avalie também se os decisores conseguem interpretar os indicadores usados.
Mapear funções, ativos e dependências
O artigo 8.º exige identificar, classificar e documentar funções suportadas por TIC, papéis, ativos e dependências. Comece pela função de negócio e percorra as aplicações, informação, infraestrutura, pessoas e prestadores necessários. Um inventário de equipamentos isolado não mostra o impacto de uma falha num serviço financeiro.
| Elemento | Exemplo fictício de preenchimento |
|---|---|
| Função | Receção e validação de instruções de clientes |
| Responsável funcional | Direção de operações |
| Aplicações | Portal, autenticação e sistema de validação |
| Informação | Identificação da conta, instrução, estado e prova de execução |
| Dependências | Serviço de identidade, conectividade, alojamento e assistência |
| Falha relevante | Indisponibilidade da identidade impede acesso ao portal |
| Consequência | Atraso no tratamento das instruções e necessidade de canal alternativo |
Use a cartografia dos sistemas para representar ligações e identificar componentes partilhados. Se duas aplicações «redundantes» dependem do mesmo serviço de autenticação, a redundância pode não resolver a falha escolhida para o exercício. Confirme também dependências indiretas introduzidas pelos prestadores.
No quadro geral, a classificação e a documentação relevante são revistas quando necessário e pelo menos anualmente, nos termos do artigo 8.º. As fontes de risco exigem identificação contínua, e os cenários têm revisão regular e pelo menos anual. Ligue mudanças importantes na infraestrutura ao processo de avaliação aplicável, em vez de esperar pela próxima revisão calendarizada.
Ligar cada risco a uma medida e a uma prova
Descreva o cenário de risco com causa, evento e consequência. «Ciberataque» é demasiado amplo para orientar uma medida. «Uma conta administrativa comprometida permite alterar permissões no sistema de instruções» ajuda a escolher autenticação, limitação de privilégios, deteção e recuperação de configuração.
Para cada cenário, registe medidas preventivas, capacidade de deteção, resposta e risco residual. Identifique a prova que confirma o controlo: configuração, resultado de exercício, registo de revisão ou demonstração de bloqueio. Um documento de intenção e um controlo implementado devem ter estados diferentes.
O Regulamento Delegado 2024/1774 desenvolve o quadro de gestão do risco TIC e o quadro simplificado. A matriz interna deve remeter para os requisitos pertinentes desse regulamento, incluindo políticas, procedimentos e elementos de reporte, sem reduzir a implementação a uma reprodução do texto legal.
Uma política de segurança da informação pode servir de documento de direção. Abaixo dela, mantenha procedimentos que indiquem como pedir acesso, instalar atualizações, gerir vulnerabilidades e tratar exceções. A estrutura deve permitir perceber que versão se aplica e quem verifica a sua execução.
Demonstrar que a deteção desencadeia resposta
A deteção do artigo 10.º deve permitir identificar rapidamente atividades anómalas nos termos previstos. Defina eventos relevantes, limiares, destinatários dos alertas e ações de escalada. Uma plataforma que recolhe dados sem alguém capaz de avaliar os alertas deixa uma lacuna operacional.
Num exercício, simule uma alteração administrativa inesperada em ambiente controlado. Registe quando ocorreu, quando foi detetada, quem recebeu o alerta e como foi qualificada. Se o alerta chegou a uma caixa de correio sem cobertura durante uma ausência, a ação corretiva deve incluir a organização do serviço, e não apenas uma nova regra técnica.
A política de registos de eventos de segurança deve equilibrar informação suficiente para investigar, proteção dos próprios registos e conservação adequada. Evite recolher conteúdos de clientes sem necessidade para compensar uma definição imprecisa dos eventos. Quando existam dados pessoais, aplicam-se também as condições do RGPD.
Construir continuidade e recuperação por função
Os artigos 11.º e 12.º tratam continuidade, resposta, recuperação e cópias de segurança. A análise de impacto deve apoiar prioridades e objetivos de recuperação, considerando as funções e as dependências. Um objetivo global para todos os sistemas pode esconder diferenças relevantes entre serviços.
No exemplo fictício, a entidade escolhe recuperar o acesso ao portal em duas horas e limitar a perda de instruções registadas a quinze minutos, após análise das necessidades e validação interna. Estes valores são escolhas do exemplo, não limites universais do DORA. O plano deve indicar que sistemas, pessoas e prestadores tornam esses objetivos alcançáveis.
O exercício revela recuperação técnica em uma hora e quarenta minutos, mas a reconciliação das instruções demora mais uma hora. A função não estava plenamente recuperada ao terminar o arranque do servidor. A equipa revê o procedimento de reconciliação e o critério de conclusão, distinguindo disponibilidade técnica de capacidade de executar corretamente o serviço.
Utilize um plano de recuperação TIC com exercício preenchido para organizar evidência de tempos, integridade, perdas e decisão de regresso ao funcionamento normal. Verifique as regras específicas de testes do DORA aplicáveis à entidade; não trate um único exercício informal como demonstração de todo o programa exigido.
Separar testes regulares e testes avançados
O DORA prevê obrigações de teste em diferentes disposições. No quadro geral, existem requisitos relativos à continuidade, recuperação e deteção, além do programa do capítulo IV para as entidades abrangidas pelas respetivas condições. A aplicabilidade e as exceções devem constar da matriz inicial.
Os testes avançados baseados em ameaças, TLPT, não são exigidos indistintamente a todas as entidades. O artigo 26.º prevê identificação segundo critérios e exclui, nesse âmbito, microempresas e entidades do artigo 16.º, n.º 1. A frequência e as condições próprias não devem ser transpostas para qualquer teste de intrusão contratado.
Para cada teste, defina objetivo, sistemas, autorizações, critérios de interrupção e forma de corrigir resultados. A evidência deve ligar uma constatação à ação executada e à verificação da correção. Uma lista de vulnerabilidades encerrada administrativamente, sem comprovar o resultado, deixa incerta a eficácia do controlo.
Rever o quadro e informar a administração
O artigo 6.º, n.º 5, exige documentação e revisão pelo menos anual, ou periódica no caso das microempresas, além dos eventos aí previstos, incluindo incidentes graves, instruções de supervisão e conclusões relevantes de testes ou auditorias. O quadro deve evoluir com a experiência. O relatório de revisão é fornecido à autoridade competente a pedido.
O artigo 27.º do Regulamento Delegado 2024/1774 especifica o formato e o conteúdo do relatório de revisão do quadro geral. Prepare um relatório que permita identificar âmbito, alterações, deficiências e medidas de correção. Para entidades no quadro simplificado, utilize as disposições próprias desse regime, em vez de assumir identidade total de requisitos.
Um painel de acompanhamento pode mostrar riscos acima da tolerância aprovada, medidas vencidas, resultados de recuperação e alterações relevantes de dependência. Explique o denominador: «três sistemas sem validação de restauro» significa pouco sem saber se suportam funções críticas e qual o universo analisado.
Integrar evidência sem confundir regimes
Algumas medidas apoiam simultaneamente o DORA e o artigo 32.º do RGPD, mas os âmbitos e critérios de risco não são idênticos. O registo de tratamentos descreve finalidades e operações sobre dados pessoais; o inventário DORA inclui ativos e funções TIC com outro objetivo. Pode ligar os documentos, preservando a informação específica de cada um.
Uma certificação de segurança também pode fornecer evidência útil, desde que se confirme o âmbito e a pertinência dos controlos. Não constitui, por si só, aprovação de conformidade DORA. O mesmo cuidado aplica-se a relatórios de fornecedores que apenas cobrem parte da infraestrutura utilizada.
As dependências externas devem entrar no quadro através da diligência, acompanhamento e saída de prestadores TIC. Quando uma nova informação altera o risco de uma função, atualize a decisão correspondente. O quadro torna-se útil quando a administração e as equipas conseguem seguir o percurso entre uma função, uma falha possível, uma medida demonstrada e uma decisão de gestão.