Um bom SLA de software, o acordo de nível de serviço da sustentação, precisa deixar sete pontos escritos. São eles: a classificação de cada problema por gravidade, os prazos de resposta e de solução por nível, o horário de cobertura e a meta de disponibilidade do sistema. Completam a lista a resposta a incidentes de segurança, os relatórios que a empresa recebe e o que acontece quando o prazo não é cumprido.

Sem esses pontos, o contrato de sustentação vira uma promessa genérica de “suporte”, difícil de cobrar quando o sistema para.

O SLA não serve para punir o fornecedor. Ele existe para que as duas partes saibam, antes do problema, quem faz o quê e em quanto tempo. Isso reduz discussões, acelera decisões durante uma crise e dá ao gestor um critério objetivo para avaliar o serviço.

Este guia explica cada item que deve constar no SLA, mostra uma tabela de severidade com prazos de referência e lista as cláusulas que mais costumam faltar. Também traz dados sobre o custo das paradas e sobre as regras de comunicação de incidentes com dados pessoais.

O que é SLA e por que ele importa na sustentação

SLA é a sigla em inglês para Service Level Agreement, ou acordo de nível de serviço. É a parte do contrato que transforma “o fornecedor dará suporte” em compromissos mensuráveis: prazos, horários, metas de disponibilidade e consequências.

Na sustentação de software, o SLA cobre o período depois da entrega, quando o sistema já está em uso. É nessa fase que aparecem os defeitos, as mudanças de regra, as atualizações de segurança e as quedas. Um sistema de gestão parado por um dia pode travar faturamento, emissão de notas e atendimento a clientes.

O custo das paradas explica a importância. O relatório Annual Outage Analysis 2026, do Uptime Institute, divulgado em 13 de maio de 2026, traz dados da pesquisa anual de 2025 da entidade. Nela, 57% dos participantes disseram que sua última grande interrupção custou mais de US$ 100 mil. Pelo segundo ano seguido, um em cada cinco relatou custo acima de US$ 1 milhão.

Esses números vêm de operações de data centers e grandes ambientes de TI, e não se aplicam diretamente a toda empresa. Mas mostram uma regra geral: o prejuízo de uma parada costuma ser muito maior do que o custo de um bom acordo de sustentação.

Os 7 itens que todo SLA de sustentação deve ter

A lista abaixo resume o conteúdo mínimo de um SLA de sustentação. Cada item é detalhado nas seções seguintes.

1. Classificação de severidade, com critérios objetivos para cada nível.
2. Prazos de primeira resposta, de contorno e de solução definitiva para cada nível.
3. Horário de cobertura e canais de abertura de chamados.
4. Meta de disponibilidade, com forma de medição e exclusões.
5. Procedimento para incidentes de segurança, inclusive com dados pessoais.
6. Relatórios periódicos e reuniões de acompanhamento.
7. Consequências do descumprimento, como descontos, créditos ou multas, e regras de saída.

Um contrato que deixa de fora qualquer um desses itens não é necessariamente ruim. Mas cada ausência é uma decisão que será tomada no meio de uma crise, sob pressão, e não com calma na mesa de negociação.

Item 1: classificação de severidade

A severidade define a gravidade de um problema e, com ela, a velocidade da resposta. As boas práticas do ITIL, um conjunto de referências muito adotado em gestão de serviços de TI, separam dois conceitos: impacto e urgência. A documentação do GLPI, ferramenta de chamados de código aberto, descreve essa separação. A urgência é indicada por quem abre o chamado, e o impacto, que pode atingir um usuário, um serviço ou uma funcionalidade, costuma ser definido pelo técnico.

O cruzamento dos dois gera a prioridade. Um erro que afeta toda a empresa e impede o faturamento tem impacto alto e urgência alta. Um erro num relatório usado uma vez por mês tem impacto baixo e urgência baixa, mesmo que incomode.

O ponto mais importante é que os critérios estejam escritos com exemplos do seu negócio. “Sistema parado” deve ser definido: o sistema inteiro fora do ar, ou também uma função crítica, como emitir nota fiscal? Sem essa definição, todo chamado vira crítico para quem abre e médio para quem atende.

Tabela de severidade e prazos de referência

A tabela abaixo traz uma referência de severidade e prazos que pode servir de ponto de partida na negociação. Os prazos são contados em horário de cobertura, salvo quando o contrato prevê plantão.

Metodologia: referência elaborada pela Mind Group para negociação de contratos de sustentação, com base na lógica de impacto e urgência das boas práticas do ITIL e no ciclo de entregas quinzenais usado pela Mind. Os prazos são um ponto de partida, e não compromisso padrão: devem ser ajustados à criticidade do sistema, ao horário de cobertura e ao pacote de horas, que na Mind vai de 20 a 80 horas por mês, com valor-hora de R$ 110 a R$ 190.

Repare na diferença entre contorno e solução definitiva. O contorno devolve a operação o mais rápido possível, mesmo que de forma provisória, como reiniciar um serviço ou desligar uma função com defeito. A solução definitiva corrige a causa e evita que o problema volte.

Item 2: prazos de resposta, contorno e solução

Muitos contratos definem apenas o prazo de resposta. Isso permite que o fornecedor responda “recebido, estamos analisando” em 15 minutos e cumpra o SLA sem resolver nada. Por isso, exija pelo menos dois prazos para os níveis mais graves: resposta e contorno.

O prazo de resposta mede quanto tempo leva até um técnico começar a trabalhar no problema. O prazo de contorno mede quanto tempo leva até a operação voltar a funcionar. O prazo de solução definitiva mede quando a causa foi corrigida e a correção entrou em produção.

Também é preciso definir quando o relógio para. Se o fornecedor depende de uma informação da empresa, como uma senha ou a validação de um usuário, o prazo costuma ficar suspenso até a resposta. Essa regra deve estar escrita, com limite, para evitar que a suspensão vire uma forma de nunca descumprir o SLA.

Item 3: horário de cobertura e canais

Cobertura é o período em que o fornecedor se compromete a atender. As opções mais comuns são horário comercial, horário estendido e cobertura integral, conhecida como 24×7. Quanto maior a cobertura, maior o custo, porque exige equipe de plantão.

Nem todo sistema precisa de cobertura integral. Um sistema interno usado só em horário comercial pode ficar bem servido com cobertura no mesmo horário. Um e-commerce, um aplicativo de clientes ou um sistema de operação logística noturna provavelmente precisa de plantão ao menos para a severidade 1.

Os canais de abertura também importam. O ideal é ter um canal principal com registro, como uma ferramenta de chamados, e um canal de emergência para severidade 1, como telefone de plantão. Chamados abertos só por aplicativo de mensagens tendem a se perder e não geram histórico confiável para medir o SLA.

Item 4: meta de disponibilidade

Disponibilidade é o percentual do tempo em que o sistema está funcionando. Ela costuma ser expressa em “noves”: 99%, 99,9%, 99,99%. A diferença entre esses números parece pequena, mas representa horas de parada.

Cálculo: mês de 30 dias com 720 horas e ano de 365 dias com 8.760 horas, multiplicados pelo percentual de indisponibilidade permitido.

A meta de disponibilidade do software depende da infraestrutura. Os provedores de nuvem publicam os próprios compromissos. A AWS, por exemplo, assume no acordo de nível de serviço do EC2 disponibilidade mensal de pelo menos 99,99% por região, quando a aplicação roda em duas ou mais zonas de disponibilidade. Para uma única instância, o compromisso é de 99,5%.

Isso tem uma consequência prática. Um fornecedor de software não consegue garantir 99,99% de disponibilidade se o sistema roda num único servidor cuja meta do provedor é 99,5%. Exigir um número alto sem pagar pela arquitetura que o sustenta só cria uma cláusula que será descumprida.

O contrato também deve dizer como a disponibilidade é medida e o que fica de fora. Janelas de manutenção programada, avisadas com antecedência, costumam ser excluídas. Falhas causadas por terceiros, como o provedor de nuvem, precisam de regra clara.

O que os provedores de nuvem oferecem quando falham

Os créditos de serviço dos provedores servem de modelo para o SLA do fornecedor de software. No EC2, a AWS devolve 10% da fatura mensal quando a disponibilidade regional fica entre 99% e 99,99%, 30% quando fica entre 95% e 99%, e 100% quando fica abaixo de 95%.

O crédito é limitado ao valor pago ao provedor, e não cobre o prejuízo do negócio. A mesma lógica vale para o fornecedor de sustentação: o SLA reduz o risco, mas não substitui um plano de continuidade, com backup testado e procedimento para operar durante a parada.

Vale lembrar que boa parte das paradas vem de fora do sistema. No levantamento de nove anos de interrupções divulgadas publicamente, o Uptime Institute atribui cerca de dois terços a provedores terceiros de TI e de data center, como nuvem, internet, telecomunicações e colocation.

Item 5: incidentes de segurança e dados pessoais

Incidentes de segurança têm regras próprias e prazos legais. O artigo 48 da LGPD determina que o controlador comunique à autoridade nacional e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante aos titulares.

A Resolução CD/ANPD nº 15, de 24 de abril de 2024, regulamentou essa comunicação. Ela fixa o prazo de três dias úteis para o controlador comunicar a Autoridade Nacional de Proteção de Dados, contados do conhecimento de que o incidente afetou dados pessoais, ressalvado prazo previsto em legislação específica.

O mesmo prazo de três dias úteis vale para a comunicação aos titulares dos dados. A resolução também exige que o controlador mantenha registro de todos os incidentes, inclusive dos não comunicados, pelo prazo mínimo de cinco anos.

Na sustentação, a empresa contratante costuma ser a controladora dos dados, e o fornecedor, o operador. Pelo artigo 39 da LGPD, o operador deve realizar o tratamento segundo as instruções do controlador. Se o fornecedor demorar a avisar, a empresa perde parte do prazo legal. Por isso, o SLA deve prever um prazo curto para o fornecedor comunicar qualquer suspeita de incidente, contado em horas, e as informações mínimas que essa comunicação deve trazer.

A regra é explicada aqui de forma geral e não substitui orientação jurídica. Para redigir a cláusula, valide o texto com um advogado especializado em proteção de dados. O guia sobre LGPD e inteligência artificial em 2026 traz mais contexto sobre as obrigações da lei.

Além da comunicação, o SLA deve cobrir a correção de vulnerabilidades. Uma falha pública e explorada, como a PHP2Shell, deve ser tratada como severidade 1 ou 2, com prazo de correção definido, mesmo que o sistema ainda esteja funcionando. O guia de cibersegurança para empresas brasileiras detalha os controles que devem acompanhar o contrato.

Item 6: relatórios e acompanhamento

Um SLA sem medição é só uma intenção. O contrato deve prever um relatório mensal com os indicadores de serviço e uma reunião periódica para discutir os resultados.

O indicador de problemas recorrentes é o que mais revela a qualidade do fornecedor. Um fornecedor que só aplica contornos, sem corrigir a causa, cumpre os prazos e mantém o sistema frágil.

A falha humana também merece atenção nas reuniões. O Uptime Institute informou, em maio de 2025, que quase 40% das organizações sofreram uma grande interrupção causada por erro humano nos três anos anteriores. Do total dessas falhas, 85% vieram de equipes que não seguiram procedimentos ou de falhas nos próprios procedimentos. Pedir ao fornecedor os procedimentos escritos de publicação e de recuperação é uma forma simples de reduzir esse risco.

Item 7: consequências do descumprimento e regras de saída

As consequências mais usadas em contratos privados são descontos na mensalidade ou créditos de serviço, proporcionais ao descumprimento. Multas fixas também aparecem, mas costumam gerar mais disputa. O importante é que a regra seja proporcional e calculável sem discussão.

Uma forma comum é definir um percentual de desconto por faixa de cumprimento. Por exemplo hipotético: cumprimento de prazo acima de 95% dos chamados, sem desconto; entre 90% e 95%, desconto de 5% na mensalidade; abaixo de 90%, desconto de 10%. Os números devem ser negociados caso a caso.

As regras de saída são tão importantes quanto as multas. O contrato deve garantir a entrega do código-fonte atualizado, da documentação, dos acessos e dos dados ao fim do contrato, com prazo de transição. Sem isso, a empresa fica presa ao fornecedor mesmo quando o serviço é ruim. O artigo sobre como escolher uma software house aprofunda esse ponto.

Cláusulas que mais faltam nos contratos de sustentação

Algumas cláusulas aparecem pouco em contratos de sustentação, mas fazem diferença quando algo dá errado. Vale conferir se a proposta que você recebeu cobre cada uma delas.

• Definição escrita de “sistema parado” e de “função essencial”, com exemplos do negócio.
• Suspensão do prazo com limite, para que pendências da empresa não congelem o SLA indefinidamente.
• Plantão para severidade 1 fora do horário comercial, quando o sistema funciona à noite ou no fim de semana.
• Prazo em horas para o fornecedor comunicar suspeita de incidente de segurança.
• Teste periódico de restauração de backup, com relatório.
• Atualização de versões e bibliotecas dentro do pacote, com calendário.
• Entrega do código-fonte atualizado a cada ciclo, e não só no fim do contrato.
• Plano de transição para outro fornecedor, com prazo e responsabilidades.

Quanto custa um SLA mais exigente

Cada exigência do SLA tem custo. Prazos menores pedem mais gente disponível. Cobertura integral pede plantão. Disponibilidade alta pede infraestrutura redundante, com servidores em mais de uma zona.

Um exemplo hipotético ajuda a visualizar. Uma empresa com um sistema de uso interno pode contratar 20 horas mensais de sustentação, cobertura em horário comercial e meta de 99,5% de disponibilidade, com um único servidor. Uma empresa com um e-commerce provavelmente vai precisar de mais horas, de plantão para severidade 1 e de infraestrutura em duas zonas para buscar 99,9% ou mais.

Na Mind Group, a sustentação vai de 20 a 80 horas por mês, o que representa de R$ 2.200 a R$ 15.200 mensais pelo valor-hora de R$ 110 a R$ 190. Plantão e infraestrutura redundante entram como itens separados, dimensionados conforme a criticidade.

A comparação justa entre propostas deve considerar o SLA, e não só o preço. Uma proposta mais em conta, sem prazo de contorno nem plantão, pode sair mais cara na primeira parada séria. O guia sobre TCO de software ajuda a colocar esses custos lado a lado, e o comparativo entre software house, equipe interna e freelancer mostra como cada modelo lida com sustentação.

Como a Mind Group pode ajudar

A Mind Group é uma software house brasileira, fundada em 2016, que desenvolve sistemas, aplicativos e soluções de inteligência artificial sob medida para empresas de todo o Brasil. Tem mais de 60 desenvolvedores próprios, mais de 500 produtos digitais lançados, nota 5,0 no Clutch com 17 avaliações verificadas de clientes, entrega o código-fonte ao cliente e mantém uma frente de cibersegurança dedicada à correção de vulnerabilidades e à resposta a incidentes.

Nos contratos de sustentação, a Mind trabalha com pacotes de 20 a 80 horas por mês e define com o cliente a tabela de severidade, os prazos e o horário de cobertura antes de começar. As entregas acontecem a cada duas semanas, com uma versão para testar, e o código-fonte fica com o cliente. A frente de cibersegurança assume a correção de vulnerabilidades e a resposta a incidentes quando eles acontecem.

Para sistemas desenvolvidos por outros fornecedores, o primeiro passo costuma ser um diagnóstico de versões, infraestrutura e riscos. O artigo sobre modernização de sistemas legados explica como esse diagnóstico funciona.

Atualizado em outubro de 2026.

Perguntas frequentes

O que é SLA na sustentação de software?

SLA é o acordo de nível de serviço, a parte do contrato que define prazos, horários, metas de disponibilidade e consequências do descumprimento. Na sustentação, ele cobre o atendimento a problemas e mudanças depois que o sistema entra em uso. Sem ele, o compromisso de suporte fica genérico e difícil de cobrar.

Qual a diferença entre prazo de resposta e prazo de solução?

O prazo de resposta mede o tempo até um técnico começar a trabalhar no problema. O prazo de solução mede o tempo até o problema ser corrigido. Para casos graves, vale exigir também um prazo de contorno, que devolve a operação mesmo antes da correção definitiva.

Qual disponibilidade devo exigir do fornecedor?

Depende da criticidade e da infraestrutura. Uma meta de 99,5% permite até 3,6 horas de parada por mês, e 99,9% permite 43,2 minutos. A AWS assume 99,5% para uma instância única do EC2 e 99,99% por região com várias zonas, então a meta do software deve ser compatível com a arquitetura contratada.

O fornecedor de sustentação precisa avisar sobre vazamento de dados?

A Resolução CD/ANPD nº 15/2024 dá ao controlador três dias úteis para comunicar à ANPD um incidente com risco ou dano relevante aos titulares. Como o fornecedor costuma ser o operador, o contrato deve prever que ele avise a empresa em poucas horas. Valide a redação da cláusula com um advogado especializado.

Quais multas são comuns em SLA de software?

Em contratos privados, o mais comum são descontos na mensalidade ou créditos proporcionais ao descumprimento. Os provedores de nuvem usam essa lógica: a AWS devolve de 10% a 100% da fatura do EC2 conforme a disponibilidade. O valor deve ser negociado e calculável sem discussão.

Todo sistema precisa de cobertura 24 horas?

Não. Sistemas internos usados em horário comercial costumam ficar bem servidos com cobertura no mesmo horário. Sistemas que funcionam à noite ou no fim de semana, como e-commerce e aplicativos de clientes, precisam ao menos de plantão para a severidade mais grave.

Fontes: Uptime Announces Annual Outage Analysis Report 2026 (ITWeb) · Uptime Announces Annual Outage Analysis Report 2025 (Uptime Institute) · Amazon Compute Service Level Agreement (AWS) · Resolução CD/ANPD nº 15, de 24/04/2024 (LegisWeb) · GLPI: Matrix of calculus for priority · Lei nº 13.709/2018, LGPD (Planalto)