What should an outsourced IT contract include for a small business?

An outsourced IT contract should turn a broad support arrangement into a precise, measurable and manageable service. It should describe the operating model in enough detail that the business, the provider and any relevant third parties understand what is being delivered, how it is governed, what it costs and how risk is controlled.

1. A clearly defined service scope

The agreement should include a service catalogue rather than relying on general descriptions such as “IT support”. It should identify the systems, users, locations and devices covered, together with the activities the provider will perform. Depending on the arrangement, this may include service desk support, user administration, device management, cloud administration, network monitoring, backup management, security monitoring, infrastructure maintenance and strategic technology advice.

It should also distinguish between included services and chargeable extras. For example, routine administration may be included while a major office move, new site deployment, bespoke software work or extensive project activity is handled separately. Exclusions matter just as much as inclusions: the contract should state whether personal devices, unsupported hardware, line faults, software licensing, third-party applications and out-of-scope consultancy are covered.

An asset and system schedule can make the scope easier to maintain. This should record relevant servers, endpoints, networking equipment, cloud services, licences, domains and suppliers. The contract should explain how this schedule is updated when the organisation adds users, sites or technology.

2. A practical support and incident process

The contract should explain how users report issues and what information is needed to diagnose them. It should define the difference between an incident, a service request, a problem and a change. This prevents routine requests from being treated in the same way as a major outage.

Priority definitions should be based on business impact and urgency. A critical incident affecting a core operation may require a different process from an isolated user problem. The agreement should state how priority is assigned, who can change it and how disagreements are resolved.

It should also cover escalation routes, status updates, maintenance notifications and the circumstances in which the provider can involve a third party. If the provider uses a ticketing system, the contract should clarify who can access records, how tickets are closed and how a business can challenge an inaccurate resolution.

3. Service levels that can be measured

Service levels need more detail than a promise to provide a “responsive” service. They should define the relevant measures, such as acknowledgement, progress updates, restoration, resolution, system availability or completion of scheduled tasks. Each measure should have a clear starting point and end point.

The agreement should state how service performance is reported and whether planned maintenance, supplier failures, customer-caused delays or unavailable contacts are excluded from a calculation. It should also explain the remedy for a material service failure, which might include a service review, corrective action plan or contractual credit where agreed. A service credit should not be treated as a substitute for a proper explanation of the underlying problem.

Targets must reflect the business’s actual operational needs. A small organisation should avoid accepting complex service-level wording that it cannot interpret or use. The important point is that both parties can identify whether the provider has met its obligations.

4. Responsibilities on both sides

The contract should include a responsibility matrix setting out which party owns each activity. The provider may administer systems and maintain security controls, while the customer may need to approve access, maintain accurate staff information, provide suitable premises or connectivity, and make business decisions about risk and expenditure.

Responsibilities should cover joiners, movers and leavers; user access approvals; equipment procurement; software licensing; data classification; backup restoration requests; incident reporting; and authorisation for material changes. The agreement should also identify named contacts or roles with authority to approve changes and escalate serious issues.

5. Commercial terms that are easy to audit

The pricing section should explain the charging model, billing frequency, treatment of taxes, minimum commitments, included quantities and the basis for additional charges. It should be clear whether fees vary when the number of users, devices, sites or services changes.

Project work, emergency work, equipment, licences, third-party subscriptions, travel and telecommunications should be addressed separately where they are not part of the recurring service. The contract should specify how extra work is authorised, how estimates are presented and whether work can begin without written approval.

Price reviews should have a defined mechanism and notice requirement. The agreement should also cover disputed invoices, late payment, suspension of services and what happens if a supplier increases the cost of an underlying licence or platform.

6. Security requirements and evidence

Security obligations should be written as operating requirements, not broad statements that the provider will keep systems safe. The contract can specify controls such as multi-factor authentication, least-privilege access, privileged account management, secure remote administration, vulnerability and patch management, endpoint protection, security logging and regular access reviews.

It should state how security incidents are identified, contained, investigated and reported, including who makes decisions about customer, regulator or insurer notifications. The provider should be required to preserve relevant evidence and support post-incident investigation where appropriate.

The business should also understand how the provider protects its own administrative tools and support channels. A provider with powerful access to customer environments represents a significant concentration of risk, so the contract should address approval, monitoring and removal of that access.

7. Data protection and confidentiality

Where the provider processes personal data, the agreement should allocate the roles of controller and processor and include the required data-processing provisions. It should cover the purpose and duration of processing, categories of data, confidentiality, security measures, sub-processors, assistance with data-subject rights, breach support and deletion or return of data.

Confidentiality clauses should cover business information, credentials, system documentation and commercially sensitive records. The contract should state where data may be stored or accessed, how transfers are controlled and what evidence the provider can provide about its safeguards. Any sub-contractor involved in support should be subject to equivalent confidentiality, security and data-protection obligations.

8. Backups, continuity and recovery

If backup or recovery is part of the service, the contract should identify the systems covered, the backup method, retention approach, monitoring responsibilities and restoration process. It should not assume that a completed backup is usable: restoration testing and reporting should be addressed separately.

The agreement should distinguish between restoring a file, recovering an individual device and rebuilding a wider service. It should explain what the provider will do during a significant disruption and what decisions remain with the customer. Recovery dependencies, such as third-party platforms, internet connectivity, hardware availability and customer approvals, should be recorded rather than left implicit.

9. Change, project and governance arrangements

Technology changes should follow an agreed process covering risk assessment, approval, testing, implementation, documentation and rollback. The contract should identify which changes are routine and which require specific authorisation. This reduces the risk of an apparently minor modification causing an avoidable service or security problem.

Regular service reviews should examine open issues, recurring incidents, capacity, security actions, asset information, planned improvements and technology risks. The contract should state what reports are supplied, who attends the review and how actions are tracked to completion. This gives the relationship a governance structure rather than limiting it to reactive ticket handling.

10. Legal protection and exit arrangements

The agreement should define liability, insurance, intellectual property, confidentiality, subcontracting, audit rights, dispute resolution and the circumstances in which either party can terminate. It should distinguish ordinary termination from termination for serious breach, insolvency or an unacceptable security failure.

Exit provisions should be detailed enough to support an orderly transfer. They may cover the return or deletion of data, export of documentation, asset and licence information, administrator credentials, configuration records, open tickets, backup information and cooperation with a replacement provider. The contract should state the format, timing and cost of this assistance, as well as how access is removed once the relationship ends.

Before signing, a small business should compare the proposed contract with its actual systems, risk tolerance and growth plans. Any verbal assumption about included support, security ownership, costs or access to information should be written into the agreement or removed from the decision. A well-structured contract does not eliminate every IT risk, but it makes responsibilities, performance and remedies clear enough for the business to manage them.