Governança e Compliance

Quais os erros comuns ao contratar serviços gerenciados de TI?

Equipe C3 IT Solution
19 min de leitura
Quais os erros comuns ao contratar serviços gerenciados de TI?

Contratar serviços gerenciados de TI deixou de ser uma decisão operacional e passou a ser uma escolha estratégica — e é justamente por isso que os erros mais comuns ao contratar serviços gerenciados de TI costumam sair caros. Quando o fornecedor passa a ter acesso privilegiado a servidores, identidades, backups e ambientes em nuvem, um escopo mal definido ou um contrato genérico deixa de ser detalhe burocrático e vira exposição concreta a indisponibilidade, retrabalho e não conformidade.

O problema raramente está na tecnologia em si. Ele aparece na proposta comercial que omite o que ficou de fora, no SLA sem métrica, na ausência de inventário inicial, na indefinição sobre quem responde por segurança e backup, e na falta de um plano de saída. Para decisores de TI, segurança da informação e compliance — sobretudo em ambientes que lidam com dados sensíveis e transações financeiras —, esses pontos precisam ser avaliados antes da assinatura, não durante o primeiro incidente.

Este texto reúne os erros mais frequentes nesse processo e mostra o impacto prático de cada um, além de cláusulas contratuais, cuidados com LGPD e sinais de alerta que ajudam a comparar propostas com critério. A proposta é reduzir risco e dar base técnica para uma decisão de contratação mais consciente.

O que são serviços gerenciados de TI e o que muda em relação ao suporte sob demanda

Serviços gerenciados de TI (MSP, na sigla em inglês para Managed Service Provider) são um modelo de contratação em que o fornecedor assume a responsabilidade contínua por um conjunto definido de ativos, sistemas e processos de tecnologia. Em vez de acionar um técnico apenas quando algo quebra, a empresa paga uma mensalidade para que o parceiro monitore, atualize, corrija e evolua o ambiente de forma proativa. O contrato define escopo, níveis de serviço, tempo de resposta e responsabilidades de cada lado.

A diferença central em relação ao suporte sob demanda — também chamado de break-fix — está no incentivo econômico. No modelo reativo, o fornecedor lucra quando há incidentes: quanto mais chamados, maior o faturamento. No modelo gerenciado, o fornecedor lucra com estabilidade e previsibilidade, porque o valor mensal é fixo e o custo dele aumenta quando o ambiente falha. Essa inversão de incentivo é o que torna o MSP atraente para empresas que não podem se dar ao luxo de operar com downtime frequente.

Outra mudança prática é a natureza da relação. O suporte sob demanda entrega horas de trabalho avulsas; o MSP entrega resultado mensurável — disponibilidade, tempo de resposta, janela de recuperação de backup, conformidade de patches. Para médias e grandes empresas, especialmente as que operam ambientes híbridos com Microsoft Azure e Microsoft 365, essa diferença é estrutural: o parceiro passa a ter acesso privilegiado a sistemas críticos e precisa ser avaliado com critérios de governança, não apenas de preço por chamado.

Os 10 erros mais comuns ao contratar serviços gerenciados de TI

Os erros abaixo aparecem com frequência em processos de contratação de MSP, sobretudo quando a decisão é conduzida por compras sem participação técnica aprofundada. Cada um deles tem impacto operacional e financeiro mensurável, e a ordem não indica prioridade — indica o ponto do processo em que costumam ocorrer.

1. Contratar pelo preço mais baixo e ignorar o que está fora do escopo

Propostas de MSP com valores muito abaixo da média do mercado raramente entregam o mesmo escopo. O que costuma ficar de fora: monitoramento 24x7 de servidores, gestão de patches em estações, administração de identidades no Microsoft Entra ID, resposta a incidentes de segurança e reuniões mensais de revisão. O contratante descobre a lacuna no primeiro incidente grave, quando o chamado é cobrado como projeto à parte.

Uma prática recomendada é pedir que cada proposta detalhe as exclusões em uma tabela separada, não apenas as inclusões. Se o fornecedor não consegue listar o que está fora do escopo, é sinal de que o escopo não foi desenhado — e contratos vagos tendem a gerar disputa na primeira crise.

2. Aceitar contrato sem SLA mensurável e sem penalidade

SLA (Service Level Agreement) sem métrica objetiva é promessa de marketing. Um contrato de MSP precisa especificar, no mínimo: tempo máximo de primeira resposta por severidade, tempo de resolução ou contorno, disponibilidade mensal de cada serviço crítico e janela de manutenção programada. Cada indicador precisa ter método de medição e fonte de dados definidos — normalmente a ferramenta de monitoramento do próprio fornecedor, com auditoria possível pelo cliente.

Sem penalidade atrelada, o SLA vira meta aspiracional. O mecanismo mais comum é o crédito percentual sobre a mensalidade quando o nível combinado não é atingido no mês, com teto definido. Para entender quais indicadores exigir em cada tipo de serviço, vale consultar o que cobrar no SLA.

3. Não exigir inventário e diagnóstico inicial do ambiente

Assinar um contrato de gestão sem saber exatamente quantos dispositivos, servidores, licenças e workloads existem é como contratar um seguro sem declarar os bens segurados. O inventário inicial é a linha de base que define o preço justo, o dimensionamento da equipe do fornecedor e a responsabilidade sobre ativos que ninguém sabia que existiam.

O diagnóstico também revela riscos pré-existentes — máquinas fora de suporte, backups antigos, contas administrativas órfãs — que precisam ser tratados antes ou logo após a transição. A ausência dessa etapa transfere passivos ocultos para dentro do contrato. Sobre esse ponto, há um detalhamento em inventário de ativos.

4. Confundir 'usuário atendido' com 'dispositivo, servidor e nuvem gerenciados'

Muitas propostas de MSP precificam por "usuário", o que é legítimo, mas deixam ambíguo o que aquele usuário inclui. Um colaborador pode ter notebook, celular corporativo, conta no Microsoft 365, acesso a servidor de arquivos e perfil em ambiente virtual. Se o contrato cobre só o suporte ao usuário, a gestão do servidor, do backup e da nuvem fica de fora — ou é cobrada à parte.

O erro inverso também ocorre: a empresa acha que contratou gestão completa de infraestrutura, mas o contrato prevê apenas atendimento de help desk para pessoas. A solução é exigir uma matriz de responsabilidade explícita, separando usuário, dispositivo, servidor físico ou virtual, rede, identidade, backup e workloads em nuvem. Para ambientes que misturam servidores locais e Azure, o escopo precisa ser ainda mais claro, como abordado em MSP para ambiente híbrido.

5. Deixar segurança, backup e continuidade fora do pacote

Segurança e backup não são módulos opcionais de um contrato de MSP para empresas que lidam com dados sensíveis — são a razão de existir do contrato. Deixá-los de fora para reduzir custo é o erro de maior potencial destrutivo desta lista, porque transforma uma economia mensal pequena em exposição a incidentes de custo imprevisível.

O contrato precisa prever, no mínimo: gestão de patches e vulnerabilidades, monitoramento de backup com testes periódicos de restauração, política de retenção alinhada à regulação do setor e resposta a incidentes de segurança. O monitoramento de backup, em particular, é uma atividade que muitos fornecedores dizem fazer sem executar de fato — o tema é detalhado em monitoramento de backup. Para entender o que deve estar incluído no serviço de backup gerenciado, consulte backup gerenciado por MSP.

6. Não definir governança, canal de escalonamento e reuniões de revisão

Contrato de MSP sem rotina de governança definhada em poucos meses. O documento precisa estabelecer quem são os interlocutores de cada lado, qual o canal oficial de abertura de chamados, como funciona a escalação quando o prazo estoura e com que frequência ocorrem reuniões de revisão de indicadores. Sem isso, o cliente fica refém do gerente de contas de plantão e não tem instância formal para cobrar resultado.

Reuniões mensais ou trimestrais de revisão são o fórum onde se avaliam SLA, backlog de melhorias, riscos identificados e evolução do ambiente. Um MSP maduro traz dados e recomendações para essas reuniões; um fornecedor imaturo as evita ou as transforma em apresentação comercial.

7. Ignorar a LGPD e a cláusula de tratamento de dados no contrato

O MSP é, na prática, um operador de dados pessoais — e, em alguns cenários, pode até atuar como tomador de decisão sobre tratamento. A LGPD exige que essa relação seja formalizada em contrato com cláusulas específicas: finalidade do tratamento, duração, escopo dos dados acessados, obrigações de segurança, dever de comunicação de incidentes e destino dos dados ao fim do contrato.

Empresas do setor financeiro e que processam transações via Pix têm camadas adicionais de exigência regulatória — resoluções do Banco Central, normas de segurança cibernética e requisitos de trilha de auditoria. Um contrato genérico de MSP, sem tratamento explícito dessas obrigações, transfere para o contratante o risco de não conformidade. O tema setorial é aprofundado em serviços gerenciados de TI.

8. Não planejar a transição e a saída (reversibilidade)

Todo contrato de MSP termina — por renovação, troca de fornecedor ou internalização. O que define se a saída será ordenada ou traumática é o plano de transição negociado antes da assinatura. Sem ele, o cliente pode descobrir, no momento da rescisão, que não tem acesso administrativo aos próprios sistemas, que as documentações estão em ferramentas proprietárias do fornecedor ou que a devolução de dados levará meses.

O contrato precisa prever o processo de saída: prazo de transição, entrega de credenciais e documentação, exportação de configurações e backups, cooperação com o novo fornecedor e custo dessa fase. Cláusulas de reversibilidade bem escritas custam pouco na assinatura e evitam dependência técnica involuntária — o chamado vendor lock-in.

9. Escolher fornecedor sem especialização no seu setor ou porte

Um MSP que atende majoritariamente pequenos escritórios dificilmente terá processos maduros para operar um ambiente financeiro com requisitos de alta disponibilidade, auditoria e criptografia de dados transacionais. O inverso também vale: um fornecedor acostumado a grandes corporações pode não ter agilidade ou modelo de custo adequado para uma empresa média.

A especialização setorial importa porque reduz o tempo de adaptação a normas específicas, acelera a identificação de riscos típicos e evita que o cliente pague para o fornecedor aprender no seu ambiente. No caso de stacks Microsoft, é razoável exigir certificações e experiência comprovada em Azure, Microsoft 365 e Intune — inclusive para ambientes com gestão de dispositivos, como detalhado em MSP para ambiente Microsoft Intune.

10. Tratar o MSP como fornecedor e não como parceiro estratégico

O erro final é relacional, mas tem consequência contratual. Empresas que tratam o MSP como prestador descartável tendem a esconder informações, atrasar decisões e não envolver o parceiro no planejamento de TI — e depois cobram proatividade que nunca deram condições de exercer. O resultado é um contrato que opera no mínimo esforço, com o fornecedor limitado a apagar incêndio.

Parceria estratégica não significa ausência de cobrança; significa que o MSP tem acesso ao roadmap de negócio, participa de decisões de arquitetura e é avaliado por indicadores de resultado, não por número de chamados atendidos. Essa postura é o que permite, por exemplo, que o parceiro alerte sobre subutilização de licenças Microsoft 365 já pagas — tema explorado em recursos do Microsoft 365.

Como avaliar um contrato de serviços gerenciados antes de assinar

A avaliação de contrato de MSP exige leitura técnica combinada com visão de negócio. O objetivo não é eliminar todo risco — isso não existe em contratação de serviços —, mas garantir que os riscos estejam alocados do lado certo e que haja mecanismos de correção quando algo sair do combinado.

Cláusulas que precisam estar no contrato

Um contrato de MSP minimamente sólido contém cláusulas que vão além de preço e prazo. A ausência de qualquer uma delas deve ser tratada como ponto de negociação, não como detalhe formal:

  • Definição de escopo com matriz de responsabilidade explícita
  • SLA com métricas, método de medição e penalidades
  • Política de segurança da informação e obrigações de confidencialidade
  • Cláusula de tratamento de dados pessoais em conformidade com a LGPD
  • Plano de transição de entrada com prazos e responsáveis
  • Plano de saída e reversibilidade com entrega de ativos e credenciais
  • Regras de subcontratação e acesso de terceiros ao ambiente
  • Propriedade intelectual sobre scripts, documentação e configurações
  • Seguro de responsabilidade civil e limitação de responsabilidade
  • Foro, lei aplicável e mecanismo de resolução de disputas

Duas cláusulas merecem atenção redobrada: a de limitação de responsabilidade e a de subcontratação. A primeira define o teto de indenização em caso de falha grave do fornecedor — e precisa ser proporcional ao dano potencial, não ao valor da mensalidade. A segunda precisa impedir que o MSP terceirize partes críticas do serviço sem aprovação prévia do cliente, sobretudo quando há dados sensíveis envolvidos.

Perguntas que você deve fazer ao fornecedor na proposta

As respostas a estas perguntas revelam mais sobre o fornecedor do que qualquer slide institucional. Faça-as por escrito, preferencialmente na fase de proposta, e compare as respostas entre os concorrentes:

  • Quais ativos ficam fora do escopo desta proposta e quanto custam à parte?
  • Como o SLA é medido e qual a penalidade se não for cumprido?
  • Quem faz a transição inicial e quanto tempo ela leva?
  • Como funciona a resposta a incidentes de segurança fora do horário comercial?
  • Onde os dados da nossa empresa ficam armazenados e quem tem acesso?
  • Qual o processo de saída e quanto custa migrar para outro fornecedor?
  • Quais certificações a empresa possui e há quanto tempo?
  • Quem será o responsável técnico pela nossa conta e qual a senioridade da equipe?
  • Como são tratadas as solicitações que não estão no escopo?
  • Qual o histórico de retenção de clientes nos últimos três anos?

A pergunta sobre histórico de retenção costuma gerar desconforto — e é exatamente por isso que deve ser feita. Fornecedores com alta rotatividade de clientes geralmente escondem problemas de entrega que só aparecem depois do primeiro ano de contrato.

Sinais de alerta na proposta comercial de um MSP

Alguns sinais aparecem já na proposta comercial e permitem descartar fornecedores antes de gastar tempo com negociação. Eles indicam imaturidade comercial, escopo mal definido ou intenção de lucrar com aditivos futuros:

  • Proposta com valor mensal sem detalhar o que está incluído
  • SLA descrito em texto corrido, sem tabela de severidade e prazos
  • Promessa de "proteção total" ou "segurança garantida"
  • Ausência de menção a backup, recuperação de desastres ou LGPD
  • Preço baseado apenas em número de usuários, sem menção a servidores e nuvem
  • Prazo de início imediato sem fase de diagnóstico e transição
  • Resistência a incluir cláusulas de saída ou penalidade
  • Proposta genérica, sem referência ao ambiente ou setor do cliente
  • Pressão para assinar com desconto válido por poucos dias
  • Falta de referências verificáveis de clientes do mesmo porte

O sinal mais grave é a promessa de segurança absoluta. Nenhum fornecedor sério de cibersegurança garante eliminação de risco — o que se contrata é redução de exposição, detecção mais rápida e resposta estruturada. Propostas que prometem "100% seguro" devem ser tratadas como desqualificação automática, especialmente em ambientes financeiros com transações Pix.

Outro alerta é a ausência de qualquer menção a conformidade. Um MSP que atende empresas com dados sensíveis e não aborda LGPD, normas setoriais ou requisitos de auditoria na proposta provavelmente não tem processos para sustentá-los — e o contratante descobrirá isso em uma fiscalização, não em uma reunião comercial.

Checklist de due diligence do fornecedor de serviços gerenciados

A due diligence de um MSP vai além da leitura da proposta. Ela investiga a saúde financeira, a maturidade operacional e o histórico do fornecedor. O checklist abaixo organiza os pontos essenciais em quatro blocos:

Jurídico e financeiro:

  • CNPJ ativo e tempo de operação da empresa
  • Certidões negativas fiscais, trabalhistas e cíveis
  • Balanço ou indicadores de saúde financeira dos últimos dois anos
  • Ações judiciais relevantes em que a empresa figura como ré
  • Contratos vigentes com clientes de porte semelhante

Técnico e operacional:

  • Certificações da equipe nas tecnologias que serão gerenciadas
  • Ferramentas de monitoramento, ticketing e gestão de patches utilizadas
  • Processo documentado de gestão de mudanças e incidentes
  • Política de acesso administrativo e controle de privilégios
  • Estrutura de plantão e tempo real de resposta fora do horário comercial

Segurança e conformidade:

  • Certificação ISO 27001 ou equivalente, quando aplicável ao porte
  • Política de tratamento de dados pessoais e adequação à LGPD
  • Histórico de incidentes de segurança divulgados ou conhecidos
  • Processo de resposta a incidentes e comunicação ao cliente
  • Testes periódicos de restauração de backup documentados

Referências e histórico:

  • Referências de clientes atuais do mesmo setor ou porte
  • Tempo médio de permanência dos clientes na carteira
  • Motivos declarados de saída de clientes recentes
  • Equipe dedicada ou compartilhada entre múltiplos clientes
  • Plano de continuidade do próprio fornecedor

A certificação ISO 27001, quando presente, é um indicador relevante de maturidade em segurança da informação — mas não substitui a verificação dos demais pontos. Para entender o peso dessa certificação na escolha de um MSP, consulte certificação ISO 27001.

Quanto custa errar: impacto financeiro e operacional de um contrato mal feito

O custo de um erro na contratação de MSP raramente aparece na primeira fatura. Ele se materializa em incidentes, horas extras da equipe interna, retrabalho de migração e perda de produtividade — itens que não entram na comparação de preços entre propostas, mas que definem o custo real do contrato.

Considere um cenário hipotético: uma empresa média com 300 usuários contrata um MSP sem exigir inventário inicial. Seis meses depois, descobre 40 servidores que não estavam no escopo, um backup que não era testado havia oito meses e um contrato sem penalidade por descumprimento de SLA. O custo de correção — renegociação, projeto de recuperação e horas internas — pode facilmente superar o valor economizado na negociação inicial.

O impacto operacional é igualmente relevante. Cada troca de fornecedor de MSP consome de três a seis meses de esforço interno entre seleção, transição e estabilização. Nesse período, a equipe de TI da empresa deixa de atuar em projetos de negócio para administrar a troca — um custo de oportunidade que não aparece em nenhuma planilha de comparação de propostas.

Há ainda o risco reputacional e regulatório. Para empresas do setor financeiro, um incidente de segurança decorrente de falha do fornecedor pode gerar notificação à autoridade reguladora, exposição na imprensa e perda de confiança de clientes. O valor de um contrato bem estruturado, nesse contexto, é medido pelo que ele evita — não pelo que ele entrega no dia a dia.

Perguntas frequentes sobre contratar serviços gerenciados de TI

Posso contratar serviços gerenciados tendo equipe interna de TI?

Sim, e esse é um modelo comum em médias e grandes empresas. O MSP assume a operação de rotina — monitoramento, patches, backup, help desk de primeiro nível — enquanto a equipe interna se concentra em arquitetura, segurança, projetos e alinhamento com o negócio. O ponto crítico é definir com clareza a fronteira de responsabilidade entre os dois times, para evitar sobreposição de atividades e conflito de autoridade.

Esse modelo híbrido funciona melhor quando o contrato prevê uma matriz RACI (Responsible, Accountable, Consulted, Informed) e reuniões regulares entre a equipe interna e o MSP. Sem essa definição, a tendência é que ambos os lados assumam que o outro está cuidando de determinada atividade — e ela fique sem dono.

Qual o prazo mínimo de contrato recomendado?

Contratos de MSP costumam ter prazo de 12 a 36 meses. Prazos mais longos geralmente vêm com condições comerciais melhores, porque permitem ao fornecedor diluir o custo da transição inicial. No entanto, um prazo longo só faz sentido se o contrato tiver cláusulas de saída claras, métricas de desempenho e gatilhos de rescisão por descumprimento.

Para o primeiro contrato com um fornecedor desconhecido, prazos de 12 a 24 meses são mais prudentes — tempo suficiente para avaliar a entrega, mas curto o bastante para não ficar preso a um parceiro ruim. A renovação por períodos maiores pode ser negociada depois que o fornecedor provar consistência.

Como comparar propostas de MSPs diferentes?

A comparação só é possível quando as propostas seguem a mesma estrutura. O método recomendado é enviar aos concorrentes um documento de requisitos com o escopo desejado, os SLAs mínimos e as perguntas obrigatórias — e exigir que cada proposta responda ponto a ponto. Propostas que chegam em formatos diferentes não são comparáveis e geralmente escondem lacunas.

  • Normalizar o escopo: mesma lista de ativos e serviços para todos
  • Comparar SLA item a item, não apenas o preço mensal
  • Incluir custos de transição, saída e aditivos prováveis no comparativo
  • Avaliar qualificação técnica da equipe, não apenas o nome da empresa
  • Verificar referências do mesmo setor e porte antes de decidir

O preço mensal é apenas um componente do custo total de propriedade do contrato. Uma proposta 20% mais barata que não inclui monitoramento de backup ou gestão de patches pode custar muito mais caro no primeiro incidente.

O que fazer se o fornecedor atual não está entregando o combinado?

O primeiro passo é formalizar a insatisfação por escrito, com base nos indicadores do contrato — SLA descumprido, chamados fora do prazo, entregas não realizadas. Reuniões informais não geram registro e enfraquecem qualquer medida posterior. O segundo passo é acionar a cláusula de penalidade, se ela existir, e exigir um plano de correção com prazos definidos.

Se o descumprimento persistir após o plano de correção, o caminho é a notificação formal de rescisão, observando o plano de saída previsto em contrato. É nesse momento que a ausência de cláusulas de reversibilidade cobra seu preço: empresas que não negociaram a saída antecipadamente descobrem que dependem do fornecedor para ter acesso aos próprios sistemas. Por isso, o plano de saída precisa ser tratado na assinatura do contrato — não no momento da crise.

Em paralelo, é prudente iniciar um novo processo de seleção com base no que o contrato atual ensinou: escopo detalhado, SLA com penalidade, inventário inicial obrigatório e cláusulas de saída negociadas desde o primeiro dia. O erro mais caro é repetir, por pressa, as mesmas condições que geraram o problema atual.