Software Maintenance Agreement: What It Must Contain, a Clause Table and the Red Flags to Avoid

A software maintenance agreement is the contract that sets out what a vendor will fix, adapt and look after in your software once it is live, how quickly it must respond, and what happens when the relationship ends. For custom software it should define the systems covered, severity levels with separate response and resolution targets, exclusions, how change requests differ from defects, hosting and security patch duties, personal data obligations and a handover plan. Without those clauses, "support" means whatever the vendor decides on the day something breaks.

Updated: 7 November 2026

What a software maintenance agreement covers

Maintenance work falls into four kinds, and a good agreement names each one:

• Corrective maintenance is fixing defects: behaviour that differs from the agreed specification or from how the system worked at acceptance.
• Adaptive maintenance is keeping the software working when its surroundings change, such as a browser update, a new operating system version, or a payment gateway that changes its API.
• Preventive maintenance is work that stops problems before users see them: dependency updates, security patches, log reviews and backup restore tests.
• Enhancement is new or changed functionality, usually priced separately as a change request.

Enterprise software support is the day-to-day service wrapped around that work: a helpdesk, incident handling by severity, user questions and regular reporting.

Two things are often confused with maintenance. A warranty is the period after acceptance in which the vendor fixes its own defects at no extra cost; maintenance starts when the warranty ends. A licence maintenance fee for packaged software buys updates to someone else's product; it does not cover care of a system built for you. This guide is about maintaining custom software you own.

The software maintenance agreement clause table

Severity levels: response is not resolution

Response time is how long the vendor takes to acknowledge an incident and start working on it. Resolution time is how long it takes until the system works again, through a workaround or a permanent fix. An agreement that promises a fast response but no resolution target guarantees only a quick reply saying someone is looking.

Define severity by business impact, with examples your own staff would recognise. The targets below are for example only; the right numbers depend on how critical the system is and which service hours you pay for.

Add a dispute rule: if you and the vendor disagree on the level, the higher one applies until it is reviewed. Ask for a monthly report that shows every incident against its target, not just an average.

Exclusions, defects and change requests

A defect is behaviour that differs from the agreed specification or from how the system behaved when you accepted it. A change request is a request for behaviour that was never agreed. Most maintenance disputes sit in the grey area between the two, so write down how cases like these are treated:

• A third-party service changes its API and an integration stops working (usually adaptive maintenance, included up to an agreed limit).
• A new regulation changes a calculation or a form (usually a change request).
• A user deletes or corrupts data by mistake (data repair, often billed at the change rate).
• Your own IT team changes the server or network (excluded unless agreed in advance).
• The fault sits in a module built by another vendor (excluded, or quoted separately).

Reasonable exclusions are specific. "Anything not caused by the vendor" is not an exclusion; it is an exit door. Our guide to fixed price vs time and materials explains how a rate card and written change control keep change requests predictable.

Hosting, security patches and personal data

State who hosts the system and who pays the hosting bill, how often backups run, how often a restore is actually tested, and how long recovery may take after a total failure. If the vendor hosts, the cloud account should still be in your company's name, or transferable on request.

Security patches deserve their own clause: which components are covered (operating system, database, frameworks, libraries), how quickly a critical patch is applied after release, and what happens when a component reaches end of life. The same applies to connected devices, as our IoT security checklist notes.

If the vendor handles personal data on your behalf, Singapore's Personal Data Protection Act 2012 reaches both sides. The sections below are as published on Singapore Statutes Online; the PDPC's summary of the obligations and its data breach reporting page explain them in plain terms.

• Under section 4(2), a data intermediary processing personal data for another organisation under a written contract still carries the protection obligation (section 24) and the retention obligation (section 25).
• Section 26C(3)(a) requires that data intermediary to notify your organisation "without undue delay" when it has reason to believe a data breach has occurred.
• Section 4(3) keeps you responsible for that data as if you processed it yourself.
• Under section 26D(1), once you assess a breach as notifiable, you must notify the PDPC no later than 3 calendar days after that assessment.

So the agreement should name a breach contact on both sides, a short notification window and the information the vendor must hand over, so your own clock does not start blind.

Handover and exit

Exit is the clause buyers forget and vendors rarely volunteer. It should guarantee:

• Access to the source code repository throughout the contract, not only at the end.
• Credentials, domains, cloud accounts and API keys held in, or transferable to, your company's name.
• Current documentation: architecture, deployment steps, environment settings and runbooks for common incidents.
• A full data export in a documented, usable format.
• A defined transition period in which the outgoing team answers the new team's questions, at an agreed rate.

If you buy development across borders, our guide to outsourcing software development to Indonesia covers code ownership and handover from the buyer's side.

Red flags before you sign

• "Best effort" with no numbers.
• A response target but no resolution or workaround target.
• Severity decided only by the vendor.
• Defect fixes deducted from the same hours bucket as new features.
• Security patching "on request".
• Hosting accounts, domains or the repository in the vendor's name, with no transfer clause.
• Support that runs through one engineer's personal phone.
• No exit clause, or a fee for handing over your own code.

Key takeaways

• A software maintenance agreement for custom software should cover corrective, adaptive and preventive work, with enhancements priced separately.
• Set separate response and resolution targets per severity level, and agree who decides the level.
• Make exclusions specific and write down how grey-area requests are classified.
• Put hosting, backups, restore tests and security patching in writing.
• Under the PDPA, a vendor processing personal data for you must report a suspected breach without undue delay; give that duty a contact and a window.
• Secure the exit from day one: repository access, credentials in your name, documentation and data export.

How Etzal Group handles maintenance

Enterprise Software projects at Etzal Group end with source code ownership on final payment, documentation and a 30-day warranty, followed by maintenance on terms written into the proposal: scope, severity levels, targets and exit. If you have a maintenance draft from any vendor, we can go through it with you from the technical side in a free consultation.