Documento de Aplicabilidade (SoA): Como Construir a Peça-Chave da Governança em ISO 27001 e ISO 27701

Atualmente estou implementando em uma empresa a ISO 27001 e 27701, e já participei da implantação da ISO 9001, 20.00-1 e 37301. A empresa definiu que precisaria dessas duas novas normas implantadas para aumentar a confiabilidade na empresa e melhorar sua adesão ao programa de LGPD interno. Diante disso, segue meu aprendizado.

Em projetos de implementação de normas de gestão da segurança da informação e privacidade, poucas exigências geram tantas dúvidas técnicas quanto o Documento de Aplicabilidade, mundialmente conhecido como Statement of Applicability (SoA). Frequentemente reduzido por engano a uma simples planilha de checagem, o SoA é, na realidade, a peça central de governança que conecta a visão estratégica do negócio, a avaliação de riscos e os controles operacionais de segurança e privacidade.

Para organizações que buscam certificação ou consolidação de seus Sistemas de Gestão de Segurança da Informação (SGSI) e Sistemas de Gestão da Privacidade da Informação (SGPI), o SoA funciona como a "carteira de identidade" do sistema de gestão. Ele declara formalmente quais salvaguardas foram adotadas, quais foram descartadas e o raciocínio técnico que sustenta cada decisão.

Neste artigo, detalharemos o papel prático do SoA, o ciclo de vida da seleção de controles, as armadilhas comuns em auditorias de certificação e o passo a passo para construir um documento dinâmico e auditável do zero.

O que é o SoA e Qual a Sua Finalidade Real?

O Documento de Aplicabilidade (SoA) é uma informação documentada obrigatória exigida por normas como a ABNT NBR ISO/IEC 27001 (requisito 6.1.3 d) e a ABNT NBR ISO/IEC 27701 (requisito 6.1.3 e). A sua finalidade primordial é servir de elo direto entre a avaliação de riscos conduzida pela empresa e os controles de segurança selecionados.

Enquanto os anexos normativos das ISOs apresentam catálogos de salvaguardas genéricas, o SoA traduz essa lista para a realidade específica da organização. Ele cumpre quatro propósitos cruciais:

1. Garantir a não omissão de salvaguardas: Assegura que nenhum controle necessário para mitigar riscos identificados tenha sido ignorado involuntariamente.
2. Fundamentar inclusões e exclusões: Formaliza os motivos técnicos, operacionais, contratuais ou legais que levaram à adoção ou ao descarte de cada controle.
3. Demonstrar transparência para auditoria e governança: Fornece aos auditores internos, externos e à alta direção uma visão precisa da cobertura de segurança.
4. Estabelecer a linha de base operacional: Mapeia o status atual de implementação de cada medida de segurança ou privacidade.

Listar Controles vs. Avaliar Aplicabilidade: A Diferença Prática

Um dos erros mais graves na gestão de normas ISO é tratar o SoA como um inventário estático. Existe uma grande diferença entre simplesmente relacionar controles e efetivamente avaliar a sua aplicabilidade no contexto do negócio.

• Listar controles (Checklist genérico): Ocorre quando a equipe pega os 93 controles da ISO/IEC 27001:2022 ou os controles da ISO/IEC 27701 e marca "sim" ou "não" de maneira mecânica, sem rastreabilidade com o inventário de ativos ou com a matriz de riscos.
• Avaliar aplicabilidade (Gestão real de riscos): Exige analisar o contexto da organização, as ameaças reais sobre os ativos de informação, as obrigações regulatórias (como a LGPD) e os requisitos de partes interessadas.

Se uma empresa opera 100% em nuvem e não mantém servidores físicos locais, a declaração de não aplicabilidade de controles de segurança física de datacenter deve ser derivada do contexto e do contrato de compartilhamento de responsabilidades com o provedor cloud e não de um palpite do gestor.

O Ciclo de Vida: Do Contexto Organizacional à Evidência Auditável

O SoA não surge no vácuo; ele é o resultado final de uma cadeia estruturada de governança. A integração entre os elementos de um sistema de gestão funciona em fluxo contínuo:

1. Contexto da Organização (Seção 4): Definição das partes interessadas, escopo do sistema de gestão, processos de negócio e requisitos legais.
2. Avaliação de Riscos (Seção 6.1.2): Identificação de ativos, ameaças e vulnerabilidades, determinação da probabilidade e do impacto para definir o nível de risco.
3. Tratamento de Riscos e Seleção de Controles (Seção 6.1.3): Definição da estratégia para lidar com o risco (mitigar, transferir, evitar ou aceitar) e determinação das medidas necessárias.
4. Mapeamento com o Anexo A e SoA: Comparação dos controles escolhidos com a referência normativa do Anexo A para registrar a aplicabilidade, o status e as justificativas.
5. Implementação e Operação (Seção 8): Execução do plano de tratamento e operação continuada dos processos de segurança.
6. Geração de Evidências Auditáveis: Produção de artefatos (registros, logs, atas, políticas) que comprovam que o controle não apenas existe no papel, mas funciona na prática.
7. Validação do Proprietário do Risco ( Risk Owner ): Formalização da aceitação dos riscos residuais e aprovação do plano pela alta gestão.

Como Justificar Controles Aplicáveis e Não Aplicáveis

As normas ISO/IEC 27001 e ISO/IEC 27701 exigem explicitamente que o SoA inclua justificativas tanto para as inclusões quanto para as exclusões de controles.

1. Justificando Controles Aplicáveis

Não basta declarar que um controle é aplicável; é preciso registrar a motivação técnica. As justificativas padrão para inclusão envolvem:

• Mitigação de risco: Necessidade de reduzir o nível de risco de um ativo crítico até um limite aceitável.
• Requisito legal ou regulatório: Exigência expressa de legislações como a LGPD Ou regulamentações setoriais (ex.: BACEN, ANPD).
• Obrigatoriedade contratual: Requisitos estabelecidos em acordos de nível de serviço (SLA) com clientes ou parceiros comerciais.
• Boas práticas e diretrizes internas: Políticas estabelecidas pela alta direção para preservar a reputação do negócio.

2. Justificando Controles Não Aplicáveis (Exclusões)

As exclusões devem ser raras e extremamente bem fundamentadas. Aceita-se a exclusão quando:

• Inexistência do processo ou ativo no escopo: Por exemplo, excluir o controle de "Desenvolvimento Seguro" (Secure Coding) caso a empresa atue apenas como revendedora e não desenvolva software ou scripts internamente.
• Transferência total de responsabilidade: Quando o controle físico é assumido por um fornecedor de infraestrutura em nuvem pública (desde que auditado e comprovado por relatórios independentes como SOC 2 ou ISO 27001 do provedor).

Atenção: Declarar um controle como "não aplicável" apenas porque a empresa ainda não teve verba ou tempo para implementá-lo é uma infração às regras da norma. Se o risco existe, o controle é aplicável, e seu status deve constar como "não implementado" ou "em planejamento".

Declarado vs. Implementado vs. Operacional vs. Comprovado

Para evitar uma gestão meramente documental, os profissionais de compliance e auditoria devem avaliar a maturidade de cada controle em quatro níveis operacionais:

• Declarado: O controle está formalizado em políticas, manuais ou na própria planilha de SoA. (Maturidade Inicial)
• Implementado: A ferramenta tecnológica foi adquirida ou o processo foi desenhado e configurado no ambiente. (Maturidade Intermediária)
• Operacional: O controle roda na rotina diária das equipes, com papéis e responsabilidades definidos. (Maturidade Avançada)
• Comprovado por Evidências: A empresa mantém registros históricos (logs de acesso, atas de reunião de análise crítica, relatórios de varredura de vulnerabilidade, listas de presença em treinamentos) que provam a eficácia continuada do controle. (Maturidade Pronta para Auditoria)

Principais Erros na Elaboração do SoA e Suas Consequências

Experiências reais em auditorias revelam falhas recorrentes que comprometem o processo de certificação:

• Utilização de SoAs "Copiar e Colar": Baixar modelos genéricos da internet e tentar encaixar no negócio sem passar pela avaliação de riscos.
• Desalinhamento com a Matriz de Riscos: Apontar no SoA que a criptografia é aplicável, mas não ter nenhum risco registrado na matriz que seja mitigado pela criptografia.
• Exclusão de controles sem fundamentação técnica: Excluir controles sob a alegação de "baixo orçamento" ou "dificuldade de implementação.
• Falta de atualização do documento: Manter a versão original criada na consultoria inicial, ignorando mudanças tecnológicas, novas contratações ou alterações regulatórias.

Consequências Práticas

Erros no SoA resultam na emissão de Não Conformidades Maiores durante auditorias externas de certificação, impedindo a recomendação do selo ISO. Além disso, criam uma falsa sensação de segurança, deixando brechas operacionais expostas que podem levar a vazamentos de dados, sanções administrativas e perda de contratos relevantes.

O SoA em Auditorias de Certificação (Stage 1 e Stage 2)

Durante o processo de certificação ISO/IEC 27001 ou ISO/IEC 27701, o auditor independente utiliza o SoA como o principal guia de trabalho:

• Auditoria de Estágio 1 (Stage 1): O auditor faz a análise documental preliminar. Ele verifica se a estrutura do SoA contempla todos os controles normativos, se as justificativas de exclusão fazem sentido frente ao escopo declarado e se o documento foi aprovado pela direção.
• Auditoria de Estágio 2 (Stage 2): O auditor vai para a validação prática. Ele seleciona uma amostragem dos controles declarados como "aplicáveis" no SoA e exige a comprovação de sua execução no dia a dia.
• Auditorias de Vigilância (Anuais) e Recertificação (Trienais): O auditor verifica se o SoA permaneceu vivo, se passou por revisões periódicas e se acompanhou as mudanças da empresa.

O SoA como Pilar Integrado de Governança, GRC e IRM

No contexto moderno de GRC (Governança, Risco e Conformidade) e IRM (Integrated Risk Management), o SoA não deve ser trabalhado isoladamente. Uma abordagem madura conecta a estrutura do SoA a uma plataforma única de gestão.

Essa integração permite a reutilização inteligente de evidências: uma mesma evidência de controle de acesso ou backup pode servir simultaneamente para comprovar conformidade com a ISO 27001, atender a requisitos da ISO 27701, fundamentar relatórios da LGPD e responder a questionários de due diligence de clientes, eliminando a duplicidade de esforço operacional.

Aplicação do SoA no Ecossistema de Normas ISO

É fundamental esclarecer uma confusão comum no mercado sobre quais normas possuem o requisito formal do SoA.

+-------------------------------------------------------------------------+
|                  NORMAS QUE EXIGEM O SOA / ANEXO A                      |
|  • ISO/IEC 27001 (Segurança da Informação)                              |
|  • ISO/IEC 27701 (Privacidade da Informação / SGPI)                     |
|  • ISO/IEC 42001 (Gestão de Inteligência Artificial)                     |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  NORMAS SEM ANEXO A / SOA EXPRÉSSO                      |
|  • ISO 9001 (Qualidade)                                                 |
|  • ISO/IEC 20000-1 (Gestão de Serviços de TI)                           |
|  • ISO 22301 (Continuidade de Negócios)                                 |
+-------------------------------------------------------------------------+

Conforme as diretrizes de integração de sistemas de gestão ISO, apenas as normas ISO/IEC 27001, ISO/IEC 27701 e ISO/IEC 42001, essa terceira não sendo foco desse artigo, possuem Anexo A e exigência formal de Declaração de Aplicabilidade (SoA). Normas tradicionais como ISO 9001, ISO 22301 e ISO/IEC 20000-1 usam a Estrutura de Alto Nível (Anexo SL), mas não possuem Anexo A nem SoA.

Contudo, quando a organização adota um Sistema de Gestão Integrado (SGI), as abordagens se complementam. Por exemplo, o requisito de Política de Segurança da Informação previsto no capítulo 8 da ISO 20000-1 ou os planos de continuidade da ISO 22301 utilizam a estrutura de controles do SoA da ISO 27001 como mecanismo de entrega técnica.

Relação Direta: ISO/IEC 27001, Análise de Riscos e Anexo A

A versão da norma ABNT NBR ISO/IEC 27001:2022 reestruturou seu Anexo A em 93 controles, agrupados em 4 domínios estruturais:

1. Controles Organizacionais (37 controles): Políticas, gestão de ativos, relacionamento com fornecedores, resposta a incidentes.
2. Controles de Pessoas (8 controles): Triagem, conscientização, treinamento, encerramento de contrato.
3. Controles Físicos (14 controles): Perímetros de segurança, monitoramento físico, proteção de equipamentos.
4. Controles Tecnológicos (34 controles): Controle de acesso, criptografia, prevenção contra vazamento de dados, gestão de vulnerabilidades.

A análise de riscos determina a necessidade do controle, o Anexo A serve como lista de verificação exaustiva para evitar omissões, e o SoA consolida o resultado do cruzamento entre ambos.

SoA, Privacidade e a LGPD: A Camada da ISO/IEC 27701

A publicação da norma ISO/IEC 27701 (referência internacional para Sistemas de Gestão da Privacidade da Informação - SGPI) expandiu a atuação do SoA para abranger os dados pessoais (PII).

Organizações que buscam adequação técnica e jurídica à LGPD (Lei Geral de Proteção de Dados Pessoais) ou ao GDPR encontram na ISO 27701 uma estrutura para expandir a Declaração de Aplicabilidade, agregando controles específicos para papéis de Controladores e Operadores de dados.

A ISO Substitui a Legislação?

Não. É indispensável destacar que a certificação ISO/IEC 27001 ou ISO/IEC 27701 demonstra governança e boas práticas de mercado, mas não substitui as obrigações legais impostas pela LGPD ou autoridades como a ANPD. O SoA de privacidade auxilia na operacionalização dos princípios da lei (como Privacy by Design, gestão de direitos dos titulares e registro de bases legais), funcionando como evidência robusta de responsabilidade e prestação de contas (accountability).

Passo a Passo Prático: Como Elaborar um SoA do Zero

Para estruturar um Documento de Aplicabilidade seguro e pronto para auditoria, siga este roteiro de implementação:

Passo 1: Delimitação do Escopo e Contexto

Defina claramente as fronteiras do SGSI/SGPI (unidades de negócio, produtos, infraestruturas físicas e em nuvem) e mapeie as partes interessadas.

Passo 2: Execução da Avaliação de Riscos

Realize a identificação e análise de riscos sobre os ativos de informação compreendidos no escopo, definindo os níveis de risco antes e depois dos tratamentos previstos.

Passo 3: Mapeamento de Requisitos Legais e Contratuais

Catalogue todas as obrigações regulatórias (LGPD, leis setoriais) e cláusulas contratuais firmadas com clientes que exijam salvaguardas específicas.

Passo 4: Cruzamento com o Anexo A (ISO 27001 e ISO 27701)

Percorra cada um dos controles dos anexos normativos, comparando-os com as necessidades de tratamento de risco e os requisitos legais mapeados.

Passo 5: Registro das Justificativas e Status

Preencha a matriz de SoA detalhando: aplicabilidade (Sim/Não), justificativa técnica clara, status atual de implementação, risco associado e link para a evidência documental.

Passo 6: Aprovação Formal pelos Risk Owners e Alta Direção

Submeta o documento final à revisão e aprovação dos proprietários dos riscos e da alta administração, garantindo o aceite formal dos riscos residuais.

Por que o SoA Deve Ser Tratado como um Documento Vivo?

Um erro fatal em projetos de governança é arquivar o SoA após a conquista da certificação. O SoA é um documento dinâmico e deve evoluir continuamente.

Sempre que a organização passar por mudanças significativas, como a migração para novas tecnologias, lançamento de sistemas, reestruturação de processos, alteração na legislação ou identificação de novas ameaças,, o SoA deve ser revisado e atualizado. A manutenção atualizada do SoA garante que a gestão de riscos continue acompanhando o ritmo de crescimento do negócio.

Exemplo Prático de Matriz de SoA (Estrutura Fictícia)

Abaixo, apresentamos um modelo simplificado de como as informações devem ser organizadas na matriz de SoA da sua empresa:

💡 Precisa de apoio especializado para estruturar o SoA ou acelerar a certificação ISO da sua empresa? Converse com os nossos consultores e descubra como nossas soluções de consultoria e sistemas podem simplificar a sua governança.