Backup automático no SaaS de prontuário já cumpre a LGPD?

Não exatamente. O SaaS faz o backup do banco dele, normalmente sem garantia escrita de tempo de restore, sem teste documentado e sem cópia imutável fora do ambiente do próprio fornecedor. Se o SaaS sofre ataque ou some, sua clínica fica refém. A LGPD responsabiliza o controlador (a clínica), não o operador (o SaaS) — então o ônus de provar que existe backup íntegro e restaurável é seu, não do fornecedor.

Quanto tempo a clínica precisa guardar prontuário eletrônico segundo a lei?

A Lei 13.787/2018 estabelece 20 anos a partir do último registro como prazo mínimo, alinhando o prontuário físico e o digital. A Resolução CFM 1.821/2007 exige que o sistema atenda ao Nível de Garantia de Segurança 2 (NGS2), o que inclui controles de backup e auditoria. Esse prazo somado ao volume de dado sensível torna a estratégia de backup uma decisão de longo prazo, não uma configuração que se ajusta uma vez.

O que é um backup imutável e por que importa para clínica médica?

É uma cópia que não pode ser alterada nem apagada por um período definido, nem mesmo por quem tem credencial de administrador. Importa porque o ataque típico de ransomware em saúde criptografa o servidor de produção e tenta apagar os backups conectados antes de pedir resgate. Se a cópia imutável existe (em S3 com Object Lock, fita, ou disco offline), o atacante não consegue eliminar o caminho de volta. Sem ela, o backup está exposto ao mesmo risco do dado original.

Vale a pena fazer backup local em uma clínica pequena ou só backup em nuvem resolve?

Backup só em nuvem deixa a clínica refém da disponibilidade do provedor e do link de internet no momento do incidente. A regra de mercado mais aceita é 3-2-1-1: três cópias, em duas mídias diferentes, uma fora do site, uma imutável. Para clínica pequena, isso pode ser implementado com custo baixo: cópia local em NAS, cópia em nuvem (S3 ou equivalente) e uma rotação imutável. O ponto não é local versus nuvem — é diversidade controlada.

Como saber se o backup da minha clínica realmente funciona?

Restaurando. Backup que nunca foi restaurado é hipótese, não plano. A prática mínima é: a cada trimestre, escolher uma data aleatória, restaurar o banco em ambiente isolado e verificar se um prontuário específico abre corretamente. Documentar o teste com data, responsável e tempo de restore. Sem esse teste regular, a clínica descobre que o backup estava corrompido só no dia que precisa dele — geralmente no pior dia possível.

A ANPD pode multar a clínica por falha de backup?

Pode, indiretamente. A ANPD não exige backup específico, mas exige a guarda íntegra e disponível dos dados. Se um incidente apaga ou corrompe prontuários e a clínica não consegue recuperá-los, o controlador descumpriu o dever de zelar pela integridade do dado pessoal — uma das obrigações centrais da LGPD. A multa pode chegar a 2% do faturamento anual, com teto de R$50 milhões por infração, somada à possibilidade de suspensão das atividades de tratamento de dados.

Backup em clínica médica: 3 boas práticas que a maioria ignora

Em setembro de 2025, o grupo de ransomware KillSec atacou a MedicSolution, fornecedor brasileiro de software para gestão de clínicas. O resultado: 34 GB vazados, 94.818 arquivos sensíveis incluindo exames, imagens médicas e prontuários de menores. Várias clínicas que dependiam exclusivamente do backup do fornecedor ficaram dias sem acesso ao próprio histórico de pacientes.

A maioria dessas clínicas tinha “backup automático” contratado. O problema é que ninguém tinha testado o restore antes do dia em que precisaram.

Aqui estão três práticas de backup que separam segurança real de ilusão de segurança em clínica médica — e que a maioria das clínicas pequenas e médias ignora porque acredita que “o sistema cuida disso”.

Por que backup virou ponto cego em clínica média no Brasil

Backup deixou de ser problema técnico nos últimos anos porque virou commodity. Todo SaaS de prontuário promete backup automático, todo provedor de nuvem oferece snapshot diário, todo NAS tem agendamento integrado. A clínica contrata, vê a tela verde dizendo “último backup: hoje 03:00”, e fica tranquila.

O problema é que essa tranquilidade não responde três perguntas que a LGPD e a operação real exigem:

Esse backup, se eu precisar dele agora, vai voltar?
Se o atacante chegou no servidor de produção, ele já chegou no backup também?
Quem acessou esse backup, quando, e o que ele tirou?

A maioria das clínicas não sabe responder nenhuma das três. E é nesse vácuo que estão os incidentes mais caros do setor — não porque faltou backup, mas porque o backup que existia não fazia o que prometia.

Boa prática 1 — Restore testado é o que conta. Backup feito não.

A pergunta que define se um backup é real é simples: quando foi a última vez que você restaurou algo dele?

Se a resposta é “nunca” ou “não sei”, você não tem backup. Tem um arquivo grande encostado em algum lugar que talvez funcione no dia em que precisar.

Backup é uma promessa. Restore é a entrega da promessa. Sem teste regular de restore, a clínica está pagando por uma promessa não-verificada — e a única hora que vai descobrir se ela é falsa é exatamente no momento em que não pode arcar com isso.

A prática mínima viável para uma clínica pequena:

Trimestralmente, escolher uma data aleatória dos últimos 30 dias
Restaurar o backup dessa data em um ambiente isolado (não em produção)
Abrir três prontuários específicos e verificar se os dados estão íntegros — texto, anexos, evolução clínica
Cronometrar o tempo total: do início do restore até ter um sistema funcional
Documentar: data do teste, data do backup restaurado, tempo de restore, problemas encontrados, responsável

Esse processo leva meio dia uma vez por trimestre. Em troca, a clínica passa a saber, com dado real, que o backup funciona — e quanto tempo de operação está em risco se algo acontecer hoje.

Casos onde o backup falha silenciosamente são mais comuns do que parece. Banco corrompido por update mal feito do SaaS. Anexos guardados em diretório separado que o backup não pega. Versão do banco diferente entre origem e destino, que aceita o dump mas perde tabelas. Tudo isso só aparece no restore — nunca no momento em que o backup é gerado.

Boa prática 2 — Cópia imutável: o ransomware adora backup conectado

A segunda prática que a maioria das clínicas ignora é a regra 3-2-1-1: três cópias, em duas mídias diferentes, uma cópia fora do site, uma cópia imutável.

A parte ignorada é o último “1” — a cópia imutável. É justamente a que protege contra o cenário de ransomware que dominou o setor de saúde no Brasil em 2025.

O ataque típico funciona assim: o invasor entra no servidor (geralmente via phishing ou credencial vazada), passa alguns dias mapeando o ambiente, identifica onde está o backup, apaga ou criptografa o backup primeiro, e só depois ataca o sistema de produção. Quando a clínica percebe e vai restaurar, descobre que não tem o que restaurar.

Backup imutável quebra esse fluxo. É uma cópia que, depois de gravada, não pode ser modificada nem apagada por um período definido — nem mesmo pelo administrador do sistema. Se o atacante chegou ao servidor com credencial de root, ele consegue criptografar o disco de produção, mas não consegue tocar na cópia imutável.

Implementações concretas para clínica pequena:

Object Lock no S3 (AWS, Backblaze, MinIO self-hosted): habilita retenção compliance que impede deleção pelo período definido
Snapshots imutáveis no NAS (TrueNAS, Synology com versões recentes): camada extra que impede ransomware de apagar versões anteriores
Disco USB rotacionado e desconectado: solução baixa-tecnologia que funciona — três discos, um sai do cofre toda semana, dois ficam fora da rede
Fita LTO: viável para clínica que tem volume e precisa de retenção longa; o ransomware não chega no que está fisicamente desconectado

A combinação típica que a gente recomenda: cópia local rápida (para restore comum), cópia em nuvem com Object Lock (para disaster recovery), e uma rotação semanal em disco offline (para o caso pior). Custo total: a partir de R$200 a R$600 por mês para clínica pequena, dependendo do volume de prontuários e exames.

Boa prática 3 — Backup também é tratamento de dado pela LGPD

A terceira prática que a maioria das clínicas ignora é o tratamento de backup como dado regulado pela LGPD — porque é exatamente isso que ele é.

O backup contém os mesmos dados sensíveis do sistema de produção: diagnóstico, histórico clínico, resultado de exame, dado de menor, dado psiquiátrico. Tudo o que a LGPD considera dado pessoal sensível, com a categoria mais restrita da lei. Quando um backup é gerado, copiado para nuvem, restaurado em ambiente de teste ou exportado para um técnico, todas essas operações são tratamento de dado. E todas precisam de base legal, controle de acesso e audit trail.

O que a clínica precisa documentar:

Quem tem acesso ao backup — quais técnicos podem baixar, restaurar ou exportar; sob qual base legal acessam
Onde o backup mora — em qual servidor, em qual região, sob qual jurisdição (cuidado especial se o destino é S3 em região US sem cláusula de transferência internacional)
Por quanto tempo o backup é retido — política coerente com a Lei 13.787/2018 (mínimo 20 anos para prontuário) e com o princípio LGPD de minimização (não guardar mais do que precisa)
Audit trail de acesso ao backup — log de quem baixou, quando, com qual finalidade
Procedimento de exclusão segura — como o backup é descartado quando passa do prazo, com prova de eliminação

Sem essa documentação, a clínica está em situação confortável quando tudo dá certo e em situação muito ruim quando algo dá errado. Em uma fiscalização da ANPD após incidente, a primeira pergunta que vem é “como vocês controlam o acesso ao backup?”. A resposta “o sistema X cuida disso” não é suficiente — porque a responsabilidade é da clínica como controladora dos dados, não do fornecedor como operador.

A multa por descumprimento pode chegar a 2% do faturamento anual da clínica, com teto de R$50 milhões por infração, somada a sanções administrativas como suspensão das atividades de tratamento de dados — o que na prática paralisa o agendamento e o prontuário eletrônico até a regularização.

Como uma clínica monta isso na prática

A iAvancada monta essa camada de backup e governança em clínicas médicas como parte da estruturação de infra AI-ready. O ponto de partida é o mapeamento real do que existe hoje (geralmente uma cópia automática no SaaS, sem teste, sem imutabilidade, sem audit trail) e o caminho até a configuração 3-2-1-1 testada.

A operação concreta:

Inventário do que precisa ser protegido — banco do prontuário, anexos, base de imagens, configurações
Configuração das três camadas (local, nuvem com Object Lock, offline rotacionado) usando ferramentas open-source quando faz sentido (restic, Borg, pgBackRest para Postgres)
Definição de RTO (tempo de retorno aceitável) e RPO (perda máxima de dado aceitável) com a clínica
Implementação do teste trimestral de restore com checklist documentado
Camada de governança LGPD: política de acesso ao backup, audit trail, procedimento de descarte
Monitoramento ativo: a infra reporta automaticamente quando um backup falha; a clínica não fica sabendo só na hora do incidente

Tudo roda no servidor da clínica ou no cluster da Inteligência Avançada, dependendo do tamanho da operação. A regra é a mesma: dado de paciente fica sob controle do controlador, com audit trail completo e backup que efetivamente restaura.

O que fazer essa semana, sem grande projeto

Se a clínica quer começar antes de qualquer projeto maior, três ações de baixo custo que cabem na semana:

Pedir ao fornecedor do prontuário uma cópia exportada do banco completo, em formato lido por outro sistema. Se o fornecedor recusa ou cobra caro, esse já é o primeiro sinal de risco.
Tentar restaurar essa cópia em uma máquina separada, ou contratar alguém para fazer isso. Verificar se três prontuários reais abrem corretamente.
Documentar o resultado: quanto tempo levou, o que faltou, o que estava íntegro. Esse documento já vale como início de plano de continuidade — algo que a ANPD pode pedir em qualquer fiscalização.

O ponto não é virar especialista em backup. É ter a clareza, antes de um incidente, de que o caminho de volta existe e funciona.

Conclusão

Backup deixou de ser problema técnico e virou problema de governança. A clínica que tem “backup automático” mas nunca testou restore, não tem cópia imutável e não documenta acesso aos dados, está em situação de risco mesmo com tudo aparentemente em ordem.

O caminho não é caro nem complexo — é metodológico. Restore testado, cópia imutável e backup tratado como dado regulado. Três práticas que mudam a posição da clínica de “espera não acontecer” para “se acontecer, eu sei o que faço”.

Perguntas frequentes sobre backup em clínica médica

As perguntas abaixo são as mais comuns no diagnóstico inicial que a gente faz com clínicas que querem fechar esse buraco antes de virar incidente.