IT support contract: what it should include

An IT support contract should cover above all: the scope with a list of supported systems, clear exclusions, maintenance windows, reporting channels and escalation for faults, a documentation obligation, rules for hardware failures and extra work, and termination and handover. Every commitment must be worded so that it can be checked whether it was kept. What cannot be measured cannot be enforced in a dispute either.

Why does an SME need a written support contract at all?

Many support relationships in small businesses rest on a handshake and habit: the technician has known the company for years, you call, he comes. That works as long as both sides mean the same thing by "support". Problems arise when they no longer do – after a major outage, an unexpected invoice, or when the relationship ends.

A written IT support contract protects both sides. The business knows what it gets for its money. The provider knows what it is responsible for and what it is not. And both have a basis to refer to when expectations diverge. The following checklist is a professional one, not legal advice; the legal drafting of the contract belongs with your legal adviser. Whether ongoing managed IT services or billing by effort suits you is a separate question, which we cover in our article on managed IT services for SMEs. Here the focus is on what the contract must contain once you have decided on ongoing support.

How do you describe the scope properly?

The scope is the most important part of the IT support contract. General wording such as "support of the IT infrastructure" is not enough. A sensible approach is an annex that lists the supported systems specifically, plus a description of the tasks carried out on a regular basis.

• List of supported systems: sites, routers, firewall, switches, Wi-Fi, servers, backup, cameras, business applications with interfaces
• Regular tasks: monitoring, updates, backup checks including restore tests, maintenance of access rights and firewall rules
• Coordination with third parties: internet provider, manufacturers, vendors of business applications
• Advice: a regular overview of condition, upcoming replacements and risks
• A procedure for adding new systems to the list

What must be explicitly excluded?

The exclusions are at least as important as the scope. Typically excluded are new projects, training, questions about how to use business applications and, depending on the provider, support for individual workstations. What matters is not what is excluded but that it is written down. For each exclusion it should also be clear how it is handled instead: as a separate quote, billed by effort, or through another partner.

How are maintenance windows regulated?

Updates to the firewall, switches or servers sometimes require a restart or a short interruption. The contract should set out when such work may take place, how it is announced, and how urgent security updates are handled that cannot wait for the next maintenance window. This is especially important for businesses with shift work, weekend opening or seasonal peaks, where the usual evening window may not fit.

How are faults, availability and response regulated?

The contract should describe through which channels faults are reported, how they are classified by urgency and who can be reached outside office hours, if that is agreed. A sensible classification distinguishes at least between operations coming to a standstill, individual functions being restricted, and a normal request.

If you agree a response time, make it measurable: what exactly is measured – the first reply, the start of work or the resolution? When does the clock start, and how is it recorded? Without that definition, a commitment is worth little when it counts. On top of that, a response time describes the start of a fault, not its end. How long a fault actually lasts depends heavily on whether the systems are documented.

Why does a documentation obligation belong in the contract?

The documentation obligation is missing from many support contracts, and its absence costs a lot of time and money when switching provider or during a major outage. The clause should state what is documented, how current the documentation must be kept, where it is stored and that the business has access at any time. Ownership matters too: the documentation describes the business's systems and therefore belongs to the business.

• Network diagram with sites, devices and connections
• Configurations of firewall, switches, Wi-Fi and servers
• Credentials in a password manager the business can access itself
• Change history: who changed what, when and why
• List of licences, contracts and terms

How should escalation be regulated?

Escalation means: what happens if a fault is not resolved as expected, or if the business is unhappy with the support? The contract should name who is responsible at each level on both sides, when the manufacturer or provider is brought in, and how management is informed. A regular review meeting, in which open points are discussed before they need escalating, is equally helpful.

How are hardware failures and extra work billed?

Hardware failures and extra work cause the most surprises. The contract should clarify whether replacing faulty devices is included, who pays for the replacement device and whether spare devices are kept. For everything beyond the flat fee, a transparent procedure belongs in the contract: extra work is announced and approved in advance, before it happens, and does not first appear on the monthly invoice.

What applies to data protection and access to data?

An IT provider that looks after servers, backup or email usually has access to personal data. Under the GDPR this normally requires a separate data processing agreement, either alongside the support contract or as part of it. From a technical point of view, it should also be settled who on the provider's team has access to which systems, how access is logged and how credentials are stored.

For businesses that use or plan AI applications, another question arises: where is data processed, and does it leave the business? That question belongs in the discussion with your provider just as much as in the review by your legal adviser.

What belongs to termination and handover?

Besides term and notice period, the IT support contract should include a handover clause: which documents and credentials are handed over at the end of the contract, in what form and within what period, and that the outgoing provider takes part in a handover meeting with the successor. The domain, cloud accounts and licences should be registered to the business from the start anyway. If a provider refuses such a clause, that is a warning sign for the planned relationship.

How do you check an existing or proposed contract?

1. 01Compare the list of supported systems with the IT you actually have: anything missing is not supported when it matters.
2. 02Read the exclusions and clarify for each one how it is handled instead.
3. 03Check whether commitments on maintenance and faults are worded measurably.
4. 04Look for the documentation obligation and ownership of the documentation; if missing, renegotiate.
5. 05Work through the rules on hardware failure and extra work before the first case occurs.
6. 06Check the handover clause and clarify who the domain, accounts and licences are registered to.

How NDVDL sets up support contracts

NDVDL only drafts a support contract after we have visited your premises and taken an inventory of the infrastructure. You then receive a contract with the list of supported systems, explicit exclusions, maintenance windows that fit your operating hours, and full-service support including hardware replacement. We do not support individual workstations; the contract says so, and for that part we coordinate with your own arrangement or a specialised partner. We do not advertise a fixed response time. Instead, we commit to ongoing documentation that belongs to you and is handed over in full at the end of the contract. During operation you have one permanent contact person who knows your systems.