ISMS na prática: o que ninguém te conta na implementação

Depois de passar anos implementando e consultando sobre sistemas de gestão de segurança da informação, aprendi que existe uma lacuna enorme entre o que a norma ISO 27001 descreve e o que acontece quando você tenta aplicar isso em uma empresa real.

Este post é sobre essa lacuna.

O problema com a abordagem padrão

A maioria das implementações de ISMS começa pelo lugar errado: pela documentação.

Times contratam consultoras, compram templates, passam meses criando políticas lindas em Word, constroem um repositório de documentos impecável — e então descobrem que ninguém lê, ninguém segue, e o ambiente de produção ainda está com a mesma superfície de ataque de antes.

Isso não é falha de comprometimento. É falha de sequência.

A sequência certa

Depois de diversas implementações, aprendi que a ordem correta é:

1. Inventário real, não aspiracional

Antes de qualquer política, você precisa saber o que existe. Não o que deveria existir — o que existe de fato. Isso significa:

Mapeamento de todos os ativos (inclua as shadow IT que “oficialmente” não existem)
Inventário de dados: onde estão, quem acessa, como trafegam
Mapeamento de integrações com terceiros (APIs, SaaS, sistemas legados)

A maioria das empresas se surpreende com o que encontra nessa fase. Surpresas são o objetivo — elas revelam o risco real.

2. Análise de risco com o time técnico, não para o time técnico

Análise de risco feita por consultores externos e entregue em relatório para o time técnico não funciona. O time técnico precisa participar da análise, não receber o resultado.

Por quê? Porque o time técnico tem contexto que nenhum consultor tem. E porque análise de risco que o time não participou é análise de risco que o time vai ignorar.

3. Controles que funcionam na realidade operacional

Controles de segurança precisam ser compatíveis com a realidade operacional da empresa. Um controle que torna o trabalho impossível vai ser contornado. E um controle contornado é pior que nenhum controle — dá sensação falsa de segurança.

# Exemplo: MFA obrigatório que ninguém usa porque quebra o workflow
# vs MFA integrado ao SSO que "simplesmente funciona"

O segundo é melhor mesmo sendo mais complexo de implementar.

O que a ISO 27001 não te conta

A norma define o que, não o como. E o como é 90% do trabalho.

Alguns exemplos:

Gestão de incidentes: A norma diz que você precisa ter um processo. O que ela não diz é que esse processo precisa ser simples o suficiente para funcionar às 3h da manhã com um engenheiro cansado. Se o runbook tem mais de uma página, ele não vai ser seguido na hora do incidente.

Continuidade de negócio: Planos de continuidade que nunca foram testados não são planos — são ficção científica cara. Teste regular e realista é o único jeito de saber se funciona.

Gestão de fornecedores: Este é o controle mais ignorado nas implementações que vejo. Terceiros com acesso aos seus sistemas são parte do seu perímetro de segurança, independente do que diz o contrato.

O que funciona

Depois de muitas implementações, o que consistentemente funciona:

Começar pelo risco, não pela documentação
Envolver o time técnico como protagonista, não como receptor
Controles graduais que se encaixam no workflow existente
Métricas operacionais reais (tempo de resposta a incidente, cobertura de patches, taxa de phishing bem-sucedido)
Revisões regulares e honestas — incluindo as coisas que não funcionaram

A pergunta certa

Quando avaliamos uma implementação de ISMS, a pergunta não é “temos a documentação em ordem?”. A pergunta é:

Se um incidente sério acontecer hoje, estamos preparados para responder?

Se a resposta for não — e na maioria das empresas é não, independente da documentação — então o ISMS ainda tem trabalho a fazer.

Este é o tipo de trabalho que fazemos na INIT4: implementações de SGSI que funcionam no mundo real, não só no papel. Se quiser conversar sobre a realidade de segurança da sua empresa, entre em contato.