Roteiro DORA 2026 para risco de TIC, fornecedores e TLPT

O pânico das pesquisas sobre DORA 2026 não é realmente sobre regulamentação; é sobre evidência

São 08:15 de uma segunda-feira e o Diretor de Segurança da Informação de uma instituição de pagamentos de média dimensão tem três separadores do navegador abertos: “lista de verificação RTS/ITS DORA”, “modelo de registo de terceiros de TIC DORA” e “requisitos TLPT para entidades financeiras”.

O responsável pela conformidade já perguntou se o dossiê para o conselho de administração deve incluir o fluxo de classificação de incidentes mais recente. A área de Compras quer integrar uma nova plataforma de analítica na nuvem. O COO quer garantia de que o fornecedor SaaS de core banking não tem exposição oculta a subcontratantes fora da UE. A Auditoria Interna está a pedir um calendário de testes. O Jurídico pergunta se os prazos de notificação de violações de dados do RGPD da UE foram alinhados com a comunicação de incidentes DORA.

Ninguém está a fazer uma pergunta teórica. Estão a perguntar: “Conseguimos provar isto até sexta-feira?”

Esse é o verdadeiro problema da DORA 2026. A maioria das entidades financeiras compreende as obrigações principais: gestão do risco de TIC, comunicação de incidentes relacionados com as TIC, testes de resiliência operacional digital, gestão do risco de terceiros de TIC e supervisão reforçada de prestadores críticos de serviços de TIC. A parte difícil é converter Normas Técnicas de Regulamentação, Normas Técnicas de Execução e obrigações ao nível dos artigos em práticas controladas, repetíveis e auditáveis.

O Digital Operational Resilience Act exige que as entidades financeiras mantenham capacidades robustas de gestão do risco de TIC, políticas para gerir e comunicar incidentes relacionados com as TIC, testes de sistemas, controlos e processos de TIC, e supervisão estruturada de prestadores terceiros de serviços de TIC. Também exige proporcionalidade. Uma pequena sociedade de investimento e um grande grupo bancário não precisam de modelos de evidência idênticos, mas ambos devem provar que a sua abordagem é adequada à sua dimensão, perfil de risco, complexidade e funções críticas.

Os projetos DORA costumam falhar por uma de três razões. Primeiro, a organização trata a DORA como um exercício de mapeamento jurídico em vez de a tratar como um modelo operacional. Segundo, o risco de fornecedores é documentado como uma lista de fornecedores, e não como uma análise de dependência, grau de substituibilidade e risco de concentração. Terceiro, os testes são tratados como um teste de intrusão anual, e não como um programa de resiliência que inclui varrimentos de vulnerabilidades, testes baseados em cenários, exercícios de incidentes e, quando aplicável, testes de intrusão baseados em ameaças, normalmente pesquisados como TLPT.

Uma abordagem melhor consiste em criar um único sistema de evidência que ligue políticas, registos, proprietários, riscos, incidentes, fornecedores, testes, recuperação e revisão pela gestão. É aqui que o Zenith Blueprint da Clarysec, as políticas prontas a utilizar e os Zenith Controls ajudam as entidades financeiras a transformar a DORA de um prazo regulatório num ritmo operacional.

Comece pelo modelo operacional DORA, não pela folha de cálculo RTS/ITS

Muitas equipas começam com uma folha de cálculo que enumera artigos da DORA e requisitos RTS/ITS. Isso é útil, mas não é suficiente. Uma folha de cálculo pode indicar o que deve existir. Não atribui proprietários, não define frequência de revisão, não preserva evidência nem prova que um controlo funciona efetivamente.

No Zenith Blueprint: roteiro de 30 passos para auditores, a Clarysec aborda este ponto na fase de Gestão de Riscos, passo 14, Políticas de tratamento do risco e referências cruzadas regulamentares:

“DORA: Para empresas do setor financeiro, a DORA exige um quadro de gestão do risco das TIC muito alinhado com o que fizemos: identificar riscos, implementar controlos (e políticas) e testá-los. A DORA também enfatiza a resposta e comunicação de incidentes e a supervisão dos prestadores terceiros de serviços de TIC.”

A mensagem prática é simples: não construa a “conformidade DORA” como uma burocracia paralela. Construa uma camada de governação de TIC baseada no risco que mapeie os requisitos DORA para políticas, registos, proprietários dos controlos, registos de testes, evidência de fornecedores e revisão pela gestão.

Um modelo operacional DORA prático deve ter cinco pilares de evidência:

Para entidades financeiras reguladas, esta estrutura transforma a implementação RTS/ITS num sistema de evidência preparado para auditoria. Para entidades sujeitas a gestão simplificada do risco de TIC, o mesmo modelo pode ser escalado para menos documentos e registos mais simples. As disciplinas essenciais permanecem as mesmas: identificar, proteger, detetar, responder, recuperar, testar e governar fornecedores.

Gestão do risco de TIC: o registo é a sala de controlo

As expectativas da DORA em matéria de gestão do risco de TIC exigem que as entidades financeiras identifiquem, classifiquem e giram riscos de TIC em sistemas, dados, processos, funções críticas ou importantes e dependências de terceiros.

A falha comum não é a ausência de um Registo de Riscos. É o facto de o registo estar desligado de fornecedores, ativos, incidentes e testes. A DORA não valoriza uma folha de cálculo visualmente impecável se esta não explicar por que razão um fornecedor de alto risco não tem plano de saída, ou por que razão uma plataforma crítica de pagamentos de clientes não foi testada.

A Política de Gestão de Riscos da Clarysec para PME fornece às entidades financeiras de menor dimensão uma linha de base de evidência concisa:

“Cada entrada de risco deve incluir: descrição, probabilidade, impacto, pontuação, proprietário e plano de tratamento.”
Da secção “Requisitos de governação”, cláusula 5.1.2 da política.

Para entidades financeiras de maior dimensão, a Política de Gestão de Riscos Enterprise da Clarysec exige um processo mais formal:

“Deve ser mantido um processo formal de gestão de riscos em conformidade com a ISO/IEC 27005 e a ISO 31000, abrangendo identificação, análise, avaliação, tratamento, monitorização e comunicação do risco.”
Da secção “Requisitos de governação”, cláusula 5.1 da política.

Esta distinção é importante. A DORA é proporcional, mas proporcionalidade não significa informalidade. Uma pequena instituição de pagamentos pode utilizar um registo simplificado, enquanto um grupo bancário pode utilizar ferramentas GRC integradas. Em ambos os casos, o auditor continuará a perguntar: quais são os seus riscos de TIC? Quem é o proprietário? Qual é o plano de tratamento? Que evidência demonstra progresso? Como é que os fornecedores e as funções críticas afetam a pontuação?

Um Registo de Riscos de TIC DORA robusto deve incluir estes campos:

Um exercício prático é selecionar um serviço crítico de TIC, como uma plataforma de monitorização de transações alojada na nuvem, e criar uma entrada de risco em 20 minutos. Descreva o cenário de falha ou comprometimento, pontue probabilidade e impacto, atribua um proprietário, identifique fornecedores relacionados, defina um plano de tratamento e ligue a entrada a evidência como diligência prévia de fornecedores, SLA, cláusulas de incidentes, BIA, resultados de testes de recuperação de desastre, painéis de monitorização e revisão de acessos.

Essa única entrada torna-se o fio condutor que liga a gestão do risco de TIC DORA, a supervisão de terceiros, a deteção de incidentes, a continuidade e os testes. É assim que um Registo de Riscos se torna uma sala de controlo, e não um arquivo.

Preparação RTS/ITS: mapeie obrigações para políticas, não para promessas

O termo de pesquisa prático “lista de verificação RTS/ITS DORA” normalmente significa “Que documentos os supervisores esperam ver?” As entidades financeiras devem evitar prometer conformidade através de declarações genéricas. Precisam de um mapeamento que associe cada obrigação a uma política, controlo, proprietário e item de evidência.

A Política de Cumprimento Legal e Regulamentar da Clarysec para PME estabelece uma âncora de governação simples:

“O Diretor-Geral deve manter um Registo de Conformidade simples e estruturado que liste:”
Da secção “Requisitos de governação”, cláusula 5.1.1 da política.

Para a DORA 2026, o seu Registo de Conformidade deve incluir:

• Obrigação DORA ou área de requisitos RTS/ITS.
• Aplicabilidade, incluindo justificação de proporcionalidade.
• Referência a política ou procedimento.
• Proprietário do controlo.
• Localização da evidência.
• Frequência de revisão.
• Lacunas abertas e prazo de remediação.
• Estado do reporte ao conselho de administração ou à gestão.

Isto está alinhado com a abordagem do passo 14 do Zenith Blueprint: mapear requisitos regulamentares para controlos e políticas do SGSI para que nada fique por tratar. Em vez de perguntar “Estamos conformes com a DORA?”, a liderança pode perguntar “Que itens de evidência DORA estão em atraso, que fornecedores críticos não têm planos de saída e que atividades de teste ainda não produziram evidência de remediação?”

Risco de terceiros de TIC: concentração, grau de substituibilidade e subcontratantes

A DORA mudou a conversa sobre fornecedores nos serviços financeiros. Já não é suficiente perguntar se um prestador tem uma certificação de segurança, seguro ou um Acordo de Tratamento de Dados. As entidades financeiras devem avaliar se um prestador cria risco de concentração, se pode realisticamente ser substituído, se vários serviços críticos dependem de um único fornecedor ou de fornecedores relacionados, e se a subcontratação introduz exposição jurídica ou de resiliência adicional.

Este é o tema que tira o sono a muitos Diretores de Segurança da Informação. Uma entidade pode depender de um grande prestador de serviços de nuvem para processamento de transações, analítica de dados, portais de clientes e colaboração interna. Se esse prestador sofrer uma indisponibilidade prolongada, um litígio regulatório ou uma falha de subcontratante, a pergunta não é apenas “Temos contrato?” A pergunta é “Conseguimos continuar serviços críticos, comunicar com clientes e provar que compreendíamos a dependência antes de ela falhar?”

A Política de Segurança de Terceiros e Fornecedores da Clarysec para PME estabelece a base:

“Deve ser mantido e atualizado um registo centralizado de fornecedores pelo contacto administrativo ou de aquisição. Deve incluir:”
Da secção “Requisitos de governação”, cláusula 5.4 da política.

Para programas empresariais, a Política de Gestão do Risco de Dependência de Fornecedores da Clarysec aprofunda a dependência e o grau de substituibilidade específicos da DORA:

“Registo de dependências de fornecedores: O Gabinete de Gestão de Fornecedores (VMO) deve manter um registo atualizado de todos os fornecedores críticos, incluindo detalhes como serviços/produtos fornecidos; se o fornecedor é de fonte única; fornecedores alternativos disponíveis ou grau de substituibilidade; termos contratuais atuais; e uma avaliação do impacto caso o fornecedor falhe ou seja comprometido. O registo deve identificar claramente fornecedores com elevada dependência (por exemplo, aqueles para os quais não existe alternativa rápida).”
Da secção “Requisitos de implementação”, cláusula 6.1 da política.

Esta é a evidência de fornecedores que os projetos DORA frequentemente não contemplam. Um registo centralizado de fornecedores diz quem é o fornecedor. Um registo de dependências diz o que acontece quando o fornecedor falha.

O Zenith Blueprint, na fase Controlos em Ação, passo 23, Controlos organizacionais, fornece um fluxo de trabalho prático para supervisão de fornecedores. Recomenda compilar uma lista completa de fornecedores, classificar fornecedores com base no acesso a sistemas, dados ou controlo operacional, verificar que as expectativas de segurança estão incorporadas nos contratos, gerir o risco de subcontratantes e de cadeia a jusante, definir procedimentos de alteração e monitorização e criar um processo de avaliação de serviços na nuvem.

Em Zenith Controls: o guia de conformidade cruzada, o controlo ISO/IEC 27002:2022 5.21, Gestão da segurança da informação na cadeia de fornecimento de TIC, é mapeado como controlo preventivo que suporta Confidencialidade, Integridade e Disponibilidade. Está associado à segurança da relação com fornecedores e ao conceito de cibersegurança Identificar. Liga-se a engenharia segura, programação segura, controlo de acesso, testes de segurança, recolha de evidência, ciclo de vida de desenvolvimento seguro e desenvolvimento externalizado.

Essa é exatamente a realidade da supervisão de terceiros ao abrigo da DORA. O risco de fornecedores não é apenas Compras. Afeta arquitetura, desenvolvimento, resposta a incidentes, controlo de acesso, continuidade de negócio e Jurídico.

Numa perspetiva de conformidade cruzada, os Zenith Controls mapeiam a segurança da cadeia de fornecimento de TIC para os Articles 28 e 32 do RGPD da UE, porque os subcontratantes responsáveis pelo tratamento de dados e subcontratantes subsequentes devem ser selecionados e supervisionados com medidas técnicas e organizativas adequadas. Suportam as expectativas de segurança da cadeia de fornecimento da NIS2, incluindo o Article 21 sobre medidas de gestão do risco de cibersegurança e o Article 22 sobre avaliações coordenadas de risco da cadeia de fornecimento. O mapeamento é particularmente forte para os Articles 28, 29 e 30 da DORA, onde o risco de terceiros de TIC, o risco de concentração, a subcontratação em cadeia e as disposições contratuais são centrais.

As normas de suporte reforçam a evidência. A ISO/IEC 27036-3:2021 suporta a segurança na aquisição de TIC e na seleção de fornecedores. A ISO/IEC 20243:2018 suporta a integridade de produtos tecnológicos de confiança e a segurança da cadeia de fornecimento. A ISO/IEC 27001:2022 liga estes elementos ao tratamento de riscos e aos controlos de fornecedores do Anexo A.

Comunicação de incidentes: construa a cadeia de escalonamento antes do incidente

A comunicação de incidentes DORA não se resume à submissão de uma notificação. Trata-se de detetar, classificar, escalar, comunicar e aprender com incidentes relacionados com as TIC. As entidades financeiras devem manter processos de gestão e comunicação de incidentes de TIC, com papéis definidos, critérios de classificação, vias de notificação e análise pós-incidente.

A Política de Resposta a Incidentes da Clarysec para PME liga os prazos de resposta a incidentes aos requisitos legais:

“Os prazos de resposta, incluindo recuperação de dados e obrigações de notificação, devem ser documentados e alinhados com os requisitos legais, como o requisito do RGPD da UE de notificação de violação de dados pessoais em 72 horas.”
Da secção “Requisitos de governação”, cláusula 5.3.2 da política.

Para ambientes empresariais, a Política de Resposta a Incidentes da Clarysec acrescenta a perspetiva de escalonamento de dados regulados:

“Se um incidente resultar em exposição confirmada ou provável de dados pessoais ou outros dados regulados, o Jurídico e o EPD devem avaliar a aplicabilidade de:”
Da secção “Requisitos de implementação da política”, cláusula 6.4.1 da política.

A citação termina no ponto de acionamento, que é exatamente onde muitos processos de incidentes falham. Se o acionador não for claro, as equipas debatem obrigações de notificação quando o relógio já está a contar.

O Zenith Blueprint, na fase Controlos em Ação, passo 16, Controlos de pessoas II, enfatiza a comunicação de incidentes orientada para as pessoas. Trabalhadores, contratados e partes interessadas precisam de saber como reconhecer e comunicar potenciais incidentes de segurança através de canais simples, como uma caixa de correio dedicada, portal ou linha direta. O Blueprint liga isto ao Article 33 do RGPD da UE, ao Article 23 da NIS2 e ao Article 17 da DORA, porque o reporte regulamentar começa com sensibilização e escalonamento internos.

Nos Zenith Controls, o controlo ISO/IEC 27002:2022 5.24, Planeamento e preparação da gestão de incidentes de segurança da informação, é mapeado como controlo corretivo que suporta Confidencialidade, Integridade e Disponibilidade, alinhado com Responder e Recuperar. Liga-se diretamente à avaliação de eventos, aprendizagem com incidentes, registo de eventos e monitorização, segurança durante perturbações, continuidade da segurança da informação e contacto com autoridades. O guia mapeia este controlo para os Articles 17 a 23 da DORA para gestão, classificação e comunicação de incidentes relacionados com as TIC e notificação voluntária de ameaças cibernéticas, Articles 33 e 34 do RGPD da UE para notificação de violação de dados, e Article 23 da NIS2 para notificação de incidentes.

Um processo de incidentes preparado para DORA deve incluir:

• Canais claros de entrada de incidentes.
• Triagem de eventos e critérios de classificação.
• Fluxo de escalonamento de incidentes graves relacionados com as TIC.
• Pontos de decisão jurídica, do EPD e de notificação regulatória.
• Acionadores de notificação de incidentes de fornecedores.
• Requisitos de preservação de evidência.
• Regras de comunicação à direção executiva e ao conselho de administração.
• Revisão pós-incidente e lições aprendidas.
• Ligação a atualizações do Registo de Riscos e à remediação de controlos.

As normas de suporte acrescentam estrutura. A ISO/IEC 27035-1:2023 fornece princípios de planeamento e preparação para gestão de incidentes. A ISO/IEC 27035-2:2023 detalha as etapas de tratamento de incidentes. A ISO/IEC 22320:2018 suporta comando, controlo e comunicação de crise estruturada. Isto é importante quando uma indisponibilidade de TIC se transforma numa crise com impacto nos clientes e a entidade deve demonstrar que as decisões foram atempadas, coordenadas e baseadas em evidência.

Testes de resiliência operacional digital e TLPT: não deixe que o teste se torne o incidente

Os testes são um dos temas DORA 2026 mais pesquisados porque são simultaneamente técnicos e intensivos em governação. As entidades financeiras precisam de testar sistemas, controlos e processos de TIC. Para entidades designadas, testes avançados como TLPT tornam-se um requisito central ao abrigo do Article 26 da DORA.

A pergunta de auditoria não é apenas “Testaram?” É “O teste foi baseado no risco, autorizado, seguro, independente quando exigido, remediado e ligado a objetivos de resiliência?”

A Política de Testes de Segurança e Red Teaming Enterprise da Clarysec define claramente o programa mínimo de testes:

“Tipos de testes: O programa de testes de segurança deve incluir, no mínimo: (a) varredura de vulnerabilidades, composta por varreduras automatizadas semanais ou mensais de redes e aplicações para identificar vulnerabilidades conhecidas; (b) testes de intrusão, compostos por testes manuais aprofundados de sistemas ou aplicações específicos por testadores qualificados para identificar fraquezas complexas; e (c) exercícios de red team, compostos por simulações baseadas em cenários de ataques reais, incluindo engenharia social e outras táticas, para testar as capacidades de deteção e resposta da organização como um todo.”
Da secção “Requisitos de implementação”, cláusula 6.1 da política.

Esta é a ponte entre testes de rotina e maturidade TLPT. O varrimento de vulnerabilidades identifica fraquezas conhecidas. Os testes de intrusão validam a explorabilidade. O red teaming testa a deteção e a resposta como um sistema. O TLPT, quando aplicável, deve integrar-se num programa de testes governado, com controlo de âmbito, regras de segurança, gestão do risco em produção, recolha de evidência e acompanhamento da remediação.

O Zenith Blueprint, na fase Controlos em Ação, passo 21, aborda a proteção dos sistemas de informação durante auditorias e testes. Alerta que auditorias, testes de intrusão, revisões forenses e avaliações operacionais podem introduzir risco porque podem envolver acesso elevado, ferramentas intrusivas ou alterações temporárias ao comportamento dos sistemas. O Blueprint mapeia esta preocupação para o Article 32 do RGPD da UE, as expectativas DORA de testes de resiliência operacional digital, preocupações de continuidade da NIS2 e práticas COBIT 2019 para execução segura de auditorias e avaliações.

Nos Zenith Controls, o controlo ISO/IEC 27002:2022 5.35, Revisão independente da segurança da informação, é mapeado como preventivo e corretivo, suportando Confidencialidade, Integridade e Disponibilidade. Liga-se ao cumprimento das políticas, responsabilidades de gestão, aprendizagem com incidentes, proteção de registos, eliminação de informação, registo de eventos e monitorização. Para a DORA, as obrigações de teste relevantes são sobretudo os Articles 24 a 27, incluindo o Article 26 para TLPT. Isto também suporta o Article 32(1)(d) do RGPD da UE, que exige testes e avaliação regulares de medidas técnicas e organizativas, e o Article 21 da NIS2, que exige medidas de gestão do risco de cibersegurança.

Um pacote de preparação TLPT DORA deve incluir:

A principal lição DORA é que a evidência de testes não pode terminar no relatório. Os auditores irão perguntar se as constatações foram classificadas por risco, atribuídas, remediadas e retestadas. Também podem verificar se os testes abrangeram funções críticas ou importantes, e não apenas ativos expostos à Internet.

Continuidade de negócio e recuperação de desastre: a resiliência deve ser operacional

A DORA é um regulamento de resiliência operacional digital. A recuperação é tão importante como a prevenção. Um quadro documentado de risco de TIC não ajudará se a indisponibilidade de uma plataforma de pagamentos revelar que os Objetivos de Tempo de Recuperação (RTO) nunca foram testados, que as árvores de contacto de fornecedores estão desatualizadas e que a equipa de crise não concorda sobre quem comunica com os clientes.

A Política de Continuidade de Negócio e Recuperação de Desastre da Clarysec para PME estabelece uma linha de base clara:

“A organização deve testar as suas capacidades de BCP e recuperação de desastre pelo menos anualmente. Os testes devem incluir:”
Da secção “Requisitos de implementação da política”, cláusula 6.4.1 da política.

A Política de Continuidade de Negócio e Recuperação de Desastre Enterprise começa pelo impacto no negócio:

“A análise de impacto no negócio deve ser realizada pelo menos anualmente para todas as unidades de negócio críticas e revista após alterações significativas a sistemas, processos ou dependências. Os resultados da BIA devem definir:”
Da secção “Requisitos de governação”, cláusula 5.2 da política.

Para a DORA, a BIA deve estar ligada a ativos de TIC, fornecedores, resposta a incidentes e testes. Se a BIA identificar “pagamentos de clientes” como função crítica, o registo de dependências de fornecedores deve identificar os subcontratantes responsáveis pelo tratamento de dados, serviços na nuvem e prestadores de rede que a suportam. O Registo de Riscos deve incluir cenários de falha. O plano de testes deve incluir validação de resiliência. O Plano de Resposta a Incidentes deve incluir escalonamento e comunicação. O teste de recuperação de desastre deve produzir evidência, não apenas uma nota de reunião.

Esta rastreabilidade é o que transforma a conformidade DORA num sistema de resiliência operacional.

Conformidade cruzada: um conjunto de evidência, muitas perguntas de auditoria

As entidades financeiras raramente enfrentam a DORA isoladamente. Frequentemente têm obrigações do RGPD da UE, exposição à NIS2, compromissos contratuais de segurança, objetivos ISO/IEC 27001:2022, requisitos de auditoria interna, diligência prévia de clientes, expectativas SOC e reporte de risco ao conselho de administração. A resposta não é criar silos de evidência separados. A resposta é construir um modelo de evidência de conformidade cruzada.

Os Zenith Controls são a bússola de conformidade cruzada da Clarysec. Não inventam novas obrigações. Mapeiam normas e referenciais oficiais para que as organizações compreendam como uma área de controlo suporta vários resultados de conformidade.

Isto é relevante para orçamento e governação. Um Diretor de Segurança da Informação pode explicar ao conselho de administração que melhorar a classificação de incidentes suporta o reporte DORA, a notificação de violação de dados do RGPD da UE, o tratamento de incidentes NIS2 e a resiliência interna. Um responsável de Compras pode justificar o mapeamento de dependências de fornecedores porque suporta o risco de concentração DORA, a diligência prévia de subcontratantes responsáveis pelo tratamento de dados no RGPD da UE e a segurança da cadeia de fornecimento NIS2. Um responsável por testes pode demonstrar que exercícios de red team e revisões independentes suportam testes DORA, avaliação de controlos no RGPD da UE e garantia mais ampla.

Perspetiva de auditoria: como os avaliadores testarão a sua evidência DORA

A preparação DORA torna-se real quando alguém pede evidência. Diferentes auditores e avaliadores abordarão o mesmo tema por ângulos diferentes.

Um auditor orientado pela ISO/IEC 27001:2022 começará pela lógica do SGSI: âmbito, avaliação de riscos, tratamento de riscos, aplicabilidade de controlos do Anexo A, auditoria interna, revisão pela gestão e evidência de que os controlos estão implementados. Para a segurança da cadeia de fornecimento de TIC, analisará políticas, classificação de fornecedores, cláusulas contratuais, diligência prévia e monitorização contínua. Para gestão de incidentes, inspecionará o plano, papéis, vias de escalonamento, ferramentas e registos. Para testes, esperará intervalos planeados, independência quando apropriado, remediação e contributos para a revisão pela gestão.

Uma perspetiva de auditoria ISO/IEC 19011:2018 foca-se na execução da auditoria. Nos Zenith Controls, a metodologia de auditoria para segurança da cadeia de fornecimento de TIC observa que os auditores examinam políticas de aquisição, modelos de RFP e processos de gestão de fornecedores para verificar que os requisitos de segurança específicos de TIC estão incorporados desde a aquisição até à eliminação. Para gestão de incidentes, os auditores examinam o Plano de Resposta a Incidentes quanto à completude e alinhamento com boas práticas. Para revisão independente, os auditores procuram evidência de que auditorias ou revisões independentes foram realizadas.

Uma perspetiva ISO/IEC 27007:2020 é mais específica de auditoria ao SGSI. Os Zenith Controls indicam que os auditores podem entrevistar responsáveis de Compras, pessoal de segurança de TI e gestores do fornecedor para avaliar a compreensão e execução dos controlos da cadeia de fornecimento de TIC. Para preparação de incidentes, confirmam que existe uma Equipa de Resposta a Incidentes e que está operacional. Para revisão independente, verificam que o programa de auditoria interna cobre todo o âmbito do SGSI e tem recursos adequados.

Um avaliador de testes informado pela NIST SP 800-115 focar-se-á na metodologia de avaliação de vulnerabilidades e testes de intrusão. Poderá examinar se o âmbito de teste, as regras de atuação, as constatações, as classificações de severidade, a remediação e o reteste estão documentados. Para TLPT DORA, isto significa que o avaliador não ficará satisfeito com um conjunto de slides de red team. Irá querer evidência de governação, segurança, profundidade técnica e encerramento.

Um auditor ao estilo COBIT 2019 ou ISACA perguntará se os objetivos de governação são cumpridos: quem é proprietário do processo, como é medido o desempenho, como são aprovadas exceções e como a gestão recebe garantia.

A lista de verificação prática de preparação DORA 2026

Utilize esta lista de verificação como linha de base operacional para converter pesquisas sobre DORA em ações.

Governação e mapeamento RTS/ITS

• Mantenha um Registo de Conformidade DORA com área da obrigação, aplicabilidade, proprietário, evidência, frequência de revisão e estado das lacunas.
• Mapeie os requisitos DORA para políticas, registos, controlos e reporte à gestão.
• Defina a justificação de proporcionalidade para gestão simplificada ou escalada do risco de TIC, quando aplicável.
• Atribua responsabilização executiva por risco de TIC, comunicação de incidentes, supervisão de terceiros e testes.
• Inclua o estado DORA na revisão pela gestão e no reporte de risco ao conselho de administração.

Gestão do risco de TIC

• Mantenha um Registo de Riscos de TIC com descrição, probabilidade, impacto, pontuação, proprietário e plano de tratamento.
• Ligue riscos a funções críticas ou importantes.
• Ligue riscos a ativos de TIC, fornecedores e processos.
• Reveja riscos após incidentes graves, alterações de fornecedores, alterações tecnológicas ou constatações de testes.
• Acompanhe ações de tratamento até ao encerramento ou aceitação formal do risco.

Supervisão de terceiros de TIC

• Mantenha um registo centralizado de fornecedores e um registo de dependências de fornecedores.
• Identifique fornecedores que suportam funções críticas ou importantes.
• Avalie fornecedores de fonte única e o grau de substituibilidade.
• Reveja subcontratantes e acordos de subcontratação em cadeia.
• Inclua nos contratos cláusulas de segurança, acesso, comunicação de incidentes, auditoria e saída.
• Monitorize fornecedores críticos pelo menos anualmente ou após alterações materiais.
• Mantenha planos de saída e contingência para prestadores com elevada dependência.

Gestão e comunicação de incidentes

• Mantenha procedimentos de resposta a incidentes com papéis e vias de escalonamento claros.
• Defina critérios de classificação de incidentes de TIC.
• Alinhe acionadores de reporte DORA com obrigações de notificação do RGPD da UE, NIS2 e contratos.
• Forme trabalhadores e contratados nos canais de comunicação de incidentes.
• Mantenha logs de incidentes, registos de decisão e evidência.
• Conduza revisões pós-incidente e atualize riscos e controlos.

Testes, red teaming e TLPT

• Mantenha um calendário de testes baseado no risco.
• Realize varrimentos de vulnerabilidades e testes de intrusão em intervalos definidos.
• Utilize exercícios de red team baseados em cenários para testar deteção e resposta.
• Para preparação TLPT, defina âmbito, regras de atuação, controlos de segurança e coordenação com fornecedores.
• Proteja sistemas de produção durante os testes.
• Acompanhe constatações, remediação, reteste e lições aprendidas.
• Reporte resultados dos testes à gestão.

Continuidade e recuperação

• Realize BIA anual para unidades de negócio críticas e atualize-a após alterações significativas.
• Defina objetivos de recuperação para funções críticas e serviços de TIC de suporte.
• Teste capacidades de BCP e recuperação de desastre pelo menos anualmente.
• Inclua cenários de indisponibilidade de fornecedores e incidentes cibernéticos.
• Preserve evidência de testes, lacunas, ações de remediação e resultados de reteste.
• Alinhe planos de continuidade com resposta a incidentes e comunicações de crise.

Como a Clarysec ajuda entidades financeiras a passar de resultados de pesquisa para evidência preparada para auditoria

A preparação DORA 2026 não se alcança descarregando uma lista de verificação e esperando que a organização preencha as lacunas mais tarde. Exige um modelo operacional estruturado que ligue risco, fornecedores, incidentes, testes, continuidade e evidência de auditoria.

A abordagem da Clarysec combina três camadas.

Primeiro, o Zenith Blueprint fornece o roteiro de implementação. O passo 14 ajuda as organizações a cruzar requisitos regulamentares com tratamento de riscos e políticas. O passo 16 reforça a comunicação de incidentes orientada para as pessoas. O passo 21 assegura que auditorias e testes não colocam sistemas de produção em risco. O passo 23 transforma a supervisão de fornecedores num fluxo de trabalho prático que cobre classificação, contratos, subcontratantes, monitorização e avaliação da nuvem.

Segundo, as políticas Clarysec fornecem governação pronta a operacionalizar. A Política de Gestão de Riscos, a Política de Cumprimento Legal e Regulamentar, a Política de Segurança de Terceiros e Fornecedores, a Política de Gestão do Risco de Dependência de Fornecedores, a Política de Resposta a Incidentes, a Política de Testes de Segurança e Red Teaming e a Política de Continuidade de Negócio e Recuperação de Desastre dão às equipas cláusulas concretas, modelos de propriedade e expectativas de evidência.

Terceiro, os Zenith Controls fornecem o mapa de conformidade cruzada. Mostram como a segurança da cadeia de fornecimento de TIC, o planeamento da gestão de incidentes e a revisão independente se ligam à DORA, ao RGPD da UE, à NIS2, à ISO/IEC 27001:2022, à ISO/IEC 27002:2022, à ISO/IEC 27035, à ISO/IEC 27036, à ISO/IEC 22320, à ISO/IEC 20243, ao COBIT 2019 e às práticas de teste NIST.

O resultado é um programa de conformidade DORA defensável numa auditoria e útil durante um incidente real, falha de fornecedor ou teste de resiliência.

Próximo passo: construa o seu pacote de evidência DORA antes do próximo pedido de auditoria

Se a sua equipa ainda pesquisa “lista de verificação RTS/ITS DORA”, “modelo de gestão do risco de TIC DORA”, “supervisão de terceiros DORA” ou “requisitos TLPT DORA”, o próximo passo é transformar essas pesquisas em evidência controlada.

Comece com quatro ações esta semana:

1. Crie ou atualize o seu Registo de Conformidade DORA utilizando o modelo de políticas Clarysec.
2. Selecione uma função crítica e siga-a através do Registo de Riscos, do registo de dependências de fornecedores, do fluxo de incidentes, da BIA e do plano de testes.
3. Reveja os seus cinco principais fornecedores de TIC quanto a grau de substituibilidade, subcontratantes, cláusulas de incidentes e opções de saída.
4. Construa um pacote de evidência de testes com âmbito, autorização, resultados, remediação e reteste.

A Clarysec pode ajudá-lo a implementar isto com o Zenith Blueprint, modelos de políticas e Zenith Controls, para que o seu programa DORA 2026 seja prático, proporcional e preparado para auditoria.