Certificados de eliminação de PII para conformidade na saída de subcontratantes

Maria, CISO numa fintech europeia em crescimento, olhava para uma breve mensagem de correio eletrónico da DataLeap, o fornecedor SaaS de analítica de marketing que a sua empresa acabara de cessar.

“Confirmamos que todos os dados associados à sua conta foram eliminados dos nossos sistemas de produção.”

A mensagem era cortês, rápida e quase inútil.

Durante três anos, a DataLeap tratou identificadores de clientes, dados de interação com campanhas, atributos de pontuação de leads, metadados de consentimento e dados de análise comportamental de milhares de clientes da UE. A FinSecure preparava-se para uma auditoria DORA, o Encarregado da Proteção de Dados revia evidências de responsabilidade demonstrável ao abrigo do RGPD da UE, e a equipa de compras queria encerrar o registo do fornecedor antes do ciclo de faturação seguinte. A mensagem respondia apenas a uma pergunta muito limitada: dados de produção. Nada dizia sobre cópias de segurança, logs, tickets de suporte, espaços de trabalho de análise, caches de subcontratantes subsequentes, cópias de teste, credenciais de API ou relatórios arquivados.

Maria fez a pergunta que todos os CISO, EPD e responsáveis de conformidade acabam por enfrentar durante a desvinculação de um SaaS:

Onde está o certificado de eliminação?

Essa pergunta transforma uma cessação contratual comum num evento de conformidade. Ao abrigo do RGPD da UE, os responsáveis pelo tratamento devem conseguir demonstrar o cumprimento de princípios como a limitação da conservação, a integridade, a confidencialidade e a responsabilidade demonstrável. Ao abrigo de DORA, as entidades financeiras devem gerir o risco de terceiros de TIC ao longo de todo o ciclo de vida da relação, incluindo a cessação e estratégias de saída que evitem interrupções, incumprimento regulamentar e danos para os clientes. Ao abrigo da ISO/IEC 27701:2025, as organizações precisam de evidência PIMS baseada em funções para atividades de tratamento de PII como responsável pelo tratamento, subcontratante, subcontratante subsequente e subcontratante em cloud. Ao abrigo da ISO/IEC 27001:2022, as dependências de fornecedores, serviços externos, controlos operacionais e evidências retidas devem ser geridos dentro do Sistema de Gestão de Segurança da Informação.

A lacuna raramente é descoberta durante a integração. Surge na saída. O contrato diz que os dados serão eliminados, mas não define a evidência. O fornecedor cloud consegue exportar um CSV, mas não consegue explicar o tratamento de cópias de segurança. A equipa de compras consegue cessar o fornecedor, mas a conformidade não consegue provar o destino final. A TI consegue desativar contas, mas desativar acessos não é eliminação. O jurídico consegue enviar uma notificação de cessação, mas os auditores querem uma cadeia de evidências.

A Clarysec trata a saída de subcontratantes como uma cadeia de controlos auditável, não como uma formalidade administrativa.

Porque é que a saída de subcontratantes se tornou um ponto crítico de conformidade

O fim de uma relação de serviço SaaS, processamento salarial, RH, finanças, CRM, alojamento cloud, analítica de marketing ou serviço gerido de TIC é um dos momentos de maior risco no ciclo de vida dos dados pessoais. Durante a operação normal, pelo menos a organização sabe que sistema está em produção, quem é o seu proprietário e que contrato se aplica. Na cessação, a propriedade fragmenta-se rapidamente. A equipa de compras encerra o registo do fornecedor. A TI desativa utilizadores. O jurídico arquiva o contrato. A área de negócio migra para a plataforma substituta. O fornecedor anterior continua a reter dados ao abrigo de ciclos normais de cópia de segurança, arquivo ou registo.

Essa fragmentação é exatamente o que auditores e reguladores testam.

O RGPD da UE define tratamento de forma ampla, incluindo conservação, apagamento e destruição. Distingue responsáveis pelo tratamento, que determinam as finalidades e os meios, de subcontratantes, que atuam por conta dos responsáveis pelo tratamento. O Article 5 estabelece princípios como limitação das finalidades, minimização dos dados, limitação da conservação e integridade e confidencialidade. O Article 5(2) acrescenta o princípio da responsabilidade demonstrável, ou seja, o responsável pelo tratamento deve conseguir demonstrar conformidade. O Article 28(3)(g) exige que os contratos com subcontratantes indiquem que, por escolha do responsável pelo tratamento, o subcontratante deve eliminar ou devolver todos os dados pessoais no fim da prestação do serviço e eliminar as cópias existentes, salvo se a lei exigir a conservação.

Uma mensagem informal do fornecedor raramente satisfaz esse padrão quando os dados envolvem informação salarial, registos financeiros, dados relacionados com a saúde, identificadores de clientes, logs de autenticação ou registos de clientes regulados.

DORA eleva o nível de exigência para as entidades financeiras. A partir de 17 de janeiro de 2025, DORA aplica-se como o quadro normativo de resiliência operacional digital do setor financeiro da UE. Exige que as entidades financeiras façam a gestão do risco de terceiros de TIC como parte integrante do seu quadro global de risco e continuem plenamente responsáveis pela conformidade quando os serviços são externalizados. DORA espera que as organizações mantenham registos de informação dos contratos de serviços de TIC, identifiquem serviços que suportam funções críticas ou importantes, realizem diligência prévia, avaliem o risco de concentração, incluam direitos contratuais de acesso, recuperação e devolução de dados, e mantenham estratégias de cessação e saída.

Para funções críticas ou importantes, os contratos DORA devem ir mais longe. Precisam de disposições sobre direitos de auditoria, períodos de transição, níveis de serviço, testes de contingência, obrigações de cooperação e apoio à saída. Um certificado de eliminação não é todo o pacote de saída DORA, mas é um artefacto de evidência crítico dentro dele.

A Diretiva NIS2 da UE também é relevante para muitos prestadores na cadeia de TIC mais ampla, incluindo fornecedores de serviços de computação em cloud, fornecedores de centros de dados, prestadores de serviços geridos, prestadores de serviços de segurança geridos e outros prestadores de infraestrutura digital. O NIS2 Article 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas, incluindo segurança da cadeia de fornecimento, controlos da relação com fornecedores, controlo de acesso, gestão de ativos, tratamento de incidentes, continuidade e higiene de cibersegurança. Para entidades financeiras abrangidas por DORA, DORA atua, em geral, como ato jurídico setorial da União para requisitos comparáveis de risco de TIC, reporte, testes e terceiros, mas a Diretiva NIS2 da UE continua a enquadrar o ecossistema mais amplo de cibersegurança.

A mensagem prática é simples: se um fornecedor tratou PII, suportou operações reguladas ou integrou a sua cadeia de serviços de TIC, a evidência de saída é um controlo de risco.

A visão da Clarysec: a saída de subcontratantes é uma cadeia de controlos

Um fluxo maduro de saída de subcontratantes responde a três perguntas:

1. Que dados, sistemas e subcontratantes subsequentes estão dentro do âmbito?
2. Que ação de devolução, transferência, eliminação ou descarte é exigida legal e contratualmente?
3. Que evidência demonstra que a ação foi concluída antes do encerramento da saída?

Em Zenith Controls: The Cross-Compliance Guide, este cenário é mapeado para o controlo ISO/IEC 27002:2022 5.20, “Tratamento da segurança da informação em acordos com fornecedores”; controlo 8.10, “Eliminação de informação”; e controlo 7.14, “Eliminação segura ou reutilização de equipamentos”. Estes não são itens separados de uma lista de verificação. A saída de subcontratantes liga acordos com fornecedores, gestão do ciclo de vida dos dados, desativação de serviços cloud, remoção de acessos, propriedade de ativos, retenção de evidência e preparação para auditoria.

O Zenith Blueprint: An Auditor’s 30-Step Roadmap da Clarysec coloca isto na fase Controls in Action. No Step 23, Organizational controls, espera-se que os acordos com fornecedores cubram disposições de fim de contrato, controlos de subcontratantes, direitos de auditoria e protocolos de incidentes. O Blueprint descreve áreas típicas de acordos com fornecedores como incluindo:

“Disposições de fim de contrato, tais como devolução ou destruição de dados, recuperação de ativos e desativação de contas.”

É nessa frase que se encontram a responsabilidade demonstrável do RGPD da UE, a evidência PIMS da ISO/IEC 27701:2025, as expectativas de saída DORA, a segurança da cadeia de fornecimento da Diretiva NIS2 da UE e o controlo operacional da ISO/IEC 27001:2022.

O mesmo Zenith Blueprint, no Step 19, Technological Controls I, explica o risco de eliminação subjacente à saída de subcontratantes:

“Este controlo assegura que os dados não são mantidos por mais tempo do que o necessário e, quando deixam de ser necessários, devem ser eliminados de forma segura e fiável.”

O Step 18, Physical Controls II, traduz a expectativa de evidência em termos práticos:

“Se utilizar um prestador externo, solicite e retenha certificados de destruição como evidência de auditoria.”

Para sistemas baseados na cloud, a eliminação física está normalmente fora do controlo direto do cliente. Isso torna ainda mais importantes a confirmação contratual de eliminação, os certificados de apagamento com qualidade de conformidade e a documentação arquivada do SGSI.

O modelo operacional da Clarysec é direto: cláusula contratual, evento de saída, inventário de dados, ação de eliminação, confirmação de subcontratantes subsequentes, registo de evidências e verificação final.

Porque “eliminado” não é o mesmo que demonstrado

Uma constatação de auditoria comum é formulada da seguinte forma:

“A organização declarou que o fornecedor eliminou os dados, mas não conseguiu fornecer evidência da eliminação, âmbito da eliminação, data da eliminação, parte responsável, sistemas incluídos, tratamento de cópias de segurança ou confirmação de subcontratantes subsequentes.”

Isto acontece em grandes empresas, mas também é comum em PME que dependem fortemente de ferramentas SaaS para processamento salarial, gestão de tickets de suporte, CRM, integração de RH, armazenamento cloud, colaboração, analítica e desenvolvimento de software. Quando um fornecedor muda, os dados pessoais permanecem frequentemente em contas inativas, anexos de suporte, ficheiros temporários de migração, exportações de desenvolvimento, bases de dados de staging e ciclos de cópia de segurança.

O conjunto de políticas da Clarysec transforma “eliminado” num requisito de evidência.

A Third party and supplier security policy [P26] exige na cláusula 6.5.1.2:

“Devolução ou destruição certificada de toda a informação pertencente à organização”

A cláusula 6.5.1.3 exige em seguida:

“Verificação final de conformidade (por exemplo, revisão de logs, atestados de conformidade)”

Esta distinção é relevante. Um certificado de eliminação não é todo o controlo. É um artefacto dentro de um pacote de verificação final de conformidade. Os auditores vão querer verificar se o certificado corresponde ao contrato do fornecedor, ao inventário de dados, ao ticket de saída, aos logs de acesso, à lista de subcontratantes subsequentes, ao calendário de retenção e à avaliação de riscos.

Para PME, a Third-Party and Supplier Security Policy - SME [P26S] fornece uma linha de base prática. A cláusula 5.3.6, em Governance Requirements, exige:

“Termos de cessação, incluindo devolução ou destruição segura de dados”

A cláusula 6.4.2.3, em Policy Implementation Requirements, exige que os fornecedores:

“Confirmem por escrito que os dados foram eliminados de forma segura”

A Data Retention and Disposal Policy [P14] acrescenta o requisito de evidência na cláusula 4.7.2:

“Devem fornecer informação documentada de cumprimento (por exemplo, logs de eliminação, certificados de destruição) mediante pedido.”

Para PME, a Data Retention Policy and Secure Disposal Policy - SME exige na cláusula 6.2.3:

“Os eventos de eliminação devem ser registados com a data, a categoria de registo, o método e a pessoa responsável.”

Esta é a diferença entre confiar no fornecedor e dispor de evidência de auditoria.

ISO/IEC 27701:2025: evidência de saída baseada em funções

A ISO/IEC 27701:2025 acrescenta uma camada de gestão da privacidade ao SGSI. A saída de subcontratantes deve refletir o papel PIMS da organização. Um responsável pelo tratamento que termina uma relação com um subcontratante tem responsabilidades diferentes das de um subcontratante que termina uma relação com um subcontratante subsequente. Um subcontratante que atua segundo instruções do cliente deve documentar que seguiu essas instruções. Um subcontratante em cloud deve demonstrar que a devolução, transferência, eliminação ou descarte ocorreu dentro do prazo acordado com o cliente.

O conjunto de políticas PIMS da Clarysec utiliza etiquetas de função para operacionalizar isto. “Both” aplica-se quando a organização é responsável pelo tratamento ou subcontratante. “Processor” aplica-se quando trata PII com base em instruções documentadas do responsável pelo tratamento. “Subprocessor” aplica-se quando é contratado por outro subcontratante.

A Processor, Subprocessor and Third-Party Privacy Management Policy exige na cláusula 4.5.6:

“[Both] O Responsável pelo Fornecedor / Responsável de Compras DEVE obter evidência de devolução, eliminação, descarte ou transição em REG08 no prazo de 30 dias após a cessação contratual, caducidade, instrução do cliente ou evento de saída aprovado, salvo se for aplicável um prazo contratual mais curto.”

A PII Retention, Deletion and Disposal Policy separa as obrigações de subcontratantes e subcontratantes subsequentes. A cláusula 4.3.3 estabelece:

“[Processor] O Responsável pelo Fornecedor / Responsável de Compras DEVE executar ou confirmar a devolução, transferência, eliminação ou descarte orientados pelo cliente em REG08 até ao prazo contratual ou à data documentada da instrução do cliente.”

A cláusula 4.3.4 estabelece:

“[Subprocessor] O Responsável pelo Fornecedor / Responsável de Compras DEVE obter evidência de devolução, eliminação ou descarte do subcontratante subsequente em REG08 dentro do período contratual de evidência após instrução do cliente, saída do serviço ou cessação do subcontratante subsequente.”

A cláusula 7.1.7 faz regressar o requisito ao encerramento:

“[Both] O Responsável pelo Fornecedor / Responsável de Compras DEVE obter evidência do subcontratante, subcontratante subsequente ou serviço externo relativa às ações exigidas de devolução, transferência ou destino final em REG08 antes de encerrar a saída do serviço.”

Para serviços cloud, a Cloud PII Processor Policy exige na cláusula 4.6.3:

“[Processor] O Responsável pelo Sistema / Responsável pela Aplicação DEVE concluir a devolução, transferência, eliminação ou descarte aprovados de PII do cliente dentro do prazo acordado com o cliente e registar evidência de conclusão em REG08 ou REG12.”

A melhoria operacional é imediata. Não espere por uma auditoria. Crie o requisito de evidência no evento de saída, atribua-o a um responsável, defina um prazo e impeça o encerramento até que REG08 ou REG12 esteja completo.

O que deve incluir um bom pacote de evidências de saída de subcontratantes

Um certificado de eliminação não deve ser um PDF vago com um logótipo e uma frase. Deve apoiar um pacote de evidências estruturado, capaz de resistir a um pedido de esclarecimento ao abrigo do RGPD da UE, a uma auditoria PIMS ISO/IEC 27701:2025, a uma auditoria de acompanhamento ISO/IEC 27001:2022, a um pedido de supervisão DORA, a uma revisão de garantia por cliente ou a uma auditoria interna.

Isto não é burocracia. É uma cadeia de custódia prática para PII na saída do serviço.

A cláusula contratual que previne a crise

O problema de Maria começou anos antes da mensagem final da DataLeap. Começou quando o contrato foi assinado com uma cláusula de eliminação vaga e sem obrigação de evidência. O fluxo de saída de subcontratantes mais robusto começa na aquisição, não na cessação.

Para serviços cloud, a Cloud Usage Policy empresarial exige na cláusula 5.4.4:

“Cláusulas de cessação que permitam uma saída segura e verificável”

Para PME, a Cloud Usage Policy - SME exige na cláusula 6.3.5:

“Confirmação de procedimentos de eliminação segura antes do encerramento da conta”

Uma cláusula contratual prática para fornecedores deve exigir devolução ou eliminação, definir prazos, abranger cópias de segurança e subcontratantes subsequentes, exigir evidência e preservar direitos de auditoria.

Cláusula-modelo: devolução, eliminação e evidência de dados

Após a cessação ou caducidade do acordo, ou mediante instrução escrita do responsável pelo tratamento, o subcontratante deve, por escolha do responsável pelo tratamento, devolver de forma segura todos os dados pessoais num formato legível por máquina acordado ou eliminar de forma segura todos os dados pessoais de sistemas, suportes, cópias de segurança e ambientes sob o controlo do subcontratante, salvo se o direito da União ou de um Estado-Membro exigir a conservação.

No prazo de trinta dias de calendário após concluir a ação exigida, ou em prazo mais curto quando contratualmente acordado, o subcontratante deve fornecer um Certificado de Eliminação assinado ou atestado de conformidade equivalente. O certificado deve identificar o serviço, as categorias de dados, os sistemas abrangidos, o intervalo de datas da eliminação, o método de eliminação, o tratamento de cópias de segurança e arquivos, o estado dos subcontratantes subsequentes, as exceções retidas e o signatário autorizado.

O responsável pelo tratamento pode solicitar evidência de suporte razoável, incluindo logs, registos de eliminação, atestados de subcontratantes subsequentes e documentação do processo, para verificar o certificado e encerrar o registo de saída do fornecedor.

Esta redação transforma a responsabilidade demonstrável num entregável operacional.

Exemplo prático: saída de SaaS de processamento salarial

Considere uma PME que migra do PayrollCloud A para o PayrollCloud B. O PayrollCloud A tratava nomes de trabalhadores, moradas, identificadores fiscais, dados bancários, histórico salarial, registos de doença e tickets de suporte. Utilizava um prestador de alojamento cloud e uma plataforma de suporte como subcontratantes subsequentes.

Uma saída alinhada com a Clarysec funcionaria da seguinte forma.

1. Abrir um ticket de saída de fornecedor

A equipa de compras cria um ticket de saída ligado ao registo do fornecedor. O ticket inclui a data de cessação do contrato, a data final do serviço, o responsável de negócio, o responsável pelo sistema, o EPD ou contacto de privacidade, e se podem estar envolvidas categorias especiais de dados pessoais. Como o processamento salarial pode incluir dados laborais sensíveis e dados relacionados com a saúde, a classificação de risco é alta.

2. Mapear a saída ao acordo

O Responsável pelo Fornecedor verifica o contrato quanto a cláusulas de devolução, eliminação, auditoria, transição e subcontratantes subsequentes. Se o contrato for fraco, o responsável ainda assim envia uma instrução formal que exige devolução, eliminação e confirmação de subcontratantes subsequentes. A expectativa de evidência assenta nas políticas da Clarysec, incluindo P26, P26S, P14, a Cloud Usage Policy e a Cloud Usage Policy - SME.

3. Definir o âmbito da PII

O Responsável pelo Sistema preenche uma declaração do âmbito dos dados que cobre registos salariais de produção, documentos de autosserviço dos trabalhadores, anexos, exportações, tickets de suporte, logs de auditoria contendo identificadores de utilizador, ficheiros de integração por API, extratos temporários de migração, cópias de segurança, snapshots e dados detidos por subcontratantes subsequentes.

Isto apoia a responsabilidade demonstrável do RGPD da UE, a evidência PIMS ISO/IEC 27701:2025, o controlo operacional ISO/IEC 27001:2022 e, para entidades financeiras, as expectativas relativas ao registo de informação de terceiros de TIC em DORA.

4. Solicitar evidência de devolução, eliminação e subcontratantes subsequentes

O Responsável pelo Fornecedor envia ao PayrollCloud A um pedido estruturado para confirmar a conclusão da exportação final, a eliminação dos dados do tenant de produção, o tratamento de cópias de segurança e arquivos imutáveis, a eliminação de anexos de tickets de suporte, a revogação de contas específicas do cliente e credenciais de API, a evidência de eliminação ou descarte por subcontratantes subsequentes, e um certificado de eliminação assinado.

5. Registar a conclusão em REG08 ou REG12

O Responsável pelo Fornecedor regista cada item de evidência em REG08. Se a organização atuar como subcontratante e a aplicação cloud contiver PII do cliente, a conclusão também pode ser registada em REG12 ao abrigo da Cloud PII Processor Policy.

6. Efetuar a verificação final antes do encerramento

A Conformidade compara o certificado de eliminação com a declaração do âmbito dos dados. A TI verifica os logs de acesso e a evidência de encerramento de contas. O EPD verifica se existe alguma exceção de retenção, como uma obrigação legal ou uma preservação por litígio. A Segurança verifica que os tokens de API, contas de serviço e configurações de SSO foram removidos.

Só então o ticket de saída é encerrado.

Se o fornecedor se recusar a fornecer evidência, a questão passa a ser matéria de tratamento de riscos. Pode desencadear escalonamento, medidas contratuais, análise de notificação a clientes, avaliação regulamentar, monitorização reforçada durante a transição ou alterações à classificação de risco do fornecedor.

DORA, NIS2 e resiliência TIC: evidência de saída para além da privacidade

DORA trata a saída de fornecedores como parte da resiliência, não apenas como administração da privacidade. Uma entidade financeira continua responsável pela conformidade mesmo quando serviços de TIC são externalizados. Deve manter um registo de informação dos contratos de serviços de TIC, distinguir serviços que suportam funções críticas ou importantes, realizar diligência prévia, avaliar o risco de concentração e manter estratégias de saída.

Um certificado de eliminação de subcontratante pode afetar várias preocupações DORA:

• Continuidade do serviço ao cliente
• Reporte regulamentar
• Integridade dos dados
• Resposta a incidentes
• Direitos de auditoria
• Resiliência operacional
• Planeamento de recuperação e transição
• Gestão de funções críticas ou importantes

Para uma instituição de pagamento, empresa de investimento, instituição de crédito, prestador de serviços de criptoativos ou plataforma fintech, o certificado de eliminação deve integrar um pacote de saída mais amplo. Não basta provar que a PII foi eliminada se a organização não conseguir também provar que a transição do serviço evitou interrupções, que as obrigações regulamentares continuaram a ser cumpridas e que os impactos nos clientes foram geridos.

A Diretiva NIS2 da UE alarga a discussão sobre segurança de fornecedores para além dos serviços financeiros. A saída de subcontratantes é um teste de segurança da cadeia de fornecimento. Se uma entidade essencial ou importante não conseguir provar que um fornecedor devolveu ou eliminou dados no fim do serviço, tem uma fragilidade na gestão da relação com fornecedores, no controlo de ativos, na governação de acessos, na proteção de dados e, potencialmente, na preparação para incidentes.

Se uma saída falhada resultar em acesso não autorizado, perda, divulgação ou interrupção do serviço, a organização poderá ter de avaliar obrigações de notificação de incidentes ao abrigo da lei aplicável e das regras nacionais de transposição.

Mapeamento entre referenciais: um fluxo de trabalho, muitas obrigações

O valor de um fluxo de saída de subcontratantes bem desenhado é satisfazer múltiplos referenciais em simultâneo.

O NIST CSF 2.0 é especialmente útil como camada de comunicação. A sua função GOVERN exige que as organizações compreendam obrigações legais, regulamentares, contratuais e de privacidade, definam a estratégia de risco, atribuam funções e estabeleçam supervisão. Os seus resultados de Cybersecurity Supply Chain Risk Management abrangem requisitos de fornecedores em contratos, monitorização do risco de fornecedores e atividades após o fim de uma parceria ou acordo de serviço. GV.SC-10 é exatamente onde a saída de subcontratantes pertence.

O que os auditores vão perguntar

Auditores diferentes abordam a saída de subcontratantes por perspetivas diferentes, mas o pacote de evidências deve ser suficientemente robusto para todos.

Um auditor ISO/IEC 27001:2022 pode não começar por pedir um “certificado de eliminação de PII”. Pode começar pelo âmbito, requisitos de partes interessadas, controlo de fornecedores, Declaração de Aplicabilidade, tratamento de riscos e informação documentada retida. Se o certificado de eliminação não puder ser ligado a esses elementos, pode parecer um artefacto autónomo e não prova de um controlo em funcionamento.

Um auditor PIMS perguntará se a organização compreendeu o seu papel de privacidade. Era responsável pelo tratamento, subcontratante, subcontratante subsequente ou subcontratante de PII em cloud? A saída baseou-se numa instrução documentada do cliente? As obrigações foram propagadas aos subcontratantes subsequentes? A evidência foi armazenada no registo correto? As exceções foram justificadas?

Um revisor DORA perguntará se o serviço consta do registo de informação de TIC, se suporta uma função crítica ou importante, se o contrato incluía devolução de dados e direitos de auditoria, e se a transição evitou interrupções e danos para os clientes.

O mesmo pacote de evidências deve responder a todos.

Padrões comuns de falha

A Clarysec observa repetidamente as mesmas fragilidades durante revisões de saída de subcontratantes:

• Os contratos exigem eliminação, mas não definem a evidência.
• Os fornecedores emitem declarações genéricas de eliminação sem âmbito de sistemas.
• Cópias de segurança, snapshots e arquivos imutáveis são ignorados.
• A eliminação por subcontratantes subsequentes é assumida, não evidenciada.
• A desativação de acessos é tratada como eliminação de dados.
• A equipa de compras encerra o fornecedor antes de a conformidade rever a evidência.
• As exceções de retenção não são documentadas.
• Os programadores retêm exportações de teste após o fim do desenvolvimento externalizado.
• As contas cloud são encerradas antes de ser obtida confirmação de eliminação.
• A evidência de auditoria fica armazenada em correio eletrónico, não num registo controlado.

O cenário de desenvolvimento externalizado é particularmente comum. A Outsourced development policy - SME exige na cláusula 7.4.1.2:

“Todos os dados detidos por programadores devem ser eliminados e a evidência pode ser solicitada”

Para equipas de desenvolvimento, isto inclui conjuntos de dados locais, bases de dados de staging, logs de depuração, crash dumps, capturas de ecrã, exportações de suporte, prompts de teste de IA e ficheiros temporários de migração. Se o fluxo de saída de fornecedores ignorar dados detidos por programadores, está incompleto.

Lista de verificação de saída de subcontratantes

Um processo robusto de saída de subcontratantes não precisa de ser complexo, mas deve ser disciplinado.

• Identificar o evento de saída: cessação, caducidade, instrução do cliente, substituição de fornecedor, resposta a violação de dados pessoais, transição aprovada ou cessação de subcontratante subsequente.
• Confirmar o papel PIMS: responsável pelo tratamento, subcontratante, subcontratante subsequente, responsável conjunto pelo tratamento ou subcontratante de PII em cloud.
• Ligar o registo do fornecedor: contrato, responsável pelo serviço, função de negócio, criticidade e categorias de dados.
• Identificar o âmbito da PII: produção, cópias de segurança, logs, exportações, tickets de suporte, analítica, dados de teste e subcontratantes subsequentes.
• Emitir instruções escritas: devolução, transferência, eliminação, descarte ou exceção de retenção.
• Obter evidência: certificado de eliminação, certificado de destruição, logs, atestado de subcontratante subsequente e prova de encerramento de acessos.
• Registar a evidência em REG08 ou REG12: localização da evidência, data, método, pessoa responsável e revisor.
• Verificar antes do encerramento: comparar a evidência com o âmbito dos dados, o contrato e as instruções do cliente.
• Escalonar exceções: evidência em falta, expiração adiada de cópias de segurança, retenção contestada, fornecedor não cooperante ou acesso residual.
• Alimentar a melhoria: atualizar modelos contratuais, classificação de risco do fornecedor, calendário de retenção, plano de auditoria e reporte à gestão.

É assim que o Zenith Blueprint, o Zenith Controls e o conjunto de políticas da Clarysec funcionam em conjunto. O Blueprint mostra onde o controlo pertence na jornada de implementação. As políticas definem o comportamento exigido. O Zenith Controls mapeia a relação de controlo entre ISO/IEC 27002:2022, RGPD da UE, DORA, NIS2, NIST e expectativas de auditoria.

A mensagem para o Conselho de Administração

A saída de subcontratantes não é uma etapa administrativa no fim de um contrato. É um teste real à governação da privacidade, gestão de fornecedores, segurança na cloud, resiliência TIC e disciplina de evidência de auditoria.

Um certificado de eliminação só é valioso quando está ligado a:

• Uma relação conhecida com fornecedor
• Um âmbito de dados definido
• Uma instrução contratual ou do cliente
• Um método de eliminação ou descarte seguro
• Evidência de obrigações em cadeia para subcontratantes subsequentes
• Encerramento de acessos
• Tratamento de cópias de segurança e arquivos
• Um registo de evidências controlado
• Verificação final de conformidade

Sem essa cadeia, a organização está a confiar precisamente no momento em que deveria depender de evidência.

Próximos passos com a Clarysec

Se a sua organização utiliza SaaS, cloud, processamento salarial, RH, finanças, suporte, desenvolvimento ou prestadores geridos de TIC, reveja o seu fluxo de saída de subcontratantes antes de enviar a próxima notificação de cessação.

A Clarysec pode ajudá-lo a implementar um modelo prático de saída de subcontratantes, pronto para auditoria, utilizando:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap para colocar a saída de fornecedores, a eliminação e o descarte nos passos de implementação corretos.
• Zenith Controls: The Cross-Compliance Guide para mapear acordos com fornecedores, eliminação de informação e descarte seguro entre ISO/IEC 27002:2022, RGPD da UE, DORA, NIS2, NIST e expectativas de auditoria.
• Processor, Subprocessor and Third-Party Privacy Management Policy e PII Retention, Deletion and Disposal Policy para operacionalizar a evidência REG08.
• Third party and supplier security policy, Data Retention and Disposal Policy e Cloud PII Processor Policy para tornar a evidência de saída exigível.

A sua próxima ação é simples: escolha um fornecedor cessado recentemente e construa um pacote retrospetivo de evidências de saída. Se não conseguir provar devolução, eliminação, confirmação de subcontratantes subsequentes e verificação final, esse é o seu primeiro item de remediação.

A Clarysec pode ajudá-lo a transformar essa lacuna num controlo repetível de saída de subcontratantes antes que um auditor, regulador ou cliente o solicite.