Tempo de leitura: 11 min · Atualizado em 03/09/2026
Manter senhas e acessos administrativos depois do fim do contrato é falha grave do prestador de TI, mas também expõe a empresa contratante: ela responde por eventual uso indevido dos sistemas e dos dados pessoais que trata. A solução passa por notificação formal exigindo comprovação de revogação de acessos, auditoria técnica imediata e, no próximo contrato, cláusulas claras de desligamento.
Por que um prestador de TI com acesso residual é um problema sério
É comum que empresas terceirizem a administração de servidores, sistemas de gestão, e-mails corporativos, backups e infraestrutura em nuvem para prestadores externos. Durante a vigência do contrato, é natural que esse prestador tenha senhas de administrador, chaves de acesso e permissões elevadas — afinal, é assim que ele presta o serviço. O problema começa quando o contrato termina e ninguém revoga formalmente esses acessos.
Na prática, isso significa que uma pessoa ou empresa que não tem mais nenhum vínculo contratual continua com a chave da casa. Ela pode entrar nos sistemas, visualizar dados sensíveis, alterar configurações, exportar informações ou até paralisar operações — tudo isso sem que ninguém perceba, porque tecnicamente o acesso “existe” e não dispara nenhum alerta de invasão. Não é um caso de hacker externo. É uma porta que ficou destrancada por descuido de gestão contratual.
Esse tipo de situação tem paralelo com o que ocorre quando um ex-sócio muda as senhas das redes sociais e e-mails da empresa para reter controle sobre ativos digitais: em ambos os casos, o problema real não é técnico, é a ausência de um procedimento formal de desligamento que devolva o controle à empresa.
O risco jurídico não é hipotético
Muitos empresários pensam nesse cenário como um incômodo administrativo — “vou pedir para trocarem a senha quando der”. Mas o risco é concreto e tem pelo menos três frentes.
A primeira é a possibilidade de dano direto: um prestador insatisfeito, ou um ex-funcionário dele que ainda guarda as credenciais, pode acessar o sistema e causar prejuízo deliberado — apagar arquivos, sequestrar dados, desviar informações comerciais. Situações assim já geraram disputas semelhantes às que vemos quando um ex-funcionário apaga arquivos e e-mails importantes antes de sair da empresa: o acesso que deveria ter sido cortado se torna a arma do dano.
A segunda frente é a vulnerabilidade a ataques. Credenciais antigas, não revogadas, viradas contra a empresa, são justamente o tipo de brecha explorada em incidentes de segurança mais amplos — o mesmo tipo de exposição que discutimos quando tratamos de uma empresa que sofreu um ataque de ransomware e precisa reconstruir, às pressas, o controle sobre seus próprios sistemas.
A terceira frente, e talvez a mais subestimada, é a responsabilidade da própria empresa contratante perante seus clientes e usuários, caso esse acesso indevido resulte em vazamento ou uso irregular de dados pessoais de terceiros.
A empresa contratante responde, mesmo que o problema seja do fornecedor
Um erro comum é pensar que, se o vazamento ou o incidente partiu do prestador de TI, a responsabilidade é só dele. Não é assim que funciona quando dados pessoais estão envolvidos. A empresa que coleta e usa os dados de clientes, fornecedores ou funcionários é quem decide como e para que esses dados são tratados — e por isso tem o dever de garantir que apenas pessoas autorizadas tenham acesso a eles, inclusive depois de encerrar contratos com terceiros que antes tinham essa permissão.
Isso significa que, diante de um incidente causado por um acesso que já deveria ter sido revogado, a empresa contratante dificilmente conseguirá se eximir alegando que “a culpa foi do prestador”. Os órgãos de fiscalização e a própria lógica da proteção de dados pessoais partem do princípio de que cabe a quem trata os dados manter o controle sobre quem pode acessá-los — durante e depois de qualquer relação contratual. A situação se assemelha ao que ocorre quando uma empresa vaza dados pessoais e precisa responder pelas consequências, mesmo quando o vazamento foi provocado por uma falha de terceiro contratado.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
Além disso, há um ponto contratual relevante: se o prestador se recusa a devolver credenciais, revogar acessos ou repassar informações técnicas necessárias para a transição, isso pode configurar descumprimento contratual — tema semelhante ao que se discute quando um fornecedor de software se recusa a entregar o código-fonte após o fim do contrato. Em ambos os casos, o prestador retém algo que deveria ter sido transferido ou eliminado ao término da prestação de serviço, e isso gera direito de exigência formal e, se necessário, judicial.
O que fazer imediatamente quando o contrato já terminou
Se a empresa já está nessa situação — contrato encerrado, prestador fora, mas sem certeza de que os acessos foram efetivamente revogados —, o caminho recomendado segue uma ordem prática.
O primeiro passo é levantar, com a equipe interna de TI ou com um novo prestador, um inventário completo de todos os sistemas, plataformas, servidores, e-mails corporativos, ferramentas de nuvem e redes sociais que estavam sob gestão do prestador anterior. Sem esse mapeamento, é impossível saber por onde começar a revogação.
O segundo passo é trocar imediatamente todas as senhas de administrador, chaves de API, tokens de acesso e credenciais de sistemas críticos, independentemente de haver ou não suspeita concreta de uso indevido. Trocar por precaução é sempre mais barato do que remediar um incidente.
O terceiro passo é enviar uma notificação formal ao prestador — de preferência por meio que comprove o recebimento, como carta com aviso de recebimento ou e-mail com confirmação de leitura — exigindo, por escrito, a comprovação de que todos os acessos foram revogados de seu lado e que nenhuma cópia de dados ou sistemas permanece sob sua guarda. Esse documento tem valor tanto preventivo (formaliza o corte de vínculo) quanto probatório, caso um incidente futuro precise ser apurado.
O quarto passo, quando o volume de sistemas ou a sensibilidade dos dados envolvidos justificar, é contratar uma auditoria técnica independente para confirmar que não restam portas de acesso abertas — inclusive integrações automatizadas, backups em nuvem paralelos ou contas de serviço que nem sempre aparecem numa checagem superficial.
Como evitar que isso se repita no próximo contrato
A forma mais eficiente de lidar com esse risco é não deixar que ele se instale desde o início da relação contratual. Isso passa por incluir, em todo contrato de TI, cláusulas específicas de desligamento — o que no mercado costuma ser chamado de procedimento de offboarding.
Essas cláusulas devem prever, entre outros pontos: prazo máximo para revogação de todos os acessos após o encerramento do contrato; obrigação do prestador de apresentar comprovação formal dessa revogação; devolução ou destruição certificada de cópias de dados e backups que estejam em posse do prestador; e penalidades específicas caso o prestador mantenha qualquer acesso não autorizado após o prazo combinado.
Também vale a pena adotar, já durante a execução do contrato, uma política de acessos individualizados e temporários — em vez de uma senha mestra compartilhada, cada técnico do prestador deveria ter login próprio, com permissões limitadas ao necessário e passíveis de revogação isolada. Isso facilita enormemente o processo de desligamento e reduz a dependência de boa vontade do fornecedor na hora de encerrar o vínculo.
Empresas que já tratam dados pessoais de forma mais estruturada tendem a exigir, ainda na contratação, que o prestador assine um termo específico de tratamento de dados, deixando claro que o acesso é temporário, vinculado à vigência do contrato, e que qualquer uso posterior é considerado acesso não autorizado — o que fortalece a posição da empresa caso precise agir judicialmente no futuro.
Perguntas frequentes
O prestador pode alegar que manteve o acesso “só para garantir suporte”?
Não é uma justificativa válida. Se o contrato terminou, qualquer acesso deve ser expressamente autorizado por um novo acordo, ainda que temporário. Manter credenciais ativas sem autorização vigente é, no mínimo, uma falha grave de conduta profissional, e pode configurar acesso indevido a sistema de informação, independentemente da intenção alegada.
A empresa pode ser responsabilizada mesmo sem saber que os acessos não tinham sido revogados?
Sim. O desconhecimento não afasta a responsabilidade quando o dever de controlar o acesso aos próprios sistemas e aos dados pessoais tratados era da própria empresa. Por isso a revogação de acessos deve ser tratada como etapa obrigatória de todo encerramento de contrato, e não como um detalhe operacional que “alguém vai lembrar de fazer”.
É preciso provar que houve uso indevido para agir contra o prestador?
Não necessariamente. A simples manutenção de acesso não autorizado após o fim do contrato já é, em si, uma irregularidade que autoriza notificação formal e cobrança de providências. Se houver uso efetivo e comprovado, com dano decorrente, isso reforça a possibilidade de buscar reparação, mas a exigência de regularização não depende de prova de dano prévio.
Trocar as senhas já resolve o problema por completo?
É o passo mais urgente, mas raramente é suficiente sozinho. É preciso também verificar contas de serviço, integrações automatizadas, acessos remotos configurados em roteadores ou firewalls, backups paralelos e qualquer credencial que o prestador possa ter cadastrado em nome próprio dentro dos sistemas da empresa.
Vale a pena formalizar tudo por escrito mesmo em relações de confiança com o prestador?
Sim, principalmente nessas relações. A formalização não é sinal de desconfiança, é proteção mútua: ela documenta que o encerramento foi feito de forma correta, protege o prestador de suspeitas futuras e protege a empresa caso algo dê errado depois. Sem esse registro, é a palavra de um contra a palavra do outro se surgir qualquer problema.
É possível pedir indenização se o prestador se recusar a comprovar a revogação dos acessos?
Se a recusa causar prejuízo comprovado — como um incidente de segurança, vazamento de dados ou paralisação de sistemas — a empresa pode buscar reparação pelos danos sofridos, além de exigir judicialmente a regularização imediata dos acessos, inclusive por meio de medida de urgência quando o risco for iminente.
Fontes e legislação relacionada: Lei Geral de Proteção de Dados Pessoais (Lei nº 13.709/2018); Marco Civil da Internet (Lei nº 12.965/2014); Código Civil (Lei nº 10.406/2002), disposições sobre responsabilidade civil contratual e extracontratual.
Artigos relacionados
- Marketplace liberou o pagamento ao vendedor mesmo após eu denunciar o golpe: pode responder pelo prejuízo?
- Fornecedor de software recusa entregar o código-fonte após o fim do contrato: a empresa tem direito a receber?
- Por que a 99 bloqueia motoristas após denúncia de passageiro ou muitas corridas canceladas, e como reverter isso?
- Vazamento de código-fonte de software por ex-desenvolvedor contratado como PJ sem contrato formal: quais as vias legais?
Veja também nosso conteúdo completo sobre direito digital.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
