IT Contract Service Level Agreements: 11 Items to Check Before You Sign

Choosing an IT support provider is an important decision. The company may be given administrative access to your systems, responsibility for protecting business data and a central role in recovering your operations when something goes wrong.

However, many businesses focus on the monthly price without examining exactly what the provider is promising to deliver.

A Service Level Agreement, commonly known as an SLA, should set measurable expectations for the service. It may define support hours, response targets, escalation procedures, system availability, reporting and the responsibilities of both parties.

An SLA is not necessarily the whole contract. It is often a schedule attached to a wider managed-services agreement containing commercial, legal, data-protection and termination terms. Both documents should be reviewed together.

Before signing an IT support agreement, check these 11 essential areas.

1. What Services Are Actually Included?

The contract should clearly describe the services covered by the monthly fee.

A statement such as “comprehensive IT support” may sound reassuring, but it does not explain what the provider will actually do.

The agreement should identify whether the service includes:

• Remote helpdesk support.
• On-site support.
• Server and network monitoring.
• Microsoft 365 administration.
• Cybersecurity management.
• Backup monitoring.
• Software updates.
• Device management.
• New-user setup.
• Leaver processing.
• Supplier liaison.
• Strategic IT reviews.

Check whether the provider supports every device, location and system used by your business. Specialist applications, legacy equipment, home networks, printers and third-party software may be excluded.

The contract should also explain how new employees, devices, offices and services are added. A business does not want to discover after signing that every routine change attracts an unexpected project charge.

Ask the provider to include a written service catalogue showing what is included, what is optional and what falls outside the agreement.

2. What Are the Support Hours?

A four-hour response target is very different if the helpdesk operates only between 9am and 5pm.

The SLA should define:

• Normal support hours.
• Weekend and bank-holiday arrangements.
• Whether support is available outside normal hours.
• How emergency support is requested.
• Whether out-of-hours work costs extra.
• Which issues qualify as emergencies.
• Which time zone applies.

Suppose a critical system fails at 4:30pm on Friday and the provider operates only during weekday business hours. A “four-business-hour response” might not be due until Monday.

Businesses operating evenings, weekends or across international locations may require extended or round-the-clock cover. Others may only need an emergency escalation service outside normal hours.

Make sure the support model reflects when your business actually depends on its technology.

3. How Are Support Priorities Defined?

Most IT providers categorise support requests by severity or priority. The highest category may be called Priority 1, Severity 1 or Critical.

The wording matters.

A provider may classify an issue as critical only when the entire organisation is unable to work. That could leave a serious failure affecting one department, senior employee or business-critical application assigned a lower priority.

The SLA should explain how each level is determined. Factors may include:

• Number of users affected.
• Business impact.
• Availability of a workaround.
• Security implications.
• Customer or regulatory impact.
• Whether a critical service has stopped.
• Urgency of the business activity.

Examples should be included wherever possible.

A company-wide internet outage might be Priority 1. A finance system unavailable during payroll processing could also deserve the highest priority, even if other departments remain operational.

The agreement should also state who can declare an incident critical and whether the provider can change its priority without consulting the customer.

4. Are Response and Resolution Times Clearly Separated?

This is one of the most important areas to check.

A response time normally measures how quickly the provider acknowledges the issue or begins investigating it. A resolution time measures how quickly the issue is fixed or an agreed workaround is provided.

They are not the same.

A provider could technically meet a 15-minute response target by sending an acknowledgement while taking several days to resolve the fault.

The SLA should explain:

• When the response clock begins.
• What counts as a genuine response.
• Whether an automated email qualifies.
• When technical investigation should start.
• Whether resolution targets are guaranteed or only objectives.
• What qualifies as a temporary workaround.
• When the clock can be paused.
• How supplier or customer delays are recorded.

Hamilton Group aims to make first contact on IT support requests within 15 minutes. This gives customers early confirmation that the issue has been received and is being assessed, but every business should also examine the wider escalation and resolution process.

Be cautious of impressive headline figures that are not supported by precise definitions.

5. How Is System Availability Measured?

Where the provider hosts or manages an important platform, the agreement may include an availability commitment, often expressed as a percentage.

For example, 99.9% availability sounds high, but it can still permit more than eight hours of downtime over a year. The calculation becomes even more important when scheduled maintenance and other exclusions are removed from the measurement.

Check:

• Which systems have availability commitments.
• The period over which availability is calculated.
• Whether measurement is monthly or annually.
• When downtime begins and ends.
• Which monitoring system supplies the evidence.
• Whether scheduled maintenance is excluded.
• Whether internet-provider or software-vendor failures are excluded.
• Whether partial performance degradation counts.
• What happens when the target is missed.

The contract should distinguish between services directly controlled by the IT provider and services operated by third parties such as Microsoft, an internet provider or a software vendor.

Do not accept a single general availability percentage unless it is clear which services it covers and how it is measured.

6. What Is the Escalation and Communication Process?

A good SLA should explain what happens when the initial support process is not enough.

The escalation procedure should identify:

• Technical escalation levels.
• Named service-management contacts.
• Senior-management escalation routes.
• Communication intervals during major incidents.
• Who is responsible for providing updates.
• How complaints and disputes are handled.
• When third-party suppliers are contacted.
• How unresolved recurring problems are reviewed.

During a major outage, communication can be as important as the immediate technical work. Business leaders need to know what has happened, what is affected, what is being done and when the next update will arrive.

The latest UK government contract-management principles emphasise clear accountability, roles, responsibilities, governance and contingency planning. Although written for government contracting, these are equally useful principles when reviewing a commercial IT agreement. 

The SLA should not leave you repeatedly chasing a general helpdesk address during a serious incident.

7. What Cybersecurity Responsibilities Does the Provider Accept?

An IT company may have extensive access to your systems, user accounts, network and confidential information. Its security obligations should therefore be written into the contract.

Check whether the provider commits to appropriate controls covering:

• Multifactor authentication.
• Privileged access.
• Endpoint protection.
• Security updates.
• Remote-access security.
• Encryption.
• Staff screening.
• Security awareness training.
• Vulnerability management.
• Activity logging.
• Independent security assessments.
• Cybersecurity certifications.

The NCSC recommends embedding necessary cybersecurity requirements into supplier contracts and monitoring whether those controls remain effective throughout the contractual relationship. It also advises businesses to understand and control suppliers’ remote access to their systems. 

The agreement should also define security-incident reporting. It should state:

• Which incidents must be reported.
• How quickly notification must occur.
• Who must be contacted.
• What information the notification must contain.
• How evidence will be preserved.
• What assistance the provider will supply.
• Who pays for investigation and recovery.
• Whether the provider participates in incident-response exercises.

The NCSC specifically recommends including security-incident management and reporting requirements in supplier contracts. 

Avoid wording that allows the provider to decide whether an incident is significant enough to tell you without clear criteria.

8. Does the Contract Meet Data-Protection Requirements?

An IT support company may process personal information on behalf of its customer. This could include employee records, customer details, email content, support tickets and information stored on managed systems.

Where the supplier acts as a data processor, the contract must include the mandatory provisions required by UK GDPR.

ICO guidance states that relevant contracts must address matters including:

• Documented processing instructions.
• Confidentiality.
• Appropriate security.
• The use of sub-processors.
• Assistance with individuals’ rights.
• Support with data breaches and impact assessments.
• End-of-contract data handling.
• Audits and inspections. 

Check where the provider stores and accesses information. Support services delivered from outside the UK may introduce additional data-transfer and jurisdictional considerations.

You should also understand:

• Which subcontractors are used.
• Whether you will be notified of changes.
• Whether subcontractors receive equivalent obligations.
• How long support records are retained.
• Whether remote sessions are recorded or logged.
• How securely credentials are stored.
• How information is deleted after the agreement ends.

A confidentiality clause alone is not a complete data-processing agreement.

9. What Business Continuity and Disaster-Recovery Arrangements Exist?

Your IT provider may become difficult or impossible to contact during its own cyberattack, building outage, communications failure or financial difficulty.

The SLA should explain how the provider will continue delivering essential services if its normal operations are disrupted.

Questions to ask include:

• Does it have a documented business-continuity plan?
• Can staff operate from alternative locations?
• Are customer records and documentation securely backed up?
• Is the helpdesk dependent on a single system or office?
• Are multiple employees familiar with your environment?
• How are emergency credentials protected?
• Has the continuity plan been tested?
• What happens if a key subcontractor fails?
• What happens if the provider becomes insolvent?

The NCSC recommends asking whether suppliers have tested incident and recovery processes and whether they can maintain minimum service levels following an event such as ransomware. 

Government digital-contracting guidance also recommends continuity and contingency planning for critical contracts, including planning for supplier insolvency and emergency exit. 

Do not assume that an IT support company is automatically resilient simply because it advises other businesses about resilience.

10. How Is Performance Reported and What Happens When Targets Are Missed?

An SLA is only useful if performance is measured and reviewed.

The provider should supply meaningful service reports showing areas such as:

• Number of tickets raised.
• Response and resolution performance.
• Outstanding issues.
• Reopened tickets.
• Recurring problems.
• Major incidents.
• Device and server health.
• Patch status.
• Backup results.
• Security alerts.
• Customer satisfaction.
• Recommended improvements.

The report should show whether SLA targets were met, rather than presenting only positive headline statistics.

Check how performance failures are handled. Possible remedies may include:

• A service-improvement plan.
• Root-cause analysis.
• Additional reporting.
• Service credits.
• Fee reductions.
• Escalation to senior management.
• Termination rights following repeated failure.

Service credits can provide accountability, but they should not be viewed as adequate compensation for prolonged disruption. A small credit against next month’s invoice may have little value if the business has suffered a serious outage.

The most useful remedy is often a clear requirement to identify the underlying cause, correct it and prevent recurrence.

11. What Are the Contract Length, Renewal and Exit Terms?

Some IT agreements are easy to enter and surprisingly difficult to leave.

Check:

• The initial contract length.
• Whether it renews automatically.
• The required cancellation notice.
• Whether prices can rise during the term.
• What happens after a serious breach.
• Whether repeated SLA failures allow termination.
• Early-termination charges.
• Exit-assistance costs.
• The format in which data and documentation will be returned.
• How quickly access will be transferred.
• When the provider will delete retained information.

The exit plan should cover the transfer of:

• Administrator credentials.
• Network and system documentation.
• Microsoft 365 access.
• Domain and DNS management.
• Cloud subscriptions.
• Software licences.
• Backup information.
• Supplier contacts.
• Configuration records.
• Open support issues.
• Company-owned equipment.

The NCSC advises contracts to specify requirements for returning and deleting information and assets when a supplier relationship ends. ICO guidance similarly requires processor contracts to address the return or deletion of personal information at the customer’s choice, subject to applicable legal requirements. 

Your business should retain ownership and control of its domains, tenant accounts, data and licences wherever commercially possible. A provider should not be able to hold essential access information hostage during a disagreement.

Additional Questions Worth Asking

The written agreement matters, but due diligence should go beyond the contract.

Ask the potential provider:

• Can we speak to existing customers of a similar size?
• Who will manage our account?
• How many engineers support the service?
• Are support functions outsourced?
• What certifications and insurance are maintained?
• How are employees screened and trained?
• How is customer access monitored?
• How often will our systems be reviewed?
• What happens when our business grows?
• Can you demonstrate your ticketing and reporting processes?

The NCSC recommends requesting evidence of a supplier’s security approach and verifying that certifications or assurance schemes cover the services actually being purchased. 

Promises made during a sales meeting should be added to the written agreement if they are important to your decision.

Red Flags to Look Out For

Proceed carefully when an agreement contains:

• Vague descriptions of “unlimited” support.
• No distinction between response and resolution.
• Broad exclusions that undermine the SLA.
• Targets measured only during limited business hours.
• No data-processing provisions.
• No security-incident reporting deadline.
• No service-reporting commitment.
• Excessive automatic-renewal periods.
• High exit or data-transfer charges.
• No obligation to return documentation and credentials.
• Liability limits that bear no relation to the potential risk.
• The right to change terms without meaningful notice.

A contract should give both parties clarity. If the provider cannot explain how a key clause works in practice, obtain clarification before signing.

The Lowest Price May Not Provide the Best Value

An inexpensive agreement may offer limited coverage, slow responses or additional charges for common activities. A higher monthly fee may include proactive monitoring, cybersecurity, strategic planning and more comprehensive support.

Compare providers on the complete service rather than price alone.

Consider:

• What is included.
• When support is available.
• How quickly issues are addressed.
• What security controls are provided.
• How performance is demonstrated.
• What happens during a crisis.
• How easily the relationship can end.

The purpose of an SLA is not to create an impressive sales document. It is to establish a practical and measurable service that protects your organisation.

How Hamilton Group Can Help

Hamilton Group provides responsive, proactive IT support designed around the operational and security needs of UK businesses.

We aim to make first contact on support requests within 15 minutes, while providing clear escalation procedures, proactive system management and ongoing strategic guidance.

Our services can include:

• Managed IT support.
• Microsoft 365 management.
• Cybersecurity services.
• Network and server monitoring.
• Backup and disaster recovery.
• Cloud solutions.
• IT strategy and roadmaps.
• Compliance support.
• Project delivery.
• Regular service reviews.

We can also review your existing support arrangement to identify unclear service levels, coverage gaps and areas where your current provider may not be meeting your business requirements.

To discuss your IT support contract or arrange a review of your current service, contact Hamilton Group on 0330 043 0069 or visit hgmssp.com.

This article provides general information and does not constitute legal advice. Contracts should be reviewed by an appropriately qualified legal professional before signature.