Resumo rápido. Na ISO/IEC 27001:2022, a gestão de identidade e acesso está concentrada em quatro controles do Anexo A: A.5.15 (controle de acesso), A.5.16 (gestão de identidade), A.5.17 (informações de autenticação) e A.5.18 (direitos de acesso). Eles se completam com controles tecnológicos, como A.8.2 (acesso privilegiado) e A.8.5 (autenticação segura). Na auditoria, o que pesa é a evidência de que o controle funciona todos os dias: matriz de acesso, registros de entrada e saída, revisões periódicas com decisão registrada e retirada de acessos no desligamento.
A ISO/IEC 27001 é o padrão internacional para sistemas de gestão de segurança da informação (SGSI) e aparece com frequência em processos de compra de clientes corporativos. Dentro dela, os controles de identidade e acesso costumam concentrar achados de auditoria, porque dependem de processos que mudam todo dia: gente entrando, mudando de área e saindo. Neste guia, você vê o que cada controle pede, como implementar e quais evidências separar para a certificação.
O que é o Anexo A da ISO 27001?
A ISO 27001 tem duas partes. O corpo da norma traz os requisitos do SGSI (contexto, liderança, análise de riscos, melhoria contínua). O Anexo A traz uma lista de controles de referência. Na versão 2022, são 93 controles em quatro temas: organizacionais (5), de pessoas (6), físicos (7) e tecnológicos (8).
Dois pontos evitam confusão:
- A empresa decide quais controles aplica. A decisão sai da análise de riscos e fica registrada na Declaração de Aplicabilidade (SoA), com a justificativa para incluir ou excluir cada controle. Na prática, os controles de identidade se aplicam a quase toda empresa, porque toda empresa precisa decidir quem acessa o quê.
- A 27001 diz o quê; a 27002 sugere o como. O detalhamento de cada controle (o que uma boa implementação costuma ter) está na ISO/IEC 27002:2022, que é um guia, não um requisito. As listas abaixo seguem essa lógica: são o que o auditor costuma esperar ver, não um texto obrigatório.
Se a sua empresa ainda tem certificado na versão de 2013: pelas regras do IAF (documento MD 26), a transição para a 2022 tinha de terminar até 31 de outubro de 2025. Depois dessa data, certificados na versão antiga expiram ou são retirados.
Os controles de identidade e acesso em uma tabela
| Controle (2022) | Equivalente na 2013 | O que pede, em resumo | Evidência típica na auditoria |
|---|---|---|---|
| A.5.15 Controle de acesso | A.9.1.1 e A.9.1.2 | Regras de acesso definidas pelo negócio e pela segurança, com base em “precisa saber” e “precisa usar” | Política aprovada e matriz de acesso por função |
| A.5.16 Gestão de identidade | A.9.2.1 | Cada identidade é única, tem dono e é gerida da criação à desativação | Inventário de identidades, inclusive contas de serviço, e registros de criação e desativação |
| A.5.17 Informações de autenticação | A.9.2.4, A.9.3.1 e A.9.4.3 | Entrega, guarda e troca de senhas e outros segredos sob controle | Política de senhas e processo de entrega e redefinição de credenciais |
| A.5.18 Direitos de acesso | A.9.2.2, A.9.2.5 e A.9.2.6 | Acesso concedido com aprovação, revisado de tempos em tempos e retirado quando a pessoa sai ou muda de função | Pedidos aprovados, revisões periódicas com decisão registrada e retiradas no desligamento |
| A.8.2 Acesso privilegiado | A.9.2.3 | Acesso privilegiado restrito ao mínimo, aprovado, com prazo de expiração e revisado periodicamente | Lista de contas privilegiadas com dono e data da última revisão |
| A.8.5 Autenticação segura | A.9.4.2 | Autenticação proporcional ao risco, como MFA em acessos críticos | Configuração de MFA no provedor de identidade |
Também conversam com esses controles o A.5.3 (segregação de funções, antes A.6.1.2) e o A.8.3 (restrição de acesso à informação, antes A.9.4.1). Na versão de 2013, quase todos ficavam no capítulo A.9.
A.5.15: controle de acesso
O A.5.15 pede que a empresa defina e aplique regras de acesso físico e lógico com base nos requisitos do negócio e de segurança. É o controle que diz “quem pode ter acesso ao quê, e por quê”. Os princípios de referência são o “precisa saber” (need-to-know) e o “precisa usar” (need-to-use), que na prática são o menor privilégio.
Como implementar
- Escreva a política de controle de acesso e aprove com a liderança.
- Monte a matriz de acesso: para cada função, quais sistemas e quais perfis ela recebe por padrão.
- Defina o caminho das exceções: quem aprova acesso fora do padrão e onde isso fica registrado.
- Cubra todos os tipos de sistema, inclusive SaaS contratado por áreas fora de TI.
O erro mais comum é ter a política sem a matriz. O documento existe, mas não há como comparar o que está escrito com quem tem acesso de verdade. Se a sua empresa usa papéis, veja o que é RBAC.
A.5.16: gestão de identidade
O A.5.16 pede que o ciclo de vida completo das identidades seja gerido. Cada identidade deve ser única e ligada a uma pessoa ou, no caso de contas de serviço e integrações, a um responsável. Identidades compartilhadas só com justificativa e aprovação. Quando a identidade não é mais necessária, ela é desativada ou removida.
Os três momentos em que mais aparecem falhas:
- Entrada: conta criada sem registro de quem pediu e quem aprovou.
- Mudança de área: acessos novos somados aos antigos, o acúmulo de privilégios.
- Saída: contas que continuam ativas depois do desligamento, sobretudo em aplicativos fora do SSO. Veja as exigências no offboarding.
A norma não exige automação. Mas, sem ela, a evidência costuma ser montada às pressas na semana da auditoria. Ligar o ciclo de vida ao sistema de RH faz com que cada entrada, mudança e saída gere o registro sozinha. Mais em gestão do ciclo de vida do usuário.
A.5.17: informações de autenticação
O A.5.17 trata das credenciais em si: como senhas, tokens e outros segredos são entregues, guardados, trocados e revogados. Exemplos do que se espera: senha inicial temporária com troca obrigatória no primeiro acesso, canal seguro para entregar credenciais, orientação aos usuários para não compartilhar senhas e um gerenciador de senhas para contas que não passam pelo SSO.
O MFA costuma ser associado a este controle, mas o lugar dele no Anexo A é o A.8.5 (autenticação segura), que pede autenticação proporcional à sensibilidade do acesso. Em boa parte das empresas, a maior parte desses dois controles é atendida no provedor de identidade, como o Microsoft Entra ID ou o Google Workspace. Para escolher o método, veja os tipos de autenticação.
A.5.18: direitos de acesso
O A.5.18 cobre a vida de cada permissão: como ela é concedida, revisada, ajustada e retirada. Costuma ser um dos controles que mais geram pedido de evidência na auditoria, porque o auditor costuma pegar uma amostra de pessoas e conferir cada etapa.
- Concessão: pedido e aprovação do dono do sistema ou do gestor, de acordo com a política do A.5.15.
- Revisão periódica: gestores confirmam ou retiram os acessos das suas equipes em ciclos definidos. Acessos privilegiados costumam ser revisados com mais frequência (veja o A.8.2).
- Ajuste na mudança de função: o que não serve mais para a função nova sai.
- Retirada: no desligamento ou no fim de contrato de terceiros, todos os acessos são retirados, com registro de quando isso aconteceu.
O ponto fraco da revisão é a qualidade. Quando o gestor recebe uma lista longa e sem contexto, ele aprova tudo. Contexto ajuda: último uso, mudança recente de área, acesso fora do padrão da função. Veja 5 dicas para revisão de acessos.
Checklist de evidências para a auditoria
- Política de controle de acesso, com versão e data de aprovação.
- Matriz de acesso por função e registro das exceções aprovadas.
- Inventário de identidades ativas com responsável, incluindo contas de serviço e de terceiros.
- Registros de entrada, mudança e saída de pessoas, com data de cada concessão e retirada.
- Relatórios das revisões periódicas: quem revisou, quando, o que foi mantido e o que foi retirado.
- Lista de contas privilegiadas com dono e data da última revisão.
- Configuração de MFA e política de senhas no provedor de identidade.
Um teste rápido: escolha cinco pessoas que saíram nos últimos três meses e confira se ainda existe alguma conta ativa delas, em qualquer sistema. Se aparecer, o auditor também vai achar.
Por que implementar um controle sem os outros não fecha a conta
- Política (A.5.15) sem ciclo de vida (A.5.16): as regras existem, mas ninguém garante que valem na entrada e na saída.
- Ciclo de vida (A.5.16) sem revisão (A.5.18): a concessão é controlada, mas as permissões se acumulam com o tempo.
- Revisão (A.5.18) sem autenticação forte (A.5.17 e A.8.5): o acesso certo pode ser usado pela pessoa errada.
Na prática, autenticação (quem é você) fica no provedor de identidade, e governança (o que você deveria acessar e por quanto tempo) é o papel da IGA. Entenda a diferença em IAM, IGA, RBAC e PAM.
Como a Niuco ajuda nos controles de identidade
A Niuco não substitui o seu provedor de identidade: a autenticação e o MFA continuam no Microsoft Entra ID ou no Google Workspace. Ela trabalha junto com eles na parte de governança:
- A.5.15 e A.5.16: inventário de identidades e acessos, inclusive terceiros e contas de serviço; políticas por papel e departamento; criação, alteração e retirada de acessos a partir do RH.
- A.5.18 e A.8.2: campanhas de revisão de acessos com o registro de cada decisão, acessos temporários com expiração e revisão, expiração e revogação de acessos privilegiados. A autenticação e o registro das sessões privilegiadas continuam no provedor de identidade ou na ferramenta de PAM.
- Evidência: trilha de cada concessão, revisão e retirada, com exportação para a auditoria.
Trabalha em instituição financeira? Veja também o guia de compliance bancário. Se a sua empresa também passa por SOC 2, veja SOC 2 e controle de acesso.
Perguntas frequentes sobre ISO 27001 e controle de acesso
Quais controles da ISO 27001 tratam de identidade e acesso?
Os principais são A.5.15 (controle de acesso), A.5.16 (gestão de identidade), A.5.17 (informações de autenticação) e A.5.18 (direitos de acesso), da ISO/IEC 27001:2022. Eles se completam com A.8.2 (acesso privilegiado), A.8.3 (restrição de acesso à informação), A.8.5 (autenticação segura) e A.5.3 (segregação de funções).
A ISO 27001 exige MFA?
Não de forma explícita. O A.8.5 pede autenticação segura, proporcional ao risco, e deixa o método a critério da empresa. Na prática, é comum o auditor perguntar por MFA em acessos remotos, administrativos e a sistemas críticos.
Com que frequência revisar os acessos?
A norma não fixa um prazo. A empresa define a frequência pelo risco e cumpre o que definiu. Um ritmo comum é trimestral para acessos privilegiados e sistemas críticos e semestral ou anual para os demais.
Onde fica o princípio do menor privilégio na ISO 27001?
No A.5.15, pelos princípios de “precisa saber” e “precisa usar”, e no A.8.2, para acessos privilegiados. A revisão periódica do A.5.18 é o que mantém o menor privilégio ao longo do tempo.
Ainda vale o certificado da ISO 27001:2013?
Não. Pelas regras do IAF, a transição para a versão 2022 tinha de terminar até 31 de outubro de 2025. Na versão de 2013, os controles equivalentes ficavam no capítulo A.9 (controle de acesso).
Qual a diferença entre ISO 27001 e SOC 2 no controle de acesso?
A ISO 27001 certifica um sistema de gestão: a empresa mostra que identifica riscos e mantém controles. O SOC 2 é um relatório de auditor sobre controles ligados aos Trust Services Criteria do AICPA. No tipo 2, o auditor testa se os controles funcionaram durante um período. Nos dois, revisão periódica de acessos e retirada no desligamento aparecem entre as evidências mais pedidas.
Sobre a Niuco. A Niuco governa quem deve ter acesso aos sistemas da empresa e automatiza a criação, a alteração e a retirada de acessos, junto com o Microsoft Entra ID e o Google Workspace. Conheça a governança de identidade da Niuco ou solicite uma demonstração.
Conteúdo informativo, sem valor de parecer jurídico ou de auditoria. ISO e IEC são marcas das respectivas organizações; demais marcas citadas pertencem aos respectivos donos.
