ISO 27001 como base de evidência para NIS2 e DORA

A colisão de conformidade de segunda-feira de manhã

Às 08:12 de segunda-feira, Maria, diretora de segurança da informação (CISO) de um processador de pagamentos europeu, recebe três mensagens que parecem não ter relação entre si.

O responsável de auditoria interna pede evidência de que a Declaração de Aplicabilidade da ISO 27001:2022 está atualizada. A equipa jurídica encaminha um questionário de um parceiro bancário sobre a supervisão do risco de terceiros TIC no âmbito do DORA. O diretor de operações pergunta se o mesmo procedimento operacional de incidentes pode suportar as expectativas de notificação NIS2 para uma unidade de negócio da UE recentemente adquirida.

Às 09:00, o quadro branco no gabinete de Maria está coberto de acrónimos: ISO 27001, NIS2, DORA, RGPD da UE, NIST, COBIT 2019. A organização tem controlos. Tem gestão de acessos, cópias de segurança, questionários a fornecedores, cifragem, resposta a incidentes, aprovações de políticas, revisões pela gestão e registos de formação. O que não tem é uma base única de evidência preparada para auditoria que explique por que razão esses controlos existem, que riscos tratam, que regulamentos suportam, quem é responsável por eles e onde se encontra a evidência.

Este problema está a tornar-se comum em toda a Europa. A NIS2 impulsiona a gestão de riscos de cibersegurança, a governação, o tratamento de incidentes e a resiliência da cadeia de fornecimento. O DORA acrescenta requisitos detalhados de gestão do risco das TIC, testes de resiliência, comunicação de incidentes e supervisão de terceiros TIC para entidades financeiras. O RGPD da UE continua a exigir responsabilização, segurança do tratamento, governação de subcontratantes e avaliação de violações de dados pessoais.

A resposta errada é criar três programas de conformidade paralelos. Isso gera controlos duplicados, evidência inconsistente e equipas sobrecarregadas.

A resposta mais sólida é usar a ISO 27001:2022 como base de controlos. Não como um certificado na parede, mas como o sistema operativo para risco, políticas, governação de fornecedores, resposta a incidentes, mapeamento de conformidade e evidência de auditoria.

O modelo prático da Clarysec é simples: usar o SGSI da ISO 27001:2022 como sistema de organização, usar a Declaração de Aplicabilidade como ponte, usar políticas como regras operacionais aplicáveis e usar Zenith Controls: O Guia de Conformidade Cruzada como bússola de conformidade cruzada. Construir uma vez, mapear cuidadosamente e demonstrar continuamente.

Por que razão a ISO 27001:2022 funciona como base de conformidade

A NIS2 e o DORA têm âmbitos, mecanismos jurídicos e modelos de supervisão diferentes. A NIS2 aplica-se a entidades essenciais e importantes em vários setores. O DORA aplica-se a entidades financeiras e cria requisitos detalhados para a resiliência operacional digital. O RGPD da UE centra-se no tratamento de dados pessoais e na responsabilização.

Ainda assim, as questões operacionais por trás destes referenciais sobrepõem-se:

• A cibersegurança é governada por políticas aprovadas pela gestão?
• Os riscos de segurança da informação e de TIC são identificados, avaliados e tratados?
• Os controlos são selecionados com base no risco, no contexto de negócio e nas obrigações legais?
• Os fornecedores são governados através de diligência prévia, contratos, monitorização e controlos de saída?
• O pessoal consegue reconhecer e comunicar eventos de segurança numa fase inicial?
• Os incidentes podem ser triados, escalados, investigados e avaliados para efeitos de notificação regulatória?
• A organização consegue obter evidência rapidamente durante uma auditoria, uma revisão de cliente ou um pedido de esclarecimento de uma autoridade de supervisão?

A ISO 27001:2022 dá à liderança um sistema de gestão para responder a essas questões de forma consistente. A ISO/IEC 27007:2022 trata a Declaração de Aplicabilidade como uma lista auditável de controlos de segurança da informação selecionados, incluindo controlos do Anexo A da ISO 27001:2022, de outras normas ou de medidas específicas da organização, com justificação documentada para inclusão ou exclusão. A ISO/IEC 27006-1:2024 reforça que a SoA e a documentação relacionada do SGSI formam uma base central de evidência para demonstrar que controlos são necessários, como as responsabilidades são atribuídas e como as políticas são implementadas e comunicadas.

Isto torna a SoA muito mais do que uma folha de cálculo. Ela passa a ser o contrato de controlo entre risco, conformidade, operações, jurídico, compras, auditoria e Conselho de Administração.

A [P01] Política de Segurança da Informação da Clarysec ancora este requisito de governação:

A organização deve implementar e manter um Sistema de Gestão de Segurança da Informação (SGSI) em conformidade com as Cláusulas 4 a 10 da ISO/IEC 27001:2022.

Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.

Isto é importante porque os pedidos de evidência NIS2 e DORA raramente chegam em linguagem ISO. Um regulador, cliente ou comité do Conselho de Administração pode pedir evidência de gestão de riscos de cibersegurança, governação das TIC, supervisão de dependências de terceiros, escalonamento de incidentes ou testes de resiliência operacional. O SGSI da ISO 27001:2022 dá estrutura a essas respostas.

A SoA é a ponte, não um exercício documental

Em Zenith Blueprint: Roteiro de 30 passos para auditores, na fase de Gestão de Riscos, Passo 13, a Clarysec enquadra a SoA como o principal mecanismo de rastreabilidade entre o tratamento de riscos e os controlos implementados:

A SoA é, na prática, um documento de ligação: liga a sua avaliação/tratamento de riscos aos controlos que efetivamente tem.

Esta frase é o núcleo da conformidade cruzada. Um controlo sem rastreabilidade torna-se um artefacto solto. Um controlo ligado a um risco, obrigação legal, política, responsável, registo de evidência e resultado de teste fica preparado para auditoria.

O Passo 13 também recomenda adicionar referências de controlos aos cenários de risco, como ligar um cenário de violação de uma base de dados de clientes ao controlo de acessos, criptografia, gestão de vulnerabilidades, resposta a incidentes e controlos de fornecedores. Recomenda ainda assinalar quando os controlos suportam requisitos externos, como RGPD da UE, NIS2 ou DORA.

A [P06] Política de Gestão de Riscos da Clarysec torna esta regra operacional explícita:

As decisões de controlo resultantes do processo de tratamento de riscos devem ser refletidas na SoA.

Da secção “Requisitos de implementação da política”, cláusula 6.5.1 da política.

Para organizações de menor dimensão, a Política de Gestão de Riscos - PME usa a mesma lógica:

Garante que a gestão de riscos é uma componente ativa do planeamento, da execução de projetos, da seleção de fornecedores e da resposta a incidentes, em alinhamento com a ISO 27001, a ISO 31000 e os requisitos regulamentares aplicáveis.

Da secção “Finalidade”, cláusula 1.2 da política.

Se um tratamento de risco de terceiros DORA, uma medida de tratamento de incidentes NIS2 ou um requisito de segurança de subcontratante do RGPD da UE não estiver refletido na SoA ou no Registo de Conformidade relacionado, a organização pode ainda assim estar a executar o trabalho. Mas terá dificuldade em demonstrá-lo de forma coerente.

Um mapeamento prático da ISO 27001:2022 para NIS2 e DORA

O mapeamento seguinte não constitui aconselhamento jurídico. É um modelo prático de evidência para CISO, responsáveis de conformidade, auditores internos e responsáveis de negócio que precisam de alinhar a evidência ISO 27001:2022 com as expectativas NIS2 e DORA.

A ENISA, em colaboração com a Comissão Europeia e o Grupo de Cooperação NIS, disponibilizou orientações consultivas de referências cruzadas que ajudam a alinhar requisitos de cibersegurança da UE com normas internacionais e nacionais, incluindo a ISO 27001. Essas orientações não são juridicamente vinculativas e devem ser complementadas com instruções das autoridades nacionais, regras setoriais e revisão jurídica. Ainda assim, suportam uma abordagem de mapeamento defensável.

O mapeamento funciona porque não cria controlos duplicados para cada regulamento. Usa a ISO 27001:2022 como base de controlos e acrescenta etiquetas regulatórias, propriedade e expectativas de evidência.

Três controlos ISO 27001:2022 que desbloqueiam a base

Vários controlos são relevantes para NIS2 e DORA, mas três controlos da ISO/IEC 27002:2022 tornam-se frequentemente a espinha dorsal do modelo de evidência: 5.1, 5.19 e 5.24. Um quarto controlo, 6.8, determina muitas vezes se a comunicação de incidentes funciona na prática.

No Zenith Controls, o controlo 5.1 da ISO/IEC 27002:2022, Políticas de segurança da informação, é caracterizado como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, tendo a governação e a gestão de políticas como capacidades operacionais essenciais. O mapeamento cruzado explica que os Artigos 5(2), 24 e 32 do RGPD da UE exigem responsabilização, responsabilidade e segurança do tratamento. Também mapeia o mesmo controlo para as expectativas de gestão de riscos de cibersegurança e governação da NIS2, e para os requisitos de governação das TIC e de quadro de gestão de riscos do DORA.

É por isso que a Política de Segurança da Informação não é apenas mais uma política. Um avaliador NIS2 pode lê-la como evidência de governação. Um supervisor DORA pode lê-la como evidência do quadro de risco das TIC. Um revisor do RGPD da UE pode lê-la como evidência de responsabilização. Um auditor ISO 27001:2022 pode lê-la como parte da estrutura de políticas do SGSI.

O controlo 5.19, Segurança da informação nas relações com fornecedores, é onde compras, jurídico, segurança, privacidade e resiliência se encontram. O Zenith Controls mapeia-o para obrigações de subcontratantes no RGPD da UE, cibersegurança da cadeia de fornecimento NIS2 e gestão do risco de terceiros DORA. Para o DORA, esta evidência torna-se ainda mais forte quando suportada pelos controlos 5.20, Tratamento da segurança da informação em acordos com fornecedores, 5.21, Gestão da segurança da informação na cadeia de fornecimento TIC, e 5.23, Segurança da informação na utilização de serviços na nuvem.

O controlo 5.24, Planeamento e preparação da gestão de incidentes de segurança da informação, é o motor operacional da preparação para incidentes. O Zenith Controls mapeia-o para tratamento e notificação de incidentes NIS2, notificação de violações de dados pessoais no RGPD da UE e gestão e reporte de incidentes relacionados com TIC no DORA. A sua evidência não é apenas uma política de resposta a incidentes. Inclui canais de reporte, critérios de triagem, registos de escalonamento, avaliações jurídicas de notificação, exercícios de mesa, tickets de incidentes e lições aprendidas.

O controlo 6.8, Comunicação de eventos de segurança da informação, fecha a lacuna entre o plano escrito e o comportamento humano. Se o pessoal não souber como comunicar suspeitas de phishing, fuga de dados, indisponibilidade de fornecedores ou atividade suspeita nos sistemas, a organização pode perder tempo crítico antes de as avaliações jurídicas ou regulatórias de reporte sequer começarem.

Um incidente de fornecedor, uma cadeia de evidência coordenada

Imagine que um fornecedor de serviços de análise na nuvem usado pelo processador de pagamentos de Maria deteta acesso não autorizado a um portal de suporte. O fornecedor aloja dados pseudonimizados de utilização de clientes e suporta um fluxo de reporte crítico para o negócio. O incidente pode afetar dados pessoais, resiliência TIC regulamentada e disponibilidade do serviço.

Um programa de conformidade fragmentado abre três fluxos de trabalho separados: uma avaliação de violação no RGPD da UE, uma revisão de incidente TIC DORA e um ticket de fornecedor ISO 27001. Cada equipa pede evidência semelhante num formato diferente. A equipa de compras procura o contrato. O jurídico pergunta se o fornecedor é um subcontratante. A segurança pergunta se o incidente cumpre os limiares de reporte. A conformidade inicia uma nova folha de cálculo.

Uma base ISO 27001:2022 madura abre uma única cadeia de evidência coordenada.

Primeiro, o evento é registado no âmbito do processo de resposta a incidentes. O autor do reporte usa um canal definido, a equipa de segurança tria o evento e o jurídico avalia as obrigações de notificação. A [P30] Política de Resposta a Incidentes da Clarysec exige que incidentes que envolvam dados regulados sejam avaliados pelo Jurídico e pelo EPD:

Se um incidente resultar em exposição confirmada ou provável de dados pessoais ou de outros dados regulados, o Jurídico e o EPD devem avaliar a aplicabilidade de:

Da secção “Requisitos de implementação da política”, cláusula 6.4.1 da política.

Para organizações de menor dimensão, a Política de Resposta a Incidentes-sme - PME atribui o mesmo ponto de decisão prático:

Quando estiverem envolvidos dados de clientes, o Diretor-Geral deve avaliar as obrigações legais de notificação com base na aplicabilidade do RGPD da UE, NIS2 ou DORA.

Da secção “Tratamento do risco e exceções”, cláusula 7.4.1 da política.

Em segundo lugar, a relação com o fornecedor é revista. O fornecedor estava classificado como crítico? O contrato incluía obrigações de notificação de violação de dados, direitos de auditoria, responsabilidades de proteção de dados, expectativas de continuidade do serviço e disposições de saída? A Política de segurança de terceiros e fornecedores da Clarysec estabelece essa expectativa:

Incorporar requisitos de segurança padronizados em todos os contratos com fornecedores, incluindo obrigações de notificação de violação de dados, direitos de auditoria e responsabilidades de proteção de dados.

Da secção “Objetivos”, cláusula 3.2 da política.

Para PME, a Política de Segurança de Terceiros e Fornecedores-sme - PME torna explícita a finalidade de conformidade cruzada:

Suportar a conformidade com obrigações da ISO/IEC 27001:2022, do RGPD da UE, da NIS2 e do DORA relacionadas com a governação de fornecedores.

Da secção “Objetivos”, cláusula 3.6 da política.

Em terceiro lugar, o Registo de Riscos, o plano de tratamento e a SoA são atualizados se o incidente revelar uma lacuna. Talvez o contrato do fornecedor não tenha um prazo específico de notificação regulatória. Talvez a frequência de monitorização do fornecedor seja demasiado baixa para um fornecedor TIC crítico. Talvez o plano de resposta a incidentes não distinga claramente os critérios de violação de dados pessoais dos critérios de interrupção de serviço TIC.

O objetivo não é criar um novo universo de conformidade. O objetivo é atualizar uma cadeia de evidência integrada para que os mesmos registos possam responder a várias questões de auditoria.

Transformar a SoA num mapa de evidência NIS2 e DORA

Uma SoA padrão costuma responder bem a questões ISO: quais controlos são aplicáveis, por que foram selecionados e se estão implementados. Para a tornar um mapa prático de evidência NIS2 e DORA, enriqueça-a com campos de evidência regulatória e operacional.

Abra o SoA_Builder.xlsx do Audit Ready Toolkit referenciado no Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 24. O Passo 24 explica que os auditores frequentemente selecionam uma amostra de um controlo da SoA e perguntam por que foi implementado. A coluna de justificação e o risco ou requisito associado devem responder a essa questão.

Adicione estas colunas:

Agora aplique isto ao conjunto central de controlos.

Em seguida, execute um rastreio por amostragem. Escolha um incidente de fornecedor do último ano e siga-o do ticket de incidente ao contrato do fornecedor, da classificação do fornecedor ao Registo de Riscos, do tratamento de riscos à SoA e da SoA à revisão pela gestão.

Se a cadeia se quebrar, isso não é uma falha. É uma ação corretiva precisa antes de um auditor, cliente, regulador ou comité do Conselho de Administração encontrar a lacuna.

A evidência centralizada é o acelerador subestimado

Muitas organizações têm controlos adequados, mas fraca capacidade de recuperação de evidência. A evidência está dispersa por correio eletrónico, sistemas de tickets, pastas SharePoint, repositórios contratuais, plataformas de Recursos Humanos, ferramentas GRC e portais de fornecedores. Durante a época de auditorias, a equipa de conformidade passa semanas a perseguir capturas de ecrã.

Isto não é preparação para auditoria. É recuperação para auditoria.

A [P33S] Política de Auditoria e Monitorização da Conformidade-sme - PME da Clarysec declara:

Toda a evidência deve ser armazenada numa pasta de auditoria centralizada.

Da secção “Requisitos de implementação da política”, cláusula 6.2.1 da política.

Uma pasta de auditoria centralizada não significa um depósito descontrolado. Significa um repositório estruturado alinhado com o SGSI, a SoA, o Registo de Riscos, o Plano de Auditoria e o Registo de Conformidade.

A Política de Cumprimento Legal e Regulamentar - PME da Clarysec aborda diretamente o problema de mapeamento:

Quando um regulamento se aplica a várias áreas (por exemplo, o RGPD da UE aplica-se à retenção, segurança e privacidade), isso deve ser claramente mapeado no Registo de Conformidade e nos materiais de formação.

Da secção “Requisitos de governação”, cláusula 5.2.2 da política.

É exatamente assim que a ISO 27001:2022 se torna a base de controlos para NIS2 e DORA. Não se depende de conhecimento informal. Mapeiam-se os regulamentos em processos, políticas, controlos, evidência e formação.

A comunicação de incidentes começa nas pessoas, não nos portais

Uma fraqueza comum em auditoria surge quando o plano de resposta a incidentes parece sólido, mas os colaboradores não sabem quando ou como reportar. Isto é perigoso para NIS2, DORA e RGPD da UE, porque os prazos de avaliação regulatória dependem da deteção, do escalonamento e da classificação.

No Zenith Blueprint, fase Controlos em Ação, Passo 16, a Clarysec enfatiza a comunicação de incidentes conduzida pelo pessoal ao abrigo do controlo 6.8 da ISO/IEC 27002:2022. A orientação afirma que a resposta a incidentes começa nas pessoas. As organizações devem criar um canal de reporte claro, simples e acessível, como um endereço de correio eletrónico monitorizado, portal interno, linha direta ou categoria de ticket. Também recomenda formação de sensibilização, uma cultura de reporte sem culpa, confidencialidade, reporte de baixo limiar e simulações periódicas.

O impacto na conformidade cruzada é direto. O Zenith Blueprint liga esta capacidade de reporte pelo pessoal ao Artigo 33 do RGPD, ao Artigo 23 da NIS2 e ao Artigo 17 do DORA. Se os colaboradores hesitarem em reportar atividade suspeita, a organização pode perder tempo crítico antes de as equipas jurídica, de segurança ou regulatória conseguirem avaliar as obrigações de notificação.

Um teste prático de controlo é simples:

1. Pergunte a cinco colaboradores como devem reportar uma mensagem de phishing suspeita.
2. Verifique se o canal de reporte é monitorizado.
3. Confirme se o sistema de tickets tem uma categoria de incidente de segurança.
4. Reveja a última simulação ou exercício de mesa.
5. Verifique se as lições aprendidas foram revistas em revisão pela gestão.

Se alguma resposta não for clara, atualize a folha de instruções de incidentes, o material de formação, o canal de reporte e a referência de evidência na SoA.

Como diferentes auditores inspecionam a mesma base

A evidência de conformidade cruzada tem de resistir a diferentes perspetivas de auditoria. O mesmo controlo pode ser testado de forma diferente consoante o mandato do revisor.

É aqui que o Zenith Controls acrescenta valor para além de uma simples tabela de mapeamento. Ajuda a traduzir os controlos ISO/IEC 27002:2022 em perspetivas relevantes para auditoria, incluindo atributos de controlo, relações regulatórias e expectativas de evidência. Para o controlo 5.1, os atributos suportam governação, gestão de políticas, responsabilização e objetivos de segurança. Para o controlo 5.24, os atributos suportam conceitos de resposta e recuperação, preparação para incidentes e ação corretiva. Para o controlo 5.19, os atributos de relacionamento com fornecedores ligam governação, risco do ecossistema, proteção e supervisão de terceiros.

O que o Conselho de Administração deve ver

O Conselho de Administração não precisa de ver todas as linhas da SoA. Precisa, sim, de compreender a história que a SoA conta.

Um pacote sólido para o Conselho de Administração sobre alinhamento ISO 27001:2022, NIS2 e DORA deve incluir:

• Âmbito do SGSI e serviços de negócio abrangidos.
• Principais riscos de segurança da informação e de TIC.
• Resumo dos controlos aplicáveis por domínio.
• Estado do mapeamento NIS2, DORA e RGPD da UE.
• Fornecedores críticos e riscos de concentração.
• Métricas de reporte de incidentes e resultados de exercícios de mesa.
• Ações corretivas em aberto e tratamentos de risco em atraso.
• Decisões necessárias sobre aceitação do risco, orçamento, propriedade e recursos.

Isto transforma conformidade em evidência de governação. Também se alinha com a finalidade do controlo 5.1 no Zenith Controls, em que as políticas de segurança da informação suportam a orientação ao nível executivo, a responsabilização e os objetivos de segurança.

Erros comuns a evitar

O primeiro erro é assumir que a certificação ISO 27001:2022 demonstra automaticamente conformidade com NIS2 ou DORA. Não demonstra. A ISO 27001:2022 dá-lhe um sistema de gestão robusto e uma base de controlos, mas continua a precisar de delimitação regulatória, análise jurídica, interpretação específica do setor, fluxos de notificação e conhecimento das expectativas das autoridades nacionais.

O segundo erro é tratar a SoA como estática. A SoA deve evoluir quando surgem novos fornecedores, sistemas, incidentes, regulamentos, serviços ou riscos. O Zenith Blueprint, Passo 24, recomenda verificar cruzadamente a SoA face ao Registo de Riscos e ao plano de tratamento, garantindo que cada controlo selecionado tem uma justificação baseada num risco mapeado, requisito legal ou necessidade de negócio.

O terceiro erro é mapear a um nível demasiado elevado. Um diapositivo que diz “a ISO 27001 mapeia para o DORA” não é evidência de auditoria. Uma entrada específica da SoA que liga a segurança nas relações com fornecedores a um risco de fornecedor TIC crítico, cláusula contratual, registo de revisão de fornecedor e expectativa de supervisão de terceiros DORA é muito mais forte.

O quarto erro é não centralizar a evidência. Se o responsável de conformidade passa duas semanas a recolher capturas de ecrã antes de cada auditoria, a organização tem um problema de recuperação de evidência.

O quinto erro é ignorar controlos de pessoas. Reporte de incidentes, integração de fornecedores, revisão de acessos, aceitação da política e escalonamento dependem todos do comportamento humano. Um processo polido que ninguém segue colapsará sob amostragem de auditoria.

O modelo operacional da Clarysec para conformidade cruzada

O método da Clarysec liga a história de conformidade desde a estratégia até à evidência:

• No Zenith Blueprint, fase de Gestão de Riscos, Passo 13, mapeia os controlos aos riscos e constrói a SoA como documento de ligação.
• No Zenith Blueprint, fase de Gestão de Riscos, Passo 14, referencia cruzadamente os requisitos do RGPD da UE, NIS2 e DORA com políticas e controlos.
• No Zenith Blueprint, fase Controlos em Ação, Passo 16, operacionaliza a comunicação de incidentes conduzida pelo pessoal para que o escalonamento comece cedo.
• No Zenith Blueprint, fase de Auditoria, Revisão e Melhoria, Passo 24, finaliza e testa a SoA, verifica-a cruzadamente com o plano de tratamento de riscos e prepara-a como um dos primeiros documentos que um auditor irá solicitar.

Esse método é suportado por políticas da Clarysec que transformam princípios em regras operacionais: governação da segurança da informação, tratamento de riscos, segurança de fornecedores, resposta a incidentes, mapeamento legal e regulamentar e armazenamento de evidência.

O resultado não é apenas preparação para a ISO 27001:2022. É um sistema reutilizável de evidência de conformidade para NIS2, DORA, RGPD da UE, programas de garantia para clientes, auditoria interna e supervisão pelo Conselho de Administração.

Próximos passos: construir uma vez, demonstrar muitas vezes

Se a sua organização enfrenta pressão relacionada com NIS2, DORA, RGPD da UE, auditorias de clientes ou certificação ISO 27001:2022, comece pela base.

1. Reveja a sua SoA e adicione colunas de fator regulatório para NIS2, DORA e RGPD da UE.
2. Verifique a SoA face ao seu Registo de Riscos e plano de tratamento de riscos.
3. Mapeie fornecedores críticos para controlos de segurança de fornecedores, cláusulas contratuais e evidência de monitorização.
4. Teste o seu fluxo de reporte de incidentes com um exercício de mesa.
5. Centralize a evidência de auditoria por controlo, regulamento, responsável e estado dos testes.
6. Use o Zenith Controls para traduzir controlos ISO/IEC 27002:2022 em evidência de conformidade cruzada.
7. Use o Zenith Blueprint para passar do tratamento de riscos para a validação da SoA preparada para auditoria.
8. Implemente o conjunto de políticas da Clarysec, incluindo a Política de Segurança da Informação, a Política de Gestão de Riscos, a Política de segurança de terceiros e fornecedores e a Política de Resposta a Incidentes, para acelerar a implementação.

O caminho mais rápido não é criar mais listas de verificação desconectadas. É ter um SGSI integrado, uma SoA rastreável, um modelo de evidência centralizado e um ritmo operacional único de conformidade cruzada.

A Clarysec pode ajudá-lo a transformar a ISO 27001:2022 de um projeto de certificação numa base prática de controlos para NIS2 e DORA. Descarregue o Zenith Blueprint, explore o Zenith Controls ou agende uma avaliação Clarysec para criar um modelo de evidência preparado para auditoria antes de o próximo regulador, cliente ou comité do Conselho de Administração pedir evidência.