Um plano de continuidade de atividade explica como a organização mantém os serviços prioritários durante uma interrupção e como regressa ao funcionamento normal. Começa pelas consequências para clientes, trabalhadores e outras pessoas, não pela lista de servidores. O resultado deve permitir decidir o que continua, com que recursos e durante quanto tempo.
Este guia apresenta uma análise de impacto, uma decisão de serviço mínimo e um exercício preenchido. Os tempos e capacidades dos exemplos são escolhas hipotéticas. Devem ser substituídos por valores justificados pela operação, pelas obrigações aplicáveis e pelos testes da organização. A política de segurança da informação enquadra as responsabilidades e as regras que continuam válidas durante a crise.
Continuidade e recuperação de TI respondem a perguntas diferentes
A continuidade pergunta como prestar o serviço quando faltam pessoas, instalações, aplicações ou fornecedores. A recuperação de TI pergunta como restaurar sistemas e dados. Uma aplicação recuperada pode não permitir retomar imediatamente o serviço se faltarem pessoas autorizadas, comunicações ou dados de um parceiro.
O plano de recuperação de TI deve, por isso, apoiar os objetivos da atividade. Uma cópia de segurança é uma medida importante, mas não define quem recebe pedidos enquanto a aplicação está indisponível, como se evitam duplicações ou quem valida as operações introduzidas durante o período de contingência.
O artigo 32.º do RGPD inclui disponibilidade, resiliência, reposição do acesso a dados e avaliação da eficácia das medidas. Não estabelece um tempo único de recuperação para todas as organizações. O impacto nos direitos das pessoas tem de ser considerado em conjunto com a continuidade operacional. RGPD, artigo 32.º.
Definir o âmbito e os serviços prioritários
Escolha processos com responsáveis identificados e resultados observáveis. “Manter a empresa a funcionar” é demasiado amplo. “Receber pedidos urgentes de assistência e atribuí-los à equipa disponível” já permite definir entradas, saídas, capacidade mínima e dependências.
Na análise inicial, inclua clientes e pessoas que dependem do serviço, períodos de maior procura e tarefas com prazos externos. O impacto de uma interrupção pode variar entre uma manhã normal e o dia de processamento de salários. Não use apenas a média anual quando existe uma janela operacional especialmente sensível.
A cartografia dos sistemas e dependências ajuda a identificar serviços de identidade, correio, telecomunicações, energia e prestadores externos. Inclua também dependências humanas: uma única pessoa pode conhecer um procedimento ou deter a autorização necessária para uma ação urgente.
Fazer a análise de impacto na atividade
Para cada processo, descreva as consequências da interrupção ao longo do tempo. Considere incumprimento de obrigações, danos para pessoas, perda de informação, acumulação de trabalho e dificuldades de reconciliação. Uma estimativa financeira pode ser útil, mas não deve esconder consequências que não se exprimem apenas em euros.
A orientação NIST SP 800-34, publicada em 2010 para sistemas federais norte-americanos, apresenta a análise de impacto e a articulação entre planos de contingência. É uma referência metodológica datada, não uma obrigação portuguesa. O modelo de análise disponibilizado com a publicação pode ajudar a estruturar dependências e prioridades. NIST: guia de planeamento de contingência.
| Processo no exemplo | Consequência principal | Funcionamento mínimo escolhido |
|---|---|---|
| Receção de pedidos urgentes | Pessoas sem resposta e perda de prioridade | Canal alternativo e triagem por duas pessoas autorizadas |
| Agendamento | Duplicações e falhas de coordenação | Registo temporário controlado, com confirmação antes de marcar |
| Faturação corrente | Acumulação de trabalho administrativo | Suspensão temporária com fila de operações pendentes |
| Gestão de acessos | Contas indevidas ou impossibilidade de trabalhar | Circuito de emergência limitado a necessidades documentadas |
A tabela pertence a uma empresa hipotética de serviços. Outra organização pode ter prioridades diferentes. Cada decisão deve ser confirmada pelo responsável do processo e confrontada com a capacidade real dos recursos disponíveis.
Definir objetivos que possam ser demonstrados
O tempo objetivo de recuperação, frequentemente designado RTO, exprime o objetivo para recuperar um recurso ou serviço. O ponto objetivo de recuperação, RPO, exprime a perda de dados tolerável em termos temporais. Ambos precisam de contexto: um RPO de uma hora pressupõe saber que operações podem ter de ser reconstruídas nessa hora.
No exemplo, a empresa pretende reabrir o serviço de pedidos em quatro horas e tolerar, para a aplicação principal, no máximo uma hora de dados não recuperados automaticamente. Estes valores são objetivos internos hipotéticos. A equipa verifica se as cópias, as dependências e a reconciliação permitem realmente cumpri-los.
Não escreva que o plano “garante” o RTO apenas porque o fornecedor promete disponibilidade elevada. Peça o âmbito do compromisso, as exclusões e o processo de restauro. Um objetivo deve ser apoiado por medidas e ensaios; quando ainda não é atingido, o plano deve mostrar a lacuna e a decisão tomada.
Escolher estratégias de continuidade
As opções podem incluir um local alternativo, uma equipa substituta, um canal de contacto adicional ou um modo de trabalho temporário. Avalie cada uma pela capacidade, tempo de ativação, dependências e segurança. Uma alternativa que usa o mesmo serviço de identidade indisponível pode falhar no mesmo momento que o sistema principal.
A estratégia deve especificar o que não pode ser feito no modo reduzido. Por exemplo, a equipa pode receber e classificar pedidos, mas não alterar determinados dados contratuais sem acesso à fonte de referência. Esta limitação evita decisões baseadas em informação desatualizada.
O Quadro Nacional de Referência para a Cibersegurança do CNCS inclui resposta e recuperação no conjunto de capacidades organizacionais. Pode apoiar a revisão dos elementos do plano, mantendo a distinção entre referência técnica e deveres específicos da entidade. CNCS: Quadro Nacional.
Exemplo preenchido de ativação
Às nove horas, a aplicação de pedidos deixa de responder. O responsável operacional confirma que a falha afeta toda a equipa e recebe indicação de que a duração ainda é desconhecida. O plano prevê ativar o canal alternativo quando a interrupção impede a triagem normal e não existe reposição imediata confirmada.
A decisão de exemplo é: “Ativar receção reduzida; duas pessoas autorizadas usam o formulário temporário; recolher apenas contacto, assunto e prioridade; não copiar documentos sensíveis para contas pessoais; atualizar os clientes através do canal validado. O responsável de TI acompanha a recuperação e comunica alterações de previsão ao coordenador.”
O plano identifica quem pode tomar esta decisão e quem o substitui. Inclui ainda um registo de hora, motivo, medidas ativadas e responsáveis. Não exige que toda a direção esteja disponível para iniciar uma ação já prevista, mas define quais as decisões que precisam de escalamento.
Proteger os dados no modo de contingência
O modo reduzido deve respeitar a minimização de dados. Recolha apenas o necessário para manter o serviço previsto. Se bastam um contacto e uma referência de pedido, não peça uma cópia integral da documentação do cliente por um canal improvisado.
Defina a localização do registo temporário, os acessos e o destino após a normalização. Se for usada uma folha de cálculo, controle a partilha e as versões. Se forem usados formulários em papel, indique onde ficam guardados e quem pode transportar ou consultar os documentos.
A cifragem de dados e gestão de chaves deve ser compatível com a emergência. Uma cópia protegida cuja chave só está acessível no sistema indisponível pode não servir para recuperar. A solução deve equilibrar disponibilidade e acesso controlado, incluindo a verificação do uso de credenciais de emergência.
Comunicação durante a interrupção
Prepare mensagens diferentes para equipa interna, clientes e fornecedores. A equipa precisa de instruções e limites; o cliente precisa de saber que serviço está disponível, como contactar e quando receberá nova informação. Evite anunciar uma hora de reposição que ainda não foi confirmada.
Uma mensagem de exemplo pode dizer: “O canal habitual encontra-se indisponível. Pode apresentar pedidos urgentes pelo contacto alternativo indicado. Não envie documentação clínica ou financeira neste canal. A equipa confirmará a receção e explicará os passos seguintes.” A mensagem deve corresponder ao serviço real e à informação que pode ser recebida com segurança.
A interrupção pode constituir uma violação de dados pessoais, mas a qualificação depende das circunstâncias. O plano deve ligar à avaliação de incidentes e, quando aplicável, à comunicação aos titulares, distinguindo-a de um simples aviso operacional. A continuidade não suspende os deveres de análise e resposta.
Exercício de mesa com decisões verificáveis
Num primeiro exercício, reúna os responsáveis e apresente uma sequência de acontecimentos: aplicação indisponível, ausência do coordenador principal, pedido urgente de um cliente e falha parcial do canal alternativo. Peça que indiquem a decisão, o substituto e o documento que usariam em cada momento.
O observador regista as lacunas. No exemplo, descobre-se que o contacto do fornecedor estava apenas dentro da aplicação indisponível e que o substituto não tinha acesso ao formulário temporário. A correção consiste em tornar os contactos acessíveis por um meio controlado e validar previamente o acesso do substituto.
O exercício de mesa não demonstra a recuperação técnica. Deve ser complementado por ensaios apropriados dos componentes, com evidências das medidas técnicas de recuperação quando previsto. Evite contabilizar uma reunião como prova de que cópias, integrações e permissões foram efetivamente recuperadas.
Retomar sem perder nem duplicar operações
A normalização começa pela confirmação de que o serviço recuperado está utilizável e íntegro. O dono do processo executa operações de controlo antes de abrir toda a fila. A equipa técnica confirma a infraestrutura, mas o responsável operacional verifica se o resultado corresponde às necessidades da atividade.
Reconcilie os pedidos recebidos durante a interrupção. Atribua identificadores e marque quais já foram introduzidos no sistema principal. Preserve o rasto necessário para resolver dúvidas, evitando manter indefinidamente cópias temporárias. Se houver conflito entre versões, defina quem decide com base em fontes verificáveis.
No fecho, registe tempo efetivo de recuperação, capacidade atingida, dados reconstruídos e medidas de proteção usadas. Compare os resultados com os objetivos e atribua correções. Atualize o plano após mudanças de serviço, fornecedor, equipa ou dependência relevante, para que a próxima ativação se apoie em informação atual e numa capacidade demonstrada.