Plano de continuidade de negócio para a NIS2: como integrar BCP, análise de risco e exercícios de crise

Um plano de continuidade de negócio preparado no contexto dos requisitos da NIS2 não pode ser um procedimento isolado, mantido apenas pelo departamento de tecnologias de informação. Deve resultar da análise de impacto das interrupções e da análise de risco, estabelecer prioridades para a recuperação dos processos e ser objeto de exercícios regulares. A sua eficácia não se comprova por declarações, mas pela capacidade da organização para tomar decisões, ativar um modo de operação alternativo, alcançar um nível mínimo de funcionamento e regressar em segurança à operação normal.

A continuidade de negócio é uma decisão de gestão

Um plano de continuidade de negócio não começa por um modelo de procedimento nem por um inventário de sistemas informáticos. O ponto de partida são os serviços, produtos e processos cuja interrupção pode comprometer o cumprimento de obrigações, a segurança, a conformidade com requisitos ou a estabilidade financeira da empresa. O âmbito do plano deve resultar de uma análise de impacto no negócio. É necessário determinar como os efeitos se agravam ao longo do tempo, em que momento ultrapassam o nível aceite pela gestão e por que ordem devem ser recuperadas as capacidades operacionais.

O tempo máximo tolerável de interrupção e o nível de perdas aceitável não devem ser definidos unilateralmente pelas TI. Estes parâmetros devem ser aprovados pela gestão com base na informação fornecida pelos responsáveis dos processos e pelas áreas financeira, de conformidade, segurança e tecnologia. O responsável pelo processo define os requisitos de continuidade, enquanto o responsável pelo plano coordena a preparação e a manutenção da solução. Sem um mecanismo comum de decisão entre estas funções, as TI protegem a infraestrutura, as operações asseguram a prestação dos serviços e a administração não dispõe de uma visão coerente das prioridades de recuperação e dos períodos de interrupção admissíveis.

Numa unidade industrial, o simples restabelecimento do sistema de planeamento ou controlo não significa que as expedições possam ser retomadas. A produção pode continuar parada devido à indisponibilidade de dados tecnológicos, à falta de operadores autorizados, de energia, de comunicações asseguradas por um fornecedor ou de um procedimento aprovado para trabalho em modo alternativo. A resiliência operacional só existe quando o plano cobre toda a cadeia de dependências do processo, e não apenas os recursos controlados pelas TI.

Importa também distinguir entre continuidade de negócio, recuperação de recursos informáticos, resposta a incidentes e gestão de crises. A primeira procura manter ou retomar os processos; a segunda visa recuperar tecnologia e dados; a terceira limita e trata os efeitos do incidente; e a quarta suporta a tomada de decisões perante uma perturbação grave. Estes mecanismos devem utilizar cenários, limiares de escalonamento e regras de responsabilidade comuns, mas não são equivalentes nem substituíveis entre si.

Só depois de definido este modelo operacional é possível relacioná-lo com as obrigações decorrentes da NIS2 e da legislação nacional aplicável em matéria de gestão de risco, continuidade de negócio, tratamento de incidentes e responsabilidade dos órgãos de gestão, tendo em conta o enquadramento concreto da organização. O contexto mais amplo é apresentado no artigo NIS2 para empresas industriais: quem está abrangido, que obrigações introduz e como preparar a organização sem reduzir o tema às TI.

O risco tem de conduzir a um cenário

O registo de riscos só orienta o plano de continuidade quando demonstra a relação entre ameaça, vulnerabilidade, ativo, processo e impacto no negócio. Uma lista de ciberameaças, por si só, não explica como manter a atividade. Os cenários devem, por isso, ser construídos em torno dos efeitos da interrupção, como a indisponibilidade de um sistema de controlo, a perda de dados, a falha das comunicações, a ausência de pessoal ou a indisponibilidade de um fornecedor. Causas diferentes podem produzir o mesmo estado operacional e exigir a mesma estratégia de continuidade.

A análise de impacto no negócio e a análise de risco têm funções distintas, mas complementares. A primeira determina a relevância da interrupção, o ritmo de acumulação das perdas e o momento em que é ultrapassado o nível aceite pela gestão. A segunda permite identificar possíveis origens do evento, vulnerabilidades e a eficácia dos controlos existentes. O método e a escala de avaliação adotados devem permitir comparar cenários e aceitar conscientemente o risco residual, de acordo com o apetite pelo risco da organização.

É aconselhável limitar o número de cenários aos efeitos distintos que exijam decisões, recursos ou sequências de recuperação diferentes. Analisar separadamente todas as variantes técnicas raramente aumenta a utilidade do plano e tende a dificultar a sua manutenção e aplicação sob pressão.

Para cada cenário é necessário definir o tempo máximo de interrupção admissível, o nível mínimo de operação, os recursos necessários, a sequência de recuperação e a pessoa autorizada a ativar o plano. Estes parâmetros devem apoiar-se nos tempos reais de paragem e recuperação registados em incidentes, avarias e exercícios, bem como nos requisitos contratuais relativos à disponibilidade, aos prazos de execução e à comunicação de perturbações. A partir destes dados, torna-se possível medir o tempo necessário para tomar decisões, atingir o nível mínimo de operação e concluir a recuperação integral.

A análise deve considerar as dependências reais do processo relativamente a aplicações, dados, infraestrutura, instalações, serviços essenciais, competências críticas, fornecedores de TI, integradores e subcontratados. Quando a estratégia depende do apoio de terceiros, é necessário verificar a sua disponibilidade, tempos de resposta, canais de escalonamento e soluções alternativas, em vez de confiar apenas nas cláusulas contratuais. Este tema é desenvolvido no artigo NIS2 e segurança da cadeia de fornecimento: como avaliar fornecedores de TI, integradores e subcontratados.

O plano deve orientar a organização durante a interrupção

Um plano de continuidade útil não procura descrever todos os eventos possíveis. Deve conduzir os responsáveis ao longo das decisões sucessivas: quem identifica a situação, quem declara a ativação do regime de continuidade, que processos devem ser mantidos no nível mínimo, por que ordem se recuperam as capacidades, como se gere a comunicação de crise e com base em que critérios se encerra o regime de exceção.

O nível de detalhe é adequado quando reduz a necessidade de interpretação sob pressão, sem substituir as instruções técnicas e operacionais. Numa organização de maior dimensão, uma solução prática consiste num plano geral que defina o comando, o escalonamento e as regras de atuação conjunta, complementado por planos específicos para cada processo.

O procedimento de ativação exige critérios mensuráveis. Uma indicação como “em caso de avaria grave” transfere a discussão sobre o significado de “grave” para o pior momento possível. O critério pode estar relacionado com a ultrapassagem do tempo máximo de interrupção, a perda de fiabilidade dos dados, a impossibilidade de trabalhar em segurança, a indisponibilidade de pessoas-chave ou a previsão de uma queda abaixo do nível mínimo de operação aprovado pelo responsável do processo. Cada desvio deve estar associado a uma ação, a uma pessoa autorizada a decidir, a um prazo de escalonamento e ao registo exigido. Uma lógica semelhante, embora aplicada noutro nível operacional, é apresentada em Plano de reação no plano de controlo: como definir as ações quando o processo sai dos limites.

As responsabilidades devem ser atribuídas a funções, e não apenas a nomes. A matriz de responsabilidades deve contemplar substituições, níveis de autoridade, disponibilidade e canais de contacto principal e de emergência. A lista nominal de contactos pode constituir um anexo controlado, evitando que cada alteração de pessoal obrigue a rever todo o plano.

A administração deve decidir sobre matérias que ultrapassem o âmbito operacional previamente aprovado, incluindo a aceitação de riscos significativos para o negócio, a mobilização de recursos extraordinários ou comunicações de importância estratégica. Já a decisão de passar para um modo alternativo anteriormente aprovado deve permanecer tão próxima do processo quanto possível.

Após a indisponibilidade do sistema de encomendas, a pessoa de serviço pode confirmar a falha e o tempo estimado de interrupção; o responsável pelo processo pode ativar o registo alternativo; e o coordenador de continuidade pode escalar o evento quando for atingido o limiar definido. O plano deve estabelecer os limites desta solução: capacidade de processamento, duração máxima de utilização, regras de proteção e integridade dos dados, reconciliações manuais necessárias e método de posterior introdução dos registos no sistema.

O regresso à operação normal só pode ocorrer depois de confirmadas a estabilidade da solução, a integridade e completude dos dados e a reconciliação das operações executadas manualmente. Os registos produzidos devem permitir avaliar o tempo de decisão, o tempo necessário para atingir o nível mínimo e o tempo de recuperação total.

O maior custo surge nas interfaces entre planos

A dimensão das perdas não depende apenas da causa da falha. A interrupção também é prolongada pela espera por autorizações, por classificações ambíguas do evento, por prioridades de recuperação divergentes e pela falta de conhecimento das dependências entre processos, sistemas e fornecedores. O plano de resposta a incidentes serve principalmente para detetar, avaliar, conter e tratar o evento. O plano de continuidade procura manter a atividade num nível aceite. Ambos devem definir pontos comuns de transmissão de informação e decisão: quem determina que a continuidade está ameaçada, quem ativa o modo alternativo e quem aprova o regresso à operação normal.

A prioridade da recuperação técnica deve decorrer da prioridade do processo, mas não pode ser uma simples reprodução desta. Um sistema que suporta o processo mais crítico pode depender da recuperação prévia de serviços de identidade, rede, bases de dados ou integração. É igualmente necessário preservar a integridade dos dados, a sequência correta de arranque e os mecanismos de segurança. A coerência entre prioridades de negócio e técnicas verifica-se comparando a disponibilidade exigida pelo processo com os resultados reais dos testes de recuperação de cópias de segurança, a perda de dados admissível e as dependências da infraestrutura.

A área operacional pode pretender retomar a receção de encomendas antes da faturação, enquanto a equipa de TI planeia recuperar primeiro a faturação porque esta contém o registo central de clientes. Se esta dependência não tiver sido previamente acordada, a decisão será tomada sob pressão e a solução manual poderá introduzir dados que depois não podem ser reconciliados com segurança. Um caso deste tipo deve ser avaliado com base nos tempos reais de deteção, escalonamento, decisão e recuperação, bem como nos resultados dos testes que confirmem a completude e a integridade dos dados.

Uma lacuna semelhante surge na fronteira das responsabilidades do fornecedor. Uma declaração contratual de disponibilidade não substitui uma via de escalonamento nominal ou funcional, parâmetros de recuperação acordados, acesso a informação sobre a evolução da interrupção nem a obrigação de participação nos exercícios. Os requisitos dos processos críticos devem ser comparados com as condições contratuais e com a capacidade real do prestador. Só então é possível decidir de forma consciente entre manter uma solução de contingência, aceitar a indisponibilidade, utilizar recursos internos ou recorrer a um serviço externo.

O orçamento deve responder a lacunas de capacidade, e não financiar a produção de documentos. O investimento pode destinar-se a redundância adicional, à redução do percurso decisório, a testes de recuperação mais frequentes, à alteração de condições contratuais ou à criação de um modo alternativo de executar o processo. A organização destes custos é desenvolvida na análise Quanto custa implementar a NIS2 e a uKSC: como preparar o orçamento de auditoria, documentação, formação e controlos sem erros dispendiosos.

O exercício deve testar decisões

Um exercício de continuidade de negócio não pode limitar-se à leitura do procedimento ou ao registo da presença dos participantes. Deve testar uma hipótese claramente formulada, por exemplo: a organização consegue ativar um processo alternativo sem o sistema principal, manter o controlo dos dados introduzidos e reconciliá-los com segurança após a recuperação do serviço?

O programa de exercícios deve evoluir gradualmente: desde a revisão de funções e exercícios de mesa, passando pelo teste de um procedimento ou recuperação específicos, até a um exercício técnico e operacional que envolva as áreas de negócio, as TI, a gestão e os fornecedores. O âmbito deve crescer em função do risco, da criticidade do processo e da maturidade da organização.

O cenário deve obrigar à tomada de decisões em condições próximas de uma perturbação real. Para tal, podem ser introduzidas informações incompletas, pressão de tempo, conflitos de prioridades e a indisponibilidade de uma dependência relevante, como a pessoa que aprova, um serviço do fornecedor ou a lista atualizada de contactos. O exercício não deve, contudo, constituir uma armadilha para os participantes. O objeto da avaliação é o sistema — a distribuição de responsabilidades, a qualidade da informação, a exequibilidade dos procedimentos e a capacidade de escalonamento — e não a responsabilização individual dos trabalhadores.

A participação da gestão é necessária sempre que o cenário exija aceitar um risco, alterar prioridades ou ativar uma solução alternativa de custo elevado. O fornecedor deve ser incluído quando a sua resposta condicione a continuidade do processo.

Um exercício pode começar com a indisponibilidade do sistema de gestão de encomendas. Em seguida, o facilitador comunica que a cópia dos dados está incompleta e que a resposta do prestador está atrasada. A equipa tem de decidir se ativa o processamento manual, que encomendas aceita e como identifica os registos para evitar duplicações e perda de integridade após a recuperação do serviço.

Durante o exercício devem ser medidos os tempos de identificação da interrupção, escalonamento, ativação do modo de continuidade, alcance do nível mínimo de operação e recuperação. Em paralelo, avaliam-se a qualidade dos fluxos de informação e dos registos, a utilização de dados de contacto desatualizados, os escalonamentos ineficazes e as etapas do plano que não puderam ser executadas. Os tempos alcançados devem ser comparados com os objetivos de continuidade aprovados.

A frequência e o formato dos exercícios devem resultar do risco, das alterações nos processos, dos resultados dos testes anteriores e da importância das dependências, e não apenas de um calendário anual. Um exercício anunciado facilita a aprendizagem e o alinhamento de responsabilidades. Um exercício não anunciado permite avaliar a prontidão real, mas exige controlo do risco operacional. A utilização do sistema de produção só é justificável quando o âmbito, as salvaguardas e a possibilidade de interromper o teste tenham sido conscientemente aprovados; nos restantes casos, deve ser utilizado um ambiente de teste.

Cada exercício deve terminar com ações que tenham responsável, prazo, critério de eficácia e uma decisão sobre a repetição do teste. A percentagem de ações concluídas dentro do prazo é um indicador útil, mas o estado “concluído” não demonstra, por si só, uma melhoria. O resultado do novo teste é o elemento decisivo. A abordagem apresentada em Como criar uma biblioteca de modelos da qualidade: FMEA, Control Plan, 8D, auditoria, CAPA e KPI pode apoiar a organização de cenários, relatórios, ações corretivas e indicadores.

Fechar o ciclo com evidências e revisão pela gestão

Um conjunto completo de procedimentos não demonstra capacidade para manter a operação. Uma cadeia de evidências credível deve ligar os pressupostos aprovados da análise de risco e de continuidade, as decisões dos responsáveis pelos processos, os registos dos testes, os resultados dos exercícios, as não conformidades identificadas, as ações corretivas e a avaliação da sua eficácia. O histórico de versões do plano de continuidade deve indicar não apenas a data e o autor da alteração, mas também o evento, a decisão ou o resultado da análise que a justificou.

A frequência de revisão do plano deve ser ajustada à criticidade dos processos e à evolução do risco. Uma data periódica, por si só, não é suficiente. A revisão também deve ser desencadeada por um incidente, exercício ou alteração significativa no processo, tecnologia, localização, fornecedor, estrutura organizacional ou perfil de risco. Os critérios de aceitação do exercício devem ser definidos antes do seu início, para evitar que a avaliação se limite à conclusão subjetiva de que a organização “conseguiu responder”.

A monitorização mensal pode confirmar que o programa de exercícios foi cumprido, mas revelar simultaneamente que um processo não atingiu o tempo de recuperação exigido e que continua a não existir uma solução alternativa para um serviço crítico prestado por um fornecedor. Este resultado não deve ficar escondido num relatório técnico. A administração deve receber informação sobre os processos que não atingem a capacidade necessária, os desvios ainda não aceites, os riscos conscientemente assumidos e os investimentos ou decisões organizacionais necessários. A revisão pela gestão deve terminar com decisões documentadas, e não apenas com a tomada de conhecimento.

A auditoria interna deve verificar a coerência entre as declarações e a prática: se o processo classificado como crítico participa efetivamente nos exercícios, se os objetivos técnicos de recuperação correspondem às necessidades operacionais e se as ações resultantes dos testes foram encerradas e tiveram a sua eficácia confirmada. Ao auditor ou à autoridade de supervisão deve ser apresentada uma sequência de registos que demonstre o percurso entre o risco identificado, a decisão, o teste e a melhoria verificada. Entre os indicadores de apoio encontram-se o grau de execução do programa de exercícios aprovado, o cumprimento dos prazos das ações corretivas e o número de discrepâncias não aceites entre a capacidade de continuidade necessária e a capacidade efetivamente confirmada.

A lista final de ações pode ser integrada no plano mais amplo descrito em Implementação da NIS2 após a inscrição na lista do KSC: plano de ações até 3 de abril de 2027. Os prazos, o âmbito das obrigações e as medidas adequadas devem, contudo, ser sempre verificados face ao enquadramento jurídico em vigor, ao estatuto da organização no sistema nacional de cibersegurança aplicável e ao seu perfil real de risco.