Art. 21(2)(c) NIS 2 + CIR §4.2

Estratégia de cópias de segurança NIS 2 ao abrigo do Artigo 21(2)(c)

A NIS 2 obriga a manter o negócio a funcionar durante e após um incidente. O Artigo 21(2)(c) nomeia a gestão de cópias de segurança, a recuperação de desastres e a gestão de crises. O §4.2 do CIR (UE) 2024/2690 transforma isso num plano de cópias de segurança documentado, testes regulares de recuperação e redundância.

Simon OrzelSimon Orzel·

A versão curta

As cópias de segurança na NIS 2 não são 'temos cópias de segurança'. Todas as equipas de TI do Mittelstand têm trabalhos de fita ou snapshot noturnos. A pergunta que a diretiva e o CIR de facto fazem é se tem um plano documentado, com tempos de recuperação, armazenamento fora do local, controlos de acesso, períodos de retenção, e uma capacidade testada de repor os sistemas.

O §4.2 do CIR tem seis peças. Um plano de cópias de segurança com seis pontos nomeados. Testes regulares de integridade. Redundância de rede, ativos, pessoal e comunicações. Monitorização de recursos. E testes regulares de recuperação com resultados documentados. As seis estão numa só secção do Anexo. Nenhuma delas é opcional.

A Alemanha passa a mesma regra para a lei nacional através do § 30(2)(3) BSIG. A redação transpõe o Artigo 21(2)(c) quase palavra por palavra. Esta página percorre a diretiva, o regulamento de execução da UE e a transposição alemã por essa ordem.

A fonte legal
Três camadas empilhadas umas sobre as outras. A diretiva (vinculativa para todos os países da UE). O regulamento de execução (lei da UE diretamente aplicável aos setores nomeados no Anexo). A transposição nacional (na Alemanha: BSIG).

Artigo 21(2)(c) da Diretiva NIS 2 (2022/2555)

Continuidade das atividades, como a gestão de cópias de segurança e a recuperação de desastres, e gestão de crises.

Este é o ponto (c) na lista das dez medidas de cibersegurança que todas as entidades essenciais e importantes têm de implementar. A gestão de cópias de segurança é nomeada diretamente no texto da diretiva, não apenas enterrada no regulamento de execução.

CIR (UE) 2024/2690, Anexo §4.2

Gestão de cópias de segurança, salvaguarda e redundância. Para efeitos do Artigo 21(2)(c) da Diretiva (UE) 2022/2555, as entidades relevantes devem efetuar cópias de segurança e prover recursos suficientes, incluindo instalações, redes e sistemas de informação e pessoal, para assegurar um nível adequado de redundância.

Por ser um regulamento (e não uma diretiva), é lei da UE diretamente vinculativa. Não é necessária transposição nacional. O §4.2 tem seis subsecções numeradas que cobrem o plano de cópias de segurança, os testes de integridade, a redundância, a monitorização de recursos e os testes de recuperação. Aplica-se a fornecedores de DNS, fornecedores de cloud, centros de dados, MSPs, serviços de confiança e aos outros setores listados no Anexo do CIR.

§30(2)(3) BSIG (Alemanha)

Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement.

A Alemanha copia o texto da UE palavra por palavra. A transposição alemã aponta para os blocos de construção do IT-Grundschutz CON.3 (Datensicherungskonzept) e DER.2.3 (Wiederherstellung) como a via prática de implementação.

As três coisas que o §4.2 do CIR exige de facto
O CIR 2024/2690 divide a gestão de cópias de segurança e redundância em três peças: o plano escrito, os testes, e a redundância de recursos. Precisa das três.
§4.2.2

Escreva o plano de cópias de segurança de seis pontos

Com base na sua avaliação de risco e no BCP, escreva: (a) tempos de recuperação, (b) como garante que as cópias de segurança são completas e exatas, incluindo dados de configuração e dados armazenados na cloud, (c) onde residem as cópias (online ou offline) em uma ou mais localizações seguras, não na mesma rede do sistema principal, suficientemente afastadas para que um incidente no local principal não as derrube, (d) controlos de acesso físico e lógico ajustados à classificação do ativo, (e) como corre de facto a recuperação a partir das cópias, (f) períodos de retenção por requisitos de negócio e regulamentares.

§4.2.3 + §4.2.6

Teste a integridade e a recuperação com uma cadência

O §4.2.3 exige testes regulares de integridade das próprias cópias de segurança. O §4.2.6 vai mais longe: testes regulares do processo real de recuperação. Verifique que a recuperação é fiável, que todas as cópias e procedimentos funcionam, e que as pessoas que correriam a recuperação ainda têm o conhecimento para o fazer. Documente os resultados. Tome medidas corretivas quando um teste falha.

§4.2.4

Construa redundância em quatro recursos

Com base na sua avaliação de risco e no BCP, assegure pelo menos redundância parcial de: (a) redes e sistemas de informação, (b) ativos e valores, incluindo instalações, equipamento e consumíveis, (c) pessoal com a responsabilidade, autoridade e competência exigidas, (d) canais de comunicação. As cópias de segurança são sobre dados. A redundância é sobre tudo o resto de que precisa para continuar a operar.

Duas regras que moldam tudo o resto
Duas regras de base estão sob o §4.2. Ambas vêm diretamente do texto do regulamento. Ambas são esquecidas com regularidade.

Cópias de segurança e redundância em conjunto

O §4.2 do CIR nomeia ambas no mesmo título de secção: 'Gestão de cópias de segurança, salvaguarda e redundância'. As cópias de segurança protegem os dados para que possa reconstruir a partir de uma cópia em bom estado conhecido. A redundância protege as operações para que não pare logo à partida. Ambas pertencem ao plano. Uma equipa que tem cópias de segurança mas não tem redundância recupera os dados e mesmo assim não consegue operar.

Testadas, não apenas feitas

O §4.2.6 exige especificamente testes regulares de recuperação, não apenas cópias de segurança regulares. Uma cópia de segurança de que ninguém restaurou não é uma capacidade de recuperação, é uma esperança. O auditor vai perguntar quando fez o último restauro completo, quem o correu, o que falhou, e o que corrigiu depois. Se a resposta for 'na instalação, há três anos', tem uma constatação de auditoria.

Como as autoridades nacionais gerem isto na prática
A UE define a regra. Cada país transpõe-na. A substância é a mesma. A mecânica local difere um pouco.
Alemanha

BSI / IT-Grundschutz CON.3 + DER.2.3

O IT-Grundschutz do BSI tem dois blocos de construção que mapeiam diretamente no §4.2 do CIR. O CON.3 'Datensicherungskonzept' cobre o próprio conceito de cópias de segurança (o que é copiado, com que frequência, onde residem as cópias, retenção). O DER.2.3 'Notfallwiederherstellung der IT' cobre o lado da recuperação (procedimentos, funções, teste de restauro). Em conjunto, dão-lhe o pacote de evidência do §4.2 numa linguagem que um auditor alemão lê todos os dias.

Toda a UE

Orientação Técnica de Implementação da ENISA

A TIG da ENISA pega no texto abstrato do §4.2 e mostra-lhe o que fazer na prática para cada subsecção. Também mapeia o requisito no Anexo A.8.13 (cópias de segurança de informação) e A.8.14 (redundância das instalações de processamento de informação) da ISO/IEC 27001:2022. Os controlos ISO 27001 existentes dão-lhe um avanço na evidência do §4.2.

Outros Estados-Membros

Leis nacionais de transposição

Cada Estado-Membro transpõe o Artigo 21(2)(c) para a sua própria lei (Países Baixos: Cyberbeveiligingswet, Áustria: NISG, Bélgica: NIS2-Wet). Os deveres são os mesmos porque a diretiva define um padrão único para toda a UE. O que difere: a que agência nacional responde e como conduzem as inspeções.

Três armadilhas que vemos a toda a hora
Três pressupostos que surgem em quase todas as chamadas de preparação de auditoria. Os três criam falhas que um auditor vai encontrar.
  • Corremos cópias de segurança noturnas, por isso estamos cobertos.

    As cópias de segurança noturnas são necessárias, não suficientes. O §4.2.2(c) quere-as armazenadas fora do local, não na mesma rede do sistema principal, e suficientemente afastadas para que um único incidente não derrube ambos. O §4.2.2(f) quer períodos de retenção documentados, não 'guardamo-las até o disco encher'. O §4.2.6 quer uma cadência regular de testes de recuperação com resultados documentados. O auditor vai pedir os três. 'Temos cópias de segurança' responde a um deles.

  • Testámos a recuperação uma vez, quando montámos o sistema.

    O §4.2.6 diz testes regulares, não testes únicos. Um teste de há três anos não prova que o formato de cópia de hoje, o procedimento de restauro de hoje e as pessoas de hoje ainda funcionam em conjunto. Escolha uma cadência (trimestral ou semestral para sistemas críticos, anual para o resto), escreva-a no plano, corra-a, documente cada teste.

  • Fazemos cópia dos dados; as configurações reconstruímos do zero.

    Não. O §4.2.2(b) exige explicitamente que a cópia de segurança seja completa e exata, 'incluindo dados de configuração, incluindo dados armazenados em ambientes de computação em nuvem'. Uma base de dados sem a configuração da aplicação, as regras de firewall e as definições do fornecedor de identidade não é um sistema recuperável, é uma pilha de registos a que não consegue chegar. O plano tem de cobrir as configurações e os dados armazenados na cloud, não apenas as tabelas de produção.

Como os operadores reais do Mittelstand fazem isto

O que vemos na prática: a maioria do Mittelstand tem cópias de segurança. A maioria tem trabalhos noturnos a correr para um NAS ou para um bucket de cloud. O que normalmente falta é o plano documentado do §4.2.2 com tempos de recuperação por sistema, a localização de armazenamento fora do local nomeada, os controlos de acesso físico e lógico por escrito, os períodos de retenção por sistema e regulador, e o calendário de testes de recuperação. O trabalho de cópia de segurança existe. O plano à sua volta não existe.

A correção é pequena. Escreva o plano de seis pontos do §4.2.2 uma vez, aprove-o, e ponha um teste de recuperação no calendário (trimestral para sistemas críticos, semestral ou anual para o resto). Após o primeiro ciclo de testes, tem o pacote de evidência que o regulamento pede. A parte difícil não é a tecnologia. A parte difícil é ter o plano em papel e o teste no calendário.

Como tratamos disto na plataforma

O módulo BCP capta o plano de cópias de segurança de seis pontos do §4.2.2, o calendário de testes de recuperação, o registo de redundância para rede, ativos, pessoal e comunicações, e os resultados dos testes de recuperação com assinatura. Um módulo cobre do §4.2.2 ao §4.2.6.

Os testes são tarefas agendadas, não lembretes de texto livre. Quando um teste de recuperação corre, o resultado, as lacunas e as ações corretivas são captadas contra o mesmo registo. O registo de auditoria responde então a 'quando testou a recuperação pela última vez, o que falhou, o que fez a respeito' num clique. Sem registo de testes separado para manter.

Fontes
  • Diretiva (UE) 2022/2555 (NIS 2), Artigo 21(2)(c). eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), Anexo §4.2. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • Lei do BSI (BSIG), §30(2)(3) com a redação dada pela Lei de Implementação da NIS2 e de Reforço da Cibersegurança
  • BSI IT-Grundschutz Baustein CON.3 'Datensicherungskonzept'. bsi.bund.de/grundschutz
  • BSI IT-Grundschutz Baustein DER.2.3 'Notfallwiederherstellung der IT'. bsi.bund.de/grundschutz
  • Orientação Técnica de Implementação da ENISA para o CIR (UE) 2024/2690 (à data de maio de 2026)
Faça cópias de segurança e redundância sem uma pilha de documentos separada
Plano de seis pontos, calendário de testes, registo de redundância e evidência de testes de recuperação numa só plataforma. Gratuita, open source, sem lock-in.