Terceirizar TI não terceiriza a responsabilidade quando o dado vaza
Enquanto contratos de tecnologia tratam segurança como cláusula genérica, a ANPD já deixou claro quem paga a conta quando o incidente acontece.

Uma parcela significativa das empresas brasileiras opera com pelo menos um fornecedor externo de tecnologia. Integradores, consultorias, provedores de nuvem, fábricas de software. O modelo faz sentido econômico e, na maioria das vezes, entrega resultado. O problema aparece quando um incidente de segurança nasce justamente no ambiente do fornecedor e a empresa contratante descobre, no pior momento possível, que o contrato assinado não define com clareza quem responde pelo quê. Com a LGPD em plena vigência e a ANPD intensificando sua atuação fiscalizatória, essa zona cinzenta deixou de ser um risco hipotético e virou uma bomba com prazo de validade.
O erro mais comum que vejo em contratos de serviço de TI é tratar segurança da informação como um parágrafo genérico no meio de dezenas de páginas. Algo como “o fornecedor se compromete a adotar as melhores práticas de segurança”, sem especificar quais práticas, quais padrões, quais métricas e, principalmente, o que acontece quando essas práticas falham. No mundo real, isso significa que quando um banco de dados gerenciado por um terceiro sofre um vazamento, a empresa contratante fica exposta regulatoriamente, reputacionalmente e financeiramente, enquanto o fornecedor aponta para aquela cláusula vaga e diz que cumpriu sua parte. A LGPD é clara ao definir que o controlador dos dados responde perante o titular, independentemente de quem operava o sistema no momento do incidente. Terceirizar a operação nunca significou terceirizar a responsabilidade legal.
O cenário brasileiro tem uma particularidade que agrava o problema. Muitas empresas de médio porte, especialmente fora do eixo das grandes capitais, dependem de fornecedores regionais que são excelentes em entrega funcional, mas ainda não amadureceram seus processos de segurança. Não é uma crítica a esses fornecedores, é um retrato do mercado. O ponto é que a empresa contratante precisa assumir um papel ativo na governança de segurança da cadeia, em vez de presumir que o parceiro tem tudo sob controle. Isso inclui exigir evidências periódicas de conformidade, definir SLAs específicos para resposta a incidentes e estabelecer em contrato o direito de auditar controles de segurança. Cada uma dessas medidas ajuda, mas nenhuma basta sozinha. Segurança na cadeia de fornecedores é construída em camadas, e a primeira camada é o contrato.
Já abordei aqui no Café com Bytes sobre a importância de o CISO traduzir risco técnico em linguagem de negócio. Esse tema se conecta diretamente. A revisão dos contratos de TI com olhar de segurança não é tarefa exclusiva do jurídico nem do time técnico. Precisa envolver quem entende o apetite de risco da empresa, quem conhece os fluxos de dados sensíveis e quem tem autoridade para dizer “esse fornecedor não atende nosso padrão mínimo”. Na prática, isso significa que o CISO, ou quem faz esse papel, precisa ter assento na mesa quando contratos de tecnologia são negociados. Não depois, não para dar um parecer protocolar, mas durante a definição de escopo e responsabilidades.
Um exercício simples que recomendo para qualquer gestor que leia este artigo: pegue o contrato do seu principal fornecedor de TI e procure respostas claras para três perguntas. Quem notifica a ANPD e os titulares em caso de vazamento? Em quanto tempo o fornecedor é obrigado a comunicar um incidente à sua empresa? E quais evidências de segurança ele entrega periodicamente sem que você precise pedir? Se as respostas não estiverem explícitas no documento, você tem um risco de negócio disfarçado de contrato de prestação de serviço. A boa notícia é que corrigir isso não exige investimento em tecnologia. Exige vontade de sentar com o fornecedor e reescrever as regras do jogo antes que a ANPD ou um incidente façam isso por você.
Você sabe hoje, com clareza, onde termina a responsabilidade do seu fornecedor de TI e onde começa a sua? Agradeço por acompanhar mais um artigo do Café com Bytes. Se esse tema fizer sentido para alguém da sua rede, compartilhe e deixe seu comentário.



