Contratar serviços gerenciados de TI para o setor financeiro não é uma decisão de eficiência operacional: é uma decisão de governança. Bancos, corretoras, fintechs, cooperativas, seguradoras e instituições de pagamento operam sob supervisão do Banco Central, da CVM e da SUSEP, e a terceirização de ambientes críticos precisa passar pelo crivo do compliance antes de chegar à mesa do fornecedor. O problema é que a maior parte do conteúdo sobre MSP disponível no mercado trata o tema como se toda empresa fosse igual — e não é.
Quem lidera TI em uma instituição regulada precisa responder a perguntas que um contrato corporativo comum sequer levanta: quais cláusulas o regulador exige, como comprovar controles em uma fiscalização, o que acontece com dados sensíveis sob LGPD e sigilo bancário, e como integrar ambientes gerenciados a core bancário, Open Finance e sistemas legados. Errar nesse enquadramento não gera apenas retrabalho — gera exposição regulatória.
Este texto percorre as exigências que recaem sobre provedores e contratantes em ambientes financeiros, os requisitos contratuais que sustentam uma auditoria e os erros que costumam virar glosa ou incidente. O objetivo é dar base técnica e normativa para avaliar um parceiro com critério, e não por preço.
O que são serviços gerenciados de TI e por que o setor financeiro tem regras próprias
Serviços gerenciados de TI — ou MSP, na sigla em inglês para Managed Service Provider — correspondem ao modelo em que uma empresa terceiriza a operação, o monitoramento e a manutenção contínua da sua infraestrutura tecnológica para um provedor especializado. Em vez de acionar suporte apenas quando algo quebra, a organização contrata uma gestão proativa: o parceiro assume patching, atualizações, monitoramento de disponibilidade, backups, gestão de identidades e resposta a incidentes sob um contrato de escopo definido e recorrência mensal. Para empresas que operam ambientes Microsoft, isso costuma incluir administração de Azure, Microsoft 365, Intune e ferramentas de segurança como Microsoft Defender e Microsoft Sentinel.
No setor financeiro, esse mesmo modelo ganha uma camada adicional de complexidade. Bancos, corretoras, fintechs, cooperativas de crédito, seguradoras e instituições de pagamento não terceirizam TI apenas com base em critérios de custo e eficiência operacional. A contratação de um MSP nesse segmento é, antes de tudo, uma decisão regulatória: o Banco Central do Brasil, a CVM e a SUSEP impõem deveres específicos de governança, sigilo, continuidade e supervisão sobre qualquer serviço relevante prestado por terceiros. Um incidente de segurança em um ambiente gerenciado não gera apenas prejuízo operacional — pode resultar em autuação, glosa regulatória, responsabilização de administradores e dano reputacional irreversível.
Por isso, o conteúdo de um contrato de serviços gerenciados para instituições financeiras é substancialmente diferente de um contrato corporativo comum. As cláusulas precisam prever direito de auditoria do regulador sobre o provedor, plano de continuidade testado, segregação de ambientes, rastreabilidade de acessos privilegiados e conformidade com normas que não se aplicam a outros setores. Quem contrata sem esse enquadramento corre o risco de descobrir, na primeira fiscalização, que o parceiro escolhido não atende aos requisitos mínimos exigidos pelo supervisor.
O que muda quando o cliente é uma instituição financeira
A principal diferença está no regime de responsabilidade. No setor financeiro, a instituição contratante permanece integralmente responsável perante o regulador pelos serviços executados pelo terceiro. A Resolução CMN 4.658, de 2018, que dispõe sobre a política de segurança cibernética das instituições autorizadas a funcionar pelo Banco Central, é explícita: a contratação de serviços relevantes de processamento e armazenamento de dados não transfere a responsabilidade da instituição. O MSP é um braço operacional, mas a governança, a supervisão e a prestação de contas continuam sendo do contratante.
Isso muda completamente o desenho da relação contratual. O provedor deixa de ser apenas um fornecedor e passa a ser um componente do ambiente regulado, sujeito às mesmas exigências de confidencialidade, integridade e disponibilidade que se aplicam à própria instituição. Na prática, significa que o MSP precisa estar preparado para receber auditorias do contratante, responder a questionamentos do Banco Central, fornecer evidências de controles e manter documentação compatível com o padrão exigido de uma instituição financeira — não de uma empresa comercial comum.
Exigências da Resolução CMN 4.658 e da Lei 13.709 (LGPD)
A Resolução CMN 4.658 estabelece que as instituições financeiras devem implementar e manter política de segurança cibernética aprovada pelo conselho de administração ou diretoria, cobrindo requisitos para a contratação de serviços de processamento e armazenamento de dados em nuvem. O normativo exige que os contratos com provedores prevejam, no mínimo: definição clara de responsabilidades, obrigação de comunicação imediata de incidentes, adoção de medidas de segurança compatíveis com as da instituição, e acesso do Banco Central aos dados e informações armazenados no ambiente do provedor.
A LGPD, por sua vez, se aplica em camadas sobre esse arcabouço. O MSP que opera ambientes de instituições financeiras é tipicamente um operador de dados pessoais, enquanto a instituição permanece como controladora. Isso exige contrato de tratamento de dados com cláusulas específicas: finalidade delimitada, proibição de uso secundário, dever de confidencialidade, obrigação de apoiar o controlador no atendimento a direitos de titulares, e comunicação de incidentes de segurança em prazo compatível com o artigo 48 da lei. Em ambientes de Pix e Open Finance, onde há tratamento massivo de dados transacionais e de identificação, a ausência dessas cláusulas é um risco jurídico concreto.
Circular BCB 3.909, PCI DSS e o papel do Banco Central na terceirização
A Circular BCB 3.909, de 2018, trata especificamente da contratação de serviços de processamento e armazenamento de dados em nuvem por instituições financeiras. Ela exige que a instituição comunique previamente ao Banco Central a intenção de contratar serviços relevantes, apresentando análise de riscos, plano de contingência e informações sobre o provedor. O normativo também determina que os dados de clientes armazenados em nuvem devem permanecer em território nacional ou em países que ofereçam tratamento jurídico equivalente, e que o Banco Central tenha acesso irrestrito a essas informações quando necessário.
Para operações com cartões, o PCI DSS (Payment Card Industry Data Security Standard) entra como exigência contratual das bandeiras. Um MSP que administra servidores, endpoints ou redes por onde trafegam dados de portadores de cartão precisa operar dentro de um escopo PCI definido, com segmentação de rede, controles de acesso rigorosos e monitoramento contínuo. A combinação de Circular 3.909, PCI DSS e Resolução 4.658 cria um cenário em que o provedor precisa demonstrar maturidade de controles muito acima da média do mercado de TI gerenciada.
Segregação de funções, auditoria e trilha de evidências
Segregação de funções é um princípio de controle interno que reduz o risco de fraude e erro: quem desenvolve não aprova, quem administra não audita, quem tem acesso de produção não tem acesso de desenvolvimento. Em ambientes financeiros gerenciados, isso se traduz em arquiteturas de identidade com papéis bem definidos, aprovação dupla para mudanças críticas e separação entre ambientes de produção, homologação e desenvolvimento. O MSP precisa operar dentro dessa estrutura sem criar "superusuários" que concentrem poderes incompatíveis com o controle interno da instituição.
A trilha de evidências é o que torna a segregação auditável. Logs de acesso, registros de alteração de configuração, histórico de comandos executados em servidores e trilhas de atividades administrativas no Microsoft 365 e no Azure precisam ser coletados, protegidos contra adulteração e retidos por prazo compatível com as exigências regulatórias. Em uma fiscalização, o Banco Central não pergunta se a instituição "acha" que os controles funcionam — pede evidências. O MSP que não entrega trilha íntegra e consultável compromete a capacidade de defesa do contratante.
Requisitos obrigatórios em um contrato de TI gerenciada para finanças
O contrato de MSP para uma instituição financeira não pode ser um modelo genérico de prestação de serviços. Ele precisa refletir o regime regulatório do contratante e antecipar situações de fiscalização, incidente e descontinuidade. Três blocos de cláusulas são inegociáveis: níveis de serviço, governança contratual e continuidade de negócios. A ausência de qualquer um deles costuma ser apontada como deficiência em auditorias internas e externas.
Além das cláusulas, pesa a capacidade do provedor de comprovar o que promete. Um SLA assinado sem lastro em monitoramento real, relatórios periódicos e penalidades proporcionais é apenas um compromisso retórico. O mesmo vale para a continuidade: um plano de recuperação que nunca foi testado tem valor próximo de zero quando ocorre um incidente real em plena janela de processamento do Pix.
SLA, RTO e RPO compatíveis com operações críticas
SLA (Service Level Agreement) define o nível de serviço contratado, com métricas objetivas de disponibilidade, tempo de resposta e tempo de resolução. Para infraestrutura crítica de uma instituição financeira, disponibilidade de 99,9% pode ser insuficiente: cada hora de indisponibilidade em canais digitais gera perda de receita, reclamações em massa e exposição regulatória. O contrato precisa distinguir criticidade — um ambiente de desenvolvimento pode ter SLA de 99,5%, enquanto o core de processamento de transações exige meta superior, com medição mensal e relatório auditável.
RTO (Recovery Time Objective) e RPO (Recovery Point Objective) são métricas complementares que definem, respectivamente, quanto tempo o ambiente pode ficar fora do ar e quantos dados podem ser perdidos em um incidente. Para sistemas de pagamento instantâneo, o RPO tende a ser próximo de zero, o que exige replicação síncrona ou quase síncrona de dados. O contrato de MSP deve especificar esses valores por sistema ou por classe de serviço, e prever testes periódicos que comprovem o cumprimento das metas — não apenas a existência de um plano teórico.
Cláusulas de confidencialidade, subcontratação e direito de auditoria
A cláusula de confidencialidade em contratos financeiros precisa ir além do dever genérico de sigilo. Deve abranger sigilo bancário (Lei Complementar 105/2001), dados pessoais sob LGPD, segredos de negócio e informações sobre a arquitetura de segurança da instituição. Também é recomendável prever que a obrigação de confidencialidade sobreviva ao término do contrato, alcançando ex-funcionários do provedor e subcontratados.
A subcontratação é um ponto crítico: muitos MSPs utilizam terceiros para serviços de monitoramento, help desk ou datacenter. O contrato precisa condicionar qualquer subcontratação à aprovação prévia da instituição, exigir que os subcontratados cumpram os mesmos padrões de segurança e confidencialidade, e manter o provedor principal como responsável solidário. O direito de auditoria, por sua vez, deve permitir que a instituição — e, quando aplicável, o Banco Central — inspecione as instalações, os processos e os registros do provedor, com ou sem aviso prévio, incluindo o direito de contratar auditoria independente às expensas do provedor em caso de indício de não conformidade.
Plano de continuidade de negócios e testes de recuperação
O plano de continuidade de negócios (PCN) do MSP precisa estar alinhado ao PCN da própria instituição financeira. Não basta que o provedor tenha um datacenter redundante: é preciso que a arquitetura de contingência cubra os cenários de risco identificados — falha de hardware, indisponibilidade de link, ataque de ransomware, erro humano em mudança de configuração, desastre no site primário. O contrato deve definir quem aciona o plano, em que prazo, com qual prioridade de restauração e qual canal de comunicação com a instituição durante o incidente.
Testes de recuperação são a única forma de validar que o PCN funciona. A prática recomendada é realizar testes periódicos, documentando resultados, tempos alcançados e falhas identificadas. Um MSP maduro entrega relatórios de teste com evidências objetivas — logs de restauração, capturas de tela, tempos medidos — e trata as falhas encontradas como plano de ação corretiva. Instituições que não exigem essa comprovação contratual descobrem, tarde demais, que o backup existia mas a restauração nunca funcionou.
Segurança, identidade e conformidade na prática
A operação diária de um ambiente financeiro gerenciado gira em torno de três eixos: detecção e resposta a incidentes, controle de identidade e acesso, e preservação de evidências. Cada um desses eixos exige ferramentas específicas, processos documentados e equipe com conhecimento do ecossistema Microsoft — onde a maior parte das instituições brasileiras de médio e grande porte opera hoje.
A integração desses eixos é o que diferencia um MSP genérico de um provedor preparado para o setor financeiro. Não se trata apenas de instalar um antivírus e monitorar servidores: é preciso operar um ciclo completo de segurança, com coleta de eventos, correlação, resposta orquestrada, gestão de identidades privilegiadas e retenção compatível com demandas judiciais e regulatórias.
SOC, SIEM, gestão de identidades e acesso privilegiado
Um SOC (Security Operations Center) é a estrutura — interna ou terceirizada — responsável por monitorar eventos de segurança 24 horas por dia, 7 dias por semana. No contexto de MSP, o provedor pode operar o SOC como serviço, utilizando SIEM (Security Information and Event Management) para coletar e correlacionar logs de servidores, firewalls, endpoints, Microsoft 365 e Azure. Para instituições financeiras, a operação contínua não é um diferencial, é pré-requisito: a Resolução CMN 4.658 exige monitoramento contínuo e plano de resposta a incidentes.
A gestão de identidades é o segundo pilar. Em ambientes Microsoft, isso envolve Azure AD/Entra ID, políticas de acesso condicional, autenticação multifator obrigatória para acessos administrativos e revisão periódica de permissões. O acesso privilegiado merece tratamento especial: contas de administrador devem ser protegidas com PIM (Privileged Identity Management), ativação just-in-time, justificativa obrigatória e registro automático de uso. A redução de privilégios permanentes é uma das medidas mais eficazes contra movimentação lateral em ataques de ransomware — e uma das primeiras coisas que um auditor verifica em ambientes regulados. Para entender melhor o papel de um SOC, vale consultar o que é um SOC.
Prevenção a fraudes, eDiscovery e retenção de dados
Prevenção a fraudes em ambientes gerenciados passa por controle de mudanças, segregação de ambientes e monitoramento de atividades anômalas. Um MSP que opera servidores de processamento de Pix precisa garantir que nenhuma alteração não autorizada seja aplicada em produção, que acessos fora do horário comercial sejam investigados e que tentativas de exportação massiva de dados disparem alertas. Ferramentas como Microsoft Purview e Defender for Cloud Apps ajudam a detectar exfiltração de dados e uso incomum de credenciais.
eDiscovery é a capacidade de localizar, preservar e exportar dados eletrônicos em resposta a demandas legais, auditorias ou investigações internas. Em instituições financeiras, litígios e fiscalizações frequentemente exigem a entrega de e-mails, documentos e registros de transações em prazos curtos. O contrato de MSP deve prever que o provedor apoie a instituição nesses processos, com ferramentas de busca e retenção adequadas. A retenção de dados, por sua vez, precisa equilibrar a LGPD — que veda retenção indefinida — com as exigências de guarda de documentos contábeis e financeiros, que podem chegar a décadas em casos específicos.
Open Finance, APIs e integração com o core bancário
O Open Finance impôs às instituições financeiras a obrigação de expor APIs padronizadas para compartilhamento de dados e iniciação de pagamentos. Isso criou uma superfície de ataque nova: cada API publicada é um ponto de entrada potencial para atacantes. O MSP que gerencia a infraestrutura precisa garantir que gateways de API, firewalls de aplicação web e controles de autenticação OAuth 2.0 estejam configurados e monitorados adequadamente, e que logs de acesso às APIs sejam retidos para fins de auditoria e investigação.
A integração com o core bancário — o sistema central que processa contas, transações e saldos — é o ponto mais sensível de toda a arquitetura. O MSP raramente administra o core em si, mas gerencia a infraestrutura que o cerca: servidores de aplicação, bancos de dados, barramentos de integração, filas de mensageria. Qualquer intervenção nesses componentes exige planejamento de mudança rigoroso, janela de manutenção aprovada e rollback testado. A indisponibilidade do core durante o horário de pico do Pix é um incidente grave, com repercussão imediata em indicadores operacionais e na imagem da instituição.
Como avaliar e selecionar o provedor certo
A seleção de um MSP para o setor financeiro não pode ser conduzida como uma simples cotação de preço. O processo precisa combinar análise documental, entrevistas técnicas, visita às instalações do provedor e verificação de referências em clientes do mesmo porte e segmento. Uma boa prática é estruturar a avaliação em critérios objetivos, com pesos definidos antes de receber as propostas, evitando que a decisão seja influenciada apenas por promessas comerciais.
Os critérios abaixo formam um ponto de partida para a matriz de avaliação:
- Certificações de segurança: ISO 27001, SOC 2 tipo II e conformidade com PCI DSS quando aplicável
- Especialização comprovada em Azure e Microsoft 365, com equipe certificada
- Experiência anterior com clientes regulados pelo Banco Central, CVM ou SUSEP
- Estrutura de SOC própria ou parceria formal com SOC terceirizado
- Política documentada de gestão de acessos privilegiados e segregação de funções
- Capacidade de atender auditorias e fornecer trilhas de evidências
- Localização dos datacenters e conformidade com a Circular BCB 3.909
- Saúde financeira do provedor e tempo de mercado
Além dos critérios objetivos, a avaliação deve incluir um teste prático: solicitar ao provedor que demonstre, em ambiente controlado, como executa um procedimento crítico — restauração de backup, resposta a um alerta de segurança, mudança em produção. A diferença entre um provedor que descreve processos e um que executa processos fica evidente nesse tipo de exercício. Para contratos que envolvem ambiente híbrido, vale entender como um MSP gerencia ambientes híbridos.
Modelos de contratação e custos: o que pesa no orçamento
Os modelos de contratação de serviços gerenciados variam conforme o escopo e a forma de precificação. Os mais comuns no mercado brasileiro são: valor fixo mensal por usuário (per user), valor fixo por dispositivo (per device), valor por ambiente monitorado (por servidor ou por workload em nuvem), e modelo híbrido com uma taxa base mais consumo variável. Para instituições financeiras, a tendência é o contrato por ambiente ou por workload, já que o número de usuários pode ser grande e o que define a complexidade é a infraestrutura crítica, não a quantidade de colaboradores.
O orçamento de TI gerenciada para o setor financeiro é impactado por fatores que não aparecem em contratos corporativos comuns:
- Requisitos de disponibilidade elevada, que exigem redundância de infraestrutura e monitoramento 24x7
- Conformidade regulatória, que demanda documentação, auditorias e testes periódicos
- Gestão de identidades privilegiadas e segregação de funções, com ferramentas específicas
- Retenção de logs e evidências por prazos estendidos, com custo de armazenamento
- Plano de continuidade com testes regulares e ambiente de contingência
- Atendimento a demandas de auditoria e fiscalização do regulador
É um erro comum comparar o custo de um MSP para o setor financeiro com o de um MSP para uma empresa comercial do mesmo porte. O segundo não carrega os custos de conformidade, redundância e governança que o primeiro precisa absorver.
Para quem está estruturando o contrato, o conteúdo sobre o que exigir no SLA oferece parâmetros objetivos para definir métricas e penalidades.
Erros comuns na terceirização de TI em instituições financeiras
O primeiro erro é tratar a terceirização de TI como uma decisão puramente operacional, sem envolver as áreas de compliance, risco e jurídico desde o início. Quando a escolha do provedor é feita apenas pela equipe de tecnologia, cláusulas regulatórias essenciais costumam ficar de fora do contrato, e a instituição descobre a lacuna apenas na primeira auditoria ou fiscalização. A contratação de serviços gerenciados para o setor financeiro é uma decisão multidisciplinar por natureza.
O segundo erro recorrente é não verificar a capacidade real do provedor de atender às exigências de auditoria. Muitos MSPs assinam contratos com cláusulas de conformidade que não conseguem cumprir na prática: não têm trilha de evidências estruturada, não documentam mudanças, não realizam testes de recuperação. A instituição só percebe o problema quando o Banco Central solicita evidências e o provedor não consegue fornecê-las no prazo. A verificação prévia — com evidências reais, não promessas — é o antídoto.
O terceiro erro é a ausência de um plano de saída. Contratos de MSP podem terminar por decisão da instituição, por falha do provedor ou por encerramento das atividades do fornecedor. Sem um plano de transição documentado, a instituição fica refém do provedor: não sabe como recuperar acessos, migrar dados ou transferir a operação para outro parceiro. O contrato deve prever prazos de transição, obrigação de cooperação na saída, devolução de dados e documentação, e reversão de acessos após o término.
Perguntas para fazer ao fornecedor antes de assinar
A etapa final de seleção deve incluir um questionário técnico detalhado, respondido por escrito e de preferência com evidências anexadas. As respostas verbais em reunião comercial não têm valor de compromisso. Abaixo, as perguntas essenciais para qualquer provedor que esteja disputando um contrato de serviços gerenciados para instituição financeira.
- Quais clientes regulados pelo Banco Central, CVM ou SUSEP vocês atendem hoje, e podemos contatá-los como referência?
- Qual é a política de gestão de acessos privilegiados e como a segregação de funções é implementada na operação?
- Onde estão localizados os datacenters e como vocês atendem aos requisitos da Circular BCB 3.909?
- Qual é a frequência dos testes de recuperação de desastres e quais evidências são fornecidas após cada teste?
- Como funciona o processo de gestão de mudanças em ambientes de produção e qual é o prazo de aprovação?
- Quem são os subcontratados envolvidos na operação e como é garantida a conformidade deles?
- Qual é o prazo de retenção de logs e como as trilhas de evidências são protegidas contra adulteração?
- Como vocês apoiam a instituição em auditorias do regulador e em processos de eDiscovery?
- Qual é o plano de saída e quais são as condições de transição para outro provedor?
- Quais certificações de segurança a empresa possui e há relatórios de auditoria independente disponíveis?
As respostas a essas perguntas revelam, em poucos dias, se o provedor entende o regime regulatório do setor financeiro ou se está apenas adaptando um contrato genérico de MSP. A diferença entre os dois perfis define o nível de risco que a instituição assume ao assinar o contrato. Em um ambiente onde a responsabilidade perante o regulador permanece integralmente com a instituição, escolher um provedor que não comprove maturidade de governança é transferir a operação e reter o risco — a pior combinação possível.
Para instituições que operam ambientes Microsoft e precisam de um parceiro com entendimento profundo de Azure e Microsoft 365, a certificação do provedor é um filtro relevante. O conteúdo sobre certificação ISO 27001 detalha como essa certificação se traduz em controles práticos de segurança da informação — um ponto de partida útil para a avaliação documental.
