Revisões de acesso de usuários que satisfazem qualquer auditor
As revisões de acesso estão entre os controles mais reprovados em auditorias, raramente porque ninguém as realizou e geralmente porque ninguém consegue comprovar que foram feitas corretamente.
Esta publicação abrange as 11 normas que a ControlMapping tinha mapeado quando foi escrita. Desde então, foram acrescentadas DORA, CPS 234, Cyber Essentials em 2026-10-27; as respetivas páginas e a matriz de cobertura já as incluem.
Poucos controles são tão universais ou tão frequentemente reprovados quanto as revisões de acesso de usuários. Todo framework espera que alguém verifique, periodicamente, se cada pessoa ainda precisa do acesso que possui. A maioria das organizações realiza a revisão. Bem menos conseguem demonstrar a um auditor que ela foi completa, independente e que gerou ações.
O que os frameworks exigem
| Framework | Controle de acesso | Vínculo |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01PR.AA-05 | Definição do tópico |
| ISO 27001 | A.5.15A.5.16A.5.18A.8.3 | Correspondência |
| CIS v8.1 | CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5 | Correspondência |
| SOC 2 | CC6.1CC6.2CC6.3 | Editorial |
| PCI DSS | 7.2.17.2.27.2.48.2.1 | Correspondência |
| CMMC | AC.L2-3.1.1AC.L2-3.1.2 | Correspondência |
| 800-53 | AC-2AC-3 | Correspondência |
| HIPAA | §164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d) | Correspondência |
| GDPR | Art.25(2)Art.32(1)(b) | Editorial |
| NIS2 | 11.111.211.5 | Correspondência |
| Essential Eight | — | Sem mapeamento em nossos dados |
Detalhe completo e o motivo de cada ligação: Controle de acesso em todos os frameworks →
PCI DSS é o único com uma frequência fixa: todas as contas de usuário e privilégios devem ser revisados pelo menos a cada seis meses (7.2.4), assim como as contas de aplicações e sistemas (7.2.5.1). Auditores do SOC 2 testam se o acesso é autorizado, modificado e removido adequadamente (CC6.2, CC6.3) e procuram revisões periódicas como evidência. A ISO 27001 exige que os direitos de acesso sejam revisados em intervalos regulares (A.5.18). A HIPAA exige gestão do acesso a informações e revisão de atividades (§164.308(a)(4)). O CMMC espera que o acesso seja limitado a usuários e funções autorizados (AC.L2-3.1.1, 3.1.2) e ao princípio do menor privilégio.
Uma revisão que passa na auditoria
- População completa. Extraia a lista de usuários diretamente do sistema (uma exportação, não uma planilha mantida por alguém), incluindo contas de serviço e contas compartilhadas.
- Revisor adequado. O proprietário do sistema ou dos dados, ou o gestor de cada usuário, e não o administrador que concedeu o acesso.
- Contexto suficiente. Mostre aos revisores o papel e o nível de acesso de cada usuário, para que “aprovar” seja uma decisão informada.
- Uma decisão por conta. Manter, alterar ou remover, com o nome e a data do revisor.
- Alterações efetivamente feitas. Abra chamados para as remoções e guarde comprovantes de que foram concluídas.
- Evidências preservadas. A exportação, as decisões, os chamados e a aprovação, armazenados juntos.
Frequência
Use os seis meses do PCI DSS como base para todos os sistemas no escopo e revise o acesso privilegiado trimestralmente. Se você possui um SOC 2 Tipo II, certifique-se de que pelo menos uma revisão (idealmente duas) ocorra em cada período de observação.
O que os auditores encontram
- Aprovação automática: todas as contas aprovadas, em minutos, por alguém que não tinha como saber.
- Populações incompletas: a revisão cobriu a aplicação, mas não o banco de dados, ou contas humanas, mas não contas de serviço.
- Autorrevisão: administradores aprovando o próprio acesso.
- Remoções não concluídas: a revisão determinou a remoção, mas a conta continua existindo meses depois.
- Desligados identificados pela revisão: sinal de que o processo de desligamento está falhando, o que os auditores testarão separadamente.
Principais conclusões
- As revisões reprovam em auditorias por falta de evidências, não por falta de esforço: populações incompletas, autorrevisão e remoções nunca concluídas.
- Use exportação do sistema, o revisor adequado, uma decisão por conta e comprovação das alterações.
- Revisões semestrais (regra do PCI DSS) e trimestrais para acesso privilegiado atendem a todos os frameworks.
- Limite o escopo aos sistemas que importam e automatize a parte mecânica.
Tornando o processo sustentável
Automatize a exportação e os lembretes, revise por sistema em vez de por usuário e limite o escopo aos sistemas que importam: produção, dados de clientes, ferramentas privilegiadas e qualquer item no escopo de um framework. Uma revisão menor e bem documentada é melhor do que uma extensa que está sempre atrasada.
Consulte as páginas de Controle de Acesso e Acesso Privilegiado de tópico para cada requisito com sua fonte, e nosso artigo sobre reutilização de evidências entre SOC 2, ISO 27001 e PCI DSS.
Perguntas
Com que frequência o acesso de usuários deve ser revisado?
O PCI DSS exige que contas de usuário e privilégios de acesso sejam revisados pelo menos a cada seis meses (7.2.4). A maioria dos outros frameworks exige revisão periódica em uma frequência que você define; trimestral para acesso privilegiado e semestral para os demais é uma base comum.
Quem deve realizar uma revisão de acesso?
O proprietário do sistema ou dos dados, ou o gestor do usuário, e não o administrador que concedeu o acesso. Os auditores buscam independência e um revisor informado.
As contas de serviço precisam de revisões de acesso?
Sim. Os auditores cada vez mais incluem contas de serviço, compartilhadas e de API na população de revisão; o PCI DSS exige explicitamente a revisão periódica de contas de aplicações e sistemas (7.2.5.1).
Dados atualizados em 2026-10-27: os números deste artigo são calculados a partir da correspondência atual e são atualizados quando ela muda. Correspondência um crosswalk publicado (NIST, ENISA, CIS, PCI SSC) estabelece a correspondência · Editorial Juízo editorial da ControlMapping onde não existe crosswalk; o motivo é indicado · compartilha apenas um resultado do CSF 2.0: vale verificar, mas não é um mapeamento · Sem mapeamento em nossos dados nada mapeado em nossos dados; muitas vezes é trabalho novo, mas verifique as notas de cobertura. Não é aconselhamento de conformidade.
Publicações relacionadas
Análise · 2026-10-27APRA CPS 234 e ISO 27001: o que seu ISMS cobre e o que a APRA acrescentaUm ISMS ISO 27001 cobre quase todos os parágrafos da CPS 234 da APRA, mas a APRA acrescenta deveres do Conselho, garantia de terceiros e prazos rigorosos de notificação.
Análise · 2026-10-13Requisitos de MFA comparados em 11 frameworks de segurançaQuais frameworks exigem MFA, para quem e com que rigor: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 e HIPAA, comparados lado a lado.
Análise · 2026-09-29Regra de Segurança da HIPAA sob a ótica do NIST CSF 2.0Um programa NIST CSF 2.0 se mapeia com quase todos os requisitos da Regra de Segurança da HIPAA. O que se aproveita, os dois que não se aproveitam e o que o CSF acrescenta além da HIPAA.