An enterprise software engagement runs on two documents. The master services agreement holds the terms that do not change between projects: intellectual property assignment, confidentiality, data protection, liability, termination and dispute resolution. Each statement of work holds the project specifics: scope, deliverables, acceptance criteria, timeline, price, team and the change control procedure. The clauses that matter most in practice are IP assignment on payment, written acceptance criteria, a change process with a turnaround time, and termination for convenience with a handover obligation.
Software contracts are read twice: once at signing, by lawyers, and once eighteen months later, by the people trying to work out who pays for the thing that went wrong. The second reading is the one that matters, and it is usually about four clauses. This post is for the program manager, CIO or procurement lead structuring an engagement with a development partner. It explains how the master agreement and the statement of work divide the work, which clauses decide outcomes, and how change requests should operate so that they are a tool rather than a tax. It is a practitioner's view, not legal advice, and your counsel should review any contract you sign.
What goes in the MSA and what goes in the SOW?
The master services agreement is signed once and governs every project with the vendor. The statement of work is signed per project, or per phase, and refers back to the MSA. Keeping them separate means the second and third projects start in days rather than weeks, and it keeps the legal review focused on terms that are actually new.
| Topic | Master services agreement | Statement of work |
|---|---|---|
| Intellectual property | Assignment of all deliverables to you on payment; license to vendor's pre-existing tools; open-source handling | Any project-specific exceptions, named third-party components |
| Confidentiality and data protection | NDA terms, data processing agreement as a schedule, security obligations, subcontractor approval | The specific data and systems in scope, environments, access list |
| Scope and deliverables | How SOWs are formed and amended | The scope, exclusions, deliverables, milestones and timeline |
| Acceptance | The general acceptance procedure and review period | The acceptance criteria for each deliverable, who signs |
| Price and payment | Rates card, invoicing terms, expenses, late payment | The price, pricing model, payment schedule tied to milestones |
| Change control | The procedure and turnaround commitment | Any contingency or pre-approved change budget |
| Team | Key personnel and replacement rules, non-solicitation | Named roles and people, allocation, your-side responsibilities |
| Warranties and liability | Warranty period, remedies, liability cap and exclusions, insurance | Any project-specific warranty, for example on performance targets |
| Termination | For cause, for convenience, notice periods, handover obligations, escrow if any | What is paid for work in progress if this SOW ends early |
| Governance | Escalation path, dispute resolution, governing law | Meeting cadence, reporting, steering committee for this project |
Which clauses actually decide outcomes?
Intellectual property assignment
The deliverables, meaning the source code, designs, documentation and data models, should be assigned to you on payment of the relevant invoice. Not on final payment of the whole program, which leaves you owning nothing until the end, and not "licensed", which leaves the vendor owning it. The vendor keeps ownership of its pre-existing tools and frameworks and grants you a perpetual license to anything of theirs embedded in your system. Open-source components stay under their own licenses, and the SOW should list any with obligations. Who owns the code walks through the practical side: repositories, accounts and domains in your name from the start.
Acceptance criteria
Every deliverable needs a written statement of what "done" means, agreed before the work starts, and a review period after which it is deemed accepted if you have not responded. Without criteria, acceptance becomes an argument. Without a review period, projects stall on a sign-off nobody owns. Good criteria are testable: "the import handles the three sample files in Appendix B without error and completes in under five minutes" rather than "the import works".
Change control
The procedure for changing the scope, price or timeline of a signed SOW. It must say who can raise a change, what a change request contains, how quickly the vendor prices it, who approves, and that nothing changes until it is signed. The turnaround matters: a vendor that takes three weeks to price a change blocks the program. Five working days is reasonable for most changes.
Termination for convenience
You should be able to end a SOW on notice, usually thirty days, paying for work completed and work in progress to the date of termination. The clause should also oblige the vendor to hand over all code, documentation, credentials and knowledge within the notice period, at the normal rates. This is the clause that makes every other clause enforceable, because it is what gives you the option to walk away.
Liability, in plain terms
Vendors cap their liability, usually at the fees paid under the SOW or over the previous twelve months. That is normal. What you should check is what sits outside the cap: breach of confidentiality, data protection, IP infringement and gross negligence are commonly excluded from the cap, and should be. Ask for professional indemnity and cyber insurance at a stated level. Then stop negotiating liability and start negotiating acceptance criteria, which prevent far more disputes than any cap resolves.
Escrow
Source code escrow matters when the vendor hosts or operates the system and you could not run it without them. If the code lives in your repository and the environments are in your accounts, escrow adds little. If it does not, insist on it, with a release trigger for insolvency and for material breach.
How should change requests work?
Change requests are not a sign of failure. On a well-scoped program they run 10 to 20 percent of the contract value, and the organizations that budget for them have calmer programs than the ones that treat every change as a dispute. The point of the process is to make the cost of a decision visible before it is taken.
- Anyone can raise one, in writing, through a single channel. Verbal changes in a review meeting are the main source of "we never agreed that".
- The vendor assesses impact on scope, effort, price, timeline and other deliverables within a fixed turnaround.
- A named approver on your side decides, with a threshold above which the steering committee is involved.
- Nothing starts until the signed change is attached to the SOW. This protects both sides.
- A change log is reviewed monthly, so the program's drift is visible and the budget for changes is tracked against the contingency.
Build the contingency into the budget rather than discovering it in month eight. How to budget a multi-year software program covers where the 15 to 25 percent goes.
A change request structure you can copy
| Field | Content |
|---|---|
| Reference | CR number, SOW reference, date raised, raised by |
| Description | What is being requested, in one paragraph, and why |
| Affected deliverables | Which items in the SOW change, and how their acceptance criteria change |
| Effort and price | Additional or reduced effort by role, resulting price change, and the pricing basis |
| Timeline impact | Effect on milestones and the go-live date |
| Risks and dependencies | What this change makes harder or depends on |
| Alternatives considered | Cheaper or later ways to get most of the value |
| Decision | Approved, declined or deferred, by whom, on what date, with signatures |
The "alternatives considered" row is the one most templates omit and the one that saves the most money. A good vendor will often propose a smaller change that achieves the same business outcome.
Which pricing model does the contract assume?
A fixed-price SOW needs strong acceptance criteria and a disciplined change process, because every ambiguity becomes a change. A time-and-materials SOW needs a rate card, an estimate, a cap or a not-to-exceed figure, and reporting that shows burn against the estimate. Many enterprise programs use both: a fixed price for discovery and the first release, time and materials or a monthly team fee afterwards. Fixed price vs time and materials covers when each is right, and dedicated team vs project-based vs staff augmentation covers the engagement shapes each pricing model usually accompanies.
Before you sign, confirm in writing
- IP assigned to you on payment of each invoice, not at the end.
- Testable acceptance criteria for every deliverable, with a review period.
- A change process with a five-day pricing turnaround and a named approver.
- Termination for convenience with a handover obligation.
- Confidentiality, data protection and IP outside the liability cap.
- Named key people and the rule for replacing them.
- Repositories, cloud accounts and domains in your name.
How 7L contracts
7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens. Across more than one hundred organizations we have found that the engagements with the fewest disputes are the ones with the clearest acceptance criteria, so we write them with the client before the SOW is signed, and we assign IP on payment of each invoice as standard. We price changes within five working days, we propose the cheaper alternative when there is one, and our termination clause includes a full handover because we would rather be kept on merit. If you are structuring a contract for an enterprise software program and want a vendor's view of the terms before your lawyers see them, talk to us. This post is general guidance and not legal advice.
Frequently asked questions
What is the difference between an MSA and a SOW?
The master services agreement is signed once and sets the terms that apply to every project with a vendor: IP assignment, confidentiality, data protection, liability, termination and dispute resolution. A statement of work is signed per project or phase and sets the specifics: scope, deliverables, acceptance criteria, timeline, price and team. The SOW refers to the MSA, so new projects can start without renegotiating the legal terms.
Should IP be assigned on final payment or as we go?
As you go, on payment of each invoice. Assignment only on final payment means you own nothing if the engagement ends early, which weakens your termination rights and your position in any dispute. Vendors keep their pre-existing tools and frameworks and license them to you perpetually for use in your system.
How much should we budget for change requests?
On a well-scoped program, 10 to 20 percent of the contract value. Hold it as a contingency line that the steering committee controls, track the change log against it monthly, and treat a program that is consuming it faster than that as a signal that the scope or the discovery was weak, not as a vendor problem to be argued over change by change.
Do we need source code escrow?
Only if you could not run the system without the vendor, for example when they host it in their own accounts or when key components are theirs. If the code is in your repository, the infrastructure is in your cloud accounts and the documentation is delivered as you go, escrow adds cost and little protection. If any of those are not true, fix that first and consider escrow second.
What is a reasonable liability cap for a software development contract?
A cap at the fees paid under the SOW, or over the preceding twelve months, is the usual range and is generally acceptable. What matters more is what is excluded from the cap: breach of confidentiality, data protection obligations, IP infringement and gross negligence should sit outside it. Ask for professional indemnity and cyber insurance at a level proportionate to the program. Then spend your negotiating effort on acceptance criteria, which prevent more disputes than any cap resolves.