Master Service Agreement for IT Services: Key Terms
Cooperation between an IT company and a customer is rarely limited to a single task. Today, it may involve the development of new functionality, while later the parties may decide to cooperate on testing, technical support, design, or the engagement of a dedicated team of specialists. Entering into a separate comprehensive agreement for each project is not always convenient, especially where the parties are planning a long-term relationship.
A Master Service Agreement, or MSA, is used precisely in such cases. It is a framework agreement under which the parties agree once on the general rules of their cooperation: the procedure for ordering and paying for services, the transfer of intellectual property rights, confidentiality, liability, the term of the agreement, and the termination procedure.
At the same time, the MSA itself usually does not contain a detailed description of each task. The parties specify the terms of a particular project in a Statement of Work, Service Order, technical specification, or another appendix.
We therefore propose examining which provisions should be included in a Master Service Agreement for IT services and its related documents, as well as what should be considered when reviewing a counterparty’s contract template.
MSA and Statement of Work: How Should the Terms Be Allocated?
The main feature of a master agreement is its framework nature. It establishes the rules applicable to the parties’ entire cooperation, while the SOW sets out the terms of a particular project or project stage.
| Master Service Agreement | Statement of Work |
|---|---|
| General subject matter of the agreement | Specific list of services, delivery periods, and project stages |
| Procedure for determining fees, making payments, and issuing invoices | Specific service fees, hourly rates, project or milestone fees, and similar terms |
| Legal regime governing intellectual property | List of deliverables and the procedure and time limits for their delivery and acceptance |
| Confidentiality, non-solicitation, and non-compete obligations | Specific composition of the team of engaged specialists, where relevant |
| Liability, term, and termination | Term of the SOW |
The agreement should expressly specify which document prevails in the event of a conflict. For example, the parties may agree that the specific terms of an SOW prevail over the IT services agreement only in relation to the relevant project. If no hierarchy of documents is established, the same arrangement may be interpreted differently.
It is also necessary to determine how an SOW is agreed and signed and from which moment it becomes effective. This is particularly relevant for IT projects, since some arrangements are often recorded through email, task-management systems, or messaging platforms, meaning that the SOW may be further detailed through separate communications.
How Should the Subject Matter and Cooperation Model Be Defined?
The review of a Master Service Agreement should begin with a simple question: does the text of the agreement reflect the parties’ actual arrangements?
Even before signing the contract, the customer and the service provider usually agree on the types of services, time frames, format of cooperation, budget, and payment procedure. These terms must be correctly reflected in the agreement and its appendices.
The subject matter of a framework agreement should not be so narrow that every new service requires the entire agreement to be signed again. At the same time, wording such as “the service provider shall provide any services requested by the customer” also creates risks, since it does not make it possible to determine the actual scope of the obligations.
Particular attention should be paid to the cooperation model.
For a Time and Materials model, the parties should agree on the hourly service rate, the time-tracking procedure, timesheets, and limits on the number of hours.
For a Fixed Price model, the scope of work, deadlines, milestones, and the procedure for changing the technical specification should be clearly defined.
For a Dedicated Team or outstaffing model, the agreement should specify the composition of the team, the procedure for replacing specialists, the minimum workload, and the notice periods for reducing the team.
In practice, the Agile model is becoming increasingly common. Under this model, development is divided into separate iterations or sprints, while tasks may change during the project. In such a case, the MSA should not establish every technical detail but should instead provide a clear mechanism for agreeing on the backlog, priorities, time frames, and cost of the work.
Service Fees, Invoices, and Acceptance of Deliverables: What Should Be Considered?
Financial terms are among the most sensitive provisions of a Master Service Agreement. The parties should determine the currency, rates, invoice issuance and payment deadlines, reimbursement of expenses, bank charges, and the possibility of revising the service fees.
Where hourly billing applies, the agreement should establish the procedure for tracking and approving the time spent. To protect the customer, a maximum number of hours or budget may be set, which may be exceeded only with separate approval.
For the service provider, it is important to establish a time limit for disputing an invoice and the right to suspend the services in the event of late payment.
It is equally important to regulate the acceptance of deliverables. The agreement should specify:
- what constitutes a deliverable;
- how it is transferred to the customer;
- how much time the customer has to review it;
- what form the customer’s comments must take;
- what happens if the customer does not respond;
- how a defect is distinguished from a new requirement.
We recommend avoiding provisions under which the deliverable must simply “fully satisfy the customer.” Acceptance criteria should be objective and linked to the SOW, technical specification, or agreed standards.
It is also worth checking whether penalties or other financial consequences are included in less obvious provisions, such as sections relating to deadlines, reporting, payment, an NDA, or termination.
Intellectual Property, Open Source, and Artificial Intelligence
In an MSA for IT services, the intellectual property section is one of the key provisions. First, the parties must distinguish between deliverables created specifically for the customer and the service provider’s pre-existing materials.
Background IP may include internal libraries, templates, frameworks, tools, methodologies, and know-how that existed before the project began or are used in work for different customers.
Unless a separate regime is established for such materials, broad wording assigning “all rights to everything created and used” may effectively deprive the service provider of the right to use its own tools in other projects.
The MSA should also specify when the rights are transferred to the customer: upon creation, upon delivery of the relevant deliverable, or after full payment. In practice, it is safer for the service provider to transfer the rights after receiving payment for the relevant services.
It is also difficult to imagine a modern agreement without provisions governing open source and AI.
With regard to open source, the agreement should expressly determine whether its use is permitted, which licences are acceptable, whether the customer’s prior approval is required, and who is responsible for any breach of the applicable licence terms.
The AI provisions should reflect the team’s actual practices. Where developers use generative tools to write code, perform testing, create designs, or produce text content, the agreement should define the limits of such use.
In particular, it should specify whether code, personal data, or confidential information may be uploaded to AI services, whether AI-generated content may be included in the deliverables, and who is responsible for conducting a human review.
A simple permission to use AI does not resolve every issue. It is also advisable to establish an obligation to review and test the output and to ensure that it does not infringe third-party rights.
What About Confidentiality and Data Security in an IT Contract?
An MSA usually contains a separate confidentiality section or refers to an NDA. It should define which information is confidential, the purposes for which it may be used, who may have access to it, and how long the relevant restrictions remain in force.
For IT services, this is often insufficient. Where the service provider has access to the customer’s personal data, systems, or infrastructure, a DPA and separate security requirements may also be required.
The parties should agree on the incident-notification procedure, rules governing access by subcontractors, and the return or deletion of data after the cooperation ends.
Where the customer requires compliance with ISO or other standards, the agreement should clearly identify the specific standard, the scope of its application, and the method for verifying compliance.
A general obligation to “comply with all applicable standards” may be insufficient and vague or, conversely, excessively burdensome for the service provider.
How Should Liability Be Drafted and Risks Limited?
Counterparties often seek to regulate the other party’s liability in as much detail as possible, including penalties, compensation, and indemnities. When drafting the MSA, it is therefore important to assess not only the amount of liability but also the grounds on which it may arise.
The agreement should establish an overall liability cap, for example, equal to the amount paid during a particular period or under the relevant SOW.
The parties may separately agree on exceptions to the cap, for example, for breaches of confidentiality, IP obligations, or data protection requirements. However, such exceptions should not automatically make all of the service provider’s liability unlimited.
It should also be checked:
- whether indirect and consequential damages and loss of profit are excluded;
- whether a penalty, damages, and an indemnity may be recovered simultaneously for the same breach;
- whether the party has the right to control the defence against third-party claims;
- whether the time limit for bringing claims is restricted;
- whether liability is mutual and balanced.
The law of the chosen jurisdiction must also be taken into account, since the enforceability of penalties, non-compete provisions, and certain limitations of liability may differ significantly. We discussed the requirements for the validity of non-compete provisions in detail in this article.
Term and Termination of the MSA: How Can the Cooperation Be Ended?
In the IT industry, the duration of a project and the possibility of ending the cooperation are of practical importance to both parties. A company should understand how quickly the customer may discontinue the services, whether the work already completed will be paid for, and what will happen to the reserved team.
The MSA should specify its term, the automatic renewal procedure, termination on specific grounds, or termination for cause, and unilateral termination at the request of a party, or termination for convenience.
In the event of a breach, the agreement usually provides for a cure period, meaning a period during which the party may remedy the breach before the agreement is terminated.
It is also important to distinguish between the termination of an individual SOW and the termination of the entire MSA. The completion of one project should not always automatically terminate the framework agreement and all other active orders.
When drafting the terms or reviewing a counterparty’s draft, attention should be paid to the consequences of termination, including:
- payment for the services actually provided;
- transfer of completed and unfinished deliverables;
- return of equipment and access credentials;
- deletion or return of confidential information;
- transition assistance;
- provisions that survive the termination or expiry of the agreement.
A counterparty’s right to terminate immediately or under a simplified procedure may be hidden not only in the termination section but also in a separate SOW, SLA, or provisions relating to missed deadlines. The lawyers of Legal IT Group discussed other matters that should be considered when reviewing an agreement with an IT company in this article.
To summarise, before signing a Master Service Agreement, we recommend considering, in particular, the following questions:
- Does the agreement reflect the actual commercial arrangements?
- Is it clear how SOWs are entered into and amended?
- Which document prevails in the event of a conflict?
- Are the payment model and the procedure for approving hours correctly defined?
- Are there objective acceptance criteria for the deliverables?
- When are the intellectual property rights transferred?
- Is the service provider’s Background IP protected?
- How is the use of AI and open source regulated?
- Has a reasonable liability cap been established?
- Are the termination provisions and their consequences balanced?
- Does the agreement comply with the law of the chosen jurisdiction?
A Master Service Agreement is therefore not merely a universal template for all future projects. A properly drafted MSA should create a stable legal basis for cooperation while leaving the parties sufficient flexibility to agree on individual tasks, budgets, and deadlines.
For this reason, when preparing or reviewing an agreement, it is important to analyse not only its individual provisions but also the entire system of documents: the MSA, SOWs, SLA, DPA, technical specifications, and the parties’ agreed communications.
This approach helps minimise legal and financial risks and makes the cooperation more predictable for both parties.
Should you require professional assistance with preparing your own draft or negotiating a proposed agreement with a counterparty, please contact Legal IT Group.
The lawyers of Legal IT Group will assist at every stage of an IT company’s contract work, take the relevant risks into account, and propose solutions aimed at protecting the company’s interests to the greatest possible extent.