What should a managed IT support provider include in its service agreement?

A managed IT support service agreement should be a clear operational document, not simply a description of technical services. It should explain what is included, how support is requested and managed, how performance is assessed, how information is protected, and what happens when the organisation’s requirements change. The wording should be specific enough for both parties to make consistent decisions without relying on informal assumptions.

Service scope and definitions

The agreement should identify the systems, locations, users and technology environments covered by the service. This might include end-user devices, servers, cloud platforms, networks, connectivity, business applications and security tools. It should also define important terms such as an incident, service request, problem, change, major incident and out-of-scope work. Clear definitions reduce disagreement about whether an issue is part of the managed service or a separate project.

A useful agreement distinguishes between recurring support and project work. Routine administration, monitoring and fault resolution may form part of the managed service, while activities such as office moves, major infrastructure changes, new system implementations or complex remediation may need separate planning and approval.

Service catalogue and deliverables

The document should include a service catalogue that states what the provider will do in practical terms. Depending on the arrangement, this may cover:

• user support and fault diagnosis;
• device, server and network management;
• cloud administration and access management;
• patching, maintenance and vulnerability remediation;
• backup administration and recovery assistance;
• security monitoring and incident coordination;
• supplier liaison for connectivity, hardware or software issues; and
• technical advice relating to planned changes and business growth.

Each item should state any relevant assumptions, dependencies or limits. For example, the agreement may need to explain whether support includes third-party applications, personally owned devices, unsupported operating systems, specialist equipment or systems that the provider cannot administer directly.

Responsibilities and access

The agreement should allocate responsibilities rather than assuming that the provider owns every technology decision. It should state what the provider is expected to manage and what the client must supply, approve or maintain. Client responsibilities may include nominating authorised contacts, providing accurate asset information, approving changes, maintaining suitable premises and connectivity, and ensuring staff follow agreed security procedures.

It should also describe the access required by the provider, including administrative permissions, remote management tools and access to relevant third-party portals. The arrangement should specify how access is authorised, reviewed, restricted and removed. Privileged access should be attributable to an individual or controlled account wherever practical, rather than shared without accountability.

Support workflow and service measurement

A good agreement explains how users report issues, which channels can be used, what information should accompany a request and how the provider records progress. It should define priority levels using business impact and urgency, rather than allowing every request to be labelled critical. Examples can clarify the difference between a complete service outage, a serious loss of functionality affecting several users and an individual request with a workable alternative.

Any response or restoration targets should be written as measurable service levels. The agreement should explain when measurement starts, which events pause or stop the clock, how dependencies on the client or another supplier are treated, and whether the target relates to acknowledgement, attendance, workaround, restoration or resolution. Reporting should show trends and exceptions, not just a list of closed tickets.

Cyber security requirements

Security provisions should describe the controls expected from both parties. These may include multi-factor authentication, least-privilege access, secure remote administration, endpoint protection, patch management, vulnerability handling, email security, security logging and user awareness measures. The agreement should make clear which controls the provider operates, which the client operates and which require a separate service.

It should also establish a process for suspected security incidents. This should cover notification, evidence preservation, containment, investigation, decision-making, communication and recovery. Where the organisation has regulatory or contractual reporting duties, the agreement should identify how the provider supports those duties without taking responsibility for legal decisions that belong to the client.

Data protection and confidentiality

The agreement should explain what business and personal data the provider may access, why that access is needed and how it is protected. It should address confidentiality, data processing roles, permitted subprocessors, access controls, retention, secure deletion and the handling of data held in backups or support records. The parties should also document how data breaches or suspected unauthorised access are reported and investigated.

Where information is stored or processed through external platforms, the agreement should identify the relevant responsibilities and dependencies. It should not imply that using a managed provider transfers the client’s legal or governance obligations.

Change, approval and continual improvement

Technology environments change, so the agreement should include a controlled change process. It should explain how proposed changes are assessed, documented, approved, scheduled and reviewed. Emergency changes should have a separate route with retrospective recording and review. The process should protect the organisation from unplanned disruption while avoiding unnecessary bureaucracy for routine, low-risk work.

Regular service reviews can provide a structured opportunity to examine recurring incidents, unresolved risks, capacity, asset changes, security findings and upcoming business plans. The agreement should state what information is supplied for these reviews and how agreed actions are tracked.

Costs, purchasing and third-party suppliers

Commercial terms should explain the charging model, invoicing arrangements, treatment of additional work, expenses, equipment, licences and third-party charges. They should distinguish between included activities and work requiring prior approval. If the provider purchases or renews licences on the client’s behalf, the agreement should state who owns the licence, who controls the account and what happens if the relationship ends.

Where another supplier is responsible for part of the environment, the agreement should clarify the provider’s role. It may coordinate diagnosis and communication without being able to control the third party’s actions, systems or service levels.

Continuity, liability and contract governance

The document should set out how the provider maintains its own service capability and how the client receives support if a significant operational disruption affects either party. It should also address backup responsibilities, recovery assistance and the limits of any recovery service. Backup administration alone does not establish that every system can be restored within a particular period.

Legal and governance provisions commonly cover confidentiality, intellectual property, insurance, liability limits, compliance responsibilities, subcontracting, dispute handling, renewal, review and termination. These terms should be checked against the organisation’s risk profile and any obligations owed to its own customers, regulators or insurers.

Exit and transition arrangements

An agreement should describe the practical handover process if the service ends or responsibility changes. This can include exporting documentation, asset and configuration records, credentials held on the client’s behalf, backup information, licences, support history and open issues. It should state the format, timing, ownership and reasonable charges for transition work, while ensuring that access is removed securely and confidential information is returned or deleted as agreed.

Before signing, the client should test the agreement against realistic scenarios: a widespread outage, a suspected account compromise, an employee joining or leaving, a new office, a failed backup, a third-party application fault and the end of the contract. If the document does not explain who acts, what is included and how decisions are recorded in those situations, it is not yet detailed enough to serve as a reliable working agreement.