Evidência de auditoria cloud para ISO 27001, NIS2 e DORA
Maria, a CISO de uma empresa de análise financeira em rápido crescimento, tinha seis semanas até três prazos convergirem. A auditoria de acompanhamento ISO 27001:2022 já estava agendada. A NIS2 tinha elevado a empresa a um novo nível de responsabilização da gestão enquanto entidade importante. A DORA estava prestes a testar se as suas operações fintech conseguiam demonstrar resiliência operacional digital. Ao mesmo tempo, um grande cliente empresarial mantinha um contrato suspenso até a sua equipa passar uma revisão detalhada de garantia de segurança.
A empresa não era insegura. Executava cargas de trabalho de produção na AWS e Azure, utilizava Microsoft 365 e várias plataformas SaaS críticas, impunha MFA, fazia cópias de segurança dos dados, realizava análises de vulnerabilidades e recolhia logs cloud. O problema era a prova.
A evidência estava dispersa por capturas de ecrã do Slack, páginas wiki de programadores, exportações de consolas cloud, pastas de compras, contratos jurídicos e garantias verbais de proprietários de plataformas. Quando um auditor perguntasse: “Mostre-me como controla o seu ambiente cloud”, uma hiperligação para a página de conformidade de um prestador de serviços cloud não seria suficiente. Os certificados do prestador provavam os controlos do prestador. Não provavam a parte de Maria no modelo de responsabilidade partilhada.
É aqui que muitos programas de evidência de auditoria de segurança cloud falham. Não porque os controlos estejam ausentes, mas porque a organização não consegue provar, de forma estruturada e rastreável, que responsabilidades pertencem ao prestador, quais pertencem ao cliente, como estão configurados os controlos SaaS e IaaS, como são aplicados os compromissos dos fornecedores e como a evidência é retida para auditores, reguladores e clientes.
A conformidade cloud já não é um apêndice técnico. Para um prestador SaaS abrangido pela NIS2, uma entidade financeira abrangida pela DORA ou qualquer organização ISO 27001:2022 que utilize IaaS, PaaS e SaaS, a governação cloud faz parte do âmbito do SGSI, do plano de tratamento de riscos, do ciclo de vida dos fornecedores, do processo de incidentes, da responsabilização em privacidade e da revisão pela gestão.
O objetivo prático é simples: construir uma única arquitetura de evidência cloud pronta para reguladores que responda a perguntas de ISO 27001:2022, NIS2, DORA, RGPD da UE, garantia de clientes e auditoria interna sem reconstruir evidência para cada referencial.
A cloud está sempre no âmbito, mesmo quando a infraestrutura é externalizada
A primeira armadilha de auditoria é assumir que a infraestrutura externalizada está fora do SGSI. Não está. A externalização altera o perímetro de controlo; não elimina a responsabilização.
A ISO/IEC 27001:2022 exige que a organização defina o seu contexto, partes interessadas, âmbito do SGSI, interfaces, dependências e processos. Num negócio cloud-first, o fornecedor de identidade, a conta de alojamento cloud, o CRM, a plataforma de correio eletrónico, o data warehouse, a pipeline de CI/CD, a ferramenta de tickets e o serviço de cópias de segurança são frequentemente infraestrutura essencial do negócio.
O Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec Zenith Blueprint salienta este ponto na fase ISMS Foundation & Leadership, Step 2, Stakeholder Needs and ISMS Scope:
“Se externalizar a sua infraestrutura de TI para um prestador de serviços cloud, isso não a exclui do âmbito; pelo contrário, deve incluir a gestão dessa relação e os ativos cloud como parte do âmbito (porque a segurança dos seus dados na cloud é uma responsabilidade sua).”
Esta afirmação é uma âncora de auditoria. O seu âmbito não deve dizer: “A AWS está excluída porque é gerida pela Amazon.” Deve dizer que os ativos de informação e os processos relacionados com serviços alojados na AWS estão no âmbito, incluindo a gestão dos controlos de segurança cloud, identidade, logging, cifragem, cópia de segurança, garantia de fornecedores e resposta a incidentes.
Para ISO 27001:2022, isto suporta as cláusulas 4.1 a 4.4 sobre contexto, partes interessadas, âmbito e processos do SGSI. Para NIS2, suporta as expectativas da Article 21 para análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e manutenção seguras, controlo de acesso, gestão de ativos, criptografia, eficácia dos controlos e MFA quando adequado. Para DORA, suporta o princípio de que as entidades financeiras continuam responsáveis pelo risco das TIC mesmo quando os serviços TIC são externalizados.
A questão não é saber se o seu prestador de serviços cloud é seguro. A questão é saber se governa a sua utilização do prestador, configura corretamente o seu lado, monitoriza o serviço, gere os compromissos dos fornecedores e retém evidência.
A responsabilidade partilhada deve tornar-se evidência partilhada
Os prestadores de serviços cloud explicam a responsabilidade partilhada. Os auditores testam se a operacionalizou.
Em IaaS, o prestador normalmente protege as instalações físicas, a infraestrutura essencial e o hipervisor. O cliente controla a identidade, a configuração das cargas de trabalho, o hardening do sistema operativo, a segurança das aplicações, a classificação de dados, as definições de cifragem, as regras de rede, o logging, as cópias de segurança, a aplicação de patches e a resposta a incidentes.
Em SaaS, o prestador controla a maioria das operações da plataforma, mas o cliente continua a controlar a configuração do tenant, utilizadores, funções administrativas, integrações, partilha de dados, retenção, opções de logging e procedimentos de escalonamento.
O Zenith Controls: guia de conformidade cruzada da Clarysec Zenith Controls trata o controlo ISO/IEC 27002:2022 5.23, Segurança da informação para a utilização de serviços cloud, como um controlo central de governação cloud com intenção preventiva sobre confidencialidade, integridade e disponibilidade. Liga os serviços cloud às relações com fornecedores, transferência segura de informação, inventário de ativos, prevenção de fuga de dados, segurança de endpoints e redes, e práticas de desenvolvimento seguro.
Uma interpretação-chave do Zenith Controls afirma:
“Os prestadores de serviços cloud (CSPs) funcionam como fornecedores críticos e, por isso, aplicam-se todos os controlos relativos à seleção, contratação e gestão de riscos de fornecedores previstos em 5.19. No entanto, 5.23 vai mais longe ao abordar riscos específicos da cloud, como multitenancy, transparência da localização dos dados e modelos de responsabilidade partilhada.”
Esta distinção é crítica. Certificados de fornecedores, por si só, não satisfazem o Anexo A.5.23. É necessária evidência do lado do cliente que prove que o serviço cloud é governado, configurado, monitorizado e revisto.
| Área de evidência | O que o auditor quer ver | Prova típica |
|---|---|---|
| Inventário cloud | Serviços SaaS, PaaS e IaaS aprovados são conhecidos | Registo de Serviços Cloud, lista de proprietários, tipos de dados, regiões, contratos |
| Responsabilidade partilhada | As responsabilidades do prestador e do cliente estão documentadas | Matriz de responsabilidades, documentação do prestador, mapeamento de controlos internos |
| Configuração de referência | As definições controladas pelo cliente seguem uma configuração de referência aprovada | Relatórios CSPM, exportações de secure score, verificações de políticas Terraform, capturas de ecrã |
| Identidade e acesso | O acesso administrativo e de utilizadores é controlado e revisto | Relatórios MFA, configuração SSO, revisão de funções privilegiadas, amostras de offboarding |
| Logging e monitorização | Logs cloud relevantes estão ativados, retidos e revistos | Integração SIEM, regras de alerta, definições de retenção de logs, tickets de incidentes |
| Compromissos dos fornecedores | Os contratos contêm cláusulas de segurança aplicáveis | DPA, SLA, direitos de auditoria, notificação de violação, termos de subcontratação |
| Continuidade e saída | Serviços críticos podem ser recuperados ou transitados | Testes de cópias de segurança, plano de saída, evidência de recuperação, revisão de risco de concentração |
| Preparação para incidentes | Incidentes cloud podem ser detetados, classificados e reportados | Playbooks, evidência de escalonamento, fluxo de notificação ao regulador |
Esta é a diferença entre ter controlos cloud e ter controlos cloud preparados para auditoria.
Comece com um Registo de Serviços Cloud que os auditores consigam utilizar
A forma mais rápida de melhorar a prontidão para auditoria cloud é criar um Registo de Serviços Cloud completo. Não deve ser uma lista de compras nem uma exportação financeira. Deve ligar os serviços cloud a dados, proprietários, regiões, acesso, contratos, criticidade, relevância regulamentar e evidência.
A Política de Utilização da Cloud para PME da Clarysec Cloud Usage Policy-sme fornece uma configuração de referência compacta e adequada a auditoria na cláusula 5.3:
“Deve ser mantido um Registo de Serviços Cloud pelo prestador de TI ou pelo Diretor-Geral. Deve registar: 5.3.1 O nome e a finalidade de cada serviço cloud aprovado 5.3.2 A pessoa ou equipa responsável (Proprietário da aplicação) 5.3.3 Os tipos de dados armazenados ou tratados 5.3.4 O país ou região onde os dados são armazenados 5.3.5 Permissões de acesso de utilizadores e contas administrativas 5.3.6 Detalhes contratuais, datas de renovação e contactos de suporte”
Para ambientes empresariais, a Política de Utilização da Cloud da Clarysec Cloud Usage Policy estabelece o mandato mais amplo:
“Esta política estabelece os requisitos obrigatórios da organização para a utilização segura, conforme e responsável de serviços de computação em cloud nos modelos de prestação Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) e Software-as-a-Service (SaaS).”
A Política de Utilização da Cloud exige um registo centralizado sob responsabilidade do CISO e configurações de referência aprovadas para ambientes cloud. Esse registo torna-se a base de evidência para várias obrigações em simultâneo.
Para ISO 27001:2022, suporta inventário de ativos, governação da utilização cloud, relações com fornecedores, controlo de acesso, requisitos legais e contratuais, tratamento de riscos e informação documentada. Para NIS2, suporta segurança da cadeia de fornecimento, gestão de ativos, análise de riscos, tratamento de incidentes e continuidade. Para DORA, suporta mapeamento de ativos e dependências TIC, registos de terceiros TIC, mapeamento de funções críticas ou importantes e análise de risco de concentração. Para RGPD da UE, identifica se são tratados dados pessoais, onde estão localizados, que prestador atua como subcontratante e que termos de transferência ou de tratamento de dados se aplicam.
Se o registo não identificar categorias de dados e regiões, a evidência de privacidade e resiliência ficará incompleta. Se não identificar Proprietários de aplicações, a revisão de acessos ficará sem responsável. Se não identificar contratos e datas de renovação, as cláusulas de segurança de fornecedores não poderão ser testadas.
Transforme a ISO 27001:2022 na espinha dorsal da evidência cloud
A ISO 27001:2022 é a melhor espinha dorsal para a evidência cloud porque liga contexto de negócio, risco, controlos, prova operacional, monitorização e melhoria.
Os principais requisitos ISO 27001:2022 relevantes para cloud incluem:
- Cláusulas 4.1 a 4.4 para contexto, partes interessadas, âmbito do SGSI, interfaces, dependências e processos.
- Cláusulas 5.1 a 5.3 para liderança, política, papéis, responsabilidades e responsabilização.
- Cláusulas 6.1.1 a 6.1.3 para avaliação de riscos, tratamento de riscos, comparação com o Anexo A, Declaração de Aplicabilidade e aceitação do risco residual.
- Cláusula 7.5 para informação documentada controlada.
- Cláusulas 8.1 a 8.3 para planeamento operacional, execução da avaliação de riscos e execução do tratamento de riscos.
- Cláusulas 9.1 a 9.3 para monitorização, medição, auditoria interna e revisão pela gestão.
- Cláusula 10 para não conformidade, ação corretiva e melhoria contínua.
Os controlos do Anexo A com maior peso na evidência cloud incluem A.5.19 Segurança da informação nas relações com fornecedores, A.5.20 Abordagem da segurança da informação nos acordos com fornecedores, A.5.21 Gestão da segurança da informação na cadeia de fornecimento das TIC, A.5.22 Monitorização, revisão e gestão de alterações dos serviços de fornecedores, A.5.23 Segurança da informação para utilização de serviços cloud, A.5.24 a A.5.27 gestão de incidentes, A.5.29 Segurança da informação durante perturbações, A.5.30 preparação das TIC para a continuidade de negócio, A.5.31 Requisitos legais, estatutários, regulamentares e contratuais, A.5.34 Privacidade e proteção de PII, A.5.36 Conformidade com políticas, regras e normas de segurança da informação, A.8.8 Gestão de vulnerabilidades técnicas, A.8.9 Gestão da configuração, A.8.13 Cópia de segurança da informação, A.8.15 Registo, A.8.16 Atividades de monitorização, A.8.24 Utilização de criptografia, A.8.25 Ciclo de vida de desenvolvimento seguro, A.8.29 Testes de segurança no desenvolvimento e aceitação, e A.8.32 Gestão de alterações.
No Zenith Blueprint, a fase Controls in Action, Step 23, explica os serviços cloud numa linguagem que ressoa com auditores:
“A transição para serviços cloud introduz alterações profundas no modelo de confiança. Deixa de controlar o servidor, o perímetro de rede ou o hipervisor. Muitas vezes, nem sequer sabe onde os dados residem fisicamente. O que controla, e o que este controlo impõe, é a governação dessa relação, a visibilidade sobre aquilo que utiliza e as expectativas de segurança que coloca nos seus prestadores.”
Uma entrada robusta da Declaração de Aplicabilidade para A.5.23 não deve dizer apenas “Aplicável, prestador cloud certificado.” Deve explicar por que razão o controlo se aplica, que riscos trata, como é implementado e onde a evidência é armazenada.
| Campo da SoA | Exemplo de conteúdo para A.5.23 |
|---|---|
| Aplicabilidade | Aplicável porque serviços críticos para o negócio operam em plataformas SaaS e IaaS |
| Justificação | Os serviços cloud tratam dados de clientes, dados de colaboradores e cargas de trabalho de produção |
| Riscos tratados | Configuração incorreta, acesso não autorizado, fuga de dados, falha do prestador, alteração de região, lacunas de logging |
| Estado de implementação | Registo cloud mantido, configurações de referência aprovadas, MFA imposto, logs integrados, revisões de fornecedores realizadas |
| Evidência | Registo cloud, relatórios de configuração, revisão de acessos, painéis SIEM, contrato com fornecedor, revisão de relatório SOC, teste de cópia de segurança |
| Mapeamento regulamentar | NIS2 Article 21, DORA Articles 28 to 30, RGPD da UE Articles 28 and 32, contratos com clientes |
| Proprietário | CISO para governação, Cloud Security Architect para configuração de referência, Proprietários de aplicações para controlos ao nível do serviço |
Adicione uma coluna de localização da evidência à SoA ou ao tracker de controlos. Os auditores não devem ter de pesquisar correio eletrónico, sistemas de tickets e unidades partilhadas para encontrar prova.
Utilize um único modelo de evidência para ISO 27001:2022, NIS2 e DORA
NIS2 e DORA exigem cibersegurança documentada, baseada no risco e liderada pela gestão. A sobreposição é substancial, mas a pressão supervisora é diferente.
A NIS2 aplica-se a muitas entidades essenciais e importantes na UE, incluindo prestadores de infraestrutura digital, prestadores de serviços geridos, prestadores de serviços de segurança geridos, banca, infraestruturas dos mercados financeiros e prestadores digitais. A Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionais, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e manutenção seguras, tratamento de vulnerabilidades, avaliação da eficácia dos controlos, higiene de cibersegurança, formação, criptografia, controlo de acesso, gestão de ativos e MFA ou comunicações seguras quando adequado.
Para evidência de auditoria de segurança cloud, a NIS2 pergunta se os riscos cloud e de fornecedores são geridos como parte do risco de prestação do serviço. Também introduz notificação estruturada de incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação de incidente no prazo de 72 horas e relatório final no prazo de um mês.
A DORA aplica-se desde 17 de janeiro de 2025 a muitas entidades financeiras da UE e cria requisitos uniformes para gestão do risco das TIC, reporte de incidentes TIC graves, testes de resiliência operacional digital, partilha de informação e risco de terceiros TIC. Para entidades financeiras também identificadas ao abrigo da NIS2, a DORA é tratada como o ato jurídico setorial da União para obrigações operacionais sobrepostas.
Para cloud, a DORA é direta. As entidades financeiras continuam responsáveis pelo risco das TIC quando os serviços são externalizados. Precisam de estratégias de terceiros TIC, registos contratuais, avaliações pré-contratuais, diligência prévia, direitos de auditoria e de acesso, gatilhos de cessação, análise de risco de concentração, controlos de subcontratação e estratégias de saída testadas.
O Zenith Controls mapeia o controlo ISO/IEC 27002:2022 5.23 para EU NIS2 Article 21 e DORA Articles 28 to 31. Também aponta para normas de apoio como ISO/IEC 27017 para papéis de segurança cloud e monitorização, ISO/IEC 27018 para proteção de PII em cloud pública, ISO/IEC 27701 para gestão de privacidade em relações com subcontratantes cloud, ISO/IEC 27036-4 para monitorização de serviços cloud e acordos com fornecedores, e ISO/IEC 27005 para avaliação de riscos cloud.
| Referencial | Cláusula ou artigo relevante | Como a evidência de A.5.23 ajuda |
|---|---|---|
| ISO 27001:2022 | Cláusulas 4, 6, 8, 9 e Anexo A.5.23 | Prova que a utilização cloud está no âmbito, é sujeita a avaliação de riscos, controlada, monitorizada, auditada e melhorada |
| NIS2 | Article 21 | Demonstra medidas proporcionais para segurança da cadeia de fornecimento, controlo de acesso, continuidade, tratamento de incidentes e gestão de ativos |
| DORA | Articles 28 to 31 | Apoia diligência prévia de terceiros TIC, contratos, monitorização, risco de concentração, planos de saída e supervisão |
| RGPD da UE | Articles 28 and 32 | Apoia governação de subcontratantes, segurança do tratamento, preparação para violações e responsabilização de privacidade cloud |
A implicação prática é simples. Não construa pacotes de evidência separados para ISO 27001:2022, NIS2, DORA e RGPD da UE. Construa uma única arquitetura de evidência cloud com mapeamentos específicos por referencial.
Contratos com fornecedores são evidência de controlo, não arquivos jurídicos
A evidência de auditoria cloud falha frequentemente na camada contratual. Segurança tem um questionário de fornecedor. Jurídico tem o MSA. Compras tem a data de renovação. O EPD tem o DPA. Ninguém tem uma visão única sobre se o acordo inclui as cláusulas de segurança exigidas por ISO 27001:2022, NIS2, DORA e RGPD da UE.
A Política de segurança de terceiros e fornecedores para PME da Clarysec Third-Party and Supplier Security Policy-sme declara na cláusula 5.3:
“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, dentro de 24–72 horas) 5.3.4 Direitos de auditoria ou disponibilidade de evidência de conformidade 5.3.5 Restrições à subcontratação adicional sem aprovação 5.3.6 Termos de cessação, incluindo devolução ou destruição segura de dados”
Para consistência de auditoria, traduza essas cláusulas numa matriz de revisão contratual. A ISO 27001:2022 Anexo A.5.20 espera que os requisitos de segurança sejam acordados com fornecedores. O RGPD da UE Article 28 exige termos de subcontratante que cubram confidencialidade, medidas de segurança, assistência, subcontratantes subsequentes, eliminação ou devolução de dados e apoio a auditoria. A DORA Article 30 exige disposições contratuais detalhadas para prestadores terceiros TIC, incluindo descrições de serviço, localização de dados, segurança, assistência em incidentes, cooperação com autoridades, direitos de auditoria, direitos de acesso, cessação e regimes de transição. A segurança da cadeia de fornecimento da NIS2 também exige cooperação aplicável dos fornecedores.
O Zenith Controls mapeia o controlo ISO/IEC 27002:2022 5.20 para acordos com fornecedores e assinala ligações a 5.19 relações com fornecedores, 5.14 transferência de informação, 5.22 monitorização de fornecedores, 5.11 devolução de ativos e 5.36 conformidade.
O ponto-chave é a operacionalização. Se um contrato cloud conceder acesso a relatórios SOC 2, os auditores podem perguntar se obteve o relatório, reviu exceções, acompanhou a remediação e reavaliou o risco. Se o contrato prometer notificação de violação, podem perguntar se o seu playbook de incidentes inclui a via de contacto com o fornecedor e os pontos de decisão regulamentar. Se alterações de subcontratantes exigirem aprovação ou aviso, podem perguntar se as notificações de subcontratantes subsequentes são revistas antes da aceitação.
Um contrato sem evidência de revisão é um arquivo. Um contrato ligado a risco de fornecedor, registos de monitorização e fluxos de trabalho de incidentes é um controlo.
Logging e configuração SaaS são pontos cegos comuns em auditoria
As constatações cloud surgem frequentemente de SaaS, não de IaaS. As equipas de infraestrutura normalmente têm proprietários de engenharia, pipelines de logging, controlos de referência e registos de alterações. As plataformas SaaS estão fragmentadas por vendas, Recursos Humanos, finanças, sucesso do cliente, marketing e operações. Cada uma pode tratar dados sensíveis ou regulados.
A Política de registo em logs e monitorização para PME da Clarysec Logging and Monitoring Policy-sme aborda isto diretamente na cláusula 5.5:
“5.5 Serviços cloud e registo de terceiros 5.5.1 Para plataformas em que o registo não está sob controlo direto de TI (por exemplo, correio eletrónico SaaS), aplicam-se os seguintes requisitos: 5.5.1.1 O registo deve ser ativado e configurado quando disponível 5.5.1.2 Os alertas devem ser encaminhados para o Prestador de Suporte de TI 5.5.1.3 Os contratos devem exigir que os prestadores retenham logs durante pelo menos 12 meses e disponibilizem acesso mediante pedido”
Para empresas, a Política de Utilização da Cloud acrescenta:
“Os serviços cloud devem ser integrados no SIEM da organização para monitorização contínua.”
Este requisito desloca SaaS de “ferramenta de negócio” para “sistema de informação monitorizado”. A evidência deve incluir exportações de definições de logging, prova de conector SIEM, regras de alerta, tickets de triagem, definições de retenção e revisão de acessos administrativos.
Para SaaS críticos, prepare evidência de criação de contas administrativas, autenticações suspeitas, transferências em massa, partilha pública, desativação de MFA, criação de tokens de API, atividade de convidados externos e elevação de privilégios. Para IaaS, prepare CloudTrail ou registo equivalente do plano de controlo, logs de acesso a armazenamento, alterações IAM, logs de fluxo quando adequado, constatações CSPM, análises de vulnerabilidades, evidência de patches, definições de cifragem, estado das cópias de segurança, revisões de grupos de segurança de rede e tickets de alteração.
A metodologia de auditoria do Zenith Controls para o controlo 5.23 observa que uma auditoria ao estilo ISO/IEC 27007 pode inspecionar permissões de buckets AWS S3, cifragem, políticas IAM e registo CloudTrail. Um auditor orientado por COBIT pode rever configurações de alertas, controlos DLP, utilização do Microsoft 365 Secure Score e logs de gestão de alterações. Uma perspetiva NIST SP 800-53A pode testar gestão de contas e monitorização, incluindo se as cargas de trabalho cloud são corrigidas, sujeitas a análise e monitorizadas com o mesmo rigor que os sistemas internos.
Auditores diferentes falam dialetos diferentes. A sua evidência deve ser a mesma.
Crie um pacote de evidência pronto para reguladores para um serviço SaaS e um serviço IaaS
Um fluxo de trabalho prático começa com uma plataforma SaaS crítica e um ambiente IaaS crítico. Por exemplo, Microsoft 365 para colaboração e AWS para alojamento de produção.
Passo 1: Atualizar o Registo de Serviços Cloud
Para Microsoft 365, registe finalidade, proprietário, tipos de dados, região, contas administrativas, contrato, DPA, contacto de suporte, data de renovação e criticidade. Para AWS, registe a conta de produção, regiões, categorias de dados, cargas de trabalho, proprietário da conta, estado da conta root, plano de suporte, termos contratuais e serviços de negócio associados.
Utilize os campos da Política de Utilização da Cloud para PME como conjunto mínimo de dados. Acrescente criticidade, relevância regulamentar e localização da evidência.
Passo 2: Documentar a responsabilidade partilhada
Para Microsoft 365, as responsabilidades do cliente incluem ciclo de vida dos utilizadores, MFA, acesso condicional, partilha com convidados, etiquetas de retenção, DLP quando utilizado, logging e escalonamento de incidentes. Para AWS, as responsabilidades do cliente incluem IAM, regras de rede, hardening de cargas de trabalho, configuração de cifragem, cópia de segurança, logging, aplicação de patches e segurança das aplicações.
Anexe a documentação de responsabilidade partilhada do prestador e mapeie cada responsabilidade do cliente para um proprietário de controlo e uma fonte de evidência.
Passo 3: Capturar evidência de configuração
Para Microsoft 365, exporte ou capture em ecrã políticas de MFA e acesso condicional, funções administrativas, definições de partilha externa, registo de auditoria, configuração de retenção e ações de security score. Para AWS, exporte a política de palavras-passe IAM, estado de MFA privilegiado, configuração CloudTrail, bloqueio de acesso público S3, estado de cifragem, revisão de grupos de segurança, tarefas de cópia de segurança e estado de análise de vulnerabilidades.
A Política de Utilização da Cloud exige que ambientes cloud cumpram uma configuração de referência documentada e aprovada pelo Cloud Security Architect. O seu pacote de evidência deve incluir tanto a configuração de referência como a prova de alinhamento.
| Requisito da política | Ação realizada | Evidência de auditoria gerada |
|---|---|---|
| MFA para acesso privilegiado | MFA imposto em contas administrativas e acesso à consola | Exportação da política MFA, amostra de conta privilegiada, revisão da conta de emergência break-glass |
| Registo de atividades | Logs de auditoria cloud ativados e encaminhados para o SIEM | Captura de CloudTrail ou log de auditoria SaaS, prova de ingestão SIEM, definição de retenção |
| Restrições de acesso | Funções de princípio do menor privilégio aplicadas e revisão de acessos trimestral | Exportação de função IAM, revisão de função administrativa, aprovação formal do proprietário dos dados |
| Configuração segura | Definições cloud avaliadas face à configuração de referência aprovada | Relatório CSPM, exportação de secure score, Registo de Exceções |
| Cópia de segurança e recuperação | Restauro testado para cargas de trabalho ou dados críticos | Estado da tarefa de cópia de segurança, registo de teste de restauro, lições aprendidas |
Passo 4: Ligar evidência de fornecedor e privacidade
Anexe o contrato, DPA, lista de subcontratantes subsequentes, termos de notificação de violação, relatórios de garantia de auditoria e evidência de localização dos dados. Se forem tratados dados pessoais, registe se o prestador atua como subcontratante, como é tratada a eliminação, como funciona o apoio a pedidos de titulares dos dados e que salvaguardas de transferência se aplicam.
Para DORA, identifique se o serviço cloud suporta uma função crítica ou importante. Se sim, ligue a evidência ao registo de terceiros TIC, ficheiro de diligência prévia, direitos de auditoria, plano de saída e revisão de risco de concentração.
Passo 5: Ligar o logging à resposta a incidentes
Mostre que os logs estão ativados, encaminhados, revistos e utilizados. Anexe painéis SIEM, regras de alerta e pelo menos um ticket de alerta encerrado. Depois mapeie o fluxo de trabalho para os pontos de decisão de reporte NIS2 e DORA.
Para NIS2, o processo de incidentes deve suportar alerta precoce em 24 horas, notificação de incidente em 72 horas e relatório final no prazo de um mês para incidentes significativos. Para DORA, o processo de incidentes TIC deve classificar incidentes por clientes afetados, transações, duração, indisponibilidade, dispersão geográfica, impacto nos dados, criticidade do serviço e impacto económico.
Passo 6: Armazenar evidência com disciplina
A Política de Auditoria e Monitorização da Conformidade para PME da Clarysec Audit and Compliance Monitoring Policy-sme, cláusula 6.2, define disciplina prática de evidência:
“6.2 Recolha e documentação de evidência 6.2.1 Toda a evidência deve ser armazenada numa pasta de auditoria centralizada. 6.2.2 Os nomes dos ficheiros devem referenciar claramente o tema da auditoria e a data. 6.2.3 Os metadados (por exemplo, quem recolheu, quando e a partir de que sistema) devem ser documentados. 6.2.4 A evidência deve ser retida durante pelo menos dois anos, ou mais quando exigido por certificação ou acordos com clientes.”
A Política de Auditoria e Monitorização da Conformidade empresarial Audit and Compliance Monitoring Policy declara o objetivo:
“Gerar evidência defensável e um rasto de auditoria em apoio a pedidos de esclarecimento regulamentares, processos legais ou pedidos de garantia por parte de clientes.”
Uma captura de ecrã chamada “screenshot1.png” é evidência fraca. Um ficheiro chamado “AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” é mais forte porque descreve o sistema, o controlo, a data e o coletor. Os metadados importam porque os auditores precisam de confiar em quando a evidência foi recolhida, por quem e a partir de que sistema.
Como os auditores testam o mesmo controlo cloud
Os pacotes de evidência cloud mais robustos são concebidos para várias lentes de auditoria. Auditores ISO 27001:2022 testam se o controlo está no SGSI, na avaliação de riscos, no tratamento de riscos e na SoA. Avaliadores orientados por NIST testam a implementação técnica. Auditores COBIT 2019 testam governação, desempenho de fornecedores e integração de processos. Auditores de privacidade focam-se em obrigações de subcontratantes, residência dos dados, preparação para violações e direitos dos titulares dos dados. Revisões supervisoras DORA focam-se no risco de terceiros TIC e na resiliência.
| Lente de auditoria | Pergunta provável de auditoria | Evidência a preparar |
|---|---|---|
| ISO 27001:2022 | Por que razão o controlo cloud é aplicável e como é implementado no SGSI? | Declaração de âmbito, Registo de Riscos, SoA, política cloud, registo, configuração de referência, registos de auditoria interna |
| Auditoria SGSI ao estilo ISO/IEC 27007 | A configuração e a documentação podem ser validadas através de entrevistas e amostras? | Capturas de ecrã, exportações, validação em modo só de leitura, entrevistas com proprietários cloud e SaaS |
| NIST SP 800-53A | Contas cloud, monitorização e serviços externos são controlados como sistemas internos? | Revisão IAM, registos do ciclo de vida das contas, logs SIEM, análises de vulnerabilidades, requisitos de serviços externos |
| COBIT 2019 | Os serviços de fornecedores são monitorizados, alterados e governados de acordo com o risco de negócio? | Atas de revisão de fornecedores, KPIs, KRIs, relatórios SLA, registos de alterações, reavaliações de risco |
| ISACA ITAF | A evidência é suficiente, fiável e retida para suportar conclusões? | Pasta de evidência centralizada, metadados, exportações de origem, trilhos de tickets, aprovações |
| Auditoria de privacidade e RGPD da UE | As obrigações de subcontratante e os controlos de dados pessoais estão operacionais na cloud? | DPA, SCC quando necessário, prova de residência dos dados, processo de eliminação, acesso ao log de violações, testes de restauro |
| Revisão supervisora DORA | A entidade financeira consegue provar supervisão e resiliência de terceiros TIC? | Registo de contratos TIC, mapeamento de funções críticas, estratégia de saída, revisão de risco de concentração, resultados de testes |
| Pedido de autoridade competente NIS2 | A entidade consegue demonstrar medidas de cibersegurança proporcionais e preparação para reporte de incidentes? | Mapeamento Article 21, playbook de incidentes, evidência de segurança de fornecedores, testes de continuidade, aprovação da gestão |
O Zenith Controls inclui estas diferenças de metodologia de auditoria para serviços cloud, acordos com fornecedores e monitorização de fornecedores. Para 5.22, Monitorização, revisão e gestão de alterações dos serviços de fornecedores, destaca que os auditores podem inspecionar atas trimestrais de revisão de fornecedores, relatórios KPI, avaliações de relatórios SOC, logs de alterações, avaliações de risco, incidentes de fornecedores e acompanhamento de issues. Para 5.20, Abordagem da segurança da informação nos acordos com fornecedores, destaca a amostragem contratual para confidencialidade, obrigações de segurança, notificação de violação, direitos de auditoria, aprovação de subcontratantes e termos de cessação.
Controlos de conformidade cruzada que suportam a carga da auditoria cloud
Um modelo de evidência cloud pronto para reguladores é construído em torno de um pequeno conjunto de controlos de elevado impacto. Estes controlos suportam grande parte da carga de conformidade em ISO 27001:2022, NIS2, DORA, RGPD da UE, NIST e COBIT 2019.
| Tema de controlo | Âncora ISO 27001:2022 | Relevância NIS2 | Relevância DORA | Relevância RGPD da UE |
|---|---|---|---|---|
| Governação cloud | A.5.23 | Article 21 medidas de risco cloud e de sistemas | Quadro de risco TIC e dependências de terceiros | Segurança do tratamento cloud e supervisão de subcontratantes |
| Acordos com fornecedores | A.5.20 | Segurança da cadeia de fornecimento e cooperação | Article 30 disposições contratuais | Article 28 contrato de subcontratante |
| Monitorização de fornecedores | A.5.22 | Gestão contínua de riscos | Monitorização contínua de terceiros TIC, KPIs e KRIs | Diligência prévia de subcontratantes e revisão de segurança |
| Logging e monitorização | A.8.15, A.8.16 | Deteção de incidentes e eficácia dos controlos | Deteção, classificação e reporte de incidentes TIC | Deteção de violações e responsabilização |
| Controlo de acesso e MFA | A.5.15, A.5.16, A.5.17, A.5.18 | Controlo de acesso e MFA quando adequado | Medidas de proteção e prevenção | Confidencialidade e integridade de dados pessoais |
| Cópia de segurança e resiliência | A.8.13, A.5.29, A.5.30 | Continuidade de negócio e gestão de crises | Continuidade, recuperação, cópia de segurança e restauro | Disponibilidade e resiliência do tratamento |
| Gestão de Incidentes | A.5.24, A.5.25, A.5.26, A.5.27 | Fluxo de reporte em 24 horas, 72 horas e final | Ciclo de vida de reporte inicial, intermédio e final | Avaliação e notificação de violação de dados pessoais |
| Obrigações legais e de privacidade | A.5.31, A.5.34 | Conformidade legal e regulamentar | Requisitos supervisores setoriais | Tratamento lícito, responsabilização e contratos Article 28 |
NIST SP 800-53 Rev.5 acrescenta profundidade técnica através de gestão de contas, serviços de sistemas externos, monitorização contínua, monitorização de sistemas e proteção de perímetro. COBIT 2019 acrescenta profundidade de governação através de gestão de relações com fornecedores, risco de fornecedor, troca de dados, segurança de rede e preparação para alterações.
Normas ISO de apoio tornam o modelo de evidência mais preciso. A ISO/IEC 27017 fornece orientação específica para cloud sobre papéis partilhados, configuração de máquinas virtuais e monitorização da atividade do cliente. A ISO/IEC 27018 foca-se na proteção de PII em cloud pública. A ISO/IEC 27701 alarga obrigações de privacidade às operações de subcontratantes e responsáveis pelo tratamento. A ISO/IEC 27036-4 apoia acordos com fornecedores cloud e monitorização. A ISO/IEC 27005 apoia a avaliação de riscos cloud.
A revisão pela gestão deve ver risco cloud, não apenas uptime cloud
Um dos artefactos de auditoria mais negligenciados é a revisão pela gestão. A ISO 27001:2022 espera que a revisão pela gestão considere alterações, necessidades de partes interessadas, tendências de desempenho, resultados de auditoria, estado do tratamento de riscos e oportunidades de melhoria. A NIS2 exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança e supervisionem a implementação. A DORA exige que o órgão de gestão defina, aprove, supervisione e permaneça responsável pela gestão do risco das TIC.
Um painel trimestral de segurança cloud e fornecedores deve mostrar:
- Número de serviços cloud aprovados.
- Serviços cloud críticos e respetivos proprietários.
- Serviços que tratam dados pessoais.
- Serviços que suportam funções críticas ou importantes.
- Configurações incorretas cloud de alto risco em aberto.
- Estado de MFA e revisão de acessos privilegiados.
- Cobertura de logging para plataformas SaaS e IaaS críticas.
- Relatórios de garantia de fornecedores recebidos e revistos.
- Exceções contratuais e riscos aceites.
- Incidentes cloud, quase-incidentes e lições aprendidas.
- Resultados de testes de cópia de segurança e recuperação.
- Estado do risco de concentração e do plano de saída.
Este painel torna-se evidência para liderança e avaliação de desempenho ISO 27001:2022, governação NIS2 e responsabilização da gestão DORA.
O Zenith Blueprint, na fase Risk Management, Step 14, recomenda fazer referências cruzadas aos requisitos regulamentares ao implementar tratamentos de risco e políticas. Afirma que mapear requisitos regulamentares-chave para controlos do SGSI é um exercício interno útil e “também impressiona auditores/avaliadores, porque mostra que não está a gerir a segurança no vazio, mas consciente do contexto jurídico.”
Essa é a maturidade que reguladores e clientes empresariais esperam.
Constatações comuns em auditorias cloud e como evitá-las
No trabalho de preparação para auditoria cloud, as constatações recorrentes são previsíveis:
- O Registo de Serviços Cloud existe, mas faltam ferramentas SaaS.
- A localização dos dados não é registada ou é copiada de páginas de marketing em vez de evidência contratual.
- A MFA é imposta para colaboradores, mas não para todas as contas administrativas ou break-glass.
- Logs cloud estão ativados, mas não são revistos, retidos ou ligados à resposta a incidentes.
- Relatórios SOC de fornecedores são arquivados, mas não avaliados.
- Existem cláusulas contratuais para novos fornecedores, mas não para serviços críticos legados.
- Notificações de subcontratantes subsequentes são recebidas por correio eletrónico, mas não são sujeitas a avaliação de risco.
- Tarefas de cópia de segurança são executadas com sucesso, mas os testes de recuperação não são evidenciados.
- A responsabilidade partilhada é compreendida pelos engenheiros, mas não documentada para auditores.
- A SoA assinala controlos cloud como aplicáveis, mas não os liga a entradas de risco, evidência ou proprietários.
Estes são problemas de rastreabilidade. A correção é ligar política, risco, controlo, proprietário, evidência e revisão.
Quando Maria chegou ao dia da auditoria, já não dependia de capturas de ecrã dispersas. Abriu um painel central que mostrava o Registo de Serviços Cloud, avaliações de riscos, entradas da SoA, evidência de configuração de referência, ficheiros de revisão de fornecedores, prova de logging e revisão de risco de concentração DORA. Quando o auditor perguntou como eram governados os riscos cloud, ela mostrou o SGSI. Quando o auditor perguntou como os serviços eram configurados de forma segura, ela mostrou a configuração de referência e a evidência CSPM. Quando o auditor perguntou sobre risco de terceiros TIC, ela mostrou a revisão contratual, a monitorização de fornecedores e o planeamento de saída.
O resultado não foi um ambiente perfeito. Nenhum ambiente cloud é perfeito. A diferença foi que as decisões de risco estavam documentadas, a evidência era defensável e a responsabilização era visível.
Construa o seu pacote de evidência cloud antes de o auditor pedir
Se a sua organização depende de SaaS, IaaS ou PaaS, a sua próxima auditoria não aceitará “o prestador trata disso” como resposta suficiente. Tem de provar responsabilidade partilhada, configuração do lado do cliente, cláusulas de fornecedores, logging, preparação para incidentes, resiliência e supervisão da gestão.
Comece com três ações práticas esta semana:
- Crie ou atualize o seu Registo de Serviços Cloud utilizando a Política de Utilização da Cloud da Clarysec Cloud Usage Policy ou a Política de Utilização da Cloud para PME Cloud Usage Policy-sme.
- Mapeie os seus cinco principais serviços cloud para controlos do Anexo A da ISO 27001:2022, NIS2 Article 21, obrigações de terceiros TIC da DORA quando aplicável, e requisitos de subcontratante do RGPD da UE.
- Crie uma pasta centralizada de evidência utilizando a disciplina de retenção e metadados da Política de Auditoria e Monitorização da Conformidade Audit and Compliance Monitoring Policy ou da Política de Auditoria e Monitorização da Conformidade para PME Audit and Compliance Monitoring Policy-sme.
Depois utilize o Zenith Blueprint Zenith Blueprint para colocar o trabalho no roteiro de auditoria SGSI em 30 passos, e o Zenith Controls Zenith Controls para validar mapeamentos de conformidade cruzada, normas ISO de apoio e expectativas de metodologia de auditoria.
A Clarysec pode ajudá-lo a transformar capturas de ecrã cloud dispersas, ficheiros de fornecedores e definições SaaS num pacote de evidência pronto para reguladores que resiste a auditorias de certificação ISO 27001:2022, questões supervisoras NIS2, revisões de terceiros TIC DORA e exigências de garantia de clientes empresariais.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
