Âmbito do SGSI ISO 27001 para NIS2, DORA e GDPR

Maria, Diretora de Segurança da Informação (CISO) numa fintech europeia em rápido crescimento, pensava que a auditoria de acompanhamento ISO 27001 estava sob controlo.

O certificado era recente. A Declaração de Aplicabilidade parecia madura. A declaração de âmbito abrangia “o Sistema de Gestão de Segurança da Informação corporativo que suporta as operações da plataforma SaaS”. O ambiente de nuvem de produção estava documentado. O procedimento de resposta a incidentes existia. O Registo de Riscos tinha responsáveis, datas e classificações de risco residual.

Então o auditor fez uma pergunta simples:

“Que partes desta plataforma SaaS também estão no âmbito do registo NIS2, que serviços externalizados suportam funções críticas ou importantes DORA para os vossos clientes financeiros, e onde são exatamente tratados os dados pessoais abrangidos pelo GDPR?”

A sala ficou em silêncio.

O Jurídico abriu uma folha de cálculo de obrigações regulamentares. O Produto abriu um diagrama de arquitetura. O Encarregado da Proteção de Dados (EPD) abriu os registos das atividades de tratamento de dados. Compras abriu a lista de fornecedores. Operações abriu o Plano de Recuperação de Desastres. Nada coincidia.

O âmbito do SGSI dizia “plataforma SaaS”. A avaliação NIS2 identificava serviços de infraestrutura digital em vários Estados-Membros. Os contratos de clientes descreviam a plataforma como suporte a operações financeiras reguladas. Os registos GDPR incluíam dados de identidade, telemetria, endereços IP, metadados de pagamentos, pedidos de suporte e análise de dados subcontratada. O Plano de Recuperação de Desastres cobria a produção, mas não a plataforma de suporte ao cliente utilizada para comunicações de violações de dados. A due diligence de fornecedores cobria o prestador de alojamento, mas não o serviço gerido de deteção ligado aos logs de produção.

Este é o problema da definição do âmbito do SGSI em 2026. A certificação ISO 27001 continua a ter valor, mas um “âmbito mínimo viável” e estreito pode tornar-se uma responsabilidade quando autoridades de supervisão, clientes e auditores esperam que o mesmo sistema de gestão explique serviços essenciais NIS2, funções críticas ou importantes DORA e limites de tratamento GDPR.

Para ISO/IEC 27001:2022, NIS2, DORA e GDPR, um âmbito frágil não é uma deficiência administrativa. É a primeira peça de dominó. Se o âmbito estiver errado, a avaliação de riscos fica incompleta, a SoA torna-se enganadora, os controlos de fornecedores deixam de cobrir prestadores críticos, os prazos de notificação de incidentes tornam-se incertos e a responsabilização em matéria de privacidade fragmenta-se entre equipas.

Porque é que o âmbito do SGSI ISO 27001 é agora uma fronteira regulamentar

A ISO/IEC 27001:2022 Cláusula 4.3 exige que a organização determine os limites e a aplicabilidade do SGSI, considerando questões internas e externas, requisitos das partes interessadas, bem como interfaces e dependências com outras organizações ISO/IEC 27001:2022.

Esta formulação tem mais peso em 2026 do que teve em ciclos de certificação anteriores. NIS2, DORA, GDPR, externalização para nuvem, contratos de clientes, serviços tecnológicos de grupo e prestadores de serviços geridos não são notas laterais. São entradas para a fronteira do SGSI.

A NIS2 aumenta a exigência de governação para entidades essenciais e importantes. Exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação. A NIS2 Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e desenvolvimento seguros, avaliação de eficácia, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e autenticação multifator quando adequado.

A DORA altera a conversa sobre o âmbito para as entidades financeiras. Aplica-se a partir de 17 de janeiro de 2025 e estabelece requisitos uniformes para gestão do risco das TIC, comunicação de incidentes relacionados com TIC, testes de resiliência operacional digital, partilha de informação e gestão do risco de terceiros TIC. A DORA Article 6 exige um quadro documentado de gestão do risco das TIC. A DORA Article 8 exige a identificação, classificação e documentação das funções de negócio suportadas por TIC, dos ativos de informação e dos ativos de TIC, incluindo dependências. A DORA Article 28 exige a gestão do risco de terceiros TIC.

O GDPR acrescenta o eixo dos dados pessoais. Aplica-se ao tratamento automatizado ou estruturado de dados pessoais, incluindo tratamento por estabelecimentos na UE e por determinados responsáveis pelo tratamento ou subcontratantes fora da UE que ofereçam bens ou serviços a pessoas na União ou monitorizem o seu comportamento. O GDPR Article 30 exige registos das atividades de tratamento de dados, o Article 32 exige segurança do tratamento, e o Article 33 estabelece expectativas de notificação de violações.

Um âmbito defensável do SGSI não é, portanto, escrito em torno de departamentos. É escrito em torno de serviços regulados, funções críticas ou importantes, tratamento de dados pessoais, ativos de suporte e dependências de terceiros.

O erro: tratar ISO 27001, NIS2, DORA e GDPR como programas separados

Surge um padrão comum em muitas organizações:

• Segurança redige o âmbito ISO 27001.
• Jurídico avalia a aplicabilidade da NIS2.
• Risco ou Conformidade gere as obrigações DORA.
• Privacidade mantém os registos GDPR das atividades de tratamento de dados.
• Compras é responsável pela lista de fornecedores.
• Operações é responsável pela continuidade de negócio e pela recuperação de desastres.

Cada equipa pode estar a executar trabalho razoável. O problema é que a realidade regulada atravessa todas estas áreas.

Um serviço de identidade de clientes alojado em nuvem pode suportar simultaneamente a prestação de serviços NIS2, operações de clientes reguladas pela DORA e tratamento de dados pessoais GDPR. Um prestador gerido de deteção pode ser um fornecedor de segurança, uma dependência de resposta a incidentes, um subcontratante ou subcontratante subsequente de dados de logs e uma entrada-chave para decisões de notificação regulamentar. Uma plataforma de suporte pode ser considerada “não produção” e, ainda assim, tratar comunicações de violações de dados pessoais e pedidos de evidência de clientes.

O SGSI é o melhor local para integrar estas obrigações porque a ISO 27001 impõe uma pergunta disciplinada: o que está dentro da fronteira, o que está fora e porquê?

O Zenith Blueprint: An Auditor’s 30-Step Roadmap da Clarysec Zenith Blueprint aborda este tema na fase ISMS Foundation & Leadership, Step 2: Stakeholder Needs and ISMS Scope:

“Com o contexto compreendido e os requisitos das partes interessadas identificados, a Cláusula 4.3 exige que determine os limites e a aplicabilidade do SGSI para estabelecer o respetivo âmbito. O âmbito do SGSI é uma definição crucial que estabelece o que está incluído no seu programa de gestão de segurança (e o que não está).”

O Zenith Blueprint também destaca um ponto que muitas declarações de âmbito ainda ignoram:

“Se externalizar a sua infraestrutura de TI para um prestador de serviços de nuvem, isso não a exclui do âmbito; pelo contrário, deve incluir a gestão dessa relação e os ativos em nuvem como parte do âmbito.”

A externalização transfere a execução. Não elimina a responsabilização.

O modelo de quatro fronteiras para o âmbito ISO 27001 em 2026

Para organizações afetadas por NIS2, DORA e GDPR, a Clarysec recomenda definir o âmbito do SGSI ISO 27001 através de quatro fronteiras interligadas.

Uma declaração de âmbito frágil diz apenas “a plataforma SaaS”. Uma declaração mais robusta indica que serviços de negócio, sistemas, ambientes, localizações, atividades de tratamento de dados, grupos de pessoal, relações com fornecedores e processos de gestão estão incluídos.

Uma versão mais defensável poderia dizer:

“O SGSI abrange a governação, a gestão de riscos, a operação e a melhoria contínua da segurança da informação da plataforma SaaS de análise de pagamentos da empresa na UE, incluindo ambientes de nuvem de produção e não produção, serviços de identidade de clientes, interfaces administrativas, operações de suporte, plataformas de logging e monitorização, resposta a incidentes, continuidade de negócio, gestão de fornecedores e todas as atividades de tratamento de dados pessoais que suportam o serviço. O SGSI inclui a gestão do alojamento em nuvem externalizado, da deteção gerida e das ferramentas de suporte ao cliente utilizadas para prestação do serviço, resiliência, monitorização de segurança ou comunicações relacionadas com GDPR.”

Este âmbito não é apenas mais longo. É mais auditável porque liga serviços, ativos, tratamento e dependências.

Como as políticas da Clarysec transformam o âmbito em linguagem de governação

O âmbito não deve existir apenas num documento autónomo. Deve alinhar-se com a Política de Segurança da Informação, conformidade legal e regulamentar, gestão de riscos, privacidade, governação de fornecedores, critérios de auditoria e planeamento de continuidade.

A Política de Segurança da Informação Enterprise Política de Segurança da Informação evita ambiguidades em torno das exclusões:

“Quaisquer exclusões ou limitações a este âmbito devem ser documentadas na Declaração do Âmbito do SGSI e justificadas com aprovação formal da Alta Direção.”

Esta cláusula é relevante quando uma unidade de negócio argumenta que o suporte ao cliente está fora da plataforma, embora os agentes de suporte acedam a identificadores de clientes e tratem comunicações de violações de dados. A exclusão só é possível se for documentada, justificada e aprovada.

A Política de Conformidade Legal e Regulamentar Enterprise Política de Conformidade Legal e Regulamentar torna operacional o mapeamento jurídico:

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

Esta é a ponte entre a aplicabilidade jurídica e a Declaração de Aplicabilidade. A NIS2 Article 21 não deve permanecer num memorando jurídico. As obrigações DORA relativas a terceiros TIC não devem permanecer apenas em orientações de compras. As obrigações GDPR Article 30 e Article 32 não devem estar apenas no registo de privacidade. Precisam de responsáveis, controlos e evidência mapeados.

A Política de Gestão de Riscos Enterprise Política de Gestão de Riscos alarga o âmbito a terceiros:

“Esta política aplica-se a todas as unidades organizacionais, processos de negócio, sistemas, pessoal e relações com terceiros envolvidos no tratamento, desenvolvimento, armazenamento ou gestão de ativos de informação.”

Esta formulação está alinhada com a segurança da cadeia de fornecimento NIS2, o risco de terceiros TIC DORA e a responsabilização do responsável pelo tratamento ou do subcontratante ao abrigo do GDPR.

A Política de Proteção de Dados e Privacidade Enterprise Política de Proteção de Dados e Privacidade ancora o âmbito de privacidade ao tratamento:

“Esta política aplica-se a todas as unidades organizacionais, pessoal e sistemas envolvidos no tratamento de informações pessoais identificáveis (PII), incluindo:”

O princípio é decisivo. Se um sistema trata PII, não pode estar invisível para o SGSI por ser “apenas suporte”, “não produção” ou “propriedade do marketing”.

A Política de Continuidade de Negócio e Recuperação de Desastres Enterprise Política de Continuidade de Negócio e Recuperação de Desastres liga o âmbito aos resultados da BIA:

“Esta política aplica-se a todas as unidades organizacionais, sistemas de informação, processos de negócio, pessoal e serviços de terceiros classificados como críticos ou essenciais com base nos resultados da análise de impacto no negócio (BIA).”

Esta cláusula alinha-se naturalmente com funções críticas ou importantes DORA e continuidade de serviços NIS2.

Para organizações mais pequenas, as políticas PME da Clarysec mantêm a redação concisa preservando a mesma lógica. A Política de Auditoria e Monitorização da Conformidade PME Política de Auditoria e Monitorização da Conformidade PME define a cobertura da auditoria como:

“Todos os controlos e sistemas no âmbito do Sistema de Gestão de Segurança da Informação (SGSI)”

A Política de Proteção de Dados e Privacidade PME Política de Proteção de Dados e Privacidade PME define o âmbito de privacidade como:

“Qualquer sistema, aplicação ou localização em que dados pessoais sejam armazenados ou transmitidos”

A Política de Gestão de Riscos PME Política de Gestão de Riscos PME mantém os serviços externalizados visíveis:

“Toda a informação, serviços e ativos geridos internamente ou através de terceiros”

Cláusulas curtas como estas são poderosas porque impedem que uma fronteira de certificação exclua dados regulados, serviços de nuvem ou ativos geridos por fornecedores.

O inventário de ativos é onde o âmbito se torna real

Uma declaração de âmbito só é credível se puder ser rastreada a ativos, responsáveis, fornecedores, fluxos de dados e evidência.

O Zenith Blueprint, na fase de Gestão de Riscos, Step 9: Identifying Assets, Threats, and Vulnerabilities, instrui as organizações a listar os ativos no âmbito do SGSI e a registar responsável, localização e classificação. Dá um exemplo prático:

“Base de Dados de Clientes – propriedade do Departamento de TI – alojada na AWS – contém dados pessoais e financeiros (sensibilidade elevada).”

O mesmo passo acrescenta um lembrete de âmbito diretamente relevante para NIS2 e GDPR:

“Assegure que os ativos de dados pessoais são assinalados (para relevância GDPR) e que os ativos de serviços críticos são identificados (para potencial aplicabilidade NIS2 se operar num setor regulado).”

O Zenith Controls: The Cross-Compliance Guide da Clarysec Zenith Controls trata o controlo ISO/IEC 27002:2022 5.9, Inventário de informação e outros ativos associados, como um controlo fundamental de conformidade transversal. Os seus atributos classificam o controlo como preventivo, suportando confidencialidade, integridade e disponibilidade, alinhado com o conceito de cibersegurança Identificar, a capacidade operacional de gestão de ativos e os domínios de governação, ecossistema e proteção.

O Zenith Controls explica de forma clara a relevância para GDPR e NIS2:

“Sem um inventário de ativos exato e atualizado, as organizações não conseguem avaliar nem implementar proteções adequadas.”

Para a NIS2, o inventário de ativos suporta a identificação de sistemas e componentes críticos que sustentam serviços essenciais ou importantes. Para a DORA, a DORA Article 8 torna a identificação de ativos de TIC e ativos de informação central para a resiliência operacional. Para o GDPR, o inventário de ativos suporta o mapeamento de fluxos de dados, a qualidade do RoPA e a resposta a violações.

As normas ISO de suporte reforçam a mesma lógica. A ISO/IEC 27005:2024 reforça a identificação de ativos na avaliação de riscos de segurança da informação. A ISO 22301:2019 apoia a identificação dos recursos necessários para a continuidade de negócio. A ISO/IEC 19770-1:2017 apoia a maturidade da gestão de ativos de TI. A ISO/IEC 27017:2015 e a ISO/IEC 27018:2019 suportam controlos específicos de nuvem e a proteção de PII em nuvens públicas. A ISO/IEC 27701:2019 estende a gestão da informação de privacidade. A ISO/IEC 29100:2011 contribui com princípios de privacidade como transparência, minimização e salvaguardas de segurança.

Um exercício prático de definição do âmbito para equipas SaaS e fintech

Comece por um serviço regulado, não pela empresa inteira. Por exemplo: “SaaS de análise de pagamentos na UE para instituições financeiras”.

Em seguida, construa um mapa serviço-ativo-tratamento.

Uma amostra de ativos mais detalhada poderia ser assim.

Em seguida, utilize o Zenith Blueprint Step 13: Risk Treatment Planning and Statement of Applicability. O guia instrui os utilizadores a construir a SoA utilizando o modelo que lista todos os controlos do Anexo A e a decidir a aplicabilidade com base no tratamento de riscos, requisitos legais ou contratuais, relevância para o âmbito e contexto organizacional. Indica:

“Para cada controlo (linha) na folha da SoA, decida se é Aplicável ao seu SGSI.”

Para o exemplo acima, a SoA deve considerar controlos de segurança de fornecedores, serviços de nuvem, gestão de incidentes, continuidade, requisitos legais e regulamentares, privacidade, gestão de vulnerabilidades, cópias de segurança, logging, monitorização, criptografia, desenvolvimento seguro, testes de segurança e gestão de alterações.

Um fluxo de trabalho prático é:

1. Criar um separador “Mapeamento do Âmbito do SGSI” no Registo de Riscos e no SoA Builder.
2. Adicionar uma linha por serviço regulado ou linha de produto.
3. Ligar cada serviço a ativos, tipos de dados, fornecedores, localizações e responsáveis de negócio.
4. Assinalar a relevância NIS2, a relevância DORA e a relevância de tratamento GDPR.
5. Adicionar cenários de risco para indisponibilidade do serviço, violação de dados pessoais, falha de fornecedor, configuração incorreta da nuvem, vulnerabilidade crítica e falha de reporte de incidentes.
6. Selecionar controlos da SoA com base nesses riscos e obrigações.
7. Documentar exclusões, controlos compensatórios e aceitação do risco.
8. Obter aprovação da Alta Direção para os limites e exclusões finais.
9. Integrar a fronteira final na auditoria interna, na revisão pela gestão e na monitorização de fornecedores.

O resultado não é apenas uma declaração de âmbito melhor. É uma cadeia defensável desde o serviço regulado até ao ativo, fornecedor, dado, controlo, responsável e evidência.

Mapeamento de conformidade transversal: um âmbito, muitas obrigações

Um SGSI ISO 27001 bem definido torna-se a camada operacional onde as expectativas de NIS2, DORA, GDPR, NIST CSF e COBIT podem ser conciliadas.

Para o controlo ISO/IEC 27002:2022 5.31, Requisitos legais, estatutários, regulamentares e contratuais, o Zenith Controls liga obrigações de conformidade a privacidade, proteção de PII, retenção de registos, revisão independente e cumprimento de políticas internas. Mapeia-se naturalmente para responsabilização GDPR, conformidade da cadeia de fornecimento NIS2, gestão e conformidade do risco das TIC DORA, governação NIST CSF e monitorização de conformidade externa COBIT 2019.

Para o controlo ISO/IEC 27002:2022 5.34, Privacidade e proteção de PII, o Zenith Controls liga a privacidade ao inventário de ativos, serviços de nuvem, classificação, transferência de informação, controlo de acesso, gestão de identidades e revisões de alterações de projeto. O seu mapeamento GDPR cobre segurança do tratamento e proteção de dados desde a conceção. O seu mapeamento DORA suporta integridade, segurança e confidencialidade dos dados, incluindo dados pessoais tratados em serviços TIC.

O princípio é simples: não crie quatro programas de conformidade desligados. Crie um SGSI com âmbito definido que consiga explicar como as obrigações são satisfeitas, evidenciadas e auditadas.

Âmbito da comunicação de incidentes: onde as fronteiras afetam os relógios regulamentares

Um âmbito incorreto torna-se dolorosamente visível durante incidentes.

A NIS2 Article 23 exige comunicação faseada de incidentes significativos, incluindo um alerta precoce no prazo de 24 horas, uma notificação de incidente no prazo de 72 horas, relatórios intermédios quando solicitados e um relatório final no prazo de um mês. A comunicação aos destinatários afetados também pode ser exigida.

A DORA exige que as entidades financeiras detetem, giram, classifiquem e comuniquem incidentes graves relacionados com TIC utilizando critérios como clientes ou contrapartes afetados, duração, tempo de indisponibilidade, dispersão geográfica, perdas de dados, criticidade dos serviços afetados e impacto económico. Os clientes devem ser informados sem demora indevida quando um incidente grave de TIC afetar os seus interesses financeiros.

A notificação de violação de dados pessoais ao abrigo do GDPR depende de a violação resultar em destruição, perda, alteração, divulgação não autorizada ou acesso não autorizado a dados pessoais, de forma acidental ou ilícita.

Se a plataforma de suporte, o ambiente de logs, o serviço de identidade, o canal de notificação de clientes ou o prestador gerido de deteção ficarem fora do âmbito do SGSI, as equipas de incidentes podem não saber se um evento aciona NIS2, DORA, GDPR, reporte contratual ao cliente ou todos estes regimes. Essa incerteza consome o prazo de notificação.

Um âmbito maduro inclui dependências relevantes para incidentes: ferramentas de deteção, repositórios de logs, repositórios forenses, canais de comunicação com clientes, ferramentas de suporte, ambientes de cópia de segurança, canais de coordenação de incidentes e fornecedores envolvidos na triagem ou recuperação.

Como auditores e supervisores irão testar o âmbito do seu SGSI

Um âmbito forte resiste à amostragem. Um âmbito frágil colapsa quando os auditores comparam documentos com a realidade.

O Zenith Controls fornece expectativas de auditoria úteis para o controlo ISO/IEC 27002:2022 5.9. Auditores ao estilo ISO/IEC 19011 solicitam o inventário cedo para definir o âmbito de outras avaliações e realizar verificações por amostragem de ativos físicos, software e nuvem. Auditores ao estilo ISO/IEC 27007 perguntam como e quando o inventário é atualizado, procurando ligações à aquisição, gestão de alterações e descomissionamento. Auditores ao estilo NIST SP 800-53A verificam se os detalhes do inventário incluem tipo de ativo, responsável, localização, endereço de rede quando aplicável e estado, e se ativos de nuvem, virtuais e móveis estão incluídos.

Para o controlo 5.31, o Zenith Controls assinala que os auditores de certificação esperam um Registo de Conformidade ou uma lista de leis e contratos, referenciados na SoA e nos planos de tratamento de riscos. Auditores COBIT procuram responsáveis de conformidade, avaliações e reporte à Alta Direção. Auditores ISACA ITAF amostram evidência para confirmar que a organização não só conhece as suas obrigações, como assegura ativamente que são cumpridas.

Para o controlo 5.34, os auditores revêem políticas de privacidade, inventários de dados, AIPD, registos de formação, evidência de cifragem, controlos de acesso, amostras de pedidos de titulares de dados, evidência de privacidade desde a conceção e registos de incidentes envolvendo PII. Uma declaração de âmbito que exclua um sistema que trata dados pessoais será rapidamente contestada.

A pergunta do Conselho de Administração: o que não pode ser excluído?

A Alta Direção pergunta frequentemente se uma unidade de negócio, localização, fornecedor ou sistema pode permanecer fora do âmbito do SGSI. Por vezes, a resposta é sim. Mas não se a exclusão impedir a organização de cumprir obrigações legais, regulamentares, contratuais ou de segurança do serviço.

Utilize este teste de exclusão antes de aprovar qualquer limitação da fronteira:

• A unidade, sistema ou fornecedor suporta um serviço regulado pela NIS2?
• Suporta uma função crítica ou importante DORA para a organização ou para os seus clientes regulados?
• Recolhe, armazena, transmite, regista logs, suporta ou elimina dados pessoais?
• Presta monitorização de segurança, identidade, cópia de segurança, resposta a incidentes ou recuperação para um serviço no âmbito?
• Fornece evidência necessária para classificação de incidentes ou notificação regulamentar?
• Um contrato de cliente exige que esteja coberto pelo SGSI?
• O seu comprometimento afetaria confidencialidade, integridade, disponibilidade, conformidade legal ou continuidade do serviço no âmbito declarado?

Se a resposta for sim, a exclusão exige evidência robusta, governação compensatória, aceitação do risco e aprovação formal da Alta Direção. Em muitos casos, não deve ser excluída.

Um âmbito moderno de SGSI ISO 27001 deve incluir:

1. Serviços de negócio e linhas de produto abrangidos.
2. Entidades jurídicas, unidades organizacionais e localizações abrangidas.
3. Segmentos de clientes e jurisdições que determinam obrigações.
4. Funções críticas ou importantes e serviços essenciais baseados na BIA.
5. Ativos de informação, ativos de TIC e ambientes de nuvem.
6. Atividades de tratamento de dados pessoais e repositórios de PII.
7. Processos de desenvolvimento, testes, suporte, monitorização e incidentes.
8. Fornecedores e serviços externalizados que suportam serviços no âmbito.
9. Interfaces e dependências com empresas do grupo ou prestadores externos.
10. Exclusões explícitas com justificação, aceitação do risco e aprovação da Alta Direção.

É assim que o âmbito ISO 27001 se torna uma posição de governação ao nível do Conselho de Administração, e não um atalho de certificação.

Torne o âmbito do seu SGSI preparado para auditoria antes que o auditor o defina por si

O pior momento para descobrir um problema de âmbito é durante a certificação, uma revisão de supervisão, uma due diligence de cliente ou um incidente em curso.

Um certificado estreito pode satisfazer uma caixa de verificação de compras, mas não resistirá a um escrutínio sério se excluir os serviços, funções TIC, fornecedores e tratamento de dados pessoais que geram exposição regulamentar. Em 2026, as organizações que passarão auditorias com confiança serão as que conseguem apresentar um mapa coerente desde o serviço regulado até ao ativo, fornecedor, dado pessoal, controlo, responsável e evidência.

Comece com três ações concretas:

1. Utilize o Zenith Blueprint Zenith Blueprint, fase ISMS Foundation & Leadership, Step 2, para reescrever o âmbito do seu SGSI em torno de serviços, funções, tratamento e dependências.
2. Utilize o Zenith Controls Zenith Controls para mapear inventário de ativos, obrigações legais e proteção de PII face às expectativas de auditoria de ISO 27001, NIS2, DORA, GDPR, NIST e COBIT 2019.
3. Alinhe o âmbito das políticas utilizando a Política de Segurança da Informação Política de Segurança da Informação, a Política de Conformidade Legal e Regulamentar Política de Conformidade Legal e Regulamentar, a Política de Gestão de Riscos Política de Gestão de Riscos, a Política de Proteção de Dados e Privacidade Política de Proteção de Dados e Privacidade e a Política de Continuidade de Negócio e Recuperação de Desastres Política de Continuidade de Negócio e Recuperação de Desastres.

Se o âmbito atual do seu SGSI ainda parece um rótulo de departamento, reconstrua-o como uma fronteira de conformidade. Transfira os toolkits da Clarysec, mapeie um serviço regulado de ponta a ponta e transforme o âmbito ISO 27001 em evidência preparada para auditoria para NIS2, DORA e GDPR.