O que é uma Declaração de Aplicabilidade (SoA)?
A Declaração de Aplicabilidade (SoA) é um documento obrigatório da ISO 27001 que lista todos os 93 controles do Anexo A e explica se cada controle está incluído no…
Visão geral
A Declaração de Aplicabilidade (SoA) é um documento obrigatório da ISO 27001 que lista todos os 93 controles do Anexo A e explica se cada controle está incluído no seu SGSI ou excluído. Para os controles incluídos, descreve como são implementados. Para os excluídos, fornece justificativa para a exclusão.
O que significa na prática
A SoA é o seu projeto de seleção de controles – ela conecta os resultados da avaliação de riscos aos controles de segurança específicos que você escolheu implementar. Os auditores a utilizam como roteiro para verificar se o seu SGSI aborda os riscos identificados de forma adequada.
Exemplo do mundo real: Sua avaliação de riscos identifica ransomware como uma ameaça crítica. Sua SoA mostraria o controle A.8.7 (Proteção contra malware) como "Incluído" com detalhes de implementação como "Software de detecção e resposta em endpoints implantado em todos os dispositivos com gerenciamento centralizado", enquanto o controle A.7.4 (Monitoramento de segurança física) poderia ser "Excluído – organização é exclusivamente em nuvem, sem data center físico".
Por que a SoA é importante para a ISO 27001
Requisito obrigatório
A Cláusula 6.1.3(d) da ISO 27001 exige explicitamente a manutenção de "uma Declaração de Aplicabilidade contendo os controles necessários e a justificativa para inclusões e exclusões". Você não pode obter a certificação sem uma SoA completa e precisa.
Demonstra abordagem baseada em riscos
A SoA prova que você não está implementando controles aleatoriamente ou aplicando modelos cegamente. Ela mostra como cada decisão de controle está vinculada à sua avaliação de riscos.
Roteiro para auditoria
Os auditores usam sua SoA para planejar o que verificarão durante as auditorias de certificação. Controles incluídos precisam de evidências de implementação e eficácia. Exclusões devem ser justificadas com base na avaliação de riscos ou no contexto organizacional.
Gestão de mudanças
À medida que os riscos evoluem, sua SoA deve ser atualizada para refletir novos requisitos de controle ou permitir que controles anteriormente excluídos sejam removidos se os riscos diminuírem.
Achado comum em auditorias: Justificativas da SoA que não estão alinhadas com os resultados da avaliação de riscos. Por exemplo, excluir controles de backup (A.8.13) enquanto sua avaliação de riscos identifica perda de dados como um alto risco resultará em não conformidade.
O que a SoA deve incluir
Lista completa de controles
Todos os 93 controles do Anexo A da ISO 27001:2022 devem constar na sua SoA, organizados por tema:
- Controles organizacionais: A.5.1 até A.5.37 (37 controles)
- Controles de pessoas: A.6.1 até A.6.8 (8 controles)
- Controles físicos: A.7.1 até A.7.14 (14 controles)
- Controles tecnológicos: A.8.1 até A.8.34 (34 controles)
Status de inclusão/exclusão
Para cada controle, declare claramente se ele está incluído no seu SGSI ou excluído. Evite status ambíguos como "parcialmente aplicável" – os controles estão dentro ou fora.
Descrição de implementação (para controles incluídos)
Descreva brevemente como você implementa cada controle incluído. Inclua:
- Políticas, procedimentos ou tecnologias específicas utilizadas
- Quem é responsável pelo controle
- Onde encontrar evidências da implementação
- Como o controle aborda os riscos identificados
Justificativa de exclusão (para controles excluídos)
Explique por que os controles excluídos não fazem parte do seu SGSI. Justificativas válidas:
- Baseada em riscos: "Nenhum risco em nossa avaliação requer este controle"
- Baseada no contexto: "Não aplicável – somos exclusivamente em nuvem, sem infraestrutura física"
- Legal/regulatória: "Proibido por leis de residência de dados em nossa jurisdição"
Qualidade da justificativa: Justificativas fortes de exclusão referenciam achados específicos da avaliação de riscos ou contexto organizacional. Justificativas fracas como "não relevante" ou "ainda não implementado" serão questionadas pelos auditores.
Estrutura e formato da SoA
Formato tabular (mais comum)
Uma tabela com colunas para:
- Número do controle (ex.: A.5.1)
- Nome do controle (ex.: "Políticas para segurança da informação")
- Status (Incluído / Excluído)
- Descrição da implementação ou justificativa de exclusão
- Referência de risco (vinculando ao registro de riscos)
- Localização da evidência (opcional, mas útil)
Formato narrativo
Algumas organizações preferem um documento narrativo descrevendo a implementação dos controles agrupados por tema. Menos comum, mas aceitável se abordar claramente todos os 93 controles.
Formato baseado em ferramentas
Plataformas de GRC e ferramentas de SGSI frequentemente geram SoAs automaticamente com base na seleção de controles e vinculação às avaliações de riscos. Estas ainda precisam de validação manual para garantir precisão.
Preferência do auditor: A maioria dos auditores prefere SoAs tabulares porque são fáceis de analisar e referenciar. Mantenha as descrições de implementação concisas (2-3 frases por controle) – procedimentos detalhados pertencem a documentos de procedimentos separados, não à SoA.
Criando sua SoA
Passo 1: Concluir a avaliação de riscos
Sua SoA é um resultado direto da avaliação de riscos. Identifique todos os riscos que requerem tratamento antes de determinar quais controles implementar.
Passo 2: Mapear controles para riscos
Para cada risco que requer tratamento, identifique quais controles do Anexo A o reduziriam a níveis aceitáveis. Um risco pode precisar de vários controles; um controle pode abordar vários riscos.
Passo 3: Determinar inclusão/exclusão
Controles que abordam riscos identificados são incluídos. Controles que não abordam nenhum dos seus riscos podem ser excluídos (com justificativa).
Passo 4: Descrever implementação
Para controles incluídos, documente como você os está implementando. Seja específico o suficiente para que os auditores entendam sua abordagem sem duplicar procedimentos inteiros.
Passo 5: Justificar exclusões
Para controles excluídos, explique por quê com base na sua avaliação de riscos ou contexto organizacional. Referencie achados específicos do seu registro de riscos sempre que possível.
Passo 6: Revisar e aprovar
A gestão deve revisar e aprovar formalmente a SoA, reconhecendo as decisões de seleção de controles e quaisquer riscos residuais.
Controle de versão: A SoA é um documento vivo que deve ser atualizado quando os riscos mudam, controles são adicionados ou modificados, ou exclusões são reconsideradas. Mantenha um histórico de versões mostrando quando e por que as mudanças ocorreram.
Erros comuns na SoA
Excluir muitos controles
Organizações às vezes excluem controles para reduzir o esforço de implementação. Os auditores examinam as exclusões cuidadosamente – se sua avaliação de riscos for minuciosa, a maioria dos controles deve ser incluída.
Descrições genéricas de implementação
Copiar descrições de controles da ISO 27002 sem descrever sua implementação real. Os auditores precisam entender o que você faz, não o que o padrão diz.
Falta de vínculo com riscos
Não conectar os controles de volta a riscos específicos na sua avaliação de riscos. Isso quebra a rastreabilidade e sugere que os controles foram selecionados arbitrariamente.
Cobertura incompleta
Esquecer de abordar todos os 93 controles. Mesmo que um controle pareça obviamente não aplicável, ele deve aparecer na SoA com justificativa de exclusão.
Sem ciclo de revisão
Criar a SoA uma vez durante a implementação inicial e nunca atualizá-la, apesar de mudanças organizacionais ou novos riscos.
Dica de eficiência: Use o ISMS Copilot para gerar um modelo de SoA com descrições comuns de implementação para o seu setor. Personalize a saída com base nos resultados específicos da sua avaliação de riscos e contexto.
SoA vs. outros documentos da ISO 27001
SoA vs. Plano de Tratamento de Riscos
O Plano de Tratamento de Riscos detalha como você implementará os controles selecionados (prazos, responsabilidades, recursos). A SoA declara quais controles são implementados e por quê. Os dois documentos são complementares.
SoA vs. Evidência de Controle
A SoA descreve quais controles você implementa. A evidência prova que os controles estão realmente operando de forma eficaz. Durante as auditorias, os auditores amostram controles da sua SoA e solicitam evidências correspondentes.
SoA vs. Políticas e Procedimentos
Políticas e procedimentos fornecem instruções detalhadas para implementar controles. A SoA resume em alto nível quais controles existem e como funcionam.
Como os auditores usam a SoA
Auditoria de Etapa 1 (revisão de documentação)
Os auditores verificam se sua SoA está completa (todos os 93 controles abordados), estruturada logicamente e alinhada com sua avaliação de riscos. Eles verificam se as justificativas para exclusões fazem sentido.
Auditoria de Etapa 2 (verificação de implementação)
Os auditores amostram controles da sua SoA e solicitam evidências de que estão implementados conforme descrito. Eles testarão controles em todos os quatro temas e áreas organizacionais dentro do escopo.
Gatilhos de não conformidade
Razões comuns para os auditores emitirem não conformidades relacionadas à SoA:
- Controles marcados como "incluídos" mas não implementados de fato
- Exclusões sem justificativa válida
- SoA não reflete os resultados reais da avaliação de riscos
- Controles faltantes (menos de 93 listados)
- Descrições de implementação muito vagas para verificação
Preparação para auditoria: Antes da auditoria de certificação, revise cada controle "incluído" na sua SoA e reúna evidências correspondentes. Se não conseguir encontrar evidências para um controle, implemente-o corretamente ou atualize a SoA para excluí-lo com justificativa.
Manutenção da SoA ao longo do tempo
Atualizações anuais da avaliação de riscos
Quando realizar reavaliações de riscos programadas, revise a SoA para determinar se as seleções de controles permanecem apropriadas. Novos riscos podem exigir controles anteriormente excluídos.
Mudanças organizacionais
Atualize a SoA quando:
- Nova tecnologia for implantada (pode exigir novos controles técnicos)
- O modelo de negócio mudar (ex.: migrar para a nuvem altera controles físicos)
- A expansão geográfica introduzir novos requisitos regulatórios
- Fusões ou aquisições mudarem o perfil de risco
Revisões desencadeadas por incidentes
Após incidentes de segurança significativos, revise se os controles existentes foram eficazes ou se controles adicionais (anteriormente excluídos) devem ser implementados.
Auditorias de vigilância
Os auditores verificarão durante as auditorias anuais de vigilância se a SoA foi mantida atualizada. Evidências de revisão regular demonstram que seu SGSI está ativo, e não abandonado após a certificação.
SoA e personalização de controles
O padrão permite adaptação
A ISO 27001 permite que as organizações implementem controles de forma diferente com base no tamanho, complexidade e risco. Sua SoA deve refletir sua implementação específica, não um modelo genérico.
Controles adicionais além do Anexo A
Se sua avaliação de riscos identificar riscos não adequadamente abordados pelos 93 controles padrão, você pode implementar controles adicionais. Liste-os na sua SoA ou em um documento suplementar.
Proporcionalidade importa
A implementação de "A.6.3 Treinamento de conscientização em segurança da informação" por uma startup de 10 pessoas será diferente da de uma empresa com 10.000 funcionários. Ambas podem ser conformes se forem apropriadas ao contexto e eficazes na redução de riscos.
Exemplo de implementação proporcional: Uma pequena empresa SaaS exclusivamente em nuvem pode excluir A.7.1-A.7.14 (controles físicos) justificando "Sem infraestrutura física – todos os sistemas operam na AWS com segurança gerenciada pelos controles SOC 2 do provedor de nuvem". Isso é aceitável se sua avaliação de riscos refletir a arquitetura cloud-first.
Conceitos relacionados
- Controles do Anexo A - Os 93 controles de segurança que sua SoA deve abordar
- Avaliação de Riscos - Processo que orienta a seleção de controles na sua SoA
- Tratamento de Riscos - Implementação de controles identificados na sua SoA
- Controle - As medidas de segurança que você seleciona na sua SoA
- Como começar a implementação da ISO 27001 usando IA
Obtendo ajuda
Acelere a criação da SoA com o ISMS Copilot. Gere descrições de implementação personalizadas, valide suas justificativas em relação aos resultados da avaliação de riscos e garanta que todos os 93 controles sejam devidamente abordados.