Resposta rápida

A ISO 27001 exige backup e cópia de segurança (controle 8.13), procedimento de restauração documentado e testes registrados — mas não define periodicidade: quem define é a organização, com base em RTO e RPO. Backup precisa ser criptografado em trânsito e em repouso, com gestão e rotação de chaves. Usar o backup do provedor de nuvem é aceito, desde que você verifique em contrato os tempos garantidos. E há um risco residual que poucos registram: a restauração pode reintroduzir dados pessoais que já deveriam ter sido eliminados.

Backup é o controle que todo mundo diz que tem — e que quase ninguém testa. Na ISO/IEC 27001, ele não é boa intenção de TI: é o controle 8.13 do Anexo A, obrigatório, auditável e diretamente ligado aos três pilares da segurança da informação (confidencialidade, integridade e disponibilidade).

Neste artigo, a consultora Jennifer Dantas, especialista em ISO 27001 e ISO 27701 na Templum, destrincha o que a norma realmente exige, o que fica a critério da organização e onde as empresas tropeçam na auditoria.

Backup e cópia de segurança não são a mesma coisa

Essa confusão aparece em quase toda implementação. O backup é a cópia dos dados que garante a continuidade da operação. A cópia de segurança é o plano B: se o backup falhar ou se perder, é ela que sustenta a recuperação.

Os dois são exigidos pela norma. E "dados" aqui não significa apenas hardware e software — significa ativo de informação: bases de dados, arquivos de usuários, documentos gerados durante a implementação e tudo o que está armazenado em sistemas, data centers e ferramentas.

O que a ISO 27001 exige no controle 8.13

A norma exige que existam cópias das informações, que elas sejam recuperáveis e que o processo esteja documentado. Traduzindo para a prática:

  • Cópia dos ativos críticos — bases de dados, arquivos de usuários e softwares e sistemas críticos para a operação.
  • Procedimento de restauração documentado — porque hoje quem restaura é uma pessoa, e amanhã pode ser outra. Conhecimento que mora só na cabeça de um profissional não é controle, é risco.
  • Testes de recuperação, com registro de resultados e ações corretivas quando o resultado não for o esperado.
  • Política que defina periodicidade, cenários de teste e responsabilidades.

A ISO 27701 também trata do tema, pelo recorte da privacidade — voltamos a isso adiante.

De quanto em quanto tempo fazer backup? A norma não diz

Essa é a dúvida mais frequente nos treinamentos, e a resposta surpreende: a ISO 27001 não define periodicidade. Não existe "backup semanal e cópia mensal" na norma. Fazer diferente do vizinho não gera não conformidade.

Quem define é a organização, e a decisão se apoia em dois indicadores de continuidade:

  • RTO (Recovery Time Objective) — quanto tempo você leva para recuperar e voltar a operar.
  • RPO (Recovery Point Objective) — quanto de informação você aceita perder. Se o backup é de hora em hora, você aceita perder até uma hora de dados.

É desse par que sai a periodicidade real: há dados que pedem backup diário, outros de hora em hora, outros de madrugada. O que a norma cobra é que a periodicidade exista, esteja escrita na política e seja cumprida.

Testar a restauração é o que separa backup real de backup no papel

Backup que nunca foi restaurado é uma hipótese, não um controle. O teste serve justamente para descobrir o problema antes do desastre — e um teste que dá resultado ruim não é fracasso, é informação.

Exemplo concreto: sua política diz que a ferramenta precisa voltar em uma hora, o teste levou duas. Isso não é um problema do teste, é um gap que você acabou de descobrir de graça. Registre, abra ação corretiva, ajuste e teste de novo.

Por isso a recomendação é testar em periodicidade curta: quanto mais cedo o gap aparece, mais barato ele é. E cada teste precisa de registro — o que foi feito, quem executou, quanto tempo levou e o que foi corrigido.

O que registrar em cada restauração

  • Quem executou (operador) e em qual sistema
  • Motivo da restauração e origem do backup
  • Horário de início e de término — é daqui que sai o RTO medido
  • Validação pós-restauração: os dados voltaram íntegros?
  • Evidência: quando não é possível gravar, prints com data e hora visíveis

Esse último ponto é onde muita empresa perde a evidência na auditoria. O auditor verifica se aquele print é daquele teste ou de uma recuperação de anos atrás.

Sincronização de relógio: o controle que ninguém liga ao backup

Parece detalhe burocrático, mas há um controle específico para isso (8.17) e ele tem consequência direta na recuperação. Horários inconsistentes comprometem a confiabilidade dos logs e a sequência de eventos em uma restauração forense — você pode estar registrando um tempo distorcido e descobrir isso no pior momento.

Boas práticas: usar NTP ou PTP de forma redundante, monitorar a deriva do relógio, marcar os backups com timestamps confiáveis, preservar fuso horário nos metadados e incluir essa verificação nos testes de restauração.

Quem opera ambiente híbrido — servidores locais e nuvem — precisa de atenção extra: o auditor vai perguntar qual é a sincronização dos dois ambientes e, se não seguirem a mesma referência, vai querer uma justificativa muito plausível. Provedores de nuvem normalmente já usam NTP, mas cabe a você confirmar se bate com o padrão interno.

Criptografia e gestão de chaves

Backup precisa ser criptografado em trânsito e em repouso. AES-256 é uma referência recomendada, e criptografia é requisito obrigatório da norma — em empresas menores isso pode se materializar como criptografia de disco, de ambiente ou uso de VPN, mas tem de existir.

E não basta criptografar: é preciso gerenciar as chaves. A política deve definir ciclo de rotação, backup das chaves e processo seguro de revogação, além de separar quem opera de quem administra as chaves — segregação que reduz o risco de exposição.

Onde entram a LGPD e a ISO 27701

Mesmo empresas que implementam só a ISO 27001 têm um requisito de privacidade a cumprir, e toda empresa está sujeita à LGPD. Três princípios afetam diretamente a política de backup:

  • Retenção mínima — armazenar apenas pelo tempo necessário ao propósito legítimo. A política de backup precisa estar alinhada às políticas de retenção e eliminação.
  • Eliminação efetiva — quando a finalidade expira ou há pedido de exclusão, o dado tem de ser destruído de forma irrecuperável, inclusive nos backups (expurgo planejado, retenção segregada ou destruição criptográfica).
  • Minimização — evitar incluir dados pessoais desnecessários em backups de sistemas não relacionados, e anonimizar quando aplicável. A norma pede que ambiente de teste não use dados reais; quando o cliente exige exceção, ela precisa de justificativa e controles documentados.

O risco residual que quase ninguém registra

Aqui está a armadilha mais elegante do tema: uma restauração pode reintroduzir dados que deveriam ter sido eliminados. Você cumpriu o direito ao esquecimento, apagou o dado — e o restore o traz de volta.

É o exemplo perfeito de risco residual: existe controle bem implementado e o risco continua existindo. Em segurança da informação, praticamente nenhum risco é 100% eliminado, e a norma pede a reavaliação periódica dos riscos ligados aos controles do Anexo A.

Práticas que mitigam: manter inventário de onde e quando dados pessoais entram em backup, adotar políticas de retenção diferencial com pontos de restauração que excluam dados já removidos, e usar pseudonimização e segmentação de backups para facilitar o expurgo.

Quando o backup é do provedor de nuvem

Usar o backup do próprio provedor é completamente aceito pela norma — cópia de disco, snapshot de máquina virtual, o plano nativo do fornecedor. Não há problema algum nisso.

Muda apenas o objeto de controle: em vez de executar, você passa a gerenciar o fornecedor. Isso significa saber, com base em contrato, qual é a periodicidade de backup garantida, qual o tempo de retenção da cópia de segurança e em quanto tempo o fornecedor devolve a restauração. E, principalmente, avaliar se esses números atendem ao seu RTO e RPO. A responsabilidade de executar pode ser dele; a de exigir e verificar é sempre sua.

Checklist para não travar na auditoria

  • Política de backup, retenção e criptografia alinhadas entre si
  • Periodicidade definida e justificada por RTO e RPO
  • Calendário de testes de restauração — automatizados quando possível, manuais sempre documentados
  • Registro de cada restauração com operador, horários e validação
  • Gestão de chaves com rotação e segregação de funções
  • Aprovação prévia para restaurações com dados sensíveis, envolvendo quem cuida de privacidade
  • Plano de comunicação: quem avisa, para quem, na indisponibilidade e na volta
  • Indicadores medidos e reportados ao comitê de segurança: taxa de sucesso das restaurações, tempo médio de recuperação e conformidade com a retenção

Um detalhe que os auditores costumam cobrar: eles comparam o calendário com a execução. Se a política diz "teste a cada seis meses" e ela existe há um ano, tem de haver dois testes registrados — ou um feito e o próximo agendado.

Assista ao treinamento técnico completo

Este artigo foi produzido a partir do treinamento técnico gratuito conduzido por Jennifer Dantas, com as dúvidas reais dos participantes respondidas ao vivo:

Leia mais

Perguntas frequentes

A ISO 27001 define de quanto em quanto tempo fazer backup?
Não. A norma não estabelece periodicidade. A definição é da organização e deve se basear no RTO (quanto tempo você leva para recuperar) e no RPO (quanto de informação aceita perder). Adotar uma periodicidade diferente da de outra empresa não gera não conformidade, desde que a sua esteja definida na política, justificada e cumprida.
Qual a diferença entre backup e cópia de segurança?
O backup é a cópia dos dados que garante a continuidade da operação. A cópia de segurança é o plano B: se o backup falhar ou for perdido, é ela que sustenta a recuperação. Os dois são exigidos pela ISO 27001.
Usar o backup do próprio provedor de nuvem atende à norma?
Sim, é completamente aceito, incluindo cópia de disco e snapshot de máquina virtual. O que muda é o objeto de controle: você precisa saber, por contrato, a periodicidade de backup garantida, o tempo de retenção e o prazo de restauração do fornecedor, e avaliar se esses números atendem ao seu RTO e RPO.
Backup precisa ser criptografado?
Sim. A criptografia é requisito da norma e deve cobrir os dados em trânsito e em repouso, com AES-256 como referência recomendada. Em organizações menores pode se materializar como criptografia de disco, de ambiente ou uso de VPN, mas precisa existir — acompanhada de gestão de chaves com rotação, backup das chaves e segregação entre quem opera e quem administra.
A sincronização de relógio é realmente obrigatória?
Sim, há um controle específico para isso no Anexo A (8.17). Horários inconsistentes comprometem a confiabilidade dos logs e a sequência de eventos em uma restauração forense. Recomenda-se NTP ou PTP redundante, monitoramento da deriva do relógio e verificação dessa consistência nos testes de restauração — atenção especial em ambientes híbridos, porque o auditor compara a sincronização entre nuvem e ambiente local.
Restaurar um backup pode violar a LGPD?
Pode, e esse é um risco residual que poucas empresas registram: a restauração é capaz de reintroduzir dados pessoais que já deveriam ter sido eliminados por fim de finalidade ou pedido de exclusão. Mitiga-se com inventário de onde e quando dados pessoais entram em backup, políticas de retenção diferencial, pontos de restauração que excluem dados já removidos e uso de pseudonimização e segmentação.

Pronto para certificar sua empresa?

Fale com um especialista da Templum e receba um diagnóstico gratuito — com garantia de 200%.

Falar com um especialista