Uma distribuidora de médio porte mantém o ERP em servidor próprio, administrado por uma empresa de suporte de TI. Na madrugada de um sábado, por volta das 02h40, um ransomware cifra o servidor de arquivos, o banco de dados do ERP e o backup, que estava na mesma rede. A operação só volta na quarta-feira.
Os registros mostram que o primeiro acesso aconteceu na sexta-feira, às 23h15, pela ferramenta de acesso remoto, com a conta de um técnico do prestador. A conta era administradora em todos os servidores, fora criada pela própria distribuidora em 2022, era compartilhada por três técnicos e não exigia segundo fator de autenticação (MFA). A senha era a mesma que o técnico usava no ambiente de outro cliente, invadido semanas antes. Já dentro da rede, o invasor explorou uma falha do sistema de documentos fiscais cuja correção o fornecedor havia publicado seis meses antes. Ninguém a aplicou.
A distribuidora quer cobrar o prestador, porque a credencial era dele. O prestador responde que a conta foi criada pela cliente, sem MFA e com privilégios que ele nunca pediu. O fornecedor lembra que avisou da correção por e-mail. Cada um tem parte da razão, e por isso a pergunta do título não se responde com o relatório forense.
Por onde entrou e quem responde são perguntas diferentes
O relatório técnico reconstrói a sequência de eventos. O direito pergunta quem tinha o dever de evitar cada um deles. Entre empresas, a resposta começa no contrato: quem descumpre obrigação responde por perdas e danos (art. 389 da lei 10.406/02, o CC), que abrangem o que a outra parte efetivamente perdeu e o que razoavelmente deixou de lucrar (art. 402 do CC), limitadas ao efeito direto e imediato da inexecução (art. 403 do CC).
A defesa mais frequente é tratar o ataque como caso fortuito. O art. 393 do CC afasta a responsabilidade pelo fato necessário cujos efeitos não era possível evitar ou impedir, salvo se o devedor tiver assumido esse risco expressamente. Um ataque que entra por senha reutilizada em conta sem segundo fator e avança por uma falha corrigida há meses dificilmente se encaixa nessa definição. Para instituições financeiras, o STJ consolidou na súmula 479 que elas “respondem objetivamente pelos danos gerados por fortuito interno relativo a fraudes e delitos praticados por terceiros no âmbito de operações bancárias”. A súmula trata de bancos em relação de consumo e não se transporta sem ajustes para um contrato entre empresas, mas serve de referência: quem vende administração de servidores vende também a guarda das credenciais que usa.
Na esfera da lei 13.709/18 (LGPD), o STJ deu um passo parecido. No REsp 2.147.374/SP (relator ministro Ricardo Villas Bôas Cueva, j. 3/12/24), a 3ª turma não reconheceu a culpa exclusiva de terceiro (art. 43, III, da LGPD) invocada com base apenas na ocorrência de um ataque, porque cabia ao agente de tratamento demonstrar que havia adotado as medidas de segurança esperadas. A decisão trata da responsabilidade perante o titular, mas indica como o tribunal lê o argumento de que “foi o invasor”.
O que o contrato atribuía a cada um
Contratos de suporte de TI costumam descrever horas de atendimento e tempo de resposta. Poucos dizem quem cria contas, quem define privilégios, quem revisa acessos, quem aplica atualizações. Quando o contrato é omisso, a discussão migra para o que se espera de um prestador diligente e para o que as partes praticaram ao longo da relação, sob a boa-fé do art. 422 do CC.
Quando o contrato trata do tema, ele tende a prevalecer. O art. 421-A do CC presume paritários e simétricos os contratos empresariais e determina que a alocação de riscos definida pelas partes seja respeitada. Uma cláusula que limita a responsabilidade do prestador a doze mensalidades, ou que exclui lucros cessantes, em geral será levada a sério pelo juiz, ressalvada a discussão sobre sua aplicação a condutas de culpa grave.
O contrato também define o que cada parte deveria ter dito à outra. O prestador que administra o ambiente e percebe que a conta compartilhada não exige MFA tem o dever de avisar por escrito e propor a correção; se avisou e a cliente recusou o custo, o registro dessa recusa pesa a favor dele. As referências de mercado tratam isso como gestão de fornecedores: o CIS Controls v8.1 (Center for Internet Security, 2024) pede, no controle 15, requisitos de segurança nos contratos com provedores de serviço (15.4) e descomissionamento seguro ao fim da relação (15.7); o NIST CSF 2.0 (National Institute of Standards and Technology, 2024) reúne na categoria GV.SC a definição de papéis de segurança para fornecedores (GV.SC-02) e a inclusão desses requisitos nos contratos (GV.SC-05). Nenhuma delas tem força de lei, mas ambas documentam o que um prestador diligente faz.
A conta administrativa sem MFA e a senha reutilizada
No exemplo, duas condutas se somaram: a distribuidora criou uma conta de administrador compartilhada, sem segundo fator, e nunca revisou os privilégios; o técnico reutilizou a senha em outro ambiente. Nenhuma das duas, sozinha, teria produzido aquele ataque.
O art. 945 do CC manda fixar a indenização considerando a gravidade da culpa da vítima em confronto com a do autor do dano, e o art. 944 do CC mede a indenização pela extensão do dano, com redução equitativa quando houver desproporção excessiva entre culpa e resultado. Os dois artigos estão na parte da responsabilidade extracontratual, mas a proporcionalidade que expressam vale também no contrato.
A divisão dependerá de quem tinha o dever de exigir o segundo fator. Se o contrato dizia que a segurança das contas era da cliente e o prestador apenas executava chamados, a culpa da cliente pesa mais. Se o prestador administrava o ambiente com autonomia, a conta compartilhada e a ausência de MFA passam a ser omissões dele. A reutilização de senha é negligência do técnico em qualquer cenário, e o prestador responde perante a cliente pela conduta de quem escala para executar o serviço. O controle 6 do CIS Controls v8.1 (Center for Internet Security, 2024) exige MFA para todo acesso administrativo, inclusive quando o ativo é gerido por terceiro (6.5), e revisão dos privilégios ao menos anual (6.8).
O fornecedor de software e a falha conhecida
A posição do fornecedor muda conforme quem opera o sistema. Se o sistema é entregue como serviço na nuvem (SaaS), o fornecedor administra o ambiente, e uma falha conhecida sem correção por seis meses é inexecução da obrigação de manter o serviço seguro, com perdas e danos nos limites do contrato (art. 389 do CC). Se o sistema roda no servidor da cliente, o fornecedor cumpre a parte dele ao publicar a correção e comunicá-la; a instalação cabe a quem administra o servidor.
A correção não aplicada tende a pesar sobre quem administrava o servidor, mas o fornecedor não fica automaticamente fora: se o aviso foi a um contato desatualizado, ou sem indicar que a falha estava sendo explorada, há espaço para discutir se ele cumpriu o dever de informar. Quando o sistema trata dados pessoais, a LGPD acrescenta um critério: o tratamento é irregular quando não fornece a segurança que o titular pode esperar, consideradas as técnicas disponíveis à época (art. 44, III, da LGPD).
Dados pessoais: Controlador, operador e solidariedade
Se o servidor cifrado continha dados pessoais, existe uma segunda camada de responsabilidade, perante os titulares. A distribuidora é controladora. O prestador que acessa o banco de dados e gere o backup trata dados em nome dela; o fornecedor de SaaS também. O Guia orientativo da ANPD sobre agentes de tratamento (Autoridade Nacional de Proteção de Dados, 2022, p. 16-18) descreve o operador como quem trata dados em nome do controlador e pode definir elementos não essenciais do tratamento, como medidas técnicas.
Perante o titular, o operador responde solidariamente quando descumpre as obrigações da legislação de proteção de dados ou não segue as instruções lícitas do controlador (art. 42, § 1º, I, da LGPD). A reutilização de senha por técnico com acesso administrativo ao banco de dados viola o dever de segurança do art. 46 da LGPD, que o art. 47 da LGPD estende a qualquer pessoa que intervenha em uma das fases do tratamento. Quem indenizar o titular tem regresso contra os demais responsáveis, na medida da participação de cada um (art. 42, § 4º, da LGPD).
A 2ª turma do STJ, no AREsp 2.130.619/SP (relator ministro Francisco Falcão, j. 7/3/23), decidiu que o vazamento de dados pessoais não gera, por si só, dano moral indenizável, cabendo ao titular comprovar o dano, com ressalva para os dados sensíveis. Se os clientes da distribuidora forem consumidores, ela responde perante eles de forma objetiva (art. 14 da lei 8.078/1990, o CDC); entre ela e o prestador, vale o CC.
Ônus da prova e os registros que sobraram
No processo civil, quem alega o fato constitutivo do seu direito precisa prová-lo (art. 373, I, da lei 13.105/15, o CPC). A distribuidora que afirma que o acesso inicial usou a credencial do prestador precisa dos registros da ferramenta de acesso remoto e da VPN (a conexão remota à rede); o prestador que afirma ter avisado sobre o MFA precisa do chamado.
O § 1º do art. 373 do CPC permite ao juiz atribuir o ônus de modo diverso, por decisão fundamentada, quando uma das partes tem maior facilidade de obter a prova do fato contrário. Em disputas com prestador de TI esse dispositivo pesa, porque os registros costumam estar com ele: a ferramenta de acesso remoto é dele e o log da VPN fica em equipamento que ele configura. Se esses registros foram apagados ou sobrescritos na restauração, o prestador pode receber o encargo de demonstrar o que eles diriam. O mesmo vale para a distribuidora quanto ao que estava sob seu controle.
A ISO/IEC 27001:2022 (International Organization for Standardization, 2022) prevê no Anexo A a definição da segurança nos acordos com fornecedores (5.20) e o monitoramento dos serviços prestados (5.22). O contrato deveria prever que os registros de acesso remoto pertencem à cliente e lhe são entregues em caso de incidente. Sem isso, a prova depende da boa vontade de quem pode vir a ser o réu.
Antes de notificar o prestador, a distribuidora precisa ler o contrato e admitir quais portas ela mesma deixou abertas. A conta final vai sair desse inventário e dos registros que sobraram; o primeiro nome que apareceu no relatório forense é só o ponto de partida.
_____
AUTORIDADE NACIONAL DE PROTEÇÃO DE DADOS. Guia orientativo para definições dos agentes de tratamento de dados pessoais e do encarregado. Versão 2.0. Brasília, DF: ANPD, abr. 2022. Disponível em: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia-orientativo-para-definicoes-dos-agentes-de-tratamento-de-dados-pessoais-e-do-encarregado. Acesso em: 12 out. 2026.
BRASIL. lei 8.078, de 11 de setembro de 1990. Dispõe sobre a proteção do consumidor e dá outras providências. Brasília, DF: Presidência da República, 1990. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/l8078compilado.htm. Acesso em: 12 out. 2026.
BRASIL. lei 10.406, de 10 de janeiro de 2002. Institui o CC. Brasília, DF: Presidência da República, 2002. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/2002/l10406compilada.htm. Acesso em: 12 out. 2026.
BRASIL. lei 13.105, de 16 de março de 2015. Código de Processo Civil. Brasília, DF: Presidência da República, 2015. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13105.htm. Acesso em: 12 out. 2026.
BRASIL. lei 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais (LGPD). Brasília, DF: Presidência da República, 2018. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm. Acesso em: 12 out. 2026.
BRASIL. Superior Tribunal de Justiça (2. Seção). Súmula nº 479. Aprovada em 27 jun. 2012. DJe, 1 ago. 2012. Disponível em: https://arquivocidadao.stj.jus.br/index.php/sumula-479-2. Acesso em: 12 out. 2026.
BRASIL. Superior Tribunal de Justiça (2. Turma). Agravo em Recurso Especial nº 2.130.619/SP. Relator: Min. Francisco Falcão, 7 de março de 2023. DJe, 10 mar. 2023. Informativo de Jurisprudência, n. 766. Disponível em: https://processo.stj.jus.br/jurisprudencia/externo/informativo/?livre=@CNOT%3D019794. Acesso em: 12/10/2026.
BRASIL. Superior Tribunal de Justiça (3. Turma). Recurso Especial nº 2.147.374/SP. Relator: Min. Ricardo Villas Bôas Cueva, 3 de dezembro de 2024. DJEN, 6 dez. 2024. Informativo de Jurisprudência, n. 838. Disponível em: https://processo.stj.jus.br/jurisprudencia/externo/informativo/?livre=@CNOT%3D021293. Acesso em: 12/10/2026.
CENTER FOR INTERNET SECURITY. CIS Critical Security Controls: version 8.1. [S. l.]: CIS, 2024. Controles 6 (Access Control Management) e 15 (Service Provider Management). Disponível em: https://www.cisecurity.org/controls/access-control-management e https://www.cisecurity.org/controls/service-provider-management. Acesso em: 12 out. 2026.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 27001:2022: information security, cybersecurity and privacy protection: information security management systems: requirements. 3. ed. Geneva: ISO, 2022. Disponível em: https://www.iso.org/standard/27001. Acesso em: 12 out. 2026.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. The NIST Cybersecurity Framework (CSF) 2.0. Gaithersburg, MD: NIST, fev. 2024. (NIST CSWP 29). DOI: https://doi.org/10.6028/NIST.CSWP.29. Disponível em: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf. Acesso em: 12 out. 2026.