Quando terceiros causam incidentes: como responder, investigar e documentar

Quando um incidente de terceiro é seu incidente: critérios de escalonamento

Nem todo problema em um fornecedor é igualmente relevante para sua organização. Um incidente operacional no servidor web de um SaaS de gestão de ponto é diferente de uma falha de confidencialidade em um processador de dados pessoais. O primeiro passo é classificar.

Você escala quando:

• O terceiro processa, armazena ou tem acesso a dados pessoais (sua responsabilidade conforme LGPD, art. 37);
• O terceiro suporta serviços críticos para seu negócio (cobrança, atendimento ao cliente, operações);
• Há indício de acesso não autorizado, roubo de dados ou destruição de informações;
• O terceiro é regulado (instituição financeira, operadora de telecomunicações) e o incidente afeta conformidade regulatória;
• Há exposição reputacional ou impacto ao cliente final (vazamento de dados, indisponibilidade de serviço).

Você monitora, mas não escala crítico quando:

• O incidente é operacional, contido e sem risco direto (falha de e-mail interno do fornecedor, downtime previsível);
• O terceiro é low-risk, periférico (fornecedor de material de escritório, consultoria sem acesso a sistemas);
• Há transparência e comunicação proativa do fornecedor.

Uma matriz de risco de fornecedores, atualizada em onboarding e monitoramento contínuo, facilita essa decisão em segundos. Se o fornecedor está mapeado em risco alto ou crítico, escale imediatamente.

Primeiras 24 horas: checklist de ações imediatas

O tempo inicial é crítico. Não para tomar decisões perfeitas, mas para conter danos e preservar evidências.

Hora 0 a 2:

1. Confirme a notificação. Verifique a fonte (é realmente do fornecedor? há comunicação oficial?). Phishing e rumores acontecem.
2. Reúna o time. Riscos, jurídico, segurança da informação, operações (quem depende do terceiro) e privacidade/compliance.
3. Congelar comunicações internas desnecessárias. Evite e-mails para "todos", redes sociais ou comentários públicos enquanto não há clareza.
4. Documente o incidente. Hora, nome do terceiro, descrição inicial, quem reportou, impacto conhecido (nenhum dado ainda, só fatos).

Hora 2 a 8:

1. Solicite informações formais ao fornecedor. Envie um e-mail ou abra um ticket solicitando: o que aconteceu, quando foi descoberto, quantas pessoas/dados foram afetados (se aplicável), que medidas foram tomadas para conter, cronograma de investigação, ponto de contato responsável.
2. Avalie o escopo interno. Quais sistemas, dados e pessoas da sua organização estão afetados? Se o terceiro processava nomes e e-mails de clientes, há 50 mil pessoas potencialmente envolvidas? Se processava dados financeiros, há risco de fraude?
3. Acione o seguro. Se há cobertura (cyber, E&O), notifique a seguradora conforme a apólice (geralmente há prazos).
4. Documente em trilha de auditoria. Use sua plataforma de TPRM ou sistema de ocorrências para criar um registro estruturado.

Hora 8 a 24:

1. Reúna-se novamente. Compartilhe o que o fornecedor reportou. Há inconsistências? O tempo de descoberta foi longo? O incidente afeta você diferente do que foi reportado?
2. Decida se há notificação ao regulador ou cliente. Isso depende de lei (LGPD exige notificação em 48 horas para incidentes graves), tipo de dado e setor. Jurídico lidera aqui.
3. Prepare comunicado ao cliente (se necessário). Coordene com marketing/comunicação, jurídico e privacidade. Transparência reduz danos reputacionais.
4. Defina responsáveis pelas próximas fases. Quem conduzirá a investigação? Quem será interface com o fornecedor? Quem documentará tudo?

Investigação proporcional ao risco: perguntas essenciais ao fornecedor

Não investigue como se fosse uma auditoria forense completa (a menos que o incidente seja grave). Investigue proporcionalmente ao risco real.

Incidentes de risco baixo a médio (p.ex., acesso não autorizado contido, erro de configuração já corrigido):

• Qual foi a causa raiz?
• Quando foi descoberto e como?
• Qual foi a ação imediata de contenção?
• Há evidências de exfiltração ou malware?
• Qual é o plano para evitar reincidência?

Incidentes de risco alto a crítico (p.ex., roubo de dados de cliente, exposição prolongada):

• Cronograma completo: data de início, descoberta e notificação (por que demorou?).
• Dados específicos: quais tipos de informação, quantas pessoas, quais períodos?
• Acesso: como o invasor entrou? Credenciais roubadas, vulnerabilidade, insider?
• Escopo: apenas suas informações ou clientes do fornecedor também foram afetados?
• Evidências forenses: logs, registros de acesso, análise de malware (se aplicável).
• Ações tomadas: notificação a reguladores, reset de credenciais, patches de segurança.
• Certificados e auditorias: quando foi o último teste de penetração, auditoria SOC 2, certificação ISO 27001?

Dica importante: Peça ao fornecedor que envie documentação por escrito. Conversas e reuniões geram compromissos vagos. Evidências escritas (relatório de incidente, logs, cronograma) servem para compliance, auditoria interna e possíveis investigações regulatórias.

Documentação para compliance: o que LGPD, BCB e CGU esperam

Cada regulador e lei tem um ângulo.

LGPD (Lei Geral de Proteção de Dados) — Agência Nacional de Proteção de Dados:

Conforme o artigo 33, a notificação de incidente ao regulador (ANPD) é exigida quando há "violação dos direitos dos titulares" (roubo, vazamento de dados pessoais). Você deve documentar:

• Descrição do incidente e dados afetados.
• Medidas de segurança que existiam e falharam.
• Como foi descoberto.
• Impacto estimado.
• Medidas de contenção e remediação.
• Comunicação ao titular (aviso publicado, e-mail individual).

Se o terceiro é um processador (prestador contratado para tratar dados sob sua orientação), você continua responsável. Sua documentação deve deixar claro o papel do terceiro, o contrato que o vinculava e como o incidente foi comunicado.

Banco Central do Brasil — Instituições Financeiras:

Se você é uma instituição financeira ou prestador de serviço do setor, o BCB espera que você reporte incidentes de cibersegurança via circular ou resolução específica (a mais recente é a Resolução BCB nº 212/2024 sobre gestão de riscos). Documente:

• Classificação de severidade (conforme critérios do BCB).
• Impacto operacional e financeiro.
• Ações implementadas.
• Plano de ação para evitar reincidência.

CGU — Controladoria-Geral da União:

Se você é uma empresa pública, órgão federal ou contratada do governo, a CGU espera que incidentes de segurança da informação entrem em sua política de gestão de riscos. Documente para integridade pública:

• Constatações (o que aconteceu).
• Causas (por que falhou).
• Efeitos (qual foi o impacto).
• Ações corretivas e prazos.

Padrão universal: sempre documente

Independente do regulador, mantenha um registro único e estruturado do incidente em sua plataforma de TPRM ou sistema de auditoria:

• Identificação clara: data, fornecedor, tipo de incidente.
• Cronograma: descoberta, notificação interna, investigação, encerramento.
• Causa raiz e análise de impacto.
• Ações de contenção (o que foi feito imediatamente).
• Plano de ação corretiva (o que será feito para evitar).
• Evidências anexadas (relatório do fornecedor, logs, comunicados, respostas regulatórias).
• Status e data de encerramento.

Essa trilha de auditoria protege você em auditorias posteriores, investigações internas e defensabilidade regulatória.

Remediação, planos de ação e aceitação de risco

Investigação termina quando você entende o que aconteceu. Remediação é o que vem depois.

Remediar significa:

1. Conter a ameaça ativa (se ainda existir). Exemplo: se houve acesso não autorizado, forçar reset de senhas, revogar tokens, desligar conta comprometida.

1. Corrigir a causa raiz. Se foi falta de criptografia, implementar. Se foi configuração incorreta, reconfigurar. Se foi falta de monitoramento, adicionar alerta.

1. Validar a correção. Pedir ao fornecedor evidências de que a ação foi concluída (print de screen, certificado, relatório de teste).

Planos de ação (PA):

Para cada achado que não foi resolvido imediatamente, crie um plano de ação. Um bom PA tem:

• O quê: descrição clara do que será feito.
• Por quê: por que essa ação reduz risco ou cumpre requisito.
• Quem: responsável no fornecedor (ou em você, se a ação for sua).
• Quando: data-alvo de conclusão (ser realista).
• Como validar: como você confirmará que foi feito.

Exemplo: *"Terceiro implementará autenticação multifator para acesso administrativo até 15/02/2025. Validação: screenshot de teste de login com 2FA ativo, enviado por responsável de segurança do fornecedor."*

Aceitar risco:

Nem sempre você resolve tudo. Às vezes, o custo ou tempo são incompatíveis com o benefício. Nesse caso, formalize a aceitação de risco em documento:

• Qual é o risco que você está aceitando.
• Por quanto tempo (até quando essa aceitação vale).
• Sob quais condições (p.ex., monitoramento extra, limite de dados).
• Quem aprovou (gerente, diretor, comitê de risco).

Isso documenta sua decisão consciente e evita surpresas no futuro ("Por que não fizemos nada?").

Prevenção: aprendizados que reduzem reincidências

Um incidente bem documentado e encerrado é oportunidade para fortalecer seu programa de TPRM.

Revisão pós-incidente:

1. O terceiro foi descoberto cedo ou tarde? Se tarde, por que? Há monitoramento contínuo? Você deveria ter alertas de notícia, verificação de domínio, inteligência de ameaças?

1. O contrato cobria essa situação? Havia cláusula sobre notificação de incidente, direito de auditoria, penalidades? Se não, adicione no próximo contrato.

1. Esse terceiro deveria estar em um nível de risco mais alto? Se o incidente foi significativo, a classificação de risco estava incorreta. Revise o perfil.

1. Outros fornecedores similares têm exposição parecida? Se um SaaS de gestão de ponto sofreu roubo de dados, seus outros SaaS críticos têm proteção equivalente? Faça due diligence adicional.

1. Há padrão? Se é o terceiro incidente do mesmo tipo, sua organização está aprendendo ou repetindo?

Ações preventivas de TPRM:

• Onboarding robusto: novos fornecedores passam por questionário de segurança, verificação de certificados, análise de contrato.
• Monitoramento contínuo: notícias, monitoramento de dark web, verificação de reputação periódica.
• Contratos vivos: revise anualmente com fornecedores críticos para reforçar cláusulas de segurança, notificação de incidente, direito de auditoria.
• Treinamento: equipe de riscos, jurídico e segurança entendem o processo de resposta e suas responsabilidades.
• Simulados: anualmente, rode um cenário de incidente fictício para treinar o time.

Documentar e aprender de um incidente diferencia organizações maduras em TPRM daquelas que apenas reagem.

---

Referências:

• Agência Nacional de Proteção de Dados (ANPD): https://www.gov.br/anpd/pt-br — Lei Geral de Proteção de Dados e notificação de incidentes.
• Banco Central do Brasil: https://www.bcb.gov.br/estabilidadefinanceira — Normas sobre cibersegurança e gestão de riscos para instituições financeiras.
• Controladoria-Geral da União (CGU): https://www.gov.br/cgu/pt-br — Orientações sobre integridade, transparência e gestão de riscos em órgãos públicos.
• CISA (Cybersecurity and Infrastructure Security Agency): https://www.cisa.gov/resources-tools/groups/ict-supply-chain-risk-management-task-force — Referências internacionais de supply chain risk management.