Risco de terceiros no RGPD, na NIS2 e no DORA

O mesmo fornecedor pode criar obrigações de privacidade, de cibersegurança e de resiliência operacional. Um prestador de processamento salarial trata dados pessoais; um prestador de serviços geridos detém acessos privilegiados; uma plataforma cloud suporta aplicações críticas para o negócio. Por vezes, um único fornecedor faz as três coisas.

Um registo partilhado de fornecedores ajuda as equipas a coordenar a avaliação, desde que cada obrigação continue identificável. Para um CTO, o desafio prático é ligar os compromissos contratuais à realidade técnica: a que pode o fornecedor aceder, como se propagam as falhas, que controlos estão evidenciados e se a organização consegue recuperar ou sair.

Determinar a aplicabilidade antes de combinar avaliações

Estes instrumentos sobrepõem-se, mas não se aplicam da mesma forma a todas as organizações ou fornecedores.

O artigo 28.º do RGPD exige que os responsáveis pelo tratamento recorram a subcontratantes que apresentem garantias suficientes. Um acordo nos termos do artigo 28.º não é adequado só porque um fornecedor recebe dados: determine primeiro o papel efetivo no tratamento.

Os artigos 20.º a 23.º da NIS2 tratam da supervisão pelos órgãos de gestão, das medidas de gestão de riscos e da notificação de incidentes significativos. A NIS2 é uma diretiva aplicada através do direito nacional, pelo que o âmbito e os procedimentos exigem verificações específicas de cada jurisdição.

O DORA é aplicável desde 17 de janeiro de 2025. Abrange principalmente entidades financeiras especificadas; os fornecedores de TIC comuns podem estar sujeitos a requisitos contratuais dos clientes, enquanto os terceiros prestadores críticos de serviços de TIC designados têm um regime de superintendência separado. Para as entidades financeiras abrangidas, o DORA funciona como direito setorial específico da UE nas áreas relevantes da NIS2. Não duplique automaticamente os dois conjuntos de controlos.

Construir o registo em torno da dependência

Comece pelo serviço e não pelo questionário ao fornecedor. Um fornecedor pode prestar vários serviços com dados, acessos e importância operacional diferentes.

Como base prática, registe:

• O serviço, a entidade jurídica do fornecedor, o responsável de negócio, o responsável técnico e os revisores.
• As funções, sistemas, integrações e acessos privilegiados suportados.
• As categorias de dados pessoais, as finalidades do tratamento, as localizações e os subcontratantes ulteriores.
• Os requisitos de disponibilidade, os objetivos de recuperação e a perturbação tolerável.
• Os fornecedores subjacentes, as dependências contratuais e as alternativas realistas.
• As obrigações aplicáveis, as datas das evidências, as lacunas por resolver e as decisões.

Identifique que funções falhariam ou se degradariam após um comprometimento ou uma interrupção. Um fornecedor que armazena poucos dados sensíveis pode, ainda assim, controlar a autenticação ou os pipelines de implementação. Inversamente, um serviço com baixo risco de disponibilidade pode expor dados pessoais altamente sensíveis.

Mantenha estas dimensões separadas, em vez de as reduzir a uma única pontuação de «risco elevado» sem explicação. Para as entidades financeiras abrangidas pelo DORA, ligue este inventário operacional ao registo de informações obrigatório sobre os acordos contratuais de TIC; uma lista genérica de fornecedores não é necessariamente suficiente.

Reutilizar evidências sem reutilizar cegamente conclusões

Um relatório de segurança, um mapa de fluxos de dados ou um teste de recuperação podem apoiar várias revisões. Verifique o âmbito do serviço, o período de reporte, as exclusões, as exceções e as responsabilidades do cliente antes de confiar nele.

Por exemplo, um relatório que abrange a infraestrutura do fornecedor não abrange necessariamente o acesso do seu pessoal de suporte aos registos dos clientes. Uma política de cópias de segurança documentada não mostra que a restauração cumpre os requisitos de recuperação da sua aplicação.

Mantenha uma matriz que relacione evidências e perguntas:

Um certificado ISO ou um relatório SOC 2 apoiam a garantia dentro do respetivo âmbito; nenhum deles demonstra a conformidade com o RGPD ou com a NIS2. Preserve o raciocínio do revisor e não apenas o documento carregado. Avaliar a garantia de segurança deve ser uma revisão técnica repetível e não a verificação de um selo.

Traduzir os requisitos em contratos e controlos

Nos termos do artigo 28.º do RGPD, as cláusulas do subcontratante têm de abordar o objeto, a duração, a natureza e a finalidade do tratamento, o tipo de dados e as categorias de titulares. Abrangem também as instruções documentadas, a confidencialidade, a segurança, as condições de subcontratação ulterior, a assistência, o apagamento ou a devolução, e as obrigações de informação e auditoria. As transferências internacionais exigem uma avaliação separada ao abrigo do capítulo V; o alojamento na UE, por si só, não resolve as questões de acesso ou de transferências ulteriores.

O artigo 21.º da NIS2 inclui a segurança da cadeia de abastecimento e a consideração das vulnerabilidades e das práticas de cibersegurança dos fornecedores diretos. As expectativas contratuais práticas podem incluir restrições de acesso, tratamento de vulnerabilidades, cooperação em incidentes e disponibilização de evidências. Adapte-as ao serviço e aos requisitos nacionais, em vez de tratar um pacote universal de cláusulas como juridicamente suficiente.

O artigo 30.º do DORA especifica as disposições contratuais relativas às TIC, com requisitos adicionais para os serviços que suportam funções críticas ou importantes. Reveja as descrições dos serviços, as localizações, a proteção e a recuperação dos dados, a assistência, a cessação e os direitos de supervisão relevantes. Essas funções críticas ou importantes exigem especial atenção aos níveis de serviço, ao reporte, às medidas de contingência, à cooperação em testes, aos direitos de auditoria e às disposições de transição.

Depois, verifique a implementação. Se um contrato promete acesso administrativo restrito, obtenha evidência da separação de funções, da autenticação, da aprovação e do registo de eventos. Se promete o apagamento, determine o que acontece às cópias de segurança e aos registos conservados. Atribua as lacunas jurídicas e as lacunas técnicas aos revisores adequados.

Conceber as passagens de testemunho em incidentes antes de um incidente

A política de resposta a incidentes de um fornecedor pode apoiar uma avaliação de segurança e deixar por resolver os deveres de notificação. Especifique os canais de contacto, a cobertura da escalada, a informação inicial, as expectativas de atualização e a responsabilidade pela preservação de evidências.

Nos termos dos artigos 33.º e 34.º do RGPD, o subcontratante notifica o responsável pelo tratamento sem demora injustificada. O responsável pelo tratamento avalia a notificação à autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas após ter tido conhecimento, a menos que a violação não seja suscetível de resultar num risco para os direitos e liberdades das pessoas. Um elevado risco pode exigir a comunicação às pessoas, sem prejuízo das exceções. Registe o raciocínio quando a notificação não for exigida.

As fases de notificação da NIS2 a nível da UE para incidentes significativos incluem um alerta precoce em 24 horas, uma notificação em 72 horas e, em regra, um relatório final no prazo de um mês após a notificação; verifique as regras nacionais e setoriais. O DORA tem o seu próprio quadro de notificação para incidentes graves relacionados com as TIC. Não substitua estas avaliações por um único indicador de «violação» do fornecedor.

Como recomendação prática, faça um exercício de incidente de um fornecedor com informação incompleta. Teste se as equipas conseguem determinar os serviços afetados, a exposição, o impacto operacional e as decisões de notificação sem esperar por um relatório final sobre a causa raiz.

Exemplo prático: um serviço, três percursos de revisão

Suponha, a título ilustrativo, que uma entidade financeira abrangida utiliza uma plataforma alojada de apoio a clientes que trata dados pessoais e suporta uma função que classificou como crítica ou importante ao abrigo do DORA.

O fornecedor apresenta um relatório de garantia, uma política de incidentes e um resumo de testes de recuperação. A segurança constata que os controlos de acesso administrativo estão evidenciados, mas que o teste de recuperação exclui a integração do cliente.

A privacidade identifica separadamente um processo pouco claro de alteração de subcontratantes ulteriores e disposições por resolver sobre transferências decorrentes do acesso remoto. A revisão ao abrigo do DORA conclui que a assistência na transição e as disposições de auditoria relevantes precisam de atenção.

O plano de ação resultante é concreto:

• O responsável técnico testa a recuperação da integração e documenta o resultado.
• O revisor de privacidade resolve as questões dos subcontratantes ulteriores e das transferências.
• O departamento jurídico e as compras tratam das lacunas contratuais.
• O responsável decide se a utilização temporária é aceitável, com condições e uma data de revisão.

As evidências são reutilizadas, mas nenhuma das três conclusões é deduzida de outra. Uma revisão de segurança aprovada não encerra as lacunas de privacidade ou de resiliência.

Monitorizar alterações, concentração e uma saída exequível

Defina a frequência das revisões de acordo com a dependência e o risco. Desencadeie revisões adicionais após incidentes, alterações importantes ao serviço, novos subcontratantes ulteriores, alterações da localização dos dados, mudanças de propriedade ou renovações de contratos.

Olhe para além dos nomes dos fornecedores: vários serviços podem depender da mesma região cloud, do mesmo fornecedor de identidades ou do mesmo subcontratante. Avalie a perturbação correlacionada e se a alternativa proposta partilha essa dependência. O artigo 29.º do DORA trata explicitamente da avaliação do risco de concentração no domínio das TIC.

Mantenha um plano de saída proporcionado que abranja a exportação de dados, a migração, a continuidade, a revogação de acessos e a evidência de apagamento. Teste a usabilidade da exportação e identifique quem consegue operar a solução de substituição. Um direito de rescisão é mais útil quando a organização o consegue exercer.

As consequências também diferem. O RGPD tem escalões de coimas específicos consoante a infração; a NIS2 exige regimes sancionatórios nacionais com limites máximos diferentes para entidades essenciais e importantes. As sanções do DORA para as entidades financeiras dependem dos regimes aplicáveis, ao passo que as sanções da superintendência dos prestadores críticos são distintas. Não modele a exposição com base numa suposta coima universal.

Começar com uma dependência com consequências

Escolha um fornecedor que suporte uma função importante. Concilie o seu inventário de serviços, os contratos, as evidências, os riscos em aberto e os pressupostos de saída. Termine com responsáveis designados e conclusões separadas e datadas para cada obrigação aplicável.

Na Secani, as equipas podem modelar o serviço e o fornecedor externo, ligar requisitos e controlos às evidências e acompanhar as lacunas como tarefas com responsáveis. As decisões revistas por pessoas, as ligações às fontes, os comentários e os registos temporais preservam o raciocínio. Isto apoia um contexto partilhado sobre os fornecedores sem ocultar os juízos distintos de privacidade, segurança e resiliência.