PECB · 15% de desconto Aproveitar a oferta →

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

Igor Petreski

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:

  1. O controlo está corretamente concebido para o risco e a obrigação?
  2. O controlo funcionou durante o período de avaliação?
  3. 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 CSATeste de conceçãoTeste de eficácia operacionalExemplos de evidência
Revisão de acessosO procedimento define âmbito, frequência, revisor, aprovação e regras de exceçãoAs revisões selecionadas por amostragem ocorreram dentro do prazo e as exceções foram resolvidasRegistos de revisão, listas de utilizadores exportadas, logs de aprovação, registos de encerramento de tickets
Gestão de vulnerabilidadesA política define o âmbito da análise, regras de severidade, SLA e processo de aceitação do riscoAs análises foram executadas, as constatações foram triadas e as correções ou aceitações de risco foram documentadasRelatórios de análise, tickets, registos de alteração, aprovações de aceitação do risco
Cópia de segurança e recuperaçãoA norma de cópias de segurança define sistemas, frequência, retenção e testes de restauroAs cópias de segurança foram concluídas e os testes de restauro tiveram êxito para os sistemas selecionadosLogs de tarefas de cópia de segurança, relatórios de testes de restauro, tickets de remediação de falhas
Segurança de fornecedoresO processo de diligência devida e monitorização cobre criticidade e salvaguardas contratuaisOs fornecedores críticos foram avaliados, revistos e monitorizados durante o períodoRegisto centralizado de fornecedores, formulários de diligência devida, cláusulas contratuais, relatórios de SLA
Gestão de incidentesO guia operacional define classificação, escalonamento, reporte e tratamento de evidênciaIncidentes ou exercícios seguiram o processo e as lições aprendidas foram acompanhadasRegisto de incidentes, cronologia, comunicações, análise de causa raiz, registos CAPA
Revisão independenteO programa de auditoria interna define âmbito, competência, imparcialidade e reporteAs revisões ocorreram, as constatações foram reportadas e as ações corretivas foram acompanhadasPlano 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ênciaO que significaFalha típica
CompletaCobre todo o âmbito do controlo e o período de avaliaçãoA captura de ecrã mostra um sistema, mas o controlo cobre cinco sistemas
AtualReflete o período em avaliaçãoA revisão do fornecedor tem dois anos
AtribuívelMostra quem a executou, aprovou ou recolheuA folha de cálculo não tem proprietário nem carimbo temporal
AutênticaProvém de um sistema de origem fiável ou de um repositório controladoCaptura de ecrã editada manualmente sem fonte
RelevanteProva diretamente o objetivo do controloExiste o material de formação, mas falta a presença
RetidaArmazenada de acordo com requisitos de retenção e acessoA evidência está guardada em caixas de correio pessoais
ReutilizávelMapeada para múltiplas obrigações sem reinterpretaçãoA 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 fracaEvidência robusta
Um ficheiro chamado audit_report.pdf numa pasta partilhadaUm 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órioAtas 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 ticketsExportaçã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 vulnerabilidadesRelató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 fornecedorRegisto 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 CSAUtilização em ISO/IEC 27001:2022Utilização em NIS2Utilização em DORAUtilização em GDPR da UEAlinhamento com NIST CSF 2.0
Tratamento de riscos aprovado pela gestão e propriedade dos controlosCláusulas 5.3, 6.1, 6.2 e Anexo A 5.2Governação do Article 20 e medidas do Article 21Responsabilidade do órgão de gestão do Article 5 e quadro de risco das TIC do Article 6Responsabilização por medidas técnicas e organizacionaisResultados GOVERN para papéis, estratégia de risco e supervisão
Evidência de revisão de acessosAnexo A 5.15, 5.16 e 5.18Medidas de controlo de acesso, gestão de ativos e autenticaçãoProteção de TIC e controlos de riscoIntegridade, confidencialidade e limitação de acessoResultados PR.AA para identidade, autenticação e princípio do menor privilégio
Exercício de incidentes e registo de incidentesAnexo A 5.24, 5.25, 5.26 e 5.27Tratamento de incidentes do Article 21 e preparação para reporte do Article 23Classificação de incidentes relacionados com TIC, reporte e causa raizDeteção e tratamento de violação de dados pessoaisResultados RESPOND e RECOVER
Registos de monitorização de fornecedoresAnexo A 5.19, 5.20, 5.21 e 5.22Segurança da cadeia de fornecimento ao abrigo do Article 21Risco de terceiros de TIC, registos, contratos e saídaSupervisão de subcontratantes e salvaguardas de proteção de dadosResultados GV.SC para cadeia de fornecimento
Teste de restauro de cópia de segurançaAnexo A 8.13 e controlos de continuidadeContinuidade de negócio, cópia de segurança, recuperação de desastre e gestão de criseContinuidade, restauro e testes de resiliênciaDisponibilidade e resiliência do tratamentoResultados PR.DS e RC.RP para cópia de segurança e recuperação
Remediação de vulnerabilidadesAnexo A 8.8Tratamento de vulnerabilidades e manutenção seguraProteção, deteção e remediação do risco das TICSegurança do tratamento e redução do riscoResultados 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 auditorEm que se focará o auditorO 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 corretivaO controlo está ligado a risco, proprietário, procedimento, evidência, resultado de monitorização, exceção e ação corretiva
Avaliador orientado por NISTResultados atuais e pretendidos, governação, priorização de riscos, identidade, monitorização, resposta e recuperaçãoA CSA mapeia para resultados CSF, mostra desempenho atual e identifica lacunas face ao estado pretendido
Revisor DORASupervisã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çãoA evidência dos controlos de TIC é atual, baseada no risco, testada, escalonada e reportada à gestão quando relevante
Revisor do GDPR da UEResponsabilização, princípios de proteção de dados, segurança do tratamento, preparação para violações e supervisão de subcontratantesA 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 ISACAObjetivo de governação, propriedade do processo, capacidade, métricas, gestão de problemas e independência da garantiaA 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.

Clarysec · Parceiro revendedor PECB

Torne-se PECB ISO/IEC 27001 Lead Implementer ou Lead Auditor

Formação oficial PECB Lead Implementer ou Lead Auditor, com duas tentativas de exame e taxas de certificação incluídas. Combine-a com as políticas e registos ISO 27001 prontos para auditoria da Clarysec num pacote Certify + Comply.
  • ✓ 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
Oferta de lançamento · primeiras 10 utilizações
15% de desconto
Cursos PECB selecionados e pacotes Certify + Comply
Introduza este código no pagamento:
Máximo de 10 utilizações. Exclui o pacote duplo Lead Implementer + Lead Auditor e os kits vendidos separadamente. Não acumulável com descontos de grupo. PECB é uma marca registada da PECB Group Inc. A Clarysec LLC é parceira revendedora autorizada da PECB.

Sobre o autor

Igor Petreski

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

Formação ao vivo com o Igor
Formador certificado PECB. Cursos ISO/IEC 27001 Lead Implementer, Lead Auditor e Foundation, ministrados ao vivo online em inglês.
Ver cursos PECB →

Partilhar este artigo