Contratacao de nuvem em setor regulado

A responsabilidade não vai para a nuvem junto com a carga

Mover carga para a nuvem transfere a operação, não a responsabilidade regulatória — ela permanece inteira com a instituição contratante. Essa assimetria é a origem de praticamente todo problema prático do tema: o regulador escreve a exigência endereçada à instituição, o provedor escreve o contrato endereçado ao seu próprio modelo de serviço, e entre as duas peças existe uma tradução que quase nunca é feita.

Este artigo faz essa tradução. Ele não repete o processo de avaliação e monitoramento de fornecedores, tratado em Gestão de risco de terceiros (TPRM) na prática para a TI, nem a negociação de disponibilidade e desempenho, tratada em SLA de cloud: o que negociar e como monitorar. O que ele acrescenta é específico: a matriz que converte cada controle de segurança cibernética exigido no setor financeiro brasileiro em cláusula contratual verificável e em evidência apresentável — a peça que falta entre o programa de TPRM, que diz como avaliar fornecedores, e a auditoria, que pergunta mostre o documento.

Responsabilidade compartilhada não é responsabilidade transferida

O modelo de responsabilidade compartilhada divide quem cuida do quê, não quem responde perante quem. Na formulação corrente de mercado, o provedor responde pela segurança da nuvem — instalações, hardware, camada de virtualização — e o cliente responde pela segurança na nuvem: configuração, identidade, dado, criptografia e acesso. Essa divisão é técnica e útil, e é frequentemente lida como se fosse também uma divisão de responsabilidade regulatória. Não é.

A consequência operacional aparece no pior momento possível: quando o regulador ou o auditor pergunta, o interlocutor é sempre a instituição. Ela não pode responder que o controle é do provedor; precisa demonstrar que o controle existe, que está contratado e que há evidência de que funciona. Por isso a pergunta que organiza o trabalho não é quem executa o controle?, e sim qual documento eu apresento, com que periodicidade ele é gerado, e quem tem o direito contratual de exigi-lo?

Serviço relevante e serviço acessório: por que a classificação vem primeiro

Nem toda contratação de nuvem recebe o mesmo tratamento, e classificar corretamente evita tanto o excesso quanto a omissão. A categoria de serviço relevante aparece expressamente no documento primário do Banco Central que fundamenta a norma de segurança cibernética e de contratação de serviços de processamento e armazenamento de dados e de computação em nuvem por instituições autorizadas^[1]. Um serviço relevante carrega exigências que um serviço acessório não carrega — e tratar tudo com o mesmo rigor consome orçamento sem reduzir risco.

O critério prático de classificação combina dois eixos: a criticidade do serviço para a continuidade do negócio — se ele parar, a operação para? — e a sensibilidade do dado tratado. Uma ferramenta de gestão de tarefas internas e o ambiente que processa transações de clientes não pertencem à mesma categoria, ainda que ambos sejam "nuvem". O produto dessa etapa é um catálogo simples: cada serviço em nuvem contratado, seu dono, sua classificação e a justificativa de um parágrafo. É a partir dele que a matriz de controles se aplica de forma proporcional.

A matriz controle, cláusula e evidência

A matriz converte cada exigência do regulador em duas peças exigíveis: o que o contrato precisa dizer e o documento que comprova o cumprimento. É o ativo central deste artigo porque resolve a lacuna prática mais comum — contratos que afirmam que o provedor "adota as melhores práticas de segurança" e que, por isso, não sustentam nenhuma demonstração.

Como montar a matriz para o seu contrato

Monte uma linha por controle e não avance enquanto as quatro colunas não estiverem preenchidas. O conjunto de controles abaixo é o que consta do documento primário do Banco Central já referido: autenticação, mecanismos de criptografia, mecanismos de rastreabilidade de transações e operações, testes de intrusão realizados no mínimo anualmente e com independência, monitoramento de credenciais e de certificados digitais, segmentação de rede resguardando em especial o ambiente de produção, e isolamento físico e lógico do ambiente do sistema de pagamentos instantâneos em relação aos demais sistemas — com prazo de adaptação estabelecido, segundo o documento, para 1º de março de 2026^[1].

Vale uma delimitação honesta de escopo: a obrigação formal descrita nesse documento é dirigida a instituições autorizadas do setor financeiro. Para saúde, educação e para empresas que atendem clientes regulados por contrato, o conjunto funciona como régua de referência transferível — um bom padrão de exigência —, e não como a mesma obrigação legal. O panorama dos setores regulados é tratado em Setores regulados: saúde, financeiro, educação.

Rastreabilidade e retenção de log: o controle mais subestimado

A rastreabilidade falha na auditoria não por ausência de log, mas por retenção insuficiente — e retenção costuma ser função do plano contratado, não da norma. O provedor gera a trilha; por quanto tempo ela fica disponível depende do nível de serviço adquirido. Uma instituição que precisa demonstrar operações de um período anterior ao que seu plano retém descobre o problema no momento em que já não há como corrigi-lo.

Quatro perguntas resolvem a lacuna antes que ela apareça. Quem gera o log — provedor, instituição ou ambos, e há sobreposição? Por quanto tempo ele fica disponível no plano efetivamente contratado, e esse prazo cobre o período que a instituição precisa demonstrar? Quem consegue exportá-lo, em que formato e com que esforço? E o que acontece com ele no encerramento do contrato — a trilha é entregue, e em qual prazo? Essa última é a mais esquecida e a que mais dói: encerrar um contrato e perder o histórico é perder a capacidade de responder sobre o passado.

Gestão de chaves criptográficas: quem detém a chave muda tudo

A decisão sobre custódia de chave define o que a instituição consegue garantir e o que ela assume de risco operacional. São três arranjos, em nível de decisão. Na chave gerenciada pelo provedor, a operação é simples e a instituição depende integralmente dele — inclusive para impedir acesso. Na chave gerenciada pelo cliente dentro do provedor, a instituição controla ciclo de vida e revogação, com o material ainda residindo na infraestrutura contratada. Na chave mantida fora do provedor, o controle é máximo e o risco operacional também: perder a chave significa perder o dado, sem recurso.

O erro comum é escolher o arranjo pelo grau de controle desejado, sem avaliar se existe maturidade para operá-lo. Custódia externa exige processo de rotação, redundância, procedimento de recuperação testado e pessoas treinadas. Uma instituição que assume a custódia sem essa base troca um risco de confidencialidade por um risco de disponibilidade — e disponibilidade é justamente o que o regulador cobra primeiro.

Isolamento de ambientes críticos e teste de intrusão

Esses são os dois controles mais caros e mais frequentemente mal compreendidos da lista — e ambos falham na demonstração pelo mesmo motivo: são tratados como configuração técnica, quando o que a auditoria pede é evidência formal e periódica.

O que significa isolamento físico e lógico, e como se comprova

Isolamento significa que o ambiente crítico não compartilha caminho de rede, credencial, plano de gestão nem repositório de dados com os demais ambientes. São quatro separações distintas, e atender três não é atender: separação de rede, para que não haja rota entre os ambientes; separação de credencial, para que a conta que administra um não administre o outro; separação de plano de gestão, para que o console ou a automação de um não alcance o outro; e separação de dado, para que não haja base compartilhada.

A comprovação exige artefatos, não afirmações: diagrama de arquitetura vigente e datado, regras de filtragem em produção, lista de contas administrativas por ambiente com evidência de que não há sobreposição, e registro da revisão periódica das exceções — porque exceções são criadas para resolver incidentes e raramente são removidas depois. Empresas médias costumam conseguir separação lógica com evidência de configuração; empresas grandes precisam do isolamento formalizado, com revisão periódica documentada e dono nomeado.

O que caracteriza um teste de intrusão com independência

Independência significa que quem testa não é quem construiu nem quem opera o ambiente testado, e que o resultado não passa pelo crivo de quem seria responsabilizado por ele. O documento primário do Banco Central estabelece a realização de testes de intrusão no mínimo anualmente e com independência^[1] — e é a palavra "independência" que costuma ser interpretada de forma frouxa.

Na prática, três elementos sustentam a demonstração. Primeiro, o escopo acordado por escrito antes da execução, porque um teste de escopo estreito produz um relatório limpo que não significa nada. Segundo, a declaração formal de independência do executor em relação às equipes de desenvolvimento e operação. Terceiro, o acompanhamento das correções: um relatório com achados não tratados é evidência contra a instituição, não a favor. O ciclo completo — escopo, execução, relatório, correção, verificação — é o que se apresenta na auditoria.

O que o provedor global não vai assinar

Há um conjunto de exigências que provedores globais de nuvem simplesmente não aceitam, e insistir nelas consome meses de negociação sem resultado. Saber o que não se obtém é tão útil quanto saber o que pedir — e evita que a instituição chegue à auditoria acreditando ter contratado algo que nunca esteve no contrato.

O que não se obtém

Quatro pedidos são recusados de forma consistente. Auditoria presencial no data center não é concedida a clientes individuais, por razões de segurança e de escala do próprio provedor. Responsabilidade ilimitada não é aceita; os limites de responsabilidade são estruturais no modelo de negócio. Personalização do ambiente para um cliente de porte médio não existe: o serviço é padronizado por definição. E o contrato-padrão do cliente, com as cláusulas que o jurídico da instituição costuma usar com fornecedores locais, não será assinado no lugar dos termos do provedor.

O que se obtém, e como pedir

O que se obtém é substancial, desde que se peça o que existe. Relatório de auditoria independente com escopo declarado — o instrumento que substitui a auditoria presencial e que, para efeito de demonstração, cumpre a função, desde que a instituição verifique se o escopo cobre os serviços que ela usa. Certificações vigentes, com atenção ao escopo e à data, e não apenas ao nome. Região de armazenamento definida contratualmente, que é diferente de uma configuração alterável a critério do provedor. Prazo de notificação de incidente estabelecido em contrato. Direito de exigir evidência periódica e mediante evento. E, sobretudo, o adendo setorial que os grandes provedores mantêm para clientes de setores regulados — que já traz boa parte dessas cláusulas escritas.

O erro mais comum de instituições pequenas e médias é negociar a partir do contrato-padrão sem saber que o adendo existe. Pedir o adendo setorial é a primeira pergunta a fazer, não a última — e costuma resolver, sem negociação, cláusulas que levariam meses para serem discutidas uma a uma. Os critérios gerais de avaliação de provedores estão em Como avaliar fornecedores de cloud e infraestrutura.

Incidente, subcontratação e saída

Três compromissos contratuais determinam se a instituição consegue cumprir suas obrigações quando algo dá errado: o prazo de notificação de incidente, o controle sobre a cadeia de subcontratados e a existência de um plano de saída testado. Nenhum deles é sobre o funcionamento normal do serviço — todos são sobre o que acontece quando ele falha.

Por que o prazo de notificação precisa ser menor que o prazo regulatório

Se o provedor avisa depois, quem descumpre é a instituição. A aritmética é simples e frequentemente ignorada: a instituição tem um prazo regulatório para comunicar um incidente ao regulador; esse prazo começa a correr do evento, não do aviso do provedor. Se o contrato permite que o provedor notifique em um prazo igual ou maior que o da instituição, a instituição está estruturalmente impedida de cumprir sua obrigação — e nenhum esforço operacional corrige isso depois.

A cláusula precisa então estabelecer um prazo de notificação materialmente menor que o prazo regulatório aplicável, deixando margem para que a instituição avalie, classifique e comunique. Precisa também definir o que conta como incidente notificável, por qual canal a comunicação chega e a quem — porque um aviso enviado a um endereço genérico que ninguém monitora tem o mesmo efeito prático de aviso nenhum.

Subcontratação encadeada e plano de reversibilidade

O provedor subcontrata, e a cadeia inteira continua sob responsabilidade da instituição. Três exigências dão controle mínimo sobre isso: lista dos subcontratados relevantes, notificação prévia de inclusão ou substituição e direito de objeção com consequência definida. Sem a terceira, as duas primeiras são apenas informação. O tratamento do risco da cadeia como processo é tema de Gestão de risco de terceiros (TPRM) na prática para a TI; aqui, o recorte é a cláusula.

A reversibilidade responde à pergunta que o regulador faz cedo: o que acontece se o provedor falhar ou o contrato terminar? Quatro pontos precisam estar contratados — formato de exportação do dado, em padrão utilizável e não proprietário; prazo para a entrega; assistência do provedor na transição; e teste periódico do plano, porque plano de saída não testado é documento, não capacidade. A estruturação e o teste de recuperação estão em Disaster recovery em cloud: como estruturar e testar.

O roteiro consolidado, para quem vai montar isso do zero, é este:

1. Classificar cada serviço em nuvem por criticidade e sensibilidade do dado.
2. Montar a matriz de controle, cláusula e evidência para os serviços classificados como relevantes.
3. Verificar o que o contrato-padrão já cobre, antes de negociar qualquer coisa.
4. Pedir o adendo setorial e negociar apenas as lacunas remanescentes.
5. Definir dono e periodicidade para cada evidência da matriz.
6. Coletar evidência continuamente, e não na véspera da auditoria.
7. Revisar a matriz a cada renovação e a cada mudança relevante do serviço.