A segurança da sua organização é tão forte quanto o seu fornecedor mais fraco. Pode parecer um lugar-comum, até que controlos de acesso deficientes de um fornecedor interrompam as operações ou um regulador pergunte por que motivo não foi validada a resiliência dos parceiros críticos.

Regulamentos como a NIS2 e o DORA transformaram a governação de fornecedores num tema ao nível da administração, não porque os reguladores apreciem burocracia, mas porque os incidentes na cadeia de fornecimento se tornaram demasiado frequentes e danosos para serem tratados como um problema de terceiros. Este artigo apresenta um modelo prático e direto para ir além dos questionários básicos a fornecedores. Explica onde começa efetivamente grande parte do risco de terceiros, como identificar concentrações antes de causarem impacto e por que razão o planeamento de saída não é opcional.

O risco começa antes do contrato

Uma parte significativa do risco de terceiros é aceite quando compras, jurídico e segurança não participam na mesma discussão. São celebrados demasiados contratos em que a segurança intervém apenas para validar formalmente o acordo depois de as condições comerciais estarem fechadas. O resultado são contratos com direitos de auditoria fracos, linguagem vaga sobre notificação de incidentes e ausência de responsabilidade operacional clara.

A melhor governação de fornecedores começa com as normas que a organização está disposta a fazer cumprir durante a negociação, e não depois. Uma regra simples: se um fornecedor crítico recusar uma cláusula de direito de auditoria, isso constitui uma decisão de risco que exige um responsável e uma aceitação documentada, e não uma reação indiferente.

Considere-se uma empresa industrial que celebrou um contrato plurianual com um novo fornecedor de ERP na cloud sem incorporar requisitos de segurança no SLA. Quando a relação enfrentou dificuldades, o fornecedor recusou-se a partilhar relatórios de auditoria críticos. A remediação teve um custo de seis dígitos e demorou meses. A conclusão não foi que o fornecedor era difícil, mas sim que nada no contrato o obrigava a cooperar.

As cláusulas de direito de auditoria, os prazos de notificação de incidentes, as obrigações de tratamento de dados e as condições de saída não são extras jurídicos. São controlos de segurança redigidos em linguagem comercial. Se não constarem do contrato, não existem.

A realidade da NIS2: a organização responde pela falha do fornecedor

Ao abrigo da NIS2, se um fornecedor crítico for comprometido e o seu serviço ficar indisponível, o regulador responsabilizará a sua organização, e não apenas o fornecedor. A diretiva é explícita: as entidades essenciais e importantes devem gerir os riscos de segurança colocados pelos seus fornecedores e prestadores de serviços.

Não se trata de uma expectativa geral de boa conduta. É uma obrigação de conformidade com consequências de supervisão e sanção.

Numa empresa de energia, presumia-se que o prestador de manutenção SCADA era seguro. Uma avaliação de lacunas revelou que utilizava credenciais administrativas partilhadas e sem correções em vários clientes. O problema foi resolvido antes de resultar numa notificação de violação. Este é o nível de validação ativa que os reguladores esperam atualmente. Perguntar «estão em conformidade?» não é suficiente. É necessário analisar evidências e continuar a fazê-lo regularmente.

No mínimo, a maioria das organizações deve aplicar aos fornecedores críticos:

  • Um questionário anual de segurança validado com evidências, e não apenas por autoavaliação
  • Uma cláusula de direito de auditoria que seja efetivamente utilizada
  • Obrigações de notificação de incidentes com prazos definidos
  • Evidências dos seus próprios testes e da sua capacidade de resiliência

Para os fornecedores de maior criticidade, esta base é apenas o ponto de partida.

O que um bom registo de terceiros deve realmente revelar

Listar fornecedores é apenas o início. O verdadeiro valor está no que o registo permite identificar.

Para um cliente bancário, uma simples lista de fornecedores não era suficiente. O registo foi enriquecido e revelou que 40% do processamento de pagamentos críticos dependia de uma única região de cloud em Frankfurt. Essa visibilidade permitiu conceber uma estratégia de failover multirregional antes que uma indisponibilidade regional afetasse os clientes. O registo não indicou a solução, mas tornou impossível ignorar a exposição.

Um registo maduro de terceiros mostra:

  • Risco de concentração: quantos serviços críticos dependem de um único fornecedor ou de uma única geografia
  • Opções de saída fracas: relações das quais não existe uma forma prática de sair
  • Dependências frágeis: fornecedores que constituem um ponto único de falha para um processo crítico de negócio
  • Lacunas na qualidade contratual: situações em que as proteções contratuais não correspondem à criticidade da relação

O DORA exige que as entidades financeiras mantenham um registo de informação sobre todos os acordos contratuais com prestadores terceiros de serviços TIC. O regulamento especifica o conteúdo desse registo. Mesmo fora dos serviços financeiros, o princípio mantém-se: se o registo não ajudar a identificar o risco, é apenas uma folha de cálculo com etapas adicionais.

A responsabilidade partilhada não é uma cláusula de exclusão

Demasiadas organizações migram para AWS, Azure ou Google Cloud e assumem que o fornecedor trata de tudo. O modelo de responsabilidade partilhada é preciso. A AWS protege a cloud; a organização é responsável pelo que nela coloca: dados, configuração, acessos, monitorização e cópias de segurança.

Um cliente sofreu uma fuga de dados porque assumia que o fornecedor SaaS fazia cópias de segurança dos dados de configuração. Os termos e condições indicavam explicitamente que essa responsabilidade cabia ao cliente. Ninguém os tinha lido com atenção. As suposições transformaram-se em exposição.

Um modelo claro de governação da cloud elimina essa ambiguidade. Deve documentar-se quem é responsável pelos registos, pela recuperação, pela gestão de acessos e pela resposta a incidentes. Em seguida, o modelo deve ser testado, porque uma suposição não documentada e uma suposição documentada mas nunca testada são igualmente perigosas num incidente real.

O planeamento de saída faz parte da resiliência

Uma dependência não está verdadeiramente gerida se não existir uma forma credível de sair. Isto aplica-se a fornecedores de cloud, serviços geridos, plataformas de software e consultoras especializadas.

Durante um projeto de preparação para o DORA numa seguradora, foi colocada uma pergunta simples ao fornecedor do sistema central de administração de apólices: «Se entrarem em insolvência amanhã, como recuperamos os nossos dados em 48 horas?». O fornecedor não dispunha de um processo automatizado de exportação. Teriam sido necessárias semanas, possivelmente mais, para recuperar os dados num formato utilizável. Foi imposto um depósito mensal de dados em custódia como condição de renovação do contrato.

Se os contratos com fornecedores críticos não incluírem uma cláusula de saída com passos práticos — formato dos dados, prazo, parte responsável e custo —, a organização não é resiliente. Está dependente e apenas descobrirá até que ponto quando já for demasiado tarde para negociar.

O planeamento de saída não significa esperar que as relações falhem. Significa manter a capacidade de agir quando isso acontecer.

A integração de fornecedores transforma as normas em realidade

Uma política de fornecedores só é útil se o processo de integração a fizer cumprir. Muitas organizações possuem políticas fortes no papel e controlos de entrada fracos na prática. O momento em que um novo fornecedor necessita de acesso é frequentemente aquele em que as normas desaparecem silenciosamente sob pressão comercial.

Numa empresa financeira, foi concebido um fluxo de integração em que nenhum fornecedor podia ser criado no sistema de gestão de identidades antes da revisão do relatório SOC 2 Tipo II, da verificação e registo dos contactos de incidente na ferramenta GRC e da confirmação das obrigações de classificação de dados. No primeiro mês, o processo impediu o acesso à rede por três fornecedores de elevado risco.

Controlos práticos sobre a atribuição de acessos, a confirmação do tratamento de dados, a revisão de evidências e o registo de contactos de incidente transformam uma boa política num controlo real. Sem esses controlos, a integração é apenas uma mensagem de boas-vindas.

A proliferação de SaaS é um problema de GRC, não apenas de inventário de TI

Os departamentos de marketing subscrevem ferramentas com cartões empresariais sem que ninguém as avalie em termos de segurança. Ao longo do tempo, o número de plataformas não governadas aumenta, tal como a exposição.

Já foram observadas listas de clientes carregadas para treinar modelos públicos de aprendizagem automática porque ninguém verificou os termos de utilização do fornecedor. A equipa de marketing não tinha consciência, a equipa de TI não tinha visibilidade e a equipa de GRC não tinha sido informada. Os dados já eram públicos quando o problema foi detetado.

A proliferação de SaaS cria deriva de acessos, propriedade de dados pouco clara, condições contratuais não revistas e exposição oculta a fornecedores. É um tema de GRC porque os riscos são de governação — responsabilidade, tratamento de dados, supervisão de terceiros e resposta a incidentes — e não apenas técnicos.

Se o ambiente SaaS cresce mais rapidamente do que a capacidade de supervisão, o ponto de partida é um exercício de descoberta. Não é possível governar aquilo cuja existência se desconhece.

Conclusão e próximos passos

O risco de terceiros deixou de ser uma tarefa administrativa de conformidade. Está no centro da resiliência operacional e constitui, ao abrigo da NIS2 e do DORA, uma obrigação jurídica direta para um vasto conjunto de organizações europeias.

Ao integrar a segurança nas compras antes da assinatura dos contratos, aplicar controlos rigorosos de integração, manter um registo que revele riscos de concentração e saída e supervisionar o ambiente de cloud e SaaS, a cadeia de fornecimento deixa de ser uma vulnerabilidade e passa a ser um ecossistema gerido e resiliente.

Próximo passo: descarregue gratuitamente a Lista de verificação para auditoria de contratos de fornecedores segundo a NIS2 e o DORA. Não existe barreira de registo por correio eletrónico: o download é direto e o documento foi concebido para ser utilizado.

Para analisar primeiro o seu modelo atual de risco de terceiros, contacte a GRCForce para uma breve conversa de diagnóstico.