Requisitos da ISO 27001: as cláusulas 4 a 10 explicadas

Quem procura os requisitos da ISO 27001 costuma esbarrar em duas confusões. A primeira é achar que os requisitos são os controles do Anexo A — não são. A segunda é procurar uma lista de tecnologias obrigatórias — que também não existe.

Os requisitos auditáveis da norma estão nas cláusulas 4 a 10. As cláusulas 1, 2 e 3 (escopo, referências normativas e termos) são introdutórias e não geram não conformidade. Este artigo percorre cláusula por cláusula, com a evidência que a auditoria pede em cada uma e o achado que mais aparece.

A versão de referência é a ISO/IEC 27001:2022, incluindo a Emenda 1 de 2024, que trouxe as mudanças climáticas para dentro da cláusula 4. Os certificados emitidos na edição de 2013 perderam validade em outubro de 2025.

Cláusula 4 — Contexto da organização

A cláusula que a maioria trata como formalidade e que decide a qualidade do sistema inteiro. É aqui que se define o que será protegido e até onde vai o certificado.

4.1 e 4.2 — Contexto e partes interessadas

Entender o que, dentro e fora da empresa, afeta a segurança da informação: setor de atuação, modelo de operação, dependência de fornecedores de nuvem, exigências contratuais de clientes, legislação aplicável (LGPD à frente), expectativas de matriz e de investidores.

Desde a Emenda 1:2024, a organização precisa determinar se as mudanças climáticas são uma questão pertinente ao seu contexto — e registrar essa determinação, mesmo que a conclusão seja que não são. Para segurança da informação isso é menos abstrato do que parece: evento climático extremo é causa de indisponibilidade de data center e de interrupção de link.

Evidência esperada: análise de contexto documentada, com as questões nomeadas e não genéricas, e a lista de partes interessadas com o que cada uma exige. O achado clássico é a matriz SWOT copiada de modelo, que serviria para qualquer empresa de qualquer setor.

4.3 — Determinando o escopo do SGSI

A decisão mais cara de errar. O escopo diz quais processos, unidades, pessoas e ativos de informação estão dentro do sistema — e nada fora do escopo declarado será auditado nem estará coberto pelo certificado.

Escopo largo demais multiplica esforço sem retorno. Escopo estreito demais esvazia o certificado: se o cliente exige a 27001 para o serviço que ele contrata e aquele serviço ficou de fora, o certificado não resolve a exigência comercial que motivou o projeto. O passo a passo está em como definir o escopo do SGSI.

Evidência esperada: escopo documentado, com interfaces e dependências externas explícitas (o que é responsabilidade do provedor de nuvem, por exemplo). Auditor confere se o escopo escrito bate com o que ele encontra andando pela operação.

4.4 — O sistema de gestão

Não tem documento próprio: materializa-se no conjunto. Vale conhecer um detalhe, porém — quando o sistema simplesmente não existe de forma estruturada, o auditor não abre dezenas de achados espalhados; abre uma não conformidade maior em 4.4, dizendo que o SGSI não está estabelecido, implementado, mantido e melhorado. É o achado que encerra a conversa.

Cláusula 5 — Liderança

5.1 — Liderança e comprometimento

A norma cobra da alta direção, não da equipe de TI: garantir que a política e os objetivos existam e sejam compatíveis com a estratégia, prover recursos, comunicar a importância do SGSI e apoiar quem o conduz.

Evidência esperada: ata de reunião com pauta de segurança da informação, orçamento aprovado, comunicação assinada pela direção e — o que mais convence — decisão difícil registrada: o projeto adiado por risco não tratado, o fornecedor reprovado na avaliação de segurança.

Um aviso prático: a entrevista com a alta direção acontece na auditoria, e o auditor cruza o que ouve com as atas. Diretor que não sabe dizer quais são os principais riscos de informação da empresa produz achado em 5.1.

5.2 — Política de segurança da informação

Precisa ser apropriada ao propósito da organização, incluir os objetivos de segurança (ou o quadro para defini-los), comprometer-se com o atendimento aos requisitos aplicáveis e com a melhoria contínua, estar documentada, comunicada internamente e disponível às partes interessadas pertinentes.

Evidência esperada: política vigente, com controle de versão, e prova de que chegou às pessoas — não o PDF na pasta da rede que ninguém abriu. O achado comum não é sofisticado: o colaborador operando por uma versão duas revisões atrasada, porque não há distribuição controlada.

5.3 — Papéis, responsabilidades e autoridades

Atribuição formal de quem responde pelo quê no SGSI, com autoridade para reportar o desempenho à direção. A norma não exige um cargo com nome específico — não existe "gestor de SGSI obrigatório" —, mas exige que a responsabilidade esteja atribuída e conhecida.

Evidência esperada: designação formal, descrição de responsabilidades, e ausência de conflito: quem administra os acessos não deve ser a única pessoa que revisa os acessos.

Cláusula 6 — Planejamento

O coração da norma. Se a cláusula 6 for genérica, todo o resto desaba — porque é dela que sai a escolha dos controles.

6.1.2 — Avaliação de riscos de segurança da informação

A empresa precisa definir e aplicar um processo de avaliação de riscos que estabeleça critérios de aceitação de risco e critérios para executar a avaliação, produza resultados consistentes e comparáveis, identifique os riscos associados à perda de confidencialidade, integridade e disponibilidade, identifique os donos dos riscos, e então analise e avalie cada um.

Repare no que a norma não exige: metodologia específica, software, nem inventário de ativos como ponto de partida obrigatório. A edição de 2013 empurrava a abordagem por ativo-ameaça-vulnerabilidade; a de 2022 dá liberdade, desde que o processo seja definido e repetível. A ISO/IEC 27005 é o guia de apoio, e não é certificável.

Evidência esperada: critérios de risco escritos antes dos resultados (sem régua definida, "risco alto" é opinião), riscos nomeados com dono, e ligação visível entre o risco identificado e o controle escolhido. O achado clássico é a planilha comprada em modelo que não menciona os sistemas que a empresa de fato usa.

6.1.3 — Tratamento de riscos e a Declaração de Aplicabilidade

Para cada risco, escolher a opção de tratamento e determinar os controles necessários. Só então comparar esses controles com o Anexo A para verificar se nada essencial foi esquecido — a ordem importa: o Anexo A é conferência, não catálogo de partida.

Daqui saem dois documentos que o auditor abre primeiro:

• a Declaração de Aplicabilidade (SoA), que lista os controles necessários, se estão implementados, a justificativa de inclusão e a justificativa de cada exclusão;
• o plano de tratamento de riscos, com responsável e prazo, aprovado pelos donos dos riscos, incluindo a aceitação formal dos riscos residuais.

Evidência esperada: SoA e plano coerentes entre si e com a avaliação de riscos. O achado que mais aparece na auditoria de estágio 2 é a SoA de fachada: controle marcado como aplicável e implementado, sem nenhuma evidência de operação por trás.

6.2 — Objetivos de segurança da informação

Objetivos mensuráveis, coerentes com a política, comunicados, monitorados e atualizados — com o que será feito, com quais recursos, por quem, quando e como o resultado será avaliado. "Melhorar a segurança" não é objetivo; "reduzir a zero as contas de ex-colaboradores ativas, verificado mensalmente" é.

6.3 — Planejamento de mudanças

Cláusula nova na edição de 2022: mudanças no SGSI precisam ser planejadas, não improvisadas. Migração de servidor para nuvem, troca de ERP, aquisição de empresa, abertura de unidade — tudo isso muda o risco e precisa passar pelo sistema, não contorná-lo.

Cláusula 7 — Apoio

A cláusula que sustenta todas as outras no dia a dia. Costuma ser subestimada e responde por boa parte dos achados.

7.1 e 7.2 — Recursos e competência

Determinar e prover os recursos necessários ao SGSI, e garantir que quem executa tenha competência — com base em educação, treinamento ou experiência. Quando faltar, tomar ação para adquiri-la.

Evidência esperada: matriz de competência por papel do SGSI e o registro de como cada pessoa a atende. Certificado de curso vencido em 2020 não sustenta competência em 2026.

7.3 — Conscientização

Todas as pessoas sob o controle da organização precisam conhecer a política, sua contribuição para a eficácia do SGSI e as implicações de não cumprir os requisitos. Conscientização não é o mesmo que treinamento técnico: é o comportamento esperado de quem não trabalha em segurança.

Evidência esperada: registro de participação, conteúdo aplicado, avaliação de eficácia e plano de reciclagem. Os auditores costumam deixar este requisito para o fim, justamente para amostrar as pessoas com quem conversaram nos dias anteriores: se o analista entrevistado na terça não tem registro de conscientização, o achado aparece na quinta.

7.4 — Comunicação

Definir o que é comunicado sobre segurança da informação, quando, a quem, e por quem — interna e externamente. É o requisito que organiza a comunicação de incidente antes de o incidente acontecer.

7.5 — Informação documentada

Criar, atualizar e controlar os documentos e registros: identificação, formato, análise crítica e aprovação, distribuição, controle de versão, proteção contra perda de integridade e retenção. Vale a mesma disciplina de informação documentada das outras normas ISO.

Um cuidado específico da 27001: a informação documentada do SGSI é, ela mesma, informação a proteger. Matriz de risco e SoA descrevem exatamente onde a empresa é frágil — documento desses em pasta aberta a toda a rede é achado com ironia embutida.

Cláusula 8 — Operação

Cláusula curta e frequentemente mal lida. Ela pede três coisas: 8.1 planejar, implementar e controlar os processos necessários para atender aos requisitos e implementar os controles — mantendo informação documentada na medida necessária para confiar que os processos foram executados como planejado; 8.2 executar a avaliação de riscos em intervalos planejados e quando houver mudança significativa; 8.3 implementar o plano de tratamento.

A distinção que resolve confusão: a cláusula 6 define como se avalia risco; a cláusula 8 é rodar aquilo de novo, no calendário. Empresa que avaliou risco uma vez, na implantação, e chega à auditoria de recertificação com a mesma planilha de três anos atrás não atende à 8.2.

A 8.1 também mudou de tom em 2022: a norma passou a pedir explicitamente que a organização controle os processos, produtos e serviços fornecidos externamente que sejam pertinentes ao SGSI — nuvem e terceiros entram aqui.

Evidência esperada: avaliações de risco datadas em série, mostrando periodicidade real, e o plano de tratamento com itens efetivamente concluídos.

Cláusula 9 — Avaliação de desempenho

Três evidências que a certificação não dispensa. Sem elas, não há auditoria de estágio 2 bem-sucedida.

9.1 — Monitoramento, medição, análise e avaliação

Determinar o que precisa ser monitorado, os métodos, quando, por quem, e quando os resultados serão analisados. Indicadores que digam se o SGSI funciona: tempo de tratamento de incidentes, percentual de acessos revisados no prazo, resultado dos testes de restauração de backup, cobertura de conscientização.

A pergunta que vale fazer antes de a auditoria fazer por você: seus indicadores medem desempenho do sistema ou volume de atividade dele? "Número de treinamentos realizados" mede esforço; "percentual de contas privilegiadas revisadas no trimestre" mede funcionamento.

9.2 — Auditoria interna

Programa de auditoria interna cobrindo todos os requisitos ao longo do ciclo, com auditores objetivos e imparciais em relação à área auditada, e os resultados reportados à direção.

Um esclarecimento que evita retrabalho: auditoria interna do sistema de gestão não é teste técnico de segurança. Não é o pentest nem a varredura de vulnerabilidade — é um auditor competente na ISO 27001 verificando requisito por requisito, como simulado da auditoria de certificação. Os dois têm valor, e um não substitui o outro. Veja como escolher o auditor interno e o checklist de preparação.

9.3 — Análise crítica pela direção

A direção precisa analisar o SGSI em intervalos planejados, com entradas definidas pela norma: situação das ações anteriores, mudanças no contexto, retroalimentação sobre o desempenho (não conformidades, resultados de monitoramento, resultados de auditoria, cumprimento dos objetivos), retroalimentação das partes interessadas, resultados da avaliação de riscos e status do plano de tratamento, e oportunidades de melhoria. A Emenda 1:2024 acrescentou como entrada as mudanças pertinentes relacionadas ao clima.

Evidência esperada: ata com as entradas exigidas e, principalmente, com decisões. Ata que só registra apresentação de números não demonstra análise crítica — e a 9.3 é um dos requisitos mais esquecidos da norma inteira.

Cláusula 10 — Melhoria

Na edição de 2022 a ordem inverteu em relação à de 2013: 10.1 é melhoria contínua e vem antes de 10.2, não conformidade e ação corretiva. É detalhe de numeração que confunde quem migrou de versão com checklist antigo na mão.

O conteúdo é o de sempre: ao identificar uma não conformidade, reagir e corrigir, avaliar a necessidade de eliminar a causa para que não se repita, implementar a ação, analisar a eficácia e registrar tudo.

A distinção que resolve a maior parte dos achados repetidos: correção é tirar o problema do caminho agora; ação corretiva é agir sobre a causa. Uma senha vazada exige trocar a senha (correção) e, depois, descobrir por que ela circulava em planilha compartilhada e corrigir isso (ação corretiva). Plano que só contém a correção é meia resposta, e o auditor do ciclo seguinte encontra o mesmo desvio. Vale a disciplina de análise de causa raiz.

Os documentos que a norma exige

A ISO 27001 não pede manual do SGSI (isso saiu com as versões antigas das normas ISO) e deixa o formato livre. Mas há informação documentada que a auditoria vai pedir pelo nome, porque a própria norma a exige:

Além dessa lista, os controles do Anexo A que a empresa declarar aplicáveis podem exigir os seus próprios registros — política de controle criptográfico, inventário de ativos, registros de acesso, plano de continuidade.

Por que o Anexo A não é requisito no mesmo sentido

O Anexo A lista 93 controles de segurança na edição de 2022, agrupados em quatro temas: organizacionais (37), de pessoas (8), físicos (14) e tecnológicos (34). Na edição de 2013 eram 114 controles em 14 seções — essa versão saiu de circulação em outubro de 2025.

A diferença é decisiva: a empresa não é obrigada a aplicar os 93. Ela determina os controles necessários a partir dos riscos que identificou, confere a lista do Anexo A para não deixar lacuna, e justifica cada exclusão na Declaração de Aplicabilidade. O que a cláusula 6.1.3 exige é que a escolha seja fundamentada — não que a lista inteira seja implementada.

A edição de 2022 também introduziu cinco atributos para filtrar os controles (tipo de controle, propriedades de segurança da informação, conceitos de cibersegurança, capacidades operacionais e domínios de segurança). São ferramenta de organização e visão gerencial, não requisito adicional.

Como implementar cada controle está na ISO/IEC 27002, que é guia e não é certificável. Três controles têm guia próprio aqui, porque são os que mais geram não conformidade: backup e cópia de segurança (8.13), controle criptográfico (8.24) e mascaramento de dados (8.11). Veja o detalhamento dos quatro temas.

Como os requisitos viram um projeto

A lista de cláusulas é mapa de verificação, não roteiro de implantação. Na prática de projeto, a ordem é outra:

1. Contexto e escopo (4.1 a 4.3) — decidir o que entra, antes de qualquer documento;
2. Avaliação de riscos (6.1.2) — é ela que determina quais controles sua empresa precisa e em que profundidade;
3. Tratamento, SoA e implementação dos controles (6.1.3 e 8.3);
4. Rodar o sistema (7 e 8) — conscientização, documentos, operação, por tempo suficiente para gerar evidência;
5. Auditoria interna e análise crítica (9.2 e 9.3) — descobrir os problemas antes do auditor externo;
6. Ação corretiva (10.2) — e só então marcar a auditoria de certificação.

Sistema montado a partir de um checklist de requisitos, e não do risco real, gera pasta de documentos que passa raspando no estágio 1 e trava no estágio 2, quando o auditor sai da mesa e vai conversar com quem opera. O caminho completo está em como implementar a ISO 27001.

Os erros que mais geram não conformidade

• SoA de fachada. Controle marcado como aplicável e implementado, sem evidência de operação. É a não conformidade mais comum do estágio 2;
• Avaliação de riscos genérica. Matriz de modelo, sem os sistemas e processos reais da empresa, não sobrevive à primeira pergunta do auditor;
• Critérios de risco definidos depois. Sem régua escrita antes, a classificação é opinião e a avaliação não é repetível — contraria a 6.1.2;
• Escopo mal recortado. Largo demais multiplica esforço; estreito demais deixa fora justamente o serviço que o cliente exigia certificado;
• Análise crítica que nunca aconteceu. A 9.3 pede registro da direção analisando o desempenho, com decisões — e é dos itens mais esquecidos;
• Avaliação de riscos feita uma única vez. A 8.2 exige repetição em intervalos planejados e a cada mudança significativa;
• Tratar sintoma como causa. A 10.2 pede ação sobre a causa-raiz; trocar a senha vazada sem investigar como vazou não fecha o achado;
• Migrar de versão com checklist antigo. Quem ainda usa a estrutura de 2013 perde a 6.3, os atributos do Anexo A e a Emenda 1:2024.

Quer o quadro completo da norma? Veja o guia da ISO 27001: o que é, requisitos e como certificar. Se a privacidade de dados pessoais também está no radar, vale entender o que mudou na ISO 27701:2025. E se quiser o caminho com prazo e investimento, veja certificação ISO 27001: etapas, prazo e custo ou como funciona a consultoria de ISO 27001.