Declaração de Aplicabilidade ISO 27001 para preparação para NIS2 e DORA

São 08:30 de uma segunda-feira e Elena, diretora de segurança da informação (CISO) de um fornecedor SaaS FinTech B2B em rápido crescimento, abre um pedido urgente do Conselho de Administração. A empresa acabou de obter a certificação ISO/IEC 27001:2022, mas um grande potencial cliente bancário da UE está a colocar perguntas mais exigentes do que as de um questionário de segurança habitual.

Não querem saber apenas se a empresa cifra dados, utiliza MFA ou tem um relatório de testes de intrusão. Querem saber se a plataforma SaaS apoia as suas obrigações DORA, se o fornecedor pode estar no âmbito da NIS2 enquanto serviço de TIC ou dependência de infraestrutura digital, e se a Declaração de Aplicabilidade ISO 27001 consegue justificar cada controlo incluído, cada controlo excluído e cada elemento de evidência.

O Conselho de Administração coloca a pergunta que cada CISO, gestor de conformidade e fundador de SaaS ouve cada vez mais:

A nossa SoA ISO 27001 consegue demonstrar preparação para NIS2 e DORA?

Elena sabe que a resposta errada seria lançar três programas de conformidade separados: um para ISO 27001, um para NIS2 e um para DORA. Isso criaria evidência duplicada, proprietários de controlos em conflito e uma corrida permanente antes de cada avaliação de cliente. A melhor resposta é utilizar o SGSI existente como sistema operativo da conformidade, tendo a Declaração de Aplicabilidade, ou SoA, como documento-mestre de rastreabilidade.

A SoA não é apenas uma folha de cálculo para certificação ISO. Num ambiente de cibersegurança e resiliência operacional da UE, é nela que a organização demonstra por que existem controlos, por que as exclusões são defensáveis, quem é responsável por cada controlo, que evidência suporta a implementação e de que forma o conjunto de controlos responde à NIS2, à DORA, ao GDPR, aos contratos com clientes e ao tratamento interno de riscos.

A Política de Segurança da Informação empresarial da Clarysec Política de Segurança da Informação estabelece:

O SGSI deve incluir limites de âmbito definidos, uma metodologia de avaliação de riscos, objetivos mensuráveis e controlos documentados justificados na Declaração de Aplicabilidade (SoA).

Esse requisito, da cláusula 6.1.2 da Política de Segurança da Informação, é a base de uma abordagem preparada para auditoria. A SoA deve tornar-se a ponte entre obrigações, riscos, controlos, evidência e decisões de gestão.

Porque NIS2 e DORA mudaram o significado de “aplicável”

Uma SoA ISO/IEC 27001:2022 tradicional começa muitas vezes com uma pergunta simples: “Que controlos do Anexo A se aplicam ao nosso plano de tratamento de riscos?” Isso continua correto, mas já não é suficiente para fornecedores SaaS, cloud, serviços geridos, fintech, tecnologia financeira e prestadores críticos da cadeia de fornecimento.

A NIS2 eleva a linha de base da gestão de riscos de cibersegurança para entidades essenciais e importantes na UE. Abrange setores como infraestrutura digital, prestadores de serviços de computação em cloud, prestadores de serviços de centros de dados, redes de distribuição de conteúdos, prestadores de serviços geridos, prestadores de serviços de segurança geridos, banca e infraestruturas dos mercados financeiros. Os Estados-Membros devem identificar entidades essenciais e importantes e prestadores de serviços de registo de nomes de domínio, e muitos fornecedores tecnológicos que antes tratavam a regulamentação de cibersegurança como um problema do cliente estão agora diretamente no âmbito ou expostos por requisitos contratuais em cascata.

O NIS2 Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionais em matéria de análise de riscos, políticas de segurança, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e desenvolvimento seguros, avaliação da eficácia dos controlos, higiene de cibersegurança, formação, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e autenticação, quando adequado. O NIS2 Article 23 acrescenta expectativas de notificação faseada de incidentes, incluindo alerta precoce, notificação, atualizações e relatório final para incidentes significativos.

A DORA, o Regulamento relativo à Resiliência Operacional Digital, aplica-se desde 17 de janeiro de 2025 e foca-se nas entidades financeiras e no respetivo ecossistema de risco das TIC. Abrange a gestão do risco das TIC, a notificação de incidentes relacionados com TIC, a notificação de incidentes operacionais ou de segurança relacionados com pagamentos para determinadas entidades, os testes de resiliência operacional digital, a partilha de informações sobre ameaças cibernéticas, a gestão do risco de terceiros de TIC, os acordos contratuais e a supervisão de prestadores terceiros críticos de serviços de TIC.

Para entidades financeiras que também sejam entidades essenciais ou importantes ao abrigo da NIS2, a DORA funciona como o regime setorial específico para obrigações equivalentes de gestão do risco das TIC e notificação de incidentes. Mas, para fornecedores SaaS, prestadores de serviços cloud, MSPs e prestadores MDR que servem clientes financeiros, a realidade prática é que as expectativas da DORA chegam através de processos de aquisição, contratos, direitos de auditoria, obrigações de suporte a incidentes, planeamento de saída, transparência sobre subcontratantes e evidência de resiliência.

Isso muda a conversa sobre a SoA. A pergunta já não é: “O Anexo A contém este controlo?” A melhor pergunta é:

Conseguimos demonstrar que a seleção de controlos é baseada no risco, considera obrigações, é proporcional, tem proprietário, está implementada, é monitorizada, tem evidência e foi aprovada?

ISO 27001 é o tradutor universal para NIS2 e DORA

A ISO/IEC 27001:2022 é valiosa porque é uma norma de sistema de gestão, não uma checklist limitada. Exige que o SGSI seja integrado nos processos da organização e dimensionado às suas necessidades. Isso torna-a um tradutor universal eficaz para requisitos de conformidade sobrepostos.

As cláusulas 4.1 a 4.4 exigem que a organização compreenda o seu contexto, identifique partes interessadas, determine requisitos relevantes e defina o âmbito do SGSI. Para um fornecedor FinTech SaaS como a empresa de Elena, esses requisitos das partes interessadas podem incluir clientes da UE, clientes financeiros afetados pela DORA, exposição setorial à NIS2, obrigações de responsável pelo tratamento e subcontratante ao abrigo do GDPR, dependências cloud externalizadas, interfaces com fornecedores e expectativas do Conselho de Administração.

As cláusulas 6.1.1 a 6.1.3 exigem planeamento para riscos e oportunidades, um processo repetível de avaliação de riscos de segurança da informação, um processo de tratamento de riscos, comparação com o Anexo A e uma Declaração de Aplicabilidade que identifique controlos incluídos, estado de implementação e justificações de exclusão.

É aqui que a SoA se torna um registo de decisões de controlo. Um controlo pode ser incluído porque trata um risco, satisfaz um requisito legal, cumpre um contrato com cliente, apoia um objetivo de negócio ou representa higiene de segurança de referência. Um controlo só pode ser excluído depois de a organização o ter avaliado conscientemente, considerado irrelevante para o âmbito do SGSI, documentado a justificação e obtido aprovação adequada.

A Política de Gestão de Riscos empresarial da Clarysec Política de Gestão de Riscos estabelece:

Uma Declaração de Aplicabilidade (SoA) deve refletir todas as decisões de tratamento e deve ser atualizada sempre que a cobertura de controlos for modificada.

Este requisito, da cláusula 5.4 da Política de Gestão de Riscos, é crítico para a preparação para NIS2 e DORA. Um novo cliente regulado, uma nova dependência cloud, uma nova obrigação de notificação de incidentes ou um novo risco de concentração em fornecedores podem alterar a aplicabilidade dos controlos.

Comece pelo registo de conformidade, não pela lista de controlos

Uma SoA fraca começa pelo Anexo A e pergunta: “Que controlos já temos?” Uma SoA forte começa pela realidade operacional da organização e pergunta: “Que obrigações, serviços, riscos, dados, fornecedores e clientes o SGSI deve cobrir?”

A ISO/IEC 27005:2022 suporta esta abordagem ao enfatizar os requisitos das partes interessadas, critérios de risco e a necessidade de considerar normas, regras internas, leis, regulamentos, contratos e controlos existentes. Também sublinha que a não aplicabilidade ou o incumprimento devem ser explicados e justificados.

A Política de Cumprimento Legal e Regulamentar para PME da Clarysec Política de Cumprimento Legal e Regulamentar para PME capta o mesmo princípio operacional:

A gestão deve manter um Registo de Conformidade simples e estruturado que enumere:

Esse requisito vem da cláusula 5.1.1 da Política de Cumprimento Legal e Regulamentar para PME. Para uma organização mais pequena, o registo pode ser simples. Para uma empresa, deve ser mais detalhado. A lógica é a mesma: as obrigações devem ser visíveis antes de poderem ser mapeadas.

A Política de Cumprimento Legal e Regulamentar empresarial da Clarysec Política de Cumprimento Legal e Regulamentar é explícita:

Todas as obrigações legais e regulamentares devem ser mapeadas para políticas, controlos e proprietários específicos no Sistema de Gestão de Segurança da Informação (SGSI).

Essa é a cláusula 6.2.1 da Política de Cumprimento Legal e Regulamentar. É a espinha dorsal de governação para utilizar uma Declaração de Aplicabilidade ISO 27001 na preparação para a conformidade com NIS2 e DORA.

Crie critérios de risco que reflitam resiliência, privacidade, fornecedores e regulamentação

Muitas justificações da SoA falham porque o modelo de pontuação de risco é demasiado estreito. Mede probabilidade e impacto técnicos, mas não capta exposição regulatória, criticidade do serviço, dano ao cliente, dependência de fornecedores, impacto na privacidade ou disrupção operacional sistémica.

A NIS2 não trata apenas de confidencialidade. Foca-se na prevenção e minimização do impacto dos incidentes nos serviços e nos destinatários dos serviços. A DORA define funções críticas ou importantes com base na possibilidade de uma disrupção prejudicar materialmente o desempenho financeiro, a continuidade do serviço ou a conformidade regulamentar. O GDPR acrescenta responsabilização, integridade, confidencialidade, preparação para violações e dano aos titulares dos dados.

A Política de Gestão de Riscos para PME da Clarysec Política de Gestão de Riscos para PME fornece um mínimo prático:

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

Esta é a cláusula 5.1.2 da Política de Gestão de Riscos para PME. Para preparação para NIS2 e DORA, a Clarysec expande esse mínimo para campos como fonte da obrigação, serviço afetado, categoria de dados, dependência de fornecedores, proprietário de negócio, impacto regulatório, risco residual, estado do tratamento e fonte de evidência.

Repare na linguagem. Uma justificação forte não diz apenas “implementado”. Explica por que razão o controlo é aplicável no contexto de negócio, regulamentar e de risco da organização.

Mapeie domínios NIS2 e DORA para controlos ISO 27001:2022

Depois de estabelecidos o registo de conformidade e os critérios de risco, o trabalho prático consiste em mapear domínios regulamentares para controlos do Anexo A. Este mapeamento não comprova a conformidade por si só, mas fornece a auditores e clientes um índice claro para testar evidência.

Para Elena, este mapeamento mudou a conversa com o Conselho de Administração. Em vez de apresentar NIS2 e DORA como projetos separados, pôde mostrar a sobreposição: governação, gestão de riscos, incidentes, continuidade, fornecedores, testes, controlo de acesso e criptografia.

Os três controlos ISO de que depende toda a SoA NIS2 e DORA

Em Zenith Controls: The Cross-Compliance Guide Zenith Controls, a Clarysec trata três controlos ISO/IEC 27002:2022 como centrais para a governação da SoA preparada para auditoria em NIS2 e DORA. São controlos ISO, enriquecidos com atributos de conformidade cruzada no guia Zenith Controls.

Estes controlos não são isolados. Ligam-se diretamente aos controlos de relacionamento com fornecedores A.5.19 a A.5.23, aos controlos de gestão de incidentes A.5.24 a A.5.28, aos controlos de continuidade A.5.29 e A.5.30, ao controlo de privacidade A.5.34, à gestão de vulnerabilidades A.8.8, à gestão da configuração A.8.9, à cópia de segurança da informação A.8.13, ao registo de logs A.8.15, às atividades de monitorização A.8.16, à criptografia A.8.24, aos controlos de desenvolvimento seguro A.8.25 a A.8.29 e à gestão de alterações A.8.32.

O valor do Zenith Controls é ajudar as equipas a evitar tratar a SoA como um artefacto de uma única norma. O controlo 5.31 suporta o mapeamento legal e contratual. O controlo 5.35 suporta auditoria interna, revisão independente e garantia pela gestão. O controlo 5.36 suporta o cumprimento operacional de políticas, procedimentos, normas e requisitos de controlo.

Utilize o Zenith Blueprint para construir, testar e defender a SoA

Em Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, a Clarysec coloca a construção da SoA na fase de Gestão de Riscos, etapa 13: planeamento do tratamento de riscos e Declaração de Aplicabilidade. O Blueprint orienta as organizações a utilizar a folha SoA no modelo “Risk Register and SoA Builder.xlsx”, decidir se cada um dos 93 controlos do Anexo A é aplicável e basear a decisão no tratamento de riscos, requisitos legais e contratuais, relevância para o âmbito e contexto organizacional.

O Blueprint estabelece:

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

Essa frase capta o modelo operacional. A SoA liga obrigações, riscos, políticas, controlos, evidência e conclusões de auditoria.

O Zenith Blueprint também orienta as equipas a referenciar regulamentos nas notas da SoA quando adequado. Se um controlo for implementado para GDPR, NIS2 ou DORA, isso deve aparecer no registo de riscos ou nas notas da SoA. Mais tarde, na etapa 24, o Blueprint instrui as organizações a atualizar a SoA após a implementação e a verificá-la face ao plano de tratamento de riscos. Na etapa 30, preparação para a certificação, revisão final e auditoria simulada, o Blueprint orienta as equipas a confirmar que cada controlo aplicável do Anexo A tem evidência, como uma política, procedimento, relatório, plano ou registo de implementação.

Essa sequência transforma a SoA num instrumento vivo de conformidade:

1. A etapa 13 constrói-a a partir do tratamento de riscos e das obrigações.
2. A etapa 24 testa-a contra a realidade da implementação.
3. A etapa 30 defende-a através da revisão final da evidência e de uma auditoria simulada.

Como escrever justificações de inclusão que os auditores consigam seguir

Um controlo deve ser incluído quando existe pelo menos um fator defensável: tratamento de riscos, requisito legal, requisito contratual, relevância para o âmbito, higiene de segurança de referência, expectativa de garantia do cliente ou objetivo de resiliência aprovado pela gestão.

Uma fórmula útil é:

Aplicável porque [risco ou obrigação] afeta [serviço, ativo, dado ou processo], e este controlo fornece [resultado preventivo, de deteção, corretivo ou de resiliência], evidenciado por [política, registo, teste, relatório ou saída de sistema].

Para um fornecedor fintech SaaS, uma linha da SoA poderia ter este aspeto:

Isto está preparado para auditoria porque liga o controlo a contexto, risco, obrigação, implementação, propriedade e evidência.

Como justificar exclusões sem criar exposição em auditoria

Exclusões não são falhas. Exclusões mal justificadas são falhas.

A ISO/IEC 27001:2022 exige que a SoA justifique controlos excluídos do Anexo A. A ISO/IEC 27005:2022 reforça que a não aplicabilidade deve ser explicada e justificada. A Política de Segurança da Informação empresarial da Clarysec estabelece:

A linha de base pode ser adaptada; contudo, as exclusões devem ser documentadas com aprovação formal e justificação na SoA.

Esta é a cláusula 7.2.2 da Política de Segurança da Informação.

A Política de Segurança da Informação para PME da Clarysec Política de Segurança da Informação para PME estabelece:

Qualquer desvio a esta política deve ser documentado, explicando claramente por que o desvio é necessário, que medidas de proteção alternativas estão em vigor e a data definida para reavaliação.

Esse requisito vem da cláusula 7.2.1 da Política de Segurança da Informação para PME.

Para NIS2 e DORA, as exclusões exigem cuidado adicional. Uma empresa SaaS raramente deve excluir registo de logs, monitorização, cópias de segurança, gestão de incidentes, controlo de acesso, segurança de fornecedores ou gestão de vulnerabilidades. Mesmo quando um controlo não está ligado a um risco específico, ainda pode ser necessário como segurança de referência, garantia ao cliente, expectativa contratual ou obrigação legal.

A Política de Gestão de Riscos para PME da Clarysec também recorda às equipas como deve ser tratado o risco aceite:

Aceitar: Justificar por que não é necessária ação adicional e registar o risco residual.

Essa cláusula, 6.1.1 da Política de Gestão de Riscos para PME, traduz exatamente a mentalidade necessária para exclusões e decisões de risco residual.

Notificação de incidentes: demonstre o fluxo de trabalho, não a existência da política

O NIS2 Article 23 exige notificação faseada de incidentes significativos, incluindo alerta precoce no prazo de 24 horas após a tomada de conhecimento, notificação no prazo de 72 horas, atualizações quando solicitadas e relatório final no prazo de um mês após a notificação de 72 horas. A DORA exige que as entidades financeiras detetem, giram, classifiquem, escalem, comuniquem e reportem incidentes importantes relacionados com TIC, informem clientes afetados quando exigido, realizem análise de causa raiz e melhorem os controlos.

Um fornecedor SaaS pode nem sempre reportar diretamente a uma autoridade DORA, mas pode ter de apoiar os prazos de reporte dos seus clientes financeiros. Isso torna os controlos de incidentes altamente relevantes na SoA.

Uma SoA fraca diz: “Existe política de resposta a incidentes.”

Uma SoA forte diz: “Aplicável porque a organização deve detetar, avaliar, classificar, escalar, comunicar, preservar evidência, suportar prazos de reporte regulamentar, notificar clientes afetados quando contratualmente exigido e aprender com incidentes que afetem serviços, dados ou clientes regulados.”

A evidência deve incluir:

• Plano de resposta a incidentes e matriz de escalonamento.
• Critérios de classificação de severidade.
• Fluxo de notificação a clientes.
• Árvore de decisão para notificação regulamentar, quando aplicável.
• Tickets e cronologias de incidentes.
• Logs e alertas de monitorização.
• Registos de exercícios de simulação de incidentes.
• Revisão pós-incidente e ações corretivas.
• Procedimentos de preservação de evidência.

A Política de Auditoria e Monitorização da Conformidade empresarial da Clarysec Política de Auditoria e Monitorização da Conformidade explica por que isto é importante:

Gerar evidência defensável e um trilho de auditoria em suporte de pedidos de esclarecimento regulamentares, processos judiciais ou pedidos de garantia por parte de clientes.

Esse objetivo vem da cláusula 3.4 da Política de Auditoria e Monitorização da Conformidade.

Para organizações mais pequenas, a retenção de evidência também deve ser explícita. A Política de Auditoria e Monitorização da Conformidade para PME da Clarysec Política de Auditoria e Monitorização da Conformidade para PME estabelece:

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

Essa é a cláusula 6.2.4 da Política de Auditoria e Monitorização da Conformidade para PME.

Uma SoA, várias conversas de auditoria

A melhor SoA não duplica referenciais. Cria uma narrativa de controlos rastreável que diferentes auditores conseguem compreender.

Um auditor ISO 27001 começa normalmente pela lógica das cláusulas: âmbito, partes interessadas, avaliação de riscos, tratamento de riscos, SoA, objetivos, auditoria interna, revisão pela gestão e melhoria. Um revisor orientado para NIS2 foca-se em proporcionalidade, responsabilização da gestão, formação, cadeia de fornecimento, prazos de incidentes e impacto no serviço. Um avaliador de cliente orientado para DORA foca-se em risco de TIC, funções críticas ou importantes, incidentes importantes de TIC, testes de resiliência, cláusulas contratuais, direitos de auditoria, planos de saída, subcontratação e risco de concentração. Um revisor de privacidade foca-se na responsabilização GDPR e na preparação para violações. Um auditor ao estilo COBIT 2019 ou ISACA testa governação, métricas, propriedade, garantia e ação corretiva.

É por isso que a SoA não pode ser mantida apenas pela equipa de segurança. Exige propriedade por parte de jurídico, privacidade, compras, engenharia, operações, recursos humanos e direção executiva.

Falhas comuns da SoA em projetos de preparação para NIS2 e DORA

A Clarysec encontra repetidamente os mesmos problemas em projetos de preparação:

1. A SoA assinala controlos como aplicáveis, mas não regista risco, obrigação ou razão de negócio.
2. NIS2 e DORA são mencionadas em políticas, mas não são mapeadas para controlos, proprietários ou evidência.
3. Os controlos de fornecedores estão marcados como implementados, mas não existe registo centralizado de fornecedores, classificação de criticidade, revisão contratual ou plano de saída.
4. Existem controlos de incidentes, mas o processo não suporta fluxos de reporte de 24 horas, 72 horas, cliente ou relatório final.
5. A aprovação da gestão está implícita, mas não existe registo de aceitação do risco, aprovação da SoA ou decisão sobre risco residual.
6. As exclusões são copiadas de um modelo e não correspondem ao modelo operacional real cloud, remoto, SaaS ou fintech.
7. Existe evidência em várias ferramentas, mas nenhum trilho de auditoria liga a evidência à SoA.
8. O tratamento de dados pessoais ao abrigo do GDPR não está ligado a controlos de segurança, resposta a violações, contratos com fornecedores ou retenção.
9. A auditoria interna verifica documentos, mas não testa se a SoA reflete a implementação real.
10. A SoA só é atualizada antes da certificação, não após novos clientes, fornecedores, incidentes, constatações de auditoria ou alterações regulamentares.

Estas não são questões documentais. São questões de governação.

Lista de verificação prática para uma SoA ISO 27001 preparada para auditoria

Utilize esta lista de verificação antes de uma auditoria de certificação ISO 27001, revisão de preparação para NIS2, avaliação DORA por cliente, reunião do Conselho de Administração ou processo de diligência prévia de investidores.

Transforme a SoA numa ponte defensável de conformidade

A apresentação de Elena ao Conselho de Administração foi bem-sucedida porque ela não apresentou três projetos de conformidade desconexos. Apresentou um modelo operacional controlado e baseado em evidência, construído sobre a ISO/IEC 27001:2022, com a SoA como ponte entre regulamentação, risco, implementação de controlos, evidência e supervisão pela gestão.

NIS2 e DORA não tornam a ISO 27001 obsoleta. Tornam uma Declaração de Aplicabilidade ISO 27001 bem construída mais valiosa. A SoA pode tornar-se o local único onde a sua organização explica por que existem controlos, por que as exclusões são defensáveis, como a evidência é retida, como os fornecedores são governados, como os incidentes são escalados e como a gestão sabe que o SGSI está a funcionar.

A sua ação imediata é simples:

1. Abra a sua SoA atual.
2. Escolha cinco controlos marcados como aplicáveis e pergunte: “Que risco, obrigação ou contrato justifica isto?”
3. Escolha cinco exclusões e pergunte: “Isto continuaria a fazer sentido para um auditor NIS2, DORA, GDPR ou ISO/IEC 27001:2022?”
4. Verifique se cada controlo aplicável tem evidência atual.
5. Confirme que a gestão aprovou os riscos residuais e as decisões da SoA.
6. Atualize o registo de conformidade, o registo de riscos e a SoA sempre que serviços, fornecedores, clientes, regulamentos ou incidentes mudarem.

A Clarysec ajuda as organizações a fazer isto através do Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, conjuntos de políticas empresariais e para PME, ferramentas de registo de riscos, modelos de SoA, preparação para auditoria e mapeamento de conformidade cruzada para NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 e garantia a clientes.

Se a sua SoA não consegue responder porquê, quem é o responsável, que evidência o demonstra e que obrigação suporta, ainda não está preparada. Use a Clarysec para a transformar numa ponte de conformidade preparada para auditoria antes de um regulador, auditor ou cliente fazer primeiro as mesmas perguntas.