ISO 27001: Li a Norma Cinco Vezes. Depois Tentei Implementá-la.

História real.

Um profissional que formei no outono passado era security manager numa empresa de média dimensão nos Países Baixos. Competente. Rigoroso. Tinha a certificação Foundation. Tinha lido o ISO 27001 de capa a capa. Várias vezes. Conseguia explicar o que a Cláusula 6 exigia. Enumerava de memória as quatro categorias de controlos do Anexo A. Desenhava o ciclo Plan-Do-Check-Act num quadro branco de olhos fechados.

A empresa decidiu obter a certificação. O seu gestor disse: "Conheces a norma. Lidera o processo."

E então sentou-se à secretária numa segunda-feira de manhã e percebeu que não fazia absolutamente ideia por onde começar.

Não por incompetência. Porque a norma nunca lhe disse. A norma diz-lhe o que tem de existir. Nunca lhe diz como construir seja o que for.

Três meses depois, ainda não tinha a certeza se o âmbito estava correto. A metodologia de avaliação de risco tinha sido reescrita duas vezes porque ninguém conseguia chegar a acordo sobre o que significava "provável". A SoA estava a meio e ele não confiava em nada do que lá estava. Havia progresso, mas do género em que se avança sem saber se se está a avançar na direção certa.

Quando chegou ao meu curso, já tinha dedicado quase um ano ao projeto. Não porque o trabalho fosse difícil. Porque o estava a fazer sem metodologia.

Se alguma parte disto lhe soa familiar, este artigo é para si.

A norma não é um manual de instruções. Nunca foi suposto sê-lo.

Isto é o que ninguém diz em voz alta: o ISO 27001 é deliberadamente incompleto.

Não é uma crítica. É o design. A norma tem de funcionar para uma startup de cinco pessoas e para um banco com cinquenta mil colaboradores. Tem de funcionar em todos os setores, todas as jurisdições, todas as tecnologias. A única forma de o conseguir é especificar o que tem de existir sem especificar como construí-lo. Essa generalidade é o que a torna poderosa. É também o que a torna inútil como guia passo a passo.

"A organização deve determinar as questões externas e internas relevantes para o seu propósito." Como? Workshop? PESTLE? Entrevistas? Esboço numa folha durante um café? A norma não diz, porque a resposta depende de se tratar de um hospital, uma empresa SaaS ou um escritório de advogados.

"A organização deve definir e aplicar um processo de avaliação de riscos de segurança da informação." Muito bem. Mas como é esse processo? Que metodologia? Que escalas? Como se calibra para que a palavra "elevado" signifique o mesmo para o departamento jurídico e para a equipa do SOC? A norma não diz.

"A organização deve produzir uma Declaração de Aplicabilidade." Certo. Mas o que faz uma boa SoA? Que nível de detalhe devem ter as justificações? O que conta como evidência de implementação? Uma política é suficiente, ou o auditor quer logs? A norma absolutamente não diz.

As pessoas que compreendem a norma mas não conseguem implementá-la não carecem de inteligência. Carecem de metodologia. E isso não é uma falha da pessoa. É uma lacuna que a norma nunca foi concebida para colmatar.

Cinco decisões que a norma deixa inteiramente a seu cargo

Implementei o ISO 27001 em mais de uma centena de organizações. Estas cinco decisões são onde cada implementação encontra o seu rumo ou perde meses.

Como definir o âmbito. A maioria das pessoas acha que definir o âmbito é simples. Define-se o que está dentro, o que está fora, e avança-se. Depois passam três meses a discutir sobre isso. O ambiente de desenvolvimento deve estar no âmbito? E a subsidiária que partilha o mesmo Active Directory? E a equipa de suporte offshore que acede a dados de produção? Cada decisão de âmbito tem consequências a jusante para o risco, os controlos e a auditoria. A norma diz "determinar o âmbito". Não diz como navegar esses compromissos, nem como redigir uma declaração de âmbito que um auditor aceite em trinta segundos em vez de passar duas horas a desmontá-la.

Como avaliar o risco. É aqui que se perde mais tempo. Não na execução da avaliação, mas na conceção da metodologia. Já revi registos de risco em que toda a coluna de probabilidade diz "médio". Em que a coluna de impacto tem cinco níveis mas ninguém consegue explicar a diferença entre um três e um quatro. Em que o mesmo risco é pontuado de forma diferente por duas equipas em salas adjacentes porque ninguém calibrou as escalas. A norma diz "aplicar um processo de avaliação de riscos". Não diz como construir uma metodologia que seja repetível, defensável e que não colapse na primeira vez que o auditor pergunta "por que razão é este um três e não um quatro?"

Como redigir a SoA. A Declaração de Aplicabilidade é o documento mais importante do seu ISMS e o mais frequentemente mal feito. Já revi SoAs em que todos os controlos estão marcados como "implementados" sem qualquer evidência. Em que a coluna de justificação diz "ver política" em noventa e três linhas. Em que as propriedades do documento mostram que foi editado pela última vez por alguém de uma empresa completamente diferente, porque foi descarregado da internet e os nomes nunca foram alterados. O auditor lê a sua SoA primeiro. Se ela colapsa, nada mais o salva.

Como fazer a liderança comprometer-se. A Cláusula 5 diz que a gestão de topo deve demonstrar liderança e compromisso. Na prática, isto significa que precisa de levar o conselho de administração a alocar orçamento, a participar nas revisões de gestão e a aprovar decisões de aceitação de risco. A norma diz "a liderança deve". Não diz como entrar numa reunião de conselho e explicar por que razão a empresa precisa de gastar dinheiro em algo sem ROI visível até ao dia em que algo corre mal. Esse é um problema de comunicação, não um problema de segurança, e a maioria das implementações falha aqui, não na camada técnica.

Como preparar a auditoria. A Fase 1 é a revisão documental. A Fase 2 é a evidência operacional. A maioria das pessoas prepara-se para uma e entra em pânico com a outra. Constroem documentação impecável e depois não conseguem demonstrar que os controlos estão efetivamente a funcionar. Ou têm controlos operacionais e não conseguem produzir o rasto de evidências. A norma diz "preparar a auditoria de certificação". Não diz o que o auditor abre primeiro, quais as perguntas da primeira hora, nem o que falha sistematicamente. Eu sei, porque já estive dos dois lados dessa mesa.

O que significa metodologia, na prática

Quando digo que este curso ensina a metodologia, não quero dizer que recebe uma checklist. Quero dizer que aprende o sistema operativo que está por trás da norma.

Uma metodologia diz-lhe o que fazer primeiro, e porquê. Diz-lhe como conduzir o workshop de âmbito para que demore um dia, não um trimestre. Dá-lhe um framework de avaliação de risco que consegue defender, não apenas preencher. Mostra-lhe como é uma boa SoA e o que torna uma má SoA evidente. Ensina-lhe como apresentar segurança a um conselho que não se interessa por segurança, numa linguagem que os leve a interessar-se. E diz-lhe o que o auditor vai fazer, por que ordem, para que se possa preparar em vez de sobreviver.

É essa a diferença entre conhecer a norma e ser capaz de a implementar. E é a diferença entre um projeto de seis meses que tem sucesso e um projeto de doze meses que produz um arquivo cheio de documentos que ninguém usa.

É para isso que servem os 5 dias

17 a 21 de agosto. Segunda a sexta-feira. Online em direto, em inglês. Uma turma limitada a seis pessoas, porque ao sétimo a conversa morre e os exercícios tornam-se uma formalidade.

Cada linha dessa tabela começa com "como". É deliberado. O "o quê" está na norma. Pode lê-la gratuitamente. O "como" é o que está a pagar.

Quem leciona

Eu. Christophe Mazzola. CISO ativo, fundador da Cyber Academy, PECB Gold Trainer.

Não ensino implementação a partir de um manual. Ensino a partir do terreno. Quando explico metodologia de avaliação de risco, é porque já construí frameworks de risco e depois sentei-me frente a um auditor que tentou desmontá-los. Quando explico como obter o compromisso da liderança, é porque já estive perante conselhos que não queriam ouvir e encontrei forma de os fazer ouvir. Quando alguém no curso diz "a minha SoA é um desastre", não lhe dou a resposta do exame. Digo-lhe o que faria se estivesse sentado à sua secretária na segunda-feira, porque já estive sentado nessa secretária.

Duzentas auditorias. Cem implementações. As histórias de guerra neste curso são minhas. Isso tem importância, porque a distância entre a norma e a realidade não é teórica. É operacional. E aprende-se a colmatá-la com alguém que o faz profissionalmente.

A garantia

Conclua o curso. Faça o exame. Se não passar, reembolsamos a taxa de formação.

Sem letras pequenas além de concluir o programa e fazer o exame. Chamamos-lhe Certified or Refunded, e é a sério. A metodologia funciona. A taxa de aprovação prova-o. E se está a investir uma semana do seu tempo e o dinheiro da sua empresa, merece um fornecedor que aposte no mesmo resultado que você.

Os detalhes

• Curso: ISO/IEC 27001:2022 Lead Implementer, PECB Certified
• Datas: 17 a 21 de agosto de 2026
• Formato: Online em direto. Interativo. Sem gravação.
• Idioma: Inglês
• Dimensão da turma: 3 a 6 participantes
• Exame: Exame PECB de 3 horas no Dia 5, consulta permitida
• Materiais: Mais de 450 páginas incluídas
• CPD: 31 créditos
• Repetição gratuita: Dentro de 12 meses
• Preço: €2.499
• Garantia: Certified or Refunded

A decisão é sua

Se leu a norma e ainda não sabe o que fazer na segunda-feira de manhã, este é o curso que colmata essa lacuna.

Se lhe entregaram um projeto de implementação e tem pesquisado "ISO 27001 risk assessment template" à meia-noite, aqui obtém a metodologia para nunca mais precisar de o fazer.

Se é consultor e os seus clientes esperam que lidere este processo de ponta a ponta, é aqui que deixa de improvisar e passa a saber.

Se está a oito meses de um projeto que deveria ter demorado quatro, este é o seu reset de cinco dias.

Reserve o seu lugar abaixo.

Questões? Escreva-me diretamente. Sem equipa comercial. Sem chatbot. Só eu.

Christophe Mazzola Founder & Trainer, Cyber Academy | Become the Code Father cyberacademy.net