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 manter e gerir a SoA?
A SoA não se elabora uma vez e fica arquivada. É um documento vivo, que é preciso rever e atualizar sempre que muda algo relevante na organização, por exemplo quando surge um novo risco, se integra um ativo ou uma tecnologia, muda o contexto normativo ou se altera uma decisão de tratamento. Por isso convém manter um controlo de versões que registe cada alteração e quem a aprovou.
É aqui que muitas organizações encalham. Manter a SoA numa folha de cálculo torna-se incomportável assim que tens dezenas de controlos ativos, com os seus responsáveis, as suas evidências e os seus prazos a mudar ao mesmo tempo. É fácil o documento ficar desatualizado e chegares à auditoria com evidências caducadas ou controlos sem responsável atribuído.
É aqui que uma ferramenta de gestão de IT e conformidade como o Factorial IT faz a diferença, porque cobre e documenta boa parte dos controlos técnicos do Anexo A que aparecem na tua SoA.
- Inventário automático dos ativos de IT: sempre atualizado e exportável para a auditoria.
- Gestão de dispositivos (MDM): encriptação, antivírus e patches em Mac, Windows e Linux.
- Gestão de acessos: atribuição e revogação de permissões consoante a função de cada colaborador.
- Offboarding seguro: encerramento de todos os acessos ao registar uma saída no RH.
- Evidências de auditoria automáticas: prontas a exportar assim que o auditor as pedir.
Com os controlos implementados e as evidências recolhidas de forma contínua, manter a SoA atualizada deixa de ser uma corrida de última hora antes da auditoria.
