Guides 5 min read

Software maintenance contract and SLA: what it must include

What a software maintenance contract and SLA must include: response times by severity, what is covered vs billed hourly, backups, security updates and exit.

by Tsunami Digital Team October 23, 2026

A software maintenance contract says who looks after your application after launch, what they do every month, how fast they react when something breaks and what happens if you part ways. The SLA (service level agreement) is its measurable part: response and resolution times by severity. Most disputes come from what the contract leaves out. This is for owners about to sign one, or holding one that fits on half a page.

Quick answer: what the contract must cover

Severity levels, each with a response and a resolution time.
Support hours and how a problem is reported.
What the monthly fee covers and what is billed by the hour.
Monitoring, and who gets the alert.
Backups and how often a restore is tested.
Security and library updates, with a cadence.
Accounts and access in your company’s name.
Personal data, if the system holds any.
Notice period, exit and handover.

Response times by severity

“We respond quickly” is not an SLA. Define levels in plain language, give each one an example from your own system and attach times to it. An illustration of the shape, not a price list:

Severity	Example	Response	Fix or workaround
1 - Critical	The shop takes no orders, nobody can log in	Within 1-2 working hours	Same working day
2 - High	A key feature is broken, a workaround exists	Within 4 working hours	2-3 working days
3 - Normal	A minor bug, a wrong label on a report	1 working day	Next planned release
4 - Change	A new field, a new report	2 working days	Planned into monthly hours

Three details decide whether the table means anything. Response is not resolution: response means a person confirms the problem and starts on it; resolution often starts as a workaround. Working hours or 0-24: night and weekend cover costs more, so buy it only if an hour of downtime at night costs you more than the cover. Who sets the severity: you propose it, and the examples in the contract settle disagreements. How the SLA level moves the price is covered in software maintenance and support cost.

Included vs billed hourly

Is it a bug or a new request? The contract should answer that in writing:

Included: fixing defects in delivered functionality, monitoring, backups, routine updates.
From monthly hours or billed hourly: changes and new features, each with an estimate you approve before work starts.
Unused hours: say whether they roll over to the next month or lapse.

Write the hourly rate into the contract as a number, not “by agreement”. Ours is €40-60 per hour excluding VAT; whoever you sign with, the figure belongs on paper.

Monitoring, backups and restore tests

Monitoring means an outside check that the system is up, alerts on errors, and warnings before a certificate or domain expires. The alerts go to the supplier, so they hear about a failure before your customers do.

For backups, the contract names how often they run, where they are kept (off the main server) and for how long. Then the clause most contracts miss: a restore test at a fixed interval, quarterly for example, with the time it took written down. Why a backup is not a restore is explained in hosting and running costs after a build. Two numbers make it concrete: how much data you can afford to lose, and how long the system may be down before it runs again.

Security updates

Name the cadence for server, framework and library updates (monthly, for example), and a shorter deadline for critical security patches. Also say what happens when a framework version reaches end of support: moving to a new major version is a project, estimated separately, not a routine update.

Accounts, data and exit

Domain, hosting, repository and app store accounts should be in your company’s name, with the supplier given access you can revoke. The reasoning is in who owns the custom software you paid for.

If the system holds personal data, the supplier processes it on your behalf. Article 28 of the GDPR requires that to be governed by a contract in writing (electronic form counts), which also states that at the end of the service the data is returned or deleted, at your choice.

Finally, the exit. A notice period instead of a multi-year lock-in, long enough for an orderly handover, and a list of what you receive on leaving: the repository up to date, documentation, a list of accounts and keys, and a final backup. If you ever need it, that list is exactly what taking over software from another agency starts with.

Note: this article is informational and is not legal advice. Have the final contract reviewed by a lawyer.

How our monthly partnership handles it

In our monthly maintenance and development partnership, scope, response times and the monthly amount are agreed in writing, accounts are moved into your name where they are not already, backups are tested by restoring them, and there is a notice period instead of a long lock-in.

Frequently Asked Questions

What if the supplier misses the SLA? The contract should say: a reduction of the monthly fee, or the right to terminate after repeated misses.

Do we need 24/7 support? Only if an hour of downtime at night costs more than the cover. Most internal tools do not need it; a busy web shop may.

Is a warranty the same as maintenance? No. A warranty covers defects in what was delivered, for a limited period. Maintenance is ongoing work, paid monthly. How to tell a bug from a change request is covered in Software warranty period.

Can we change maintenance supplier mid-contract? Yes, with notice. The exit clause decides how smooth the handover is.

Holding a maintenance contract you are unsure about?

Send it to us. We will reply with what is missing for the system to be covered properly - no obligation.

Reach out at info@tsunami-digital.com or via the form on our homepage.

All articles