Por Luciano Poubel · Publicado originalmente no LinkedIn em 14 de setembro de 2026.
Ransomware, prontuários indisponíveis, backups e fornecedores: o que acontece quando a tecnologia que sustenta a clínica simplesmente deixa de funcionar?
Tony Stark chegou à clínica às 8h20 para uma consulta marcada dez minutos depois.
A recepcionista pediu seu nome e tentou abrir o cadastro. A tela ficou carregando. Tentou novamente, sem sucesso. No computador ao lado, outra funcionária procurava a agenda do dia. No consultório, o profissional não conseguia acessar os prontuários. O financeiro estava sem o sistema de cobrança e o telefone começava a tocar porque algumas confirmações automáticas não haviam sido enviadas.
— O sistema caiu — alguém informou.
Até ali, poderia ser apenas mais uma manhã em que a tecnologia resolveu testar a paciência de todo mundo.
Então uma das telas mudou.
No lugar do sistema apareceu uma mensagem informando que os arquivos haviam sido criptografados e que seria necessário realizar um pagamento para recuperá-los.
A recepção ficou em silêncio.
— Desliga tudo? — perguntou alguém.
— Liga para a empresa do sistema — sugeriu outra pessoa.
Uma terceira tentou tranquilizar a equipe:
— Pelo menos ninguém vazou nada. Só bloquearam os arquivos.
Tony olhou para a tela. Tinha alguma experiência com tecnologia criada para facilitar a vida e que, em determinado momento, passava a controlar coisas demais.
— Vocês têm certeza de que ninguém copiou os dados?
Ninguém tinha.
Ele fez outra pergunta:
— E como vocês vão atender os pacientes agora?
Essa resposta também não existia.
A clínica não sabia se o ataque havia ficado restrito à criptografia dos arquivos, se alguém permanecia dentro da rede, se informações tinham sido copiadas antes do bloqueio, se os backups estavam íntegros ou quanto tempo seria necessário para recuperar os sistemas. Mas havia algo ainda mais imediato: pacientes já estavam dentro do estabelecimento e profissionais não conseguiam acessar informações utilizadas no cuidado.
Naquele instante, o problema deixou de ser apenas de informática.
Virou problema de continuidade assistencial, gestão, segurança da informação, contratos e, possivelmente, proteção de dados.
É disso que este episódio trata.
Nem toda queda de sistema é um ataque. Mas, quando a tecnologia realmente falha, a clínica sabe continuar funcionando? Existe um plano B? O que acontece quando o prontuário fica indisponível? Um atendimento deve continuar sem acesso a determinadas informações? Ter backup basta? E se a falha estiver no sistema terceirizado? Pagar ransomware resolve? O que deve ser preservado antes de restaurar os computadores? E como saber que chegou a hora segura de voltar ao normal?
Depois de vários episódios falando sobre proteção da informação, nossa pergunta agora é outra:
como continuar cuidando quando a informação deixa de estar disponível?
Nem todo sistema fora do ar significa ataque
Essa distinção precisa vir primeiro.
O sistema pode ficar indisponível porque a internet caiu, um servidor apresentou defeito, houve manutenção, algum componente falhou ou o fornecedor está enfrentando instabilidade. Nada disso significa automaticamente invasão, ransomware ou comprometimento de dados pessoais.
Outra situação é encontrar sinais concretos de comprometimento: arquivos criptografados, acessos desconhecidos, credenciais utilizadas indevidamente, dados alterados, sistemas bloqueados por agente malicioso ou outros indícios de perda de controle sobre as informações.
A ANPD deixa claro que incidentes de segurança não envolvem apenas quebra de confidencialidade. Perda e indisponibilidade de dados pessoais também podem configurar incidente. A própria Autoridade utiliza como exemplo a indisponibilidade prolongada de um sistema hospitalar por ransomware, impedindo acesso a dados de pacientes ou realização de procedimentos e produzindo risco à saúde.
Isso significa que a primeira missão de Tony não seria anunciar:
— Fomos hackeados.
Seria descobrir:
o que realmente aconteceu e qual é o impacto disso na operação e nos pacientes?
Sem essa resposta, qualquer certeza é prematura.
O problema pode ser tecnológico. A consequência pode ser clínica.
Imagine que o sistema de agenda esteja indisponível, mas a clínica consiga confirmar uma consulta administrativa por outro meio. Existe transtorno, mas talvez o atendimento ainda possa ocorrer normalmente.
Agora mude o cenário.
Uma paciente chegou para um procedimento. O profissional precisa confirmar alergias, medicamentos em uso, exames recentes ou uma orientação anterior, mas essas informações estão apenas no prontuário que deixou de abrir.
A pergunta deixa de ser:
— Quando a TI vai resolver?
e passa a ser:
— Temos informação suficiente para continuar com segurança?
Essa decisão não deveria ser tomada pela recepção preocupada com a fila nem pelo gestor preocupado com o faturamento do dia. Dependendo da natureza do atendimento, quem responde tecnicamente pelo cuidado precisará avaliar se há condições seguras para prosseguir ou se o mais adequado é adiar, reagendar ou adotar outra alternativa.
A RDC nº 63/2011 da Anvisa reforça uma lógica importante: serviços de saúde devem trabalhar com processos organizados, recursos necessários, registros confiáveis, normas e rotinas escritas e atualizadas e mecanismos voltados à continuidade e à segurança da assistência.
A norma não criou um “plano de ransomware” obrigatório para toda clínica.
Mas deixa muito difícil defender uma operação cuja única estratégia diante da falha tecnológica seja:
— Quando o sistema voltar, a gente vê.
Plano de contingência não é uma pasta chamada “emergência”
Tony pergunta:
— Qual é o plano de contingência?
A gerente procura no computador.
O computador não abre.
Talvez essa cena explique o problema melhor do que qualquer definição.
Um plano de contingência só é útil se puder ser executado justamente quando o caminho habitual não está disponível. Isso não exige que a clínica mantenha uma segunda operação inteira pronta para ser ativada nem que imprima todos os prontuários preventivamente. Exige conhecer suas dependências críticas e ter respostas mínimas para quando elas falham.
Se a agenda desaparecer, como identificaremos os atendimentos do dia?
Se o prontuário ficar inacessível, quais atividades podem continuar e quais dependem de informações que não conseguimos confirmar com segurança?
Se forem necessários registros provisórios, como serão identificados, protegidos e posteriormente incorporados ao sistema oficial sem perder cronologia e autoria?
Como avisaremos pacientes sobre atrasos ou cancelamentos?
Quem pode decidir que determinado procedimento precisa ser suspenso?
Essas perguntas ficam muito mais fáceis quando são respondidas antes da crise.
Plano B não é o documento.
É a capacidade real de continuar tomando decisões coerentes quando o plano A desaparece.
A tentativa de manter tudo funcionando pode criar um segundo incidente
O sistema cai e a equipe tenta ser eficiente.
Uma pessoa cria rapidamente uma planilha particular. Outra começa a mandar dados clínicos para o próprio e-mail. Alguém fotografa documentos com o celular para não perder o registro. Orientações passam a circular num grupo de mensagens porque “depois a gente organiza”.
A intenção é boa: manter a clínica funcionando.
O resultado pode ser justamente o contrário.
A contingência não deveria criar uma segunda infraestrutura improvisada, sem controle de acesso, sem padrão de registro e sem certeza de que as informações voltarão para o prontuário depois.
Conforme a atividade e as normas profissionais aplicáveis, a clínica pode prever meios temporários de registro e comunicação. O importante é que eles tenham responsáveis, proteção mínima e um fluxo para posterior reconciliação com os sistemas oficiais.
Não precisamos escolher entre fechar imediatamente toda a clínica e espalhar dados em qualquer lugar para continuar funcionando.
Existe um terceiro caminho: contingência planejada.
Ter backup não significa conseguir voltar ao normal
Depois de quarenta minutos, alguém lembra:
— Temos backup.
A sala inteira respira.
Tony pergunta:
— Quando vocês testaram a restauração pela última vez?
Silêncio.
Existe uma diferença enorme entre ter uma cópia de arquivos em algum lugar e possuir capacidade real de recuperar a operação.
Backups podem estar incompletos, desatualizados ou inacessíveis. Podem estar conectados ao mesmo ambiente comprometido. Podem depender de credenciais que ninguém possui naquele momento. E podem parecer perfeitos até a primeira tentativa de restauração.
O CERT.br recomenda proteger prioritariamente sistemas e dados críticos, especialmente backups, durante a contenção de ransomware. Na fase de recuperação, orienta restaurar os dados a partir de cópias confiáveis, preferencialmente offline, somente depois de corrigir a causa do comprometimento e preparar o ambiente para uma retomada segura.
É por isso que uma estratégia de continuidade não deveria perguntar apenas:
— Temos backup?
A pergunta mais útil é:
quanto tempo precisamos para recuperar o que realmente mantém a clínica funcionando — e quando foi a última vez que provamos que conseguimos fazer isso?
Os primeiros minutos não combinam com heroísmo individual
Tony Stark provavelmente teria vontade de conectar algum equipamento próprio e começar a resolver tudo sozinho.
Na clínica, eu evitaria.
Quando há indícios de ransomware, o CERT.br recomenda ação rápida para conter a progressão do ataque, proteger sistemas ainda não comprometidos e isolar aqueles já afetados. Também recomenda preservar evidências e coletar informações relevantes antes de alterar desnecessariamente os sistemas, porque modificações precipitadas podem destruir justamente aquilo que ajudaria a entender a extensão do ataque e recuperar o ambiente.
O funcionário que vê a tela estranha não precisa saber fazer perícia digital.
Precisa saber o protocolo.
Quem deve ser avisado primeiro?
Quem possui autoridade para decidir ações técnicas que podem afetar a operação?
Que fornecedor precisa ser acionado?
Quem registra a cronologia?
Quem trata das consequências assistenciais?
Quem avalia as questões jurídicas e de proteção de dados?
Uma organização preparada não exige que todo mundo seja Tony Stark.
Exige que cada pessoa saiba quando deve parar de improvisar.
“Formata tudo e instala de novo” pode apagar mais do que o malware
A urgência é compreensível.
A agenda está parada.
Pacientes aguardam.
A direção quer o sistema funcionando novamente.
Então surge a sugestão:
— Formata logo os computadores.
Talvez alguma reinstalação realmente faça parte da recuperação posterior. O problema é fazer isso antes de compreender minimamente o ambiente comprometido.
Logs, memória, registros de acesso e outros elementos podem ajudar a identificar o ponto de entrada, o período do comprometimento, os sistemas afetados, acessos persistentes e sinais de exfiltração. O CERT.br recomenda preservar evidências quando possível e coletar os elementos necessários antes de modificar o sistema comprometido.
Essas informações interessam à equipe técnica.
Podem interessar ao jurídico.
Podem influenciar a análise de proteção de dados.
Podem ser relevantes numa investigação policial ou numa discussão contratual com o fornecedor.
Responder rápido não é o mesmo que apagar rapidamente.
O sistema é terceirizado. Então o problema é só do fornecedor?
A clínica descobre que não hospeda os dados localmente.
— Ótimo. Então a crise é da empresa do sistema.
Não exatamente.
O fornecedor pode ter obrigações técnicas e contratuais relevantes. Pode ser responsável pela infraestrutura afetada e precisar restaurar o serviço.
Mas os pacientes continuam na clínica.
É a clínica que precisa decidir se determinado atendimento pode prosseguir, explicar a indisponibilidade, administrar sua agenda, preservar o cuidado e entender o impacto da falha sobre sua própria operação.
Também há outra dimensão. Quando o fornecedor atua como operador no tratamento de dados pessoais, a ANPD orienta que ele informe o controlador sobre incidentes sem demora injustificada e forneça as informações necessárias para a avaliação e para eventual comunicação. A própria Autoridade recomenda que essas responsabilidades estejam previstas em contrato.
É aqui que um contrato tecnológico deixa de ser um PDF esquecido numa pasta.
Ele deveria responder, conforme o serviço:
qual nível de disponibilidade foi contratado?
como funciona o suporte emergencial?
em quanto tempo o fornecedor precisa comunicar um incidente?
quais mecanismos de backup e recuperação existem?
é possível exportar os dados?
qual é o plano se a plataforma ficar indisponível por horas ou dias?
Esse assunto abrirá perfeitamente o próximo episódio.
Por enquanto, basta guardar:
terceirizar o sistema não terceiriza a necessidade de manter a clínica funcionando.
Arquivos criptografados não provam que os dados ficaram dentro da clínica
Outro erro comum aparece rapidamente:
— Os criminosos bloquearam os arquivos. Então não levaram nada.
Talvez.
Mas ainda precisamos investigar.
O próprio roteiro de resposta do CERT.br recomenda analisar evidências para descobrir, entre outras coisas, possíveis dados exfiltrados, conexões feitas pelo atacante e sistemas utilizados para transferência de informações. Em muitos ataques, a criptografia pode ser apenas uma parte da invasão.
Por isso, enquanto a investigação não estiver concluída, eu evitaria tanto:
— Com certeza vazou tudo.
quanto:
— Ninguém teve acesso.
A formulação mais responsável é:
— Temos uma indisponibilidade confirmada e estamos apurando se também houve acesso ou transferência não autorizada de dados.
Isso pode parecer menos tranquilizador.
Mas é muito mais seguro do que garantir algo que ninguém ainda sabe.
E a ANPD? Aqui ela é uma parte da resposta, não o assunto inteiro
Nós já trabalhamos profundamente a comunicação de incidentes no episódio de Ethan Hunt.
Aqui basta lembrar o essencial.
Nem todo incidente de segurança precisa ser comunicado à ANPD. O controlador deve avaliar se o incidente está confirmado, envolve dados pessoais sujeitos à LGPD e pode acarretar risco ou dano relevante aos titulares. Quando os critérios regulamentares estiverem presentes, a regra geral da Resolução nº 15/2024 é a comunicação à ANPD e aos titulares em até três dias úteis, ressalvadas legislações específicas. Se ainda não houver todas as informações, a comunicação pode ser complementada posteriormente nos termos do regulamento.
A ANPD inclusive apresenta como exemplo de risco relevante a indisponibilidade prolongada de um sistema hospitalar causada por ransomware quando ela impede acesso a dados dos pacientes ou realização de procedimentos.
Mas nosso foco aqui não é preencher o formulário da Autoridade.
Enquanto alguém avalia a obrigação regulatória, existem pacientes esperando atendimento.
A clínica precisa conseguir fazer duas coisas ao mesmo tempo:
cumprir suas obrigações de proteção de dados e manter a assistência segura durante a crise.
Devemos pagar o resgate?
A pergunta chega cedo ou tarde.
Na tela existe um valor, um endereço para pagamento e uma promessa de recuperar o acesso.
O CERT.br faz uma advertência importante: pagar não garante a recuperação total dos dados, não assegura sua confidencialidade e não impede novas tentativas de extorsão. O próprio guia ressalta que eventual negociação ou pagamento envolve decisões jurídicas e de negócio que devem fazer parte do plano de resposta, e não ser tratadas como ato impulsivo de quem está diante da mensagem.
Por isso, eu evitaria respostas absolutas formuladas antecipadamente sem conhecer o contexto:
“Paga logo.”
ou
“Nunca existe hipótese de pagar.”
O que não pode acontecer é confundir pagamento com estratégia de recuperação.
A prioridade continua sendo conter o ataque, compreender sua extensão, eliminar a causa do comprometimento e recuperar a operação de forma segura.
Quando é melhor suspender o atendimento?
Essa talvez seja a pergunta mais difícil do episódio porque não existe uma única resposta para todas as clínicas.
Um sistema de agenda fora do ar não é o mesmo que um prontuário inacessível durante um procedimento complexo.
A recepção pode explicar ao paciente que há indisponibilidade e reorganizar horários. A equipe técnica pode dar previsão de recuperação. A gestão pode coordenar recursos.
Mas, quando a falta de acesso interfere na informação necessária à segurança clínica, a decisão precisa envolver quem possui responsabilidade técnica pelo atendimento.
Se é possível continuar de maneira segura, com registros adequados e contingência prevista, não existe razão para paralisar tudo apenas porque um software falhou.
Se informações essenciais não podem ser confirmadas e isso compromete a segurança, talvez reagendar seja a decisão mais responsável.
O sistema caiu.
A responsabilidade profissional não caiu junto.
Papel pode ser um plano B. Folha solta não deveria ser.
Em algumas operações, registros provisórios em papel podem fazer parte da contingência.
Isso é muito diferente de começar a anotar informações de pacientes em qualquer folha disponível.
A RDC nº 63/2011 define prontuário como documento que possibilita comunicação entre a equipe e continuidade da assistência. Também exige que os serviços mantenham normas, procedimentos e rotinas técnicas escritas e atualizadas para seus processos de trabalho e garantam guarda, integridade, confidencialidade e disponibilidade dos prontuários quando necessária.
Por isso, se a clínica prevê documentação temporária durante uma indisponibilidade, precisa definir antes como identificar o paciente, registrar autoria e horário, preservar o documento e incorporar posteriormente essas informações ao prontuário oficial.
A contingência não pode produzir uma segunda história clínica paralela que desaparece depois que o sistema volta.
O sistema voltou. Isso não significa que a crise acabou.
Horas depois, a tela de login reaparece.
A tentação é enorme:
— Liberem todas as agendas.
Ainda existe trabalho a fazer.
O CERT.br recomenda restaurar os sistemas a partir de fontes confiáveis, corrigir a vulnerabilidade ou causa que permitiu o comprometimento, revisar acessos e credenciais, garantir a integridade dos dados recuperados e reconectar o ambiente de forma controlada.
Isso é particularmente importante numa clínica.
Imagine voltar à operação e descobrir depois que determinados prontuários foram recuperados numa versão antiga, que informações recentes não foram restauradas ou que o ambiente continuava vulnerável ao mesmo atacante.
Retomar rápido não é sinônimo de recuperar bem.
A retomada faz parte do incidente.
Não é simplesmente o momento em que a tela deixa de estar preta.
Depois da crise vem a parte que Tony Stark provavelmente mais valorizaria
O sistema funciona novamente.
A agenda foi reorganizada.
Os pacientes voltaram.
A direção quer esquecer o assunto.
Tony provavelmente faria o contrário.
Depois que uma armadura falha, ele tenta descobrir por que falhou.
O CERT.br recomenda justamente uma etapa de lições aprendidas após a recuperação: documentar o incidente, consolidar evidências, revisar o plano de resposta, corrigir o que não funcionou e melhorar as medidas preventivas e de detecção.
Talvez a vulnerabilidade tenha sido técnica.
Talvez o maior problema tenha sido operacional.
O fornecedor demorou horas para responder.
O backup não estava separado.
A clínica não sabia quem deveria decidir sobre os procedimentos do dia.
O plano de contingência estava armazenado apenas no sistema que ficou indisponível.
Ninguém sabia como reconstruir os registros feitos durante a crise.
Essas conclusões podem ser desconfortáveis.
Também são uma das partes mais valiosas do incidente.
Um ataque que não modifica nenhum processo pode virar apenas ensaio para o próximo.
Se estivéssemos advogando para Tony
Não partiríamos da conclusão de que seus dados foram “vazados” apenas porque houve ransomware.
Primeiro verificaríamos se seus dados estavam nos sistemas afetados, se houve indisponibilidade, acesso não autorizado, alteração ou sinais de exfiltração. Também investigaríamos se a falha tecnológica interferiu concretamente no atendimento e quais medidas a clínica possuía para manter a assistência.
Depois analisaríamos a resposta.
Quanto tempo levou para perceber o problema?
Houve contenção?
A clínica comunicou os fatos conhecidos sem fazer afirmações falsas?
Tomou medidas razoáveis para proteger os pacientes?
Cumpriu eventuais obrigações regulatórias?
Se houver danos concretos, essa dimensão também será examinada.
Ataque cibernético não produz automaticamente todas as formas de responsabilidade civil.
Mas ser vítima de criminoso também não apaga, por si só, os deveres de prevenção, segurança, resposta e mitigação.
O Direito continua olhando para o que aconteceu antes, durante e depois.
Se fôssemos os advogados da clínica
Nossa primeira preocupação não seria redigir uma nota pública.
Seria organizar a crise.
Quem coordena a resposta? Quais sistemas estão afetados? Existe impacto assistencial? Alguma atividade precisa ser suspensa? Qual fornecedor foi acionado? A equipe técnica está preservando evidências? Como os registros serão mantidos durante a contingência?
Ao mesmo tempo, construiríamos uma cronologia confiável: quando o problema foi percebido, por quem, quais decisões foram tomadas, quais equipamentos e serviços foram afetados e quais informações os fornecedores forneceram.
Depois viria a análise de dados pessoais e das obrigações perante a ANPD e os titulares, sem repetir automaticamente fórmulas de outros incidentes. Se houver dever de comunicação, ele será cumprido. Se não houver, a decisão também deverá ser documentada.
E, quando a operação voltar, revisaríamos contratos, backups, acessos, causa raiz, treinamento e plano de continuidade.
Porque o objetivo do jurídico não deveria ser apenas ajudar a clínica a sobreviver ao incidente.
Deveria ajudá-la a sair dele menos vulnerável.
O teste do Tony Stark
Imagine que amanhã, às 8h20, o sistema utilizado pela clínica pare de funcionar e apareça uma mensagem de ransomware.
Pergunte à equipe quem deve ser avisado primeiro e quem coordena a resposta. Descubra quais sistemas são realmente essenciais e quem pode decidir se determinado procedimento continua ou precisa ser suspenso. Verifique se existe uma forma controlada de registrar atendimentos durante a contingência e se os backups estão disponíveis, protegidos e efetivamente testados.
Depois olhe para os fornecedores. Existe canal de emergência? O contrato estabelece suporte, comunicação e recuperação? Alguém sabe a quem ligar sem procurar o contrato no mesmo sistema que acabou de cair?
Por fim, faça uma pergunta simples:
— Se isso acontecesse agora, saberíamos o que fazer nos primeiros trinta minutos?
Se a resposta for:
— Acho que sim.
Tony provavelmente pediria um teste.
Tony reconstruiu a armadura. A clínica precisa reconstruir o processo.
No final do dia, alguns sistemas voltaram.
Outros ainda estavam em recuperação.
Parte da agenda precisou ser reorganizada e determinados atendimentos foram adiados porque a equipe preferiu não prosseguir sem informações que considerava essenciais.
Os backups funcionaram, mas a recuperação demorou mais do que todos imaginavam. A clínica descobriu que o suporte contratado não tinha o tempo de resposta que a direção acreditava ter comprado. E percebeu que seu plano de contingência estava praticamente resumido a uma frase:
“Liga para o rapaz da informática.”
Tony reconheceria o problema.
Depois que uma armadura falha, o mais importante não é apenas fazê-la voltar a funcionar. É descobrir por que falhou, quais sistemas dependiam daquele ponto e o que precisa mudar antes da próxima batalha.
A clínica também não precisa abandonar tecnologia porque um sistema parou. Prontuário eletrônico, nuvem, automação e integração podem melhorar enormemente a assistência.
O risco está em construir uma operação tão dependente de um único caminho que ninguém consegue cuidar com segurança quando aquela peça deixa de funcionar.
Tecnologia deve aumentar capacidade.
Não criar dependência cega.
Por isso, talvez a pergunta mais importante deste episódio não seja:
“E se formos hackeados?”
É outra:
“Se amanhã a tecnologia que sustenta nossa clínica parar, ainda saberemos cuidar das pessoas com segurança enquanto recuperamos o controle?”
Referências oficiais e técnicas
BRASIL. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD), especialmente arts. 46 a 49 — segurança e incidentes envolvendo dados pessoais.
AGÊNCIA NACIONAL DE PROTEÇÃO DE DADOS — ANPD. Comunicação de Incidente de Segurança — orientações sobre indisponibilidade, ransomware, avaliação de risco, comunicação e papéis de controlador e operador.
AGÊNCIA NACIONAL DE PROTEÇÃO DE DADOS — ANPD. Resolução CD/ANPD nº 15/2024 — Regulamento de Comunicação de Incidente de Segurança.
ANVISA. Resolução RDC nº 63/2011 — Requisitos de Boas Práticas de Funcionamento para os Serviços de Saúde, especialmente quanto a qualidade, segurança do paciente, prontuário, processos de trabalho e gestão das atividades assistenciais.
CERT.br. Ransomware: Como Responder, versão 1.1, de outubro de 2025 — plano de resposta, contenção, preservação de evidências, análise, recuperação e lições aprendidas.
Aviso: Este artigo apresenta orientações jurídicas e de governança em caráter geral. A resposta a falhas tecnológicas e incidentes cibernéticos depende do tipo de serviço, sistemas envolvidos, impacto assistencial, categoria dos dados, contratos tecnológicos, normas profissionais e circunstâncias concretas do evento.
Deixe um comentário