Segurança em fornecedores e serviços terceirizados com requisitos contratuais

Por que fornecedores viram parte do seu perímetro de segurança

Quando uma empresa contrata um serviço terceirizado, ela não está apenas comprando uma entrega: está estendendo seu ambiente operacional para fora do próprio controle direto. Na prática, o fornecedor passa a manipular informações, operar sistemas, acessar ambientes, manter infraestrutura, desenvolver software, atender clientes ou executar processos críticos. Isso cria um ponto de exposição que pode ser tão relevante quanto um sistema interno.

“Segurança em fornecedores” é o conjunto de práticas para garantir que terceiros (fornecedores, parceiros, consultorias, BPO, SaaS, cloud, suporte, manutenção, desenvolvimento, logística, call center etc.) protejam adequadamente os ativos e dados que tocam, e que a relação contratual deixe claro o que é exigido, como será verificado e o que acontece quando algo dá errado.

O objetivo não é burocratizar compras, e sim reduzir risco operacional e jurídico com requisitos contratuais claros, verificáveis e proporcionais ao impacto. Um contrato bem escrito funciona como um “controle de segurança executável”: define obrigações, evidências, prazos, direitos de auditoria e consequências.

O que muda quando o serviço é terceirizado

Riscos típicos em terceiros

• Acesso excessivo: fornecedor recebe credenciais amplas “para facilitar” e isso vira porta de entrada.
• Ambiente compartilhado: dados do cliente em infraestrutura multi-tenant sem segregação adequada.
• Subcontratação invisível: o fornecedor repassa parte do serviço para outro sem controles equivalentes.
• Falhas de continuidade: indisponibilidade do fornecedor paralisa operação interna.
• Incidentes e vazamentos: demora para notificar, ausência de logs, dificuldade de investigação.
• Conformidade: tratamento de dados pessoais sem base legal, retenção indevida, transferência internacional não controlada.
• Dependência: dificuldade de trocar de fornecedor por falta de portabilidade e cláusulas de saída.

O contrato como mecanismo de controle

Controles técnicos e processos internos ajudam, mas não substituem a necessidade de amarrar obrigações do fornecedor. Sem contrato, você pode até “pedir” boas práticas; com contrato, você pode exigir, auditar e aplicar penalidades. O contrato também protege o fornecedor, pois deixa claro o que ele precisa entregar e quais limites existem (por exemplo, janelas de manutenção, responsabilidades de backup, níveis de serviço).

Classificando fornecedores para aplicar requisitos proporcionais

Nem todo fornecedor precisa do mesmo nível de exigência. A forma prática de evitar excesso é classificar o fornecedor por criticidade e exposição. Uma classificação simples e funcional pode usar dois eixos: (1) impacto no negócio se o serviço parar e (2) exposição de dados/ambientes.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Exemplo de critérios de criticidade

• Crítico: acesso a dados sensíveis (pessoais, financeiros, segredos industriais), acesso administrativo a sistemas, operação de processo essencial, ou indisponibilidade causa parada relevante.
• Importante: acessa dados internos não públicos ou integrações relevantes, mas com alternativas e impacto moderado.
• Baixo: sem acesso a dados sensíveis e sem impacto operacional relevante (ex.: fornecimento de material de escritório).

Essa classificação direciona o “pacote” de cláusulas e evidências. Para fornecedores críticos, você exige mais: auditoria, testes, métricas, notificação rápida, requisitos de continuidade e controles de subcontratação.

Requisitos contratuais: o que não pode faltar

A seguir estão blocos de requisitos contratuais que costumam ser aplicáveis. A ideia é montar um anexo de segurança (ou DPA/Anexo de Proteção de Dados, quando aplicável) com itens objetivos e verificáveis.

1) Escopo, dados e ativos envolvidos

• Descrição do serviço e dos sistemas envolvidos.
• Quais tipos de dados serão tratados (ex.: dados pessoais, dados financeiros, logs, dados de clientes).
• Onde os dados serão armazenados e processados (país/região, data centers, nuvem).
• Regras de segregação: ambientes dedicados vs. compartilhados, separação por cliente.

2) Obrigações de segurança mínimas

• Manter um programa de segurança compatível com o risco do serviço.
• Aplicar controles de proteção em trânsito e em repouso quando aplicável.
• Gestão de vulnerabilidades e correções com prazos acordados (por severidade/criticidade).
• Proteção contra malware e hardening em ativos sob responsabilidade do fornecedor.
• Registro e retenção de logs relevantes para auditoria e investigação.

Importante: evite cláusulas genéricas como “seguir as melhores práticas”. Prefira requisitos mensuráveis, por exemplo: “correções críticas em até X dias”, “retenção de logs por Y dias”, “criptografia com algoritmos aceitos pela organização”.

3) Controle de acesso e uso de credenciais

• Acesso apenas para pessoas autorizadas e somente ao necessário para executar o serviço.
• Proibição de contas compartilhadas; identificação individual.
• Requisitos de autenticação forte quando houver acesso remoto ou privilegiado.
• Processo para concessão, alteração e revogação de acessos (incluindo desligamentos).
• Regras para acesso de suporte: janelas, aprovação prévia, registro de atividades.

4) Subcontratados (cadeia de fornecimento)

• Obrigação de informar e obter aprovação para subcontratar atividades que envolvam dados/ambientes do cliente.
• Exigir que subcontratados cumpram requisitos equivalentes (flow-down).
• Responsabilidade do fornecedor principal por falhas do subcontratado.

5) Notificação e gestão de incidentes

• Prazos claros para notificação após detecção (ex.: “até 24h”).
• Canal de contato 24x7 para incidentes críticos.
• Obrigação de fornecer informações mínimas: escopo, dados afetados, linha do tempo, medidas de contenção, evidências disponíveis.
• Cooperação em investigação, preservação de evidências e suporte a comunicações regulatórias quando aplicável.

6) Continuidade e disponibilidade do serviço

• Metas de disponibilidade (SLA) e penalidades por descumprimento.
• RTO/RPO quando houver dependência de recuperação (para serviços críticos).
• Testes periódicos de recuperação e evidências de execução.
• Plano de contingência para falhas de infraestrutura, ataques e indisponibilidade de terceiros (ex.: provedor de nuvem do fornecedor).

7) Privacidade e proteção de dados (quando aplicável)

• Definição de papéis (controlador/operador) e instruções documentadas de tratamento.
• Finalidade do tratamento e proibição de uso para outros fins.
• Retenção e descarte seguro ao término do contrato.
• Transferência internacional: condições, regiões permitidas e garantias.
• Atendimento a solicitações de titulares (quando aplicável) e cooperação com auditorias.

8) Auditoria, evidências e direito de verificação

• Direito de auditoria (remota ou presencial) proporcional ao risco.
• Possibilidade de solicitar evidências: relatórios, testes, certificações, resultados de auditorias independentes.
• Periodicidade e formato de evidências (ex.: anual, semestral).
• Tratamento de achados: plano de ação, prazos, reavaliação.

9) Requisitos de desenvolvimento e mudanças (quando o fornecedor entrega software)

• Requisitos mínimos de segurança no ciclo de desenvolvimento (ex.: revisão de código, testes de segurança, correção de falhas).
• Gestão de mudanças com comunicação prévia e janelas de implantação.
• Compatibilidade e impacto: aviso de mudanças que afetem integrações, APIs, autenticação, criptografia.

10) Cláusulas de saída e portabilidade

• Devolução/portabilidade de dados em formato acordado.
• Prazos para entrega de exportações e suporte à migração.
• Descarte seguro e comprovação de eliminação quando aplicável.
• Continuidade temporária (transição) para evitar parada abrupta.

Passo a passo prático para implementar segurança em fornecedores com contratos

Passo 1: Mapear quais fornecedores “tocam” dados ou sistemas

Liste fornecedores e identifique rapidamente: (a) se acessam sistemas internos, (b) se processam dados do negócio, (c) se impactam operação crítica. Inclua serviços que às vezes passam despercebidos, como suporte de TI, manutenção remota, ferramentas de atendimento, marketing com base de leads, contabilidade com documentos sensíveis.

Passo 2: Classificar criticidade e definir o pacote de requisitos

Crie 3 pacotes (Crítico/Importante/Baixo) com exigências mínimas. Exemplo prático:

• Crítico: anexo de segurança completo + direito de auditoria + notificação de incidente em até 24h + requisitos de continuidade + controle de subcontratados.
• Importante: anexo de segurança enxuto + evidências anuais + notificação em até 48h.
• Baixo: cláusulas básicas de confidencialidade e proteção de informações, sem auditoria.

Passo 3: Fazer due diligence proporcional antes de contratar

Antes de assinar, peça evidências compatíveis com a criticidade. Em vez de questionários longos, use um conjunto curto de perguntas e documentos. Para um fornecedor crítico, exemplos de evidências úteis:

• Relatório de auditoria independente (quando existir) ou atestado de controles.
• Descrição de arquitetura de segurança (alto nível) e segregação de clientes.
• Política de gestão de incidentes e exemplo de comunicação (modelo).
• Resumo de continuidade (RTO/RPO) e evidência de teste recente.
• Lista de subcontratados relevantes e regiões de processamento.

Se o fornecedor não tiver maturidade para fornecer evidências, isso não significa “não contratar” automaticamente, mas exige compensações: reduzir escopo, limitar dados, exigir melhorias com prazos, ou escolher alternativa.

Passo 4: Negociar cláusulas com foco em verificabilidade

Transforme expectativas em itens verificáveis. Exemplos de redação objetiva (ajuste ao seu contexto jurídico):

Incidentes: o Fornecedor notificará o Cliente em até 24 horas após a detecção de incidente de segurança que possa afetar dados do Cliente, incluindo no mínimo: descrição, sistemas afetados, dados potencialmente impactados, medidas de contenção e ponto de contato.

Vulnerabilidades: o Fornecedor corrigirá vulnerabilidades classificadas como críticas em até 15 dias corridos e altas em até 30 dias corridos, contados da identificação, salvo exceção aprovada por escrito pelo Cliente.

Subcontratação: o Fornecedor não poderá subcontratar atividades que envolvam tratamento de dados do Cliente sem aprovação prévia por escrito, garantindo obrigações de segurança equivalentes às deste contrato.

Evite cláusulas que dependem de interpretação (“adequado”, “razoável”) sem critérios. Quando precisar usar termos amplos, complemente com anexos técnicos e SLAs.

Passo 5: Definir responsabilidades operacionais (RACI do contrato)

Mesmo sem repetir modelos de governança, é essencial que o contrato diga quem faz o quê no dia a dia. Exemplos:

• Quem aprova acessos do fornecedor e em quanto tempo.
• Quem mantém listas de usuários autorizados.
• Quem executa backups e quem testa restauração.
• Quem monitora disponibilidade e como abre chamados.
• Quem comunica incidentes e quem aprova comunicados externos.

Isso reduz “zonas cinzentas” que viram falhas em auditorias e incidentes.

Passo 6: Operacionalizar o contrato com checklists e evidências

Contrato assinado não garante execução. Crie uma rotina simples de acompanhamento:

• Onboarding: validar acessos, canais de suporte, contatos de incidente, regiões de processamento, subcontratados aprovados.
• Revisões periódicas: coletar evidências combinadas (SLA, relatórios, testes, mudanças relevantes).
• Gestão de exceções: registrar desvios (ex.: prazo de correção não cumprido) e aprovações formais.
• Reuniões de serviço: para críticos, revisar indicadores e riscos (mensal/trimestral).

Uma prática eficiente é manter um “dossiê do fornecedor” com: contrato e anexos, evidências recebidas, histórico de incidentes, SLAs, aprovações de subcontratados e decisões de exceção.

Passo 7: Monitorar mudanças do fornecedor que alteram risco

Fornecedores mudam: trocam data center, subcontratam, alteram arquitetura, mudam política de retenção, fazem aquisições. Inclua no contrato a obrigação de comunicar mudanças relevantes com antecedência e mantenha um gatilho interno para reavaliar criticidade quando:

• O escopo do serviço aumenta (mais dados, mais integrações).
• O fornecedor passa a acessar ambientes produtivos.
• Há mudança de região/país de processamento.
• O fornecedor troca subcontratados críticos.

Passo 8: Preparar o “plano de saída” desde o início

Para serviços críticos, trate saída como requisito de segurança. Defina:

• Formato de exportação (ex.: CSV/JSON/SQL dump), periodicidade e testes de exportação.
• Prazos de entrega após solicitação.
• Suporte de transição (horas incluídas, valores, janelas).
• Comprovação de descarte seguro após a migração.

Isso reduz risco de indisponibilidade e de retenção indevida de dados após o término.

Exemplos práticos de aplicação por tipo de fornecedor

SaaS que armazena dados de clientes

• Exigir: regiões de processamento, segregação de tenants, logs de acesso, notificação de incidentes, exportação de dados, retenção e descarte.
• Evidências: relatório independente quando disponível, descrição de controles de acesso, teste de recuperação, métricas de disponibilidade.

Empresa de suporte remoto com acesso administrativo

• Exigir: autenticação forte, acesso just-in-time quando possível, registro de sessões, proibição de contas compartilhadas, aprovação prévia para acessos fora de janela.
• Evidências: lista de técnicos autorizados, trilha de auditoria das sessões, procedimento de revogação imediata.

Desenvolvedora terceirizada

• Exigir: requisitos de segurança no desenvolvimento, correção de falhas com prazos, gestão de bibliotecas/dependências, entrega de evidências de testes de segurança acordados.
• Evidências: relatórios de testes, registro de correções, inventário de componentes relevantes quando aplicável.

Armadilhas comuns e como evitar

“Contrato padrão do fornecedor” sem anexos de segurança

Contratos padrão tendem a limitar responsabilidade e reduzir obrigações. Para serviços com dados ou acesso, trate o anexo de segurança como obrigatório e negocie pontos mínimos: notificação de incidentes, auditoria/evidências, subcontratação, continuidade e saída.

Exigir tudo de todos

Isso trava compras e gera “checklist de papel”. Use a classificação por criticidade para calibrar exigências e concentre esforço onde o risco é real.

Cláusulas sem mecanismo de verificação

Se você não consegue medir, vira promessa vaga. Sempre que possível, inclua: prazos, métricas, tipos de evidência, periodicidade e consequências.

Não prever cooperação em incidentes

Sem obrigação de cooperação, o fornecedor pode limitar informações por “política interna”. Deixe explícito o que será fornecido, em quanto tempo e como.

Ignorar subcontratados

Risco muitas vezes está no quarto elo da cadeia. Exija transparência e flow-down de requisitos, especialmente para hospedagem, suporte e processamento de dados.