SoA Declaração de Aplicabilidade.

Por que a ISO 27001 torna a SoA obrigatória

A declaração de aplicabilidade é a ponte entre o seu trabalho sobre os riscos e os controlos que um auditor irá efetivamente inspecionar. A ISO/IEC 27001 deixa deliberadamente em aberto, no corpo da norma, quais controlos deve executar, porque a resposta certa depende do seu contexto e dos seus riscos. A SoA é onde fecha essa lacuna: para cada controlo de referência do Anexo A, regista se se aplica, a justificação para o incluir ou excluir, se já está implementado e onde reside a evidência de suporte. É um dos poucos documentos que a norma designa explicitamente como saída exigida, razão pela qual nenhuma auditoria de certificação avança sem ela.

Uma forma útil de pensar nisto é que a SoA transforma um catálogo de controlos genérico numa declaração sobre a sua organização especificamente. O conjunto de referência do Anexo A é o mesmo para todos. A sua SoA não é. Duas empresas certificadas de dimensão semelhante podem legitimamente excluir controlos diferentes, porque as suas apreciações de risco e o seu contexto operacional diferem. O documento existe para tornar essas escolhas visíveis e defensáveis em vez de implícitas.

Como a SoA se relaciona com a apreciação do risco e o tratamento do risco

A SoA não existe isoladamente. É o produto a jusante da apreciação do risco e do plano de tratamento do risco, e os três têm de concordar. A apreciação do risco identifica o que pode correr mal. O plano de tratamento do risco decide o que fazer em relação a cada risco, incluindo quais controlos aplicar. A SoA declara então, controlo a controlo, o que essa decisão significa face ao conjunto de referência do Anexo A. Quando um auditor lê a SoA, está na verdade a verificar que a linha que vai de um risco documentado a uma decisão de tratamento, depois a um controlo aplicado, e depois a evidência real, se mantém coerente de ponta a ponta.

As exclusões merecem cuidado especial. Marcar um controlo como não aplicável é legítimo, mas apenas com um motivo declarado e ligado ao seu contexto. «Não desenvolvemos software internamente» é uma base defensável para restringir certos controlos de desenvolvimento. «Não chegámos a fazê-lo» não é uma exclusão, é uma lacuna. Os auditores sondam as exclusões precisamente porque é aí que as organizações por vezes escondem trabalho por terminar.

O que os profissionais mantêm de facto

Tratar a SoA como um registo vivo em vez de uma folha de cálculo pontual é o que separa uma auditoria de acompanhamento tranquila de uma correria. Na prática, mantê-la bem é assim:

1. Mantenha uma linha por cada controlo do Anexo A, com aplicabilidade, justificação, estado de implementação e um apontador para a evidência que um auditor possa seguir sem si na sala.
2. Refaça a SoA sempre que a apreciação do risco ou o plano de tratamento mudarem, para que os três documentos nunca divirjam em silêncio.
3. Ligue cada apontador de evidência a algo real e atual: uma política, uma configuração, um ticket, um log, e não uma promessa de o produzir mais tarde.
4. Reveja o documento a uma cadência fixa e na revisão pela gestão, e não apenas nas semanas que antecedem uma auditoria.
5. Ao transitar entre versões da norma, remapeie a SoA face ao conjunto de controlos revisto e confirme que nada ficou pelo caminho entre controlos fundidos ou recém-introduzidos.

Feita desta forma, a SoA deixa de ser papelada de auditoria e torna-se o índice de todo o seu sistema de gestão da segurança da informação. É o primeiro documento que um auditor experiente pede, porque lhe indica onde reside tudo o resto.