Governação do acesso a PII para ISO 27701:2025 e RGPD da UE

A pergunta do auditor externo ficou no ar, aparentemente simples.

“Pode mostrar-me o registo de revisão de acessos relativo ao acesso da sua equipa de suporte à PII de produção no último trimestre?”

Para Anya, CISO da Medtelligence, um prestador SaaS de tecnologia de saúde em rápido crescimento, este era o momento decisivo. A Medtelligence atua como subcontratante de PII para hospitais e trata dados sensíveis de pacientes numa plataforma na nuvem. A empresa tinha autenticação robusta, funções definidas e uma equipa de engenharia madura. Mas o auditor não estava a perguntar se existia uma página de autenticação. Estava a pedir evidência de que o acesso a dados pessoais era governado ao longo do tempo.

Queria ver quem podia aceder à PII de produção, por que motivo tinha acesso, quando esse acesso tinha sido aprovado, se ainda era necessário, se a atividade de suporte era registada em logs e se as permissões desnecessárias tinham sido removidas.

Anya abriu a consola de IAM. Havia engenheiros de suporte, administradores de bases de dados, uma conta de serviço de integração, um prestador de serviços geridos, duas funções de emergência, e um antigo contratado ainda presente num grupo porque o ticket de saída tinha sido fechado antes de a autorização ser removida. Os Recursos Humanos indicavam que a pessoa tinha saído seis semanas antes. A folha de cálculo da revisão de acessos dizia “pendente”. O SIEM tinha logs, mas ninguém tinha mapeado que eventos demonstravam acesso a PII.

É aqui que a governação da privacidade se torna concreta.

Ao abrigo do RGPD da UE, os dados pessoais devem ser tratados com integridade e confidencialidade, protegidos contra tratamento não autorizado ou ilícito e contra perda, destruição ou dano acidental através de medidas técnicas e organizativas adequadas. O RGPD da UE também torna explícita a responsabilização: o responsável pelo tratamento deve poder demonstrar o cumprimento. A ISO/IEC 27701:2025 transforma essa responsabilização num sistema de gestão da informação de privacidade, ou PIMS, em que o acesso a PII deixa de ser uma questão técnica secundária. Passa a ser um ciclo de vida governado que abrange funções, subcontratantes, plataformas na nuvem, trabalhadores, administradores privilegiados, logs, revisões, contratos e evidência.

A lacuna em muitas organizações não é a ausência de controlo de acesso. A lacuna é a incapacidade de demonstrar, de forma consistente, a governação do acesso a PII em ISO/IEC 27701:2025, RGPD da UE, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

A governação do acesso a PII não é apenas IAM

Um programa tradicional de IAM pergunta: “Os utilizadores certos conseguem aceder aos sistemas certos?”

Um PIMS maduro segundo a ISO/IEC 27701:2025 faz perguntas mais exigentes:

• Que sistemas tratam PII?
• Que funções exigem acesso a que categorias de PII?
• A organização atua como responsável pelo tratamento de PII, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente?
• O acesso é limitado pela finalidade, pela necessidade de negócio documentada e pelo princípio do menor privilégio?
• As ações privilegiadas são registadas em logs e revistas?
• A organização consegue demonstrar que o acesso de subcontratantes e subcontratantes subsequentes está controlado contratualmente?
• Os fluxos de suporte na nuvem, o isolamento entre ambientes de cliente, as exportações e as ações administrativas estão incluídos na evidência?
• As decisões de acesso são revistas após integração, alteração de função, incidente, saída e alteração material do sistema?

É por isso que a governação da segurança da PII e do controlo de acesso é uma ponte natural entre a ISO/IEC 27701:2025 e o RGPD da UE. O RGPD da UE fornece o enquadramento jurídico da responsabilização. A ISO/IEC 27701:2025 operacionaliza a gestão da privacidade para responsáveis pelo tratamento e subcontratantes. A ISO/IEC 27001:2022 fornece o motor de gestão de riscos do SGSI. A ISO/IEC 27002:2022 fornece a arquitetura de controlos, incluindo privacidade e proteção de PII, controlo de acesso, direitos de acesso, registo de eventos, serviços na nuvem, relações com fornecedores, classificação, eliminação, mascaramento e criptografia.

O Zenith Blueprint: roteiro de 30 etapas para auditores da Clarysec posiciona este tema na fase de controlos em ação. Na etapa 23, que abrange os controlos organizacionais 5.19 a 5.37, descreve o controlo 5.34 da ISO/IEC 27002:2022, Privacidade e proteção de PII, como uma questão de confiança, e não apenas uma questão de dados:

as informações pessoais identificáveis não são apenas mais um tipo de dados; são uma representação profundamente sensível da confiança. Nomes, moradas, documentos de identificação, registos de saúde, dados financeiros — estes dados contam a história de pessoas reais.

A mesma passagem fornece a base prática: a proteção da privacidade começa com o conhecimento dos dados. Uma organização deve saber que PII recolhe, onde reside, por que motivo é tratada e quem pode aceder-lhe.

A pressão de conformidade por detrás do controlo de acesso a PII

A governação do acesso a PII deixou de ser uma questão de um único referencial. Organizações como a Medtelligence operam na interseção entre regulamentação de privacidade, legislação de cibersegurança, resiliência operacional, garantia para clientes e certificação de segurança.

O Article 5 do RGPD da UE exige que os dados pessoais sejam tratados de acordo com licitude, lealdade, transparência, limitação das finalidades, minimização dos dados, exatidão, limitação da conservação, integridade e confidencialidade. O Article 5(2) introduz a responsabilização: o responsável pelo tratamento é responsável pelo cumprimento e deve poder demonstrá-lo. O Article 32 exige medidas técnicas e organizativas adequadas para a segurança do tratamento.

O Article 21 da NIS2 exige que entidades essenciais e importantes adotem medidas técnicas, operacionais e organizativas de gestão de riscos de cibersegurança adequadas e proporcionadas. Os seus domínios mínimos incluem análise de riscos, políticas de segurança, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e desenvolvimento seguros, avaliação da eficácia, higiene de cibersegurança e formação, criptografia, segurança de Recursos Humanos, controlo de acesso, gestão de ativos e, quando adequado, autenticação multifator ou contínua e comunicações seguras. O Article 20 também atribui aos órgãos de administração a responsabilidade de aprovar e supervisionar as medidas de gestão de riscos de cibersegurança.

O DORA aplica-se a partir de 17 de janeiro de 2025 a um vasto conjunto de entidades financeiras e cria um regime setorial de resiliência operacional. Abrange gestão do risco das TIC, comunicação de incidentes graves relacionados com TIC, testes de resiliência operacional digital, partilha de informações, risco de terceiros de TIC e acordos contratuais com prestadores terceiros de serviços de TIC. Para entidades financeiras e prestadores de serviços de TIC que as apoiam, o controlo de acesso não é apenas uma questão de privacidade. Faz parte da resiliência operacional.

A ISO/IEC 27001:2022 integra estas obrigações num sistema de gestão baseado no risco. As cláusulas 6.1.1 a 6.1.3 exigem que as organizações tratem riscos e oportunidades, definam um processo de avaliação de riscos de segurança da informação, identifiquem riscos para a confidencialidade, integridade e disponibilidade, avaliem riscos, selecionem opções de tratamento, determinem controlos, comparem os controlos selecionados com o Anexo A, documentem a Declaração de Aplicabilidade, obtenham a aprovação do proprietário do risco e aceitem os riscos residuais. As cláusulas 8.2 e 8.3 exigem avaliações de risco em intervalos planeados ou após alterações significativas, bem como a implementação do plano de tratamento de riscos com resultados documentados.

Para a governação de PII, isto significa que o controlo de acesso não é uma definição isolada de IAM. É uma decisão de tratamento de riscos. Uma função que pode exportar registos de salários, dados de pacientes, dados de pagamento, documentos de identidade, dados de localização ou transcrições de suporte ao cliente deve estar justificada no Registo de Riscos, refletida na Declaração de Aplicabilidade, aplicada em IAM, registada em logs de produção, revista periodicamente e removida quando deixar de ser necessária.

O modelo de controlos da Clarysec: da promessa de privacidade à evidência

A Clarysec trata a governação do acesso a PII como uma cadeia de evidência. A cadeia começa no inventário de dados e na definição de funções, passa pela aprovação e aplicação do acesso, e termina na monitorização, revisão, revogação e registos prontos para auditoria.

Em Zenith Controls: guia de conformidade transversal, o tema centra-se principalmente em três controlos da ISO/IEC 27002:2022:

Os auditores raramente aceitam “usamos IAM” como evidência. Esperam ver como as decisões de IAM se ligam a obrigações de privacidade, propriedade do sistema, classificação de dados, necessidade de negócio, tratamento de riscos, frequência de revisão de acessos, âmbito de registo de eventos e contratos com fornecedores.

A Política de segurança e controlo de acesso a PII da Clarysec estabelece a linha de base em linguagem PIMS:

[Ambos] O Proprietário do sistema / Responsável pela Aplicação DEVE restringir o acesso a PII a funções aprovadas e utilizadores autorizados registados ou rastreáveis no REG02 ou no REG12 antes de o acesso ser ativado.

Da secção “4.2 Linha de base de controlo de acesso”, cláusula 4.2.1 da política.

A etiqueta “[Ambos]” significa que o controlo se aplica quer a organização atue como responsável pelo tratamento de PII quer como subcontratante de PII. Esta distinção é importante. Os responsáveis pelo tratamento falham frequentemente na definição de regras de acesso baseadas na finalidade. Os subcontratantes falham frequentemente na demonstração de que o acesso está limitado a instruções do cliente, fluxos de suporte aprovados e pessoal contratualmente autorizado.

A mesma política eleva a exigência para PII sensível ou de alto impacto:

[Ambos] O Proprietário do sistema / Responsável pela Aplicação DEVE rever o acesso dos utilizadores a sistemas que tratam PII sensível ou de alto impacto pelo menos trimestralmente e registar o resultado da revisão no REG12.

Da secção “4.2 Linha de base de controlo de acesso”, cláusula 4.2.3 da política.

É aqui que um PIMS se torna auditável. A revisão de acessos não é apenas uma mensagem de correio eletrónico de um gestor. É um registo no REG12, associado a um sistema, categoria de dados, função, proprietário, resultado da revisão e ação de remediação.

Base de políticas: menor privilégio, necessidade de negócio e negação por defeito

A governação eficaz começa com regras aplicáveis. Antes de Anya poder mostrar ao auditor um registo de revisão de acessos, tinha de demonstrar que o requisito de revisão de acessos estava formalmente estabelecido.

A Política de controlo de acesso - PME da Clarysec define o princípio:

Esta política aplica o princípio do menor privilégio e exige que o acesso seja limitado ao mínimo necessário para desempenhar as funções profissionais.

Da secção “Finalidade”, cláusula 1.3 da política.

A Política de proteção de dados e privacidade - PME liga o acesso à necessidade de negócio:

O acesso dos utilizadores a dados pessoais deve ser limitado a funções com necessidade de negócio documentada

Da secção “Requisitos de governação”, cláusula 5.3.2 da política.

Para organizações de maior dimensão, a Política de proteção de dados e privacidade empresarial expressa a expectativa de controlo como requisito do sistema:

Todos os sistemas devem aplicar, por defeito, o acesso segundo o princípio do menor privilégio.

Da secção “Requisitos de implementação da política”, cláusula 6.3.1 da política.

A distinção é importante. Uma empresa de menor dimensão pode precisar de um registo leve, mas explícito, da necessidade de negócio. Uma organização empresarial precisa de aplicação ao nível do sistema, revisão periódica, segregação de funções, governação de acessos privilegiados e evidência preservada para auditoria interna, garantia para clientes, pedidos de esclarecimento regulamentar e investigação de violações de dados pessoais.

O ciclo de vida do acesso a PII: aprovação, utilização, revisão, revogação

A falha mais comum no acesso a PII não é a aprovação inicial. É a persistência do acesso.

O Zenith Blueprint, na fase de controlos em ação, etapa 22, explica o controlo 5.18 da ISO/IEC 27002:2022, Direitos de acesso, da seguinte forma:

O controlo 5.18 assegura que os direitos de acesso não são apenas concedidos de forma adequada, mas também revistos, ajustados e revogados de modo controlado e rastreável.

Em seguida, descreve cenários familiares: uma nova admissão recebe acesso, muda de função e mantém permissões antigas; um antigo administrador sai, mas um token permanece ativo; uma conta de contratado expira no papel, mas não em IAM. Estas são precisamente as fragilidades que se transformam em incidentes de segurança ao abrigo do RGPD da UE quando está envolvida PII.

A Política de Gestão de Contas de Utilizador e Privilégios - PME da Clarysec estabelece uma periodicidade de referência:

Deve ser realizada uma revisão de todas as contas de utilizador e privilégios a cada seis meses.

Da secção “Requisitos de implementação da política”, cláusula 6.4.1 da política.

Para ambientes empresariais, a Política de Gestão de Contas de Utilizador e Privilégios torna o ritmo operacional mais exigente:

Devem ser realizadas revisões trimestrais de todas as contas de utilizador e privilégios associados pela Segurança de TI, em colaboração com os gestores de departamento.

Da secção “Requisitos de implementação da política”, cláusula 6.5.1 da política.

Um ciclo de vida prático do acesso a PII deve incluir:

1. Classificar o sistema e as categorias de PII.
2. Definir funções aprovadas e necessidade de negócio documentada.
3. Mapear funções para finalidades do tratamento.
4. Aprovar o acesso antes da ativação.
5. Aplicar o princípio do menor privilégio, a segregação de funções e autenticação robusta.
6. Registar em logs a autenticação, o acesso, a exportação, a configuração e as ações privilegiadas.
7. Rever o acesso com periodicidade baseada no risco.
8. Remover o acesso em caso de alteração de função, cessação, encerramento do projeto, caducidade do contrato ou instrução do cliente.
9. Preservar evidência no registo do PIMS e no trilho de auditoria.

Isto não é burocracia. É a forma como uma organização demonstra que o acesso a PII é controlado desde a conceção, por defeito e por evidência.

Um exemplo prático: a revisão trimestral do acesso a PII

A auditoria de Anya foi bem-sucedida quando ela deslocou a conversa das declarações de política para a evidência.

Primeiro, citou a Política de segurança e controlo de acesso a PII, cláusula 4.2.3, que exigia a revisão trimestral do acesso a PII sensível ou de alto impacto e o registo do resultado da revisão no REG12.

Depois, guiou o auditor pelo trimestre anterior:

• A TI gerou uma lista de todos os utilizadores, grupos, funções privilegiadas, contas de serviço, contas de fornecedores, funções de emergência e permissões de suporte para a base de dados de produção que continha dados de pacientes.
• A lista foi enviada ao Responsável pela Aplicação, o Diretor de Sucesso do Cliente, que detinha a necessidade operacional da equipa de suporte.
• O Responsável pela Aplicação reviu a lista linha a linha face à função atual, à responsabilidade de suporte ao cliente e à finalidade do tratamento.
• Dois agentes de suporte que tinham mudado de equipa foram marcados para revogação.
• Foi criado um ticket no sistema de gestão de serviços de TI, associado à revisão de acessos, com um SLA atribuído, e fechado após a revogação.
• O REG12 foi atualizado com o registo da revisão, aprovador, exceções, ticket de remediação, evidência de encerramento e próxima data de revisão.

O resultado foi uma cadeia de evidência de ciclo fechado. Anya não se limitou a afirmar que a Medtelligence usava o princípio do menor privilégio. Mostrou o requisito da política, o proprietário responsável, a lista de acessos, a decisão de revisão, a ação corretiva e a revogação concluída.

Essa é a diferença entre controlo de acesso e governação de acessos.

Acesso de fornecedores e subcontratantes: o ponto cego nas auditorias ao PIMS

Muitos riscos de acesso não autorizado entram por vias de suporte, outsourcing, parceiros de integração, prestadores de serviços geridos e subcontratantes subsequentes. Um subcontratante pode ter acesso remoto a dados de produção de clientes. Um prestador de serviços na nuvem pode disponibilizar fluxos de acesso para suporte. Um subcontratante subsequente pode manter um índice de pesquisa que contém identificadores de clientes. Um prestador de serviços de segurança geridos pode aceder a logs que contêm dados pessoais.

Ao abrigo do RGPD da UE, os responsáveis pelo tratamento devem recorrer a subcontratantes que ofereçam garantias suficientes. Ao abrigo da ISO/IEC 27701:2025, a governação de subcontratantes e subcontratantes subsequentes deve ser operacionalizada através de instruções documentadas, controlos contratuais, garantia e monitorização. A ISO/IEC 27002:2022 apoia este objetivo através de controlos de relações com fornecedores, incluindo 5.19 Segurança da informação nas relações com fornecedores, 5.20 Tratamento da segurança da informação em acordos com fornecedores e 5.21 Gestão da segurança da informação na cadeia de fornecimento de TIC.

O Zenith Blueprint, na fase de controlos em ação, etapa 23, resume as áreas de evidência dos acordos com fornecedores, incluindo:

✓ Responsabilidades de controlo de acesso, como quem pode aceder aos seus dados, como são geridas as credenciais e que monitorização existe;

Também inclui obrigações de confidencialidade, medidas técnicas e organizativas, prazos de notificação de incidentes, direito de auditoria, controlos de subcontratantes e desativação de contas no fim do contrato.

A Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros da Clarysec converte isto em evidência PIMS do lado do responsável pelo tratamento:

[Responsável pelo tratamento] O Líder de Privacidade / Gestor do PIMS DEVE verificar que os campos de controlo contratual do subcontratante no REG08 abrangem o âmbito do tratamento, duração, finalidade, categorias de PII, categorias de titulares dos dados, confidencialidade, segurança, autorização de subcontratantes subsequentes, assistência, auditoria ou garantia, devolução, eliminação e cessação antes da aprovação.

Da secção “4.3 Controlos contratuais e de instruções documentadas”, cláusula 4.3.2 da política.

O acesso de fornecedores também é controlado diretamente nas políticas de fornecedores PME e empresariais da Clarysec. A Política de segurança de terceiros e fornecedores - PME afirma:

Os fornecedores devem receber acesso apenas aos sistemas e dados mínimos necessários para desempenhar a sua função.

Da secção “Requisitos de implementação da política”, cláusula 6.2.1 da política.

A Política de segurança de terceiros e fornecedores empresarial acrescenta RBAC, revisão e princípio do menor privilégio:

O pessoal do fornecedor deve estar sujeito a controlo de acesso baseado em funções (RBAC), revisões periódicas de acesso e aplicação do princípio do menor privilégio.

Da secção “Requisitos de implementação da política”, cláusula 6.3.1 da política.

Se o acesso de fornecedores puder alcançar PII, pertence ao PIMS. Deve constar dos controlos contratuais, aprovações de acesso, grupos IAM, âmbito de registo de eventos, registos de revisão, registos de saída, procedimentos operacionais de resposta a incidentes e evidência de auditoria.

Acesso a PII na nuvem: responsabilidade partilhada não é responsabilização partilhada

A governação do acesso a PII na nuvem é uma área em que as organizações frequentemente sobrestimam o prestador e subestimam as suas próprias responsabilidades. O prestador de serviços na nuvem pode proteger a infraestrutura, mas o cliente continua a governar identidades, funções, configuração do ambiente, acesso para suporte, logs, definições de cifragem, permissões de exportação e preparação para resposta a incidentes.

O Zenith Blueprint, na fase de controlos em ação, etapa 23, afirma isto de forma direta na sua orientação sobre serviços na nuvem:

Os prestadores de serviços na nuvem protegem a infraestrutura, mas a sua organização continua responsável pelos seus dados, pelas suas configurações, pelas suas políticas de acesso e pela sua preparação para resposta a incidentes.

Também alerta:

Na nuvem, a visibilidade é parcial, salvo se for concebida deliberadamente. É necessário configurar o registo em logs, aplicar cifragem, definir funções de identidade e monitorizar atividade através de ferramentas nativas ou integrações de terceiros. Isso não é uma tarefa de infraestrutura; é um requisito do SGSI.

A Política de Utilização da Nuvem da Clarysec transforma isto num requisito empresarial de acesso:

Todos os serviços na nuvem devem aplicar controlo de acesso baseado em identidade alinhado com o princípio do menor privilégio.

Da secção “Requisitos de implementação da política”, cláusula 6.2.1 da política.

Para organizações que atuam como subcontratantes em ambientes na nuvem, a Política de Subcontratante de PII na Nuvem da Clarysec define uma obrigação de revisão PIMS mais específica:

[Subcontratante] O Responsável de Segurança da Informação DEVE rever o acesso privilegiado na nuvem, o acesso para suporte, o acesso a PII de clientes e a cobertura de logs no REG12 pelo menos trimestralmente.

Da secção “4.2 Configuração na nuvem, isolamento entre ambientes de cliente, acesso e registo em logs”, cláusula 4.2.4 da política.

Essa cláusula é especialmente relevante para empresas SaaS, plataformas alojadas na nuvem, serviços de dados geridos e subcontratantes B2B.

A governação do acesso a PII na nuvem não está completa enquanto logs nativos da nuvem, políticas IAM, contas de serviço, funções privilegiadas, ferramentas de suporte ao cliente, chaves de API e funções de exportação de dados não forem revistos em conjunto.

Registo de eventos e monitorização: a memória da governação de PII

Um programa de controlo de acesso PIMS sem logs é uma promessa sem memória.

A Política de segurança e controlo de acesso a PII exige a definição do âmbito de registo de eventos antes da utilização em produção ou de uma alteração material:

[Ambos] O Proprietário do sistema / Responsável pela Aplicação DEVE definir no REG12 o âmbito de registo em logs de PII para eventos de autenticação, eventos de acesso, ações privilegiadas, atividade de exportação de PII e alterações materiais de configuração antes da utilização em produção ou de uma alteração material.

Da secção “4.6 Registo em logs e monitorização”, cláusula 4.6.1 da política.

A Política de registo de eventos e monitorização - PME torna explícito o conteúdo dos logs de acesso:

Logs de acesso: acesso a ficheiros (especialmente dados sensíveis ou pessoais), alterações de permissões, utilização de recursos partilhados

Da secção “Requisitos de governação”, cláusula 5.4.3 da política.

A Política de registo de eventos e monitorização empresarial centra-se na utilidade para auditoria:

O Registo de Trilho de Auditoria do SGSI deve registar a disponibilidade de dados de logs para auditorias, investigações e revisões regulatórias.

Da secção “Requisitos de governação”, cláusula 5.4 da política.

Isto é crítico porque a evidência de privacidade tem frequentemente de responder a perguntas baseadas em eventos:

• Quem acedeu à PII?
• O acesso estava autorizado?
• O acesso estava associado a um ticket de suporte, pedido jurídico, tarefa operacional ou instrução do cliente?
• Os dados foram exportados, copiados, alterados ou eliminados?
• Foi utilizado acesso privilegiado?
• As permissões foram alteradas antes ou depois do acesso?
• A atividade indicava um incidente de segurança ou uma violação de dados pessoais?

Os logs não servem apenas o SOC. São evidência PIMS, evidência de garantia para clientes, evidência de garantia de subcontratantes e evidência de resposta a incidentes.

Mapeamento de conformidade transversal: um modelo de acesso, várias lentes

Uma fragilidade nas revisões de acesso a PII nunca é apenas uma constatação. Pode tornar-se um problema de responsabilização no RGPD da UE, uma fragilidade do PIMS ISO/IEC 27701:2025, uma não conformidade ISO/IEC 27001:2022, uma falha de governação NIS2, uma preocupação de resiliência DORA, uma lacuna de governação NIST CSF 2.0 ou uma questão de maturidade de processo COBIT 2019.

Um mapeamento de controlos mais detalhado mostra como um único processo de governação do acesso a PII apoia múltiplos requisitos:

O valor do Zenith Controls é permitir que as equipas mapeiem estas lentes para a mesma evidência de controlo, em vez de manterem silos de conformidade separados.

Execute um exercício de 45 minutos sobre evidência de acesso a PII

Uma forma útil de testar a preparação é escolher um sistema de alto impacto, como uma plataforma de suporte ao cliente, sistema de Recursos Humanos, portal de pagamentos, portal de pacientes, data lake ou base de dados de produção SaaS, e executar um exercício focado de evidência.

Etapa 1: Definir o contexto de tratamento de PII

Registe no REG12:

• Nome e proprietário do sistema
• Categorias de PII
• Categorias de titulares dos dados
• Papel de responsável pelo tratamento ou de subcontratante
• Finalidade do tratamento
• Indicador de PII sensível ou de alto impacto
• Dependências de serviços na nuvem, fornecedores e subcontratantes subsequentes

Se o sistema envolver um subcontratante, verifique os campos de controlo contratual do REG08 utilizando a Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros. A aprovação deve cobrir âmbito do tratamento, duração, finalidade, categorias de PII, categorias de titulares dos dados, confidencialidade, segurança, autorização de subcontratantes subsequentes, assistência, auditoria ou garantia, devolução, eliminação e cessação.

Etapa 2: Extrair a lista de acessos

Exporte todos os utilizadores, grupos, funções privilegiadas, contas de serviço, funções de suporte, contas de emergência, chaves de API e contas de fornecedores. Compare cada autorização com as funções aprovadas.

Etapa 3: Confirmar o menor privilégio e o alinhamento com a finalidade

Use a linha de base da Política de segurança e controlo de acesso a PII: o acesso deve ser restringido a funções aprovadas e utilizadores autorizados registados ou rastreáveis no REG02 ou no REG12 antes da ativação. Se um utilizador não puder ser rastreado até à função, finalidade e aprovação, a constatação não é “documentação em falta”. A constatação é “acesso a PII não demonstravelmente autorizado”.

Etapa 4: Verificar o âmbito de registo de eventos

Confirme que os logs capturam autenticação, eventos de acesso, ações privilegiadas, atividade de exportação de PII e alterações materiais de configuração. Depois confirme onde os logs são armazenados, durante quanto tempo são retidos, quem pode aceder-lhes e se estão registados no Registo de Trilho de Auditoria do SGSI para auditorias, investigações e revisões regulatórias.

Etapa 5: Fechar o ciclo

Para cada exceção, registe o proprietário do risco, a ação imediata de contenção, a remediação permanente, a data-alvo, a evidência necessária, a decisão de risco residual e se é necessária avaliação da violação de dados pessoais.

Este exercício revela normalmente a maturidade real da governação do acesso a PII. As organizações fortes respondem rapidamente. As organizações frágeis descobrem que a política de privacidade, a configuração de IAM, os contratos com subcontratantes, o registo de eventos na nuvem e a evidência de auditoria estão desligados.

Constatações de auditoria comuns na governação do acesso a PII

A maioria das constatações é previsível. Surgem quando privacidade, segurança, jurídico, TI e fornecedores controlam cada um parte da história, mas ninguém detém a propriedade do ciclo de vida completo do acesso a PII.

As constatações comuns incluem:

• Os sistemas com PII não estão integralmente listados no inventário do PIMS.
• As funções de acesso estão definidas tecnicamente, mas não mapeadas para finalidades do tratamento.
• A PII sensível está acessível através de grupos operacionais demasiado amplos.
• As revisões trimestrais abrangem trabalhadores, mas não contas de serviço, chaves de API ou utilizadores de fornecedores.
• O acesso de suporte na nuvem é possível, mas não é revisto como acesso a PII.
• Existem logs, mas não demonstram acesso a PII, exportação ou atividade privilegiada.
• Os contratos com subcontratantes incluem cláusulas genéricas de confidencialidade, mas não controlos específicos de acesso, auditoria, subcontratantes subsequentes, devolução, eliminação ou cessação.
• Antigos trabalhadores ou contratados mantêm acesso através de grupos partilhados ou tokens não geridos.
• O acesso ao data warehouse é mais amplo do que o acesso à aplicação de origem.
• Existem contas de emergência sem revisão pós-utilização.
• A personificação indevida no suporte ao cliente não é registada com contexto de ticket.
• A Declaração de Aplicabilidade inclui controlos de acesso, mas a evidência não mostra implementação específica para PII.

Cada uma destas constatações pode tornar-se um problema de responsabilização no RGPD da UE, uma questão de garantia para clientes, uma fragilidade de governação NIS2 ou DORA, ou uma não conformidade ISO/IEC 27001:2022, consoante o âmbito.

Como se apresenta um bom modelo

Um modelo operacional maduro não depende de limpezas trimestrais heroicas. Integra a governação do acesso a PII nas operações normais.

Primeiro, a organização conhece os seus dados. Sabe onde existe PII, por que motivo é tratada, que papel PIMS se aplica e que sistemas, fornecedores, serviços na nuvem, logs, cópias de segurança e exportações estão no âmbito.

Segundo, o acesso é baseado em funções e alinhado com a finalidade. As permissões são definidas por funções aprovadas, necessidade de negócio documentada, finalidade do tratamento e princípio do menor privilégio.

Terceiro, os controlos são aplicados tecnicamente. IAM, RBAC, Gestão de Acessos Privilegiados (PAM), MFA, acesso condicional, controlos de ambiente, cifragem e segregação de ambientes aplicam as expectativas da política.

Quarto, a monitorização é deliberada. A organização consegue reconstruir autenticação, acesso, exportação, ação privilegiada, acesso para suporte e alterações de configuração que afetem PII.

Quinto, as revisões são baseadas no risco e documentadas. A PII de alto impacto recebe pelo menos revisão trimestral. O acesso de fornecedores e de suporte na nuvem é incluído. As exceções são acompanhadas até ao encerramento.

Sexto, a evidência é reutilizável. Os mesmos registos suportam a responsabilização no RGPD da UE, a operação do PIMS ISO/IEC 27701:2025, o tratamento de riscos ISO/IEC 27001:2022, as medidas de gestão de riscos NIS2, a governação do risco das TIC no DORA, os resultados GOVERN do NIST CSF 2.0 e a garantia de gestão COBIT 2019.

Esta é a diferença entre controlo de acesso como definição e governação de acessos como sistema.

Transforme o acesso a PII em evidência pronta para auditoria

Se a sua próxima auditoria, revisão de cliente ou pedido de esclarecimento regulamentar começasse amanhã com “mostre-me quem pode aceder a PII”, a sua equipa produziria evidência em minutos ou começaria a reconciliar folhas de cálculo?

A Clarysec pode ajudá-lo a fechar essa lacuna.

Comece pela Política de segurança e controlo de acesso a PII, alinhe obrigações de subcontratantes e na nuvem através da Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros e da Política de Subcontratante de PII na Nuvem, depois utilize o Zenith Blueprint: roteiro de 30 etapas para auditores para implementar controlos na sequência correta. Por fim, utilize o Zenith Controls: guia de conformidade transversal para mapear a evidência de acesso a PII em ISO/IEC 27701:2025, RGPD da UE, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

O próximo passo prático mais rápido é simples: selecione um sistema de PII de alto impacto, preencha o REG12, exporte a lista de acessos, verifique o âmbito de registo de eventos e execute uma revisão ao estilo trimestral. Numa única sessão, saberá se a sua governação do acesso a PII está pronta para auditoria ou apenas pronta em termos de política.