What should local IT support include in a service agreement?

A local IT support service agreement should define precisely what the provider manages, how support is requested and governed, what the customer must provide, and what happens when circumstances change. It should be detailed enough to prevent assumptions while remaining flexible enough to reflect the organisation’s systems, risks and future requirements.

The scope of service

The agreement should include a service schedule identifying the devices, users, sites, networks, cloud services and applications within scope. It should distinguish between fully managed services, advisory work and items that remain the customer’s responsibility. This avoids uncertainty over whether support includes, for example, personal devices, specialist production equipment, line-of-business software or systems hosted by another supplier.

It should also state how new users, devices, offices and applications are added to the managed environment. A clear process for changing the supported estate prevents the contract from becoming inaccurate as the organisation grows.

Support definitions and exclusions

Terms such as incident, service request, problem, change and security event should be defined. An incident affects an existing service; a service request is a planned requirement such as granting access; a problem concerns the underlying cause of repeated incidents; and a change alters the technology environment. These distinctions help ensure that different types of work are assessed and recorded consistently.

Exclusions should be equally clear. They may cover unsupported software, unauthorised changes, equipment outside the agreed estate, third-party failures or projects requiring separate planning. Exclusions should explain the available alternative, such as chargeable consultancy or a separate project statement, rather than simply stating that the work is not included.

Commercial and operational boundaries

The agreement should explain how charges are calculated, which services are included in the recurring fee, and which work is billed separately. It should address licences, hardware, travel, project work, emergency changes and costs imposed by third parties where these are relevant. Any assumptions behind the pricing, such as user numbers, site numbers or supported devices, should be recorded and linked to a review process.

It should also specify how invoices are issued, how disputed charges are handled, and how changes to the commercial arrangement are approved. This gives both parties a documented route for dealing with growth or a reduction in requirements.

Security and information handling

Security provisions should describe how the provider and customer handle administrative accounts, credentials, remote support tools and sensitive business information. The agreement should cover least-privilege access, approval for elevated permissions, removal of access when a person changes role, and the secure storage and transfer of credentials. It should make clear which party owns each account and who can authorise access.

Where the provider processes personal data, the agreement should align with the applicable data protection requirements and identify the relevant responsibilities of each party. It should address confidentiality, data processing, retention, breach notification and the use of subcontractors where applicable. Security obligations should apply to both the support provider and the customer, since insecure customer practices can undermine otherwise well-managed controls.

Backup, recovery and continuity responsibilities

Backup arrangements should state which systems and data are protected, where copies are held, how retention is managed and how recovery is tested. A contract should not merely say that backups exist; it should identify the recovery assumptions and the division of responsibility when restoration is required.

The agreement should distinguish between restoring data, restoring a service and continuing operations during a wider disruption. It should record who declares an incident, who supplies business priorities, who approves recovery actions and how lessons from tests or real events are documented.

Communication and governance

A useful agreement sets out the approved support channels, the information a customer should provide when reporting an issue, and the people authorised to raise sensitive or high-impact requests. It should identify operational contacts, escalation contacts and business decision-makers without relying on individual knowledge held outside the contract.

Regular service reviews can examine recurring incidents, unresolved risks, technology changes, security findings, asset information and upcoming business requirements. The agreement should specify what reporting is provided, how records are corrected and how actions are assigned and tracked. Governance is particularly important where the provider is advising on technology rather than simply resolving individual faults.

Change and project control

Routine support and planned change should not be treated as the same activity. The agreement should explain when a request becomes a project, what planning information is required, and how costs, dependencies, testing, approvals and rollback arrangements are recorded. Changes affecting several sites, critical systems or security controls need a documented approval route.

It should also state who owns technical designs, configuration records and project documentation. This supports informed decision-making later and reduces dependence on undocumented knowledge.

Customer responsibilities

The customer should commit to providing accurate information, suitable access, authorised contacts and timely decisions. It may also need to maintain supported hardware, approve security measures, notify the provider about organisational changes and ensure that staff follow agreed policies. These responsibilities are not administrative detail: delays or unauthorised changes can affect diagnosis, security and recovery.

The agreement should explain what happens if the customer does not meet a material responsibility. This should be proportionate and transparent, with a route for recording the issue, assessing its effect and agreeing corrective action.

Review, renewal and exit

Finally, the agreement should define its start date, term, renewal arrangements, review points and termination provisions. It should explain how either party gives notice, how outstanding work is handled and how services are transferred at the end of the relationship.

An exit clause should cover the return or transfer of documentation, asset and configuration information, credentials, licences where transferable, backups and other customer data. It should also state how access is removed and how confidential information is retained or securely deleted. Including these provisions from the outset makes the agreement clearer throughout its life, not only when the support arrangement ends.