Incidente com múltiplos fornecedores: quem lidera a resposta

São 2h47 da manhã e o e-commerce está fora do ar. A operadora informa que o link está limpo e que o problema deve ser da aplicação. O provedor de SOC responde que os endpoints monitorados estão íntegros e que não há alerta aberto. O integrador de nuvem confirma que os serviços estão saudáveis no painel dele.

Todos os três estão dizendo a verdade. E o site continua fora do ar.

Esse é o formato mais comum de um incidente com múltiplos fornecedores hoje. E a parte cara dele não é a técnica: é o tempo que se perde descobrindo que ninguém tem autoridade sobre a soma. Cada contrato foi escrito para descrever um pedaço, e o ataque não leu nenhum dos três.

A tese em uma frase: a fragmentação que atrasa a resposta não é de ferramenta, é de contrato — plataforma unificada resolve correlação de telemetria e não cria obrigação nenhuma entre empresas diferentes, então a visão única que falta não se compra, se escreve antes.

O tamanho real do problema com múltiplos fornecedores

Dois números delimitam a conversa, e é importante saber de onde cada um vem.

O primeiro é do DBIR 2026 da Verizon: terceiros estiveram envolvidos em 48% das violações, uma alta de 60% em relação ao ano anterior. A série assusta mais do que o valor absoluto — eram 15% dois relatórios atrás e 30% no de 2025. O incidente com múltiplos fornecedores deixou de ser exceção e virou o caso comum.

O segundo descreve o ambiente em que essa resposta acontece. Um estudo do IBM Institute for Business Value com a Palo Alto Networks (janeiro/2025) mediu uma média de 83 soluções de segurança de 29 fornecedores por organização. E 52% dos executivos disseram que a fragmentação limita a capacidade de lidar com ameaças.

Aqui cabe a leitura honesta, a mesma que faço com qualquer número de fornecedor: esse estudo é copatrocinado por uma empresa que vende plataforma unificada. O diagnóstico é sólido. A conclusão que ele empurra — consolide tudo com um fornecedor só — é interessada. Guarde o número e desconfie da receita.

Por que uma plataforma só não resolve múltiplos fornecedores

A resposta reflexa para fragmentação é comprar integração. É uma resposta parcialmente certa, e vale entender exatamente onde ela para.

Uma plataforma de XDR faz um trabalho que ninguém faz na mão: normaliza telemetria de origens diferentes, correlaciona e monta uma história só. Se o problema é "tenho quatro consoles e nenhuma linha do tempo", isso resolve.

Só que às 2h47 o problema quase nunca é esse. É este:

• A operadora pode bloquear o prefixo de origem, mas o pedido precisa vir do contato cadastrado, e o contato cadastrado saiu da empresa em março.
• O provedor de SOC vê o endpoint comprometido e não tem permissão para desabilitar a conta, porque a identidade está na nuvem, que é do outro contrato.
• O integrador de nuvem tem a permissão, mas atende em horário comercial, salvo severidade crítica — e quem classifica a severidade é ele.

Nenhum desses três impedimentos é técnico. Todos são contratuais. E é por isso que a fragmentação entre múltiplos fornecedores não se resolve com compra: ferramenta cria visão, contrato cria obrigação. Quem tem só a primeira consegue descrever o próprio incidente com uma clareza excelente enquanto ele acontece.

O relógio é seu, mesmo quando a falha é do fornecedor

Esta é a assimetria que mais surpreende quem nunca passou por um incidente de terceiro.

A Resolução CD/ANPD nº 15/2024 coloca a comunicação sob responsabilidade do controlador, com prazo de três dias úteis contados da ciência. Se o dado é seu, o prazo é seu — mesmo que a falha, a apuração e a evidência estejam todas dentro da empresa de outra pessoa. Os detalhes dessa régua e a comparação com a NIS2 estão em notificação de incidente.

A consequência prática é direta: um fornecedor que leva cinco dias para confirmar o que aconteceu não perdeu o prazo dele — queimou o seu. E há um incentivo perverso escondido aí. Como o prazo conta da ciência, quanto mais tarde ele avisa, mais tarde começa o seu relógio. Ótimo para o relatório dele, péssimo para a sua exposição.

Por isso a cláusula de prazo não pode ser "notificar em tempo hábil". Tem que ser em horas, com contagem a partir da detecção dele, e não da confirmação — que é a parte que ele controla.

As cláusulas que faltam no seu contrato

Nenhuma das cinco é exótica, e é justamente por isso que a ausência delas é constrangedora. Levei anos vendo contratos de tecnologia que descrevem em detalhe o que o fornecedor entrega em dia normal, e nada sobre o dia ruim.

A quarta é a que quase nunca está escrita e a que mais muda o dia. Sem ela, pedir que o fornecedor A entre numa call com o fornecedor B é favor. E favor depende de disposição, de relação pessoal e de quem está de plantão. Com a cláusula, é entrega contratada, com prazo.

Na hora de escolher, MDR, XDR, SIEM ou SOC gerenciado tem as perguntas de compra. E como comparar propostas de fornecedores ajuda a não comprar o folheto.

Quem manda na sala

O plano de resposta a incidentes já define os papéis internos. O que muda num incidente com múltiplos fornecedores é que três desses papéis estão em empresas diferentes, com contratos diferentes, e nenhum responde ao outro.

Duas regras resolvem a maior parte da confusão.

A primeira: o comandante do incidente é sempre da sua empresa. Não é o fornecedor mais técnico, nem o que está mais envolvido, nem o que mais fala na call. É quem pode decidir tirar um sistema do ar, autorizar gasto emergencial e acionar o jurídico. Fornecedor lidera o próprio escopo — é o que o contrato dele paga, e é razoável que seja assim. Ninguém que fatura por um pedaço vai assumir a conta do todo.

A segunda: uma sala só, com log de decisão. Três grupos de WhatsApp, uma ponte de conferência e uma thread de e-mail garantem duas coisas: a mesma pergunta feita quatro vezes e a resposta boa perdida. O formato que funciona é uma sala, com registro do que foi decidido, por quem e a que horas. É o que o NIST SP 800-61r3 trata como parte da coordenação. E é o que você vai precisar reconstituir depois para a autoridade, para o seguro ou para o cliente.

Uma opinião que já custei a aprender: a call de incidente com fornecedores tende a virar reunião de defesa de escopo, e isso não é má-fé — é o comportamento esperado de quem será cobrado pelo próprio SLA. Cabe ao comandante cortar isso na primeira ocorrência, deixando claro que a apuração de responsabilidade fica para depois e que o assunto da sala é conter.

O teste que ninguém faz

Tudo isso é barato de escrever e inútil se ninguém experimentou.

O exercício de mesa que o plano de resposta já recomenda muda de natureza quando os fornecedores estão na sala. Não precisa ser sofisticado: duas horas, um cenário só, com os três contratos representados.

O objetivo não é avaliar o técnico de ninguém. É descobrir, num dia calmo, o contato que não existe mais, o log que não está na retenção contratada, o critério de severidade que cada um usa e a autorização que depende de alguém de férias.

Faça uma pergunta específica no fim: quem teria acionado quem, e em quanto tempo? A resposta costuma ser silêncio, e o silêncio é o entregável.

Se a sua operação tem OT ou fornecedores de manutenção com acesso remoto, esse exercício vale dobrado — é onde o acesso de terceiro costuma ser mais amplo e menos revisado.

O ponto que fica

A indústria vende consolidação como resposta à fragmentação, e consolidar às vezes é mesmo a decisão certa. Mas é uma decisão cara, lenta e que troca fronteiras por dependência — e a maior parte do ganho está disponível sem ela.

O que resolve um incidente com múltiplos fornecedores é bem mais chato do que uma plataforma nova: um dono declarado, uma obrigação de cooperação escrita, prazos contados a partir da detecção e um ensaio por ano. Nada disso aparece em quadrante de analista, e tudo isso decide quanto tempo você fica no escuro.

A pergunta de verificação, para fazer hoje e não às 2h47: se o ataque atravessar os três contratos ao mesmo tempo, quem liga para quem, e quem tem o direito contratual de exigir uma resposta em minutos?