Get 4 FREE months of Conformio to implement ISO 27001

Explanação da terminologia básica das normas ISO

Quando ministro vários treinamentos de ISO 27001 e ISO 22301, sempre ocorre que um dos assuntos mais abordados é sobre quais políticas e procedimentos precisam ser documentados, e quais não.

Claro, existem alguns outros assuntos acalorados, mas muitos destes acontecem porque para alguém novo no mundo ISO (não apenas na ISO 27001 e ISO 22301, mas também na ISO 9001, ISO 14001, ISO 20000, etc.) não é fácil entender alguns vocábulos específicos para estas normas – aqui está uma explanação dos termos que causam as dúvidas mais comuns.

Quais políticas e procedimentos precisam ser documentados?

Quando você vê as palavras política ou procedimento em uma norma ISO, isto não significa que tal documento precisa ser escrito. Uma política ou um procedimento precisa ser escrito apenas se a palavra documentado encontra-se associada a ela.

Por exemplo, a Política de controle de acesso do controle A.9.1.1 da ISO 27001 precisa ser escrita por que o controle diz“… política deve ser estabelecida, documentada e ….” ao contrário da Política de cópias de segurança, que não precisa ser escrita porque no controle A.12.3.1 da ISO 27001 não há menção à palavra documentada.

Por que as normas ISO mencionam as palavras política ou um procedimento se eles não precisam ser documentados? Porque a política ou um procedimento poderia também ser expressado verbalmente, sem ser escrito. Por exemplo, você pode definir um procedimento simples (como atender o telefone) de forma bem precisa acordando verbalmente com todos os participantes sobre como ele precisa ser feito – você não precisa escrever um documento para ele. Da mesma forma, algumas políticas podem ser parte da configuração de sistemas de informação (e.g., a política de senhas) sem haver um documento separado para ela.

A diferença entre deve (shall) e convém (should)

Você precisa implementar certos requisitos da norma apenas se você ver a palavra deve (shall) – quando você vê deveria (should) ele não é obrigatório. Esta diferença é a mais óbvia entre as normas que especificam requisitos (i.e., ISO 27001) e as normas que são apenas orientações (i.e., ISO 27002) – na ISO 27001 você verá repetidamente a palavra deve, enquanto que a ISO 27002 primariamente usa deveria.

Isto ocorre porque a ISO 27001 é uma norma contra a qual sua organização pode ser certificada, assim ela especifica o que você deve fazer para estar em conformidade com ela; a ISO 27002 é apena um guia para a implementação, então é algo que você pode ou não usar. Veja este artigo para uma explanação mais detalhada: Semelhanças e diferenças entre a ISO 27001 e a ISO 27002.

Quais partes da norma são obrigatórias?

Basicamente, apenas a parte principal da norma (clausulas de 1 a 10) é obrigatória, enquanto os anexos devem ser implementados apenas se eles tem a palavra normativa associada a eles.

Por exemplo, o Anexo A da ISO 27001:2013 é chamado “Anexo A (normativo) Referência aos controles e objetivos de controle,” o que significa que ele deve ser implementado (claro, a implementação de cada controle depende do resultado da avaliação de riscos). Ao contrário disso, os Anexos A e B da ISO 9001:2008 são informativos, o que significa que eles não são mandatórios – eles exitem apenas para dar a você alguma informação adicional.

O que você pode excluir do escopo?

Atenção ao ver a palavra escope, porque ela é definida diferentemente de uma norma ISO para outra.

Por exemplo, ao definir seu escopo na ISO 27001, você não deveria ler apenas a cláusula 1 chamada “Escope,” mas também a cláusula 4.3 chamada “Determinando o escopo do sistema de gestão de segurança da informação.” Quando a palavra escope é mencionada na ISO 27001, isso não significa que você pode excluir alguns controles porque você não gosta deles ou porque você pensa que eles são muito dispendiosos; a exclusão dos controles é permitida apenas após sua avaliação de riscos – uma vez que você perceba que não existem riscos que requeiram certos controles. Veja também Como definir o escopo do SGSI.

Por outro lado, exclusões do escopo na ISO 9001:2008 são muito melhor explicadas (cláusula 1.2 “Aplicação”) uma vez que estas exclusões são mais diretas – você pode decidir excluir certos requisitos da cláusula 7 sem ter que realizar algum tipo de análise primeiro.

Na ISO 22301, o escopo é definido nas cláusulas 1 “Escope” e 4.3.2 “Escopo do SGCN.” Ao contrário da ISO 27001, as exclusões do escopo não são baseadas na avaliação de risco – para definir as exclusões da ISO 22301, você tem que ter certeza de que elas não afetarão a resiliência organizacional; então, algum tipo de análise prévia será requerida.

Torne sua implementação mais fácil

Qual o propósito de tudo isto? Se você entender como as normas ISO são escritas, você terá um trabalho muito mais fácil ao implementá-las. Por exemplo, você não precisa de um documento cada vez que uma política ou um procedimento é mencionado; você não precisa implementar algo a menos que ele diga deve; você não precisa implementar todos os anexos, apenas aqueles que são normativos; e finalmente, se você definir seu escopo corretamente logo no início você terá um trabalho muito mais fácil durante toda a implementação.

Então tenha certeza de ler as normas corretamente.

Clique aqui para ver uma lista de Documentos Obrigatórios da ISO 27001, um artigo que provê uma breve explanação do propósito de cada documento obrigatório.

Nós agradecemos a Rhand Leal pela tradução para o português.

Advisera Dejan Kosutic
Autor
Dejan Kosutic
Leading expert on cybersecurity & information security and the author of several books, articles, webinars, and courses. As a premier expert, Dejan founded Advisera to help small and medium businesses obtain the resources they need to become compliant with EU regulations and ISO standards. He believes that making complex frameworks easy to understand and simple to use creates a competitive advantage for Advisera's clients, and that AI technology is crucial for achieving this.

As an ISO 27001 and NIS 2 expert, Dejan helps companies find the best path to compliance by eliminating overhead and adapting the implementation to their size and industry specifics.