Implementando um SGSI na prática
A maioria das empresas tenta implementar de acordo com a norma abnt nbr iso iec 27001 partindo do escopo e do anexo A, mas isso é o caminho mais lento para receber uma lista enorme de não conformidades na auditoria. O que funciona de verdade é começar pelo contexto organizacional e pelos interessados, porque se você mapear isso direito desde o início, o resto flui com metade do esforço. O contexto organizacional (cláusula 4) exige que você identifique quais partes interessadas existem dentro e fora da sua organização, quais são os requisitos delas e como isso se conecta com seus processos de negócio. Na prática, isso significa sentar com as áreas de RH, jurídico, operações e TI e perguntar que informações precisam ser protegidas, quem tem acesso e o que acontece se algo der errado. Anote tudo. Sem isso, seu escopo vai ficar genérico e a auditoria vai cobrar objetivas que você não conseguirá sustentar.
de acordo com a norma abnt nbr iso iec 27001: o que realmente acontece durante uma auditoria
Eu passei por uma auditoria de certificação onde o auditor abriu com uma pergunta sobre política de segurança da informação. Nossa política estava bem escrita, revisada, assinada pela diretoria. Mas quando ele pediu para mostrar evidência de que o pessoal sabia dela, não tivemos nada concreto além de um e-mail de distribuição. Ele abriu uma não conformidade menor no item 5.1 (liderança). A correção imediata foi simples — fizemos um acknowledgment digital com data de leitura e encaminhamos para todos os colaboradores, mas o tempo perdido foi de pelo menos três dias de ajuste de documentação. Outro ponto que ninguém comenta: o auditor não quer ver perfeição. Ele quer ver coerência. Se seu escopo fala que protege dados de clientes, mas suas políticas e controles não cobrem tratamento desses dados, isso é incoerência. Se o escopo exclui um sistema inteiro sem justificativa documentada, também é problema. O ideal é documentar o que está fora do escopo com os motivos técnicos e operacionais.
Estrutura do documento mestre
Antes de escrever qualquer coisa, monte um documento mestre com a estrutura obrigatória. Não tente improvisar no meio do caminho. A norma exige cláusulas específicas com evidências verificáveis: Cláusula 4 — Contexto da organização: análise de partes interessadas, requisitos, escopo documentado, decisões sobre o que entra e o que sai.
Cláusula 5 — Liderança: política de segurança da informação, atribuição de papéis e responsabilidades. A direção precisa assumir o compromisso visível, não apenas assinar papel. Cláusula 6 — Planejamento: ações para tratar riscos e oportunidades, objetivos de SCI com métricas definidas. Aqui é onde a maioria erra — colocar objetivos vagos como "melhorar a segurança" sem indicador quantificável.
Cláusula 7 — Suporte: recursos, competência, conscientização, comunicação e informação documentada. A norma exige registros de treinamento, avaliação de competência e controle de documentos atualizados. Cláusula 8 — Operação: planejamento e controle operacional, gestão de riscos de segurança da informação. Este é o coração do processo e onde a maior parte do trabalho real acontece.
Cláusulas 9 e 10 — Avaliação de desempenho e melhoria: monitoramento, medição, análise, avaliação, auditoria interna e ação corretiva.
Gestão de riscos — o que funciona de fato
A cláusula 6.1.2 e 6.1.3 exigem que você avalie riscos e trate os que forem acceptáveis. A abordagem mais comum é usar uma matriz de probabilidade por impacto, mas o detalhe que poucas pessoas consideram é a diferença entre risco residual e risco aceitável. Seu tratamento de riscos deve deixar claro que o risco remanescente após os controles foi aceito por quem tem autoridade para isso — normalmente a direção ou o proprietário do risco. Na minha experiência, o ponto mais crítico é a documentação do statement of applicability (SoA). Ele é o documento que liga cada controle do Anexo A que você selecionou à avaliação de riscos. Se o SoA não justificar por que um controle foi incluído ou excluído, a auditoria vai cobrar. Eu já vi empresas com SoA que simplesmente listavam todos os 93 controles do Anexo A sem qualquer justificativa, o que é incompatível com a exigência da norma de demonstrar adequação ao contexto organizacional.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma nuance que começações ignoram: a norma não exige que você implemente todos os 93 controles do Anexo A. Ela exige que você avalie quais se aplicam ao seu contexto. Se sua organização não lida com dados biométricos, por exemplo, o controle 8.6 (proteção de informações identificáveis) pode não se aplicar, mas você precisa documentar o porquê dessa exclusão no SoA.
Evidências que realmente resistem a uma auditoria
Registros de treinamento com data, conteúdo e participante assinado. Ataendas de reunião de revisão pela direção com decisões tomadas e responsáveis definidos. Relatórios de incidentes com sequência completa desde a detecção até o fechamento. Log de acesso a sistemas críticos atualizado e guardado pelo prazo adequado. Tudo isso precisa existir antes da auditoria, não durante. A maiorarmos de auditoria que encontrei não são na tecnologia. São na documentação. Uma empresa que eu auditava tinha firewalls bem configurados, criptografia em disco, controle de acesso rigoroso. Mas não tinha registro de nenhuma manutenção preventiva nos equipamentos. O auditor gerou uma não conformidade no item 8.1 (planejamento e controle operacional) porque não havia evidência de que os controles estavam sendo mantidos. A correção levou duas semanas.
Prazos e realidade
Implementar um SGSI completo do zero em uma organização de médio porte leva entre seis e doze meses, dependendo da maturidade existente. O gargalo quase sempre é a cláusula 8 — a avaliação de riscos e o tratamento que se segue. Fases como política, escopo e definição de responsabilidades costumam ser concluídas em uma ou duas semanas. O processo de análise de riscos propriamente dito, com identificação de ativos, ameaças, vulnerabilidades e tratamentos, pode levar de um a três meses só nessa etapa. Se sua organização já tem processos de TI bem estruturados, você consegue reutilizar parte deles. Políticade acesso existente vira política de segurança. Procedimentos de backup viram controles de disponibilidade. Isso reduz o tempo de implementação em cerca de 30% a 40%, dependendo do que já existe.
Alternativas e limitações
A norma ISO/IEC 27001 é robusta, mas tem limitações claras. Para organizações muito pequenas, o custo-benefício pode não fazer sentido se o único objetivo for compliance. Nesses casos, frameworks mais leves como o NIST Cybersecurity Framework ou controles essenciais do CIS podem atingir níveis equivalentes de proteção com menos burocracia. A própria norma reconhece isso em sua introdução, que cita a necessidade de proporcionalidade. Outra limitação prática: a norma é genérica o suficiente para se aplicar a qualquer tipo de organização, mas isso também significa que ela não resolve problemas específicos de setores regulados. Se você trabalha com saúde, precisa complementar com HIPAA ou LGPD. Setor financeiro exige normas adicionais como a NBC TG 25 ou regras do BACEN. A ISO 27001 serve como base, não como cobertura total.
Relacionado a downloads e materiais de apoio: a norma ABNT NBR ISO/IEC 27001:2022 é um documento comercial vendido pela ABNT. Não disponibilizo links diretos de download porque o acesso legal se dá através do site da ABNT (abnt.org.br) ou de livrarias especializadas. Existem modelos de templates gratuitos na internet, mas é importante usar com cautela — template pronto não substitui o trabalho de contextualização que a norma exige.
O que não contar para ninguém
A norma não fala abertamente, mas na prática a equipe de auditoria internacorresponde-se com a certificadora e compara evidências entre auditorias de empresas do mesmo segmento. Documentação copiada de templates genéricos sem adaptação ao contexto real costuma ser detectada porque o auditor reconhece linguagem padrão que não reflete operações específicas. Escreva com as palavras da sua organização. Cite os sistemas reais que você usa. Mencione os processos que realmente existem. Também não conta na norma, mas na prática: manter evidências de revisões de política com datas espaçadas demais (mais de um ano entre revisões) gera questionamentos sobre a eficácia do sistema. A norma pede revisão periódica, e o intervalo ideal documentado costuma ser de seis a doze meses.
Se você está começando agora, foque na cláusula 4 primeiro. Mapeie partes interessadas, defina o escopo com argumentos claros, documente tudo. O resto se constrói a partir daí com muito menos atrito do que a maioria espera.
