1. O diagnóstico que define tudo
O gap analysis bem feito é o que garante uma jornada tranquila. O gap analysis mal feito é o que transforma um projeto de 12 meses num pesadelo de 24. Há algo que a maioria das empresas e consultores só descobre quando já é tarde: a etapa mais crítica de um projeto de certificação não é a implementação, não é a documentação e não é a auditoria de terceira parte. É o diagnóstico.
Um gap analysis bem conduzido permite dimensionar o projeto com realismo, construir uma proposta fundamentada, priorizar as ações certas e entregar um resultado que a organização consegue sustentar depois que o consultor vai embora. Um gap analysis feito às pressas, com checklist genérico e sem entendimento do negócio, produz o que o mercado chama de “consultor kit” — pacote pronto, resultado duvidoso.
Este artigo é um guia prático sobre como fazer o gap analysis de verdade para ISO/IEC 27001:2022: para que serve, quando aplicar, quais escalas usar, como conduzir as etapas e os cuidados que separam o diagnóstico honesto do relatório de prateleira.
2. O que é um Gap Analysis — e o que ele definitivamente não é
O gap analysis é uma fotografia do estado atual de conformidade de uma organização em relação a um referencial normativo — no nosso caso aqui nesse artigo, a ISO/IEC 27001:2022. Ele mapeia a distância entre onde a organização está e onde ela precisa chegar para se certificar.
O resultado concreto de um gap analysis é:
- Um mapa de lacunas entre o que existe e o que a norma exige
- A priorização das ações necessárias para fechar essas lacunas
- A base para o plano de implementação e para o cronograma realista
- O insumo quantificado para a proposta comercial — sem ele, a proposta é um chute
⚠️ O erro mais comum que o diagnóstico revela
Muitas organizações chegam para o processo de certificação com dezenas de políticas criadas — inclusive com ajuda de inteligência artificial — para responder a algum questionário de due diligence. Parecem bem documentadas. Mas quando o consultor avança um pouco, descobre que nenhuma delas foi implementada, comunicada ou operacionalizada. “Temos tudo documentado” não é a mesma coisa que “atendemos o requisito.” O gap analysis distingue o que existe no papel do que funciona na prática.
Agora, é igualmente importante entender o que o gap analysis não é:
- Não é uma penalização nem um julgamento — é um diagnóstico colaborativo
- Não é uma auditoria interna nem uma auditoria de certificação — distinção detalhada na próxima seção
- Não é uma readiness review — verificação de prontidão específica feita às vésperas da auditoria da certificadora
- Não é um relatório de riscos genérico — embora alimente o processo de avaliação de riscos
3. Gap Analysis vs. Auditoria Interna vs. Auditoria de Certificação
Um dos pontos de confusão mais frequentes na jornada de certificação ISO 27001 é não saber exatamente qual instrumento serve para quê. Gap analysis, auditoria interna e auditoria de certificação são três atividades distintas, com propósitos, posturas e consequências completamente diferentes. Confundi-las gera expectativas erradas — e problemas reais no projeto.
| Dimensão | Gap Analysis | Auditoria Interna (1ª parte) | Auditoria de Certificação (3ª parte) |
|---|---|---|---|
| Quem conduz | Consultor externo ou equipe interna de implementação | Auditor interno ou consultor contratado para este fim — com independência da área auditada | Organismo de Certificação (Certification Body - CB) acreditado — totalmente independente |
| Momento | Antes e durante a implementação | Durante e após a implementação — antes de chamar o CB | Após a implementação — Fase 1 (documental) e Fase 2 (operacional) |
| É obrigatório pela norma? | Não — é uma boa prática de gestão do projeto | Sim — exigido pela cláusula 9.2. Sem auditoria interna, não há certificação | Sim — é o processo que emite o certificado |
| Postura | Colaborativa — feito com a organização para identificar lacunas | Independente mas interna — verifica se o SGSI está funcionando conforme planejado | Totalmente independente — verifica conformidade com a norma para fins de certificação |
| Foco | O que falta implementar e o que precisa ser feito | Se o que foi implementado está funcionando e sendo mantido | Se os requisitos e controles estão atendidos com evidência suficiente para certificar |
| Resultado de uma lacuna | Ação de adequação planejada no roadmap do projeto | Não-conformidade interna com plano de ação corretiva | NC registrada no relatório — pode bloquear ou condicionar a emissão do certificado |
| Resultado final | Mapa de lacunas + plano de implementação + base para proposta | Relatório de auditoria + evidência para a análise crítica pela direção (cl. 9.3) | Certificado ISO/IEC 27001 válido por 3 anos (com auditorias anuais de vigilância) |
| Quem escolhe a evidência | O consultor, junto com a organização | O auditor interno — com base no plano de auditoria definido | O auditor do CB — sempre. Prerrogativa exclusiva dele. |
Por que essa distinção importa na prática
O gap analysis e a auditoria interna são complementares — não substituíveis. O gap analysis diz o que precisa ser feito; a auditoria interna diz se o que foi feito está funcionando. Sem gap analysis, o projeto começa sem bússola. Sem auditoria interna, o CB (Certificadora) vai reprovar na Fase 1: a cláusula 9.2 é um dos primeiros pontos verificados, e a ausência de auditoria interna é causa automática de não-conformidade.
🚫 Na auditoria de certificação, quem escolhe a evidência é o auditor — não o auditado
Esta é a diferença mais contraintuitiva entre a auditoria ISO e outros tipos de auditoria. O auditor do CB (Certificadora) pode ignorar completamente qualquer evidência pré-organizada pela organização e pedir o que quiser ver, no momento em que quiser. A auditoria ISO é ao vivo, em tempo real. Isso tem implicações diretas para como as organizações se preparam — e por que algumas promessas de plataformas de GRC precisam ser lidas com cautela (ver seção 9).
O gap analysis é feito com a organização. A auditoria interna é feita pela organização sobre si mesma. A auditoria de certificação é feita sobre a organização, de forma totalmente independente. Cada instrumento tem seu momento e seu papel — e entender essa distinção é o que permite gerenciar o projeto com clareza.
4. Quando aplicar o Gap Analysis
O gap analysis não é um evento único no início do projeto. Dependendo do momento, ele tem objetivos e profundidades diferentes:
Pré-projeto — antes de qualquer proposta
Este é o uso principal. Antes de elaborar qualquer proposta de implementação, o consultor precisa entender de onde a organização parte. Um projeto estimado sem diagnóstico é uma aposta — e as consequências chegam no meio do caminho, quando o escopo estoura e o cliente questiona por que o prazo está atrasando.
O gap analysis pré-projeto responde às perguntas essenciais: quantas lacunas existem? Qual é a maturidade atual? Quanto esforço será necessário? Isso é o que permite construir uma proposta com fundamento.
Durante a implementação — checkpoints de progresso
Ao longo do projeto, revisões parciais do gap analysis permitem medir o avanço real, identificar pontos que não evoluíram como planejado e recalibrar o cronograma antes que o atraso se torne irreversível. Um consultor que só olha para os gaps no início e no fim está perdendo informação valiosa no meio do caminho.
Pré-auditoria — conferindo o taco
Antes de chamar a certificadora, uma revisão focada de prontidão verifica o que ainda pode gerar não-conformidade na Fase 1 e na Fase 2. Não é o mesmo que o gap analysis inicial — é uma checagem cirúrgica das lacunas que ainda podem comprometer a auditoria.
💡 Questão comercial relevante
O gap analysis pode ser vendido como um serviço separado — o cliente contrata o diagnóstico e decide depois sobre a implementação — ou incluído num pacote fechado. Ambos os modelos funcionam. Muitos clientes preferem o pacote completo para não perder tempo. Outros querem ver o diagnóstico antes de decidir se avançam. A escolha deve refletir o perfil do cliente, não a preferência do consultor.
5. A estrutura do Gap Analysis para ISO 27001:2022
A ISO/IEC 27001:2022 está organizada em dois níveis de exigência, e o gap analysis precisa cobrir os dois de forma separada:
Requisitos mandatórios — Cláusulas 4 a 10
São os requisitos do sistema de gestão. Sem atendê-los integralmente, não há certificação possível. As cláusulas vão de 4.1 (contexto da organização) até 10.2 (não-conformidade e ação corretiva), cobrindo liderança, planejamento, apoio, operação, avaliação de desempenho e melhoria.
🚫 Atenção: “Não Aplicável” não existe para as Cláusulas 4 a 10
Este é um erro frequente em gap analysis mal conduzidos. Para os requisitos de gestão, todos se aplicam a qualquer organização, independente de porte, segmento ou tipo de negócio. O status “Não Aplicável” é exclusivo dos controles do Anexo A — nunca dos requisitos mandatórios.
Controles de Segurança — Anexo A (93 controles)
O Anexo A reúne 93 controles organizados em 4 seções: organizacionais (37 controles), pessoas (8 controles), físicos (14 controles) e tecnológicos (34 controles). Aqui sim, o status “Não Aplicável” é válido — e deve ser devidamente justificado na Declaração de Aplicabilidade (SoA), que é um documento obrigatório para a certificação.
💡 Exemplo prático
Uma empresa que trabalha 100% de forma remota não tem instalações físicas relevantes. Os controles A.7.1 (perímetros de segurança física), A.7.2 (entrada física), A.7.3 (segurança de escritórios) e A.7.4 (monitoramento físico) podem ser declarados como não aplicáveis — com justificativa documentada. Mas atenção: A.7.7 (mesa limpa e tela limpa) continua se aplicando mesmo para quem trabalha remotamente. É o consultor quem faz essa distinção — e ela importa.
📋 Atualização importante: versão 2022
Profissionais que trabalharam com projetos de ISO 27001:2013 precisam atualizar seus modelos. A versão 2022 reestruturou o Anexo A: de 114 controles em 14 seções para 93 controles em 4 seções, com 11 controles inteiramente novos. Usar um checklist da versão anterior numa auditoria da versão atual é um risco concreto.
6. Como conduzir o Gap Analysis na prática — 4 etapas
Um gap analysis eficaz segue uma sequência lógica que começa muito antes de abrir qualquer checklist:
Conversa preliminar antes de qualquer checklist
A etapa que a maioria pula — e que determina a qualidade de tudo que vem depois. Antes das entrevistas formais, uma reunião inicial para entender: qual é o escopo pretendido de certificação? O que motivou a empresa a buscar a ISO 27001 agora? Quantos colaboradores e sites estão no escopo? Existe estrutura interna de segurança? Houve tentativa anterior de certificação? Qual é o prazo? Essas respostas calibram o projeto inteiro. Sem elas, o consultor está atirando no escuro.
Entrevistas com os stakeholders certos
Alta direção, TI (subdivida — infraestrutura, desenvolvimento, SRE), jurídico, RH, compras e homologação de fornecedores, compliance. O roteiro segue os requisitos e controles da norma, não um questionário genérico. Cada área tem responsabilidades específicas que a ISO 27001 aborda diretamente: o jurídico sabe sobre cláusulas contratuais de segurança; o RH sabe sobre triagem e termos de contratação; o TI sabe sobre controles técnicos. Você precisa dos três.
Análise documental + walk-through técnico
O que a organização já tem: políticas, inventários de ativos, contratos com cláusulas de segurança e confidencialidade, logs, relatórios de segurança existentes. Após a análise documental, o walk-through técnico — que pode ser remoto — verifica o que os documentos dizem contra o que realmente existe: servidores, backups, controle de acesso, configurações de rede, monitoramento do ambiente. A diferença entre um documento e uma prática implementada é o que o consultor vai ao campo para descobrir.
Avaliação cláusula por cláusula e controle por controle
Com as informações coletadas nas etapas anteriores, o consultor preenche o checklist com as constatações reais, classifica o status de cada item e define ações de adequação com priorização. Este é o documento que alimenta o plano de trabalho, o cronograma e a proposta comercial. É a saída concreta do gap analysis.
“Em geral você nunca vai chegar numa organização que vai estar completamente zerada. Já tem alguma coisa funcionando que atende o que a norma pede. A habilidade do consultor é fazer essa tradução — associar o que a empresa já faz ao que a norma pede.”
— François Martinot, 30 anos de auditoria e consultoria em sistemas de gestão7. Escalas de avaliação — a escolha que define a qualidade do diagnóstico
A pergunta central do gap analysis para ISO 27001
Antes de discutir escalas, é preciso entender o que o gap analysis está realmente medindo. E aqui está o ponto mais importante desta seção:
“O consultor não está medindo maturidade em cinco níveis. Ele está verificando conformidade. A pergunta central é: você tem evidência?”
Para a certificação ISO 27001, a pergunta fundamental é essencialmente binária: o requisito está implementado e há evidência de que está operando? Essa distinção é o que determina qual escala usar — e por que escalas desnecessariamente complexas podem criar mais trabalho analítico do que clareza operacional.
A escala CMMI — origem, aplicação e limitação no contexto ISO 27001
O Capability Maturity Model Integration (CMMI), criado pelo SEI (Software Engineering Institute), define cinco níveis de maturidade de processos:
- Nível 1 — Inicial: processos ad hoc, imprevisíveis
- Nível 2 — Gerenciado: processos planejados e rastreados
- Nível 3 — Definido: processos documentados e padronizados
- Nível 4 — Quantitativamente Gerenciado: processos medidos e controlados
- Nível 5 — Em Otimização: foco em melhoria contínua e inovação
O CMMI foi adaptado para avaliar maturidade de processos de segurança e é referência em frameworks como o NIST CSF. É uma ferramenta legítima para organizações que querem mapear sua evolução ao longo do tempo.
⚠️ Limitação crítica no contexto ISO/IEC 27001
Esta norma não exige maturidade — exige conformidade. Um processo completamente ad hoc (nível 1 no CMMI) pode passar numa auditoria ISO se houver evidência de que funciona. Um processo bem documentado e maduro (nível 3 no CMMI) pode reprovar se não houver registro de operação. A escala CMMI para gap analysis pré-certificação adiciona complexidade sem necessariamente adicionar clareza para as decisões do projeto.
O CMMI é mais indicado para organizações que já possuem a certificação e querem planejar a evolução da maturidade — não para o diagnóstico inicial de conformidade.
Escalas simplificadas — o que o mercado pratica
A maioria dos consultores experientes usa escalas de 3 ou 4 categorias porque o objetivo é acionável, não acadêmico. Para certificação ISO 27001, 4 categorias capturam a realidade com granularidade suficiente para priorizar ações sem criar trabalho analítico desnecessário.
A escala adotada no modelo TIexames
🔴 Não atende
Lacuna completa — o requisito não existe na organização. Não há política, processo, prática ou evidência de qualquer natureza. Deve ser implementado do zero.
🟠 Atende Parcialmente
Existe prática informal ou parcial, mas sem documentação sistemática ou sem evidência de operação regular. A prática existe; a conformidade, ainda não.
🟢 Atende Totalmente
Implementado, documentado e com evidências de operação. Um auditor da certificadora encontraria conformidade plena neste ponto.
⚪ Não Aplicável
Fora do escopo definido — apenas para controles do Anexo A. Deve ser justificado na Declaração de Aplicabilidade (SoA). Não pode ser usado para cláusulas 4 a 10.
🟣 Em Melhoria
Categoria adicional para organizações mais maduras: o controle está implementado e a organização está ativamente refinando-o. Reconhece evolução em curso.
A categoria “Em Melhoria” é uma nuance prática que alguns consultores adicionam para clientes que já possuem controles funcionando e estão investindo em refinamento — situação comum em empresas de tecnologia que já adotam boas práticas de segurança por conta própria, sem ter associado formalmente aos requisitos da norma.
8. Cuidados que separam o bom consultor do “consultor kit”
O “consultor kit” é aquele que tem o pacote pronto, vende o pacote pronto e não tem muita preocupação em saber se aquilo atende a necessidade específica do negócio. O bom consultor faz o oposto — e os cuidados abaixo mostram exatamente onde essa diferença aparece na prática.
Documento criado, assinado e arquivado sem nunca ter sido comunicado ou implementado não atende o requisito 5.2 da norma. O consultor precisa verificar se a política existe e se ela está funcionando — são duas perguntas diferentes.
A organização não mente — ela genuinamente não sabe associar o que já faz ao que a norma pede. Mas o consultor precisa ver o processo funcionando, não apenas ouvir a descrição. O walk-through técnico existe exatamente para isso.
Um caso real: três organizações auditadas usando a mesma plataforma de GRC, com políticas praticamente idênticas — só mudaram o nome da empresa. Resultado: não-conformidade, porque nenhuma conseguia demonstrar que a política se aplicava ao seu contexto específico. Template é ponto de partida, não entregável.
O consultor experiente traduz o “isonês” para a linguagem que a organização usa no dia a dia. Isso inclui o formato da documentação — se a empresa trabalha com Notion, o procedimento vai para o Notion. Se usa Word, vai para Word. Impor uma estrutura documental estranha à cultura da empresa cria resistência e garante que ninguém vai usar os documentos depois.
O gap analysis revela as lacunas, mas fechar essas lacunas consome tempo da equipe interna — entrevistas, aprovações, treinamentos, evidências. Esse tempo tem custo que quase ninguém contabiliza, mas que determina o ritmo real do projeto. Um consultor que não mapeia a capacidade interna disponível está construindo um cronograma que vai falhar.
A certificadora exige no mínimo 3 meses de sistema em operação gerando evidências antes da Fase 2 da auditoria. Isso significa que em 6 meses, um projeto teria que conceber tudo, implementar, gerar evidências por 3 meses e ainda passar pela auditoria. O resultado é uma certificação frágil que acumula não-conformidades nas auditorias de vigilância seguintes. Maturidade não tem atalho — e saber comunicar isso com clareza é parte do trabalho do consultor.
O gap analysis precisa retratar a realidade — não o que vende mais horas de implementação nem o que o cliente quer ouvir. O diagnóstico honesto, mesmo quando o cenário é mais favorável do que o imaginado, é o que constrói credibilidade de longo prazo.
9. O alerta sobre ferramentas de GRC
Plataformas de Governance, Risk and Compliance (GRC) são ferramentas úteis — e esse uso tem lugar certo no projeto. O problema é quando elas são apresentadas como atalhos para a certificação ou como substitutos para o diagnóstico.
Algumas plataformas do mercado prometem automatizar desde a criação de políticas até a geração de evidências. Essa promessa precisa ser lida com cautela, por duas razões:
🚫 O auditor ISO escolhe a evidência — não o auditado
Em uma auditoria ISO, diferente de outros tipos de auditoria, quem decide o que vai ser analisado é o auditor. Ele pode ignorar completamente todas as evidências pré-organizadas dentro de uma plataforma e pedir o que quiser ver, no momento em que quiser. A auditoria ISO é ao vivo. Depositar evidências numa plataforma não garante que o auditor vai avaliá-las.
🚫 Políticas genéricas não passam em auditoria
Plataformas de GRC costumam vir com modelos prontos de políticas. Esses modelos são genéricos por definição — são ponto de partida, não entregável. Um auditor experiente consegue identificar uma política de template que nunca foi adaptada à realidade do negócio. E a consequência é não-conformidade.
✅ Quando faz sentido usar uma plataforma
A recomendação prática: comece com planilhas estruturadas e documentação adaptada para a primeira certificação — menos fricção, mais foco no que importa. Migre para uma plataforma de GRC quando a organização já tiver o certificado e quiser elevar a maturidade, estruturar melhor a rastreabilidade de evidências ou gerenciar múltiplos sites com alta rotatividade. A plataforma potencializa um SGSI maduro — não substitui a construção da maturidade.
10. Gap Analysis como base da proposta comercial
O gap analysis não é apenas um entregável técnico — é o fundamento de qualquer proposta de implementação que mereça ser levada a sério.
Com o diagnóstico em mãos, o consultor consegue:
- Dimensionar as horas por fase com base nas lacunas identificadas, não em estimativas genéricas de mercado
- Priorizar as ações por impacto na certificação: Crítica (sem ela não se certifica), Alta, Média, Baixa
- Construir um cronograma macro realista — e o cliente precisa ver o fim antes de assinar o contrato
- Justificar o investimento para a alta direção com dados concretos, não argumentos genéricos sobre segurança
- Identificar ferramentas necessárias — quais controles demandam solução tecnológica que o cliente ainda não tem
Sem gap analysis, a proposta é uma estimativa. Com gap analysis, é um projeto. A diferença aparece no meio do caminho — ou na reputação que o consultor constrói (ou destrói) ao longo do projeto.
“O certificado é o destino. Mas a jornada começa com um diagnóstico honesto, realista e completo.”
Modelo de Gap Analysis ISO/IEC 27001:2022
Planilha completa com as cláusulas 4 a 10, os 93 controles do Anexo A com texto literal da norma, dashboard automático por status e estimativa de esforço integrada. Desenvolvida pela TI Exames — gratuita para uso profissional.
ISO/IEC 27001 Lead Implementer
Esteja preparado para liderar projetos de certificação ISO 27001 do gap analysis à auditoria de terceira parte. Metodologia baseada no ciclo PDCA, casos práticos e certificado internacional pela Exemplar Global.
Próximas turmas disponíveis · Início imediato por gravações
