Análise de impacto no negócio para ISO 27001, NIS2 e DORA

A pergunta de auditoria que expõe a verdadeira lacuna de continuidade

É segunda-feira de manhã, e Maria, CISO de uma fintech em rápido crescimento, prepara-se para uma reunião do comité de riscos do conselho de administração. O tema é direto: “Preparação para DORA e NIS2: revisão da BIA”.

A sua equipa construiu o que a maioria dos executivos espera ver. Existe um SGSI certificado segundo a ISO/IEC 27001:2022, guias operacionais de resposta a incidentes, capturas de ecrã de cópias de segurança, relatórios de vulnerabilidades, questionários de fornecedores, diagramas de arquitetura de nuvem e um registo de riscos atualizado. Clientes empresariais estão a enviar questionários NIS2. Clientes do setor financeiro estão a introduzir cláusulas DORA nos contratos. A auditoria de acompanhamento ISO/IEC 27001:2022 está a apenas um mês de distância.

Então, o auditor externo faz a pergunta que muda o ambiente da sala:

“Se a vossa plataforma de integração de clientes estiver indisponível durante 18 horas, que serviços regulados são afetados, que fornecedores estão envolvidos, qual é a prioridade de recuperação aprovada e onde está a evidência de que o negócio aceitou o RTO e o RPO?”

A sala fica em silêncio.

O calendário de cópias de segurança diz uma coisa. O plano de recuperação de desastres diz outra. O contrato com o fornecedor inclui um SLA de disponibilidade, mas não apresenta evidência de teste de recuperação. O registo de riscos menciona disponibilidade, mas não explica por que motivo um serviço deve recuperar mais rapidamente do que outro. A gestão aprovou a política de segurança, mas não o impacto no negócio da indisponibilidade.

Esse é o problema da análise de impacto no negócio em 2026.

Uma análise de impacto no negócio, ou BIA, já não é uma folha de cálculo anexada a um plano de continuidade. É a ponte de evidência entre serviços de negócio, ativos de TIC, fornecedores, prioridades de recuperação, RTO/RPO, limiares de incidente, testes de resiliência e responsabilização do conselho de administração. Para organizações que alinham a ISO/IEC 27001:2022 com continuidade NIS2 e resiliência das TIC DORA, a BIA é o ponto em que a conformidade se torna operacional.

As organizações mais fortes já têm muitos dos controlos certos. A sua fragilidade está na rastreabilidade. A BIA transforma evidência dispersa numa narrativa preparada para auditoria: o que é relevante, por que é relevante, com que rapidez deve recuperar, que dependências o suportam, o que foi testado, o que falhou, o que foi melhorado e quem aprovou o risco residual.

Por que as antigas folhas de cálculo de BIA são agora um passivo

NIS2 e DORA alteraram o tom da conformidade em matéria de continuidade. Já não tratam continuidade do negócio, recuperação de desastres, resposta a incidentes, resiliência de fornecedores e governação como documentos separados. Esperam que funcionem como um único sistema.

Para entidades abrangidas pela NIS2, o Article 21 exige medidas técnicas, operacionais e organizacionais para gerir riscos que afetem sistemas de rede e de informação e para prevenir ou minimizar o impacto de incidentes nos destinatários dos serviços e noutros serviços. As suas medidas mínimas incluem análise de riscos, tratamento de incidentes, continuidade do negócio incluindo gestão de cópias de segurança, recuperação de desastres e gestão de crises, segurança da cadeia de fornecimento, tratamento de vulnerabilidades, avaliação da eficácia dos controlos, formação, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, MFA e comunicações seguras.

O NIS2 Article 20 leva o tema para a sala do conselho. Os órgãos de gestão devem aprovar as medidas de gestão de riscos de cibersegurança, supervisionar a sua implementação e podem ser responsabilizados por infrações. Isso significa que um RTO de quatro horas sem suporte não é apenas uma inconsistência técnica. É uma fragilidade de governação.

O DORA aplica-se a partir de 17 de janeiro de 2025 e cria um quadro uniforme da UE para gestão do risco das TIC, notificação de incidentes, testes de resiliência operacional digital, gestão de risco de terceiros de TIC, requisitos contratuais e supervisão de prestadores terceiros críticos de serviços de TIC. Para entidades financeiras, e para prestadores de tecnologia que as suportam por via contratual, o DORA transforma a resiliência operacional num requisito estruturado de evidência.

Os DORA Articles 5 e 6 exigem governação e um quadro documentado de gestão do risco das TIC. Os Articles 7 a 14 abrangem sistemas de TIC fiáveis e resilientes, identificação de ativos e dependências, proteção, deteção, continuidade do negócio das TIC, cópia de segurança, restauro, recuperação, aprendizagem pós-incidente, sensibilização, formação e comunicação de crise. Os Articles 24 a 26 exigem testes de resiliência operacional digital para entidades financeiras que não sejam microempresas. Os Articles 28 a 30 formalizam risco de terceiros de TIC, registos de contratos de serviços de TIC, estratégias de saída, níveis de serviço, direitos de auditoria e requisitos de contingência.

A ISO/IEC 27001:2022 fornece a espinha dorsal do sistema de gestão. As suas cláusulas exigem que a organização defina contexto, partes interessadas, obrigações legais e contratuais, âmbito, liderança, política, papéis, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, planeamento operacional, avaliação de desempenho e melhoria contínua.

O elo em falta é frequentemente a BIA. Sem ela, os planos de continuidade não são claramente baseados no risco, os objetivos de cópia de segurança não são aprovados pelo negócio, os fornecedores não são mapeados para serviços críticos e a gestão não consegue demonstrar de forma fiável que as decisões de resiliência foram informadas pelo impacto no negócio.

A BIA como plano de controlo da evidência de resiliência

Uma BIA defensável responde a sete perguntas que auditores, reguladores, clientes e conselhos de administração fazem cada vez mais:

1. Que serviços de negócio são críticos?
2. Que ativos de TIC, repositórios de dados, pessoas, fornecedores e utilidades suportam cada serviço?
3. Qual é o impacto operacional, financeiro, jurídico, contratual, no cliente, na segurança e reputacional da disrupção ao longo do tempo?
4. Qual é o Tempo Máximo de Interrupção Tolerável, ou MTD?
5. Quais são o Objetivo de Tempo de Recuperação aprovado, ou RTO, e o Objetivo de Ponto de Recuperação, ou RPO?
6. As disposições de cópia de segurança, redundância, nuvem, fornecedores, pessoal e comunicação tornam esses objetivos alcançáveis?
7. A organização testou o percurso de recuperação e reviu os resultados?

A Política de Continuidade do Negócio e Recuperação de Desastres empresarial da Clarysec P32 Política de Continuidade do Negócio e Recuperação de Desastres estabelece o requisito de forma clara:

A análise de impacto no negócio (BIA) deve ser realizada pelo menos anualmente para todas as unidades de negócio críticas e revista quando ocorram alterações significativas em sistemas, processos ou dependências. Os resultados da BIA devem definir: 5.2.1. Tempo Máximo de Interrupção Tolerável (MTD) 5.2.2. Objetivos de Tempo de Recuperação (RTOs) 5.2.3. Objetivos de Ponto de Recuperação (RPOs) 5.2.4. Dependências críticas (sistemas, fornecedores, pessoal)

Essa cláusula dá aos auditores um ponto de partida prático. Também evita a falha comum em que o plano de continuidade do negócio, o plano de recuperação de desastres, o calendário de cópias de segurança, o registo centralizado de fornecedores e o processo de resposta a incidentes usam cada um uma definição diferente de “crítico”.

A mesma política exige uma abordagem integrada de gestão:

A organização deve manter um sistema de gestão da continuidade do negócio integrado, alinhado com a ISO 22301 e a ISO/IEC 27001, assegurando a integração de: 5.1.1. Análise de impacto no negócio (BIA) 5.1.2. Avaliação de riscos de segurança para ameaças à continuidade 5.1.3. Planos de Continuidade do Negócio (BCP) 5.1.4. Planos de Recuperação de Desastres (DRP) de TIC 5.1.5. Programas de testes e exercícios 5.1.6. Documentação e melhoria contínua

Esta é a diferença entre conformidade por lista de verificação e resiliência preparada para auditoria. A BIA não é um documento pontual. Passa a integrar a cadeia de evidência do SGSI e do sistema de gestão da continuidade do negócio.

Como a ISO/IEC 27001:2022 transforma a BIA em evidência auditável

A ISO/IEC 27001:2022 não exige que todas as organizações utilizem a expressão “análise de impacto no negócio” em todas as cláusulas, mas os seus requisitos tornam a evidência de BIA extremamente valiosa.

As cláusulas 4.1 a 4.4 exigem que a organização compreenda questões internas e externas, partes interessadas, obrigações legais e regulamentares, requisitos contratuais, interfaces, dependências e o âmbito do SGSI. Uma BIA é frequentemente a evidência mais prática para essas interfaces e dependências. Mostra que serviço na nuvem, processador de pagamentos, fornecedor de identidade, operador de telecomunicações, serviço gerido de segurança, centro de dados ou equipa de suporte externalizada viabiliza um serviço crítico.

As cláusulas 5.1 a 5.3 exigem liderança da alta direção, recursos, comunicação, atribuição de papéis e reporte. Uma BIA dá à liderança uma base de negócio para investimentos em continuidade. Sem ela, os objetivos de RTO e RPO são intenções técnicas, não requisitos de negócio aprovados.

As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos e tratamento de riscos de segurança da informação de forma repetível. A organização deve identificar riscos para a confidencialidade, integridade e disponibilidade, analisar consequências e probabilidade, determinar níveis de risco, priorizar o tratamento, selecionar controlos, comparar os controlos selecionados com o Anexo A, produzir uma Declaração de Aplicabilidade, criar um plano de tratamento de riscos e obter aprovação do Proprietário do Risco. Uma BIA reforça o lado das “consequências” da avaliação de riscos. Explica por que motivo uma indisponibilidade de duas horas num sistema é tolerável, enquanto uma indisponibilidade de duas horas noutro provoca dano ao cliente, exposição regulatória, incumprimento contratual ou impacto severo na receita.

O Anexo A fornece o catálogo de controlos. Para BIA e continuidade, os controlos mais relevantes do Anexo A da ISO/IEC 27001:2022 incluem:

Em Zenith Controls: Guia de Conformidade Cruzada Zenith Controls, a Clarysec descreve o controlo 5.30 da ISO/IEC 27002:2022, preparação das TIC para continuidade do negócio, como um controlo corretivo focado na disponibilidade, mapeado para o conceito de cibersegurança Respond, para a capacidade operacional de continuidade e para o domínio de segurança de resiliência. O controlo 5.29, segurança da informação durante disrupção, é descrito como preventivo e corretivo, protegendo confidencialidade, integridade e disponibilidade. O controlo 8.13, cópia de segurança da informação, é descrito como corretivo, suportando integridade e disponibilidade por meio da recuperação.

Essa distinção é importante. Uma BIA não deve perguntar apenas: “Conseguimos restaurar?” Deve também perguntar: “Conseguimos manter a segurança durante a disrupção?” Durante um evento de ransomware, indisponibilidade de nuvem, falha de fornecedor ou incidente no centro de dados, a organização continua a precisar de controlo de acesso, registo, monitorização, preservação de evidência, comunicações seguras e salvaguardas de privacidade.

O modelo prático de evidência da BIA

Uma BIA robusta liga a linguagem do negócio à prova técnica. A Clarysec estrutura normalmente o modelo de evidência em cinco camadas.

Este modelo de evidência funciona porque segue a forma como os auditores pensam. Primeiro, perguntam o que é crítico. Depois, perguntam o que o suporta. Em seguida, perguntam quem aprovou o objetivo de recuperação. Depois, perguntam se as disposições técnicas e de fornecedores conseguem cumprir o objetivo. Por fim, perguntam se a organização testou e melhorou a capacidade.

O NIST CSF 2.0 é útil como camada de comunicação. O seu método de Perfis CSF incentiva as organizações a definir o âmbito, recolher entradas como políticas, prioridades de risco empresarial, registos de BIA, requisitos de cibersegurança, normas, procedimentos, salvaguardas e funções de trabalho, criar perfis atuais e alvo, analisar lacunas, produzir um plano de ação priorizado, implementar esse plano e atualizar o perfil. É praticamente assim que uma BIA deve alimentar um roteiro de conformidade cruzada.

Um exercício de BIA de uma semana que cria evidência real

Imagine um prestador SaaS que suporta clientes de serviços financeiros. A sua plataforma suporta integração de clientes, verificação documental e notificações a clientes. Não é um banco, mas os seus clientes estão a enviar pedidos contratuais orientados pelo DORA e questionários de fornecedores NIS2.

Um exercício focado de uma semana pode criar rapidamente evidência útil.

Dia 1: Identificar serviços críticos e janelas de impacto

Comece pelos serviços, não pelos servidores. Envolva proprietários do negócio, TI, segurança, jurídico, suporte, privacidade e gestão de fornecedores.

Este enquadramento é importante. Reguladores e clientes reconhecem serviços e funções. As aplicações importam porque suportam esses serviços.

Dia 2: Mapear dependências

Para cada serviço, mapeie aplicações, bases de dados, infraestrutura, serviços na nuvem, fornecedores de identidade, monitorização, ferramentas de cópia de segurança, pessoas, fornecedores e utilidades de suporte.

É aqui que a BIA começa a gerar valor. Revela o percurso de recuperação invisível, incluindo dependências que muitas vezes ficam fora de um plano técnico de recuperação de desastres.

Dia 3: Aprovar MTD, RTO e RPO

O proprietário do negócio propõe o MTD. TI e segurança validam se o RTO e o RPO propostos são tecnicamente alcançáveis. A gestão aprova os objetivos finais.

Para organizações mais pequenas, a Política de Continuidade do Negócio e Recuperação de Desastres - PME da Clarysec P32S Política de Continuidade do Negócio e Recuperação de Desastres - PME aplica a mesma disciplina em linguagem mais simples. Exige planos BCP/DR que definam a abordagem para restaurar funções essenciais:

O Diretor-Geral (GM) deve aprovar e manter Planos de Continuidade do Negócio e Recuperação de Desastres (BCP/DRP) que definam claramente a abordagem da organização para restaurar funções essenciais.

Também exige que o plano inclua:

serviços e sistemas priorizados (funções críticas do negócio)

E:

Objetivos de Tempo de Recuperação (RTOs) e Objetivos de Ponto de Recuperação (RPOs) para cada sistema

A chave não é documentação excessiva. A chave é rastreabilidade, aprovação e evidência de que os objetivos de recuperação se baseiam em impacto real no negócio.

Dia 4: Reconciliar cópias de segurança com impacto no negócio

Muitas organizações falham aqui. A BIA pode definir um RPO de quatro horas, enquanto as cópias de segurança são executadas a cada 24 horas. Ou a ferramenta de cópia de segurança protege bases de dados de produção, mas não configuração, segredos, repositórios de infraestrutura como código, armazenamento de objetos, registos DNS, definições de identidade ou configuração do gateway de API.

A Política de Cópias de Segurança e Restauro da Clarysec P15 Política de Cópias de Segurança e Restauro exige um Calendário-Mestre de Cópias de Segurança ligado aos resultados da BIA:

Deve ser mantido e revisto anualmente um Calendário-Mestre de Cópias de Segurança. Deve especificar: 5.1.1 Frequência das cópias de segurança (por exemplo, cópias de segurança incrementais diárias e cópias de segurança completas semanais) 5.1.2 Prazos de retenção por sistema ou tipo de dados 5.1.3 Requisitos de cifragem e detalhes da localização de armazenamento 5.1.4 Objetivos RTO/RPO ligados aos resultados da avaliação de impacto no negócio

Esta cláusula é ouro em auditoria. Obriga o desenho de cópias de segurança a refletir o impacto no negócio, não a conveniência de armazenamento.

Dia 5: Testar um percurso de recuperação e abrir ações corretivas

Não teste tudo de uma vez. Escolha um serviço crítico e execute um teste de recuperação focado. Restaure a base de dados. Recrie a configuração da aplicação. Valide a autenticação. Confirme que os logs estão disponíveis. Verifique a capacidade de notificação a clientes. Registe o tempo gasto, a perda de dados, defeitos, decisões e ações corretivas.

Em Zenith Blueprint: roteiro de 30 passos de um auditor Zenith Blueprint, a fase Controlos em Ação, passo 23, aborda controlos organizacionais, incluindo a preparação das TIC para continuidade do negócio. Coloca a pergunta que todas as equipas de auditoria devem fazer:

Os seus sistemas conseguem suportar os objetivos de continuidade do negócio quando as luzes piscam, quando as redes falham, quando ocorre um desastre?

O mesmo passo dá uma instrução prática:

Verifique se os objetivos de tempo de recuperação (RTO) e os objetivos de ponto de recuperação (RPO) para sistemas críticos estão alinhados com as expectativas de continuidade do negócio (5.30). Realize pelo menos um teste técnico de recuperação ou uma simulação de failover e documente os resultados.

Essa é a diferença entre ter uma BIA e ter evidência de BIA defensável. O objetivo não está apenas documentado. Está testado.

Mapeamento da evidência de BIA para NIS2, DORA, RGPD da UE, NIST e COBIT 2019

Uma BIA bem construída torna-se um ativo de conformidade cruzada. Um único conjunto de evidência pode responder a muitas perguntas.

O RGPD da UE é frequentemente esquecido nas discussões sobre BIA. No entanto, o GDPR Article 5 exige que os dados pessoais sejam tratados com integridade e confidencialidade, incluindo proteção contra perda, destruição ou dano acidental por meio de medidas técnicas ou organizativas adequadas. A responsabilização exige que o responsável pelo tratamento demonstre conformidade. Se uma plataforma de dados pessoais não puder ser restaurada dentro de um prazo aprovado e testado, o risco de privacidade afeta disponibilidade, integridade, avaliação de violação e confiança do cliente.

A notificação de incidentes NIS2 acrescenta outra dimensão. O Article 23 exige que incidentes significativos sejam notificados sem demora injustificada, incluindo um alerta precoce no prazo de 24 horas, notificação de incidente no prazo de 72 horas e relatório final no prazo de um mês. Uma BIA ajuda a classificar a severidade porque define os serviços afetados, os destinatários dos serviços, a disrupção operacional e o potencial impacto transfronteiriço.

A classificação de incidentes DORA também considera clientes ou transações afetados, duração, distribuição geográfica, perdas de dados, criticidade dos serviços afetados e impacto económico. Estes são campos de BIA. Se a BIA for fraca, a classificação de incidentes torna-se subjetiva no pior momento possível.

Continuidade de fornecedores é onde a BIA encontra a realidade contratual

Para NIS2 e DORA, a continuidade de fornecedores deixou de ser opcional. O NIS2 Article 21 inclui segurança da cadeia de fornecimento e exige atenção a vulnerabilidades de fornecedores, qualidade e resiliência de produtos, práticas de cibersegurança de fornecedores e procedimentos de desenvolvimento seguro. O DORA exige que o risco de terceiros de TIC seja gerido no quadro de risco das TIC, incluindo registos de contratos de serviços de TIC, diligência prévia, risco de concentração, estratégias de saída, direitos de auditoria e acesso, assistência em incidentes, níveis de serviço e requisitos de contingência.

A Política de Continuidade do Negócio e Recuperação de Desastres empresarial exige:

Dependências de terceiros e da cadeia de fornecimento 6.5.1. Os contratos com fornecedores críticos devem incluir obrigações de continuidade e compromissos de tempo de recuperação. 6.5.2. Os principais prestadores de serviços devem, mediante pedido, demonstrar testes periódicos de continuidade e participação em exercícios de incidentes.

A versão PME também exige:

pontos de contacto de continuidade de fornecedores

Esse pequeno campo pode ser decisivo num incidente real. Se o seu plano de recuperação diz “contactar suporte do prestador cloud”, mas ninguém conhece a via de escalonamento, referência contratual, processo de severidade ou contacto fora do horário, o RTO é fictício.

Esta tabela não substitui a gestão do risco de fornecedores. Torna o risco de fornecedores operacional.

Como os auditores testarão a sua BIA

Um auditor ISO/IEC 27001:2022 normalmente começa por âmbito, contexto, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, controlos do Anexo A, informação documentada, planeamento operacional, avaliação de desempenho e melhoria. Irá comparar a BIA com a avaliação de riscos e a SoA. Se A.5.30, A.5.29 ou A.8.13 estiverem incluídos, pedirá evidência de implementação e testes.

Um revisor DORA focar-se-á em funções críticas ou importantes, ativos de TIC, dependências de terceiros de TIC, testes de resiliência, classificação de incidentes, requisitos contratuais, estratégias de saída e supervisão pelo órgão de gestão. Esperará que a BIA esteja alinhada com o quadro de gestão do risco das TIC, a estratégia de resiliência operacional digital, os planos de continuidade do negócio das TIC, os planos de resposta e recuperação e o programa de testes.

Um supervisor NIS2 pedirá medidas de continuidade do negócio, gestão de cópias de segurança, recuperação de desastres, gestão de crises, segurança da cadeia de fornecimento, aprovação de governação e capacidade de notificação de incidentes significativos. A BIA deve demonstrar que essas medidas se baseiam no impacto dos serviços e em prioridades aprovadas.

Um avaliador NIST CSF 2.0 perguntará de que forma a BIA informa o Perfil Atual, o Perfil Alvo, a análise de lacunas e o plano de ação. Examinará os resultados Govern relativos a decisões legais, regulamentares, contratuais, de risco, papéis, política, supervisão e risco de fornecedores. Também analisará os resultados Identify, Protect, Detect, Respond e Recover.

Um auditor COBIT 2019 ou com abordagem ISACA normalmente focar-se-á na governação. Quem é proprietário do serviço? Quem aceitou o risco? Os objetivos estão alinhados com as metas empresariais? Os fornecedores são monitorizados? Benefícios, risco e recursos estão equilibrados? As ações corretivas são acompanhadas até ao encerramento?

A Política de Auditoria e Monitorização da Conformidade da Clarysec Política de Auditoria e Monitorização da Conformidade torna a BIA parte do ciclo de planeamento de auditoria:

Deve ser desenvolvido e aprovado anualmente um Plano de Auditoria baseado no risco, tendo em conta: 5.2.1 Os resultados das avaliações de riscos e da análise de impacto no negócio (BIA) mais recentes 5.2.2 Constatações de auditoria anteriores e estado das ações corretivas 5.2.3 Alterações em processos, infraestrutura de TI, sistemas ou fornecedores 5.2.4 Obrigações externas, como o DORA Article 25 ou contratos de clientes

Este é um passo de maturidade que muitas organizações ignoram. A BIA não deve ficar fora da garantia. Deve orientar o plano de auditoria.

Falhas comuns de BIA encontradas em avaliações reais

As mesmas fragilidades aparecem repetidamente.

Primeiro, a BIA lista aplicações, não serviços. Clientes e reguladores preocupam-se com a disrupção de serviços. As aplicações importam porque suportam esses serviços.

Segundo, os objetivos de RTO e RPO são copiados de modelos. Um RTO de quatro horas pode parecer razoável até um teste de restauro demonstrar que são necessárias nove horas para reconstruir a integração de identidade, recuperar configuração, restaurar dados, validar integridade e reativar a monitorização.

Terceiro, as cópias de segurança não estão ligadas ao impacto no negócio. Frequência, retenção, cifragem, localização de armazenamento, prioridade de restauro e testes devem refletir objetivos de recuperação aprovados.

Quarto, os fornecedores são tratados como itens de questionário, não como dependências de recuperação. Compromissos de continuidade de fornecedores, contactos de escalonamento, evidência de recuperação e participação em exercícios de incidentes devem estar ligados a serviços críticos.

Quinto, falta aprovação da gestão. No âmbito de NIS2 e DORA, a responsabilização da gestão é explícita. Na ISO/IEC 27001:2022, liderança, papéis, aprovação pelo Proprietário do Risco e reporte de desempenho são requisitos centrais.

Sexto, os testes são demasiado estreitos. Restaurar um ficheiro é útil, mas não comprova recuperação de serviço. Um percurso de recuperação de serviço crítico pode incluir DNS, identidade, segredos, infraestrutura como código, gateways de API, monitorização, registo, escalonamento de fornecedores, comunicação a clientes e revisão de privacidade.

O Zenith Blueprint, na fase Controlos em Ação, passo 19, capta a expectativa de auditoria para cópias de segurança:

Testam as vossas cópias de segurança?

A resposta deve ser “sim, com evidência”, e essa evidência deve ligar-se novamente à BIA.

O pacote de evidência de BIA preparado para auditoria

Um programa prático de BIA deve produzir um pacote de evidência conciso que possa ser usado para auditorias, diligência prévia de clientes, reporte ao conselho e melhoria da resiliência.

Este pacote conta uma história coerente. Também torna a resiliência mensurável.

Próximo passo: transformar a sua BIA em evidência de conformidade

Maria não precisa de uma folha de cálculo maior. Precisa de uma cadeia de evidência viva.

Comece com um serviço crítico. Mapeie os seus ativos de TIC, dados, pessoas, fornecedores e utilidades. Aprove MTD, RTO e RPO. Reconcilie o calendário de cópias de segurança. Verifique os compromissos de recuperação de fornecedores. Execute um teste de recuperação. Registe lacunas. Atualize o plano de tratamento de riscos. Apresente o resultado à gestão.

Depois repita.

A Clarysec pode ajudar a acelerar esse processo usando a Política de Continuidade do Negócio e Recuperação de Desastres, a Política de Continuidade do Negócio e Recuperação de Desastres - PME, a Política de Cópias de Segurança e Restauro, a Política de Auditoria e Monitorização da Conformidade, o Zenith Blueprint e os Zenith Controls.

A sua BIA não deve ser documentação de prateleira criada para uma auditoria. Deve ser a prova operacional de que os seus serviços mais importantes conseguem sobreviver a disrupções, cumprir expectativas de clientes e reguladores e recuperar dentro de limites que a sua liderança aprovou efetivamente.

Se a sua organização está a preparar-se para uma auditoria de acompanhamento ISO/IEC 27001:2022, garantia de cliente NIS2, revisões de terceiros de TIC DORA ou reporte de resiliência ao nível do conselho, comece por tornar a BIA defensável. Descarregue as políticas de continuidade e auditoria da Clarysec, reveja o roteiro de implementação Zenith ou solicite uma avaliação de evidência de resiliência para transformar controlos dispersos numa única narrativa preparada para auditoria.