Classificação de dados para ISO 27001, RGPD da UE, NIS2 e DORA

O momento de auditoria de 2026: “Mostre-me a evidência”

É fevereiro de 2026, e a reunião trimestral do Conselho de Administração de uma empresa fintech SaaS em rápido crescimento não está a correr tão bem como o CISO esperava.

A empresa obteve recentemente a certificação ISO/IEC 27001:2022. Tem autenticação multifator (MFA), proteção de endpoints, análises de vulnerabilidades, revisões de acessos, procedimentos de resposta a incidentes e um relatório de preparação para a DORA bem estruturado. Então, o Diretor Executivo faz a pergunta que muda a dinâmica da sala.

“O nosso investidor principal está a perguntar como conseguimos provar que os dados financeiros dos clientes são protegidos de forma consistente na AWS, no Azure, na nossa plataforma SaaS de suporte e no armazém analítico. Se um auditor retirar um ficheiro do armazenamento de objetos e outro de uma pasta de colaboração, como sabemos que são regidos pelas mesmas regras?”

O CISO abre o registo de ativos. A lista inclui bases de dados, contas de nuvem, aplicações, plataformas SaaS e localizações de armazenamento. Mas o campo de classificação está incompleto. Algumas pastas estão nomeadas por departamento, não por sensibilidade. Exportações de clientes estão lado a lado com ficheiros de reporte interno. Algumas folhas de cálculo de suporte contêm identificadores de clientes, referências de pagamento e notas de caso, mas estão rotuladas como “Interno”. Existem regras de DLP, mas só disparam perante padrões óbvios. A política de nuvem indica que os dados pessoais da UE devem permanecer em regiões aprovadas, mas a equipa não consegue demonstrar que as regras de residência dos dados são determinadas por metadados de classificação.

Depois, o gestor de conformidade acrescenta a perspetiva regulamentar: “Isto satisfaz o Artigo 32 do RGPD da UE, o Artigo 21 da NIS2 e a evidência de risco associado às TIC no âmbito da DORA?”

A resposta honesta é: ainda não.

Esta é a lacuna de 2026 que muitas organizações enfrentam. Têm controlos de segurança, mas não a camada de governação que indica a cada controlo o que deve proteger, com que nível de rigor e como o deve demonstrar. Essa camada de governação é a classificação de dados e a rotulagem da informação.

Em termos de ISO/IEC 27001:2022, a classificação e a rotulagem não são práticas cosméticas de gestão documental. São a ponte prática entre avaliação de riscos, controlo de acessos, cifragem, retenção, DLP, residência dos dados na nuvem, diligência prévia de fornecedores, monitorização e notificação de incidentes. No modelo de implementação da Clarysec, estão no centro da cadeia de evidência do SGSI: inventariar o ativo, atribuir um proprietário, classificá-lo, rotulá-lo, aplicar regras de tratamento, monitorizar exceções e demonstrar rastreabilidade aos auditores.

Porque é que a classificação e a rotulagem são agora controlos ao nível do Conselho de Administração

Reguladores e clientes esperam cada vez mais que as organizações demonstrem que as medidas de segurança são adequadas à sensibilidade dos dados, à criticidade do serviço e ao impacto de uma falha no negócio.

O RGPD da UE torna isto explícito através do princípio da responsabilidade. O Artigo 5 exige que os dados pessoais sejam tratados de forma lícita, leal e transparente, limitados ao necessário, retidos apenas pelo tempo necessário e protegidos por medidas técnicas e organizativas adequadas. O responsável pelo tratamento também deve conseguir demonstrar conformidade. O Artigo 32 do RGPD da UE torna-se então difícil de evidenciar sem saber que sistemas tratam dados pessoais, que dados são de alto risco ou de categoria especial, onde estão armazenados e que salvaguardas se aplicam.

A NIS2 eleva o patamar da governação. O Artigo 20 exige que os órgãos de gestão de entidades essenciais e importantes aprovem medidas de gestão dos riscos de cibersegurança, supervisionem a sua implementação e recebam formação. O Artigo 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionais, incluindo análise de riscos, políticas de segurança, tratamento de incidentes, continuidade de negócio, segurança da cadeia de abastecimento, segurança na aquisição e no desenvolvimento, avaliação da eficácia, higiene de cibersegurança, formação, criptografia, segurança de recursos humanos, controlo de acessos e gestão de ativos. A classificação não é uma obrigação separada nessa lista. É o sistema de decisão que torna essas medidas proporcionais.

A DORA aplica a mesma lógica às entidades financeiras e aos ecossistemas fintech. Desde 17 de janeiro de 2025, a DORA exige um quadro documentado de gestão do risco associado às TIC, responsabilidade do órgão de gestão, políticas para confidencialidade, integridade, disponibilidade e autenticidade, classificação de incidentes, testes de resiliência e gestão do risco de terceiros prestadores de serviços de TIC. Para entidades financeiras reguladas pela DORA, a DORA pode funcionar como ato jurídico setorial da União em substituição de obrigações sobrepostas de gestão de riscos e reporte da NIS2, mas a expectativa de evidência permanece a mesma: demonstrar como a informação crítica e os ativos de TIC são identificados, protegidos, testados, monitorizados e governados.

A ISO/IEC 27001:2022 é adequada como modelo operativo desta evidência. As cláusulas 4.1 a 4.4 exigem que a organização compreenda questões internas e externas, requisitos das partes interessadas, obrigações regulamentares e contratuais e interfaces com outras organizações. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos, seleção de controlos, uma Declaração de Aplicabilidade e evidência retida. ISO/IEC 27001:2022

Se o RGPD da UE, a NIS2 e a DORA perguntarem: “Porque aplicaram estas medidas?”, a ISO/IEC 27001:2022 ajuda a responder: “Porque estes ativos, tipos de dados, riscos, obrigações e decisões de tratamento nos conduziram até aqui.”

A classificação é a decisão de risco. A rotulagem é o sinal operacional.

A Clarysec separa classificação e rotulagem porque os auditores também o fazem.

A classificação é o ato de decidir a sensibilidade, o valor e a criticidade da informação. A rotulagem é o ato de tornar essa decisão visível, persistente e aplicável nas operações diárias.

A Política de Classificação e Rotulagem da Informação - PME da Clarysec define claramente a finalidade:

Esta política define como toda a informação tratada pela organização deve ser classificada e rotulada para assegurar que a sua confidencialidade, integridade e disponibilidade são mantidas ao longo de todo o seu ciclo de vida.

A mesma Política de Classificação e Rotulagem da Informação - PME exige que as organizações:

Exijam que todos os ativos de dados sejam classificados de acordo com a sua sensibilidade e rotulados em conformidade, para orientar o tratamento, o armazenamento e o acesso adequados.

Para ambientes empresariais, a P13 Política de Classificação e Rotulagem da Informação da Clarysec define o modelo mínimo de classificação:

A organização deve manter um esquema de classificação padronizado com níveis claramente definidos. No mínimo, devem ser utilizados os seguintes níveis de classificação: 5.1.1 Público: informação destinada à publicação aberta e à distribuição sem restrições 5.1.2 Interno: informação de negócio não pública não destinada a divulgação externa 5.1.3 Confidencial: dados sensíveis de negócio, contratuais ou de clientes que exigem controlo de acessos rigoroso 5.1.4 Restrito (ou Altamente Confidencial): informação crítica ou regulada cuja divulgação não autorizada pode causar danos significativos ou responsabilidade legal

Esta distinção é importante. Uma classificação “Confidencial” pode exigir cifragem, acesso baseado em funções e salvaguardas contratuais. Uma classificação “Restrito” pode acionar MFA, aprovação do CISO para partilha externa, registo reforçado, governação mais rigorosa da retenção, segregação e escalonamento prioritário de incidentes.

A política empresarial é explícita quanto à rotulagem operacional:

Todos os ativos de informação devem ser rotulados de forma que seja: 6.2.1.1 Persistente: não facilmente removível ou substituível 6.2.1.2 Visível: clara para os utilizadores no ponto de utilização 6.2.1.3 Legível por máquina: sempre que possível, deve ser suportada rotulagem baseada em metadados

Os rótulos legíveis por máquina são o ponto em que o programa evolui da sensibilização para a aplicação efetiva. Se os rótulos forem baseados em metadados, plataformas de nuvem, sistemas DLP, gateways de correio eletrónico, ferramentas de identidade, regras de SIEM, plataformas CASB e motores de retenção podem atuar sobre eles. Se os rótulos forem apenas um rodapé num documento, podem ajudar os utilizadores, mas não conseguem aplicar regras de forma fiável em escala.

Onde a classificação se integra no roteiro da Clarysec

O Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec posiciona a classificação no início do ciclo de vida da gestão de riscos, não depois da implementação tecnológica. Na fase de gestão de riscos, o passo 9, “Identificação de ativos, ameaças e vulnerabilidades”, orienta as equipas a inventariar ativos de informação e a registar proprietário, localização e classificação.

Isto evita uma falha comum: ter um inventário de nuvem, mas não um inventário de informação. Uma base de dados, um tenant SaaS ou um armazém de dados é um ativo tecnológico. Os registos de clientes, ficheiros de colaboradores, logs de pagamentos, conjuntos de dados de treino de modelos, transcrições de suporte e evidência de incidentes dentro desses sistemas são ativos de informação. A classificação vive nesse nível da informação.

A orientação do Zenith Blueprint sobre o controlo 5.12 da ISO/IEC 27002:2022, Classificação da informação, explica o princípio:

Todos os controlos de segurança da informação alguma vez escritos — restrição de acesso, cifragem, cópia de segurança, monitorização ou eliminação — assumem uma coisa: que a organização sabe o que está a proteger. O controlo 5.12 exige que a informação seja classificada com base no seu valor, sensibilidade e criticidade, constituindo a base de todas as decisões subsequentes no SGSI.

Para o controlo 5.13 da ISO/IEC 27002:2022, Rotulagem da informação, o mesmo roteiro transforma a classificação em comportamento diário:

A rotulagem é a forma de converter uma política abstrata em realidade operacional. É o momento em que um utilizador, ao ver um documento, uma mensagem de correio eletrónico, um campo de base de dados ou um relatório impresso, consegue perceber de imediato: que informação é esta, quão sensível é e como deve ser tratada.

A ligação final do roteiro surge no passo 13, “Planeamento do tratamento de riscos e Declaração de Aplicabilidade”. O Zenith Blueprint descreve a SoA como a ponte entre riscos, tratamentos e controlos. É aqui que a classificação se transforma em rastreabilidade de auditoria. Um cenário de risco como “divulgação não autorizada de dados financeiros de clientes a partir de armazenamento de nuvem partilhado” pode ser mapeado para classificação, rotulagem, controlo de acessos, cifragem, registo, DLP, utilização da nuvem, requisitos de fornecedores e resposta a incidentes.

As relações entre controlos que os auditores esperam ver

No Zenith Controls: guia de conformidade cruzada da Clarysec, o controlo 5.12 da ISO/IEC 27002:2022, Classificação da informação, é mapeado como controlo preventivo que suporta confidencialidade, integridade e disponibilidade. Está associado ao conceito de cibersegurança Identificar, à capacidade operacional de Proteção da Informação e aos domínios de segurança Proteção e Defesa.

Para o controlo 5.13 da ISO/IEC 27002:2022, Rotulagem da informação, o Zenith Controls mapeia o controlo como preventivo, focado em Proteger, com as mesmas propriedades de segurança da informação e a mesma capacidade operacional de Proteção da Informação.

O ponto crítico é que a classificação e a rotulagem não são isoladas. Tornam defensáveis os controlos envolventes.

O Zenith Controls mapeia o controlo 5.12 para o Artigo 32 e o Considerando 83 do RGPD da UE, NIS2 Article 21(2)(a) e 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 e PM-11, FIPS 199 e NIST SP 800-60, e COBIT 2019 DSS06.06 e APO13.01. Mapeia o controlo 5.13 para o Artigo 32 do RGPD da UE, NIS2 Article 21(2)(a) e 21(2)(f), DORA Article 9(1) e 9(2), NIST SP 800-53 MP-3 e COBIT 2019 DSS06.06.

Isto significa que um único conjunto de evidências pode responder a várias perguntas de garantia.

O registo de ativos é onde a classificação se torna evidência

Muitos programas de classificação falham porque o esquema de classificação existe apenas numa política. A abordagem da Clarysec começa no inventário de ativos.

A P12 Política de Gestão de Ativos da Clarysec exige que o inventário de ativos inclua o nível de classificação como campo mínimo:

O inventário de ativos deve conter, no mínimo: 5.3.1 ID do ativo, categoria e tipo 5.3.2 Número de série ou etiqueta única (para ativos físicos) 5.3.3 Versão de software ou chave de licença (para ativos de software) 5.3.4 Proprietário do ativo 5.3.5 Nível de classificação (Público, Interno, Confidencial, Restrito) 5.3.6 Localização (física, virtual, nuvem) 5.3.7 Estado do ciclo de vida (ativo, em manutenção, retirado de serviço)

Isto alinha-se diretamente com o planeamento de riscos da ISO/IEC 27001:2022. Se não consegue identificar o ativo de informação, o proprietário, a localização e a classificação, não consegue avaliar de forma consistente a probabilidade, o impacto, a prioridade de tratamento ou o risco residual. Também não consegue decidir com confiança se um acordo com fornecedor, serviço de nuvem ou integração SaaS afeta informação regulada.

Para o RGPD da UE, isto suporta o princípio da responsabilidade. Os registos de atividades de tratamento do Artigo 30 e as medidas de segurança do Artigo 32 tornam-se mais credíveis quando o registo de ativos identifica onde os dados pessoais são tratados e como são protegidos. Para a DORA, o mesmo registo suporta a criticidade de ativos e serviços de TIC, o âmbito de testes de resiliência e a análise de dependências de terceiros. Para a NIS2, suporta análise de riscos, controlo de acessos e gestão de ativos.

Este tipo de registo muda o tom de uma auditoria. Em vez de dizer “acreditamos que os dados sensíveis estão protegidos”, a organização consegue demonstrar que dados são, quem é o seu proprietário, porque são Restritos, que controlos se aplicam e quando esses controlos foram revistos pela última vez.

Os rótulos devem determinar as regras de tratamento em nuvem e SaaS

A maioria dos dados sensíveis circula agora por plataformas de nuvem, aplicações SaaS, pipelines analíticos e ferramentas de colaboração. Uma política que diga aos utilizadores para “tratar dados confidenciais com cuidado” não é suficiente.

A P27 Política de Utilização da Cloud da Clarysec liga diretamente a utilização da nuvem à classificação e à residência dos dados:

Classificação e residência dos dados 6.6.1 Nenhum dado pode ser movido para uma plataforma de nuvem sem classificação de acordo com a Política de Classificação e Rotulagem da Informação (P13). 6.6.2 Os requisitos de residência dos dados devem ser impostos contratualmente (por exemplo, armazenamento apenas na UE para dados regulados pelo RGPD da UE). 6.6.3 As transferências transfronteiriças de dados devem cumprir o Capítulo V do RGPD da UE e, quando aplicável, o Artigo 28 da DORA.

Isto é importante porque o risco de nuvem entra frequentemente pela conveniência. Uma equipa exporta um conjunto de dados para uma nova ferramenta analítica. A área comercial sincroniza listas de clientes para uma plataforma de automatização. Um programador copia dados de produção para um ambiente de teste. Sem classificação e rotulagem, estas ações podem não acionar revisão jurídica, aprovação de segurança ou verificações de fornecedores.

A Política de Classificação e Rotulagem da Informação - PME dá às organizações mais pequenas um padrão de implementação simples:

Pastas partilhadas ou unidades de nuvem devem utilizar nomes de pastas ou tags para indicar a classificação (por exemplo, “/Clients_Confidential”).

Em ambientes maduros, os nomes de pastas devem ser complementados por rótulos legíveis por máquina, políticas de acesso condicional, bloqueios de partilha externa, cifragem, rótulos de retenção, regras DLP e registo. O objetivo não é apenas rotular informação. O objetivo é tornar o rótulo acionável.

Um rótulo “Restrito” pode acionar bloqueios de partilha externa, cifragem de dados em repouso e em trânsito, MFA, restrições de transferência em dispositivos não geridos, retenção de logs de auditoria, alertas SIEM, regras de retenção, limites de localização de fornecedores e escalonamento de severidade de incidentes.

A P13 Política de Classificação e Rotulagem da Informação estabelece a linha de base:

Todo o tratamento, transmissão, acesso, armazenamento e eliminação de informação deve estar alinhado com o seu nível de classificação. No mínimo: 6.3.1.1 Público: pode ser divulgado livremente; não exige tratamento especial 6.3.1.2 Interno: partilhado dentro da organização; armazenado em sistemas internos seguros 6.3.1.3 Confidencial: 6.3.1.3.1 Acesso restrito apenas a pessoal autorizado 6.3.1.3.2 Deve ser cifrado em trânsito e em repouso 6.3.1.3.3 Só pode ser partilhado externamente ao abrigo de um NDA ou salvaguardas contratuais equivalentes 6.3.1.4 Restrito: 6.3.1.4.1 Aplicam-se os requisitos de segurança mais elevados 6.3.1.4.2 São exigidos controlos de acesso fortes, autenticação multifator (MFA) e registo de auditoria 6.3.1.4.3 Segregação física e lógica sempre que viável 6.3.1.4.4 A partilha externa é proibida sem aprovação do CISO

Cada rótulo tem um comportamento. Cada comportamento tem um controlo. Cada controlo tem evidência.

Um exemplo prático de aplicação

Considere um analista fintech que cria Q3_2026_Customer_Churn_Analysis.xlsx. A folha de cálculo inclui IDs de clientes, volumes de transações e pontuação preditiva de abandono.

O analista classifica-a como Confidencial porque contém dados de clientes e análise estratégica. Utilizando a ferramenta de proteção da informação da empresa, o analista aplica o rótulo Confidencial. Como o rótulo é persistente, visível e legível por máquina, os controlos são ativados automaticamente.

O ficheiro é cifrado em repouso no dispositivo e no armazenamento de nuvem. Um cabeçalho visível assinala-o como Confidencial. Quando o analista tenta sincronizá-lo para uma unidade de nuvem pessoal, uma regra DLP bloqueia a ação e regista a tentativa. Quando o analista tenta enviá-lo por correio eletrónico para um domínio externo que não é parceiro, o gateway de correio eletrónico coloca a mensagem em quarentena e alerta as operações de segurança. Se o ficheiro for posteriormente reclassificado como Restrito por conter dados regulados de transações financeiras, a partilha externa é desativada, salvo se o CISO ou o proprietário dos dados aprovar a exceção.

Esta é a prova que o Diretor Executivo queria. É rastreável, automatizada e vinculada a uma política aprovada pelo Conselho de Administração. Também se alinha com a P27 Política de Utilização da Cloud, porque nenhum movimento para a nuvem é permitido sem classificação e as transferências transfronteiriças devem cumprir o Capítulo V do RGPD da UE e, quando aplicável, o Artigo 28 da DORA.

Construa uma matriz de classificação para controlos numa semana

Um programa completo leva tempo, mas um sprint focado pode criar a espinha dorsal de evidência antes de uma auditoria, revisão de cliente ou avaliação regulamentar.

Dia 1: Confirmar o esquema de classificação

Comece com quatro níveis: Público, Interno, Confidencial e Restrito. Utilize a P13 Política de Classificação e Rotulagem da Informação como linha de base. Defina critérios com base no impacto no negócio, impacto legal, sensibilidade contratual, risco de dados pessoais, criticidade do serviço e dano financeiro.

Dia 2: Selecionar dez ativos de informação críticos

Utilize o passo 9 do Zenith Blueprint. Inclua uma base de dados de clientes, sistema de pedidos de suporte, plataforma de recursos humanos, fornecedor de identidade, exportação de pagamentos, armazém de dados, bucket de armazenamento de objetos, pasta de reporte ao Conselho de Administração, repositório de código-fonte e repositório de evidência de incidentes. Registe proprietário, localização, classificação e relevância para o RGPD da UE.

Dia 3: Mapear regras de tratamento

Defina requisitos de tratamento para acesso, armazenamento, transferência, monitorização e eliminação.

Dia 4: Configurar um caminho de aplicação técnica

Escolha uma plataforma, como um repositório documental de nuvem, sistema de correio eletrónico ou serviço de armazenamento de objetos. Implemente rótulos visíveis e legíveis por máquina. Configure uma regra para dados Confidenciais e uma regra para dados Restritos. Por exemplo, exija cifragem para mensagens externas Confidenciais e bloqueie a partilha externa de ficheiros Restritos.

Dia 5: Atualizar o registo de riscos e a SoA

Utilize o passo 13 do Zenith Blueprint. Adicione os controlos de classificação e rotulagem à Declaração de Aplicabilidade. Ligue-os a riscos como divulgação não autorizada, configuração incorreta da nuvem, exposição excessiva a fornecedores, falha de retenção de dados e subnotificação de incidentes.

Dia 6: Testar o controlo

Crie um ficheiro de teste rotulado como Restrito. Tente partilhá-lo externamente a partir de um dispositivo não gerido. Confirme se a ferramenta bloqueia, avisa, regista ou escalona. Capture capturas de ecrã, entradas de logs e evidência de tickets. Se o controlo falhar, registe a exceção e o plano de remediação.

Dia 7: Formar os utilizadores de primeira linha

A formação deve ser específica para a função. Os programadores devem saber quando os dados de produção não podem ser utilizados em ambientes de teste. Recursos humanos deve compreender porque os ficheiros de colaboradores são Confidenciais ou Restritos. A área comercial deve saber porque exportações de clientes não podem ser carregadas para ferramentas SaaS não aprovadas. Os executivos devem compreender porque pacotes do Conselho de Administração, ficheiros de aquisição e dados de investidores exigem tratamento mais rigoroso.

Este sprint não conclui todo o programa, mas cria a espinha dorsal da evidência: política, inventário, rótulos, regras de tratamento, aplicação técnica, rastreabilidade do risco e formação.

Como os auditores testarão a classificação e a rotulagem

Os auditores raramente testam a classificação de forma isolada. Seguem os dados.

Um auditor ISO/IEC 27001:2022 irá ligar a classificação ao âmbito do SGSI, aos requisitos das partes interessadas, às obrigações legais e contratuais, à avaliação de riscos e à Declaração de Aplicabilidade. Esperará evidência para os controlos 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 e controlos técnicos relevantes da ISO/IEC 27002:2022. A evidência típica inclui políticas aprovadas, registos do inventário de ativos, entradas no registo de riscos, amostras rotuladas, regras de tratamento, revisão de acessos, constatações de auditoria interna e ações corretivas.

Um revisor do RGPD da UE focar-se-á nos dados pessoais. Perguntará se os dados pessoais estão identificados, se os dados de categoria especial estão diferenciados, se as regras de retenção estão alinhadas com a finalidade e se as medidas de segurança do Artigo 32 são adequadas. A classificação ajuda a separar informação de negócio comum de dados pessoais, dados pessoais sensíveis, dados confidenciais de clientes e registos regulados. A rotulagem ajuda as equipas operacionais a evitar divulgação acidental, retenção excessiva e transferência não autorizada.

Um avaliador NIST CSF 2.0 enquadrará provavelmente a classificação em GOVERN, IDENTIFY e PROTECT. Poderá perguntar se os perfis atuais e alvo definem a descoberta de dados sensíveis, se a aplicação de rótulos funciona em sistemas SaaS e de nuvem, se os fornecedores tratam os dados de acordo com a classificação e se as prioridades de monitorização se ajustam em função da sensibilidade.

Um auditor de COBIT 2019 ou de estilo ISACA enfatizará objetivos de governação, propriedade de processos, desenho de controlos e eficácia operacional. O Zenith Controls mapeia o controlo de inventário 5.9 para COBIT 2019 BAI09.01, BAI09.02 e DSS05.04, e referencia ISACA ITAF 2204 e 2301. Para classificação, o Zenith Controls mapeia o controlo 5.12 para COBIT 2019 DSS06.06 e APO13.01, enquanto a rotulagem é mapeada para DSS06.06. O auditor perguntará quem é proprietário do processo, como são aprovadas as exceções, se o desempenho é monitorizado e se a gestão recebe reporte.

Um revisor focado na DORA perguntará que ativos de informação suportam funções críticas ou importantes, que dados são Restritos, que terceiros prestadores de serviços de TIC armazenam ou transmitem esses dados, se os contratos definem localizações e medidas de segurança, se os testes são delimitados a dados críticos e se os incidentes são classificados, em parte, pela perda de dados em disponibilidade, autenticidade, integridade e confidencialidade.

Se as respostas vierem de um único modelo de evidência de ativos e fornecedores orientado pela classificação, as auditorias tornam-se mais rápidas, mais consistentes e mais defensáveis.

Padrões comuns de falha

As falhas de classificação acontecem normalmente porque as organizações tratam os rótulos como ferramentas de sensibilização em vez de sinais de controlo.

Primeiro, classificam documentos, mas não bases de dados, interfaces de programação de aplicações, logs, cópias de segurança, exportações ou registos SaaS. Dados sensíveis num log de depuração podem causar tanto dano como dados sensíveis numa folha de cálculo.

Segundo, rotulam informação, mas não ligam os rótulos ao controlo de acessos. Um rótulo Restrito com acesso aberto demonstra que a organização conhecia a sensibilidade e não aplicou a regra de tratamento.

Terceiro, as migrações para a nuvem acontecem antes da classificação. As equipas movem dados para novas ferramentas SaaS sem confirmar residência dos dados, termos de fornecedor, acesso de subcontratantes subsequentes, requisitos de transferência transfronteiriça ou direitos de eliminação. A P27 Política de Utilização da Cloud aborda isto diretamente ao proibir a movimentação para plataformas de nuvem sem classificação.

Quarto, os planos de resposta a incidentes ignoram a classificação. Se os critérios de severidade não incluírem a sensibilidade dos dados, as equipas de incidentes perdem tempo a descobrir o que foi afetado durante uma crise. A análise de violações do RGPD da UE, o tratamento de incidentes da NIS2 e a classificação de incidentes da DORA beneficiam todos de contexto de dados rápido.

Quinto, a SoA não explica porque os controlos de classificação e rotulagem são aplicáveis. A organização pode ter implementado rótulos, mas a SoA não os liga ao Artigo 32 do RGPD da UE, ao Artigo 21 da NIS2, ao risco associado às TIC no âmbito da DORA, a contratos de clientes ou a cenários de risco específicos.

Reporte à gestão: tornar a classificação visível

A NIS2 e a DORA tornam a cibersegurança uma questão de responsabilidade da gestão. A ISO/IEC 27001:2022 também exige compromisso da liderança, alinhamento de políticas, recursos, papéis e reporte de desempenho. As métricas de classificação devem, por isso, chegar à revisão pela gestão.

Métricas úteis incluem:

• Percentagem de ativos de informação críticos com proprietários designados.
• Percentagem de ativos com classificação aprovada.
• Número de ativos Restritos sem registo reforçado.
• Número de repositórios Confidenciais ou Restritos com partilha externa ativada.
• Percentagem de fornecedores que tratam dados Confidenciais ou Restritos com cláusulas contratuais atualizadas.
• Número de exceções de classificação e ações de remediação em atraso.
• Incidentes DLP por rótulo.
• Conclusão da revisão de acessos para ativos Restritos.
• Localizações de armazenamento de nuvem para dados regulados pelo RGPD da UE.
• Exercícios de resposta a incidentes que utilizaram critérios de severidade baseados na classificação.

Estas métricas suportam a revisão pela gestão ISO/IEC 27001:2022, a supervisão pela gestão NIS2, o reporte de governação DORA e a garantia para clientes. Também tornam a classificação compreensível para executivos. A liderança consegue agir mais rapidamente quando vê que vários repositórios Restritos não têm recuperação testada ou que fornecedores críticos tratam dados de clientes sem armazenamento confirmado na UE.

Da política à prova

O padrão de implementação da Clarysec é orientado por evidência:

1. Defina o esquema de classificação na P13 Política de Classificação e Rotulagem da Informação ou comece pela Política de Classificação e Rotulagem da Informação - PME.
2. Adicione a classificação ao inventário de ativos utilizando a P12 Política de Gestão de Ativos.
3. Aplique restrições de nuvem e requisitos de residência através da P27 Política de Utilização da Cloud.
4. Utilize o passo 9 do Zenith Blueprint para identificar ativos de informação, proprietários, localizações e sensibilidade.
5. Utilize o passo 13 do Zenith Blueprint para mapear riscos para controlos na SoA.
6. Utilize o passo 22 do Zenith Blueprint para implementar os controlos 5.12 e 5.13 da ISO/IEC 27002:2022 nas operações diárias.
7. Utilize o Zenith Controls para mapear a mesma evidência para RGPD da UE, NIS2, DORA, NIST CSF, COBIT 2019 e normas de suporte.
8. Teste a aplicação de rótulos, restrições de acesso, registo, DLP e triagem de incidentes.
9. Reporte o desempenho da classificação à gestão.
10. Reveja a classificação após alterações relevantes em sistemas, processos, fornecedores ou requisitos regulamentares.

Isto funciona porque a classificação se torna a linguagem comum entre valor de negócio, obrigação legal, controlo técnico e evidência de auditoria.

Se a sua organização está a preparar-se para certificação ISO/IEC 27001:2022, garantia RGPD da UE, preparação NIS2, diligência prévia de clientes DORA ou uma auditoria de conformidade combinada, comece por uma pergunta:

Consegue demonstrar, para cada ativo de informação crítico, o que é, quem é o seu proprietário, onde está, como está classificado, como está rotulado, quem lhe pode aceder, como é protegido, por quanto tempo é retido, que fornecedor lhe toca e o que acontece se for exposto?

Se a resposta for “ainda não”, a Clarysec pode ajudar a construir a cadeia de evidência de forma rápida e defensável.

Utilize a Política de Classificação e Rotulagem da Informação - PME, a P13 Política de Classificação e Rotulagem da Informação, a P12 Política de Gestão de Ativos, a P27 Política de Utilização da Cloud, o Zenith Blueprint: roteiro de 30 passos para auditores e o Zenith Controls: guia de conformidade cruzada para transformar a classificação de uma política estática numa camada operacional de controlo para o Artigo 32 do RGPD da UE, a gestão de riscos de cibersegurança da NIS2 e a evidência de risco associado às TIC no âmbito da DORA.

O melhor momento para classificar dados teria sido antes da chegada do pedido de auditoria. O segundo melhor momento é antes da próxima migração para a nuvem, integração de fornecedores, questionário de cliente ou incidente.