Security12 October 2026 · 5 min read

What a software support contract should actually cover

A locked metal cabinet door in a server room

Software is not a thing you buy. It is a thing you keep. Browsers change, payment rules change, a dependency gets a security fix, somebody rings on a Saturday because the printer has stopped. The question is not whether that happens, it is who is on the hook when it does.

Support contracts are sold vaguely on purpose. Here is what to pin down before you sign one, whoever it is with.

What a support arrangement should actually cover

Security and dependency updates. The unglamorous work that stops a site going from fine to vulnerable without anybody touching it.
Hosting, backups and a tested restore. A backup nobody has ever restored from is a belief, not a backup. Ask when the last test restore was.
Uptime monitoring that wakes a human. Not a dashboard somebody looks at on Monday.
A named route in. Who do you ring at seven on a Friday, and what happens if they do not answer?
Small changes. Prices, opening hours, a new item, a seasonal banner. If every tiny change is a quote, the site goes stale, and a stale site is the main way a good build decays.

The questions that reveal the real deal

What is the response time, and is it a promise or an aspiration? Ask what happens when it is missed.
Does it cover the whole stack? If the site, the payments, the domain and the email are with four suppliers, a problem on a Friday becomes an argument about whose fault it is while you are losing orders.
What is explicitly not covered? The honest answer to this tells you more than the list of what is.
What happens to the code and the data if we stop? You should be able to leave with both. If you cannot, you are renting.

Why we do it this way

We build it, we host it, we support it, and the first thirty days after launch are on call at no extra cost. That is not generosity, it is self-interest: the only way to find out what a system is really like is to run it through its first month of real use, and if we are the ones answering the phone we build it differently in the first place.

What an arrangement covers is on the ongoing support page. The security side of it, which is the part nobody sees until it matters, is on cloud and security.

Questions

Before you ask.

What should a software support contract include?

Security and dependency updates, hosting with backups and a tested restore, uptime monitoring that wakes a person, a named route in out of hours, and small content changes without a quote for every one.

How do I check a backup is real?

Ask when the last test restore was carried out and how long it took. A backup nobody has restored from is a belief rather than a backup.

Does one supplier for everything matter?

It matters on a Friday night. If the site, payments, domain and email sit with four suppliers, a problem becomes an argument about whose fault it is while you are losing orders.

What should I ask that suppliers do not volunteer?

What is explicitly not covered, what happens when a response time is missed, and what happens to your code and your data if you stop paying. The answers tell you whether you own the system or rent it.

Is support needed if nothing is changing?

Yes, because the ground moves underneath: browsers, payment rules and security fixes. A site nobody maintains does not stay the same, it decays quietly.