Evidência da certificação EUCS de serviços cloud para auditorias de 2026

O brilho do projetor da sala de reuniões iluminava o rosto de Amelia enquanto ela observava um slide intitulado “Horizonte de conformidade 2026”. Enquanto CISO de uma fintech em rápido crescimento, tinha três acrónimos no ecrã e um problema operacional recorrente por trás de todos eles: NIS2, DORA e RGPD da UE apontavam todos para as mesmas plataformas cloud.

O auditor DORA queria evidência de gestão do risco de terceiros de TIC para os serviços cloud que alojavam aplicações de pagamento. A autoridade competente NIS2 tinha classificado a empresa como entidade importante e perguntava como era governada a segurança da cadeia de fornecimento. O Encarregado da Proteção de Dados preparava uma revisão do RGPD da UE centrada na segurança dos subcontratantes, na residência dos dados e na preparação para violações de dados. Em seguida, a área de compras encaminhou um breve email de um prestador de serviços de análise em cloud:

“Estamos a preparar-nos para a certificação EUCS. Isto pode substituir a vossa revisão de segurança de fornecedores?”

Para um CISO, responsável pela conformidade ou fundador com pouco tempo, a resposta tentadora é sim. Uma certificação europeia de cibersegurança para serviços cloud parece exatamente o tipo de evidência que deveria reduzir questionários, tranquilizar auditores e satisfazer clientes.

A resposta correta é mais precisa: a certificação EUCS de serviços cloud pode tornar-se uma evidência robusta de garantia de prestadores de serviços cloud, mas apenas quando é mapeada para a sua própria avaliação de riscos ISO/IEC 27001:2022, Declaração de Aplicabilidade, registo centralizado de fornecedores, Registo de Serviços Cloud, controlos contratuais, procedimentos de resposta a incidentes e registos de responsabilização ao abrigo do RGPD da UE.

Esta distinção é importante. A NIS2 transforma a segurança da cadeia de fornecimento e a resiliência da infraestrutura digital numa matéria sujeita a supervisão. O DORA mantém as entidades financeiras responsáveis pelo risco de terceiros de TIC, mesmo quando os serviços cloud são externalizados. O RGPD da UE exige que responsáveis pelo tratamento e subcontratantes demonstrem um tratamento responsável, lícito e seguro. A ISO/IEC 27001:2022 exige um sistema de gestão delimitado por âmbito e baseado no risco, que tenha em conta dependências legais, regulamentares, contratuais e de terceiros.

A EUCS não elimina essas obrigações. Fornece um objeto de evidência estruturado para avaliar, normalizar, questionar e reutilizar.

A abordagem da Clarysec é simples: tratar a EUCS como um contributo de elevado valor para a garantia de fornecedores, não como um atalho de conformidade. Em Zenith Controls: guia de conformidade cruzada, o cluster de garantia cloud começa com o controlo ISO/IEC 27002:2022 5.23, segurança da informação para utilização de serviços cloud, e liga-o ao 5.20, tratamento da segurança da informação em acordos com fornecedores, e ao 5.22, monitorização, revisão e gestão de alterações dos serviços de fornecedores. Estes três controlos formam a espinha dorsal de uma revisão defensável de evidência EUCS.

Porque a garantia cloud está a falhar sob NIS2, DORA e RGPD da UE

Em 2026, a garantia cloud já não é apenas um fluxo de trabalho de compras. É um tema de conselho de administração, regulador e auditoria.

A Diretiva NIS2, Diretiva (UE) 2022/2555, alarga as obrigações de cibersegurança das entidades essenciais e importantes. O seu âmbito inclui muitos setores que dependem fortemente de serviços de computação em cloud, e o seu panorama de infraestrutura digital inclui prestadores de serviços de computação em cloud, prestadores de serviços de centro de dados, redes de distribuição de conteúdos, prestadores de serviços de confiança, prestadores de serviços DNS e registos de nomes TLD. Os prestadores de serviços geridos e os prestadores de serviços de segurança geridos também estão em foco.

O Artigo 21 exige medidas técnicas, operacionais e organizativas 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, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, criptografia, controlo de acesso, gestão de ativos e autenticação. O Artigo 23 estabelece expectativas faseadas de notificação de incidentes, incluindo alerta precoce no prazo de 24 horas e notificação de incidente no prazo de 72 horas, sujeito à Diretiva e à transposição nacional. O Artigo 24 permite que os Estados-Membros, em determinadas circunstâncias, exijam a utilização de produtos, serviços ou processos de TIC certificados ao abrigo de esquemas europeus de certificação de cibersegurança. O Artigo 25 incentiva a utilização de normas europeias e internacionais relevantes.

O DORA, Regulamento (UE) 2022/2554, é ainda mais direto para as entidades financeiras. Desde 17 de janeiro de 2025, exige que as organizações financeiras façam a gestão do risco das TIC, comuniquem incidentes graves relacionados com TIC, testem a resiliência operacional digital e governem o risco de terceiros de TIC. Para as entidades abrangidas pelo seu âmbito, o DORA funciona como o ato jurídico setorial da União para as obrigações de cibersegurança correspondentes que se sobrepõem às regras nacionais NIS2.

O DORA não permite externalizar a responsabilização. Os Artigos 28 a 30 exigem que as entidades financeiras realizem devida diligência, avaliem o risco de concentração, mantenham registos de acordos contratuais, incluam salvaguardas contratuais obrigatórias, preservem direitos de auditoria e de acesso, assegurem assistência em incidentes, cooperem com autoridades competentes e mantenham estratégias de saída para serviços de TIC que suportem funções críticas ou importantes.

O RGPD da UE, Regulamento (UE) 2016/679, acrescenta a camada de responsabilização e proteção de dados. O Artigo 5 exige que os responsáveis pelo tratamento cumpram os princípios de proteção de dados e sejam capazes de demonstrar conformidade. O Artigo 28 regula as relações com subcontratantes e exige garantias suficientes por parte destes. O Artigo 32 exige medidas técnicas e organizativas adequadas para assegurar a segurança do tratamento.

O resultado é um problema de convergência. Um único prestador de serviços cloud pode ser um terceiro crítico de TIC ao abrigo do DORA, um fornecedor direto numa cadeia de fornecimento NIS2 e um subcontratante ou subcontratante subsequente ao abrigo do RGPD da UE. Se a garantia for gerida através de questionários, PDFs de certificação e pastas contratuais desconectados, cada auditoria transforma-se num exercício de reconstrução.

A EUCS pode reduzir esse caos, mas apenas quando é integrada num modelo de evidência governado.

O que a EUCS pode provar e o que não pode

O Esquema Europeu de Certificação de Cibersegurança para Serviços Cloud, normalmente designado por EUCS, foi concebido para fornecer um mecanismo europeu de garantia cloud no âmbito mais amplo do quadro europeu de certificação de cibersegurança. O seu valor prático não está apenas no rótulo. Está no âmbito subjacente do certificado, no nível de garantia, nos serviços avaliados, nas regiões, nas entidades jurídicas, nos limites da avaliação, no período de validade e no modelo de vigilância.

A pergunta correta sobre garantia cloud não é simplesmente: “Este prestador tem EUCS?” É:

• Que serviços cloud específicos estão abrangidos?
• Que regiões, localizações de dados e entidades jurídicas estão abrangidas?
• Que nível de garantia se aplica?
• Que método de avaliação foi utilizado?
• Que pressupostos de responsabilidade partilhada permanecem com o cliente?
• Que evidência pode ser divulgada a clientes, reguladores e auditores?
• Como é que o certificado afeta direitos de auditoria, notificação de incidentes, transparência de subcontratantes e planeamento de saída?

Um certificado cloud raramente cobre a sua configuração. Se a sua organização desativar MFA, expuser armazenamento, conceder privilégios administrativos excessivos, não registar acessos privilegiados ou configurar regiões incorretamente, a certificação do prestador não salvará a sua auditoria.

É por isso que a EUCS pertence a uma matriz de evidência, não a um pedestal. Pode apoiar a garantia do lado do prestador, mas a sua organização continua a ter de provar os seus próprios controlos de governação, configuração, contratos e monitorização.

O Zenith Blueprint: roteiro de 30 passos para auditores deixa isto claro na fase de gestão de riscos, Passo 13, planeamento do tratamento de riscos e Declaração de Aplicabilidade:

A SoA é, na prática, um documento de ligação: liga a avaliação/tratamento de riscos aos controlos efetivamente existentes. Ao preenchê-la, também verifica se algum controlo ficou em falta.

Esse é o modelo mental correto para a EUCS. O certificado é evidência de fornecedor. A sua Declaração de Aplicabilidade explica porque os controlos relacionados são aplicáveis, como a organização implementou o seu lado da responsabilidade partilhada, que evidência de fornecedor foi aceite e que riscos residuais permanecem.

A espinha dorsal ISO 27001 para evidência EUCS

A ISO/IEC 27001:2022 dá à EUCS um local próprio. As suas cláusulas exigem que as organizações compreendam questões internas e externas, identifiquem partes interessadas e requisitos, definam o âmbito do SGSI, atribuam responsabilidades de liderança, avaliem riscos, selecionem controlos, mantenham uma Declaração de Aplicabilidade e melhorem continuamente.

Para a garantia cloud, a EUCS deve ser incorporada em pelo menos seis artefactos do SGSI.

A biblioteca de políticas da Clarysec transforma estes requisitos em disciplina operacional.

A Política de Utilização da Cloud - PME, secção Requisitos de governação, cláusula 5.2, define uma linha de base para serviços cloud aprovados:

Os serviços cloud aprovados devem cumprir os seguintes critérios de referência: 5.2.1 O prestador mantém uma reputação sólida em termos de disponibilidade e segurança 5.2.2 A autenticação multifator (MFA) é suportada e pode ser ativada 5.2.3 As práticas de residência dos dados e privacidade cumprem os requisitos legais aplicáveis (por exemplo, RGPD da UE) 5.2.4 O serviço disponibiliza controlos de acesso seguros, registo de eventos e capacidades de proteção de dados

Um certificado EUCS pode apoiar a 5.2.1 e elementos da 5.2.3 e 5.2.4. Não prova que o seu tenant tenha MFA ativada, registo de eventos configurado, residência dos dados aplicada ou acesso administrativo revisto.

Para organizações de maior dimensão, a Política de Utilização da Cloud Enterprise, secção Requisitos de governação, cláusula 5.2, eleva o nível de exigência:

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

Esta frase é a posição de política que qualquer revisão EUCS deve seguir: avaliação do prestador, validação de conformidade legal e validação de controlos, não aceitação cega.

Mapeamento da EUCS para ISO 27001, NIS2, DORA e RGPD da UE

A EUCS torna-se preparada para auditoria quando os factos do certificado são mapeados para obrigações. Um CISO deve construir uma matriz de garantia cloud de conformidade cruzada que traduza a evidência do prestador em evidência de controlo reutilizável.

Esta tabela não serve apenas para documentação de conformidade. É a ponte entre a garantia do prestador e a responsabilização da sua organização.

A NIS2 pergunta se a sua entidade adotou medidas adequadas e proporcionadas. O DORA pergunta se a sua entidade financeira governa o risco de terceiros de TIC através de devida diligência, contratos, monitorização e planeamento de saída. O RGPD da UE pergunta se o tratamento de dados pessoais é lícito, seguro e demonstrável. A ISO/IEC 27001:2022 pergunta se tudo isto está integrado num sistema de gestão baseado no risco.

Exemplo prático: revisão da EUCS para um prestador de serviços de análise em cloud

Voltemos à fintech de Amelia, a Northstar Pay. A empresa pretende integrar uma plataforma de análise em cloud para deteção de fraude e reporte de transações. O prestador apresenta um certificado EUCS e afirma que este deve satisfazer a revisão de segurança.

A Clarysec estruturaria a revisão de evidência em seis passos.

Passo 1: Atualizar o Registo de Serviços Cloud

A Política de Utilização da Cloud - PME, secção Requisitos de governação, cláusula 5.3, exige um registo que documente o nome do serviço cloud, finalidade, proprietário responsável, tipos de dados, país ou região, permissões de acesso, contas administrativas, detalhes contratuais, datas de renovação e contactos de suporte.

Para empresas, a Política de Utilização da Cloud, secção Requisitos de governação, cláusula 5.1, começa pela titularidade:

A organização deve manter um Registo de Serviços Cloud centralizado, detido pelo CISO, contendo:

A Northstar Pay regista o serviço antes da aprovação, não depois da entrada em produção.

Passo 2: Validar o âmbito do certificado

A equipa verifica se o certificado EUCS cobre o serviço de análise exato, o modelo de implementação, a região e a entidade jurídica que a Northstar Pay irá utilizar. Se o certificado cobrir serviços de infraestrutura, mas excluir o módulo de análise, o valor probatório fica limitado.

É aqui que muitas auditorias falham. O prestador diz “certificado”, mas o cliente não consegue demonstrar que o certificado se aplica ao serviço que trata dados regulados.

Passo 3: Mapear a EUCS para o tratamento de riscos e a SoA

Utilizando o Zenith Blueprint, Passo 13, a Northstar Pay mapeia o certificado para o Registo de Riscos e a Declaração de Aplicabilidade.

A SoA regista então os controlos ISO/IEC 27002:2022 5.20, 5.22 e 5.23 como aplicáveis, porque a organização utiliza serviços cloud para tratamento regulado e fluxos de trabalho analíticos importantes.

Passo 4: Confirmar cláusulas contratuais e direitos de auditoria

A Política de Segurança de Terceiros e Fornecedores - PME, secção Requisitos de governação, cláusula 5.3, exige cláusulas contratuais obrigatórias:

Os contratos devem incluir cláusulas obrigatórias que cubram: 5.3.1 Confidencialidade e não divulgação 5.3.2 Obrigações de segurança da informação 5.3.3 Prazos de notificação de violação de dados (por exemplo, no prazo de 24–72 horas) 5.3.4 Direitos de auditoria ou disponibilidade de evidência de conformidade 5.3.5 Restrições a subcontratação adicional sem aprovação 5.3.6 Termos de cessação, incluindo devolução segura ou destruição dos dados

A evidência EUCS e os direitos contratuais têm finalidades diferentes. O certificado apoia a garantia. O contrato cria exigibilidade.

A Política de Segurança de Terceiros e Fornecedores Enterprise, secção Requisitos de implementação da política, cláusula 6.1.2.2, inclui explicitamente:

Revisão de relatórios de auditoria (por exemplo, SOC 2, ISO 27001, ISAE 3402)

A EUCS pertence a essa família de evidência, juntamente com outros relatórios de garantia. Não deve substituir a revisão contratual, os direitos de auditoria, a assistência em incidentes ou as cláusulas de estratégia de saída exigidas pelo DORA.

Passo 5: Aplicar a residência dos dados para dados regulados

A Política de Utilização da Cloud, secção Requisitos de implementação da política, cláusula 6.6.2, estabelece:

Os requisitos de residência dos dados devem ser aplicados contratualmente (por exemplo, armazenamento apenas na UE para dados regulados pelo RGPD da UE).

Para a responsabilização ao abrigo do RGPD da UE, um certificado que descreva controlos regionais é útil. Continua, porém, a não ser suficiente. A Northstar Pay precisa do acordo de tratamento de dados, de linguagem contratual de armazenamento apenas na UE, de evidência de configuração do tenant e de um método para monitorizar alterações.

Se a plataforma de análise permitir que administradores selecionem regiões, o dossiê de auditoria deve incluir capturas de ecrã de configuração, definições exportadas ou outros registos que demonstrem a região da UE aprovada.

Passo 6: Agendar revisões anuais e motivadas por eventos

A Política de Segurança de Terceiros e Fornecedores - PME, secção Requisitos de implementação da política, cláusula 6.3.1, exige revisão anual de fornecedores críticos ou de alto risco para verificar métodos de acesso seguro, certificações de segurança válidas ou evidência de controlo atualizada, histórico de incidentes e conformidade contratual.

A revisão também deve ser desencadeada quando o prestador altera subcontratantes subsequentes, regiões, serviços, arquitetura de identidade, modelo de cifragem, histórico de incidentes ou estado do certificado. A evidência de garantia envelhece, e o risco de fornecedor não é estático.

O pacote de evidência EUCS da Clarysec

Um pacote de garantia EUCS maduro contém mais do que o PDF do certificado. A Clarysec estrutura a evidência em sete secções.

A Política de Cumprimento Legal e Regulamentar, secção Requisitos de implementação da política, cláusula 6.2.1, capta o princípio operacional:

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).

Esta é a diferença entre recolher certificados e construir um modelo operacional de conformidade defensável.

Evidência de incidentes e resiliência: onde a EUCS não chega

A NIS2 e o DORA fazem da preparação para incidentes e da resiliência um teste sério à governação cloud.

O certificado EUCS de um prestador de serviços cloud pode demonstrar que o prestador tem controlos de gestão de incidentes. A sua organização continua a ter de saber quem recebe notificações, como os alertas são triados, como a evidência é preservada, como o impacto em dados pessoais é avaliado e quem comunica com reguladores, clientes e liderança interna.

Para a NIS2, os termos de notificação do prestador devem suportar as obrigações de alerta precoce e notificação de incidentes. Para o DORA, os incidentes cloud devem alimentar os processos de classificação, escalonamento, comunicação e comunicação a clientes relativos a incidentes de TIC. Para o RGPD da UE, o fluxo de trabalho de violação de dados deve suportar a avaliação sobre se ocorreu uma violação de dados pessoais e se é necessária notificação à autoridade de controlo ou aos titulares dos dados afetados.

O NIST CSF 2.0 é útil como linguagem de integração neste contexto. As suas Funções GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER ajudam as organizações a traduzir obrigações legais e controlos técnicos em resultados operacionais. Os seus resultados de cadeia de fornecimento exigem que os fornecedores sejam conhecidos, priorizados, governados contratualmente, monitorizados, incluídos no planeamento de incidentes e geridos aquando da cessação. Os seus resultados de resposta e recuperação abrangem triagem, escalonamento, coordenação com terceiros, notificação das partes interessadas, execução da recuperação e verificação do restauro.

O certificado entra no dossiê. O procedimento de resposta a incidentes prova a preparação.

Como os auditores irão testar a evidência EUCS

Diferentes auditores abordam a garantia cloud por ângulos distintos. Um modelo de evidência de conformidade cruzada evita que os mesmos factos sejam remontados em cada revisão.

O Zenith Blueprint, fase Controls in Action, Passo 23, alerta que os controlos cloud são fortemente escrutinados:

Este controlo é frequentemente objeto de forte escrutínio. Os auditores perguntarão:

✓ “Que serviços cloud estão a utilizar?” ✓ “Quem os aprovou?” ✓ “Como garantem que os dados estão protegidos?”

Estas perguntas são a essência da garantia EUCS. Um certificado pode ajudar a responder como a proteção do lado do prestador é evidenciada, mas não consegue responder que serviços são utilizados ou quem os aprovou, a menos que o Registo de Serviços Cloud e o fluxo de aprovação estejam atualizados.

Erros comuns de garantia EUCS a evitar

O primeiro erro é tratar a EUCS como uma aprovação universal. É evidência delimitada por âmbito. Se o certificado não cobrir o serviço adquirido, a região, o modelo de implementação ou a entidade jurídica, o seu valor de garantia pode ser limitado.

O segundo erro é confundir controlos do prestador com controlos do cliente. A certificação do prestador não prova MFA do tenant, RBAC, registo de eventos, definições de cifragem, cópias de segurança, revisões de acesso administrativo ou monitorização.

O terceiro erro é ignorar os requisitos contratuais do DORA. As entidades financeiras precisam de direitos e obrigações escritos, incluindo descrições dos serviços, localizações dos dados, requisitos de segurança da informação, direitos de acesso e auditoria, níveis de serviço, assistência em incidentes, cooperação com autoridades, direitos de cessação e estratégias de saída para funções críticas ou importantes.

O quarto erro é ignorar a evidência do RGPD da UE. Linguagem de residência dos dados, transparência de subcontratantes subsequentes, tratamento de violações de dados, licitude do tratamento e registos de responsabilização continuam a ser necessários. A EUCS pode apoiar evidência de segurança do Artigo 32, mas não define o seu fundamento de licitude, finalidade do tratamento ou regras de retenção.

O quinto erro é não monitorizar o estado do certificado. Se a certificação expirar, o âmbito mudar, surgirem constatações de vigilância ou o prestador alterar a arquitetura, a sua revisão de risco de fornecedor deve capturar a alteração.

Checklist prática de revisão EUCS para 2026

Utilize esta checklist antes de aceitar a EUCS como evidência de garantia de prestador de serviços cloud:

• Confirmar o esquema de certificação, o nível de garantia, o titular do certificado e o período de validade.
• Confirmar os serviços, regiões, modelos de implementação e entidades jurídicas exatos no âmbito.
• Comparar o âmbito do certificado com a entrada no Registo de Serviços Cloud.
• Mapear a evidência para os controlos ISO/IEC 27002:2022 5.20, 5.22 e 5.23.
• Atualizar o Registo de Riscos e a SoA com a evidência do certificado e o risco residual.
• Validar controlos do lado do cliente, especialmente identidade, MFA, registo de eventos, cifragem, cópias de segurança e acesso administrativo.
• Confirmar cláusulas de residência dos dados, subcontratantes subsequentes, notificação de violação de dados, evidência de auditoria e cessação.
• Ligar vias de notificação de incidentes aos prazos da NIS2, do DORA e do RGPD da UE.
• Rever o risco de concentração e a estratégia de saída para serviços críticos ou importantes.
• Agendar revisão anual e reavaliação motivada por eventos.

Faça a evidência EUCS funcionar dentro do seu SGSI

A certificação EUCS de serviços cloud pode melhorar materialmente a garantia de prestadores de serviços cloud em 2026. Pode reduzir a fadiga de questionários, reforçar a devida diligência de fornecedores e apoiar evidência para ISO 27001, NIS2, DORA e RGPD da UE. Mas só se torna defensável quando é mapeada para o seu sistema de governação.

A Clarysec ajuda as organizações a transformar evidência de certificação cloud em operações de conformidade preparadas para auditoria através do Zenith Blueprint, Zenith Controls, Política de Utilização da Cloud, Política de Utilização da Cloud - PME, Política de Segurança de Terceiros e Fornecedores - PME, Política de Segurança de Terceiros e Fornecedores e Política de Cumprimento Legal e Regulamentar.

Se o seu roteiro de 2026 inclui EUCS, preparação para NIS2, risco de terceiros de TIC ao abrigo do DORA, tratamento em cloud no âmbito do RGPD da UE ou certificação ISO/IEC 27001:2022, comece por uma ação prática: construa o seu Registo de Serviços Cloud, anexe evidência de garantia do prestador e mapeie cada serviço cloud crítico para riscos, contratos, controlos e proprietários. É aqui que a garantia cloud se torna defensável.