Preparação para o DORA de entidades financeiras e dos seus fornecedores de TIC

O DORA, o Regulamento relativo à resiliência operacional digital do setor financeiro, é aplicável desde 17 de janeiro de 2025. Para as entidades financeiras, estar preparado significa agora manter um modelo operacional de resiliência operacional digital e não preparar-se para um prazo futuro. Para os fornecedores de tecnologia, significa compreender as responsabilidades perante os clientes e saber se se aplica um regime separado de superintendência direta.

A questão para a gestão de topo é prática: a organização consegue explicar que serviços financeiros dependem de que sistemas de TIC, como será tratada uma perturbação e que evidências sustentam os seus pressupostos de recuperação? As políticas importam, mas não conseguem responder sozinhas a essa pergunta. A gestão precisa de uma visão interligada das responsabilidades, dependências, contratos, testes, incidentes e riscos por resolver.

Determinar o seu papel antes de construir a lista de verificação

Comece por uma decisão de aplicabilidade documentada para cada entidade jurídica relevante. O artigo 2.º do DORA identifica as categorias abrangidas e as exclusões. Uma empresa que se descreve como FinTech, startup ou PME não está automaticamente abrangida nem isenta.

Os exemplos de entidades financeiras abrangidas incluem instituições de crédito, instituições de pagamento, empresas de investimento e empresas de seguros, sem prejuízo das regras de âmbito detalhadas do regulamento. Registe a categoria aplicável, qualquer exclusão ou isenção, a autoridade competente relevante e o raciocínio que sustenta a sua conclusão.

Para os fornecedores, distinga três posições:

Um fornecedor que apoia uma função financeira crítica ou importante não é, só por isso, um terceiro prestador crítico de serviços de TIC designado. As entidades financeiras avaliam a importância das suas funções e dependências; a designação dos prestadores críticos ocorre através do quadro de supervisão previsto no artigo 31.º.

A localização não resolve a questão do fornecedor. Um fornecedor de cloud ou de software sediado nos EUA pode estar sujeito a requisitos dos clientes relacionados com o DORA quando serve entidades financeiras da UE. Essa relação comercial não o sujeita automaticamente a todas as obrigações impostas a uma entidade financeira.

A proporcionalidade exige também uma avaliação fundamentada. O artigo 4.º tem em conta fatores como a dimensão, o perfil de risco global e a natureza, a escala e a complexidade dos serviços. O artigo 16.º prevê um quadro simplificado de gestão do risco de TIC para categorias especificadas. Não são conceitos intermutáveis, e o mero estatuto de PME não é um atalho universal. Mantenha a análise de elegibilidade junto da decisão de âmbito.

Tornar visível a responsabilidade da gestão

Nos termos do artigo 5.º do DORA, o órgão de administração tem a responsabilidade última pela gestão do risco de TIC da entidade financeira. Delegar a implementação num CISO, numa equipa de tecnologia ou num prestador externo não transfere essa responsabilidade.

A gestão de topo deve estabelecer quem propõe as decisões, quem as aprova e quem verifica se a implementação funciona. O modelo operacional deve abranger a continuidade do negócio, a resposta a incidentes e a recuperação, os acordos com terceiros, o orçamento e os conhecimentos necessários para uma supervisão efetiva.

Uma recomendação prática é dar à gestão um pacote de reporte centrado em decisões, em vez de um painel com percentagens de conclusão. Inclua:

• Funções críticas ou importantes com pressupostos de recuperação não testados.
• Incidentes materiais, efeitos nos clientes e ações corretivas pendentes.
• Dependências de fornecedores com contratos incompletos ou opções de saída frágeis.
• Lacunas de controlo significativas, responsáveis e datas de remediação.
• Decisões que exijam financiamento, uma mudança de fornecedor ou uma resposta explícita ao risco.

Cada lacuna deve distinguir o requisito regulamentar, a fragilidade operacional atual e a solução proposta. A falta de um registo de aprovação é diferente de uma cópia de segurança que não pode ser restaurada. Ambas podem exigir ação, mas requerem responsáveis e prioridades diferentes.

A aprovação de um plano de remediação pela gestão não é uma autorização para adiar indefinidamente as obrigações aplicáveis. Quando uma lacuna é material, considere salvaguardas imediatas, a escalada e quaisquer implicações de supervisão a par da correção de longo prazo.

Construir o programa em torno das funções financeiras

Um inventário de ativos é necessário, mas o planeamento da resiliência deve começar pelo serviço que tem de continuar a funcionar. Identifique a função financeira, o seu responsável de negócio, as consequências de uma perturbação e os sistemas e fornecedores que a suportam.

Para um serviço de pagamento, mapeie a identidade, a infraestrutura cloud, o processamento de transações, a monitorização e a escalada junto dos fornecedores. Inclua dependências menos visíveis, como o DNS, a conectividade, o acesso privilegiado, as chaves de cifragem e as ferramentas de suporte. Um ambiente de produção alternativo pode ser inutilizável se depender do mesmo serviço de identidade que falhou.

O mapa resultante deve ligar cada função a:

• Aplicações, infraestrutura, ativos de informação e serviços externos de suporte.
• Contratos relevantes e responsáveis pelos serviços.
• Objetivos de recuperação e a análise de impacto no negócio que os sustenta.
• Mecanismos de deteção, resposta, recuperação e comunicação.
• Testes, constatações e riscos de dependência por resolver.

Valide o mapa com as equipas operacionais e de negócio. Os registos de compras mostram o que foi adquirido; não mostram necessariamente como um serviço funciona hoje.

Utilize este modelo para organizar a gestão do risco de TIC, a gestão e notificação de incidentes, os testes de resiliência e o risco de terceiros no domínio das TIC. O DORA contém também disposições sobre a partilha voluntária de informações sobre ciberameaças. Se participar, defina a adesão, a confidencialidade, a utilização permitida e as regras de tratamento, em vez de tratar a partilha como uma troca irrestrita de dados de incidentes.

Transformar a gestão do risco de TIC em trabalho financiado

As disposições do DORA sobre gestão do risco de TIC abrangem a identificação, a proteção e prevenção, a deteção, a resposta e recuperação, a aprendizagem e a comunicação. O quadro tem de ligar estas atividades, em vez de as deixar como coleções de políticas separadas.

Comece a avaliação de lacunas pelas funções mapeadas. Pergunte se os controlos de acesso protegem os seus sistemas, se as vulnerabilidades são tratadas, se as alterações são controladas, se a atividade suspeita é detetada e se os mecanismos de recuperação refletem falhas realistas. Considere as avarias técnicas e os erros operacionais, bem como os ataques maliciosos.

Para cada fragilidade material, crie um registo de remediação com um responsável, o impacto no negócio, a ação necessária, os critérios de conclusão e a evidência do encerramento. As dependências importam: melhorar os procedimentos de restauração pode exigir alterações ao acesso às cópias de segurança, aos compromissos dos fornecedores e à formação do pessoal antes de ser possível um teste bem-sucedido.

Os objetivos de recuperação devem resultar das necessidades do negócio e da análise de impacto, e não do que o nível de serviço normal de um fornecedor por acaso oferece. Quando a capacidade técnica não consegue cumprir o objetivo, a gestão tem de decidir se melhora a arquitetura, altera as modalidades do serviço ou reconsidera o modelo operacional. Uma meta escrita num plano de continuidade não é evidência de capacidade de recuperação.

Preparar as decisões sobre incidentes antes da perturbação

O DORA exige que as entidades financeiras giram os incidentes relacionados com as TIC e notifiquem os incidentes graves à autoridade competente relevante. Os artigos 17.º a 23.º estabelecem o quadro; as normas técnicas de regulamentação e de execução aplicáveis fornecem os critérios de classificação detalhados, os limiares, o conteúdo das notificações e os procedimentos.

Não confie numa lista de verificação genérica de incidentes para o calendário detalhado de notificação. Mantenha uma matriz de notificação atualizada que identifique as normas aplicáveis, as instruções da autoridade, o canal de submissão, as fases de notificação e o cálculo dos prazos. Atribua a responsabilidade pela sua atualização.

O processo de resposta deve tornar várias decisões executáveis sob pressão:

• Quem regista os momentos de deteção, avaliação e classificação?
• Quem obtém a informação sobre o impacto junto das operações e dos fornecedores?
• Quem decide se os critérios de incidente grave estão preenchidos?
• Quem aprova e submete as notificações, incluindo fora do horário normal de trabalho?
• Quem trata da comunicação com os clientes e de outras notificações aplicáveis?

Registe o raciocínio da classificação mesmo quando um incidente não é notificado como grave. Um quadro inicial incompleto deve desencadear uma reavaliação à medida que a informação evolui, e não uma presunção permanente de que o evento é menor.

Os compromissos de notificação dos fornecedores devem deixar à entidade financeira tempo suficiente para avaliar e cumprir as suas próprias obrigações. As tarefas de notificação podem ser externalizadas quando permitido, mas a responsabilidade permanece na entidade financeira.

Quando um incidente grave relacionado com as TIC afeta os interesses financeiros dos clientes, o DORA exige que as entidades financeiras informem esses clientes, sem demora injustificada, sobre o incidente e as medidas tomadas para atenuar os seus efeitos adversos. Avalie separadamente as obrigações relativas a violações de dados pessoais e outras regras aplicáveis. Uma única perturbação pode originar várias decisões de notificação, com destinatários e critérios jurídicos diferentes.

Testar os pressupostos em que a gestão se apoia

Um programa de testes de resiliência operacional digital deve ser proporcionado e baseado no risco. As avaliações de vulnerabilidades, os exercícios de cenários, os testes de segurança e os testes de recuperação respondem a perguntas diferentes; nenhum deve ser tratado como substituto universal dos outros.

Um exercício de mesa pode determinar se os decisores compreendem a escalada. Não consegue provar que os dados das transações podem ser restaurados com exatidão. Um teste de intrusão pode expor fragilidades exploráveis sem provar que um fornecedor alternativo consegue assumir um serviço.

Para cada teste, defina a função, o cenário, o âmbito, os critérios de sucesso, as disposições de independência quando exigidas e a evidência esperada. Preserve os resultados, as constatações, as decisões de remediação e os resultados dos novos testes. Verifique os requisitos de cobertura e de frequência aplicáveis face ao DORA e às normas relevantes, incluindo quaisquer isenções ou disposições do quadro simplificado.

Os testes de penetração baseados em ameaças são um requisito de supervisão separado para entidades financeiras selecionadas, nos termos do artigo 26.º. Não são uma obrigação geral para todas as empresas financeiras ou fornecedores de TIC.

A gestão deve rever os pressupostos que falharam e não apenas se os testes ocorreram. Se um exercício revelar que a restauração depende de um único administrador indisponível, o resultado é um risco operacional que exige ação e não um marco de testes concluído.

Tratar o risco de terceiros como uma questão de continuidade do serviço

Ao abrigo do DORA, uma entidade financeira continua responsável pelas suas obrigações quando recorre a fornecedores de TIC. Os artigos 28.º a 30.º ligam a avaliação do risco de terceiros, os acordos contratuais, a monitorização e o planeamento da saída.

Manter o registo e o quadro operacional

As entidades financeiras têm de manter um registo de informações relativas aos acordos contratuais de TIC aos níveis individual, subconsolidado e consolidado exigidos. Utilize as normas técnicas de execução aplicáveis para a sua estrutura. Uma folha de cálculo de compras ou uma lista de fornecedores aprovados não é automaticamente suficiente.

Concilie o registo com os contratos, a responsabilidade pelos serviços e os mapas de dependências. Mantenha as distinções exigidas para os serviços que apoiam funções críticas ou importantes. Um novo subcontratante, uma nova localização do serviço ou um âmbito alargado podem alterar o quadro de risco mesmo que o nome do fornecedor se mantenha.

Rever os contratos face ao serviço efetivo

Avalie os requisitos contratuais aplicáveis, incluindo as descrições dos serviços, as localizações, a proteção de dados, o acesso aos dados e a sua recuperação, a assistência em incidentes, a cooperação, os direitos de rescisão e os níveis de serviço. Os acordos que apoiam funções críticas ou importantes exigem disposições adicionais, incluindo as relativas a reporte, continuidade, acesso, inspeção, auditoria e saída.

Os responsáveis jurídicos, de compras, de tecnologia e de negócio devem rever estes aspetos em conjunto. Um direito contratual de auditoria pode ser difícil de exercer na prática; um mecanismo de recuperação prometido pode não abranger toda a cadeia de serviço do cliente. Identifique essas limitações antes de aceitar o acordo.

Examinar a concentração e a capacidade de saída

O risco de concentração não se limita a adquirir vários serviços a uma única empresa. Fornecedores diferentes podem depender da mesma plataforma cloud, região, rede ou subcontratante. Avalie a substituibilidade, a complexidade da migração e as consequências de uma falha comum.

Um plano de saída deve abordar os formatos de dados, a extração, o acesso, as dependências da migração, o apoio na transição, o apagamento e a continuidade durante a mudança. Para funções críticas ou importantes, trate o teste e a revisão da saída como trabalho substantivo e não como um exercício de redação de documentos.

Os fornecedores podem preparar um pacote de garantia coerente com o âmbito do serviço, as fronteiras de responsabilidade, os contactos para incidentes, a evidência de continuidade, a informação sobre subcontratação e as posições contratuais. Os requisitos específicos de cada cliente continuam a exigir revisão; um certificado não os substitui.

Compreender onde o DORA e a NIS2 se cruzam

O DORA é um regulamento da UE diretamente aplicável. A NIS2 é uma diretiva aplicada através do direito nacional, cuja aplicabilidade depende do setor, da dimensão, do serviço e das regras de inclusão. O prazo de transposição nacional terminou em 17 de outubro de 2024; as organizações precisam de examinar a transposição nacional aplicável, em vez de presumirem um regime operacional único e idêntico.

O n.º 2 do artigo 1.º do DORA, em conjugação com o artigo 4.º da NIS2, estabelece a relação setorial específica para as entidades financeiras abrangidas nas áreas relevantes. Não interprete isto como uma instrução para duplicar controlos equivalentes de gestão de riscos e de notificação de incidentes. Do mesmo modo, não presuma que elimina obrigações para todas as empresas de um grupo financeiro ou da sua cadeia de abastecimento.

Um prestador de serviços geridos que sirva um banco pode precisar da sua própria avaliação ao abrigo da NIS2, cumprindo ao mesmo tempo compromissos contratuais relacionados com o DORA. Uma matriz de obrigações entidade a entidade deve registar o fundamento jurídico, o âmbito, a autoridade, a via de notificação e a evidência exigida.

Os controlos partilhados podem apoiar o DORA, a ISO 27001, as obrigações de privacidade e a garantia aos clientes quando o âmbito e a evidência correspondem. Reutilize uma revisão de acessos ou um teste de recuperação quando estes apoiam genuinamente vários requisitos, preservando os pormenores próprios do setor financeiro. Um certificado ISO 27001 não demonstra a conformidade com o DORA.

A fiscalização também difere. Os poderes de supervisão e as sanções do DORA aplicáveis às entidades financeiras dependem das suas disposições e das medidas nacionais aplicáveis; os prestadores críticos designados estão sujeitos a um regime de superintendência separado. Não oriente o orçamento de risco em função de uma suposta coima universal do DORA. Avalie a exposição jurídica relevante e as consequências operacionais de uma resiliência inadequada.

Exemplo prático: revisão das dependências de um serviço de pagamento

Considere uma instituição de pagamento ilustrativa que utiliza uma plataforma cloud, um fornecedor de identidades e um serviço de monitorização externalizado. Suponha que a instituição está abrangida pelo DORA e que a execução de pagamentos está classificada como função crítica ou importante.

A primeira revisão identifica três fragilidades: os ambientes de produção e de recuperação partilham a mesma dependência de identidade; o processo de escalada de incidentes do fornecedor de monitorização não é claro; e o plano de saída da cloud indica um fornecedor alternativo sem demonstrar a extração e a migração dos dados.

A gestão encomenda três pacotes de trabalho interligados:

O responsável de negócio verifica se os objetivos de recuperação dos pagamentos continuam a ser alcançáveis. A conformidade verifica se os procedimentos de notificação e as entradas do registo refletem os acordos. A gestão aprova o financiamento necessário e revê as limitações remanescentes.

Este exemplo não demonstra, por si só, a conformidade. Mostra como uma única função pode expor decisões que permaneceriam ocultas em listas de verificação separadas de políticas, fornecedores e testes.

Estabelecer um ritmo de revisão baseado em evidências

O DORA não tem um processo de certificação universal que substitua as obrigações contínuas. A garantia independente pode informar a gestão, mas a preparação tem de ser demonstrada através de controlos em funcionamento, registos e, quando exigido, do relacionamento com a supervisão.

Um próximo passo prático é selecionar uma função crítica ou importante e reunir a respetiva decisão de âmbito, o mapa de dependências, a avaliação de riscos, os contratos, os procedimentos de incidentes, os resultados dos testes e as ações em aberto. Reveja se esses registos contam uma história coerente.

A Secani apoia este fluxo de trabalho modelando sistemas e serviços, ligando dependências e mantendo os requisitos, as evidências, os responsáveis, as tarefas e as decisões de revisão no seu contexto. Carregue o material existente associado aos objetos relevantes, transforme as lacunas em trabalho atribuído e mantenha a aprovação humana explícita para as sugestões e conclusões assistidas por IA.

Alargue o trabalho a partir dessa primeira função quando os percursos de responsabilidade e de evidência estiverem claros. A gestão de topo deve conseguir ver o que foi demonstrado, o que permanece incerto e que decisão é necessária a seguir.