IT Support Contract Checklist: SLAs, Scope and Exit Terms

An IT support contract should tell you what the provider owns, what your business still owns, when each priority receives attention, how security incidents are handled, and what happens when the relationship ends. If those answers depend on sales conversations rather than the signed documents, the service boundary is not yet clear.

Reviewed: 9 September 2026

IT support contract checklist at a glance

Area	The contract should answer	Evidence to request
Scope	Which people, devices, sites and services are covered?	Current supported-estate schedule
Service levels	When does each response clock run and stop?	Priority matrix and monthly report
Security	Who patches, monitors, backs up and responds?	Responsibility matrix and incident route
Charges	What is included, variable or separately quoted?	Price schedule and change process
Exit	How are access, data and documentation returned?	Exit plan and handover checklist

This checklist supports a commercial review; it is not legal advice. Ask a qualified adviser to review terms where liability, regulated data, employment, sector rules or a material business dependency makes that appropriate.

1. Define the supported estate

List the users, devices, offices, cloud tenants, servers, networks and important applications included at the start. The contract should explain how additions, removals and acquisitions change the fee. It should also identify unsupported, end-of-life or third-party systems rather than leaving them in an implied grey area.

• Are contractors, seasonal users, shared terminals and home workers counted?
• Are mobiles, printers, network equipment and meeting-room systems included?
• Does support cover Microsoft 365 or Google Workspace administration, or only user troubleshooting?
• Which business applications receive best-effort help, vendor escalation or no support?
• Who maintains the inventory and how often is it reconciled?

2. Separate a response target from a resolution promise

A response target measures when the provider begins handling a request. Resolution depends on diagnosis, access, suppliers, parts, change approval and the fault itself. Do not let the two terms blur together.

For each priority, record the business impact, supported hours, target response, update frequency, escalation route and any restoration or workaround objective. Explain whether the clock pauses while the provider waits for the customer or another supplier. Avoid definitions based only on words such as “urgent”; a priority-one incident might instead mean a whole-site outage, active compromise or inability to take customer payments.

3. Confirm operating hours and contact routes

State the timezone, business days, bank-holiday treatment and out-of-hours arrangement. A 24/7 monitoring service does not necessarily mean a 24/7 staffed helpdesk or unlimited engineering work. Record how users open requests, how critical incidents are declared, who may authorise emergency changes and what happens if the normal portal or email service is unavailable.

4. Build a responsibility matrix

Write the recurring duties down by system. Useful rows include patching, endpoint protection, user administration, licence renewal, backup checks, restore tests, certificate renewal, domain and DNS control, network changes, supplier escalation, documentation and asset disposal. Give each row one accountable owner even where several parties perform work.

The NCSC’s current MSP selection guidance recommends clear contracts covering responsibilities, response times, third-party dependencies, backups, access, logs, incidents, reporting and exit arrangements.

5. Protect provider and administrator access

The agreement should describe how privileged access is granted, authenticated, reviewed and removed. Ask whether technicians use named accounts, strong multifactor authentication, least-privilege roles and controlled escalation. Shared permanent administrator passwords make accountability and offboarding harder.

Confirm whether the provider can access systems without customer approval, whether sessions or actions are logged, and how emergency access is governed. Include the provider’s own service failure or compromise in the incident route; supplier access is part of your risk, not outside it.

6. Specify patching, monitoring and end-of-life duties

Define which software and firmware the provider patches, the normal cadence, the route for actively exploited vulnerabilities, testing expectations, maintenance windows and rollback. Record who identifies unsupported products and who approves replacement or risk acceptance. “Managed” should not mean obsolete systems remain unnoticed until an incident.

Monitoring needs named signals, alert thresholds, coverage hours and an action route. The provider should be able to show whether alerts were received, investigated and closed—not merely that an agent was installed.

7. Make backup and recovery measurable

List the protected systems and data, backup frequency, retention, storage locations, encryption, access and monitoring. Define recovery point and recovery time objectives where they matter. Most importantly, agree what restore tests will be performed, how often and what evidence the customer receives.

A backup licence is not a disaster-recovery plan. If the provider is responsible for recovery, identify application dependencies, recovery order, decision-makers, communications and any separately chargeable incident work.

8. Agree incident notification and evidence access

The contract should say what constitutes a security incident, who contacts whom, by which channel and within what agreed timeframe. Include incidents affecting the provider or a subcontractor where your service or data may be involved.

Confirm log sources, retention and access. Your business or an appointed incident specialist may need exports during an investigation. Do not discover after an event that evidence was unavailable, overwritten or accessible only through an additional service.

9. Understand suppliers, licences and exclusions

Record important subcontractors and platforms used to deliver support. Clarify who holds each licence, who receives renewal notices, what happens when a vendor changes its price and whether the customer can continue using the product after exit. Ask the provider to label exclusions such as major projects, onsite travel, out-of-hours work, hardware, cloud consumption and specialist forensics.

10. Check price reviews and change control

The fee schedule should explain the charging unit, minimum commitment, onboarding cost, indexation or review mechanism, taxes and payment terms. A controlled change process should cover new offices, acquisitions, migrations and material scope increases. Compare the full first-year cost with ACA’s guide to managed IT support pricing.

11. Review data protection wording

If the supplier processes personal data on your behalf, the written terms should cover the required controller–processor matters, including instructions, confidentiality, security, assistance, subprocessors and end-of-contract handling. The ICO’s contracts guidance is under review following recent legislation, so use the live version and obtain advice for your circumstances.

12. Read the exit before signing

Check the initial term, renewal, notice, early termination and service-suspension provisions. The exit schedule should cover credential transfer, administrator access, configuration exports, asset and licence records, documentation, data return or deletion, domain and cloud ownership, final backups and reasonable transition help.

Set timescales and charges for handover work. ACA’s supplier and domain handover pack can help turn those responsibilities into an acceptance checklist.

Questions to answer before approval

1. Can a manager explain the service boundary without calling the salesperson?
2. Do priority definitions describe business impact and supported hours?
3. Does every security and recovery responsibility have an accountable owner?
4. Can the business access its systems, logs and documentation during an incident?
5. Are variable charges and exclusions visible?
6. Could another provider take over using the promised exit materials?

For ongoing support, review ACA’s managed IT support for UK SMEs and use this checklist to compare the proposed scope.

Frequently asked questions

Does an SLA guarantee that an issue will be fixed?

Not automatically. Many SLAs commit to response, updates or service availability rather than a fixed resolution time. Read the exact measure, exclusions and remedy.

Who should own administrator accounts?

The business should retain controlled ownership of its core tenants, domains and services. Providers can receive named delegated access appropriate to their work.

Should exit assistance be included?

Yes. The agreement should state what is handed over, when, in which format and whether transition work is included or chargeable.