Uma cópia de segurança só conta se também tiver testado que consegue recuperar com ela — não apenas se o ficheiro está lá, mas se o código-fonte, o pipeline de desenvolvimento e os segredos associados regressam a funcionar após um incidente. No desenvolvimento de software, não se trata apenas de um repositório que consegue restaurar, mas de toda uma cadeia: controlo de versões, servidores de construção, pipelines, ambientes de teste e as chaves e tokens que lhes estão associados. Sem um procedimento de recuperação testado, só descobre durante um incidente se funciona, e esse é o pior momento para o descobrir.
A obrigação de diligência da NIS2 menciona explicitamente a continuidade e recuperação como parte das dez medidas do artigo 21. A diretiva não prescreve uma frequência de teste fixa nem uma forma concreta — isso é preenchido por organização, e a transposição específica de cada país pode adicionar ênfases próprias. O que sempre reaparece, nas listas de verificação de segurança dos clientes e no que as autoridades regulatórias consideram razoável, é a distinção entre ter uma cópia de segurança e ter uma cópia de segurança que restaurou e da qual sabe que o resultado funciona.
O que 'testado' realmente significa
Um teste não é o mesmo que uma marca de verificação verde no software de cópia de segurança. Testado significa que alguém efetivamente restaurou a cópia de segurança num ambiente separado, verificou se o código é compilado, se a construção tem sucesso e se a aplicação funciona como esperado. Só então sabe se o momento de recuperação é utilizável e quanto tempo leva. Uma cópia de segurança que é feita mas nunca restaurada é, na prática, uma suposição sobre recuperação, não uma recuperação comprovada.
O que restaura especificamente no pipeline de desenvolvimento
No desenvolvimento de software, o código-fonte raramente é a única coisa que pode perder. Pense na configuração do pipeline CI/CD, nos scripts de construção, nas dependências de pacotes externos, nas chaves de acesso para registos e ambientes em nuvem, e no histórico no próprio sistema de controlo de versões. Um plano de recuperação que cobre apenas o código, mas não o pipeline ou os segredos, deixa uma organização ainda parada após um incidente. Por isso é útil determinar para cada um destes componentes separadamente: onde está a cópia de segurança, quem a consegue restaurar, e isso foi já praticado.
Com que frequência é razoável testar
Não existe um prazo fixo na diretiva sobre com que frequência deve testar uma recuperação. O que é considerado razoável na prática depende de com que frequência o ambiente muda: um pipeline de desenvolvimento que altera a configuração semanalmente requer testes mais frequentes do que um ambiente estável que permanece inalterado durante meses. Muitas organizações optam por um momento de calendário fixo — por exemplo, a cada trimestre — combinado com um teste após cada grande alteração na infraestrutura. Mais importante do que a frequência é que tenha havido um momento, e que consiga indicar quando.
O que regista como prova
Um cliente que envia uma lista de verificação de segurança raramente pergunta sobre a técnica por trás da sua cópia de segurança. A pergunta é geralmente mais simples: quando foi testado pela última vez, por quem, e qual foi o resultado. Para essa resposta é suficiente registar três coisas: a data do último teste de recuperação, quem realizou o teste, e qual componente foi restaurado — código, pipeline, segredos, ou todos. Sem esse registo, a resposta à lista de verificação permanece uma lembrança em vez de uma prova, e essa é exatamente a diferença que um avaliador do outro lado da mesa quer ver.
A coerência com o resto do dossier
Cópia de segurança e recuperação raramente funcionam isoladamente. Quem pode executar o procedimento de recuperação depende do controle de acesso à linha de desenvolvimento; o que correu mal durante uma falha deve constar no mesmo registo de incidentes utilizado para outras medidas. Configurar esse dossier não precisa ser um projeto separado: as dez medidas desagregadas por situação mostra exatamente onde a cópia de segurança e a recuperação se encaixam no conjunto e que outras medidas estão diretamente relacionadas.
Se a cópia de segurança e a recuperação constituem uma medida de diligência devida para sua organização depende de se você está sujeito à NIS2 ou se recebe essa questão através de um cliente contratante que está. em poucas perguntas ver onde você está fornece uma primeira indicação disso, com explicação do porquê. Como chegamos a essa indicação e quais fontes a fundamentam está explicado em a página sobre nossa metodologia.
Uma cópia de segurança que nunca foi restaurada não é garantia — é uma pergunta à espera de uma resposta. Quer saber se e como essa medida é relevante para sua organização e o que mais está envolvido? Faça a verificação rápida gratuita ou navegue por as perguntas mais frequentes sobre NIS2 para as perguntas que outros empresários já fizeram.