O que deve constar em um contrato de manutenção de software?

A proposta diz "manutenção contínua". Quando você pergunta o que isso cobre, a resposta vira "depende do caso". O sistema continua importante para vendas, estoque, cobrança ou atendimento, mas o contrato não explica quem reage a uma falha, quem aprova uma mudança ou o que acontece quando o fornecedor deixa de atender.

Antes de comparar o preço, transforme a palavra manutenção em perguntas que a empresa consiga conferir. Se o negócio precisa de responsabilidade contínua pelo software da empresa, essa responsabilidade também precisa aparecer na conversa sobre escopo, acesso, decisões e continuidade.

Este texto é um checklist de compra, não um modelo jurídico. O guia da FTC sobre cibersegurança para pequenas empresas, consultado em 27/09/2026, recomenda colocar expectativas de segurança nos contratos com fornecedores e verificar se elas são cumpridas. Termos que terão efeito jurídico devem passar por um profissional habilitado na sua jurisdição.

Resposta curta

• Defina quais sistemas, ambientes e rotinas estão cobertos.
• Separe manutenção, incidente, dúvida, treinamento e projeto novo.
• Combine canal, prioridade, horário de atendimento e forma de atualização sem inventar um prazo que o fornecedor não consegue cumprir.
• Mantenha contas, dados e recuperação sob controle da empresa, com acesso do fornecedor limitado ao necessário.
• Exija um caminho de transferência se o contrato terminar ou se a pessoa que conhece o sistema não puder continuar.

O que a palavra "manutenção" precisa significar?

Manutenção não é uma promessa genérica de que alguém fará qualquer coisa que surgir. No mínimo, o contrato deve ligar cada serviço a um sistema, ambiente ou rotina e explicar o resultado esperado. A empresa precisa conseguir olhar para uma solicitação e decidir se ela é suporte incluído, correção, atualização, mudança aprovada ou projeto separado.

Uma forma prática de organizar o escopo é separar:

• Correção: o sistema fazia algo previsto e deixou de fazer.
• Adaptação: uma dependência, serviço externo ou regra operacional mudou e exige ajuste para o fluxo continuar.
• Prevenção e segurança: atualizações, verificações, cópias de segurança, monitoramento ou revisão combinados no serviço.
• Evolução: uma nova tela, integração, relatório ou regra que altera o produto e precisa de decisão própria.

Esses nomes não formam uma lei nem um padrão obrigatório. Eles ajudam a evitar que "manutenção" esconda quatro trabalhos diferentes. A orientação da NIST sobre montar uma equipe de cibersegurança para pequenas empresas, consultada em 27/09/2026, recomenda documentar nível de serviço, responsabilidades e expectativas em um contrato formal quando a empresa terceiriza esse trabalho.

O que fica dentro e fora do escopo?

Uma boa descrição de escopo permite que duas pessoas classifiquem o mesmo pedido de forma parecida. Ela não precisa listar cada detalhe do sistema, mas deve nomear as áreas que causam discussão: integrações, dados, infraestrutura, fornecedores externos, usuários, relatórios e mudanças de processo.

Use uma tabela como roteiro para a conversa, não como cláusula pronta:

Não escreva apenas "suporte a todo o software". Diga se o suporte inclui uma aplicação criada pelo fornecedor, uma ferramenta comprada, um serviço de nuvem ou uma integração entre empresas. Se o contrato depender de acesso ou serviço de terceiros, o texto precisa dizer o que acontece quando esse terceiro falha.

Como o contrato deve tratar incidentes e prazos?

Um prazo de resposta não é o mesmo que um prazo para restaurar o fluxo ou resolver a causa. O contrato fica mais compreensível quando separa essas etapas e explica o que a empresa receberá enquanto o problema estiver aberto. Sem essa separação, "atendimento em até X" pode significar apenas uma confirmação de recebimento.

Antes de aceitar uma tabela de níveis de serviço, confira:

1. Canal: onde um incidente deve ser aberto e quais informações precisam acompanhar o pedido?
2. Prioridade: o que torna um problema crítico para a operação, em vez de apenas inconveniente?
3. Horário: o relógio corre só em horário comercial ou também em fins de semana e feriados?
4. Resposta: o fornecedor confirma o responsável e o próximo passo?
5. Contorno: existe uma forma temporária de manter vendas, cobrança ou atendimento funcionando?
6. Atualização: com que frequência a empresa recebe notícias enquanto espera?
7. Escalonamento: quem decide quando o problema exige outro fornecedor ou uma mudança de prioridade?

Não copie prazos de outro contrato. Um compromisso só ajuda se o fornecedor tiver acesso, contexto e capacidade para cumpri-lo. A NIST também recomenda que a empresa esclareça e documente o nível de serviço, as responsabilidades e as expectativas ao contratar serviços externos. A responsabilidade pelo risco do negócio continua sendo da empresa, mesmo quando parte do trabalho é terceirizada.

Quem controla as contas e os dados?

O fornecedor pode administrar um sistema sem ser o único dono das contas que mantêm a operação de pé. Domínio, hospedagem, repositório, e-mail de serviço, banco de dados, ferramenta de pagamento e console de terceiros precisam estar vinculados à empresa, com usuários individuais e acesso revogável.

A FTC orienta limitar o acesso do fornecedor ao que ele precisa e pelo tempo necessário. A mesma orientação recomenda registrar como os dados serão usados, compartilhados, mantidos e excluídos. Em uma negociação, traduza isso para perguntas simples:

• A conta pertence à empresa ou foi criada no e-mail pessoal do fornecedor?
• Quem pode conceder, revisar e revogar acesso?
• Onde ficam os dados e como a empresa faz uma exportação legível?
• O fornecedor usa subcontratados? Se usa, eles aparecem no fluxo de acesso?
• Como a empresa é avisada sobre um incidente de segurança?
• O que acontece com cópias, credenciais e dados quando o trabalho termina?

O material da CISA para avaliação de fornecedores por pequenas e médias empresas, consultado em 27/09/2026, inclui entre seus casos a avaliação de provedores que recebem acesso crítico a sistemas ou dados. Você não precisa transformar a contratação em uma auditoria enorme. Precisa descobrir quem pode agir, sobre o quê e sob qual regra.

Como separar manutenção de uma mudança nova?

Uma solicitação de suporte começa a parecer injusta quando o cliente acredita que comprou evolução ilimitada e o fornecedor acredita que vendeu apenas correções. O contrato deve dar exemplos dos dois lados e definir o passo que acontece quando a classificação não é óbvia.

Considere uma pergunta operacional: o pedido devolve o sistema ao comportamento combinado ou muda o trabalho que ele executa? Corrigir uma integração que parou pode ser manutenção. Criar uma nova integração para um setor que ainda não fazia parte do fluxo tende a exigir uma decisão de projeto. Ajustar um campo pode ser pequeno ou pode mudar relatórios, permissões e faturamento.

O processo pode ser curto:

1. A empresa descreve o resultado necessário e o fluxo afetado.
2. O responsável pelo sistema confirma se existe uma falha, uma adaptação ou uma evolução.
3. Se for trabalho novo, o fornecedor informa escopo, risco, esforço e critério de aceite.
4. Alguém com autoridade na empresa aprova antes do início.
5. A entrega deixa um registro do que mudou e de como verificar o resultado.

O checklist para comparar propostas de desenvolvimento de software antes de assinar ajuda quando uma solicitação deixa de ser manutenção e vira uma entrega com escopo próprio. A regra importante é não começar trabalho pago fora do acordo com base em uma conversa vaga.

Como testar a continuidade antes de assinar?

Leia a cláusula de saída como se o fornecedor não pudesse ajudar por um mês. A empresa sabe quem entra nas contas, onde estão os dados, como mantém o fluxo mais importante e quem decide a próxima correção? Se a resposta for "vamos perguntar ao desenvolvedor", o contrato ainda depende de memória individual.

Faça um teste de transferência com um caso pequeno e seguro. Peça ao fornecedor que mostre:

• o inventário dos sistemas, serviços e integrações cobertos;
• onde estão a documentação e o histórico de mudanças;
• como a empresa exporta dados e identifica a versão mais recente;
• como alguém verifica uma cópia de segurança e uma restauração;
• quais acessos serão entregues, mantidos ou revogados;
• quanto tempo existe para transferir contexto, credenciais e pendências;
• quem continua responsável por uma falha aberta durante a transição.

O contrato também deve dizer o que acontece com trabalhos em andamento, dados, cópias, documentação, licenças, subcontratados e cobranças no encerramento. Não é preciso prometer que a saída será instantânea. É preciso evitar que a empresa descubra o custo da saída só quando estiver com pressa.

Freelancer, agência ou responsável contínuo?

O contrato não transforma automaticamente um freelancer em agência, nem uma agência em responsável pelo negócio. A escolha depende da quantidade de trabalho, da necessidade de coordenação e de quem terá autoridade para priorizar mudanças. A página sobre quem mantém um software empresarial depois do lançamento compara esses modelos pelo acesso, contexto, manutenção e transferência.

Se a empresa precisa apenas de uma correção pontual, um projeto bem definido pode ser suficiente. Se o software participa todos os dias de vendas, estoque, cobrança ou atendimento, o acordo precisa dar nome à responsabilidade que continua depois da entrega. Às vezes essa responsabilidade fica com uma pessoa interna. Em outras, com um profissional ou equipe externa que mantenha contexto e responda pela evolução combinada.

Não escolha pelo rótulo. Pergunte quem estará disponível, quem decide, quem documenta e quem assume o próximo passo quando a operação muda.

Perguntas para levar à negociação

O contrato precisa prometer um tempo exato para cada falha?

Ele precisa definir como a prioridade é determinada, quando começa a contagem, qual resposta será dada e como o problema será atualizado. Um prazo sem escopo, canal e responsabilidade pode parecer preciso e ainda não dizer quando o fluxo volta a funcionar.

A empresa precisa ter uma pessoa técnica interna?

Não necessariamente. Mesmo sem um desenvolvedor contratado, alguém na empresa precisa aprovar prioridades, controlar contas, confirmar o resultado e decidir o que é aceitável para a operação. O fornecedor pode executar o trabalho, mas não deveria ser a única pessoa capaz de explicar o sistema.

Um contrato de manutenção elimina o risco de depender do fornecedor?

Não. Ele reduz a ambiguidade quando define escopo, acesso, registro de mudanças, dados, continuidade e saída. A dependência continua alta se o negócio não controla as contas, não consegue exportar seus dados ou não tem uma forma de transferir o contexto para outra pessoa.

Conclusão

Antes de assinar um contrato de manutenção de software, peça respostas para cinco perguntas: o que está dentro, como uma falha é atendida, quem controla os acessos, quando uma mudança vira projeto e como a empresa sai. Essas respostas devem aparecer no acordo e ser compreensíveis para quem administra a operação, não apenas para quem escreveu a proposta.

Se a empresa ainda não sabe se precisa de projeto, suporte contínuo ou uma função interna, compare essa decisão com o guia sobre quando uma pequena empresa deve contratar um desenvolvedor. Se o problema começou porque sistemas não compartilham informação, veja o diagnóstico de sistemas empresariais que não conversam.

Manutenção não é só consertar o que quebrou. É combinar quem cuida do sistema, até onde vai essa responsabilidade e como o negócio continua no dia em que precisar de outra pessoa.

Fontes

• Federal Trade Commission, “Cybersecurity for Small Business”, consultado em 27/09/2026, https://www.ftc.gov/business-guidance/small-businesses/cybersecurity
• National Institute of Standards and Technology, “Building Your Small Business’s Cybersecurity Team”, consultado em 27/09/2026, https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/building-your-team
• Cybersecurity and Infrastructure Security Agency, “Assisting Small and Medium-sized Businesses Assess Vendors and Suppliers Fact Sheet”, consultado em 27/09/2026, https://www.cisa.gov/resources-tools/resources/assisting-small-and-medium-sized-businesses-assess-vendors-and-suppliers-fact-sheet