Estratégias de saída de TIC ao abrigo do DORA com controlos ISO 27001

Às 07:42 de uma segunda-feira, o responsável de operações de uma fintech recebe a mensagem que ninguém quer ler: o prestador de monitorização de transações alojado na nuvem sofreu uma indisponibilidade regional grave. Às 08:15, o Diretor de Risco (CRO) quer saber se o serviço afetado suporta uma função crítica ou importante. Às 08:40, o departamento jurídico quer confirmar se o contrato concede à empresa assistência à transição, exportação de dados, eliminação e direitos de auditoria. Às 09:05, o CISO procura evidência de que o plano de saída foi testado, e não apenas redigido.

Noutra empresa de serviços financeiros, Sarah, CISO de uma plataforma fintech em rápido crescimento, abre um pedido de informação pré-auditoria para uma avaliação de conformidade com o DORA. As perguntas são familiares até chegar à secção sobre prestadores terceiros de serviços de TIC que suportam funções críticas ou importantes. Os auditores não perguntam se a empresa tem uma política de fornecedores. Pedem estratégias de saída documentadas, testadas e viáveis.

O seu pensamento passa de imediato para o prestador principal de serviços em nuvem que aloja a plataforma, depois para o prestador de serviços de segurança geridos que monitoriza ameaças 24 horas por dia. E se o prestador de serviços em nuvem sofrer uma perturbação geopolítica? E se o MSSP for adquirido por um concorrente? E se um prestador SaaS crítico se tornar insolvente, terminar o serviço ou perder a confiança dos clientes após um incidente grave?

A resposta desconfortável em muitas organizações é a mesma. Existe uma avaliação de riscos de fornecedores, um Plano de Continuidade de Negócio (BCP), uma pasta de contratos, um inventário de serviços em nuvem e talvez um relatório de cópias de segurança. Mas não existe uma estratégia única de saída de TIC ao abrigo do DORA para terceiros, preparada para auditoria, que ligue criticidade do negócio, direitos contratuais, portabilidade técnica, planos de continuidade, evidência de cópias de segurança, obrigações de privacidade e aprovação pela gestão.

O DORA muda o tom da gestão de fornecedores. Nos termos do Regulamento (UE) 2022/2554, as entidades financeiras devem gerir o risco de terceiros de TIC como parte do quadro de gestão do risco de TIC. Mantêm responsabilidade integral pela conformidade, conservam um registo dos contratos de serviços de TIC, distinguem acordos de TIC que suportam funções críticas ou importantes, avaliam riscos de concentração e subcontratação e mantêm estratégias de saída para dependências críticas de terceiros de TIC. O DORA aplica-se desde 17 de janeiro de 2025 e estabelece requisitos uniformes da UE para gestão do risco de TIC, notificação de incidentes, testes de resiliência, partilha de informações e gestão do risco de terceiros de TIC num amplo conjunto de entidades financeiras.

Uma estratégia de saída ao abrigo do DORA não é um parágrafo num contrato de fornecedor. É um sistema de controlo. Deve ter governação, estar sujeita a avaliação de risco, ser tecnicamente viável, contratualmente exigível, testada, sustentada por evidência e melhorada continuamente.

A abordagem da Clarysec combina o Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, modelos de políticas empresariais e o Zenith Controls: The Cross-Compliance Guide Zenith Controls para transformar a pergunta dessa segunda-feira de manhã numa resposta preparada.

Porque falham as estratégias de saída DORA em auditorias reais

A maioria das falhas em estratégias de saída de TIC ao abrigo do DORA é estrutural antes de ser técnica. A organização tem um responsável pelo fornecedor, mas não um responsável pelo risco. Tem tarefas de cópia de segurança, mas não evidência de restauro. Tem um questionário de due diligence de fornecedores, mas não uma decisão documentada sobre se o prestador suporta uma função crítica ou importante. Tem linguagem contratual de cessação, mas não um período de transição alinhado com o Plano de Continuidade de Negócio (BCP).

O DORA obriga a articular estes elementos. O Article 28 estabelece os princípios gerais da gestão do risco de terceiros de TIC, incluindo a necessidade de gerir o risco dos prestadores terceiros de serviços de TIC ao longo de todo o ciclo de vida e manter estratégias de saída adequadas. O Article 30 define requisitos contratuais detalhados para serviços de TIC que suportam funções críticas ou importantes, incluindo descrições dos serviços, locais de tratamento de dados, proteções de segurança, direitos de acesso e auditoria, assistência em incidentes, cooperação com autoridades competentes e direitos de cessação.

O regulamento também é proporcional. Os Articles 4 e 16 permitem que determinadas entidades mais pequenas ou isentas apliquem um quadro simplificado de gestão do risco de TIC. Mas simplificado não significa não documentado. As entidades financeiras mais pequenas continuam a precisar de gestão do risco de TIC documentada, monitorização contínua, sistemas resilientes, identificação rápida de incidentes de TIC, identificação de dependências críticas de terceiros de TIC, cópia de segurança e restauro, continuidade de negócio, resposta e recuperação, testes, lições aprendidas e formação.

Uma pequena fintech não pode dizer: “Somos demasiado pequenos para planeamento de saída.” Pode dizer: “A nossa estratégia de saída ao abrigo do DORA é dimensionada à nossa dimensão, perfil de risco e complexidade dos serviços.” A diferença está na evidência.

Para entidades que também se enquadram no âmbito nacional da NIS2, o DORA funciona como o ato jurídico setorial da União para obrigações de cibersegurança sobrepostas no setor financeiro. A NIS2 continua relevante no ecossistema mais amplo, especialmente para prestadores de serviços geridos, prestadores de serviços de segurança geridos, prestadores de serviços em nuvem, centros de dados e entidades de infraestrutura digital. O NIS2 Article 21 reforça os mesmos temas: análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição segura, avaliação da eficácia, formação, criptografia, controlo de acesso, gestão de ativos e autenticação.

Supervisores, clientes, auditores e conselhos de administração podem formular a pergunta de modo diferente, mas a questão central é consistente: consegue sair de um prestador crítico de TIC sem perder controlo sobre a continuidade do serviço, os dados, a evidência ou o impacto nos clientes?

Integrar a estratégia de saída no SGSI

A ISO/IEC 27001:2022 fornece a espinha dorsal de sistema de gestão para o planeamento de saída ao abrigo do DORA.

As Clauses 4.1 a 4.4 exigem que a organização defina o seu contexto, partes interessadas, requisitos legais, regulamentares e contratuais, âmbito do SGSI, interfaces, dependências e processos. É aqui que uma entidade financeira identifica DORA, compromissos com clientes, expectativas de outsourcing, dependências de serviços em nuvem, obrigações de privacidade, subcontratantes e serviços de TIC dentro do perímetro do SGSI.

As Clauses 5.1 a 5.3 exigem liderança, política, recursos, atribuição de funções e responsabilização. Isto alinha-se com o modelo de governação do DORA, no qual o órgão de administração define, aprova, supervisiona e permanece responsável pela gestão do risco de TIC, incluindo continuidade de negócio de TIC, planos de resposta e recuperação, planos de auditoria de TIC, orçamentos, estratégia de resiliência e política de risco de terceiros de TIC.

As Clauses 6.1.1 a 6.1.3 convertem o planeamento de saída em tratamento de riscos. A organização define critérios de risco, executa avaliações de risco repetíveis, identifica riscos para a confidencialidade, integridade e disponibilidade, atribui responsáveis pelo risco, avalia consequências e probabilidade, seleciona opções de tratamento, compara controlos com o Anexo A, produz uma Declaração de Aplicabilidade, prepara um plano de tratamento de riscos e obtém aprovação do responsável pelo risco e aceitação do risco residual.

A Clause 8.1 exige, em seguida, planeamento e controlo operacional. A organização deve planear, implementar e controlar processos do SGSI, manter informação documentada que demonstre que os processos foram executados conforme planeado, gerir alterações e controlar processos, produtos ou serviços fornecidos externamente que sejam relevantes para o SGSI.

A ISO/IEC 27005:2022 reforça esta abordagem. A Clause 6.2 recomenda que as organizações identifiquem os requisitos das partes interessadas, incluindo os controlos do Anexo A da ISO/IEC 27001:2022, normas setoriais, regulamentos nacionais e internacionais, regras internas, requisitos contratuais e controlos existentes decorrentes de tratamento de riscos anterior. As Clauses 6.4.1 a 6.4.3 explicam que os critérios de risco devem considerar aspetos legais e regulamentares, relações com fornecedores, privacidade, impactos operacionais, incumprimentos contratuais, operações de terceiros e consequências reputacionais. As Clauses 8.2 a 8.6 suportam uma biblioteca de controlos e um plano de tratamento que podem combinar o Anexo A da ISO/IEC 27001:2022 com DORA, NIS2, RGPD da UE, compromissos com clientes e políticas internas.

O modelo operacional é simples: um inventário de requisitos, um registo de riscos de fornecedores, uma Declaração de Aplicabilidade, um plano de tratamento de riscos e um pacote de evidência para cada cenário crítico de saída.

Os controlos ISO/IEC 27001:2022 que ancoram o planeamento de saída DORA

As estratégias de saída ao abrigo do DORA ficam preparadas para auditoria quando a governação de fornecedores, a portabilidade na nuvem, o planeamento de continuidade e a evidência de cópias de segurança são tratados como uma cadeia de controlos ligada.

O Zenith Controls da Clarysec mapeia os controlos do Anexo A da ISO/IEC 27001:2022 para atributos de controlo, evidência de auditoria e expectativas de conformidade cruzada. Não é um quadro de controlos separado. É o guia de conformidade cruzada da Clarysec para compreender como os controlos ISO/IEC 27001:2022 suportam resultados de auditoria, regulamentares e operacionais.

Para uma estratégia de saída de TIC ao abrigo do DORA para terceiros, o trilho de auditoria deve demonstrar que:

• O fornecedor está classificado e ligado a processos de negócio.
• O serviço foi avaliado quanto ao suporte a uma função crítica ou importante.
• O risco de saída está registado com um responsável pelo risco.
• As cláusulas contratuais suportam transição, acesso, auditoria, devolução de dados, eliminação de dados, cooperação e continuidade.
• A portabilidade e a interoperabilidade na nuvem foram validadas.
• As cópias de segurança e os testes de restauro comprovam a recuperabilidade.
• A substituição temporária ou o processamento alternativo foram documentados.
• Os resultados dos testes de saída foram revistos, remediados e reportados à gestão.

A linguagem contratual é o primeiro controlo de continuidade

Um contrato deve ser o primeiro controlo de continuidade, não uma barreira à continuidade. Se o prestador puder cessar rapidamente, atrasar exportações, restringir o acesso a logs, cobrar encargos de transição indefinidos ou recusar suporte à migração, a estratégia de saída é frágil.

No Zenith Blueprint, a fase Controls in Action, Step 23, Control 5.20, explica que os acordos com fornecedores devem incluir os requisitos práticos de segurança que tornam a saída possível:

As áreas normalmente tratadas em acordos com fornecedores incluem:

✓ Obrigações de confidencialidade, incluindo âmbito, duração e restrições à divulgação a terceiros;

✓ Responsabilidades de controlo de acesso, tais como quem pode aceder aos seus dados, como são geridas as credenciais e que monitorização está implementada;

✓ Medidas técnicas e organizativas para proteção de dados, cifragem, transmissão segura, cópia de segurança e compromissos de disponibilidade;

✓ Prazos e protocolos de notificação de incidentes, frequentemente com prazos definidos;

✓ Direito de auditoria, incluindo frequência, âmbito e acesso a evidência relevante;

✓ Controlos de subcontratantes, exigindo que o seu fornecedor transmita obrigações de segurança equivalentes aos seus parceiros a jusante;

✓ Disposições de fim de contrato, tais como devolução ou destruição de dados, recuperação de ativos e desativação de contas.

Essa lista estabelece a ponte entre as expectativas contratuais do DORA Article 30 e o controlo A.5.20 do Anexo A da ISO/IEC 27001:2022.

A linguagem das políticas empresariais da Clarysec transmite o mesmo ponto de forma operacional. Na Supplier Dependency Risk Management Policy Política de Gestão do Risco de Dependência de Fornecedores, secção “Requisitos de implementação”, a cláusula 6.4.3 estabelece:

Salvaguardas técnicas de contingência: assegurar a portabilidade e a interoperabilidade dos dados para suportar a transição do serviço, se necessário (por exemplo, cópias de segurança regulares em formatos normalizados de um prestador SaaS para permitir a migração).

A mesma política, na cláusula 6.8.2, exige:

Direito a assistência à transição (cláusula de assistência à saída) quando seja necessária uma mudança de prestador, incluindo a continuidade do serviço durante um período de transição definido.

Esta cláusula decide frequentemente se uma estratégia de saída resiste à auditoria. Transforma a saída de um evento abrupto numa transição gerida.

Para entidades mais pequenas, a Third-Party and Supplier Security Policy-sme Política de Segurança de Terceiros e Fornecedores - PME, secção “Requisitos de governação”, cláusula 5.3.6, exige:

Termos de cessação, incluindo devolução segura ou destruição de dados

Para ambientes empresariais, a Third party and supplier security policy Política de Segurança de Terceiros e Fornecedores, secção “Requisitos de implementação da política”, cláusula 6.5.1.2 exige:

Devolução ou destruição certificada de toda a informação pertencente à organização

Esses requisitos de política devem ser diretamente rastreáveis a cláusulas contratuais, procedimentos de fornecedores, runbooks de saída e evidência de auditoria.

Saída da nuvem: teste a portabilidade antes de precisar dela

Os serviços na nuvem são onde as estratégias de saída ao abrigo do DORA frequentemente se tornam vagas. A empresa presume que consegue exportar dados, mas ninguém testou o formato. Presume que a eliminação ocorrerá, mas o modelo de retenção do prestador inclui cópias de segurança e armazenamento replicado. Presume que um prestador alternativo consegue receber os dados, mas esquemas, integrações de identidade, chaves de cifragem, segredos, logs, interfaces de programação de aplicações e limitação de débito tornam a migração mais lenta do que a tolerância ao impacto permite.

O controlo A.5.23 do Anexo A da ISO/IEC 27001:2022 aborda este problema de ciclo de vida ao exigir controlos de segurança da informação para aquisição, utilização, gestão e saída de serviços na nuvem.

A Cloud Usage Policy-sme Política de Utilização da Nuvem - PME, secção “Requisitos de implementação da política”, cláusula 6.3.4, exige:

Capacidade de exportação de dados confirmada antes da integração (por exemplo, para evitar dependência do fornecedor)

A cláusula 6.3.5 exige:

Confirmação dos procedimentos de eliminação segura antes do encerramento da conta

Estes requisitos pertencem ao início do ciclo de vida do fornecedor. Não espere pela cessação para perguntar se os dados podem ser exportados. Não espere pelo encerramento da conta para perguntar se existe evidência de eliminação.

Um teste prático de saída da nuvem ao abrigo do DORA deve incluir:

1. Exportar um conjunto de dados representativo no formato acordado.
2. Validar completude, integridade, carimbos temporais, metadados e controlos de acesso.
3. Importar o conjunto de dados para um ambiente de staging ou ferramenta alternativa.
4. Confirmar o tratamento das chaves de cifragem e a rotação de segredos.
5. Confirmar a exportação de logs e a retenção do trilho de auditoria.
6. Documentar os procedimentos de eliminação do prestador, incluindo retenção de cópias de segurança e certificação de eliminação.
7. Registar problemas, ações de remediação, responsáveis e prazos.
8. Atualizar a avaliação de riscos do fornecedor, a Declaração de Aplicabilidade e o plano de saída.

A portabilidade não é uma promessa de aquisição. É uma capacidade testada.

Um sprint de uma semana para um plano de saída DORA preparado para auditoria

Considere uma instituição de pagamento que utiliza um prestador SaaS de análise de fraude. O prestador ingere dados de transações, identificadores de clientes, telemetria de dispositivos, sinais comportamentais, regras de fraude, resultados de scoring e notas de casos. O serviço suporta um processo crítico de deteção de fraude. A empresa também utiliza um data warehouse em nuvem para armazenar resultados analíticos exportados.

O CISO quer uma estratégia de saída de TIC ao abrigo do DORA para terceiros que resista à auditoria interna e à revisão supervisora. Um sprint de uma semana pode expor lacunas e construir a cadeia de evidência.

Dia 1: classificar o fornecedor e definir o cenário de saída

Utilizando o Zenith Blueprint, fase Controls in Action, Step 23, Action Items for Controls 5.19 to 5.37, a equipa começa por rever e classificar o portefólio de fornecedores:

Compile uma lista completa dos fornecedores e prestadores de serviços atuais (5.19) e classifique-os com base no acesso a sistemas, dados ou controlo operacional. Para cada fornecedor classificado, verifique se as expectativas de segurança estão claramente incorporadas nos contratos (5.20), incluindo confidencialidade, acesso, notificação de incidentes e obrigações de conformidade.

O fornecedor é classificado como crítico porque suporta uma função crítica ou importante, trata dados operacionais sensíveis e afeta os resultados da monitorização de transações.

A equipa define três desencadeadores de saída:

• Insolvência do prestador ou descontinuação do serviço.
• Violação de segurança material ou perda de confiança.
• Migração estratégica para reduzir o risco de concentração.

Dia 2: construir o inventário de requisitos e o registo de riscos

A equipa cria um inventário único de requisitos que abrange risco de terceiros de TIC ao abrigo do DORA, controlos de fornecedores e de serviços em nuvem da ISO/IEC 27001:2022, obrigações do RGPD da UE relativas a dados pessoais, compromissos contratuais com clientes e apetite ao risco interno.

Ao abrigo do RGPD da UE, a empresa confirma se identificadores de transações, IDs de dispositivos, sinais de localização e análise comportamental se relacionam com pessoas identificadas ou identificáveis. Os princípios do GDPR Article 5, incluindo integridade, confidencialidade, limitação da conservação e responsabilização, passam a fazer parte do requisito de evidência de saída. Se a saída envolver transferência para um novo prestador, devem ser documentados o fundamento de licitude, a finalidade, a minimização, a retenção, os termos do subcontratante e as salvaguardas.

O registo de riscos inclui o seguinte:

Dia 3: corrigir lacunas contratuais

Jurídico e compras comparam o contrato com as cláusulas de fornecedores da Clarysec. Acrescentam assistência à transição, continuidade do serviço durante um período de transição definido, acesso a auditoria e evidência, notificação de subcontratantes, formato de exportação de dados, certificação de eliminação segura, cooperação em incidentes e compromissos de tempo de recuperação.

A Business Continuity Policy and Disaster Recovery Policy Política de Continuidade de Negócio e Recuperação de Desastre, secção “Requisitos de implementação da política”, cláusula 6.5.1, estabelece:

Os contratos com fornecedores críticos devem incluir obrigações de continuidade e compromissos de tempo de recuperação.

Para PME, a Business Continuity Policy and Disaster Recovery Policy-sme Política de Continuidade de Negócio e Recuperação de Desastre - PME, secção “Tratamento do risco e exceções”, cláusula 7.2.1.4, exige que as equipas:

documentem planos temporários de substituição de fornecedor ou parceiro

Essa cláusula transforma “vamos migrar” numa contingência acionável: que prestador, que solução alternativa interna, que processo manual, que extração de dados, que responsável e que via de aprovação.

Dia 4: testar a portabilidade dos dados e a recuperabilidade das cópias de segurança

A equipa tecnológica exporta regras de fraude, dados de casos, resultados de scoring de transações, logs, configuração, documentação de interfaces de programação de aplicações e listas de controlo de acesso (ACLs) de utilizadores. Testa se os dados podem ser restaurados ou reutilizados num ambiente controlado.

A Backup and Restore Policy-sme Política de Cópias de Segurança e Restauro - PME, secção “Requisitos de governação”, cláusula 5.3.3, exige:

São realizados testes de restauro pelo menos trimestralmente, e os resultados são documentados para verificar a recuperabilidade

A Backup and Restore Policy Política de Cópias de Segurança e Restauro empresarial, secção “Aplicação e cumprimento”, cláusula 8.3.1, acrescenta:

Auditar periodicamente logs de cópias de segurança, definições de configuração e resultados de testes

No Zenith Blueprint, fase Controls in Action, Step 19, Control 8.13, a Clarysec alerta para a importância deste ponto:

O teste de restauro é onde a maioria das organizações falha. Uma cópia de segurança que não possa ser restaurada a tempo, ou de todo, é um passivo, não um ativo. Agende exercícios regulares de restauro, ainda que apenas parciais, e documente o resultado.

A equipa descobre que as notas de casos exportadas não incluem anexos e que a limitação de débito das interfaces de programação de aplicações torna uma exportação completa demasiado lenta para o objetivo de recuperação definido. O problema é registado, atribuído e remediado através de uma adenda contratual e de uma reformulação técnica da exportação.

Dia 5: executar o exercício tabletop de saída e a revisão da evidência

A equipa realiza um exercício tabletop: o fornecedor anuncia a cessação em 90 dias após um incidente grave. As operações devem manter a monitorização de fraude enquanto os dados são migrados.

No Zenith Blueprint, fase Controls in Action, Step 23, Control 5.30, a Clarysec explica o padrão de teste:

A preparação das TIC começa muito antes de ocorrer uma perturbação. Envolve identificar sistemas críticos, compreender as suas interdependências e mapeá-los para processos de negócio.

A mesma secção acrescenta:

Os Objetivos de Tempo de Recuperação (RTO) e os Objetivos de Ponto de Recuperação (RPO) definidos no Plano de Continuidade de Negócio (BCP) devem refletir-se nas configurações técnicas, nos contratos e na conceção da infraestrutura.

O pacote de evidência inclui classificação do fornecedor, avaliação de riscos, cláusulas contratuais, runbook de saída, resultados de exportação de dados, evidência de restauro de cópias de segurança, procedimento de eliminação, avaliação de prestador alternativo, atas do exercício tabletop, registo de remediação, aprovação pela gestão e decisão sobre risco residual.

O CISO pode agora responder à pergunta do Conselho de Administração com evidência, não com otimismo.

Conformidade cruzada: um plano de saída, várias lentes de auditoria

Uma estratégia de saída DORA robusta reduz trabalho de conformidade duplicado em ISO/IEC 27001:2022, NIS2, RGPD da UE, NIST e expectativas de governação COBIT 2019.

O ponto importante não é que um referencial substitua outro. O valor está em um SGSI bem construído permitir que a organização gere evidência uma vez e a reutilize de forma inteligente.

O Zenith Controls da Clarysec ajuda as equipas a preparar-se para estas lentes de auditoria ao ligar controlos ISO/IEC 27001:2022 a evidência de auditoria e expectativas entre referenciais.

Uma falha comum de auditoria é a fragmentação da evidência. O responsável pelo fornecedor tem o contrato. A TI tem logs de cópias de segurança. O departamento jurídico tem o Acordo de Tratamento de Dados. O Risco tem a avaliação. A Conformidade tem o mapeamento regulamentar. Ninguém tem a história completa.

A Clarysec resolve isto ao desenhar o pacote de evidência em torno do cenário de saída. Cada documento responde a uma pergunta de auditoria: que serviço está a ser descontinuado, porque é crítico, que dados e sistemas são afetados, quem é o responsável pelo risco, que direitos contratuais tornam a saída possível, que mecanismos técnicos tornam a migração possível, que mecanismos de continuidade mantêm o negócio em funcionamento, que teste prova que o plano funciona, que problemas foram remediados e quem aprovou o risco residual.

A checklist Clarysec para estratégias de saída DORA

Use esta checklist para transformar uma estratégia de saída de TIC ao abrigo do DORA para terceiros de um documento num conjunto de controlos auditável.

Transformar o planeamento de saída num controlo de resiliência para o Conselho de Administração

Se a sua estratégia de saída DORA for apenas uma cláusula contratual, não está preparada. Se a sua cópia de segurança nunca foi restaurada, não está preparada. Se o seu prestador de serviços em nuvem consegue exportar dados, mas ninguém validou a completude, não está preparada. Se o seu Conselho de Administração não consegue ver a decisão sobre risco residual, não está preparada.

A Clarysec ajuda CISOs, gestores de conformidade, auditores e responsáveis de negócio a construir estratégias de saída de TIC ao abrigo do DORA para terceiros que sejam práticas, proporcionais e preparadas para auditoria. Combinamos o Zenith Blueprint Zenith Blueprint para sequenciação da implementação, o Zenith Controls Zenith Controls para mapeamento de conformidade cruzada, e modelos de políticas como a Supplier Dependency Risk Management Policy Política de Gestão do Risco de Dependência de Fornecedores, a Cloud Usage Policy - SME Política de Utilização da Nuvem - PME, a Third-Party and Supplier Security Policy - SME Política de Segurança de Terceiros e Fornecedores - PME e a Business Continuity Policy and Disaster Recovery Policy Política de Continuidade de Negócio e Recuperação de Desastre para criar uma cadeia completa de controlo para evidência.

O seu próximo passo é simples e de elevado valor: selecione esta semana um fornecedor crítico de TIC. Classifique-o, reveja o respetivo contrato, teste uma exportação de dados, verifique um restauro, documente um plano de substituição e crie um pacote de evidência.

Esse exercício único mostrará se a sua estratégia de saída DORA é uma verdadeira capacidade de resiliência ou apenas um documento à espera de falhar em auditoria.