Como Fazer uma Análise de Lacunas de Framework (Passo a Passo)

Uma análise de lacunas responde a uma pergunta: se já atendemos ao framework A, o que ainda precisamos para o framework B? Aqui está um método que transforma a resposta em um plano, e não em uma planilha que ninguém abre.

Todo framework adicional começa com a mesma pergunta: quanto disso já temos? A análise de lacunas responde a ela. Feita mal, produz uma planilha que diz "parcialmente conforme" para tudo e nunca mais é aberta. Feita bem, produz uma lista de tarefas com custos e responsáveis. Este é o método que usaríamos.

Etapa 1: definir o escopo e a direção

Uma análise de lacunas tem uma direção: ter um framework (ou seus controles atuais), precisar de outro. Registre ambos, com versões, e o escopo organizacional: qual entidade, serviços e locais. As análises de lacunas costumam dar errado com mais frequência quando os dois escopos não coincidem, por exemplo, um certificado ISO que cobre uma linha de produtos comparado a uma obrigação da NIS2 para a entidade inteira.

Etapa 2: gerar a comparação requisito a requisito

Comece a partir de um mapeamento, não de uma planilha em branco. A análise de lacunas da ControlMapping lista cada requisito do framework de que você precisa, cada um com sua correspondência naquele que você já possui:

mapeado: uma correspondência publicada ou nosso julgamento editorial o vincula a algo que você possui.
vagamente relacionado: compartilha apenas um resultado com algo que você possui. Trate-o como provavelmente um trabalho novo.
sem mapeamento em nossos dados: provavelmente trabalho novo, a menos que a cobertura desse framework seja parcial.

Por exemplo, ao ir da ISO 27001 para a NIS2:

Dos 49 pontos de requisito de NIS2, 49 (100%) mapeiam para algo em ISO 27001, 0 são apenas vagamente relacionados e 0 não têm mapeamento em nossos dados. Abrir o relatório de lacunas →

Etapa 3: validar as correspondências com a realidade

Um mapeamento diz que dois requisitos estão relacionados. Não diz que sua implementação atende aos dois. Para cada linha mapeada, pergunte:

Realmente fazemos o que mapeamos? Um mapeamento para a ISO A.8.8 só ajuda se sua gestão de vulnerabilidades funcionar.
O novo requisito é mais específico? Prazos, frequências, técnicas nomeadas e escopo costumam ser diferentes.
O vínculo é editorial? Verifique o motivo exibido e decida se você concorda.

Marque cada linha como atendido, parcialmente atendido ou não atendido. Seja honesto: uma análise de lacunas generosa apenas transfere a descoberta para a auditoria.

Fotografia de um quadro branco de escritório coberto por colunas de notas adesivas coloridas em branco, com um marcador na bandeja — Uma análise de lacunas só é útil quando se transforma em uma lista de tarefas com responsáveis.

Etapa 4: exportar como rastreador

Pressione e na visualização de lacunas (ou o botão Export CSV) para baixar o resultado. Cada linha traz o requisito, sua seção, a correspondência, a base e o motivo, além de quatro colunas em branco prontas para o trabalho: responsável, status de implementação, referência de evidência e observações. Abra-o na sua planilha ou importe-o para sua ferramenta de GRC.

Etapa 5: transformar linhas em trabalho

Agrupe por responsável e tema, não por número de requisito: "contratos com fornecedores" é uma tarefa só que pode fechar seis linhas.
Estime cada grupo e defina a sequência: mudanças de governança e política geralmente destravam o trabalho técnico.
Preencha a coluna de evidências à medida que avança, para que o rastreador se torne seu arquivo de auditoria.
Refaça a análise quando qualquer um dos frameworks mudar; a nossa é atualizada quando os dados mudam.

Principais conclusões

Defina primeiro o escopo e a direção: ter A, precisar de B, com versões.
Comece por um mapeamento e valide cada correspondência com o que você realmente faz.
Exporte o resultado como rastreador com colunas de responsável, status e evidência, e transforme as linhas em trabalho agrupado.

Erros comuns

Comparar com uma versão substituída (CSF 1.1, ISO 27001:2013, PCI DSS v3.2.1).
Tratar "vagamente relacionado" como coberto.
Ignorar completamente requisitos fora do mapeamento: obrigações legais, como prazos de notificação de incidentes, costumam ficar fora de qualquer catálogo de controles.

Para exemplos práticos, veja ISO 27001 vs NIS2 ponto a ponto e as comparações, cada uma das quais já é uma análise de lacunas bidirecional pronta.

Perguntas

O que é uma análise de lacunas de conformidade?

Uma comparação requisito a requisito entre o que você já faz (ou o framework que você já atende) e os requisitos de um framework de que você precisa, identificando o que está coberto, parcialmente coberto e ausente.

Quanto tempo leva uma análise de lacunas?

O mapeamento pode ser produzido em minutos com uma ferramenta como a análise de lacunas da ControlMapping. Validá-lo contra seus controles e evidências reais é o trabalho de fato, normalmente de dias a algumas semanas, dependendo do escopo.

O que significa 'vagamente relacionado' em uma análise de lacunas?

Os dois requisitos compartilham apenas um resultado do NIST CSF 2.0; ninguém os mapeou um ao outro. Trate-os como uma pista a verificar e, normalmente, como trabalho novo, não como cobertura.

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.

Análise de lacunas entre frameworks: do método ao rastreador