What should an outsourced IT services agreement include?

An outsourced IT services agreement is the legally binding framework that turns a provider’s proposal into defined obligations, boundaries and decision-making processes. It should explain how the relationship will operate in practice, how performance will be assessed, who carries particular risks, and what happens when circumstances change. The main agreement is often supported by schedules, service descriptions, security documents and order forms so that technical detail can be updated without rewriting the entire contract.

Identify the parties and contract structure. The agreement should name the legal entities involved, their registered details and the individual authorised to give instructions. It should state which documents form part of the contract and which document takes priority if they conflict. A sensible structure may include:

• a master services agreement covering the general legal relationship;
• a service schedule describing the selected IT functions;
• an asset or systems schedule recording the relevant environment and dependencies;
• a security and data protection schedule; and
• an order form setting out any project work or additional services.

This avoids relying on informal emails or assumptions when the provider, customer or technology changes.

Define important terms. Words such as “incident”, “request”, “problem”, “critical system”, “business day”, “authorised user” and “maintenance” can have different meanings. The contract should define them, particularly where they affect reporting, measurement or charges. It should also distinguish between included managed services, separately chargeable project work, third-party services and tasks that remain the customer’s responsibility.

Describe the operating boundaries. A useful agreement records the systems, sites, users, devices, cloud environments and networks within scope, together with any assumptions on which the service has been priced. It should explain how additions, removals and material changes are recorded. This is especially important for a growing organisation, a multi-site business or a company operating older systems alongside newer infrastructure. Without a documented baseline, disagreements can arise over whether an issue is covered work, a change request or a pre-existing condition.

Make service levels measurable. Service levels should do more than use terms such as “prompt” or “reasonable”. They can specify how issues are classified, what information is needed to start measurement, how progress is reported and which events are excluded. The agreement should explain how planned maintenance, customer-caused delays, unavailable third parties and incomplete information affect measurement. It should also state the remedy for a service-level failure, such as a review, corrective action or agreed service credit, rather than leaving the consequence uncertain.

Set out governance and communication. The contract should establish how the parties review the relationship, who receives reports and who can approve decisions. Governance provisions may cover service reviews, risk registers, outstanding actions, recurring incidents, capacity concerns and planned technology changes. They should also identify escalation routes for operational, commercial and security issues. This creates a formal route for resolving concerns without requiring every disagreement to become a contractual dispute.

Specify security controls in enough detail to be tested. Security wording should be linked to the organisation’s risk profile and regulatory obligations. Depending on the services, the agreement may address identity and access management, privileged accounts, authentication, patching, vulnerability management, malware protection, logging, backup protection, encryption, secure remote administration and staff security responsibilities. It should say how security incidents are notified, investigated, contained and documented, while avoiding a promise that no incident can occur. The parties should also agree how control effectiveness is reviewed and how material weaknesses are corrected.

Include a proper data protection schedule. If the provider processes personal data for the customer, the contract should identify the parties’ roles and describe the subject matter, duration, nature and purpose of processing. It should cover documented instructions, confidentiality, access controls, assistance with data subject rights, breach support, retention and deletion. Any use of sub-processors should be subject to an agreed approval or notification process, with responsibilities remaining clear. The agreement should also address international transfers where relevant and require appropriate records and cooperation with regulatory enquiries.

Clarify ownership and permitted use. The customer should know who owns its data, configurations, documentation, credentials, business records and bespoke materials. The provider may retain ownership of pre-existing tools, templates, methods or general technical knowledge, but the agreement should define the customer’s right to use materials needed to operate its environment. It should also cover software licensing responsibilities, restrictions on copying or transferring licences, and what happens to provider-owned tools when the relationship ends.

Deal with third parties and dependencies. IT services commonly depend on internet carriers, cloud platforms, software publishers, hardware suppliers and other specialists. The contract should identify whether the provider is responsible for procuring and managing those services, whether third-party charges are passed through, and how failures outside the provider’s control are handled. It should not allow the parties to assume that a supplier’s terms automatically match the outsourced IT agreement. Any flow-down obligations, warranties or limitations should be reviewed for consistency.

Allocate risk fairly. Liability provisions should address the types of loss that can arise from service failures, data incidents, confidentiality breaches, intellectual property claims and unauthorised access. The agreement may contain exclusions, financial caps and separate treatment for specific high-risk matters. These terms need to be considered alongside the actual services, insurance arrangements and the customer’s dependence on the provider. Broad exclusions should not unintentionally remove responsibility for obligations that the parties consider fundamental.

Record commercial mechanics. The agreement should state how invoices are issued, when payment is due, how disputed amounts are handled and which work attracts additional charges. It should distinguish recurring charges from project fees, usage-based costs, pass-through expenses and approved purchases. It should also explain how price changes, tax treatment, renewals and unapproved work are managed. A clear approval process helps prevent an operational request being interpreted as authority for unlimited expenditure.

Control changes and new requirements. A change procedure should identify who can request a change, what assessment is required and when the change becomes binding. The assessment may cover cost, timescale, security, compliance, service impact, dependencies and implementation risk. Emergency changes should have a separate process with appropriate records and later review. This is preferable to relying on verbal instructions, particularly where a change affects access, resilience or regulated information.

Address continuity and exit without leaving a gap. The agreement should require cooperation if either party needs to invoke its continuity arrangements or if a serious disruption affects the services. It should also define the practical steps for handover, including documentation, configuration information, credentials, data formats, equipment, licences and knowledge transfer. Any assistance charges, timescales and customer responsibilities should be agreed in advance. The objective is to make the end of the relationship orderly and technically achievable, rather than leaving essential information or access dependent on goodwill.

Before signing, the business should compare the contract with the provider’s proposal, security questionnaire, technical design and internal responsibilities. Ask whether every important assumption is written down, whether the promised service can be measured, and whether the business could continue operating if a disputed point arose. Legal advice is appropriate where the agreement involves substantial data processing, regulated activities, complex liability arrangements or significant operational dependency.