Em 2025, 56% das empresas sofreram ao menos um incidente de segurança causado por um fornecedor — um aumento de 48% em relação ao ano anterior, segundo o relatório “The State of Trust Report”, da Vanta. O número revela um problema estrutural importante: a superfície de ataque de uma organização não termina nos seus próprios sistemas. Ela se estende por toda a cadeia de parceiros, prestadores de serviço e fornecedores de tecnologia que, juntos, formam o ecossistema onde o negócio opera e, não necessariamente, está sob controle direto da empresa
O risco dessa exposição se traduz em prejuízo concreto. Que pode ser ainda mais alto quando o vetor é um fornecedor. Violações originadas na cadeia de suprimentos custaram, em média, R$ 8,98 milhões por incidente no Brasil. Esse valor é maior que a média geral de R$ 7,19 milhões por ocorrência, conforme o relatório “Cost of a Data Breach 2025”, da IBM. Além de ser a segunda maior causa de incidentes no país, o comprometimento de terceiros é também o mais caro. Acrescente a isso o fato de que, segundo a Vanta, 57% das empresas já rescindiram contratos com fornecedores por preocupações com segurança, e você vai entender por que esse tema chegou definitivamente à mesa da gestão de riscos cibernéticos.
O impacto do problema explica também por que a segurança em ecossistemas de tecnologia e cadeias de suprimentos digitais está entre os temas de interesse do CISSA, Centro de Competência Embrapii em Segurança Cibernética, operado pelo CESAR. A boa notícia é que existem caminhos práticos para gerenciar essa exposição de forma proporcional ao risco e integrada ao negócio, explicam Raissa Ramos, analista de segurança da informação, e Lorenna Agra, coordenadora de TI, ambas do CESAR, em entrevista à The Shift.
Um problema com várias camadas
A camada mais visível é a do fornecedor direto — aquele com quem a empresa assina contrato, compartilha dados e integra sistemas. Mas há uma segunda camada, menos mapeada e igualmente perigosa: os fornecedores dos fornecedores, chamados de quarta parte. O relatório de investigações de violações de dados da Verizon de 2025 mostrou que a participação de terceiros em incidentes dobrou em um ano. O ataque à SolarWinds, em 2020, virou caso de manual justamente porque o vetor de entrada não foi a empresa atacada, mas um fornecedor confiável cujo software de atualização foi comprometido — e o código malicioso chegou embutido numa atualização legítima, afetando milhares de organizações ao redor do mundo.
Do ponto de vista legal, as pesquisadoras lembram que o cenário brasileiro adiciona mais pressão. A LGPD estabelece responsabilidade compartilhada entre controlador e operador de dados, e o STJ tem consolidado o entendimento de que essa responsabilidade é objetiva: a empresa pode ser responsabilizada por um vazamento causado por um fornecedor mesmo sem comprovação de culpa própria. Isso muda o cálculo de risco — e transforma a gestão de fornecedores numa obrigação jurídica, não apenas numa boa prática de segurança. Confira a conversa inteira abaixo.
Dados de mercado mostram que 56% das empresas já sofreram incidentes de segurança por causa de fornecedores. Quais são os pontos de entrada mais comuns que vocês identificam nesse ecossistema?
Muitos desses incidentes ocorrem porque os times de segurança são excluídos completamente do processo de contratação. Algumas companhias não possuem um fluxo de compras integrado com a equipe de segurança e privacidade; outras, embora tenham essas equipes, não priorizam suas análises na hora de contratar. Se determinada ferramenta ou consultoria é considerada importante para o negócio, sua contratação pode ser aprovada sem passar pela análise técnica — ou mesmo com riscos identificados.
Além disso, outro vetor crescente é o shadow IT: quando áreas de negócio contratam fornecedores diretamente, sem passar pela TI ou pela área de segurança, criando integrações invisíveis e completamente fora de qualquer controle. Quando isso acontece, a organização perde a única oportunidade de estabelecer condições mínimas de segurança antes que o fornecedor tenha acesso aos seus sistemas e dados.
Outros pontos de entrada frequentes são: falha na gestão de acessos e credenciais do fornecedor, falha no acompanhamento contínuo de contratos e o aumento da superfície de ataque causado pela contratação indiscriminada de terceiros. Vale lembrar que muitos fornecedores críticos são micro, pequenas e médias empresas, com poucas ou nenhuma salvaguarda de segurança implementada — o que agrava significativamente o problema.
O que faz com que esses riscos se materializem mesmo quando existem contratos e políticas formais em vigor?
O risco não congela no tempo — ele permanece e evolui diariamente, enquanto os contratos e os questionários de segurança são estáticos. Raramente as organizações monitoram de forma ativa a postura de segurança do fornecedor após a contratação, ficando no escuro se novas vulnerabilidades surgem ou se o fornecedor acaba sendo comprometido.
A categorização de fornecedores por nível de criticidade e tipo de acesso é uma prática fundamental nesse contexto: fornecedores que acessam sistemas críticos ou processam dados sensíveis precisam passar por avaliação mais rigorosa. Sem essa distinção, a organização aplica o mesmo esforço para riscos completamente diferentes — ou, pior, aplica esforço mínimo para todos.
O melhor dos mundos é a adoção de uma ferramenta de gestão de riscos de terceiros, conhecida como TPRM, que monitore continuamente a segurança e utilize dados em tempo real para avaliar vulnerabilidades, incluindo bases de threat intelligence. Se um risco é identificado após a avaliação inicial, a ferramenta gera um alerta que pode desencadear novos planos de ação de acordo com a política de fornecedores da empresa. Monitoramento contínuo e baseado em inteligência é, portanto, essencial.
O relatório da Verizon de 2025 mostra que a participação de terceiros em violações dobrou em um ano. Como uma organização pode gerenciar riscos que estão além da sua relação direta de contrato?
A superfície de ataque de uma organização não termina no seu próprio perímetro — ela se estende até onde vão os parceiros comerciais e, em muitos casos, até onde vão também os parceiros desses parceiros. Isso é o que se chama de gestão de quarta parte, um problema complexo que pode parecer impossível de alcançar à primeira vista.
O ataque à SolarWinds em 2020 é o caso emblemático: os invasores não comprometeram diretamente as vítimas, mas penetraram no sistema de um fornecedor terceirizado que tinha acesso à infraestrutura dos alvos. A partir disso, distribuíram atualizações contendo código malicioso. As organizações afetadas nem sequer tinham relação direta com o código — ele chegou embutido numa atualização legítima de um fornecedor confiável.
Esse cenário mostra que o foco deve se deslocar da ilusão da prevenção absoluta para a resiliência: detecção rápida e capacidade de resposta. No eixo contratual, o caminho mais efetivo é fazer o risco fluir pela cadeia via cláusulas de flow-down, exigindo que o fornecedor direto aplique os mesmos padrões de segurança junto aos seus próprios subcontratados críticos. Não elimina o risco, mas cria responsabilidade contratual e rastreabilidade.
Existe um limite prático para até onde essa responsabilidade pode ir?
Além da quarta parte, existe ainda o conceito de quinta parte: os fornecedores dos fornecedores dos seus fornecedores. Tentar rastrear toda essa cadeia gera um custo que supera o risco mitigado para a maioria das organizações. A maturidade está em ser explícito sobre quais fornecedores entram no escopo de avaliação de quarta parte e aceitar o risco residual para o restante, documentando essa decisão.
O mais pragmático é mapear não cada fornecedor individualmente, mas os pontos de convergência da cadeia: se 80% dos seus fornecedores críticos usam o mesmo provedor de identidade ou plataforma de nuvem, esse componente compartilhado é o maior risco de quarta parte. Feeds de threat intelligence conseguem alertar quando um componente compartilhado está comprometido — que foi exatamente o que faltou nas organizações afetadas pela SolarWinds.
No fim, é preciso ser honesto sobre o que está fora do alcance de qualquer organização que não seja um regulador ou uma agência de inteligência. A empresa precisa ter a consciência tranquila de que fez sua parte — e estar preparada para responder com velocidade, evidência e capacidade de recuperação quando algo falhar.
A LGPD estabelece responsabilidade compartilhada entre controlador e operador, e o STJ tem consolidado que essa responsabilidade é objetiva. Quais são as falhas mais comuns que vocês identificam na relação entre empresas e fornecedores sob esse prisma?
A responsabilidade objetiva significa que a empresa pode ser responsabilizada por um vazamento causado por um fornecedor mesmo sem comprovação de culpa, dolo ou negligência próprios. Isso muda o cálculo: não basta mais demonstrar a própria segurança, é preciso demonstrar diligência sobre quem processa dados em seu nome.
As falhas mais comuns que observamos são: não ter nenhum processo documentado de entrada e gestão de fornecedores; ausência de um contrato com DPA — Data Processing Agreement — que defina como dados pessoais são compartilhados, processados e protegidos; a empresa não saber exatamente quais dados trafegam para o fornecedor, em qual volume e por qual canal; e não estabelecer obrigações de segurança para eventuais suboperadores do fornecedor contratado.
Dois erros frequentes e subestimados merecem destaque: SLAs de notificação de incidente incompatíveis com a LGPD — a ANPD tem sinalizado 72 horas como referência, mas muitos contratos ainda preveem cinco, dez ou trinta dias úteis, copiados de contratos genéricos de TI — e a falta de revisão contratual quando o escopo muda. O fornecedor começa processando apenas dados de cadastro e depois passa a integrar o CRM, acessar mais dados e alimentar modelos de IA, mas o contrato original nunca é aditado.
O que seria, então, um contrato realmente seguro com um fornecedor, para além do SLA padrão?
A missão do contrato robusto não é transferir o risco para o fornecedor, mas criar as condições para que o controlador possa responder com velocidade, evidência e eventual recuperação dos danos perante quem de fora falhou. Ao mesmo tempo, as empresas ainda podem se defender ao demonstrar que tomaram cuidados e salvaguardas razoáveis — e é nesse momento que ter um processo documentado de gestão de fornecedores e evidências de ferramentas de TPRM vêm muito a calhar.
Um contrato seguro precisa ir além do SLA técnico e incluir: cláusula de DPA com definição clara de papéis, finalidade e base legal do tratamento de dados; obrigação de notificação de incidente em prazo compatível com a LGPD; direito de auditoria ou exigência de certificações reconhecidas como ISO 27001 ou SOC 2; cláusulas de flow-down que estendam as obrigações de segurança aos suboperadores; e definição clara do que acontece com os dados ao término do contrato.
Por fim, é fundamental manter o registro das operações de tratamento de dados, conforme o artigo 37 da LGPD. Esse registro é uma das evidências mais objetivas de diligência que a empresa pode apresentar à ANPD em caso de fiscalização ou investigação. A área jurídica e a de segurança da informação precisam atuar juntas nessa construção — compartilhando a responsabilidade de controlador e garantindo que o contrato seja um instrumento vivo, revisado sempre que o escopo da relação mudar.
Compras quer velocidade, segurança quer controle. Como construir um fluxo integrado entre essas áreas em organizações com estruturas já estabelecidas?
A cibersegurança não pode ser tratada como um problema técnico — ela precisa ser parte da estratégia de negócios. E não é missão da área de segurança da informação sozinha conscientizar as outras áreas: esse direcionamento deve partir, em primeiro lugar, das lideranças da organização. Estudos indicam que cerca de 60% das pequenas e médias empresas que sofrem um incidente de segurança grave encerram suas atividades em até seis meses. Alguns riscos simplesmente não devem ser ignorados.
Não precisa existir uma guerra entre a equipe de compras e a equipe de segurança, mas sim cooperação: prazos claros e comunicados para cada tipo de contratação, e áreas que respeitam os processos da companhia com a compreensão de que essas diretrizes existem para manter funcionando o lugar onde trabalham. Se a equipe de compras opera pressionada para contratar o mais rápido possível, isso também é uma falha da alta gestão, que está priorizando velocidade em detrimento da continuidade do negócio.
Um modelo de governança que tem funcionado na prática é o comitê de aprovação de fornecedores, com representação das áreas de Segurança da Informação, Jurídico, Compras e da área solicitante. Cada contratação percorre uma trilha de aprovação proporcional ao risco: fornecedores de baixo impacto seguem um fluxo simplificado, enquanto fornecedores críticos passam por avaliação técnica e jurídica completa. Para organizações com estruturas já estabelecidas, a recomendação é começar de forma incremental, priorizando os fornecedores de maior criticidade, e expandir o processo gradualmente, à medida que ele ganha legitimidade interna.
Dados mostram que 43% das vulnerabilidades exploradas hoje envolvem APIs, e 99% são exploráveis remotamente. Como a gestão de fornecedores precisa evoluir para endereçar esse risco que está dentro do serviço contratado, mas fora do radar da segurança?
Ao contratar um fornecedor SaaS, a organização está, na prática, herdando toda a superfície de ataque das integrações e APIs desse fornecedor — um risco que raramente aparece em questionários de conformidade tradicionais. A maioria dos processos tradicionais de avaliação de fornecedores analisa apenas aspectos de conformidade legal, reputação e verificação documental, sem capacidade de avaliação técnica mais avançada.
A melhor prática é adotar uma ferramenta de TPRM com capacidade tecnológica para identificar e avaliar riscos em tempo real. Em vez de confiar apenas nas respostas que o fornecedor dá sobre sua própria segurança, essas ferramentas fazem escaneamento externo passivo da infraestrutura do fornecedor e geram um score baseado em evidências técnicas reais: exposição de serviços, certificados SSL vencidos, configurações de e-mail, portas abertas, vazamentos de credenciais em fontes abertas e dados expostos na surface e deep web — incluindo histórico de ataques ransomware.
Também é fundamental estruturar planos de resposta a incidentes testados e atualizados, de preferência com adoção de frameworks reconhecidos como a ISO 27001 e o NIST CSF 2.0, que oferecem bases sólidas para implantar políticas e controles eficazes. A equipe de segurança da empresa não pode ser uma entidade onisciente capaz de averiguar a fundo a postura de cada fornecedor contratado — mas pode construir um sistema que faça isso de forma automatizada e contínua.