Redigir uma Declaração de Aplicabilidade que resista à auditoria

A cláusula 6.1.3(d) da ISO/IEC 27001 exige uma Declaração de Aplicabilidade: um documento que lista os controles necessários, explica por que foram incluídos, informa se estão implementados e por que qualquer um dos 93 controles do Anexo A foi excluído. Parece um documento administrativo. Na prática, ela é a ponte entre a sua avaliação de riscos e os seus controles, e os auditores de certificação a leem com atenção, porque uma Declaração fraca geralmente indica um processo de riscos fraco por trás dela.

O que ela deve conter

Para cada controle do Anexo A, e para quaisquer controles próprios:

1. Aplicável ou não.
2. A justificativa para inclusão: geralmente os riscos que ele trata, um requisito legal ou contratual, ou uma decisão de negócio.
3. Status de implementação: implementado, parcialmente implementado ou planejado.
4. A justificativa para exclusão, se excluído.

A maioria das Declarações acrescenta uma breve descrição de como cada controle é implementado e uma referência à política ou ao procedimento. Isso não é estritamente exigido, mas torna as auditorias muito mais rápidas.

Justificando a inclusão

Vincule cada controle a algo concreto: um risco no seu registro, um requisito legal (Art. 32 do RGPD [GDPR], NIS2, regulamentação setorial), um contrato ou uma exigência de cliente. "Boa prática" é uma justificativa fraca; "trata os riscos R-12 e R-17 e é exigido pelas nossas obrigações da NIS2" é uma forte. Vincular controles a requisitos legais também ajuda quando você responde a vários frameworks: nossas páginas de requisitos mostram quais outros frameworks cada controle do Anexo A mapeia, por exemplo A.8.24 uso de criptografia.

Justificando a exclusão

As exclusões são permitidas, mas cada uma precisa de um motivo que os auditores possam testar. Bons motivos:

• A atividade não ocorre no escopo. Sem desenvolvimento terceirizado: A.8.30 excluído.
• O risco não existe no escopo. Uma organização totalmente remota, sem escritórios, pode excluir alguns controles físicos do A.7, mas não aqueles que cobrem equipamentos e mídias, onde quer que estejam.

Motivos fracos: "não é relevante", "tratado pela TI", "o provedor de nuvem faz isso". Se um fornecedor executa o controle, ele continua aplicável; você o gerencia por meio de controles de fornecedores.

Achados comuns de auditoria

• A Declaração não corresponde ao plano de tratamento de riscos. Os controles escolhidos no tratamento de riscos devem constar na Declaração, e vice-versa.
• Controles implementados sem evidências. Marcar um controle como implementado leva a um pedido de comprovação.
• Linguagem de modelo. Descrições copiadas de um modelo que não correspondem ao que você de fato faz.
• Versões desatualizadas. Uma Declaração que ainda lista a numeração do Anexo A de 2013, ou que não foi atualizada após uma mudança significativa.

Uma estrutura prática

Uma linha por controle: ID e título, aplicável (sim/não), motivo (riscos, requisitos legais e contratuais), status, uma descrição de uma linha de como é feito, o responsável e a referência à evidência. Mantenha-a em uma planilha ou na sua ferramenta de GRC, sob controle de documentos, e revise-a a cada avaliação de riscos.

Mantendo a Declaração atualizada

Uma Declaração escrita para a primeira certificação e nunca mais revisada torna-se um achado na próxima auditoria. Mantenha-a atual, atualizando-a sempre que:

• a avaliação de riscos alterar os controles selecionados;
• o escopo mudar (um novo produto, escritório ou provedor de nuvem);
• o status de implementação de um controle mudar;
• um novo requisito legal ou contratual se aplicar (por exemplo, a NIS2 ou o contrato de um cliente).

Registre a versão, a data e o aprovador a cada vez.

Principais conclusões

• Cada controle do Anexo A precisa de uma decisão e de um motivo, inclusive as exclusões.
• Vincule as inclusões a riscos específicos e a requisitos legais ou contratuais.
• Mantenha a Declaração consistente com o plano de tratamento de riscos e atualizada.

Atendendo a vários frameworks ao mesmo tempo

Se você também responde à SOC 2, NIS2 ou PCI DSS, acrescente uma coluna para os requisitos correspondentes de cada um. A Declaração passa então a ser a base de um conjunto comum de controles; nosso post sobre um conjunto de controles para SOC 2 e ISO 27001 mostra a abordagem, e a análise de lacunas lista cada controle do Anexo A em relação a qualquer outro framework. O guia da ISO 27001 cobre o restante da certificação.

Perguntas

Dá para excluir controles do Anexo A na ISO 27001?

Sim, se a exclusão for justificada, normalmente porque o risco não existe no seu escopo (por exemplo, desenvolvimento terceirizado quando você não terceiriza o desenvolvimento). As exclusões devem ser justificadas na Declaração de Aplicabilidade.

O que a Declaração de Aplicabilidade deve conter?

A cláusula 6.1.3(d) da ISO 27001 exige os controles necessários, a justificativa para incluí-los, se eles estão implementados e a justificativa para excluir quaisquer controles do Anexo A.

A Declaração de Aplicabilidade é compartilhada com clientes?

Normalmente não na íntegra; trata-se de um documento interno revisado pelo organismo certificador. Algumas organizações compartilham um resumo com clientes, sob NDA, para mostrar quais controles se aplicam.