Mapeamento NIS2 2024/2690 para ISO 27001 para prestadores de serviços cloud

Às 08:17 de uma terça-feira, Maria, Diretora de Segurança da Informação (CISO) de um prestador europeu de serviços geridos, recebe o alerta que qualquer MSP receia. Uma conta privilegiada de gestão remota acionou alertas de deslocação impossível. Dois tenants de clientes apresentam ações administrativas anómalas. O SOC já abriu uma ponte de incidente crítico.

Às 09:00, o CEO entra na chamada. As perguntas mudam de imediato.

Estamos no âmbito da NIS2? O Regulamento de Execução (UE) 2024/2690 da Comissão aplica-se à nossa organização? Precisamos de emitir um aviso prévio em 24 horas? Que clientes devem ser notificados? Conseguimos provar que MFA, registo de logs, segmentação, gestão de vulnerabilidades, controlos de fornecedores e escalonamento de incidentes estavam a funcionar antes do incidente?

A empresa de Maria é certificada pela ISO/IEC 27001:2022. Presta serviços de gestão cloud, serviços de centro de dados e suporte de segurança gerido a clientes que incluem um operador logístico e um banco regional. O certificado é importante, mas não responde, por si só, às questões operacionais. A equipa jurídica tem um processo de notificação em rascunho. O gestor de conformidade tem uma folha de cálculo. O auditor pediu a Declaração de Aplicabilidade, testes de resposta a incidentes, logs de acesso privilegiado, diligência prévia de fornecedores, evidência de responsabilidade partilhada na cloud e pressupostos de continuidade de negócio.

É neste momento que a NIS2 deixa de ser um texto jurídico e passa a ser um problema operacional de controlos.

Para prestadores de serviços de computação em cloud, prestadores de serviços geridos, prestadores de serviços de segurança geridos e prestadores de centros de dados, a NIS2 e o Regulamento de Execução 2024/2690 elevam o nível de exigência: da intenção genérica de segurança para evidência de controlos inspecionável. Governação, gestão de riscos, controlo de acesso, gestão de ativos, tratamento de vulnerabilidades, resposta a incidentes, segurança de fornecedores, registo de logs, monitorização, cifragem, continuidade de negócio e resiliência física devem funcionar como um único sistema.

A ISO/IEC 27001:2022 é a melhor espinha dorsal para esse sistema, mas apenas se a organização mapear os requisitos da NIS2 para o SGSI, o Registo de Riscos, a Declaração de Aplicabilidade, as políticas e o modelo de evidência. Um certificado na parede não basta. O verdadeiro trabalho consiste em criar um fio condutor auditável da regulamentação para o risco, do risco para o controlo, do controlo para a política e da política para a evidência operacional.

Porque a NIS2 2024/2690 muda a conversa sobre conformidade cloud e MSP

A NIS2 utiliza um modelo baseado em setor e dimensão, mas as suas categorias de infraestrutura digital e gestão de serviços TIC são intencionalmente amplas. Ao abrigo do Article 2 e do Article 3 da NIS2, lidos em conjunto com o Anexo I e o Anexo II, muitas organizações podem ser classificadas como entidades essenciais ou importantes, incluindo prestadores de serviços de computação em cloud, prestadores de serviços de centros de dados, prestadores de serviços geridos, prestadores de serviços de segurança geridos, prestadores DNS, registos TLD, redes de distribuição de conteúdos e prestadores de serviços de confiança. Os Estados-Membros devem estabelecer e rever periodicamente as listas de entidades essenciais e importantes, com o primeiro prazo de listagem definido para 17 de abril de 2025.

Isto é relevante porque prestadores de serviços cloud, MSP, MSSP e centros de dados estão integrados nas cadeias de risco de outras organizações. O comprometimento do plano de controlo de uma cloud pode afetar milhares de sistemas de clientes. Uma indisponibilidade num centro de dados pode propagar-se a setores como banca, saúde, logística e administração pública. Uma violação de credenciais num MSP pode transformar-se num evento de ransomware multicliente. Uma falha de deteção num MSSP pode atrasar a contenção em vários clientes regulados.

O Article 20 da NIS2 exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança e supervisionem a sua implementação. O Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, assentes numa abordagem multirriscos. A linha de base inclui análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e desenvolvimento seguros, tratamento e divulgação de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, formação, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, MFA ou autenticação contínua, comunicações seguras e comunicações de emergência.

O Article 23 acrescenta uma notificação faseada de incidentes significativos, incluindo um aviso prévio em 24 horas, uma notificação de incidente em 72 horas, relatórios intercalares quando solicitados e um relatório final no prazo de um mês após a notificação ou após o tratamento do incidente quando este ainda estiver em curso.

O Regulamento de Execução 2024/2690 torna estas expectativas mais concretas para os prestadores digitais relevantes. Na prática, autoridades, clientes e auditores não perguntarão apenas se existem políticas. Perguntarão se os controlos estão mapeados, atribuídos a responsáveis, testados e sustentados por evidência.

A ISO/IEC 27001:2022 transforma a NIS2 em contexto operacional do SGSI

Um erro comum na preparação para a NIS2 é começar com uma grande lista de verificação e distribuir tarefas por TI, jurídico, SOC, infraestrutura, gestão de fornecedores e conformidade. Isso pode gerar atividade, mas muitas vezes falha em auditoria porque ninguém consegue demonstrar por que razão os controlos foram selecionados, como se relacionam com o risco, quem aceitou o risco residual e que evidência comprova a eficácia.

A ISO/IEC 27001:2022 dá aos prestadores a estrutura necessária para evitar essa falha.

As cláusulas 4.1 a 4.4 exigem que a organização determine questões internas e externas, identifique partes interessadas e os respetivos requisitos, decida que requisitos serão tratados através do SGSI e defina o âmbito do SGSI, incluindo interfaces e dependências. Para um prestador de serviços cloud ou MSP, o âmbito deve considerar explicitamente a NIS2, o Regulamento de Execução 2024/2690, os anexos de segurança dos clientes, requisitos de clientes decorrentes da DORA, regiões cloud, subcontratantes, dependências de centros de dados, plataformas de gestão remota, caminhos de acesso privilegiado e obrigações de notificação de incidentes.

As cláusulas 5.1 a 5.3 exigem liderança, alinhamento de políticas, recursos, comunicação, responsabilidades atribuídas e responsabilização da gestão. Isto suporta diretamente o Article 20 da NIS2.

As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos, proprietários do risco, análise de probabilidade e consequências, seleção de controlos, comparação com o Anexo A, uma Declaração de Aplicabilidade, um plano de tratamento de riscos e aceitação formal do risco residual. É aqui que a NIS2 se torna operacional. Cada requisito regulamentar passa a ser um fator de risco, uma obrigação de conformidade, um requisito de controlo ou um requisito de evidência.

A Clarysec inicia este trabalho com Zenith Blueprint: roteiro de 30 passos para auditores Zenith Blueprint, em especial na fase de Gestão de Riscos.

A partir do Passo 13, Planeamento do Tratamento de Riscos e Declaração de Aplicabilidade, o Zenith Blueprint orienta as equipas a criar rastreabilidade entre riscos, controlos e fatores regulamentares:

“Referencie regulamentos de forma cruzada: se determinados controlos forem implementados especificamente para cumprir o RGPD da UE, a NIS2 ou a DORA, pode registá-lo no Registo de Riscos ou nas notas da SoA. Por exemplo, o controlo 8.27 (eliminação segura de dados) pode ser muito relevante para o requisito do RGPD da UE relativo à eliminação de dados pessoais; pode registar ‘Aplicável – suporta o RGPD da UE Art.32 (segurança do tratamento)’. Isto não é exigido pela ISO, mas ajuda a demonstrar que considerou esses referenciais.”

O Passo 14, Políticas de Tratamento de Riscos e Referências Regulamentares Cruzadas, acrescenta a disciplina prática de mapeamento:

“Para cada regulamento, quando aplicável, pode criar uma tabela de mapeamento simples que liste os principais requisitos de segurança do regulamento e os controlos/políticas correspondentes no seu SGSI. Isto não é obrigatório na ISO 27001, mas é um exercício interno útil para garantir que nada ficou por tratar.”

Essa é a diferença entre dizer “somos certificados ISO” e provar “o nosso SGSI ISO/IEC 27001:2022 trata o Regulamento de Execução NIS2 2024/2690.”

Mapeamento unificado de controlos NIS2 para ISO/IEC 27001:2022

O mapeamento seguinte não constitui aconselhamento jurídico nem substitui uma análise da transposição nacional. É uma arquitetura prática de controlos para prestadores que precisam de uma via ISO/IEC 27001:2022 auditável para a preparação NIS2.

Este mapeamento torna-se robusto quando é incorporado no Registo de Riscos e na Declaração de Aplicabilidade. Por exemplo, um prestador pode criar um cenário de risco denominado “Comprometimento da plataforma de gestão remota conduz a ações não autorizadas em ambientes de clientes.” Os controlos incluem MFA, Gestão de Acessos Privilegiados (PAM), segmentação, registo de logs, gestão de vulnerabilidades, segurança de fornecedores, planeamento de incidentes e procedimentos de notificação a clientes. As notas da SoA podem referenciar o Article 21 e o Article 23 da NIS2, o Regulamento de Execução 2024/2690, contratos de clientes e requisitos de diligência prévia de clientes associados à DORA, quando relevante.

Governação cloud: o controlo ISO 5.23 é uma âncora NIS2

Para prestadores de serviços cloud e MSP que utilizam serviços cloud para prestar serviços a clientes, o controlo 5.23 do Anexo A da ISO/IEC 27001:2022, Segurança da informação para a utilização de serviços cloud, é uma das âncoras mais importantes.

Zenith Controls: guia de conformidade cruzada Zenith Controls resume o controlo 5.23 como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, ligado à segurança nas relações com fornecedores, governação, risco do ecossistema e proteção. Abrange governação de serviços cloud, responsabilidade partilhada, avaliação de prestadores, inventários, localização dos dados, registo de logs, cifragem, funções de identidade, monitorização, cláusulas contratuais, risco de fornecedor, saída da cloud e planeamento de resiliência.

O Zenith Blueprint, na fase Controlos em Ação, Passo 23, explica a razão prática:

“A cloud já não é um destino; é a opção por defeito. O controlo 5.23 reconhece esta realidade e exige que a segurança da informação seja tratada explicitamente na seleção, utilização e gestão de serviços cloud, não como algo posterior, mas como um princípio de conceção desde o início.”

Para um MSP, todas as plataformas de monitorização e gestão remota, portais de clientes, ferramentas de tickets, plataformas de telemetria de segurança, serviços de cópia de segurança, diretórios cloud e consolas administrativas SaaS devem estar sujeitas a governação. Para um prestador de centros de dados, a governação cloud pode aplicar-se a plataformas de monitorização, sistemas de gestão de visitantes, integrações de controlo de acesso físico, sistemas de gestão remota e infraestrutura de portal de clientes.

A Política de Utilização da Cloud Enterprise da Clarysec Política de Utilização da Cloud torna obrigatória a diligência prévia antes da ativação:

“Toda a utilização da cloud deve ser sujeita a diligência prévia baseada no risco antes da ativação, incluindo avaliação do prestador, validação de cumprimento legal e revisões de validação de controlos.”

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

Para prestadores de menor dimensão, a Cloud Usage Policy-sme Cloud Usage Policy-sme - SME cria um modelo de aprovação simplificado:

“Toda a utilização de serviços cloud deve ser revista e aprovada pelo Diretor-Geral (GM) antes da implementação ou subscrição.”

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

Ambas as abordagens suportam a mesma expectativa da NIS2: o risco de dependência cloud deve ser compreendido antes de o serviço passar a fazer parte da cadeia de prestação.

Resposta a incidentes: o relógio de 24 horas começa antes de o relatório ser redigido

O Article 23 da NIS2 é exigente porque o prazo de notificação começa a contar a partir do conhecimento de um incidente significativo, não a partir do momento em que existe uma análise de causa raiz perfeita. O desafio para os prestadores é determinar rapidamente se um evento é significativo, que clientes são afetados, se há dados pessoais envolvidos, se existe impacto transfronteiriço no serviço e que prazos contratuais foram acionados.

O controlo 5.24 do Anexo A da ISO/IEC 27001:2022, Planeamento e preparação da gestão de incidentes de segurança da informação, é o controlo de planeamento. O Zenith Controls resume-o como um controlo corretivo que suporta confidencialidade, integridade e disponibilidade, ligado aos conceitos Respond e Recover, governação, gestão de eventos e defesa. Inclui papéis, responsabilidades, vias de escalonamento, protocolos de comunicação, preparação para notificações regulamentares, alinhamento com registo de logs e monitorização, integração com continuidade de negócio e recuperação de desastre, aprendizagem pós-incidente e mapeamento para NIS2, RGPD da UE, DORA, ISO 22301, NIST CSF, NIST SP 800-53 e COBIT 2019.

A Incident Response Policy-sme da Clarysec Incident Response Policy-sme - SME transforma a primeira decisão num requisito sujeito a prazo:

“O Diretor-Geral, com contributos do prestador de TI, deve classificar todos os incidentes por severidade no prazo de uma hora após a notificação.”

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

Essa classificação em uma hora suporta a disciplina operacional necessária para a análise do aviso prévio NIS2 em 24 horas, a avaliação de violação de dados pessoais ao abrigo do RGPD da UE, o escalonamento para clientes DORA e a triagem de notificações contratuais.

A árvore de decisão de incidentes de um prestador deve responder a quatro perguntas:

1. Existe comprometimento confirmado ou suspeito da confidencialidade, integridade ou disponibilidade?
2. O evento afeta a prestação do serviço, ambientes de clientes, clientes regulados, dados pessoais ou funções críticas?
3. Pode causar perturbação operacional grave, perda financeira ou dano material ou imaterial?
4. Que obrigações de notificação se aplicam: NIS2, RGPD da UE, obrigações de clientes DORA, SLA contratuais ou expectativas de reguladores nacionais?

A árvore de decisão deve ser testada em exercícios tabletop antes de um incidente real.

Gestão de vulnerabilidades: provar a redução do risco antes do impacto

A NIS2 exige tratamento e divulgação de vulnerabilidades. Para clientes e reguladores, a gestão de vulnerabilidades é uma das áreas de controlo mais fáceis de medir porque produz evidência clara: cobertura de scans, prazos de aplicação de patches, aprovações de exceções, análise de vulnerabilidades exploradas e registos de remediação.

O controlo 8.8 do Anexo A da ISO/IEC 27001:2022, Gestão de vulnerabilidades técnicas, é resumido no Zenith Controls como um controlo preventivo transversal à confidencialidade, integridade e disponibilidade, ligado a Identify e Protect, gestão de ameaças e vulnerabilidades, governação, ecossistema, proteção e defesa. Inclui identificação de vulnerabilidades, avaliação, priorização, aplicação de patches, controlos compensatórios, integração de informações sobre ameaças, divulgação de vulnerabilidades, responsabilidades por vulnerabilidades cloud e aplicacionais, evidência de auditoria e prazos de remediação.

A Política de Gestão de Vulnerabilidades e Patches Enterprise da Clarysec Política de Gestão de Vulnerabilidades e Patches oferece aos auditores um modelo concreto para testar:

“A organização deve classificar todas as vulnerabilidades detetadas utilizando uma metodologia normalizada (por exemplo, CVSS v3.x) e aplicar prazos de remediação alinhados com a criticidade de negócio: 5.2.1 Crítica (CVSS 9.0-10.0): revisão imediata; prazo máximo para aplicação do patch de 72 horas. 5.2.2 Alta (7.0-8.9): resposta no prazo de 48 horas; prazo para aplicação do patch de 7 dias de calendário. 5.2.3 Média (4.0-6.9): resposta no prazo de 5 dias; prazo para aplicação do patch de 30 dias de calendário. 5.2.4 Baixa (<4.0): resposta no prazo de 10 dias; prazo para aplicação do patch de 60 dias de calendário.”

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

Para um prestador de serviços cloud, isto deve abranger componentes de hipervisor, imagens de contentores, camadas de orquestração, Interfaces de Programação de Aplicações voltadas para clientes, pipelines de CI/CD, consolas administrativas e bibliotecas de terceiros. Para um MSP, a questão central é saber se as vulnerabilidades internas estão separadas das vulnerabilidades geridas pelo cliente e se os contratos definem a responsabilidade. Para um prestador de centros de dados, o âmbito pode incluir sistemas de gestão de edifícios, sistemas de controlo de acesso, plataformas de monitorização, ferramentas de remote hands e infraestrutura de rede.

O modelo de responsabilidade partilhada deve estar documentado. Um prestador pode não ser responsável por todos os patches, mas deve continuar a gerir o risco, notificar o cliente quando adequado e provar que os limites de responsabilidade são compreendidos.

Registo de logs, monitorização e segmentação tornam os incidentes investigáveis

Quando um incidente de prestador passa a afetar clientes, as primeiras perguntas sobre evidência são simples: quem iniciou sessão, a partir de onde, com que privilégio, em que tenant, o que foi alterado, que logs existem e se os caminhos administrativos estavam segmentados.

A Política de Registo de Logs e Monitorização Enterprise da Clarysec Política de registo em logs e monitorização exige que os sistemas abrangidos gerem os logs de que os respondedores e auditores precisam:

“Todos os sistemas abrangidos devem gerar logs que capturem: 6.1.1.1 Autenticação do utilizador e tentativas de acesso 6.1.1.2 Atividades de utilizadores privilegiados 6.1.1.3 Alterações de configuração 6.1.1.4 Tentativas de acesso falhadas ou eventos do sistema 6.1.1.5 Deteções de malware e alertas de segurança 6.1.1.6 Comunicações externas e acionamento de regras de firewall”

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

Para PME que dependem de prestadores externos, a Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME acrescenta um requisito contratual:

“Os contratos devem exigir que os prestadores retenham logs por, pelo menos, 12 meses e concedam acesso mediante pedido.”

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

A segmentação é igualmente importante. A Network Security Policy-sme Network Security Policy-sme - SME estabelece:

“As redes internas devem ser segmentadas por função (por exemplo, finanças, convidados, IoT, sistemas administrativos).”

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

O Zenith Blueprint, na fase Controlos em Ação, Passo 20, apresenta o procedimento prático de auditoria para arquitetura de rede e segmentação. Orienta as equipas a rever e documentar a topologia de rede, verificar regras de firewall, configurações IPS/IDS e de acesso remoto, confirmar que grupos de segurança cloud e regras de VPC ou sub-rede correspondem à arquitetura pretendida, listar serviços de rede internos e externos e validar que sistemas sensíveis não são alcançáveis a partir de VLANs de utilizadores gerais ou redes de convidados.

Para um MSP, as ferramentas de gestão remota não devem estar numa rede plana de escritório. Para um prestador de centros de dados, as interfaces de gestão de energia, refrigeração, controlo de acesso e serviços de rede de clientes devem estar isoladas e monitorizadas. Para um prestador de serviços cloud, o acesso ao plano de controlo deve ser restringido através de identidade, rede, postura do dispositivo e controlos de fluxo de trabalho privilegiado.

Segurança de fornecedores: o prestador também é cliente

Prestadores de serviços cloud, MSP, MSSP e centros de dados são fornecedores de clientes regulados, mas também são clientes de fornecedores de software, operadores de telecomunicações, fornecedores de identidade, plataformas SaaS, fornecedores de hardware, subcontratantes e operadores de infraestrutura.

A NIS2 torna a segurança da cadeia de fornecimento um requisito central. A DORA, aplicável a partir de 17 de janeiro de 2025, torna a gestão do risco de terceiros TIC central para as entidades financeiras. O Article 4 e o considerando 28 da NIS2 reconhecem a DORA como o ato jurídico setorial específico da União para entidades financeiras quando os requisitos se sobrepõem. Isto não retira pressão aos prestadores de serviços cloud e MSP. Aumenta-a, porque os clientes financeiros transferem requisitos contratuais de nível DORA, direitos de auditoria, testes de resiliência, estratégias de saída e expectativas de notificação de incidentes para os contratos com fornecedores.

A Política de Segurança de Terceiros e Fornecedores Enterprise da Clarysec Política de segurança de terceiros e fornecedores exige acesso de terceiros controlado:

“Todo o acesso de terceiros deve ser registado em logs e monitorizado e, sempre que viável, segmentado através de servidores bastião, VPN ou gateways Zero Trust.”

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

A Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME expressa o princípio do menor privilégio em termos diretos:

“Deve ser concedido aos fornecedores acesso apenas aos sistemas e dados mínimos necessários para desempenharem a sua função.”

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

Estas cláusulas mapeiam naturalmente para os controlos 5.19, 5.20, 5.21 e 5.22 do Anexo A da ISO/IEC 27001:2022. Também suportam a governação de subcontratantes e subcontratantes subsequentes ao abrigo do RGPD da UE, revisões de risco de terceiros DORA e questionários de auditoria de clientes.

Continuidade de negócio e resiliência de centros de dados: provar os pressupostos

O Article 21 da NIS2 inclui continuidade de negócio, gestão de cópias de segurança, recuperação de desastre e gestão de crises. Os Articles 11 a 14 da DORA exigem políticas de continuidade de negócio TIC, planos de resposta e recuperação, análise de impacto no negócio, políticas de cópias de segurança, procedimentos de restauro, objetivos de recuperação, testes, revisões pós-incidente e comunicações de crise para entidades financeiras.

Para prestadores de serviços cloud e de centros de dados, continuidade não é um dossiê. É arquitetura, capacidade, contratos, dependências, evidência de restauro e pressupostos testados.

A Política de Continuidade de Negócio e Recuperação de Desastre Enterprise da Clarysec Política de Continuidade de Negócio e Recuperação de Desastre exige BIA anual e revisão após alterações significativas:

“A análise de impacto no negócio (BIA) deve ser realizada, pelo menos, anualmente para todas as unidades de negócio críticas e revista perante alterações significativas em sistemas, processos ou dependências. Os resultados da BIA devem definir: 5.2.1. Tempo Máximo de Interrupção Tolerável (MTD) 5.2.2. Objetivos de Tempo de Recuperação (RTO) 5.2.3. Objetivos de Ponto de Recuperação (RPO) 5.2.4. Dependências críticas (sistemas, fornecedores, pessoal)”

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

Num cenário de centro de dados, a BIA deve abranger alimentações elétricas, UPS, geradores, contratos de combustível, refrigeração, supressão de incêndio, operadores de rede, sistemas de acesso físico, remote hands, monitorização, hardware sobresselente e canais de comunicação com clientes. Num cenário cloud, deve abranger regiões, zonas de disponibilidade, replicação, imutabilidade de cópias de segurança, dependências de identidade, DNS, Autoridades de Certificação, gateways de API e sistemas de suporte. Num cenário MSP, deve abranger ferramentas de gestão remota, cofres de acessos privilegiados, consolas EDR, tickets, repositórios documentais e comunicações de emergência.

A ISO 22301 pode reforçar a disciplina de gestão da continuidade do negócio, enquanto a ISO/IEC 27005:2022 suporta critérios de risco, planeamento de tratamento, monitorização, evidência e melhoria contínua. Isto é útil porque a preparação NIS2 exige que a organização consolide fatores legais, contratuais, operacionais, de fornecedores, tecnológicos, financeiros, processuais e humanos num único processo de risco.

Rastreio prático de risco para uma violação de acesso remoto num MSP

Um workshop prático pode começar com um cenário:

“Comprometimento de acesso remoto privilegiado resulta em acesso não autorizado a sistemas de clientes, interrupção de serviços, possível exposição de dados pessoais e obrigações de notificação regulamentar.”

Crie uma linha no Registo de Riscos e complete o rastreio.

Em seguida, atualize a Declaração de Aplicabilidade. Para cada controlo relevante do Anexo A, explique por que se aplica e que tema NIS2 suporta. Por fim, recolha evidência antes de uma auditoria: relatórios de aplicação de MFA, listas de contas privilegiadas, definições de retenção de logs, estado de patches RMM, alertas SIEM, registos de classificação de incidentes, aprovações de acesso de fornecedores e resultados de tabletop.

Como diferentes auditores testarão o mesmo ambiente de controlo

Um SGSI integrado deve satisfazer diferentes perspetivas de garantia sem criar pacotes de evidência separados para cada referencial.

É aqui que o Zenith Controls ajuda como guia de conformidade cruzada. Para controlos como 5.23, 5.24 e 8.8, liga as expectativas de controlo ISO/IEC 27001:2022 a temas NIS2, RGPD da UE, DORA, NIST SP 800-53, COBIT 2019, NIST CSF e ISO 22301. O objetivo não é criar programas de conformidade separados. O objetivo é uma única arquitetura de evidência etiquetada por controlo, risco, fator regulamentar e proprietário.

O padrão de implementação da Clarysec

Para prestadores de serviços cloud, MSP, MSSP e centros de dados, o trabalho deve avançar em cinco camadas.

Primeiro, confirme o âmbito. Determine se a organização e os serviços estão no âmbito da NIS2, que regras dos Estados-Membros se aplicam, se o Regulamento de Execução 2024/2690 se aplica à categoria do prestador e se os clientes impõem DORA, RGPD da UE, NIST ou obrigações setoriais específicas.

Segundo, construa o contexto do SGSI. Ao abrigo das cláusulas 4 e 5 da ISO/IEC 27001:2022, identifique partes interessadas, obrigações legais, compromissos com clientes, dependências de fornecedores, limites de serviço e responsabilidades de gestão.

Terceiro, realize a avaliação e o tratamento de riscos usando os princípios da ISO/IEC 27005:2022. Consolide NIS2, DORA, RGPD da UE, contratos, políticas internas e riscos de serviço num único registo de requisitos de referência. Defina critérios de risco, proprietários, probabilidade, impacto, opções de tratamento, escolhas de controlo e aprovações de risco residual.

Quarto, mapeie controlos para a Declaração de Aplicabilidade. Use os Passos 13 e 14 do Zenith Blueprint para rastrear riscos para controlos do Anexo A e expectativas regulamentares. Use o Zenith Controls para compreender como controlos como 5.23, 5.24, 8.8, 5.20 e 5.30 se mapeiam entre referenciais e perspetivas de auditoria.

Quinto, operacionalize a evidência. As políticas não bastam. A biblioteca de políticas da Clarysec fornece requisitos aplicáveis para aprovação de utilização cloud, acesso de fornecedores, registo de logs, remediação de vulnerabilidades, segmentação de rede, classificação de incidentes e planeamento de continuidade. O pacote de evidência comprova que esses requisitos estão a funcionar.

Próximo passo: transformar a pressão NIS2 em resiliência preparada para auditoria

O Regulamento de Execução NIS2 2024/2690 não exige caos. Exige rastreabilidade, propriedade e prova.

Se é prestador de serviços cloud, MSP, MSSP ou operador de centro de dados, comece pelos seus serviços, clientes, dependências, cenários de incidente e obrigações de evidência. Em seguida, execute um exercício estruturado de mapeamento NIS2 para ISO/IEC 27001:2022:

1. Confirme se a sua entidade e os seus serviços estão no âmbito.
2. Mapeie temas da NIS2 e do Regulamento de Execução para o âmbito do seu SGSI.
3. Atualize o Registo de Riscos e a Declaração de Aplicabilidade.
4. Aplique as políticas Clarysec para utilização cloud, segurança de fornecedores, registo de logs, gestão de vulnerabilidades, resposta a incidentes, segurança de redes e continuidade.
5. Use o Zenith Blueprint Zenith Blueprint Passos 13, 14, 20 e 23 para criar rastreabilidade e evidência operacional.
6. Use o Zenith Controls Zenith Controls para mapear controlos ISO/IEC 27001:2022 face às expectativas NIS2, DORA, RGPD da UE, NIST e COBIT 2019.
7. Teste a evidência através de uma simulação de auditoria antes que um cliente, regulador ou auditor de certificação a solicite.

A Clarysec pode ajudá-lo a ir além da conformidade por checklist e a criar um SGSI integrado que resista à pressão da NIS2, DORA, RGPD da UE e auditorias de clientes. Descarregue os toolkits Clarysec relevantes, marque um workshop de mapeamento ou solicite uma avaliação de preparação para auditoria para transformar complexidade regulamentar em governação de segurança defensável e resiliência operacional.