Os controles ISO 27001 que mais falham em auditorias reais — e por quê

Conversei com três auditores líderes certificados de ISO 27001 no último ano. Comparei minhas observações em auditorias de clientes. O padrão é claro: certos controles aparecem repetidamente como não-conformidade, ano após ano, em empresas dos mais variados setores.

O motivo nem sempre é o que você imagina. Não é falta de política. Não é falta de tecnologia. É falta de evidência de execução contínua.

Deixa eu te mostrar os três grupos de controle que mais reprovam — e o que fazer pra não cair.

Controle A.9: Gestão de acesso (o mais reprovado)

Os controles de gestão de identidade e acesso (A.5.15 a A.5.18 na versão 2022, antiga seção A.9) são disparados o grupo com mais ressalvas. Em 8 de cada 10 auditorias eu vejo pelo menos uma não-conformidade aqui.

Os erros típicos:

1. Usuários ativos de ex-funcionários

O auditor pede o relatório de demissões dos últimos 12 meses. Cruza com a lista de usuários ativos no AD, nos sistemas principais, no email. Sempre acha pelo menos 2-3 usuários que deveriam estar desativados.

Como evitar: processo formal de offboarding com checklist de TI. Última atividade do funcionário no último dia: revogação automática de acessos. Auditoria mensal de cross-check entre RH e TI.

2. Revisão periódica de acessos não documentada

A política diz que acessos são revisados trimestralmente. O auditor pede a evidência da última revisão. Não tem. Ou tem mas é genérica.

Como evitar: planilha datada por trimestre com cada usuário, cada sistema, aprovação ou remoção do gestor. Assinatura digital. Arquivo.

3. Acesso privilegiado sem MFA

Usuário com perfil administrador no servidor mas sem segundo fator de autenticação. Falha técnica simples mas frequente.

Como evitar: política clara — todo acesso privilegiado exige MFA. Verificação técnica periódica. Sem exceções não documentadas.

O erro de focar so em acesso a sistemas internos

A maioria das empresas controla bem acesso a sistemas internos (ERP, AD, email). Esquece de SaaS contratados — e e exatamente la que o auditor vai descobrir problemas.

Tipico: empresa tem 30 SaaS contratados. Cada um tem admin proprio. Em 2 ou 3 deles, ha ex-funcionarios ativos. Em outros 5, o admin saiu e ninguem revisou quem assumiu a conta administrativa.

Como mitigar: inventario formal de todos os SaaS, com responsavel administrativo nomeado, revisao trimestral incluindo essas plataformas, integracao com SSO sempre que possivel.

O processo trimestral de revisao bem feito

Revisão trimestral de acessos só vale se for genuína. O ritual que funciona:

• TI extrai a lista de usuários e perfis por gestor de área
• Gestor recebe planilha personalizada com prazo de 10 dias úteis
• Para cada usuário, decisão obrigatória: manter, ajustar, remover
• Devolução assinada pelo gestor (digital ou física)
• TI executa as remoções e ajustes em 5 dias
• Auditoria interna amostra 10% das revisões para validar consistência

Empresa com esse ritual passa limpa. Empresa que faz "aprova tudo" por email não.

Controle A.12: Operações de TI e o problema dos logs

Os controles de operações (A.8.15 a A.8.17 na versão 2022) — logging, monitoramento, sincronização de relógio — também aparecem muito.

O paradoxo: a empresa tem SIEM, tem logging consolidado, tem dashboard bonito. Mas o auditor pega 5 eventos críticos do ano e pergunta como foram tratados. E aí descobre que ninguém revisou os logs sistematicamente.

Os erros típicos:

• Logs coletados mas sem análise periódica
• Alertas críticos sem registro de tratamento
• Servidores fora do escopo de logging (geralmente legacy)
• Retenção de log inferior ao exigido pela política
• Relógios dessincronizados (NTP não configurado em alguns hosts)

Log que ninguém lê é como câmera de segurança desligada: dá falsa impressão de proteção sem proteger de verdade.

Como evitar: definir os eventos críticos (não mais de 15-20 tipos), responsável formal pela revisão, frequência de revisão clara (diária ou semanal), registro do tratamento. Periodicamente fazer drill — simular um evento e verificar se foi tratado conforme o procedimento.

Por que sincronizacao de relogio importa mais do que parece

Esse e um detalhe que pega muita empresa. Servidores com relogio dessincronizado entre si tornam impossivel correlacionar eventos. Auditor pede o timeline de um incidente, voce mostra logs com timestamps inconsistentes — vira ressalva.

Solucao: NTP configurado em todos os hosts, com servidor confiavel (idealmente interno), e monitoramento de desvio. Investimento minimo, mas tipicamente esquecido.

Controle A.16: Gestão de incidentes que ninguém documenta

Quase toda empresa tem incidentes de segurança ao longo do ano. Pequenos, médios, grandes. O problema: a maioria não documenta como esses incidentes foram tratados.

O auditor vai pedir o registro de incidentes do último ano. Vai sortear 3-5 incidentes e pedir o relatório completo: detecção, classificação, contenção, erradicação, recuperação, lições aprendidas.

Se você não tem esses relatórios, é não-conformidade. Pior: se você diz que não teve incidentes nenhum no ano, o auditor desconfia (com razão). Empresa séria tem incidentes pequenos o tempo todo — phishing recebido, tentativa de força bruta, vazamento de credencial em listas públicas, falha de equipamento crítico.

O que conta como incidente pra ISO 27001? Qualquer evento que afete (ou possa afetar) confidencialidade, integridade ou disponibilidade. A barra é baixa de propósito — pra você documentar e aprender.

O que conta como incidente menor

Incidente menor pra ISO 27001 inclui:

• Phishing direcionado recebido por funcionario (mesmo que ele nao tenha caido)
• Tentativa de acesso indevido bloqueada pelo firewall
• Senha vazada em base publica (Have I Been Pwned)
• Falha de servidor critico fora do horario comercial
• Erro de configuracao detectado e corrigido
• Funcionario reportando suspeita (mesmo se for falso positivo)

Empresa madura registra dezenas desses por mes. Empresa imatura tem 2 ou 3 "incidentes" reportados no ano todo, todos graves. Essa discrepancia denuncia.

Como evitar: registro centralizado de incidentes (mesmo que planilha). Classificação por gravidade. Relatório padronizado pros incidentes médios e altos. Reunião trimestral revisando os incidentes e tirando lições.

O que o auditor pergunta e a empresa não sabe responder

Tem perguntas que aparecem em quase toda auditoria. Se sua empresa não tem resposta pronta pra essas, vai sofrer.

• "Como vocês souberam que o último teste de backup funcionou?" — Quer ver evidência do teste, data, escopo, resultado
• "Quando foi a última revisão pela direção e quais foram os resultados?" — Quer ver ata, presentes, decisões tomadas
• "Qual foi o último treinamento de conscientização e quem participou?" — Quer ver lista de presença, conteúdo, avaliação
• "Como vocês avaliam riscos de fornecedores críticos?" — Quer ver matriz, frequência, critérios
• "Mostra um exemplo recente de mudança em produção e a aprovação formal correspondente." — Quer ver ticket, aprovador, evidência de teste

Empresa preparada responde cada uma dessas em menos de 5 minutos, com documento na mão. Empresa não preparada fica embaraçada e perde pontos.

O que e ouro pro auditor: a evidencia rastreavel em 30 segundos

O melhor que pode acontecer numa auditoria e isso: auditor faz uma pergunta, gestor abre o laptop, em menos de 30 segundos mostra a evidencia exata pedida.

Essa fluidez nao acontece por acaso. E resultado de:

• Indexacao centralizada de evidencias (intranet, SharePoint, Confluence)
• Padronizacao de nomenclatura (data + tipo + responsavel no nome do arquivo)
• Acesso rapido pelos donos dos processos
• Treinamento das pessoas que vao ser entrevistadas

Auditor sai com excelente impressao. E impressao vira tom do relatorio final.

Como revisar controles antes da auditoria

O que eu faço com clientes nas semanas finais antes da auditoria:

Simulação de auditoria. Sento com a equipe, faço o papel de auditor. Sorteio 10 controles aleatórios da Declaração de Aplicabilidade. Peço evidência de cada um. Se demoram mais de 10 minutos pra encontrar, o controle vai pra lista de risco.

Teste cruzado. Pego um controle e verifico em três níveis: política diz X, procedimento diz como executar X, evidência mostra que X foi feito. Se uma das três pontas falha, o controle não passa.

Entrevista com pessoas-chave. Converso com 5-8 funcionários sorteados de diferentes áreas. Pergunto sobre a política, sobre o que fazer em caso de incidente, sobre senhas, sobre uso de pendrive. Se as respostas variam muito, é sinal de que a comunicação da política não funcionou.

Esse processo geralmente revela entre 5 e 15 pontos a corrigir antes do auditor externo. Empresa que faz isso bem chega na auditoria de certificação relaxada. Empresa que pula essa etapa entra apostando.

Aposta em ISO 27001 raramente paga bem.

O risco da hubris no sprint final

Vejo dois padroes de quem chega na auditoria de certificacao: o time confiante e o time arrogante. Sao diferentes.

O time confiante preparou, simulou, refinou, sabe seus pontos fracos e tem plano pra eles. O time arrogante acha que esta pronto demais, nao simula, considera auditoria interna formalidade.

Resultado: time confiante passa com 2-4 nao-conformidades menores. Time arrogante leva 6-10, incluindo maiores.

Em ISO 27001, humildade no sprint final vale dinheiro. Quem se acha pronto, geralmente nao esta.

O controle mais falho: gestão de acessos

Em 6 entre 10 auditorias ISO 27001 que acompanhei, gestão de acessos foi o domínio com mais não-conformidades. Não é coincidência — é o controle que mais combina exposição alta com manutenção contínua exigente.

Os problemas que aparecem repetidamente: contas de ex-funcionários ainda ativas (encontrei recentemente 89 contas válidas de pessoas desligadas há mais de 6 meses); contas privilegiadas sem justificativa documentada; revisão periódica feita por email sem evidência de avaliação real; senhas compartilhadas entre técnicos para operação; ausência de MFA em sistemas críticos não-cloud; integração precária entre sistema de RH e provisionamento de acesso.

O que diferencia empresa que passa nesse domínio: processo formal de joiners/movers/leavers com uptime.com.br/" style="color:#1a365d;text-decoration:underline;font-weight:500;">SLA definido (24h pra revogação após desligamento); revisão trimestral presencial com gestor; MFA universal mesmo para sistemas legados (via solução de federação); identidade gerenciada centralmente; auditoria mensal automatizada com indicadores.

Investimento típico em gestão de acessos madura: R$ 200-500 mil em ferramentas (IAM, PAM) + 1-2 FTEs dedicados. Empresa que economiza aqui falha auditoria — e abre flanco real pra incidente.

O segundo controle mais falho: continuidade de negócio

O segundo domínio onde mais vejo falha é continuidade — política existe, plano existe, mas o teste não. Empresa documenta cenário, RTO, RPO, processo de ativação — e nunca testa de verdade.

Sintomas clássicos: backup que ninguém restaurou em 18 meses; plano de continuidade aprovado em 2021 e não revisado desde; site de DR contratado mas não testado; equipe de resposta a incidentes que nunca fez tabletop; comunicação de crise sem template pronto.

O que funciona: teste anual obrigatório de pelo menos um cenário completo, com avaliação real de RTO/RPO; tabletop exercises semestrais com gestores; restore de backup mensal em ambiente isolado para validar integridade; revisão anual da análise de impacto (BIA) com áreas de negócio.

Custo do programa de testes: 200-400 horas-pessoa/ano + custos de infraestrutura de DR. Sem isso, a continuidade documentada é teatro — e quando o incidente real acontece, a empresa descobre dolorosamente que o plano não funciona como imaginava.

O controle subestimado: gestão de fornecedores

O domínio que mais cresce em importância é a gestão de fornecedores. Em 2025, supply chain virou vetor principal de incidentes — a maioria dos vazamentos de grande escala passou por fornecedor terceirizado. A norma 2022 reforçou esse domínio explicitamente.

O que toda implementação séria precisa cobrir: inventário completo de fornecedores que processam ou acessam dados/sistemas críticos; classificação de risco por fornecedor; avaliação de segurança na contratação; cláusulas contratuais específicas (notificação de incidente, direito de auditoria, retenção e exclusão de dados); monitoramento periódico durante a vigência; processo formal de offboarding.

Os fornecedores mais críticos — provedores de cloud, processadores de pagamento, processadores de folha, integradores de TI — exigem due diligence detalhada. Os menores podem seguir processo simplificado, mas precisam ser inventariados.

Investimento: 200-400 horas iniciais para mapear e classificar a base de fornecedores + 80-160 horas/ano de monitoramento. Empresa que não faz isso descobre o problema quando o fornecedor é vazado — e responde pela cadeia inteira.