Avaliação do risco ISO 27001 pronta para auditoria para NIS2 e DORA

O café na secretária da Sarah estava frio.

Enquanto CISO de uma fintech em crescimento acelerado, Sarah estava habituada à pressão. A empresa acabara de conquistar um importante parceiro bancário, e o questionário de diligência prévia no seu ecrã deveria ter sido uma formalidade. As primeiras perguntas eram familiares: apresentar a Declaração de Aplicabilidade ISO/IEC 27001:2022, partilhar o registo de riscos mais recente, explicar a metodologia de avaliação do risco.

Depois, o questionário mudou de direção.

Demonstre de que forma o seu programa de gestão de riscos aborda o DORA. Explique a sua preparação para a Diretiva NIS2, incluindo a responsabilidade da gestão e as medidas de risco da cadeia de fornecimento. Apresente evidência de que os fornecedores críticos de TIC são avaliados, monitorizados e abrangidos por planos de resposta a incidentes e de continuidade de negócio.

Na manhã de segunda-feira, o mesmo tema estava na agenda do comité de risco do conselho de administração. Auditoria de certificação ISO 27001 dentro de oito semanas. Pressão DORA por parte de clientes do setor financeiro. Perguntas de classificação NIS2 relativas a uma linha de serviço alojada na nuvem em expansão para a UE. A área de compras afirmava que existiam revisões de fornecedores, mas a evidência estava dispersa por correio eletrónico, pastas contratuais e uma folha de cálculo de fornecedores. O departamento jurídico dizia que o mapeamento regulamentar ainda estava em curso. A engenharia dizia que o registo de riscos estava praticamente concluído.

O conselho de administração fez a única pergunta que importava:

Conseguimos provar que a nossa avaliação do risco e o nosso plano de tratamento do risco são suficientes?

Este é o verdadeiro problema para empresas SaaS, fintech, de serviços geridos, cloud e plataformas digitais. Não é saber se existe um registo de riscos. Não é saber se os controlos do Anexo A foram copiados para uma folha de cálculo. A questão é saber se a organização consegue demonstrar, sob pressão de auditoria e de clientes, que o seu processo de avaliação do risco ISO 27001 é repetível, baseado no risco, aprovado pelos proprietários do risco, ligado a ações de tratamento, mapeado para obrigações legais e operacionalmente vivo.

Quando bem executados, uma avaliação do risco ISO 27001 e um plano de tratamento do risco podem suportar a certificação ISO/IEC 27001:2022, as medidas de gestão de riscos de cibersegurança do Article 21 da NIS2, os requisitos DORA de gestão do risco das TIC, a responsabilidade no âmbito do RGPD da UE, a garantia de fornecedores, a preparação para incidentes e o reporte ao conselho de administração.

Quando mal executados, tornam-se uma folha de cálculo que os auditores desmontam em trinta minutos.

Este guia mostra como a Clarysec constrói evidência de avaliação do risco e tratamento do risco ISO 27001 pronta para auditoria usando o Zenith Blueprint: roteiro de 30 passos de um auditor, as políticas da Clarysec e o Zenith Controls: guia de conformidade cruzada.

Porque a avaliação do risco ISO 27001 é agora um eixo de conformidade

O panorama regulamentar da UE está a convergir em torno de um princípio simples: o risco de cibersegurança deve ser governado, documentado, testado e atribuído a responsáveis.

A ISO/IEC 27001:2022 já funciona desta forma. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o seu contexto, as partes interessadas, o âmbito do SGSI e as interações entre processos antes de avaliar o risco. As cláusulas 6.1.2 e 6.1.3 exigem um processo definido de avaliação do risco e tratamento do risco de segurança da informação. As cláusulas 8.2 e 8.3 exigem que a organização realize avaliações do risco e implemente o plano de tratamento, mantendo informação documentada.

A NIS2 e o DORA tornam esta mesma lógica baseada no risco mais urgente.

O Article 20 da NIS2 exige que os órgãos de administração das entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e frequentem formação em cibersegurança. O Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gerir os riscos para as redes e os sistemas de informação. Essas medidas incluem análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e autenticação multifator ou comunicações seguras, quando adequado.

O DORA exerce pressão semelhante sobre as entidades financeiras. Os Articles 5 e 6 exigem que o órgão de administração defina, aprove, supervisione e continue responsável pelos mecanismos de gestão do risco das TIC. O DORA espera um quadro documentado de gestão do risco das TIC integrado na gestão global de riscos, suportado por políticas, procedimentos, protocolos, ferramentas, auditoria interna, remediação, continuidade, testes, gestão de incidentes e governação de terceiros de TIC.

A conclusão é prática e incontornável: o registo de riscos já não é uma folha de trabalho da equipa técnica. É evidência de governação.

A Política de Gestão de Riscos Enterprise da Clarysec torna esta expectativa explícita:

Deve ser mantido um processo formal de gestão de riscos em conformidade com a ISO/IEC 27005 e a ISO 31000, abrangendo identificação de riscos, análise, avaliação do risco, tratamento de riscos, monitorização e comunicação.

Da Política de Gestão de Riscos Enterprise, secção “Requisitos de governação”, cláusula da política 5.1.

A mesma política define o resultado pronto para auditoria:

Manter um registo de riscos e um plano de tratamento de riscos centralizados e sujeitos a controlo de versões, refletindo o estado atual do risco, a cobertura de controlos e o progresso da mitigação.

Da Política de Gestão de Riscos Enterprise, secção “Objetivos”, cláusula da política 3.3.

A expressão “estado atual do risco, cobertura de controlos e progresso da mitigação” é a diferença entre um ficheiro estático de conformidade e um programa de riscos defensável.

Comece pelo âmbito, pelas obrigações e pelos critérios de risco

Muitas avaliações do risco ISO 27001 frágeis começam por uma lista de verificação de controlos. Isso inverte a lógica.

A ISO 27001 exige que a organização determine o contexto, os requisitos das partes interessadas, o âmbito do SGSI, as responsabilidades de liderança e o planeamento do risco antes de selecionar controlos. A ISO/IEC 27005:2022 reforça este ponto ao recomendar que as organizações identifiquem os requisitos básicos das partes interessadas antes de avaliar o risco. Esses requisitos podem resultar de normas ISO, regulamentos setoriais, legislação nacional, contratos de clientes, políticas internas, atividades anteriores de tratamento e obrigações de fornecedores.

Para uma empresa SaaS ou fintech orientada para a UE, o processo de risco deve começar por um inventário de conformidade e obrigações.

Para PME, a Política de Cumprimento Legal e Regulamentar - PME da Clarysec define o ponto de partida:

O Diretor-Geral deve manter um registo de conformidade simples e estruturado que liste:

Da Política de Cumprimento Legal e Regulamentar - PME, secção “Requisitos de governação”, cláusula da política 5.1.1.

Esse registo simples é uma ponte entre conformidade e gestão de riscos. Se indicar que o RGPD da UE se aplica porque são tratados dados pessoais da UE, que a NIS2 pode aplicar-se porque a organização presta serviços digitais ou geridos, ou que o DORA é relevante por via de clientes do setor financeiro, essas obrigações devem influenciar os critérios de risco e as prioridades de tratamento.

O Zenith Blueprint é direto neste ponto na fase de Gestão de Riscos, passo 10, “Estabelecer critérios de risco e matriz de impacto”:

Considere também os requisitos legais/regulamentares nos seus critérios de aceitação. Alguns riscos podem ser inaceitáveis independentemente da probabilidade devido à lei.

Do Zenith Blueprint, fase de Gestão de Riscos, passo 10.

Também fornece uma regra prática para workshops:

“Qualquer risco que possa conduzir ao incumprimento de leis aplicáveis (RGPD da UE, etc.) não é aceitável e deve ser mitigado.”

Do Zenith Blueprint, fase de Gestão de Riscos, passo 10.

Para a fintech da Sarah, isso altera o modelo de pontuação. Uma vulnerabilidade numa API de fornecedor pode ter baixa probabilidade, mas, se a sua exploração puder desencadear um incidente grave relacionado com as TIC ao abrigo do DORA, um incidente significativo NIS2, uma avaliação de violação ao abrigo do RGPD da UE, incumprimento de SLA de clientes ou escalonamento ao nível do conselho de administração, o impacto é elevado ou crítico. A exposição de conformidade passa a fazer parte da lógica de risco, não de uma folha de cálculo separada.

Construa um registo de riscos que os auditores consigam testar

Os auditores não perguntam apenas quais são os seus principais riscos. Testam se o método está definido, é repetível, rastreável e seguido.

Vão perguntar:

• Como identificou estes riscos?
• Que ativos, serviços, fornecedores, tipos de dados e processos estavam no âmbito?
• Que critérios foram usados para probabilidade e impacto?
• Quem é o proprietário de cada risco?
• Que controlos existentes reduzem o risco?
• Porque foi selecionada a decisão de tratamento?
• Onde está a evidência de que o tratamento foi realizado?
• Quem aprovou o risco residual?
• Quando será o risco reavaliado?

A Política de Gestão de Riscos - PME da Clarysec captura a entrada mínima de risco pronta para auditoria:

Cada entrada de risco deve incluir: descrição, probabilidade, impacto, pontuação, proprietário e plano de tratamento.

Da Política de Gestão de Riscos - PME, secção “Requisitos de governação”, cláusula da política 5.1.2.

Para programas empresariais, o Zenith Blueprint, fase de Gestão de Riscos, passo 11, “Construir e documentar o registo de riscos”, expande a estrutura. Recomenda colunas como ID do risco, ativo, ameaça, vulnerabilidade, descrição do risco, probabilidade, impacto, nível de risco, controlos atuais, proprietário do risco, decisão de tratamento, plano de tratamento ou controlos, e estado.

Uma entrada de risco robusta tem este aspeto:

Isto é materialmente diferente de “Risco de terceiros, Alto, mitigar”. A versão pronta para auditoria liga ativo, ameaça, vulnerabilidade, consequência, controlos atuais, proprietário, regulamento, evidência e governação.

Transforme o tratamento do risco num plano de evidência

Um plano de tratamento do risco deve responder a quatro perguntas operacionais:

1. O que vamos fazer?
2. Quem é o responsável?
3. Quando estará concluído?
4. Como provaremos que reduziu o risco?

A cláusula 6.1.3 da ISO/IEC 27001:2022 exige que a organização selecione opções de tratamento, determine os controlos necessários, os compare com o Anexo A para evitar omissões, produza uma Declaração de Aplicabilidade, formule um plano de tratamento e obtenha a aprovação dos proprietários do risco para o plano e para os riscos residuais. A cláusula 8.3 exige depois a implementação do plano de tratamento e a manutenção de informação documentada sobre os resultados.

A Política de Gestão de Riscos Enterprise torna isto prático:

O Responsável pelo Risco deve assegurar que os tratamentos são realistas, limitados no tempo e mapeados para os controlos do Anexo A da ISO/IEC 27001.

Da Política de Gestão de Riscos Enterprise, secção “Requisitos de implementação da política”, cláusula da política 6.4.2.

A política PME também clarifica que a aceitação não é um atalho:

Aceitar: justificar porque não é necessária ação adicional e registar o risco residual.

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

A aceitação deve ser justificada face aos critérios, aprovada pelo proprietário adequado e monitorizada. Ao abrigo da NIS2 e do DORA, risco residual não aprovado pode tornar-se uma falha de governação.

Um plano de tratamento completo deve conter estes campos:

Para o R-042 da Sarah, o plano de tratamento torna-se uma lista de ações de conformidade cruzada.

Este plano é poderoso porque cria uma linha direta entre um cenário de risco e controlos ISO 27001, obrigações NIS2, artigos DORA, proprietários e evidência.

Faça a Declaração de Aplicabilidade trabalhar mais

A Declaração de Aplicabilidade é frequentemente tratada como um artefacto de certificação. Deve ser mais do que isso.

A cláusula 6.1.3 da ISO/IEC 27001:2022 exige que a SoA inclua os controlos necessários, a justificação para inclusão, o estado de implementação e a justificação para exclusões. A orientação da ISO/IEC 27005:2022 reforça a necessidade de comparar os controlos selecionados com o Anexo A da ISO/IEC 27001 para evitar omissões.

Num programa pronto para auditoria, a SoA torna-se a ponte entre o tratamento do risco e a evidência de conformidade cruzada. Se um plano de tratamento exigir MFA, registo, monitorização de fornecedores, restauro de cópias de segurança, desenvolvimento seguro, escalonamento de incidentes ou planeamento de saída da cloud, a SoA deve mostrar que os controlos relevantes do Anexo A estão incluídos, justificados, implementados ou planeados, e evidenciados.

Isto também ajuda a evitar uma falha comum de auditoria: o registo de riscos diz uma coisa, o plano de tratamento diz outra e a SoA é omissa. Quando esses artefactos divergem, os auditores perdem rapidamente confiança.

Mapear o tratamento do risco ISO 27001 para NIS2, DORA e RGPD da UE

A ISO 27001 não substitui a NIS2, o DORA nem o RGPD da UE. Fornece um mecanismo estruturado para produzir evidência para estes regimes.

O ponto essencial é integrar o mapeamento no processo de risco, em vez de o acrescentar mais tarde.

Este mapeamento é especialmente importante quando os regulamentos se sobrepõem. O DORA é o regime setorial de resiliência das TIC para muitas entidades financeiras, enquanto a NIS2 pode continuar diretamente relevante para determinados prestadores, coordenação ou entidades fora do âmbito do DORA. Uma fintech pode precisar do DORA como o seu principal quadro de resiliência das TIC, enquanto um prestador de serviços geridos que apoie essa fintech pode estar sujeito diretamente a obrigações NIS2.

O registo de riscos deve conseguir mostrar os dois lados dessa dependência.

Use o Zenith Controls como bússola de conformidade cruzada

A Clarysec usa o Zenith Controls como guia de conformidade cruzada para evitar a falha comum em que controlos ISO, artigos regulamentares e perguntas de auditoria vivem em universos separados. Não cria um quadro de controlos separado. Mapeia as áreas de controlo da ISO/IEC 27001:2022 e da ISO/IEC 27002:2022 para outras normas, expectativas de auditoria e perspetivas de conformidade.

Para a avaliação do risco e o tratamento do risco ISO 27001, estas referências são especialmente importantes:

A lição de conformidade cruzada é simples. Se as obrigações legais não estiverem no método de avaliação do risco, a sua pontuação está incompleta. Se a pontuação estiver incompleta, as prioridades de tratamento podem estar erradas. Se as prioridades estiverem erradas, a SoA e o reporte ao conselho de administração tornam-se pouco fiáveis.

O Zenith Blueprint faz a mesma observação na fase de Gestão de Riscos, passo 14, “Políticas de tratamento de riscos e referências cruzadas regulamentares”. Recomenda que as organizações criem uma tabela de mapeamento com os principais requisitos regulamentares de segurança e os controlos ou políticas correspondentes no SGSI. Isto não é obrigatório para a certificação ISO 27001, mas é muito útil para demonstrar que a segurança está a ser gerida em contexto legal e contratual.

O que diferentes auditores vão perguntar

Um auditor de certificação, revisor orientado para NIS2, cliente orientado para DORA, revisor de RGPD da UE, avaliador NIST ou profissional COBIT pode analisar a mesma evidência, mas formular perguntas diferentes.

É por isso que a arquitetura da evidência é importante. A mesma entrada de risco deve ser rastreável desde o objetivo de negócio até ao ativo, ameaça, vulnerabilidade, controlo, proprietário, impulsionador regulamentar, ação de tratamento, resultado de teste e decisão de gestão.

As políticas da Clarysec são concebidas para suportar essa arquitetura. A Política de Gestão de Riscos Enterprise declara, na secção “Normas e referenciais de referência”:

Article 5: exige um quadro documentado de gestão do risco das TIC, totalmente coberto pela estrutura desta política, incluindo mapeamento da SoA e KRI.

Isto transforma a política de um documento estático em evidência de auditoria que mostra que a governação do risco das TIC foi intencionalmente desenhada com o DORA em mente.

Constatações comuns que comprometem programas de risco

Quando a Clarysec revê evidência de avaliação do risco e tratamento do risco ISO 27001, as mesmas constatações surgem repetidamente.

Primeiro, os critérios de risco ignoram impacto legal, regulamentar, contratual, de fornecedores e de privacidade. Isto causa pontuação fraca. Uma violação de dados pessoais ou falha crítica de fornecedor pode ser classificada como Média porque a probabilidade é baixa, embora o impacto sobre RGPD da UE, NIS2, DORA ou clientes devesse torná-la Alta ou Crítica.

Segundo, os proprietários do risco são genéricos. “TI” não é um proprietário do risco. Um proprietário do risco deve ser uma função ou pessoa responsável pelas decisões de tratamento, orçamento, calendário e risco residual.

Terceiro, os planos de tratamento não são limitados no tempo. “Melhorar a monitorização” não é um plano. “Implementar alertas de sessões privilegiadas no SIEM para contas administrativas de produção até 30 de junho, sob responsabilidade do Gestor do Centro de Operações de Segurança (SOC), testados por autenticação administrativa simulada, com evidência de alerta anexada” é um plano.

Quarto, a SoA está desligada do tratamento. Se o plano de tratamento exige monitorização de fornecedores, testes de cópias de segurança, escalonamento de incidentes, MFA ou registo, a SoA deve refletir os controlos relevantes e o estado de implementação.

Quinto, o risco residual não está aprovado. A ISO 27001 exige aprovação do proprietário do risco para o plano de tratamento e para os riscos residuais. A NIS2 e o DORA tornam isto ainda mais importante porque a responsabilidade da gestão é explícita.

Sexto, o risco de fornecedores é tratado como administração de compras. Ao abrigo do NIS2 Article 21(2)(d) e dos DORA Articles 28 e 30, o risco de fornecedores e de terceiros de TIC deve fazer parte da gestão de riscos, e não de um questionário anual armazenado de forma isolada.

Sétimo, não há evidência de eficácia. A cláusula 6.1.1 da ISO 27001 exige que as ações planeadas sejam avaliadas quanto à eficácia. A NIS2 inclui avaliação da eficácia no Article 21(2)(f). O DORA espera testes e remediação. Um controlo que existe mas nunca é testado é evidência fraca.

A Política de Gestão de Riscos - PME define a expectativa de forma clara:

O Diretor-Geral e o Coordenador de Risco devem assegurar que as atividades de gestão de riscos estão prontas para auditoria. O registo de riscos e as ações relacionadas estão sujeitos a auditoria interna e externa.

Da Política de Gestão de Riscos - PME, secção “Aplicação e cumprimento”, cláusula da política 8.2.1.

Reporte ao conselho de administração sem afogar os executivos

A NIS2, o DORA e a ISO 27001 apontam todos para a responsabilidade da gestão, mas os conselhos de administração não precisam de cada linha de risco. Precisam de reporte útil para decisão.

Um bom pacote de riscos para o conselho de administração deve mostrar:

• Riscos Altos e Críticos por domínio
• Ações de tratamento em atraso
• Riscos regulamentares que envolvem NIS2, DORA, RGPD da UE ou contratos
• Riscos de fornecedores que afetam serviços críticos ou importantes
• Tendências de incidentes e quase-incidentes
• Riscos residuais a aguardar aceitação
• Resultados de testes de eficácia dos controlos
• Alterações materiais ao âmbito, fornecedores, tecnologia ou lei
• Constatações de auditoria interna e ações corretivas

A Clarysec normalmente recomenda revisões operacionais mensais de risco e revisões pela gestão trimestrais. As revisões mensais focam-se na execução do tratamento. As revisões trimestrais focam-se na aceitação, financiamento, priorização, exposição regulamentar e decisões estratégicas de risco.

Este ritmo também suporta a melhoria contínua. As avaliações do risco devem ser atualizadas quando ocorrem incidentes, surgem vulnerabilidades, são introduzidos novos ativos, a tecnologia muda, os fornecedores mudam, as leis mudam, as obrigações de clientes mudam ou o apetite pelo risco muda.

O percurso de implementação da Clarysec

Um programa de riscos unificado evita folhas de cálculo desconectadas para ISO, NIS2, DORA, RGPD da UE e garantia de clientes. O caminho prático é:

1. Confirmar o âmbito do SGSI, serviços, ativos, fornecedores, jurisdições e obrigações de clientes.
2. Construir ou atualizar o registo de conformidade usando a Política de Cumprimento Legal e Regulamentar - PME, quando adequado.
3. Definir a metodologia de risco, critérios de aceitação, escalas de probabilidade, escalas de impacto e regras de impacto regulamentar.
4. Construir o registo de riscos usando a fase de Gestão de Riscos do Zenith Blueprint e a abordagem da Clarysec para registo de riscos e construtor de SoA.
5. Identificar riscos baseados em ativos e riscos baseados em cenários, incluindo cenários de fornecedores, cloud, privacidade, continuidade, incidentes, vulnerabilidades, desenvolvimento seguro e acesso.
6. Pontuar os riscos usando critérios que incluam impacto legal, regulamentar, contratual, operacional, de privacidade, de fornecedores e financeiro.
7. Selecionar opções de tratamento: mitigar, evitar, transferir ou aceitar.
8. Mapear os controlos necessários para o Anexo A da ISO/IEC 27001:2022 e a orientação da ISO/IEC 27002:2022.
9. Criar ou atualizar a Declaração de Aplicabilidade.
10. Mapear os tratamentos para o NIS2 Article 21, a gestão do risco das TIC e as expectativas de terceiros do DORA, a responsabilidade do RGPD da UE e as obrigações contratuais de clientes.
11. Recolher evidência, validar a eficácia dos controlos e obter aprovação do risco residual.
12. Preparar um pacote de auditoria organizado por risco, controlo, regulamento e artefacto de evidência.
13. Integrar os resultados na revisão pela gestão, auditoria interna, ação corretiva e melhoria contínua.

Isto não é documentação pela documentação. É o sistema operativo para uma governação cibernética defensável.

Construa um pacote de tratamento do risco pronto para auditoria

A história da Sarah termina bem porque ela deixou de tratar a ISO 27001, a NIS2 e o DORA como projetos de conformidade separados. Usou a avaliação do risco ISO 27001 como motor central, incorporou obrigações regulamentares nos critérios de risco, mapeou ações de tratamento para o Anexo A e para requisitos da UE, e recolheu evidência que clientes, auditores e o conselho de administração conseguiam compreender.

A sua organização pode fazer o mesmo.

Use o Zenith Blueprint: roteiro de 30 passos de um auditor para definir critérios de risco, construir o registo de riscos, criar o plano de tratamento do risco e referenciar requisitos regulamentares de forma cruzada.

Use o Zenith Controls: guia de conformidade cruzada para ligar as áreas de controlo do Anexo A da ISO/IEC 27001:2022 a perspetivas de governação, cumprimento legal, garantia e auditoria.

Use a Política de Gestão de Riscos, a Política de Gestão de Riscos - PME e a Política de Cumprimento Legal e Regulamentar - PME da Clarysec para normalizar propriedade, registos, decisões de tratamento e evidência pronta para auditoria.

O próximo passo prático mais rápido é selecionar os seus dez principais riscos e testá-los contra cinco perguntas:

1. O impacto regulamentar está visível?
2. O plano de tratamento é limitado no tempo e tem proprietário?
3. Cada tratamento está mapeado para o Anexo A e para a SoA?
4. A relevância para NIS2, DORA, RGPD da UE ou cliente está documentada quando aplicável?
5. Existe evidência de que o controlo funciona?

Se a resposta for não, a Clarysec pode ajudar a transformar o seu registo de riscos num programa de tratamento do risco defensável e de conformidade cruzada, em que auditores, reguladores, clientes e conselhos de administração possam confiar.