Anexo A da ISO 27001: pôr os 93 controlos em funcionamento

O Anexo A dá às equipas de segurança um conjunto de referência útil. O seu valor operacional resulta de demonstrar por que razão um controlo se aplica, como é implementado e que evidências o sustentam no seu ambiente. Um registo com 93 indicadores de estado a verde não chega se ninguém conseguir explicar que sistemas esses indicadores abrangem.

Para um CTO, o desafio prático é traduzir a intenção dos controlos em trabalho de engenharia e de operações, sem transformar o sistema de gestão da segurança da informação numa burocracia paralela. As revisões de acessos devem utilizar dados reais de permissões. Os planos de recuperação devem refletir as dependências dos serviços. As avaliações de fornecedores devem incidir sobre os serviços que a empresa efetivamente consome.

Este guia explica como selecionar controlos, distribuir responsabilidades, definir implementações e testar as afirmações daí resultantes. As frequências de revisão e os exemplos de implementação apresentados são recomendações práticas, e não intervalos universais prescritos pela norma.

Compreender o que o Anexo A faz, e o que não faz

A ISO/IEC 27001:2022 contém 93 controlos no Anexo A, distribuídos por quatro temas. As cláusulas 4 a 10 contêm os requisitos do sistema de gestão: contexto da organização, liderança, planeamento, suporte, operação, avaliação do desempenho e melhoria. O Anexo A apoia a seleção de controlos; não substitui esses requisitos nem a sua avaliação de riscos.

A distinção é importante durante a implementação. Uma configuração de cópias de segurança pode suportar um controlo selecionado, mas não demonstra que definiu o âmbito do SGSI, avaliou os riscos, realizou uma auditoria interna ou concluiu a revisão pela gestão. Essas são atividades separadas, com evidências separadas.

A seleção de controlos baseia-se no risco. Determine os controlos necessários para tratar os seus riscos e compare-os depois com o Anexo A para verificar que nenhum controlo necessário foi omitido. Podem ser necessários controlos adicionais fora do Anexo A. Inversamente, uma exclusão justificada é possível; não existe nenhuma regra segundo a qual todas as organizações tenham de excluir algo ou implementar exatamente a mesma seleção.

A ISO/IEC 27002:2022 fornece orientações de implementação para os controlos. Os seus atributos ajudam a organizá-los por tipo de controlo, propriedade de segurança da informação, conceito de cibersegurança, capacidade operacional e domínio de segurança. São auxiliares de filtragem úteis, e não listas de verificação adicionais para a certificação. Consulte as normas licenciadas para obter a redação oficial.

Utilizar os quatro temas para encontrar os responsáveis certos

Os temas fornecem uma estrutura de navegação, e não quatro frentes de trabalho independentes. Um processo de saída de trabalhadores, por exemplo, liga responsabilidades laborais, administração de identidades, devolução de equipamentos e acesso a aplicações.

Controlos organizacionais: ligar a governação às decisões operacionais

Estes controlos abrangem políticas, responsabilidades, segregação de funções, ativos, classificação e tratamento da informação, governação de acessos, fornecedores, incidentes, continuidade, obrigações legais e atividades de revisão.

Comece por identificar onde são tomadas as decisões. Quem aprova um novo serviço de computação em nuvem? Quem atribui uma classificação à informação? Quem decide se um evento comunicado é um incidente? Uma política deve tornar essas decisões repetíveis e atribuir autoridade, em vez de apenas manifestar apoio à segurança.

A segurança dos fornecedores precisa de uma cadeia de evidências específica de cada serviço: a finalidade de negócio do serviço, a informação que trata, os riscos avaliados, as responsabilidades contratuais e a revisão contínua. O relatório de garantia de um fornecedor pode apoiar essa avaliação, mas o seu âmbito, período e responsabilidades do cliente têm de corresponder à sua utilização.

Do mesmo modo, a gestão de incidentes precisa de mais do que uma lista de contactos de emergência. Defina canais de comunicação, critérios de avaliação, autoridade de resposta, tratamento de evidências e atividades de aprendizagem. Registe os exercícios ou as respostas reais, incluindo as ações de seguimento e os respetivos responsáveis.

Controlos de pessoas: tornar os eventos laborais gatilhos fiáveis

Os oito controlos de pessoas abordam a verificação de antecedentes, os termos e condições de emprego, a sensibilização e formação, os processos disciplinares, as responsabilidades após alterações na relação laboral, a confidencialidade, o teletrabalho e a comunicação de eventos.

Integre-os nos fluxos de trabalho laborais existentes. Uma entrada exige as obrigações, os acessos e as instruções adequados. Uma mudança de função exige que as permissões sejam reavaliadas, e não simplesmente acrescentadas. Uma saída exige a remoção de acessos, a devolução de ativos e clareza sobre as responsabilidades de confidencialidade que se mantêm.

A responsabilidade abrange muitas vezes várias equipas. Os recursos humanos podem iniciar uma saída, os administradores de identidades desativam a conta central, os responsáveis pelas aplicações removem os acessos geridos localmente e uma chefia confirma a conclusão. Atribuir todo o processo à segurança esconde essas dependências.

As evidências úteis incluem registos de fluxos de trabalho aprovados, conclusão de formações e seguimento de atrasos, termos aceites e amostras de alterações na relação laboral. Restrinja o acesso às evidências sensíveis de recursos humanos; quem revê um controlo não precisa automaticamente de processos individuais completos.

Controlos físicos: documentar a sua fronteira e a do fornecedor

Os controlos físicos abordam instalações, entradas, monitorização, ameaças ambientais, áreas seguras, secretárias e ecrãs, equipamentos, suportes de dados, serviços de utilidade pública, cablagem, manutenção e eliminação.

Uma organização que privilegia a nuvem continua a ter de considerar a segurança física. Parte da implementação pode ser assegurada por um fornecedor de serviços de computação em nuvem, enquanto o acesso aos escritórios e os dispositivos dos trabalhadores continuam a ser da sua responsabilidade. Registe essa divisão, em vez de excluir automaticamente todo o tema.

Para as suas próprias instalações, identifique quem pode entrar, como são alterados os acessos, onde se encontra o equipamento sensível e como são tratados os visitantes. Para os dispositivos remotos, defina disposições de armazenamento, transporte, reparação e eliminação adequadas aos respetivos riscos.

As evidências podem incluir registos de autorização de acesso, procedimentos para visitantes, inventários de equipamentos e registos de eliminação. As evidências do fornecedor devem explicar as instalações e os serviços abrangidos; não devem ser tratadas como prova dos controlos dos seus escritórios ou portáteis.

Controlos tecnológicos: definir a cobertura antes de escolher ferramentas

O tema tecnológico abrange dispositivos terminais, acessos privilegiados, autenticação, acesso ao código-fonte, capacidade, software malicioso, vulnerabilidades, configurações, tratamento de dados, cópias de segurança, resiliência, registo de eventos, monitorização, redes, criptografia, desenvolvimento e gestão de alterações.

Comece pela cobertura dos sistemas. Uma política de identidades está incompleta se os acessos de produção, as contas de serviço ou uma aplicação gerida separadamente ficarem fora da sua implementação. Uma plataforma de registo de eventos está incompleta se os eventos críticos nunca lá chegarem ou se ninguém responder aos alertas.

No desenvolvimento de software, ligue os requisitos e as decisões de desenho à revisão de código, aos testes de segurança, à separação de ambientes, ao tratamento de dados de teste e à aprovação de versões. A modelação de ameaças pode ajudar a identificar requisitos de segurança antes da implementação. A profundidade dos testes deve acompanhar o risco e as obrigações; a ISO 27001 não impõe um calendário universal de testes de intrusão.

Na criptografia, distinga os dados em repouso dos dados em trânsito e documente a titularidade, o acesso, a recuperação, a rotação e a revogação das chaves. «Cifragem ativada» deixa por responder questões de implementação importantes.

O que mudou em 2022 e onde procurar lacunas

A edição de 2013 tinha 114 controlos distribuídos por 14 domínios. A edição de 2022 reorganizou-os em 93 controlos distribuídos por quatro temas, incluindo 11 controlos novos. Um número menor não significa menos trabalho de segurança: a consolidação pode colocar várias responsabilidades operacionais sob uma única referência.

Ao atualizar um registo antigo, preserve as implementações e as evidências subjacentes, em vez de apenas substituir identificadores. Verifique se o novo agrupamento altera a cobertura, as responsabilidades ou os testes necessários para sustentar o seu estado.

O prazo de transição para a certificação acreditada segundo a ISO/IEC 27001:2013 terminou a 31 de outubro de 2025. Esses certificados já não são válidos; atualizar apenas um registo de controlos não estabelece a certificação segundo a edição de 2022.

Seguem-se pontos de partida práticos para os 11 controlos novos, e não reproduções do seu texto oficial.

Evite tratá-los como onze compras automáticas de produtos. Por exemplo, a informação sobre ameaças exige análise e ação, e não apenas a subscrição de um feed. A eliminação de dados exige compreender as cópias, as cópias de segurança e as obrigações de conservação, e não apenas um botão de apagar. A monitorização precisa de um circuito de resposta operacional.

Registar a aplicabilidade e a implementação separadamente

A sua Declaração de Aplicabilidade (SoA, do inglês Statement of Applicability) deve identificar os controlos necessários, explicar a sua inclusão, registar se estão implementados e justificar as exclusões de controlos do Anexo A. Estes requisitos inserem-se nas disposições sobre tratamento de riscos da ISO/IEC 27001.

Utilizar as 93 referências como índice de revisão é uma forma prática de tornar a comparação verificável. Inclua também quaisquer controlos adicionais necessários. A Declaração de Aplicabilidade não é o registo de riscos, o plano de tratamento nem o repositório de evidências, embora deva estar ligada a cada um deles quando relevante.

Para cada controlo aplicável, registe:

• Os riscos ou as obrigações que justificam a inclusão.
• Os sistemas, locais, informação e processos relevantes.
• A implementação efetiva e o responsável.
• As evidências de suporte e o respetivo período de revisão.
• As dependências, exceções e trabalho por concluir.
• A data da próxima revisão ou o evento que a desencadeia.

Mantenha a aplicabilidade independente do estado de execução. «Aplicável, parcialmente implementado» é um registo honesto e útil. «Não aplicável porque ainda não comprámos uma ferramenta» não é uma justificação de aplicabilidade.

Uma exclusão deve descrever os factos de âmbito que tornam o controlo desnecessário e manter-se coerente com a avaliação de riscos. «Não desenvolvemos software» merece ser escrutinado se um prestador externo desenvolver o seu portal de clientes. A subcontratação altera o caminho de implementação e de evidências; não elimina automaticamente o risco.

Para implementações distribuídas, registe a divisão. Um controlo de proteção física pode depender de instalações de alojamento operadas pelo fornecedor, do controlo de entradas nos escritórios gerido pela empresa e do tratamento dos dispositivos pelos trabalhadores. Um único responsável pode responder pela afirmação conjunta, enquanto diferentes equipas executam as atividades.

Uma declaração de implementação útil é suficientemente específica para ser testada: «Os administradores de produção recebem acesso nominativo e aprovado através do serviço de identidade; o acesso de emergência é registado e revisto separadamente.» «O acesso é gerido de forma segura» não consegue orientar um engenheiro nem um revisor.

Testar a afirmação por detrás do estado

Uma política descreve o comportamento pretendido. Pode demonstrar o desenho e a aprovação, mas não pode, por si só, demonstrar o funcionamento. Construa uma cadeia de evidências desde o requisito até ao mecanismo implementado e, depois, até um resultado observado.

Na gestão de acessos, compare as regras aprovadas com as permissões efetivas dos utilizadores e com os registos de saídas. Inclua, quando relevante, as identidades privilegiadas, as contas não humanas e as aplicações fora da gestão central de identidades. Registe a população, a amostra e as exceções, em vez de apresentar uma única captura de ecrã conveniente.

Nas cópias de segurança, inspecione a configuração e um resultado de reposição. Uma tarefa de cópia de segurança bem-sucedida prova menos do que uma recuperação bem-sucedida de informação utilizável. Verifique as permissões, as dependências e os objetivos de recuperação; uma base de dados reposta sem as respetivas chaves de cifragem pode não repor o serviço.

Na segurança dos fornecedores, ligue a avaliação ao serviço concreto e às responsabilidades contratuais. Verifique se as evidências abrangem o serviço que utiliza e se as responsabilidades identificadas do lado do cliente estão implementadas.

Um registo de teste prático deve conter o resultado esperado, o método, o âmbito, a data das evidências, o revisor, o resultado e a decisão de seguimento. Distinga:

• Desenho: o mecanismo proposto responde ao risco identificado.
• Implementação: o mecanismo existe em todo o âmbito declarado.
• Funcionamento: os registos mostram que funcionou durante o período relevante.
• Eficácia: os testes indicam que atinge o resultado pretendido.

As evidências podem incluir configurações, exportações, tickets, contratos, entrevistas e observações físicas. Selecione as evidências que sustentam a afirmação concreta. Uma exportação de configuração pode mostrar as definições atuais; os tickets históricos podem mostrar se as exceções foram tratadas ao longo do tempo.

Preserve a proveniência: sistema de origem, data de recolha, período abrangido e eventuais filtros. Proteja as evidências que contenham segredos ou informação pessoal através de restrições de acesso e de expurgos adequados. A recolha de evidências não deve criar um novo repositório não controlado de dados sensíveis.

Exemplo prático: tornar verificável um processo de saída

Considere, a título ilustrativo, uma empresa SaaS com 45 trabalhadores, um escritório, alojamento na nuvem, identidades geridas centralmente e duas aplicações com contas locais. Estes são pressupostos do exemplo, e não resultados de clientes do Secani.

O risco é a manutenção do acesso a informação de clientes ou da empresa após a saída. Os controlos relevantes incluem as responsabilidades em caso de alteração da relação laboral, a gestão de identidades, os direitos de acesso e a devolução de ativos. A autenticação técnica e as restrições de acesso também suportam a implementação.

A empresa regista o controlo como aplicável. Os recursos humanos são responsáveis pelo gatilho da saída; as TI, pelas ações sobre identidades e dispositivos; cada responsável de aplicação, pela remoção das contas locais. A chefia do trabalhador confirma o momento de saída exigido. O responsável pela segurança revê o processo e as exceções por resolver.

A implementação inclui um ticket de saída autorizado, a desativação agendada da conta central, a revogação de sessões quando suportada, a remoção das contas locais, a devolução de ativos e verificações das credenciais que a pessoa controlava. Os segredos partilhados são alterados quando necessário; as contas pessoais não são reatribuídas de forma casual a um sucessor.

O pacote de evidências liga o procedimento aprovado, o ticket de saída, os registos das ações sobre contas, as confirmações das aplicações locais e o registo de equipamentos. Cada item sustenta uma parte definida da afirmação.

Durante uma revisão ilustrativa, a equipa analisa quatro saídas. As contas centrais foram desativadas conforme agendado, mas uma aplicação local manteve o acesso durante dois dias. O controlo não é declarado totalmente eficaz apenas com base nas evidências da identidade central.

O responsável pela aplicação remove a conta, avalia se houve acesso e regista o resultado. A equipa acrescenta a aplicação à lista de verificação de saídas e atribui um passo de reconciliação. A ação de tratamento recebe um responsável e uma data-limite; um teste posterior verifica se o fluxo de trabalho revisto funciona.

Este exemplo mostra por que razão as evidências têm de acompanhar as dependências. Quatro sistemas a indicar «concluído» não demonstram a conclusão se um quinto sistema nunca foi incluído.

Manter os controlos em funcionamento entre revisões

Os controlos mudam quando mudam os sistemas, os fornecedores, as pessoas e os requisitos do negócio. Defina gatilhos de revisão para versões significativas, novos serviços, alterações nos escritórios, incidentes e obrigações revistas, a par das revisões agendadas.

Utilize uma cadência adequada à volatilidade e ao risco. As exceções de acessos privilegiados podem exigir uma revisão rápida, enquanto uma política estável pode seguir um ciclo mais longo, complementado por gatilhos de alteração. Estas são opções da gestão, e não frequências universais do Anexo A.

Acompanhe um pequeno número de indicadores úteis: correções em atraso, sistemas não cobertos, exceções de evidências por resolver e testes de controlos falhados. Separe-os das contagens de documentos. Uma grande biblioteca de evidências pode, ainda assim, deixar um ambiente de produção crítico por testar.

A auditoria interna fornece uma avaliação separada do SGSI; as revisões de rotina dos responsáveis pelos controlos não a substituem. A revisão pela gestão também exige decisões da liderança sobre o desempenho, as alterações, os recursos e a melhoria, e não apenas uma folha de cálculo de controlos preenchida. A certificação é realizada por um organismo de certificação independente, e não pela ISO nem por um fornecedor de software.

Os erros comuns incluem atribuir tudo à segurança, copiar as exclusões de outra organização, confiar em certificados de fornecedores sem verificar o âmbito e encerrar constatações quando uma política muda, em vez de quando o processo revisto foi testado.

Começar com um serviço e uma cadeia de evidências completa

Escolha um serviço representativo e mapeie os seus sistemas, prestadores, informação e responsáveis operacionais. Selecione um pequeno conjunto de controlos relacionados, como acessos, gestão de alterações, registo de eventos e recuperação, e torne cada implementação verificável antes de alargar o registo.

O Secani suporta este fluxo de trabalho ao modelar sistemas e dependências, ligar evidências a requisitos, controlos e decisões e acompanhar as lacunas como tarefas. Atribua um responsável e um revisor, anexe os registos existentes e preserve os comentários e as aprovações da revisão. Trate os mapeamentos ou resumos assistidos por IA como rascunhos: valide as fontes e mantenha explícita a aprovação humana. A preparação estruturada para auditorias explica o modelo de evidências subjacente.

O primeiro resultado deve ser uma cadeia coerente desde o risco até ao controlo, à implementação, às evidências, ao resultado do teste e à decisão de seguimento. Essa cadeia pode depois ser repetida no restante âmbito, sem inventar um novo processo para cada referência do Anexo A.

Questões práticas

Um registo pode sustentar vários controlos?

Sim. Um ticket de saída pode sustentar vários controlos relacionados. Explique que afirmação sustenta em cada um; partilhar evidências não torna os controlos idênticos.

Cada controlo tem de ter a sua própria política?

Não. Organize as políticas e os procedimentos em torno de processos operacionais compreensíveis. Um documento pode abranger vários controlos, desde que as responsabilidades e a implementação continuem claras.

De onde deve vir a lista oficial de controlos?

Utilize a norma ISO/IEC 27001 licenciada para a redação do Anexo A e a ISO/IEC 27002 para as orientações de implementação. Os resumos operacionais são auxiliares de navegação úteis, e não substitutos das normas.