Evidência de auditoria ISO 27001 para NIS2 e DORA

São 08:17 de uma terça-feira, e o CISO de uma empresa fintech SaaS em rápido crescimento tem três mensagens à espera.

A primeira é de um grande cliente bancário: “Por favor, envie o vosso relatório de auditoria interna mais recente, a ata da revisão pela gestão, o estado das ações corretivas, o procedimento de notificação de incidentes, o registo centralizado de fornecedores e evidência de supervisão pelo órgão de administração.”

A segunda é do CFO: “Estamos no âmbito da NIS2 ou do DORA, e que evidência já temos?”

A terceira é do CEO: “Podemos afirmar que estamos preparados para auditoria?”

A resposta desconfortável em muitas organizações não é que nada esteja a acontecer. É pior. O trabalho de segurança acontece em todo o lado, mas a evidência não está em lado nenhum. Existem controlos, mas não há trilho de auditoria. Existem tickets, mas não há uma ligação clara aos riscos. Existem atualizações para a liderança, mas não há resultados formais de revisão pela gestão. Existem discussões com fornecedores, mas não há um registo centralizado de fornecedores defensável, revisão contratual ou estratégia de saída.

É precisamente nessa lacuna que a auditoria interna e a revisão pela gestão ISO/IEC 27001:2022 deixam de ser meras atividades de certificação. Passam a ser o ritmo operacional para NIS2, DORA, RGPD da UE, garantia a clientes, seguro cibernético e responsabilização do órgão de administração.

Equipas SaaS, cloud, MSP, MSSP e fintech raramente falham por falta de atividade de segurança. Falham porque a atividade está dispersa por Slack, Jira, folhas de cálculo, portais de fornecedores, tickets do SOC, ficheiros de compras e apresentações ao órgão de administração. Um regulador, auditor externo ou cliente empresarial não quer uma explicação heroica. Quer evidência objetiva.

A solução prática não é executar programas de auditoria separados para cada referencial. É usar o SGSI ISO 27001 como motor central de evidência e, depois, etiquetar essa evidência para NIS2, DORA, RGPD da UE e requisitos contratuais. Quando bem feito, um ciclo de auditoria interna e uma revisão pela gestão conseguem responder a muitas questões de conformidade.

Da fadiga de referenciais a um modelo unificado de evidência do SGSI

Muitos CISO enfrentam uma versão do problema da Maria. A Maria lidera a segurança numa empresa SaaS B2B com clientes do setor financeiro. A sua equipa passou numa auditoria de certificação ISO/IEC 27001:2022 há seis meses. O SGSI está a amadurecer, as políticas são cumpridas e os proprietários dos controlos compreendem as suas responsabilidades. Depois, o CEO encaminha dois artigos, um sobre a Diretiva NIS2 e outro sobre o DORA, com uma pergunta curta: “Estamos cobertos?”

A resposta depende do âmbito, dos serviços, dos clientes e das entidades jurídicas. Mas a resposta operacional é clara: se a Maria tratar a NIS2 e o DORA como projetos de conformidade separados, criará trabalho duplicado, evidência inconsistente e fadiga de auditoria crescente. Se os tratar como requisitos das partes interessadas no SGSI, pode usar a ISO 27001 para absorver, testar e comprovar a preparação.

A ISO/IEC 27001:2022 foi concebida para isso. A cláusula 4 exige que a organização compreenda o seu contexto e os requisitos das partes interessadas, incluindo obrigações legais, regulamentares, contratuais e decorrentes de dependências. A cláusula 5 exige liderança e integração nos processos de negócio. A cláusula 6 exige avaliação de riscos e tratamento de riscos. A cláusula 9 exige avaliação de desempenho através de monitorização, auditoria interna e revisão pela gestão. A cláusula 10 exige melhoria e ação corretiva.

A NIS2 e o DORA encaixam naturalmente nessa estrutura.

A NIS2 exige que entidades essenciais e importantes implementem medidas técnicas, operacionais e organizativas de gestão de riscos de cibersegurança adequadas e proporcionais. Também atribui aos órgãos de administração a responsabilidade de aprovar essas medidas, supervisionar a sua implementação e poderem ser responsabilizados por infrações. As medidas mínimas abrangem análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de abastecimento, desenvolvimento seguro, tratamento de vulnerabilidades, avaliação da eficácia, formação, criptografia, segurança de recursos humanos, controlo de acessos, gestão de ativos e, quando aplicável, autenticação multifator ou autenticação contínua.

O DORA aplica-se a partir de 17 de janeiro de 2025 e cria um regime setorial de resiliência operacional digital para entidades financeiras. Exige responsabilidade do órgão de administração pela gestão do risco das TIC, um quadro documentado de gestão do risco das TIC, uma estratégia de resiliência operacional digital, planos de continuidade e recuperação das TIC, testes de resiliência, governação de incidentes das TIC e gestão do risco de terceiros de TIC. Para prestadores SaaS e cloud que servem entidades financeiras, o DORA pode surgir através de obrigações contratuais, auditorias de clientes e expectativas de gestão do risco de terceiros de TIC, mesmo quando o prestador não é, ele próprio, uma entidade financeira.

O RGPD da UE acrescenta a camada de responsabilização. Quando são tratados dados pessoais no âmbito do RGPD da UE, as organizações devem conseguir demonstrar conformidade com os princípios de proteção de dados e com medidas técnicas e organizativas adequadas.

A ISO 27001 não é um certificado mágico de conformidade para estas obrigações. É o sistema de gestão que as pode organizar, evidenciar e melhorar.

A questão do âmbito: o que está a comprovar e para quem?

Antes de construir um pacote de evidência preparado para auditoria, a liderança deve responder a uma pergunta básica: que obrigações estão no âmbito?

Para empresas SaaS e cloud, o âmbito da NIS2 pode ser mais amplo do que o esperado. A NIS2 aplica-se a entidades públicas ou privadas em setores listados que cumpram limiares de dimensão, bem como a determinadas entidades de elevado impacto independentemente da dimensão. Os setores relevantes podem incluir infraestrutura digital, prestadores de serviços de computação em nuvem, prestadores de centros de dados, redes de distribuição de conteúdos, prestadores de serviços de confiança, prestadores de comunicações eletrónicas públicas e prestadores B2B de gestão de serviços TIC, como prestadores de serviços geridos e prestadores de serviços de segurança geridos. Os prestadores SaaS devem prestar especial atenção à forma como os serviços são prestados, aos setores que suportam e a se permitem administração a pedido e amplo acesso remoto a recursos de computação partilhados e escaláveis.

Para prestadores fintech e do setor financeiro, o DORA deve ser analisado separadamente. O DORA abrange diretamente uma ampla gama de entidades financeiras, incluindo instituições de crédito, instituições de pagamento, prestadores de serviços de informação sobre contas, instituições de moeda eletrónica, empresas de investimento, prestadores de serviços de criptoativos, plataformas de negociação, gestores de fundos, empresas de seguros e resseguros e prestadores de serviços de financiamento colaborativo. Os prestadores terceiros de serviços TIC também fazem parte do ecossistema DORA, porque as entidades financeiras devem gerir as suas dependências de TIC, manter registos de acordos contratuais e incluir disposições contratuais específicas para serviços TIC que suportem funções críticas ou importantes.

A NIS2 e o DORA também interagem. Quando um ato jurídico setorial da UE impõe requisitos equivalentes de gestão de riscos de cibersegurança ou de notificação de incidentes, as disposições correspondentes da NIS2 podem não se aplicar a essas entidades nessas áreas. O DORA é o regime setorial de resiliência operacional para entidades financeiras. Isso não torna a NIS2 irrelevante para todos os prestadores envolventes. Significa que o modelo de evidência deve distinguir se a organização é uma entidade financeira diretamente sujeita ao DORA, um prestador terceiro de serviços TIC que suporta entidades financeiras, um prestador SaaS no âmbito da NIS2 ou um grupo com múltiplas entidades jurídicas e linhas de serviço.

Esta análise de âmbito pertence ao contexto do SGSI e ao registo das partes interessadas. Sem ela, o Plano de Auditoria irá testar as coisas erradas.

Um trilho de auditoria, muitas questões de conformidade

Um erro comum é criar pacotes de evidência separados para ISO 27001, NIS2, DORA, RGPD da UE, seguro cibernético e auditorias de clientes. Essa abordagem cria duplicação e respostas contraditórias. Uma abordagem melhor é um único modelo de evidência com várias perspetivas.

No centro está o SGSI. À sua volta existem cinco famílias de evidência.

Esta estrutura está alinhada com Zenith Blueprint: Roteiro de 30 passos para auditores Zenith Blueprint. Na fase de Auditoria, Revisão e Melhoria, o Passo 25 centra-se no programa de auditoria interna, o Passo 26 na execução da auditoria, o Passo 28 na revisão pela gestão e o Passo 29 na melhoria contínua.

A orientação do Passo 25 do Blueprint é deliberadamente prática:

“Desenvolva um calendário que indique quando as auditorias irão ocorrer e o que irão abranger.”

“Use o modelo de Plano de Auditoria Interna, se disponibilizado; este pode ser um documento simples ou uma folha de cálculo que liste datas de auditoria, âmbito e auditores designados.”

De Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 25: Programa de Auditoria Interna Zenith Blueprint

Esse Plano de Auditoria simples torna-se poderoso quando é baseado no risco e etiquetado para obrigações NIS2, DORA e RGPD da UE.

Controlos ISO 27001 que ancoram a preparação para auditoria

Para a preparação para auditoria, três controlos ISO/IEC 27002:2022 são especialmente importantes quando interpretados através de Zenith Controls: Guia de Conformidade Cruzada Zenith Controls:

• 5.4 Responsabilidades da gestão
• 5.35 Revisão independente da segurança da informação
• 5.36 Conformidade com políticas, regras e normas de segurança da informação

Estes não são “controlos Zenith” separados. São controlos ISO/IEC 27002:2022 que Zenith Controls ajuda a mapear, auditar e interpretar em vários referenciais.

O controlo 5.4 pergunta se as responsabilidades de segurança da informação estão atribuídas e compreendidas. O controlo 5.35 pergunta se a segurança da informação é revista de forma independente. O controlo 5.36 pergunta se a organização cumpre as suas políticas, regras e normas.

Zenith Controls classifica o controlo 5.35 numa lógica orientada para garantia:

O controlo 5.35 da ISO/IEC 27002:2022, “Revisão independente da segurança da informação”, é tratado em Zenith Controls como “Preventivo, Corretivo”, suportando confidencialidade, integridade e disponibilidade através dos conceitos de cibersegurança “Identificar” e “Proteger”, com capacidade operacional em “Garantia de Segurança da Informação”. Zenith Controls

Isto é importante porque a auditoria interna é simultaneamente preventiva e corretiva. Previne pontos cegos ao testar o SGSI antes do escrutínio externo e corrige fraquezas através de ações documentadas.

O mapeamento mais amplo começa com os requisitos NIS2 e DORA e identifica depois a evidência ISO 27001 que os pode comprovar.

O mapeamento de controlos só é útil quando a evidência é forte. Se o registo for fraco, nenhum crosswalk o salvará. Se o registo estiver completo, a mesma evidência pode responder a questões de estilo ISO, NIS2, DORA, RGPD da UE, NIST Cybersecurity Framework 2.0 e COBIT 2019.

Evidência de políticas que a Clarysec espera que as organizações retenham

As políticas da Clarysec transformam a teoria do SGSI em expectativas de evidência.

Para PME, a Política de Auditoria e Monitorização da Conformidade para PME Política de Auditoria e Monitorização da Conformidade para PME exige aprovação da liderança e disciplina de auditoria:

“O Diretor-Geral deve aprovar um Plano de Auditoria anual.”

De Política de Auditoria e Monitorização da Conformidade para PME, Requisitos de governação, cláusula 5.1.1 Política de Auditoria e Monitorização da Conformidade para PME

Também define uma cadência mínima:

“As auditorias internas ou revisões de conformidade devem ser realizadas, pelo menos, anualmente.”

De Política de Auditoria e Monitorização da Conformidade para PME, Requisitos de governação, cláusula 5.2.1

E liga constatações à correção e à revisão pela gestão:

“O Diretor-Geral deve aprovar um plano de ações corretivas e acompanhar a sua implementação.”

De Política de Auditoria e Monitorização da Conformidade para PME, Requisitos de governação, cláusula 5.4.2

“As constatações de auditoria e as atualizações de estado devem ser incluídas no processo de revisão pela gestão do SGSI.”

De Política de Auditoria e Monitorização da Conformidade para PME, Requisitos de governação, cláusula 5.4.3

A retenção de evidência também é explícita:

“A evidência deve ser retida durante, pelo menos, dois anos, ou por mais tempo quando exigido por certificação ou acordos com clientes.”

De Política de Auditoria e Monitorização da Conformidade para PME, Requisitos de implementação da política, cláusula 6.2.4

Para organizações de maior dimensão, a Política de Auditoria e Monitorização da Conformidade Política de Auditoria e Monitorização da Conformidade, também referida em alguns materiais da Clarysec como P33 Política de Auditoria e Monitorização da Conformidade, expande a estrutura:

“Deve ser desenvolvido e aprovado anualmente um Plano de Auditoria baseado no risco, tendo em conta:”

De Política de Auditoria e Monitorização da Conformidade, Requisitos de governação, cláusula 5.2 Política de Auditoria e Monitorização da Conformidade

“A organização deve manter um Registo de Auditoria que contenha:”

De Política de Auditoria e Monitorização da Conformidade, Requisitos de governação, cláusula 5.4

“As auditorias internas devem seguir um procedimento documentado que inclua:”

De Política de Auditoria e Monitorização da Conformidade, Requisitos de implementação da política, cláusula 6.1.1

“Todas as constatações devem resultar numa CAPA documentada que inclua:”

De Política de Auditoria e Monitorização da Conformidade, Requisitos de implementação da política, cláusula 6.2.1

A revisão pela gestão está ancorada na Política de Segurança da Informação Política de Segurança da Informação, também referida em alguns materiais da Clarysec como P01 Política de Segurança da Informação:

“As atividades de revisão pela gestão (conforme ISO/IEC 27001 cláusula 9.3) devem ser conduzidas, pelo menos, anualmente e devem incluir:”

De Política de Segurança da Informação, Requisitos de governação, cláusula 5.3 Política de Segurança da Informação

Estes requisitos criam a cadeia de evidência esperada pelos auditores: plano aprovado, procedimento definido, Registo de Auditoria, constatações, CAPA, retenção e revisão pela liderança.

Construir o pacote de evidência preparado para auditoria

Um pacote de evidência preparado para auditoria não é uma pasta gigante criada dois dias antes da auditoria. É uma estrutura viva, mantida ao longo do ano.

O pacote de evidência deve ser mapeado para cláusulas ISO/IEC 27001:2022 e controlos do Anexo A, mas etiquetado por relevância regulamentar. Um registo de auditoria de fornecedor, por exemplo, pode suportar controlos de fornecedores do Anexo A, segurança da cadeia de abastecimento NIS2 e gestão do risco de terceiros de TIC no DORA. Um registo de exercício tabletop de incidente pode suportar gestão de incidentes ISO 27001, preparação para notificação faseada NIS2 e governação de incidentes graves relacionados com TIC no DORA.

Como realizar a auditoria interna integrada

O Passo 26 de Zenith Blueprint enfatiza a evidência objetiva:

“Realize a auditoria recolhendo evidência objetiva para cada item da sua lista de verificação.”

“Entreviste pessoal relevante.”

“Reveja documentação.”

“Observe práticas.”

“Faça amostragem e verificações por amostragem.”

De Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 26: Execução da Auditoria Zenith Blueprint

É exatamente isso que a preparação para NIS2 e DORA exige. Reguladores e clientes não aceitarão “acreditamos que isto funciona”. Perguntarão como sabe.

Uma auditoria bem conduzida testa quatro dimensões de evidência.

Considere um evento de ransomware simulado num servidor de pré-produção. O auditor testa se o processo de resposta a incidentes consegue cumprir requisitos ISO 27001, expectativas de reporte faseado NIS2 e obrigações de cliente DORA.

A NIS2 tem uma estrutura de reporte faseado para incidentes significativos, incluindo alerta precoce no prazo de 24 horas após a tomada de conhecimento, notificação de incidente no prazo de 72 horas e relatório final no prazo de um mês após a notificação do incidente. O DORA tem o seu próprio quadro de classificação e reporte de incidentes relacionados com TIC para entidades financeiras. A auditoria interna deve verificar se os playbooks capturam a hora de tomada de conhecimento, critérios de severidade, serviços afetados, indicadores de compromisso (IoC), ações de mitigação, causa raiz, deveres de notificação a clientes e dados de reporte final.

Transformar uma constatação de auditoria em evidência NIS2 e DORA

Uma constatação realista sobre fornecedores mostra como a evidência deve fluir.

Durante a auditoria interna, o auditor recolhe amostras de cinco fornecedores críticos. Um prestador de registo de eventos na nuvem suporta monitorização de fraude e alertas de segurança para a plataforma fintech. O fornecedor está listado no inventário, mas não existe plano de saída documentado, não há evidência de revisão anual de segurança e não existe confirmação de que o contrato inclui assistência em incidentes ou direitos de auditoria.

O auditor regista uma não conformidade face aos requisitos de segurança de fornecedores e saída de serviços cloud. Uma resposta fraca diria “revisão de fornecedor em falta”. Uma resposta forte cria uma cadeia de evidência de conformidade cruzada:

1. Registar a constatação no relatório de auditoria, incluindo dimensão da amostra, nome do fornecedor, referência contratual e evidência em falta.
2. Adicionar uma entrada CAPA com causa raiz, como “a lista de verificação de integração de fornecedores não incluía classificação de criticidade nem acionador de plano de saída”.
3. Atribuir o proprietário do fornecedor e o proprietário do risco.
4. Atualizar o registo centralizado de fornecedores para assinalar o serviço como suporte de uma função crítica ou importante.
5. Realizar uma avaliação de riscos que cubra interrupção de serviço, acesso a dados, risco de concentração, dependência de notificação de incidentes e lacunas contratuais.
6. Atualizar o plano de tratamento de riscos e a Declaração de Aplicabilidade quando relevante.
7. Obter uma adenda contratual atualizada ou uma aceitação do risco documentada.
8. Criar ou testar um plano de saída.
9. Reauditar a evidência do fornecedor após a remediação.
10. Reportar a constatação, o risco e as necessidades de recursos na revisão pela gestão.

Esta única cadeia suporta múltiplas obrigações. A NIS2 espera segurança da cadeia de abastecimento e consideração das vulnerabilidades dos fornecedores, práticas de cibersegurança e procedimentos de desenvolvimento seguro. O DORA exige que as entidades financeiras giram o risco de terceiros de TIC, mantenham registos de acordos contratuais, avaliem prestadores antes da contratação, incluam direitos de auditoria e inspeção quando adequado, mantenham direitos de cessação e documentem estratégias de saída para serviços TIC que suportem funções críticas ou importantes. O RGPD da UE também pode ser relevante se o fornecedor tratar dados pessoais.

O registo de auditoria deixa de ser apenas evidência de conformidade. Passa a ser evidência de resiliência.

Revisão pela gestão: onde a evidência se transforma em responsabilização

A auditoria interna descobre a verdade. A revisão pela gestão decide o que fazer com ela.

O Passo 28 de Zenith Blueprint descreve o pacote de entradas para a revisão pela gestão:

“A ISO 27001 especifica várias entradas obrigatórias para a revisão pela gestão. Prepare um relatório ou apresentação breve que cubra estes pontos.”

O Blueprint lista o estado de ações anteriores, alterações em questões externas e internas, desempenho e eficácia do SGSI, incidentes ou não conformidades, oportunidades de melhoria e necessidades de recursos.

De Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 28: Revisão pela Gestão Zenith Blueprint

Para NIS2 e DORA, a revisão pela gestão é onde a responsabilização ao nível do órgão de administração se torna visível. A revisão não deve limitar-se a dizer “a segurança foi discutida”. Deve demonstrar que a liderança reviu:

• Alterações em requisitos NIS2, DORA, RGPD da UE, de clientes e contratuais.
• Alterações de âmbito, incluindo novos países, produtos, clientes regulados ou dependências de TIC.
• Resultados de auditoria interna, incluindo não conformidades maiores e menores.
• Estado de CAPAs e ações em atraso.
• Objetivos e métricas de segurança.
• Tendências de incidentes, quase-incidentes e lições aprendidas.
• Riscos de concentração em fornecedores e cloud.
• Resultados de testes de continuidade de negócio e cópias de segurança.
• Desempenho de vulnerabilidades e aplicação de patches.
• Necessidades de recursos, incluindo pessoas, ferramentas, formação e orçamento.
• Riscos residuais que exigem aceitação formal.
• Decisões de melhoria e proprietários responsabilizados.

É aqui que a Maria pode transformar um relatório técnico em garantia estratégica. Em vez de dizer “encontrámos uma lacuna no processo de incidentes”, pode dizer: “A auditoria identificou uma não conformidade menor nos nossos critérios de decisão de reporte de incidentes NIS2. A CAPA atualiza o procedimento, acrescenta uma matriz de decisão e exige um exercício tabletop no prazo de 30 dias. Precisamos de aprovação da gestão para revisão jurídica e tempo de formação.”

Esse é o tipo de registo que suporta governação, supervisão e tomada de decisão defensável.

Ação corretiva: a diferença entre uma constatação e maturidade

Uma auditoria interna sem ação corretiva é apenas um diagnóstico.

O Passo 29 de Zenith Blueprint instrui as organizações a usar um registo CAPA:

“Preencha-o com cada problema: descrição do problema, causa raiz, ação corretiva, proprietário responsável, data-alvo de conclusão, estado.”

De Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 29: Melhoria Contínua Zenith Blueprint

Também faz uma distinção importante:

“Em termos de auditoria: a correção corrige o sintoma; a ação corretiva corrige a causa. Ambas são importantes.”

De Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 29: Melhoria Contínua

Se a evidência de restauro de cópias de segurança estiver em falta, a correção pode ser executar e documentar um teste de restauro esta semana. A ação corretiva é alterar o procedimento de cópias de segurança para que os testes de restauro sejam agendados trimestralmente, gerem tickets automaticamente, sejam revistos pelo proprietário do serviço e incluídos nas métricas de revisão pela gestão.

Os auditores procuram essa maturidade. Um auditor ISO 27001 testa a conformidade com o SGSI e os controlos selecionados. Um revisor NIS2 pergunta se as medidas de gestão de riscos são eficazes e supervisionadas. Um revisor DORA procura integração do quadro de risco das TIC, testes de resiliência, gestão de dependências de terceiros e remediação. Um avaliador NIST Cybersecurity Framework 2.0 pode perguntar se os resultados de governação, identificar, proteger, detetar, responder e recuperar estão a operar. Um auditor COBIT 2019 pode focar-se em objetivos de governação, propriedade, indicadores de desempenho e garantia.

O mesmo registo CAPA pode satisfazer estas perspetivas se incluir causa raiz, proprietário, impacto no risco, ação corretiva, data limite, evidência de implementação, revisão de eficácia e visibilidade pela gestão.

As várias perspetivas do auditor

Diferentes auditores leem a mesma evidência de forma diferente. Zenith Controls ajuda a antecipar essas questões ao funcionar como guia de conformidade cruzada para controlos ISO/IEC 27002:2022 e referenciais relacionados.

O controlo 5.36 é um bom exemplo. O auditor ISO 27001 pode focar-se em saber se as revisões de conformidade acontecem e alimentam ações corretivas. O revisor NIS2 pode perguntar se essas revisões testam medidas legais de cibersegurança, e não apenas regras internas. O revisor DORA pode focar-se em saber se as revisões de conformidade incluem prestadores críticos de TIC e aplicação contratual.

É por isso que a evidência deve ser concebida para múltiplos leitores desde o início.

Um sprint prático de 30 dias para preparação para auditoria

Se o CEO perguntar se a organização consegue estar preparada para auditoria em 30 dias, a resposta honesta é: é possível construir uma linha de base de evidência credível se a liderança apoiar o sprint e o âmbito for realista.

Este sprint não substitui a maturidade a longo prazo. Cria uma linha de base operacional defensável. O valor real surge quando a organização repete o ciclo trimestral ou semestralmente, e não apenas uma vez por ano.

Falhas comuns de evidência que a Clarysec encontra

As mesmas fraquezas aparecem em auditorias SaaS, cloud e fintech:

• O Plano de Auditoria existe, mas não é baseado no risco.
• A lista de verificação de auditoria testa cláusulas ISO, mas ignora obrigações NIS2, DORA, RGPD da UE e de clientes.
• Existem atas de revisão pela gestão, mas não demonstram decisões, afetação de recursos ou aceitação do risco.
• Os registos CAPA listam ações, mas não apresentam causa raiz.
• As constatações são encerradas sem verificação de eficácia.
• As revisões de fornecedores são realizadas, mas os fornecedores críticos não são distinguidos de fornecedores de baixo risco.
• Existem playbooks de incidentes, mas ninguém consegue provar que o fluxo de reporte de 24 ou 72 horas funcionaria.
• As tarefas de cópia de segurança estão verdes, mas os testes de restauro não estão evidenciados.
• As revisões de acessos são exportadas, mas as exceções não são acompanhadas até ao encerramento.
• Os logs são recolhidos, mas ninguém consegue demonstrar monitorização, escalonamento ou resposta.
• A evidência é armazenada em pastas pessoais, em vez de num repositório controlado.
• Os requisitos de retenção são pouco claros ou inconsistentes com os contratos de clientes.

Estas falhas são corrigíveis. Exigem uma arquitetura estruturada de evidência do SGSI, não uma corrida de última hora atrás de documentos.

Como deve ser uma boa resposta ao órgão de administração

Quando o CISO regressa ao CEO e ao CFO, a resposta mais forte não é “passámos numa lista de verificação de auditoria”. É:

“Temos um Plano de Auditoria aprovado. Realizámos uma auditoria interna baseada no risco. Identificámos constatações com evidência objetiva. Aprovámos CAPAs com proprietários e datas limite. Escalonámos riscos materiais, incidentes, dependências de fornecedores e necessidades de recursos para a revisão pela gestão. Mapeámos evidência para ISO/IEC 27001:2022, NIS2, DORA e RGPD da UE. Conseguimos demonstrar o trilho de auditoria.”

Essa resposta muda a conversa. Dá confiança ao CEO perante clientes. Dá ao CFO clareza sobre exposição regulamentar. Dá ao órgão de administração um registo de supervisão defensável. Dá ao CISO um roteiro priorizado, em vez de uma pilha de pedidos desconexos.

Mais importante ainda, move a organização do teatro de conformidade para a resiliência operacional.

Próximos passos com a Clarysec

A sua próxima auditoria não deve ser uma corrida desordenada. Deve ser prova visível de que o seu SGSI funciona, a liderança está envolvida e a organização está preparada para ISO 27001, NIS2, DORA, RGPD da UE e garantia a clientes.

A Clarysec pode ajudar a:

• Construir um Plano de Auditoria interna baseado no risco usando Zenith Blueprint: Roteiro de 30 passos para auditores Zenith Blueprint.
• Mapear evidência de auditoria através de Zenith Controls: Guia de Conformidade Cruzada Zenith Controls.
• Implementar governação de auditoria para PME ou empresas usando Política de Auditoria e Monitorização da Conformidade para PME Política de Auditoria e Monitorização da Conformidade para PME ou Política de Auditoria e Monitorização da Conformidade Política de Auditoria e Monitorização da Conformidade.
• Preparar pacotes de revisão pela gestão alinhados com a Política de Segurança da Informação Política de Segurança da Informação e as expectativas da ISO/IEC 27001:2022 cláusula 9.3.
• Transformar constatações em registos CAPA, decisões da gestão e melhoria mensurável.

Descarregue os toolkits da Clarysec, marque uma avaliação de preparação ou solicite uma demonstração para transformar a sua próxima auditoria interna em evidência pronta para o órgão de administração para ISO 27001, NIS2, DORA e além.