Reestruturação do sistema de gestão ISO/IEC 27001

O certificado está no site, a declaração de aplicabilidade tem os controles marcados, e a análise de risco é a do projeto de certificação — de antes da nuvem nova, do time remoto e do fornecedor que hoje tem acesso ao banco de dados. Em segurança da informação, sistema desatualizado protege o ambiente de ontem.

O que é reestruturar

Duas coisas ao mesmo tempo:

Tornar o sistema eficaz — que o risco tratado seja o risco que o time de TI perde o sono com. Controle que reduz probabilidade ou impacto de um incidente plausível, não controle declarado aplicável em bloco para fechar a lista do Anexo A.

Tornar o sistema eficiente — que a segurança não dependa de conferência manual na véspera da auditoria. Revisão de acesso feita a cada seis meses num sábado é evidência; revisão disparada por mudança de função é controle.

E a atualização para a versão vigente da norma e do Anexo A entra no mesmo projeto. Remapear controles em separado consome o mesmo esforço da reestruturação e não muda risco nenhum.

O que reestruturação NÃO é

Não é implantação. Você já tem inventário de ativos, política aprovada e um ciclo de auditoria rodando. Reimplantar significa parar a operação de segurança para reescrever documento — justamente o contrário do que se precisa.

Não é mentoria. A mentoria orienta o responsável pela segurança. Aqui a casa senta com TI e com as áreas donas da informação para refazer a análise de risco e podar o que foi declarado aplicável sem uso.

Não é comprar mais ferramenta. Ferramenta nova sobre processo quebrado gera mais alerta que ninguém trata. Se o incidente de hoje não vira melhoria do sistema, a próxima licença só aumenta o volume de ruído.

Onde o sistema ISO/IEC 27001 costuma perder força

Em segurança da informação, o sistema costuma nascer grande demais e desatualizar rápido. A análise de risco é do projeto de certificação, os controles do Anexo A foram declarados aplicáveis em bloco, e a operação de TI mudou desde então.

Sinais de que é hora de reestruturar:

• a declaração de aplicabilidade nunca foi revisitada
• o risco tratado não é o risco que o time de TI teme
• gestão de acesso é auditada por amostra e corrigida na véspera
• incidente de segurança não vira melhoria do sistema

Como funciona

1. Diagnóstico de maturidade. Comparamos a declaração de aplicabilidade com o que roda de fato e pegamos os incidentes do último ano: quantos tinham controle previsto, quantos viraram mudança no sistema, e quantos ninguém registrou.

2. Plano com prioridade, não com lista. A prioridade sai do impacto no negócio: primeiro o ativo cuja indisponibilidade ou vazamento para a empresa, depois o que atrasa, por último o que incomoda.

3. Reestruturação conduzida, com a sua equipe. Refazemos a análise de risco com as áreas donas da informação, cortamos da declaração o que foi marcado sem uso e ligamos a gestão de acesso ao evento que a dispara — admissão, mudança de função, desligamento.

4. Verificação antes da auditoria. Auditoria interna por quem não participou, com teste de controle de verdade: pedir um acesso que não deveria ser concedido e ver se o sistema recusa.

Quanto tempo leva

O que pesa é o tamanho do inventário de ativos e o número de fornecedores com acesso. Ambiente concentrado resolve rápido; muitos terceiros com credencial alongam, porque cada um é uma análise.

Em qual destes casos sua empresa se reconhece

Quatro situações distintas, e a diferença entre elas decide se o trabalho é revisar risco ou reconstruir o sistema inteiro. Veja em qual o seu ambiente se encaixa:

1. O sistema não entrega segurança. A certificação está mantida e os incidentes continuam acontecendo pelo mesmo caminho: acesso que sobrou, senha compartilhada, fornecedor sem contrato. Controle implantado que não reduziu risco nenhum é controle decorativo.

2. O sistema está desconectado da operação. A análise de risco descreve uma arquitetura que mudou, a declaração de aplicabilidade justifica exclusões que não se sustentam mais, e a revisão de acesso é feita por quem concede acesso.

3. A empresa mudou e o sistema não acompanhou. Nuvem nova, SaaS contratado por uma área sozinha, trabalho remoto, aquisição de outra empresa. O escopo continua o da certificação inicial.

4. O sistema foi abandonado. O responsável saiu, o comitê parou de se reunir e o sistema sobrevive de evidência produzida às vésperas da auditoria.

Em todos eles o sistema protege um ambiente que já não existe. O que muda é quanto a operação de TI andou desde a última análise de risco — e é essa defasagem que o diagnóstico de maturidade mede antes de qualquer proposta.