Gestão de risco de terceiros (TPRM) na prática para a TI

Por que terceiros são um vetor de risco crescente

Terceiros são vetor de risco porque têm acesso a dados e sistemas, ampliam a superfície de ataque e um incidente deles vira incidente seu. Quando um atacante compromete um fornecedor de confiança, ele ganha um caminho já autorizado para o seu ambiente, contornando as defesas de perímetro^[2]. A parcela de brechas que envolve terceiros vem crescendo de forma consistente, segundo o relatório anual de investigação de brechas da Verizon (DBIR)^[3].

O acesso de confiança que o atacante herda

O risco não é abstrato: o terceiro já tem credenciais, integrações e acesso que a empresa concedeu voluntariamente. Casos de grande repercussão mostraram como um único fornecedor comprometido pode se propagar para milhares de clientes downstream^[2]. É o oposto de um ataque de fora para dentro — o atacante entra por uma relação legítima que a própria empresa estabeleceu.

A responsabilidade que não se terceiriza

Uma falha de conformidade ou vazamento no fornecedor pode gerar multa e dano reputacional para a sua empresa, mesmo que ela não seja diretamente responsável pela brecha^[1]. Clientes e reguladores cobram de quem contratou, não de quem falhou lá atrás na cadeia. Terceirizar a operação nunca terceiriza a responsabilidade pelo dado.

O problema brasileiro do "descobrir depois"

Muitas empresas só descobrem quem tem acesso aos seus dados depois que o incidente já ocorreu. Sem um inventário atualizado, a resposta a "quais fornecedores tocam nossos dados?" é uma reconstrução feita sob pressão, no meio da crise. É exatamente esse cenário que um programa de TPRM existe para evitar: saber a resposta antes, não durante o incidente.

Inventário de fornecedores e acessos: o ponto de partida

Sem inventário não há programa: o primeiro passo é saber quem são os fornecedores, o que acessam, que dados tocam e quem é o dono interno de cada relação. É a base sobre a qual toda a classificação, avaliação e reavaliação se apoiam. Um inventário incompleto compromete tudo o que vem depois, porque não se gerencia o risco de um fornecedor que não se sabe existir^[2].

O que registrar de cada fornecedor

Cada entrada do inventário precisa capturar, no mínimo: nome e entidade legal, serviço prestado, tipos de dado acessados (dados pessoais, financeiros, propriedade intelectual), datas de contrato, dono ou patrocinador interno e criticidade para a operação^[2]. É esse conjunto que permite depois classificar por risco e priorizar a avaliação — sem ele, todo fornecedor parece igual.

O shadow SaaS que ninguém cadastrou

Um dos maiores riscos é o fornecedor que uma área contratou por conta própria, sem passar pelo processo oficial. Esses "shadow SaaS" frequentemente representam o maior risco justamente porque nunca foram avaliados^[2]. Montar o inventário exige colaboração entre compras, TI, jurídico e as áreas de negócio, porque parte das contratações aconteceu fora do radar da TI.

O dono interno de cada relação

Todo fornecedor precisa de um dono interno — a pessoa ou área que patrocina a relação e responde por ela. É esse dono que acompanha a reavaliação, valida o encerramento de riscos e mantém a responsabilidade viva. Sem dono definido, o fornecedor entra no inventário e ninguém atualiza sua situação quando o escopo muda ou surge um alerta.

Questionário de segurança: o que perguntar

O questionário de segurança deve cobrir controles de acesso e MFA, criptografia, gestão de vulnerabilidades, plano de resposta a incidente, subprocessadores, localização dos dados, certificações e conformidade com a LGPD. O objetivo não é um formulário gigante que ninguém preenche direito, e sim um conjunto objetivo de perguntas calibrado pelo tier do fornecedor — mais profundo para quem acessa dados sensíveis, mais leve para quem não acessa^[2].

Controles técnicos: acesso, criptografia e vulnerabilidades

Comece pelos controles que mais reduzem risco na prática: autenticação multifator (MFA), controle de acesso baseado em papel, criptografia em repouso e em trânsito, e um processo de gestão de vulnerabilidades com correção em prazo definido. São perguntas verificáveis, com resposta objetiva, e cobrem os vetores mais explorados em brechas de terceiros.

Processo: resposta a incidente e subprocessadores

Pergunte se o fornecedor tem plano de resposta a incidente com prazo de notificação, e quem são seus subprocessadores — os terceiros que ele próprio usa. A resposta a incidente define quão rápido você saberá de um problema; o mapa de subprocessadores é a porta de entrada para o risco de nth-party, tratado adiante. Ambas são perguntas de processo, não de tecnologia.

Evidência: certificações e conformidade

Peça evidências que substituam a confiança pela verificação: certificações como ISO 27001 e relatórios SOC 2, além de comprovação de conformidade com a LGPD e da localização dos dados. Certificações reconhecidas dão uma linha de base auditada e reduzem o trabalho de avaliação — um fornecedor com ISO 27001 já demonstrou controles de segurança da informação verificados por terceiro.

Tiers de risco: classificar por criticidade

Classificar os fornecedores em tiers por criticidade do serviço e sensibilidade dos dados acessados é o que define a profundidade da avaliação e a cadência de reavaliação. Não faz sentido avaliar com o mesmo rigor o fornecedor que administra seu ERP e o que fornece material de escritório. O tiering direciona o esforço para onde o risco está^[2].

Como definir os tiers

O tier considera dois eixos: criticidade (o impacto no negócio se o fornecedor falhar) e exposição (que dados e sistemas ele acessa). Um modelo comum vai de Tier 1 — fornecedor que acessa dados pessoais ou sistema crítico — a um tier mais baixo, de fornecedor sem acesso a dado algum^[2]. Exemplos típicos de Tier 1 são provedores de nuvem, processadores de pagamento, o ERP e o provedor de segurança gerenciada.

O tier define profundidade e cadência

Quanto mais alto o tier, mais rigorosa a avaliação e mais frequente a reavaliação. Fornecedores críticos passam por avaliação abrangente, evidência de certificação e monitoramento contínuo; fornecedores de baixo risco recebem due diligence básica e revisão anual ou por gatilho^[2]. Essa proporcionalidade é o que torna o programa sustentável — concentra o esforço onde ele importa.

Avaliar fornecedores que usam IA

Fornecedores que usam IA exigem um conjunto de perguntas próprio, porque o risco de IA hoje empata com o risco cibernético como preocupação em programas de TPRM. As perguntas centrais são: os dados são usados para treinar modelos? Quais subprocessadores de IA existem? Onde os dados são processados? Como o fornecedor controla as saídas do modelo? À medida que os fornecedores adotam IA, os programas de TPRM evoluem para incluir critérios de governança de IA^[2].

Os dados alimentam o treino do modelo?

A pergunta mais importante é se os seus dados são usados para treinar os modelos do fornecedor. Se forem, informação sensível pode acabar incorporada a um modelo compartilhado com outros clientes ou exposta em saídas inesperadas. Exigir clareza contratual sobre uso de dados para treino é o controle mais direto — e muitas empresas nem sabem quais de seus fornecedores usam IA, o que torna essa pergunta ainda mais urgente^[2].

Subprocessadores de IA e local de processamento

Fornecedores de IA frequentemente dependem de outros provedores de modelo — subprocessadores que processam seus dados sem que você os tenha contratado diretamente. Pergunte quais são, onde processam os dados e sob qual jurisdição. Isso conecta a avaliação de IA ao risco de nth-party e à questão de localização de dados, que já faz parte do questionário de segurança.

Controle das saídas e transparência do modelo

Os riscos específicos de IA incluem viés nos modelos, falta de transparência de algoritmos "caixa-preta" e vazamento de dados por saídas do modelo^[2]. Avalie como o fornecedor controla o que o modelo produz, se há mecanismos contra vazamento em respostas e qual a transparência sobre fontes de dados e gestão de risco do modelo. Em porte maior, isso vira uma avaliação dedicada de risco de IA, com requisitos específicos.

Cláusulas contratuais de segurança e notificação

O contrato é onde o programa de TPRM ganha força exigível: as cláusulas centrais são direito de auditoria, notificação de incidente em prazo definido, requisitos mínimos de segurança, gestão de subprocessadores e exclusão ou portabilidade de dados ao fim da relação. Contratos devem ser estruturados para endereçar as principais preocupações de risco e conformidade, com cláusulas de confidencialidade, acordos de proteção de dados e SLAs^[1].

Direito de auditoria e requisitos mínimos

Garanta o direito de auditar o fornecedor e defina os requisitos mínimos de segurança que ele deve manter durante toda a relação. Sem direito de auditoria, a avaliação se limita ao que o fornecedor escolhe declarar; com ele, é possível verificar. Requisitos mínimos em contrato transformam boas práticas em obrigação — não ficam a critério do fornecedor.

Notificação de incidente em prazo definido

Estabeleça a obrigação de o fornecedor notificar qualquer incidente de segurança dentro de um prazo determinado. Esse prazo define quão rápido você poderá reagir a uma brecha que começou fora da sua empresa. Uma cláusula de notificação sem prazo é quase inútil — o valor está em saber cedo o suficiente para conter o impacto do seu lado.

Gestão de subprocessadores e saída de dados

Inclua a obrigação de o fornecedor gerenciar seus próprios terceiros e a cláusula de exclusão ou portabilidade de dados ao fim do contrato. A gestão de subprocessadores é o gancho contratual do risco de nth-party; a cláusula de saída de dados garante que, quando a relação terminar, seus dados sejam devolvidos ou destruídos de forma comprovada — não esquecidos em um ambiente que você não controla mais.

Reavaliação contínua e offboarding

TPRM não é "avaliou uma vez e esqueceu": a postura de segurança de um fornecedor muda com o tempo, então a reavaliação acontece por cadência e por gatilho. A cadência segue o tier — críticos com mais frequência, os demais anualmente. Os gatilhos incluem incidentes, mudança de escopo, fusões e novos requisitos regulatórios^[2]. O monitoramento contínuo substitui a foto anual por um acompanhamento sempre atualizado.

Cadência por tier e gatilhos de reavaliação

Fornecedores críticos são reavaliados com mais frequência; os de menor risco, anualmente ou quando algo muda. Além do calendário, defina gatilhos: uma brecha no fornecedor, mudança material no serviço ou nos dados acessados, aquisição do fornecedor por outra empresa, ou novo requisito regulatório disparam uma reavaliação fora do ciclo^[2]. É a combinação de rotina e reação que mantém o programa vivo.

Monitoramento contínuo em vez da foto anual

O monitoramento contínuo acompanha sinais de risco em tempo quase real — ratings de segurança, inteligência de ameaças, mudança de postura, saúde financeira — e gera alertas quando algo cruza um limite^[2]. Substitui a avaliação estática de uma vez por ano por uma vigilância que detecta a deterioração antes que ela vire incidente. Em porte maior, integra-se ao processo de resposta para transformar alerta em ação.

Offboarding: o passo mais esquecido

Encerrar a relação com segurança é o passo que mais se negligencia: revogar acessos, encerrar credenciais e integrações e confirmar a exclusão ou devolução dos dados. Ao terminar a relação, é preciso garantir que todos os dados e ativos sejam devolvidos ou destruídos com segurança, mantendo registro do processo para fins de conformidade^[1]. Um fornecedor "esquecido" com acesso ativo é uma porta que ficou aberta.

Nth-party risk: o fornecedor do seu fornecedor

Nth-party risk é o risco que vem dos fornecedores dos seus fornecedores — os subcontratados que você não contratou, mas cujo incidente chega até você. O risco se estende à quarta parte, e além: os subprocessadores engajados pelos seus terceiros^[1]. Rastrear essa cadeia é quase impossível sem ferramentas automatizadas, e é uma preocupação crescente à medida que as cadeias de fornecimento se alongam^[2].

Por que você herda o risco que não contratou

Quando o seu fornecedor depende de um subprocessador comprometido, o impacto propaga-se pela cadeia até chegar em você — mesmo sem relação contratual direta com o elo que falhou. A empresa que focou apenas na própria segurança e na do fornecedor direto continua exposta às vulnerabilidades de terceiros e quartos^[1]. O risco não respeita a fronteira do seu contrato.

Cobrir por contrato e mapear a cadeia

A primeira defesa é contratual: exigir que o fornecedor gerencie os próprios terceiros e mantenha seus subprocessadores sob controle de segurança. A segunda, viável em porte maior, é mapear e monitorar a cadeia além do primeiro nível. Pequenas empresas, na prática, miram o fornecedor direto e transferem a responsabilidade da cadeia por contrato; grandes usam ferramentas de monitoramento para enxergar além do primeiro elo.