Matriz de responsabilidade partilhada na cloud para ISO, NIS2 e DORA

O COO de uma fintech telefona ao CISO às 07:15 de uma segunda-feira.

Um cliente bancário europeu está a solicitar evidência de que a plataforma SaaS da empresa consegue cumprir os requisitos de DORA relativos ao risco de terceiros de TIC. A equipa comercial já enviou o pacote habitual de segurança de fornecedores: certificado ISO, resumo executivo do teste de intrusão, certificado de seguro cibernético, aviso de privacidade e relatório de garantia do prestador de serviços cloud.

O banco responde com uma pergunta mais incisiva:

“Mostrem-nos quem é responsável por cada controlo no vosso ambiente cloud. Vocês, o vosso prestador de serviços cloud, o vosso prestador de base de dados gerida, o vosso fornecedor de identidade, o vosso fornecedor de registo de eventos e quaisquer subcontratantes ulteriores. Depois mostrem a evidência.”

Mais tarde, nessa manhã, o CISO tem uma reunião com o conselho de administração. O CEO colocará a mesma questão em linguagem de negócio: “Temos a certeza de que esta plataforma é segura, e quem é responsável se algo correr mal?”

É aqui que muitos programas de conformidade cloud bloqueiam.

A organização pode ter um prestador de serviços cloud robusto, boas ferramentas, políticas razoáveis e um Registo de Riscos. Porém, quando lhe é pedido que comprove os limites de responsabilidade, a evidência encontra-se dispersa. Compras tem os contratos. O departamento jurídico tem o Acordo de Tratamento de Dados. Engenharia tem os diagramas de arquitetura. Segurança tem logs e configurações cloud. Privacidade tem a lista de subcontratantes ulteriores. Conformidade tem a Declaração de Aplicabilidade. Ninguém tem um artefacto único e controlado que indique, controlo a controlo, o que o prestador faz, o que o cliente deve configurar, que subcontratante ulterior está envolvido, que cláusula torna a obrigação exigível e que evidência um auditor deve esperar.

Esse artefacto é a matriz de responsabilidade partilhada na cloud.

Não é o slide genérico do hyperscaler que diz que o prestador protege a cloud e que o cliente protege o que está na cloud. Uma verdadeira matriz de responsabilidade partilhada na cloud para ISO/IEC 27001:2022, NIS2, DORA e RGPD da UE é um registo de governação. Resiste à diligência prévia de clientes, a uma auditoria ISO, a uma revisão DORA, a um desafio de responsabilização ao abrigo do RGPD da UE e a uma investigação de incidente.

Porque é que a responsabilidade partilhada na cloud se torna um problema de auditoria

O modelo de responsabilidade partilhada é geralmente ensinado como uma fronteira técnica. Em IaaS, o prestador gere as instalações físicas, o hardware, a virtualização e a infraestrutura essencial. O cliente gere identidades, dados, cargas de trabalho, regras de rede, opções de cifragem e configurações. Em SaaS, o prestador assume mais responsabilidade operacional, mas o cliente continua a ser responsável pelo acesso de utilizadores, pela governação de dados, pelo fundamento de licitude, pela configuração, pelas expectativas de monitorização e pelo escalonamento de incidentes.

Essa explicação é útil, mas incompleta.

Auditores, reguladores e clientes empresariais perguntam mais do que “quem opera o controlo?”. Querem saber:

• Quem é responsável pelo risco?
• Que cláusula contratual torna essa responsabilização exigível?
• Que política exige o controlo?
• Que serviço cloud, plataforma SaaS ou subcontratante ulterior está no âmbito?
• Que evidência comprova que o controlo operou durante o período em análise?
• Que requisito do referencial é satisfeito pela evidência?
• O que acontece se o prestador alterar o seu serviço, localização, subcontratado ou postura de controlos?

A ISO/IEC 27001:2022 ISO/IEC 27001:2022 transforma isto numa questão de sistema de gestão. As cláusulas 4.1 a 4.4 exigem que a organização compreenda questões internas e externas, partes interessadas, obrigações legais e contratuais, âmbito do SGSI, interfaces e dependências. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos, aprovação pelo proprietário do risco, aceitação do risco residual e uma Declaração de Aplicabilidade. A cláusula 8.1 exige planeamento e controlo operacional, incluindo o controlo de processos, produtos e serviços fornecidos externamente que sejam relevantes para o SGSI.

Em termos simples, se um prestador de serviços cloud, fornecedor SaaS ou subcontratante ulterior suporta um processo de negócio dentro do âmbito, não pode ficar fora do SGSI. Deve estar visível no âmbito, no risco, no tratamento, no controlo contratual e na evidência.

NIS2 eleva a exigência. O Article 21 exige que entidades essenciais e importantes implementem medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade, segurança da cadeia de fornecimento, aquisição segura, desenvolvimento seguro, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e autenticação multifator ou autenticação contínua quando adequado. O Article 20 atribui responsabilidade de governação aos órgãos de gestão.

DORA é ainda mais explícito para entidades financeiras. Aplica-se a partir de 17 de janeiro de 2025 e exige que as entidades financeiras façam a gestão do risco de TIC, do reporte de incidentes graves relacionados com TIC, dos testes de resiliência operacional digital e do risco de terceiros de TIC. Os Articles 28 a 30 exigem gestão do risco de terceiros de TIC, avaliação preliminar do risco de concentração, salvaguardas contratuais, direitos de auditoria e de acesso, visibilidade sobre subcontratação, direitos de cessação e estratégias de saída.

O RGPD da UE acrescenta o teste da responsabilização. O Article 5 exige que os dados pessoais sejam tratados com integridade e confidencialidade, e o Article 5(2) exige que o responsável pelo tratamento consiga demonstrar conformidade. O Article 28 regula contratos com subcontratantes e subcontratantes ulteriores. O Article 32 exige segurança do tratamento. Os Articles 33 e 34 exigem notificação de violação de dados pessoais quando aplicável.

A matriz de responsabilidade partilhada na cloud torna-se a ponte entre estas obrigações.

A definição da Clarysec: um artefacto de governação, não um diagrama

Nos projetos da Clarysec, uma matriz de responsabilidade partilhada na cloud é um registo controlado do SGSI que liga serviços cloud, fornecedores, subcontratantes ulteriores, controlos, políticas, obrigações contratuais, evidência e expectativas de auditoria.

A explicação mais forte aparece em Zenith Blueprint Zenith Blueprint, na fase Controls in Action, Step 23:

“Os prestadores de serviços cloud protegem a infraestrutura, mas a sua organização continua responsável pelos seus dados, pelas suas configurações, pelas suas políticas de acesso e pela sua preparação para resposta a incidentes.”

O mesmo passo explica que a utilização da cloud deve ser tratada como parte do SGSI, incluindo a classificação dos serviços cloud, a compreensão dos dados tratados ou armazenados, a avaliação do prestador, as cláusulas contratuais e a gestão de alterações ao serviço. Isto converte a responsabilidade partilhada de um conceito numa estrutura de controlos rastreável.

Zenith Controls Zenith Controls trata os controlos do Anexo A da ISO/IEC 27001:2022 e as orientações 5.20, 5.21 e 5.23 da ISO/IEC 27002:2022 como âncoras centrais:

• 5.20, abordagem da segurança da informação nos acordos com fornecedores.
• 5.21, gestão da segurança da informação na cadeia de fornecimento de TIC.
• 5.23, segurança da informação na utilização de serviços cloud.

Estes não são itens isolados de uma lista de verificação. Definem a espinha dorsal da matriz.

Normas de suporte podem reforçar a matriz. ISO/IEC 27017 ajuda com práticas de segurança específicas da cloud. ISO/IEC 27018 e ISO/IEC 27701 apoiam a governação de PII e de privacidade. ISO/IEC 27005 apoia a avaliação de riscos. ISO 22301 apoia a continuidade e a resiliência. ISO/IEC 27035 apoia a gestão de incidentes. ISO/IEC 20000-1 pode ajudar quando serviços cloud fazem parte de uma prestação de serviços geridos.

A matriz mínima viável de responsabilidade partilhada

Uma matriz madura não começa com 200 linhas. Começa pelos serviços cloud que mais importam.

Para uma SaaS, fintech ou PME regulada, a Clarysec começa normalmente por:

1. Ambiente cloud de produção orientado para o cliente.
2. Fornecedor de identidade.
3. Serviço gerido de base de dados ou armazenamento.
4. Plataforma de registo de eventos, monitorização e SIEM.
5. SaaS de pagamentos, KYC, análise ou suporte ao cliente.
6. Serviço de cópias de segurança e recuperação de desastre.
7. Prestador de serviços geridos ou prestador de serviços de segurança geridos.
8. Subcontratantes ulteriores que acedem, armazenam ou tratam dados de clientes.

A primeira matriz deve incluir as seguintes colunas.

Uma linha prática de registo de eventos poderia ter este aspeto.

Essa linha não é apenas documentação. Diz à Segurança o que configurar, a Compras que linguagem contratual verificar, à Privacidade que fluxo de dados registar e aos auditores que evidência solicitar.

Base de políticas: transformar a matriz num requisito exigível

Uma matriz de responsabilidade partilhada na cloud sem suporte em políticas é apenas uma folha de cálculo. As políticas da Clarysec tornam-na exigível.

Para PME, Política de Utilização da Cloud - PME Política de Utilização da Cloud - PME, secção “Requisitos de governação”, cláusula 5.3, exige:

“Deve ser mantido um Registo de Serviços Cloud pelo prestador de TI ou pelo Diretor-Geral. Deve registar:”

A mesma política para PME, cláusula 5.2.3, liga a governação da cloud ao risco de privacidade e localização:

“A residência dos dados e as práticas de privacidade cumprem os requisitos legais aplicáveis (por exemplo, RGPD da UE)”

Para ambientes empresariais, Política de Utilização da Cloud Política de Utilização da Cloud, secção “Requisitos de governação”, cláusula 5.1, estabelece:

“A organização deve manter um Registo de Serviços Cloud centralizado, sob responsabilidade do CISO, contendo:”

A cláusula 5.4 torna então as responsabilidades cloud contratualmente exigíveis:

“Todos os contratos com CSP (Cloud Service Provider) devem incluir disposições exigíveis para:”

A governação de fornecedores estende a matriz para além do prestador imediato. Política de segurança de terceiros e fornecedores - PME Política de segurança de terceiros e fornecedores - PME, secção “Requisitos de governação”, cláusula 5.3.5, exige:

“Restrições a subcontratação adicional sem aprovação”

A mesma política de fornecedores para PME, secção “Requisitos de implementação da política”, cláusula 6.3.1, acrescenta a revisão periódica:

“Fornecedores críticos ou de alto risco devem ser revistos pelo menos anualmente. A revisão deve verificar:”

Ao nível empresarial, Política de segurança de terceiros e fornecedores Política de segurança de terceiros e fornecedores, secção “Requisitos de governação”, cláusula 5.3, estabelece:

“Os contratos com fornecedores devem incluir:”

Para dados pessoais, Política de proteção de dados e privacidade Política de proteção de dados e privacidade, secção “Aplicação e cumprimento”, cláusula 8.5.1, exige:

“Os contratos com subcontratantes devem incluir:”

Para visibilidade de dependências, Política de Gestão do Risco de Dependência de Fornecedores Política de Gestão do Risco de Dependência de Fornecedores, cláusula 6.5.4, exige:

“Utilizar a relação com o fornecedor para obter atualizações sobre subcontratados ou dependências da cadeia de fornecimento um nível a jusante quando possam afetar-nos (por exemplo, se um fornecedor crítico de software depender fortemente de uma biblioteca de terceiros, isso deve ser registado).”

Para logs, Política de registo de eventos e monitorização - PME Política de registo de eventos e monitorização - PME, secção “Requisitos de governação”, cláusula 5.5.1.3, estabelece um requisito contratual concreto:

“Os contratos devem exigir que os prestadores retenham logs durante pelo menos 12 meses e forneçam acesso mediante pedido”

Em conjunto, estas políticas tornam a matriz um registo de governação obrigatório que suporta a aprovação de fornecedores, a integração na cloud, a responsabilização em matéria de privacidade, a revisão anual e a evidência de auditoria.

Mapeamento da matriz em ISO/IEC 27001:2022, NIS2, DORA e RGPD da UE

O erro clássico é criar quatro dossiês de conformidade separados. Um controlo pode satisfazer várias obrigações se a responsabilidade e a evidência forem rastreáveis.

A ISO/IEC 27001:2022 fornece o motor do SGSI: contexto, partes interessadas, âmbito, liderança, tratamento de riscos, objetivos, controlo operacional, avaliação de desempenho e melhoria. O Anexo A fornece a estrutura prática de controlos.

NIS2 Article 21 mapeia naturalmente para a mesma matriz através da segurança da cadeia de fornecimento, tratamento de incidentes, continuidade, controlo de acesso, gestão de ativos e aquisição segura. O Article 20 torna a matriz relevante para o conselho de administração porque os órgãos de gestão devem aprovar e supervisionar as medidas de gestão de riscos de cibersegurança.

DORA transforma a matriz numa ferramenta de risco de terceiros de TIC. Os Articles 5, 6 e 8 exigem governação, gestão documentada do risco de TIC e identificação de ativos, funções e dependências. Os Articles 17 a 19 exigem deteção, classificação, escalonamento, comunicação e reporte de incidentes. Os Articles 28 a 30 exigem gestão de risco de terceiros, análise de risco de concentração, cláusulas contratuais, controlos de subcontratação, direitos de auditoria, direitos de cessação e estratégias de saída.

O RGPD da UE acrescenta a perspetiva dos dados pessoais. Cada linha de serviço cloud deve identificar se são tratados dados pessoais, se o prestador é subcontratante ou subcontratante ulterior, se a localização dos dados é relevante e que evidência contratual ou de Acordo de Tratamento de Dados existe.

O NIST CSF 2.0 ajuda a comunicar a mesma matriz em linguagem de resultados. A função GOVERN aborda o contexto organizacional, os requisitos legais e regulamentares, dependências, gestão de riscos, funções, políticas e supervisão. Os resultados GV.SC são especialmente úteis para risco cibernético de fornecedores, incluindo funções dos fornecedores, criticidade, requisitos contratuais, diligência prévia, monitorização, coordenação de incidentes e planeamento de cessação.

COBIT 2019 acrescenta uma perspetiva de garantia e governação. Pergunta se a responsabilização, as práticas de gestão, a titularidade, a monitorização e a remediação de problemas são repetíveis e evidenciadas.

Construir a matriz do registo à prova

Imagine uma empresa SaaS que utiliza uma plataforma IaaS hyperscale, uma base de dados gerida, um fornecedor de identidade terceiro, uma plataforma SaaS de suporte ao cliente e um SIEM externo. O fluxo de implementação é direto.

Passo 1: começar pelo Registo de Serviços Cloud

Utilize a Política de Utilização da Cloud ou a Política de Utilização da Cloud - PME como desencadeador. Registe cada serviço cloud, proprietário, finalidade, categorias de dados, localização, função de negócio, nível do fornecedor, responsável pelo contrato e data de revisão.

Se o serviço armazenar registos de clientes, logs de autenticação ou tickets de suporte, marque-o como relevante para a privacidade. Se suportar a disponibilidade de produção, marque-o como operacionalmente crítico. Se suportar uma função crítica ou importante de um cliente financeiro, marque-o como relevante para DORA.

Passo 2: adicionar domínios de responsabilidade partilhada

Para cada serviço, defina responsabilidades nos domínios essenciais.

Passo 3: ligar controlos ao risco e à Declaração de Aplicabilidade

Zenith Blueprint, fase Risk Management, Step 13, explica o requisito de rastreabilidade:

“Cruzar regulamentos: se determinados controlos forem implementados especificamente para cumprir o RGPD da UE, NIS2 ou DORA, pode assinalá-lo no Registo de Riscos (como parte da justificação do impacto do risco) ou nas notas da SoA.”

Por exemplo, o risco “acesso não autorizado a dados de produção de clientes por configuração incorreta da cloud” pode mapear para controlo de acesso, utilização da cloud, registo de eventos, criptografia, gestão de vulnerabilidades e acordos com fornecedores. A SoA pode referenciar ISO/IEC 27001:2022 Anexo A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 e 8.24, com notas para RGPD da UE Article 32, NIS2 Article 21 e gestão do risco de TIC DORA quando aplicável.

Passo 4: anexar evidência antes da época de auditorias

A evidência deve ser desenhada na matriz, não recolhida em pânico.

A lista de evidência transforma responsabilidade em prova. Também ajuda as equipas comerciais a responder mais rapidamente à diligência prévia empresarial, porque podem mostrar não só certificações, mas também titularidade de controlos e evidência operacional.

Subcontratantes ulteriores: o ponto cego da maioria das matrizes

Os subcontratantes ulteriores são onde a responsabilidade partilhada se transforma em verdadeiro risco da cadeia de fornecimento.

Um prestador SaaS pode ser o seu subcontratante ao abrigo do RGPD da UE. Esse prestador pode depender de um prestador de alojamento cloud, CDN, serviço de análise, plataforma de suporte, serviço de envio de correio eletrónico, base de dados gerida, prestador de observabilidade e processador de pagamentos. Alguns podem aceder a dados pessoais. Alguns podem suportar a prestação de serviços críticos sem visualizar diretamente os dados. Alguns podem estar fora da UE. Alguns podem ser substituíveis. Outros podem criar risco de concentração.

O DORA Article 29 exige avaliação do risco de concentração para serviços de TIC críticos ou importantes, incluindo grau de substituibilidade, múltiplos acordos com o mesmo prestador ou com prestadores ligados, cadeias de subcontratação, subcontratados de países terceiros, direito da insolvência, restrições à recuperação de dados e exigibilidade da proteção de dados da União. O DORA Article 30 exige disposições contratuais sobre condições de subcontratação, localizações, tratamento e armazenamento de dados, acesso e recuperação, assistência em incidentes, cooperação com autoridades, direitos de auditoria, cessação e saída.

O NIS2 Article 21 exige igualmente segurança da cadeia de fornecimento para fornecedores diretos e prestadores de serviços, incluindo a consideração de vulnerabilidades específicas do fornecedor, práticas de cibersegurança do fornecedor e procedimentos de desenvolvimento seguro.

É por isso que a Clarysec trata o mapeamento de subcontratantes ulteriores como uma extensão obrigatória da governação de fornecedores, e não apenas como uma lista de privacidade. O registo de subcontratantes ulteriores deve indicar que fornecedor utiliza o subcontratante ulterior, de que serviço depende, se são tratados dados pessoais, se suporta uma função crítica, a região de tratamento quando relevante, as obrigações contratuais em cadeia, direitos de aprovação ou oposição, garantia disponível, método de monitorização e opção de saída.

Zenith Blueprint, fase Controls in Action, Step 23, estabelece:

“Para cada fornecedor crítico, identifique se utiliza subcontratados (subcontratantes ulteriores) que possam aceder aos seus dados ou sistemas. Documente como os seus requisitos de segurança da informação são repercutidos para essas partes, seja através dos termos contratuais do seu fornecedor, seja através das suas próprias cláusulas diretas.”

Esse é o nível de prova que os auditores esperam quando perguntam se as responsabilidades cloud são controladas a jusante.

Como os auditores testam a mesma matriz

Uma matriz de responsabilidade partilhada na cloud robusta resiste a múltiplos estilos de auditoria porque é construída em torno de titularidade, exigibilidade e evidência.

A matriz não é o objetivo final. É o mapa que os auditores utilizam para testar se o sistema de governação é real.

Um auditor ISO pode selecionar um risco de acesso cloud de alto impacto e rastreá-lo do Registo de Riscos à SoA, e depois para revisões de acessos, evidência MFA e alertas de monitorização. Um avaliador DORA pode selecionar um prestador crítico de TIC e solicitar o teste de saída, a análise de subcontratação e os direitos contratuais de auditoria. Um revisor RGPD da UE pode focar-se na eliminação, residência dos dados, notificação de violação de dados pessoais e transparência de subcontratantes ulteriores.

Padrões comuns de falha

As falhas mais frequentes de responsabilidade partilhada não são exóticas.

Primeiro, as organizações dependem de relatórios de garantia do prestador sem os mapear para as responsabilidades do cliente. Um prestador cloud pode comprovar segurança física, resiliência de infraestrutura e controlos da plataforma, mas não se o seu bucket de armazenamento estava privado, se as funções IAM seguiam o princípio do menor privilégio ou se os logs estavam ativados.

Segundo, os contratos contêm linguagem genérica de segurança, mas não têm prazos de incidentes, direitos de acesso a logs, direitos de auditoria, limites de subcontratação, disposições de devolução de dados ou suporte à saída. Zenith Blueprint, fase Controls in Action, Step 23, destaca áreas típicas de acordos com fornecedores, como confidencialidade, controlo de acesso, medidas técnicas e organizativas, prazos de incidentes, direito de auditoria, controlos de subcontratados e disposições de fim de contrato.

Terceiro, os subcontratantes ulteriores são listados para fins de privacidade, mas não ligados à segurança, continuidade ou risco de concentração. Um prestador de observabilidade ou suporte a jusante pode nunca aparecer no Registo de Riscos, embora a sua indisponibilidade ou violação de dados possa afetar a prestação de serviço ao cliente.

Quarto, a SoA diz que um controlo é aplicável, mas ninguém consegue produzir evidência operacional. O registo de eventos na cloud pode estar marcado como implementado, mas a organização não consegue comprovar definições de retenção, revisões de acessos, tratamento de alertas ou compromissos do prestador quanto ao acesso a logs.

Quinto, os planos de resposta a incidentes não refletem a dependência do prestador. Se o prestador notificar um incidente da plataforma, quem avalia o impacto no cliente? Quem determina se é necessária uma notificação ao abrigo de NIS2, DORA ou RGPD da UE? Quem contacta os clientes afetados? E se a causa raiz estiver num subcontratante ulterior?

Responsabilização da gestão: porque é que o conselho de administração deve preocupar-se

O NIS2 Article 20 exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança, supervisionem a implementação e recebam formação. O DORA Article 5 exige que o órgão de gestão defina, aprove, supervisione e seja responsável pelos regimes de gestão do risco de TIC, incluindo políticas de terceiros de TIC, planos de continuidade e recuperação, planos de auditoria, formação e canais de reporte.

Isto altera o propósito da matriz. Já não é apenas uma folha de trabalho de segurança. Torna-se evidência de que a gestão sabe:

• Que serviços cloud suportam operações críticas.
• Que terceiros e subcontratantes ulteriores são materiais.
• Que obrigações se aplicam ao abrigo de contratos com clientes, RGPD da UE, NIS2 e DORA.
• Que responsabilidades são retidas pela organização.
• Que compromissos do prestador são contratualmente exigíveis.
• Que lacunas exigem financiamento, remediação ou aceitação do risco.

Para PME, a proporcionalidade é relevante. Uma entidade mais pequena não precisa de burocracia pesada, mas continua a precisar de documentação, monitorização, sistemas resilientes, deteção de fontes de risco de TIC, identificação de dependências-chave de terceiros, medidas de continuidade, testes, lições aprendidas e revisão periódica quando estiver no âmbito.

A matriz é uma das ferramentas proporcionais mais eficientes porque consolida obrigações em vez de as multiplicar.

Um sprint de 30 dias para preparar o seu modelo cloud para auditoria

Se não consegue responder quem é responsável por cada controlo cloud, que evidência o comprova e que subcontratante ulterior o pode afetar, o seu modelo de responsabilidade partilhada ainda é um diagrama, não um artefacto de governação.

Um sprint prático de 30 dias é o seguinte:

1. Criar ou atualizar o Registo de Serviços Cloud utilizando a Política de Utilização da Cloud ou a Política de Utilização da Cloud - PME.
2. Identificar serviços críticos, tratamento de dados pessoais, sistemas orientados para o cliente e relevância para DORA ou NIS2.
3. Construir a primeira matriz em torno dos controlos 5.20, 5.21 e 5.23 do Anexo A da ISO/IEC 27001:2022 utilizando Zenith Controls.
4. Ligar cada linha ao Registo de Riscos e à Declaração de Aplicabilidade utilizando o Step 13 de Zenith Blueprint.
5. Validar cláusulas de fornecedores e subcontratantes utilizando a Política de segurança de terceiros e fornecedores, a Política de segurança de terceiros e fornecedores - PME e a Política de proteção de dados e privacidade.
6. Acrescentar evidência de retenção de logs, escalonamento de incidentes, aprovação de subcontratantes ulteriores, direitos de auditoria e saída.
7. Rever fornecedores críticos anualmente, bem como após alterações relevantes, incidentes, novos subcontratantes ulteriores ou constatações de auditoria.

O objetivo é simples. Quando o cliente, auditor, regulador ou conselho de administração pergunta “quem é responsável por este controlo?”, não procura em contratos, tickets e pastas. Abre a matriz, mostra o proprietário, mostra a cláusula, mostra a evidência e mostra o trilho a jusante.

A Clarysec pode ajudá-lo a transformar pacotes de garantia de prestadores cloud numa matriz integrada de responsabilidade partilhada para auditorias ISO/IEC 27001:2022, preparação NIS2, risco de terceiros de TIC DORA, responsabilização ao abrigo do RGPD da UE e diligência prévia de clientes empresariais.

Comece pelo registo. Construa a matriz. Anexe a evidência. Depois utilize-a como a sua prova para o conselho de administração de que o risco cloud não é externalizado; é governado.