Autoavaliação de controlos para evidência ISO 27001 auditável

O problema de auditoria em 2026 não é a falta de controlos, é a evidência fraca
A videochamada começou às 09:10 de uma segunda-feira. Sarah, CISO de uma empresa FinTech SaaS em rápido crescimento, olhou para três rostos tensos no ecrã: a responsável pela GRC, o Encarregado da Proteção de Dados (EPD) e o responsável pelas Operações de TI.
A empresa tinha uma auditoria de acompanhamento ISO/IEC 27001:2022 a aproximar-se. O Conselho de Administração queria um briefing de preparação para NIS2 até sexta-feira. Um cliente de serviços financeiros tinha acrescentado perguntas sobre fornecedores de TIC, ao estilo DORA, à renovação contratual. O EPD estava a preparar evidência para a responsabilização ao abrigo do GDPR da UE.
No papel, a organização parecia madura. Existia um registo de riscos, uma Declaração de Aplicabilidade, procedimentos de controlo de acesso, guias operacionais de resposta a incidentes, políticas de cópias de segurança, formulários de diligência devida de fornecedores e registos de formação.
Depois começou a revisão da evidência.
A folha de cálculo da revisão de acessos não identificava o revisor. Um relatório de análise de vulnerabilidades estava atualizado, mas ninguém conseguia provar se as constatações críticas tinham sido remediadas, aceites ou permaneciam abertas. A diligência devida de fornecedores existia, mas era anterior a uma alteração importante da arquitetura de nuvem. As capturas de ecrã dos testes de cópia de segurança estavam enterradas numa conversa de chat. As notas do exercício de simulação de incidente eram úteis, mas não atribuíveis. Os engenheiros encaminhavam capturas de ecrã de configuração sem contexto. Os proprietários dos controlos marcavam verificações trimestrais como “concluídas”, mas a evidência era inconsistente e difícil de reutilizar.
Sarah sabia que o problema não era a ausência de controlos. Era a ausência de evidência defensável e repetível.
Essa é a lacuna da autoavaliação de controlos em 2026.
As organizações têm controlos documentados, painéis de gestão e, por vezes, ferramentas de monitorização contínua. Mas muitas vezes não conseguem provar que os proprietários dos controlos testam os controlos de forma consistente, que a evidência é completa e atual, e que as exceções fluem para ações corretivas, revisão pela gestão e reporte regulamentar.
A autoavaliação de controlos, ou CSA, resolve esta lacuna operacional. Quando bem executada, a CSA cria um fluxo de trabalho disciplinado em que os proprietários dos controlos testam periodicamente a conceção dos controlos e a eficácia operacional, anexam evidência que cumpre critérios de qualidade de auditoria, registam exceções, atribuem ações corretivas e fornecem à gestão uma visão fiável do estado de saúde dos controlos.
Na Clarysec, a CSA é tratada como a ponte entre o SGSI, as obrigações legais e a evidência de auditoria. O Zenith Blueprint: roteiro de 30 passos para auditores coloca esta disciplina na fase de auditoria, revisão e melhoria. O passo 26, execução da auditoria, afirma que a recolha de evidência deve incluir entrevistas, revisão documental, observação, amostragem e verificações por amostragem:
✓ Entrevistar o pessoal relevante: pedir às pessoas responsáveis pelos processos que expliquem como cumprem os requisitos.
✓ Rever a documentação: verificar se os documentos e registos existem e estão atualizados.
✓ Observar práticas: se possível, realizar observação direta.
✓ Fazer amostragem e verificações por amostragem: não é possível verificar tudo, por isso deve usar-se amostragem.
Este raciocínio não deve esperar pela auditoria interna formal. A CSA antecipa-o e coloca-o nas mãos dos proprietários dos controlos, para que a organização consiga provar, todos os meses ou trimestres, que os controlos não estão apenas escritos, mas em funcionamento.
Porque falham as autoavaliações manuais perante NIS2, DORA e GDPR da UE
O antigo modelo de autoavaliação de controlos baseado em folhas de cálculo e correio eletrónico está quebrado porque recompensa a conclusão em vez da qualidade da evidência.
Um proprietário do controlo carrega uma captura de ecrã. Outro escreve “confirmado conforme a política”. Um terceiro anexa uma exportação de logs sem explicação do sistema, período, revisor ou conclusão. A equipa de GRC passa dias a reconstruir a narrativa para auditores, clientes e reguladores.
Isto cria quatro falhas recorrentes:
- Evidência inconsistente, em que cada proprietário tem uma ideia diferente do que constitui prova válida.
- Atribuição fraca, em que os ficheiros não mostram quem recolheu a evidência, quando e a partir de que fonte.
- Confirmação sem teste real, em que equipas sobrecarregadas atestam que um controlo funciona sem o testar.
- Ausência de reutilização, em que a evidência recolhida para ISO/IEC 27001:2022 não consegue suportar facilmente NIS2, DORA ou GDPR da UE sem reinterpretação manual.
A regulamentação moderna não tolera esse modelo.
O Article 20 da NIS2 torna a gestão de riscos de cibersegurança uma responsabilidade do órgão de gestão. A gestão deve aprovar medidas, supervisionar a implementação e acompanhar a formação. O Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, tratamento de vulnerabilidades, avaliação de eficácia, higiene de cibersegurança, controlo de acesso, gestão de ativos e autenticação.
A expressão “avaliação de eficácia” é onde a CSA se torna essencial. Uma entidade sujeita à NIS2 não consegue afirmar de forma credível à gestão que as medidas de cibersegurança são eficazes se os proprietários dos controlos não as testarem e não documentarem os resultados.
O DORA elevou a fasquia para as entidades financeiras desde 17 de janeiro de 2025. Cria um regime de resiliência operacional digital que abrange gestão do risco das TIC, notificação de incidentes, testes de resiliência, partilha de informação e risco de terceiros de TIC. O Article 5 do DORA exige responsabilidade do órgão de gestão por disposições de risco das TIC, políticas, papéis, estratégia, planos de continuidade, planos de auditoria, políticas de terceiros e medidas corretivas. O Article 6 exige um quadro documentado de gestão do risco das TIC, revisão regular, auditoria interna para entidades que não sejam microempresas e remediação de constatações críticas de auditoria de TIC. Os Articles 24 a 26 tornam os testes de resiliência um programa recorrente de validação, incluindo independência adequada e, para determinadas entidades, testes de intrusão orientados por ameaças.
A CSA não substitui os testes DORA. É a camada dos proprietários dos controlos que torna os testes DORA sustentáveis.
O GDPR da UE acrescenta uma pressão relacionada com a responsabilização. O Article 5(2) exige que os responsáveis pelo tratamento demonstrem conformidade com os princípios de proteção de dados. O Article 32 exige segurança do tratamento adequada, incluindo confidencialidade, integridade, disponibilidade, resiliência, restauro e testes ou avaliação regulares, quando adequado. Para um EPD, a evidência da CSA é uma forma prática de demonstrar que revisões de acessos, cifragem, registo, retenção, supervisão de fornecedores e tratamento de incidentes estão efetivamente a operar em torno de dados pessoais.
O modelo CSA da Clarysec, da política à prova
Um programa de CSA defensável começa com três perguntas:
- O controlo está corretamente concebido para o risco e a obrigação?
- O controlo funcionou durante o período de avaliação?
- A evidência é completa, atual, atribuível e reutilizável?
A Clarysec ancora este modelo em políticas, fluxo de auditoria e mapeamento de controlos.
A Política de Segurança da Informação estabelece a expectativa na cláusula 6.6.1:
Todos os controlos implementados devem ser auditáveis, suportados por procedimentos documentados e por evidência retida da sua operação.
A cláusula 6.6.2 acrescenta:
Os proprietários dos controlos devem manter resultados de testes, logs e registos de revisão para suportar auditorias periódicas.
Isto transforma os controlos de declarações estáticas em processos ativos e mensuráveis.
A Política de Auditoria e Monitorização da Conformidade - PME estabelece a disciplina de revisão:
Esta política estabelece a abordagem da organização à realização de auditorias internas, revisões de controlos de segurança e monitorização contínua da conformidade. Garante que todos os controlos, políticas, sistemas e prestadores de serviços são sujeitos a revisão regular e estruturada.
A cláusula 5.2.3 exige estrutura:
Cada auditoria deve incluir um âmbito definido, objetivos, pessoal responsável e evidência requerida.
Para a CSA, a mesma lógica aplica-se ao nível do proprietário do controlo. Cada autoavaliação deve ter âmbito, objetivo, pessoa responsável, período, evidência e conclusão.
O Zenith Controls: guia de conformidade cruzada fornece depois a perspetiva de mapeamento. Para a CSA, as referências de controlo mais importantes do Anexo A da ISO/IEC 27001:2022 incluem 5.2, papéis e responsabilidades de segurança da informação, 5.35, revisão independente da segurança da informação, e 5.36, conformidade com políticas, regras e normas de segurança da informação.
Em conjunto, estes controlos contam a história da CSA. Alguém deve ser responsável pelo controlo. A organização deve verificar se as políticas e normas são seguidas. A revisão independente deve desafiar o sistema. A CSA situa-se entre a propriedade do controlo e a revisão independente. Não é auditoria interna, mas prepara a evidência que torna a auditoria interna mais rápida e fiável.
Teste de conceção versus teste de eficácia operacional
Um erro comum na CSA é perguntar aos proprietários dos controlos “Este controlo está a funcionar?” sem definir o que significa “funcionar”.
Toda avaliação credível deve separar o teste de conceção do teste de eficácia operacional.
Um teste de conceção pergunta se o controlo, se executado conforme descrito, trataria o risco ou requisito. Para uma revisão de acessos, o teste de conceção verifica se o procedimento define o âmbito, o papel do revisor, a frequência, os sistemas abrangidos, o tratamento de exceções, a retenção da evidência e o escalonamento.
Um teste de eficácia operacional pergunta se o controlo efetivamente funcionou durante o período. Para a mesma revisão de acessos, o teste operacional verifica se a revisão ocorreu, quem a executou, se todos os sistemas no âmbito foram incluídos, se as exceções foram resolvidas e se os registos provam a conclusão.
Ambos os testes são relevantes. Uma política de cópias de segurança bem escrita é fraca se não tiverem ocorrido testes de restauro. Uma análise semanal de vulnerabilidades é incompleta se as constatações críticas não fluírem para remediação ou aceitação formal do risco. Uma revisão de fornecedor realizada uma única vez deixa de ser fiável se o fornecedor passar a suportar um processo crítico e tiver alterado subcontratados.
| Pergunta CSA | Teste de conceção | Teste de eficácia operacional | Exemplos de evidência |
|---|---|---|---|
| Revisão de acessos | O procedimento define âmbito, frequência, revisor, aprovação e regras de exceção | As revisões selecionadas por amostragem ocorreram dentro do prazo e as exceções foram resolvidas | Registos de revisão, listas de utilizadores exportadas, logs de aprovação, registos de encerramento de tickets |
| Gestão de vulnerabilidades | A política define o âmbito da análise, regras de severidade, SLA e processo de aceitação do risco | As análises foram executadas, as constatações foram triadas e as correções ou aceitações de risco foram documentadas | Relatórios de análise, tickets, registos de alteração, aprovações de aceitação do risco |
| Cópia de segurança e recuperação | A norma de cópias de segurança define sistemas, frequência, retenção e testes de restauro | As cópias de segurança foram concluídas e os testes de restauro tiveram êxito para os sistemas selecionados | Logs de tarefas de cópia de segurança, relatórios de testes de restauro, tickets de remediação de falhas |
| Segurança de fornecedores | O processo de diligência devida e monitorização cobre criticidade e salvaguardas contratuais | Os fornecedores críticos foram avaliados, revistos e monitorizados durante o período | Registo centralizado de fornecedores, formulários de diligência devida, cláusulas contratuais, relatórios de SLA |
| Gestão de incidentes | O guia operacional define classificação, escalonamento, reporte e tratamento de evidência | Incidentes ou exercícios seguiram o processo e as lições aprendidas foram acompanhadas | Registo de incidentes, cronologia, comunicações, análise de causa raiz, registos CAPA |
| Revisão independente | O programa de auditoria interna define âmbito, competência, imparcialidade e reporte | As revisões ocorreram, as constatações foram reportadas e as ações corretivas foram acompanhadas | Plano de Auditoria Interna, relatório de auditoria, atas de revisão pela gestão, log CAPA |
Esta distinção suporta diretamente as cláusulas 8.1 da ISO/IEC 27001:2022 sobre planeamento e controlo operacional, 9.1 sobre monitorização, medição, análise e avaliação, 9.2 sobre auditoria interna, 9.3 sobre revisão pela gestão e 10.2 sobre não conformidade e ação corretiva.
Critérios de qualidade da evidência para auditorias de 2026
A evidência não está pronta para auditoria apenas por existir. A evidência deve ser utilizável.
Para a CSA, a evidência deve ser avaliada segundo sete critérios.
| Critério da evidência | O que significa | Falha típica |
|---|---|---|
| Completa | Cobre todo o âmbito do controlo e o período de avaliação | A captura de ecrã mostra um sistema, mas o controlo cobre cinco sistemas |
| Atual | Reflete o período em avaliação | A revisão do fornecedor tem dois anos |
| Atribuível | Mostra quem a executou, aprovou ou recolheu | A folha de cálculo não tem proprietário nem carimbo temporal |
| Autêntica | Provém de um sistema de origem fiável ou de um repositório controlado | Captura de ecrã editada manualmente sem fonte |
| Relevante | Prova diretamente o objetivo do controlo | Existe o material de formação, mas falta a presença |
| Retida | Armazenada de acordo com requisitos de retenção e acesso | A evidência está guardada em caixas de correio pessoais |
| Reutilizável | Mapeada para múltiplas obrigações sem reinterpretação | A evidência de acesso tem de ser reconstruída separadamente para ISO, GDPR da UE e DORA |
A política para PME reforça a disciplina de metadados:
Os metadados (por exemplo, quem recolheu, quando e a partir de que sistema) devem ser documentados.
Para investigações de maior integridade e evidência digital, a Política de Recolha de Evidência e Análise Forense - PME é mais precisa:
Cada item de evidência digital deve ser registado com:
5.2.1.1. Nome do responsável pela recolha
5.2.1.2. Sistema/dispositivo de origem
5.2.1.3. Carimbo temporal da recolha
5.2.1.4. Localização de armazenamento
5.2.1.5. Histórico de acesso (quem o visualizou ou copiou)
Um registo CSA de rotina nem sempre necessita de tratamento forense de cadeia de custódia. Mas cada item de evidência deve ser suficientemente rastreável para que um auditor compreenda quem o produziu, quando, a partir de onde e porque prova o controlo.
A Política de Cumprimento Legal e Regulamentar acrescenta o requisito de conformidade cruzada ao exigir:
Artefactos ou registos requeridos para demonstrar conformidade (por exemplo, logs de auditoria, definições de cifragem, documentação de consentimento)
Esta é a chave para evidência reutilizável. Uma exportação da configuração de cifragem pode suportar o tratamento de riscos da ISO/IEC 27001:2022, as medidas de segurança do Article 21 da NIS2, a proteção de ativos de TIC no DORA e a segurança do tratamento do Article 32 do GDPR da UE, se o registo for completo, atribuível e mapeado.
| Evidência fraca | Evidência robusta |
|---|---|
| Um ficheiro chamado audit_report.pdf numa pasta partilhada | Um registo de GRC que liga a Internal_Audit_Report_H1_2026.pdf com responsável pela recolha, data, fonte, período, proprietário e mapeamento de controlos |
| Uma mensagem de correio eletrónico a dizer que a gestão viu o relatório | Atas da revisão pela gestão que mostram os resultados da auditoria interna como entrada ao abrigo da cláusula 9.3 da ISO/IEC 27001:2022 |
| Uma captura de ecrã de tickets | Exportação CAPA que mostra não conformidade, causa raiz, ação corretiva, proprietário, data-alvo, estado e método de verificação |
| Um PDF de análise de vulnerabilidades | Relatório de análise ligado a ativos afetados, regras de severidade, tickets de remediação, aceitações de risco e evidência de encerramento |
| Um questionário de fornecedor | Registo de fornecedor ligado a criticidade, cláusulas contratuais, resultados de monitorização, estado dos subcontratados e data de revisão |
Um fluxo de trabalho CSA prático usando o toolkit da Clarysec
Um proprietário do controlo deve conseguir executar uma sessão CSA significativa de forma estruturada e repetível. O fluxo de trabalho abaixo pode ser aplicado a acesso privilegiado, recuperação de cópias de segurança, monitorização de fornecedores, preparação para incidentes, gestão de vulnerabilidades ou revisão independente.
Passo 1, selecionar o controlo e o mapeamento de obrigações
Comece pela Declaração de Aplicabilidade, pelo plano de tratamento de riscos e pelo registo de obrigações de conformidade. Escolha um controlo, por exemplo a revisão de acesso privilegiado para sistemas de produção.
Mapeie-o para controlos relevantes do Anexo A da ISO/IEC 27001:2022, como 5.15 Controlo de acesso, 5.16 Gestão de identidades e 5.18 Direitos de acesso. Nos Zenith Controls, ligue-o a 5.2 para papéis e responsabilidades e a 5.36 para conformidade com políticas, regras e normas, porque a revisão prova que a política de acesso está a ser seguida.
Se a organização estiver abrangida pela NIS2, mapeie a evidência para as medidas do Article 21 relativas a controlo de acesso, gestão de ativos, segurança de recursos humanos e autenticação. Se for uma entidade financeira sujeita ao DORA, mapeie-a para a governação do risco das TIC, proteção, monitorização e requisitos de terceiros, quando relevante. Se estiverem envolvidos dados pessoais, mapeie-a para a integridade e confidencialidade do Article 5 do GDPR da UE e para a segurança do tratamento do Article 32.
Passo 2, definir o teste de conceção
Coloque perguntas práticas de conceção:
- O procedimento identifica todos os sistemas no âmbito?
- Abrange contas privilegiadas, contas de serviço e acesso de emergência?
- O revisor é independente do provisionamento diário, sempre que praticável?
- A frequência, o escalonamento e as regras de exceção estão definidos?
- A retenção da evidência está definida?
- As obrigações do GDPR da UE, DORA, NIS2 ou específicas de clientes estão incluídas quando relevantes?
Se a resposta for não, registe uma exceção de conceção.
Passo 3, executar o teste de eficácia operacional
Selecione uma amostra e teste a operação real. Para uma revisão trimestral de acesso privilegiado, selecione a última revisão concluída e utilizadores de alto risco em sistemas críticos. Se o ambiente for pequeno, teste todas as contas privilegiadas. Se for grande, use amostragem baseada no risco, com maior cobertura para administradores, sistemas de produção, sistemas com dados pessoais e plataformas expostas à Internet.
A Política de Auditoria e Monitorização da Conformidade empresarial suporta:
Recolha de evidência através de entrevistas, walkthroughs e amostragem
Também exige:
Documentação da estratégia de amostragem, do âmbito da auditoria e das limitações
Não se limite a anexar evidência. Registe porque a amostra foi escolhida, que população representa e o que foi excluído.
Uma declaração de amostragem robusta poderia dizer:
“População: 42 contas privilegiadas de produção em consola de nuvem, plataforma de CI/CD e administração de bases de dados. Amostra: todas as 7 contas break-glass, todas as 5 contas de administrador de bases de dados de produção e 10 contas privilegiadas de engenharia selecionadas aleatoriamente. Período: Q1 2026. Exclusões: contas de firewall geridas por terceiros avaliadas na CSA-TPR-04 de revisão de acesso de fornecedores.”
Essa frase dá ao auditor a população, a lógica de risco, o período e a limitação.
Passo 4, avaliar a qualidade da evidência
Para cada item de evidência, capture:
- ID da evidência
- ID do controlo e proprietário do controlo
- Período de avaliação
- Sistema de origem
- Data de recolha
- Responsável pela recolha
- Revisor ou aprovador
- Obrigação associada
- Localização de armazenamento
- Período de retenção
- Exceções encontradas
- Ticket de remediação ou referência CAPA
Isto transforma a CSA de um questionário subjetivo num teste de controlo baseado em evidência.
Passo 5, registar exceções e ações corretivas
Se duas contas privilegiadas não tiverem justificação de negócio documentada, não esconda o problema em notas. Crie uma constatação, atribua uma classificação de risco, defina uma ação, designe um proprietário e acorde uma data-alvo.
A política para PME exige:
Todas as constatações de auditoria devem ser documentadas com classificações de risco e ações propostas.
Depois aplique o passo 27 do Zenith Blueprint, Constatações de auditoria. O Blueprint recomenda categorias de não conformidade maior, não conformidade menor ou observação, seguidas de análise de causa raiz. Se as contas de serviço foram omitidas porque o inventário de identidades as exclui, a causa raiz não é “erro do revisor”. É inventário de acessos incompleto ou âmbito do procedimento pouco claro.
Passo 6, encerrar através de CAPA e verificar a eficácia
O passo 29 do Zenith Blueprint recomenda a utilização de um log CAPA com descrição do problema, causa raiz, ação corretiva, proprietário responsável, data-alvo e estado. Também enfatiza a verificação da eficácia após a conclusão.
Se a ação corretiva for “atualizar o procedimento de revisão de acessos para incluir contas de serviço”, o método de verificação deve ser prático: rever o ciclo de acessos seguinte e confirmar que as contas de serviço estão incluídas, que as exceções são resolvidas e que a evidência é retida.
É assim que a CSA se torna melhoria contínua em vez de teatro de conformidade.
Mapeamento de conformidade cruzada sem quatro programas de controlo separados
O maior ganho de eficiência é “testar uma vez, mapear para muitos”.
Criar processos de teste separados para ISO/IEC 27001:2022, NIS2, DORA e GDPR da UE gera evidência duplicada, respostas inconsistentes e proprietários dos controlos exaustos. Uma abordagem melhor é usar a ISO/IEC 27001:2022 como sistema de gestão, a CSA como fluxo de trabalho de teste e os Zenith Controls como guia de conformidade cruzada.
| Área de evidência CSA | Utilização em ISO/IEC 27001:2022 | Utilização em NIS2 | Utilização em DORA | Utilização em GDPR da UE | Alinhamento com NIST CSF 2.0 |
|---|---|---|---|---|---|
| Tratamento de riscos aprovado pela gestão e propriedade dos controlos | Cláusulas 5.3, 6.1, 6.2 e Anexo A 5.2 | Governação do Article 20 e medidas do Article 21 | Responsabilidade do órgão de gestão do Article 5 e quadro de risco das TIC do Article 6 | Responsabilização por medidas técnicas e organizacionais | Resultados GOVERN para papéis, estratégia de risco e supervisão |
| Evidência de revisão de acessos | Anexo A 5.15, 5.16 e 5.18 | Medidas de controlo de acesso, gestão de ativos e autenticação | Proteção de TIC e controlos de risco | Integridade, confidencialidade e limitação de acesso | Resultados PR.AA para identidade, autenticação e princípio do menor privilégio |
| Exercício de incidentes e registo de incidentes | Anexo A 5.24, 5.25, 5.26 e 5.27 | Tratamento de incidentes do Article 21 e preparação para reporte do Article 23 | Classificação de incidentes relacionados com TIC, reporte e causa raiz | Deteção e tratamento de violação de dados pessoais | Resultados RESPOND e RECOVER |
| Registos de monitorização de fornecedores | Anexo A 5.19, 5.20, 5.21 e 5.22 | Segurança da cadeia de fornecimento ao abrigo do Article 21 | Risco de terceiros de TIC, registos, contratos e saída | Supervisão de subcontratantes e salvaguardas de proteção de dados | Resultados GV.SC para cadeia de fornecimento |
| Teste de restauro de cópia de segurança | Anexo A 8.13 e controlos de continuidade | Continuidade de negócio, cópia de segurança, recuperação de desastre e gestão de crise | Continuidade, restauro e testes de resiliência | Disponibilidade e resiliência do tratamento | Resultados PR.DS e RC.RP para cópia de segurança e recuperação |
| Remediação de vulnerabilidades | Anexo A 8.8 | Tratamento de vulnerabilidades e manutenção segura | Proteção, deteção e remediação do risco das TIC | Segurança do tratamento e redução do risco | Resultados IDENTIFY, PROTECT e DETECT |
O NIST Cybersecurity Framework 2.0 é útil como camada de integração. A sua função GOVERN trata requisitos legais, regulamentares e contratuais, apetite ao risco, responsabilização da liderança, governação de políticas e supervisão. Os seus Perfis Organizacionais ajudam as organizações a definir resultados atuais e pretendidos de cibersegurança, analisar lacunas e convertê-las em planos de ação priorizados.
O COBIT 2019 e o pensamento de garantia ao estilo ISACA acrescentam outra perspetiva útil. Focam-se em objetivos de governação, capacidade dos processos, responsabilização, métricas e supervisão da gestão. Um revisor orientado por COBIT perguntará se o processo está definido, medido e melhorado, não apenas se existe um artefacto.
Como diferentes auditores escrutinarão a sua evidência CSA
O mesmo registo CSA será interpretado de forma diferente consoante o enquadramento do auditor. Conceber evidência para essas perspetivas torna o programa mais resiliente.
| Perspetiva do auditor | Em que se focará o auditor | O que demonstra uma evidência CSA robusta |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Âmbito do SGSI, tratamento de riscos, Declaração de Aplicabilidade, monitorização, auditoria interna, revisão pela gestão e ação corretiva | O controlo está ligado a risco, proprietário, procedimento, evidência, resultado de monitorização, exceção e ação corretiva |
| Avaliador orientado por NIST | Resultados atuais e pretendidos, governação, priorização de riscos, identidade, monitorização, resposta e recuperação | A CSA mapeia para resultados CSF, mostra desempenho atual e identifica lacunas face ao estado pretendido |
| Revisor DORA | Supervisão do órgão de gestão, quadro de risco das TIC, testes de resiliência, ciclo de vida de incidentes, risco de terceiros e remediação | A evidência dos controlos de TIC é atual, baseada no risco, testada, escalonada e reportada à gestão quando relevante |
| Revisor do GDPR da UE | Responsabilização, princípios de proteção de dados, segurança do tratamento, preparação para violações e supervisão de subcontratantes | A evidência liga controlos técnicos ao tratamento de dados pessoais, papéis lícitos, retenção e salvaguardas de segurança |
| Auditor COBIT 2019 ou ao estilo ISACA | Objetivo de governação, propriedade do processo, capacidade, métricas, gestão de problemas e independência da garantia | A CSA mostra processo definido, proprietário responsável, desempenho mensurável, exceções e reporte à gestão |
Para revisão independente, um auditor ISO/IEC 27001:2022 procurará o programa de auditoria interna ao abrigo da cláusula 9.2, as entradas da revisão pela gestão ao abrigo da cláusula 9.3 e a ação corretiva ao abrigo da cláusula 10.2. Um revisor DORA procurará testes baseados no risco, independência, remediação e supervisão da gestão. Um regulador NIS2 focar-se-á em saber se a gestão consegue provar a eficácia das medidas de cibersegurança. Um revisor do GDPR da UE perguntará se a evidência demonstra medidas técnicas e organizacionais adequadas em torno de atividades reais de tratamento.
O objetivo não é reescrever a evidência para cada público. O objetivo é recolhê-la uma vez com contexto suficiente para satisfazer várias perspetivas.
Reporte à gestão que cria ação, não ruído
Os resultados da CSA não devem permanecer em folhas de cálculo dos proprietários dos controlos. Devem alimentar a revisão pela gestão.
No passo 28, Revisão pela Gestão, o Zenith Blueprint recomenda entradas sobre alterações em questões internas e externas, alterações nos requisitos das partes interessadas, desempenho do SGSI, resultados de auditoria, monitorização e medição, incidentes, não conformidades, oportunidades de melhoria e necessidades de recursos.
É exatamente aí que a CSA pertence.
Um painel de gestão CSA útil para executivos deve incluir:
- Cobertura de controlos por domínio e processo crítico.
- Percentagem de controlos testados no prazo.
- Pontuação de qualidade da evidência por proprietário do controlo.
- Exceções abertas por classificação de risco.
- Ações corretivas em atraso.
- Constatações repetidas e causas raiz.
- Mapeamentos de alto risco para NIS2, DORA, GDPR da UE e obrigações de clientes.
- Exceções de controlo relacionadas com fornecedores.
- Constatações de incidentes, cópia de segurança e testes de resiliência.
- Decisões de recursos necessárias por parte da gestão.
A gestão não precisa de todas as capturas de ecrã. Precisa de saber se o ambiente de controlo é fiável, onde o risco está a aumentar, se as obrigações estão cobertas e onde são necessárias decisões.
Isto suporta a responsabilização da gestão prevista no Article 20 da NIS2 e a supervisão do órgão de gestão prevista no Article 5 do DORA. Para o GDPR da UE, ajuda o responsável pelo tratamento a demonstrar que a responsabilização não é um documento pontual, mas um processo vivo de governação.
Armadilhas comuns da CSA e como evitá-las
A primeira armadilha é a CSA baseada apenas em questionários. Uma resposta sim/não sem evidência produz conforto, não garantia. Cada afirmação material deve ser suportada por evidência.
A segunda armadilha é evidência sem contexto de controlo. Uma exportação de logs é irrelevante se não estiver associada a um objetivo de controlo, período, fonte, proprietário e conclusão.
A terceira armadilha é disciplina fraca de exceções. Se as constatações não tiverem classificações de risco, proprietários, datas-alvo e métodos de verificação, a CSA torna-se um exercício de armazenamento. O passo 29 do Zenith Blueprint evita isto ao ligar não conformidades a causa raiz, ação corretiva, proprietário, data-alvo e verificação de eficácia.
A quarta armadilha é ignorar serviços fornecidos externamente. A ISO/IEC 27001:2022 exige controlo sobre processos, produtos ou serviços fornecidos externamente e relevantes para o SGSI. A NIS2 inclui segurança da cadeia de fornecimento. O DORA exige gestão do risco de terceiros de TIC, registos, diligência devida, salvaguardas contratuais, avaliação de risco de concentração, direitos de auditoria e planos de saída. Os resultados GV.SC do NIST CSF 2.0 cobrem de forma semelhante papéis de fornecedores, diligência devida, contratos, monitorização, planeamento de incidentes e cessação. A CSA deve incluir evidência de fornecedores, não apenas evidência interna de TI.
A quinta armadilha é tratar o GDPR da UE como um anexo jurídico. Se dados pessoais forem tratados num sistema, a CSA deve testar se os controlos de segurança suportam integridade, confidencialidade, disponibilidade, retenção, limitação de acesso e preparação para violações.
A lista de verificação do proprietário do controlo para 2026
Antes de submeter um resultado CSA, cada proprietário do controlo deve conseguir confirmar o seguinte:
- Conheço o objetivo do controlo e os riscos associados.
- Sei que obrigações ISO/IEC 27001:2022, NIS2, DORA, GDPR da UE ou contratuais o controlo suporta.
- Testei a conceção e a eficácia operacional separadamente.
- Documentei a população e o método de amostragem.
- Anexei evidência completa, atual, atribuível, autêntica, relevante, retida e reutilizável.
- Registei metadados sobre quem recolheu a evidência, quando e a partir de que sistema.
- Documentei exceções com classificação de risco e ações propostas.
- Identifiquei a causa raiz das exceções materiais.
- Criei ou atualizei registos CAPA com proprietário, data limite e método de verificação.
- Escalonei questões materiais para revisão pela gestão.
Se um proprietário do controlo não conseguir completar esta lista, o problema não é apenas uma fraqueza da CSA. Pode ser uma fraqueza de monitorização do SGSI, uma lacuna de avaliação de eficácia da NIS2, uma questão de governação do risco das TIC no âmbito do DORA ou uma fragilidade de responsabilização ao abrigo do GDPR da UE.
Torne a CSA parte do seu modelo operacional de garantia
A autoavaliação de controlos não substitui a auditoria interna, testes de intrusão, testes de resiliência DORA ou revisão jurídica do GDPR da UE. É a camada operacional que torna todos esses processos mais fiáveis.
Em 2026, as organizações que passam auditorias com menos disrupção não serão as que têm mais políticas. Serão as organizações cujos proprietários dos controlos conseguem provar, com evidência de qualidade, que os controlos estão concebidos, em funcionamento, monitorizados, corrigidos e reportados.
A Clarysec ajuda as organizações a desenvolver esta capacidade utilizando o Zenith Blueprint, modelos de políticas como a Política de Segurança da Informação, a Política de Auditoria e Monitorização da Conformidade, a Política de Auditoria e Monitorização da Conformidade - PME, a Política de Recolha de Evidência e Análise Forense - PME, a Política de Cumprimento Legal e Regulamentar, e o poder de mapeamento de conformidade cruzada dos Zenith Controls.
Se os seus controlos ISO/IEC 27001:2022 estão documentados, mas a sua evidência está dispersa, inconsistente ou não é reutilizável para NIS2, DORA e GDPR da UE, comece esta semana por um domínio de alto risco. Execute uma CSA sobre acesso privilegiado, segurança de fornecedores, preparação para incidentes, remediação de vulnerabilidades ou recuperação de cópias de segurança. Teste a conceção, teste a eficácia operacional, pontue a qualidade da evidência, registe exceções e alimente o resultado na revisão pela gestão.
Pronto para transformar a autoavaliação de controlos em garantia pronta para auditoria? Descarregue o Zenith Blueprint, explore os Zenith Controls ou solicite uma avaliação de preparação da evidência da Clarysec para perceber onde a sua evidência de controlo resistirá ao escrutínio e onde precisa de melhorar.
Torne-se PECB ISO/IEC 27001 Lead Implementer ou Lead Auditor
- ✓ Material oficial PECB e duas tentativas de exame
- ✓ Taxa de certificação e AMF do primeiro ano incluídas, quando aplicável
- ✓ Autoestudo ou ao vivo online · curso atribuído em 1 dia útil
Sobre o autor

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council