A norma ISO 27001 é a referência internacional para a gestão da segurança da informação. Dentro do seu sistema de gestão, a Declaração de Aplicabilidade ocupa um lugar central. É o primeiro documento que o auditor consulta no momento da certificação e o ponto onde se liga tudo o que a organização decidiu fazer para proteger a sua informação.
Neste artigo vais ver o que é a Declaração de Aplicabilidade, para que serve, o que deve conter e como elaborá-la passo a passo, com um exemplo de tabela para veres como fica.
O que é a Declaração de Aplicabilidade (SoA) da ISO 27001?
A Declaração de Aplicabilidade, conhecida pela sigla inglesa SoA (Statement of Applicability), é o documento que reúne todos os controlos de segurança do Anexo A da ISO 27001. Para cada um, indica se a organização o aplica ou não, com a respetiva justificação e o estado de implementação.
Por outras palavras, é a fotografia completa dos controlos que a tua organização decidiu implementar, dos que deixou de fora e das razões dessas escolhas. Na versão em vigor da norma, a ISO 27001 de 2022, o Anexo A reúne 93 controlos agrupados em 4 temas, por isso a SoA percorre esses 93 controlos um a um.
Convém não confundir a SoA com a análise de riscos. A análise de riscos identifica as ameaças a que a organização está exposta, ao passo que a SoA formaliza a decisão sobre que controlos aplicar para tratar esses riscos. São documentos distintos que trabalham em conjunto, e mais abaixo vais ver como se ligam.
Para que serve e porque é obrigatória?
A SoA cumpre várias funções dentro do SGSI. Três delas explicam a sua importância.
- Um documento obrigatório para a certificação: a própria norma exige-o. O requisito 6.1.3 d) da ISO 27001 de 2022 obriga a elaborar uma Declaração de Aplicabilidade que contenha os controlos necessários, a justificação da sua inclusão, o estado de implementação e o motivo da exclusão de qualquer controlo. Sem SoA não há certificação possível.
- A ligação entre a análise de riscos e os controlos: a SoA faz a ponte entre os riscos que identificaste e as medidas que puseste em prática para os tratar. Torna visível a rastreabilidade entre o que a norma pede e o que a organização faz na realidade.
- O guia principal do auditor: quando chega a auditoria, o auditor abre a SoA antes de qualquer outro documento, porque lhe dá um mapa completo do SGSI. A partir daí verifica se os controlos que dizes aplicar estão mesmo implementados e se as exclusões fazem sentido. Uma SoA fraca, sem justificações ou com exclusões sem fundamento, leva rapidamente a uma não conformidade.
O que deve conter a SoA?
A norma não impõe um formato específico. Por isso, podes usar o que melhor te encaixa, desde que reúna a informação necessária. Para cada controlo do Anexo A, a SoA deve refletir quatro coisas.
- O controlo e a sua descrição: a referência e o nome do controlo tal como aparece no Anexo A, por exemplo A.5.1 Políticas de segurança da informação.
- Se aplica ou não: a decisão de incluir ou excluir esse controlo no teu SGSI.
- A justificação: o motivo dessa decisão, quer o controlo seja aplicado quer seja descartado. Este ponto é decisivo, porque justificar as exclusões é o que o auditor mais analisa.
- O estado de implementação e as evidências: indica se o controlo está implementado, em desenvolvimento ou pendente, com a referência à política, ao procedimento ou à evidência que o sustenta.
Muitas organizações acrescentam colunas extra, como o responsável pelo controlo ou o risco que trata, para reforçar a rastreabilidade. Não é obrigatório, mas ajuda a manter o documento sob controlo.
Exemplo de tabela de uma SoA
É assim que costuma ficar uma Declaração de Aplicabilidade em formato de tabela. Este é um exemplo simplificado, com alguns controlos, para veres a estrutura.
| Controlo | Descrição | Aplica-se? | Justificação | Estado | Evidência |
|---|---|---|---|---|---|
| A.5.1 | Políticas de segurança da informação | Sim | Risco identificado na análise de riscos | Implementado | Política de SI v1.2 |
| A.5.7 | Inteligência sobre ameaças | Sim | Necessidade de antecipar ameaças externas | Em desenvolvimento | Procedimento de inteligência sobre ameaças |
| A.6.7 | Trabalho remoto | Sim | Parte dos colaboradores trabalha fora do escritório | Implementado | Política de trabalho remoto v2.0 |
| A.7.4 | Monitorização da segurança física | Não | A organização não dispõe de instalações próprias | Não aplicável | Justificação documentada |
| A.8.23 | Filtragem da web | Sim | Risco de acesso a sites maliciosos | Implementado | Configuração do proxy da empresa |
Como fazer uma Declaração de Aplicabilidade passo a passo?
Elaborar a SoA não é um trâmite isolado. Resulta de forma natural do trabalho de gestão de riscos feito previamente. Estes são os passos habituais para a construir.
1. Faz primeiro a análise e o tratamento de riscos
A SoA não é o ponto de partida do percurso. Resulta do trabalho feito previamente sobre os riscos. Antes de lhe pegares, precisas de ter identificados os teus ativos de informação, avaliados os riscos a que estão expostos e decididas as opções de tratamento para cada um. É nesse momento que se vê com clareza que controlos são precisos para reduzir cada risco.
Se tentares preencher a SoA sem este trabalho prévio, acabas por assinalar controlos às cegas e o auditor deteta-o de imediato, por não haver rastreabilidade entre os riscos identificados e os controlos escolhidos.
2. Seleciona os controlos aplicáveis do Anexo A
Com os riscos em cima da mesa, percorres os 93 controlos do Anexo A da versão 2022 e decides quais se aplicam à tua organização e quais não. A norma não obriga a implementá-los todos, apenas aqueles que o teu nível de risco justifique, por isso um controlo pode ficar de fora se não fizer sentido no teu contexto.
Tem em conta também que podes acrescentar controlos que não constem do Anexo A se a tua análise de riscos o exigir, já que o Anexo A é uma referência e não uma lista fechada.
3. Documenta a justificação, o estado e as evidências
Para cada controlo, anotas se se aplica ou não e o motivo dessa decisão. Nos que se aplicam, acrescentas o estado de implementação, se está implementado, em desenvolvimento ou pendente, e a referência à política, ao procedimento ou à evidência que o sustenta.
Não saltes a justificação das exclusões, porque é precisamente o que o auditor mais analisa. Excluir um controlo é perfeitamente válido, desde que expliques por que razão não se aplica à tua organização. Um motivo bem redigido vale mais do que uma lista de controlos assinalados sem explicação.
4. Revê e aprova o documento
Por fim, a SoA deve ser revista e aprovada pela máxima autoridade de segurança da organização antes de ser dada como válida. É essa aprovação formal que transforma o rascunho no documento de referência do SGSI.
A partir daí fica pronta para a auditoria. Convém, no entanto, lembrar que não se trata de uma versão definitiva para sempre. É a primeira de muitas, porque a SoA vai sendo atualizada ao longo do tempo.
Como é que o Factorial IT ajuda com a Declaração de Aplicabilidade?
Cada linha da SoA exige uma decisão e uma prova. Nos controlos organizacionais, essa prova é normalmente uma política ou um procedimento. Nos tecnológicos, depende do estado real dos equipamentos, das contas e das aplicações, e é aí que o documento fica desatualizado mais depressa.
O Factorial IT gere essa parte a partir de uma única plataforma ligada aos RH, e fornece dados a várias colunas da SoA.
- Justificações baseadas em dados: o inventário mostra quantos portáteis e telemóveis a empresa tem, com que sistemas operativos e quem trabalha fora do escritório. Com essa informação, decidir se se aplicam controlos como o trabalho remoto (6.7) ou os dispositivos terminais do utilizador (8.1) deixa de ser uma suposição, e a justificação passa a assentar em números.
- Controlos que passam de “em curso” a “implementado”: as atividades de monitorização (8.16) ficam muitas vezes a meio nas empresas sem um centro de operações de segurança próprio. O Factorial IT oferece serviços MDR com analistas que vigiam os equipamentos 24 horas por dia e respondem às ameaças, uma forma de cobrir esse controlo sem montar uma equipa interna.
- Correções para além do sistema operativo (8.8): a gestão de vulnerabilidades exige corrigir também as aplicações de terceiros, que são as mais esquecidas. Com o módulo de gestão de patches do EDR, as atualizações do software instalado são aplicadas de forma centralizada em todo o parque informático.
- Evidências com data: na coluna das evidências, a referência a um relatório exportado com o estado do parque numa data concreta tem muito mais peso do que o simples nome de um documento. O auditor pode compará-la de imediato com a situação atual.
Além disso, quando o parque muda, a plataforma reflete-o de imediato. Um novo tipo de dispositivo ou uma mudança na forma de trabalhar da equipa aparecem nos dados antes de aparecerem no documento, e esse é o sinal de que está na altura de rever a SoA.
