Extensive Statement of Work template (SOW) identifying all possible aspects to be included in an SOW, including detailed guidance notes

The Statement of Work template (SOW) is assumed to be attached to a framework agreement (e.g. a General purchasing agreement) or a Master Services Agreement (MSA), as is normally the case for any Statement of Work or SOW. A Statement of Work is an agreed mostly technical project description that details the project’s objectives, tasks, deliverables, timeline and costs, typically used in contracts between a customer and a supplier. It serves to ensure all parties have a shared understanding of the project, preventing scope creep and disputes by clearly outlining expectations, roles, and responsibilities.

The template Statement of Work or SOW contains checklist points for:

Introduction and background: a high-level summary of the project’s goals and objectives.
Scope of work: a detailed description of the specific tasks and services to be performed, including what is and isn’t included.
Deliverables: a list of the specific products, services, or results that will be provided upon project completion.
Project timeline and milestones: a detailed schedule with start and end dates, deadlines for specific tasks, and milestones to track progress.
Roles and responsibilities (RACI matrix): a clear definition of who is responsible for each task and role, including both the client and the supplier.
Project management and governance
Customer obligations
Service provider obligations
Service levels and performance standards
Charges and payment terms
Intellectual property rights
Changes and variations
Acceptance testing and criteria
Warranties and representations
Term and termination
Transition and handover
Location and working arrangements
Confidentiality and data protection
Insurance and liability
Compliance and regulatory requirements
Dispute resolution
Definitions and interpretation
Schedules and appendices

The guidance below provides you a detailed explanation of each section in the SOW template, its legal and commercial significance, and key negotiation considerations (or indications of where and how the parties’ interests deviate – not necessarily an Statement of Work’s negotiation point).

1. Introduction and background of a Statement of Work

Purpose and importance

Establishes the contractual framework and relationship between the SOW and the MSA. Critical for determining order of precedence and avoiding conflicts between documents.

Key elements

Business context: Whilst not strictly legally operative, helps both parties understand objectives and can be relevant for interpretation disputes or discussions about whether variations are within contemplated scope.
Order of precedence: If the SOW conflicts with the MSA, which prevails? Typically, SOW should prevail for project-specific matters (scope, price, deliverables) whilst MSA prevails for general commercial terms (liability, insurance, termination rights). This must be explicitly stated in the general provisions section.
SOW reference number: Administrative necessity for managing multiple concurrent SOWs under one MSA.
MSA reference: Confirms this SOW is governed by the overarching MSA terms. Essential for incorporating liability caps, insurance, indemnities, and other commercial protections without repeating them.
- Service providers may resist detailed business context if it could be used to imply additional obligations or quality standards beyond express commitments.

2. Scope of work

Purpose and importance

The single most important section for managing risk and preventing scope creep. Defines the boundaries of the service provider’s obligations and protects both parties from assumptions about what is included.

Key elements

In-scope activities: Positive definition of what service provider will do. Should be sufficiently detailed to be enforceable but flexible enough to accommodate reasonable interpretation.
Out-of-scope items: Express exclusions prevent disputes. Particularly important where customer might reasonably assume something is included (e.g., “integration with third-party systems not identified in Schedule 8”).
Assumptions: Often overlooked but critical. If assumptions prove incorrect, who bears the risk? Should trigger change control process.
Dependencies: Identifies where performance depends on customer actions, third parties, or service provider’s other obligations. Allocates delay risk.

Where party interests deviate…

Assumptions: Heavily negotiated, because if an assumption appears to be incorrect, it justifies extra work (and extra charges). While an assumption clarifies what may be uncertain in the scope of the SOW, an expert (i.e. the service provider) may be expected to know or clarify quickly whether the assumed facts or circumstances are present (and fix it) instead of leaving the customer with the consequences of assumed uncertainty. A service provider would prefer an extensive list to limit risk; whereas the customer will reduce assumptions or ensure they’re verifiable before contract signature. Consider requiring customer sign-off on assumptions schedule.
Scope creep: Service providers typically want very narrow scope definition; customers want flexibility. Balance through a robust change (or variations) control process.
Dependencies: Who bears risk if dependency not met? Service provider typically wants relief from performance obligations and price/time adjustments; customer wants service provider to use reasonable endeavours to mitigate or flag risks early.
Exclusions: Customer should scrutinise carefully. Service providers sometimes exclude items that customer considers integral to project success (e.g., “data migration” or “user training”).

3. Deliverables in a Statement of Work (template)

Purpose and importance

Converts abstract scope into concrete, measurable outputs. Essential for acceptance testing, payment triggers, and determining whether service provider has fulfilled obligations. Poor deliverable definitions are the primary source of project disputes.

Key elements

Specifications: Must be objective and verifiable. Avoid subjective terms like professional quality or fit for purpose without defining what it means.
Acceptance criteria: Should mirror deliverable specifications. If criteria are different or less detailed than specifications, disputes will arise about whether deliverable meets requirements. A grey area translates partly into the payment or compensation mechanism to determine the outcome of non-accepted deliverables (or a dispute to arise).
Ownership: May differ from IP ownership. Physical deliverable ownership may transfer whilst IP remains with service provider (or vice versa).
Rejection and remediation: Time limits for service provider to cure defects are critical. Without them, project timelines become uncertain and customer’s termination rights may be restricted.

Where party interests deviate…

Specificity: Service providers resist overly detailed specifications (increases delivery risk and reduces flexibility); customers need sufficient detail to ensure deliverables meet business needs. Consider using examples, mock-ups, or reference standards.
Acceptance criteria: Service providers prefer objective, technical criteria; customers often want functional or business outcome criteria. Hybrid approach typically works best: technical criteria for objective assessment, plus limited functional testing.
Deemed acceptance: Service providers typically want deemed acceptance if customer doesn’t respond within testing period; customers resist this strongly. Compromise: deemed acceptance for non-material deliverables only, or extend testing periods to reduce customer risk.
Remediation cycles: How many attempts does service provider get? Unlimited remediation is unacceptable to customers; one attempt is often too few for complex technical deliverables. Two to three remediation cycles with defined timescales is typical.

4. Project timeline and milestones in SOWs

Purpose and importance

Creates temporal framework for project and establishes when obligations arise. Critical for payment triggers, termination rights, and determining whether delays are actionable. Interfaces closely with consequences provisions in the MSA.

Key elements

Milestones: Should align with deliverable completion, not just activities. “Complete design phase” is less useful than “deliver design specification for acceptance”.
Dependencies: Timeline assumptions about customer actions (e.g., “customer to approve design within 10 business days of delivery”).
Delay consequences: Without express provisions, common law remedies for delay are uncertain, especially if MSA limits consequential loss. Must specify: time extensions, price adjustments, termination triggers, liquidated damages (if any).

Where party interests deviate…

Fixed vs indicative dates: Service providers want “target” or “estimated” dates; customers want firm commitments. Compromise depends on project certainty and risk allocation. Consider: firm dates for early milestones, indicative dates for later stages, with re-baselining at intervals.
Customer delay: Service providers will insist on relief if customer delays (missing approval deadlines, failing to provide access/resources). Customers should ensure relief is proportionate to actual impact and requires notice and mitigation efforts.
Force majeure interaction: How do force majeure provisions in the MSA interact with SOW timeline? Consider whether some delays (e.g., technology supply chain issues) should be service provider’s risk even if they might disqualify as a force majeure event.
Liquidated damages: If included (rare in SOWs under MSAs), heavily negotiated, probably the result of seeking reward for ‘overperformance’ or protection against (repeated past) disappointments. Under common law, LD-amounts should align with a genuine pre-estimate of loss. Service providers will want caps (typically lower than general liability cap) and exclusions (e.g., no LDs if delay caused or contributed to by customer). Customers must consider whether LDs are their ‘sole remedy’ or additional to other rights.

5. Roles and responsibilities (RACI matrix)

Purpose and importance

Prevents disputes about who does what and avoids gaps where neither party believes something is their responsibility. RACI (who are Responsible, Accountable, Consulted, Informed) provides clear allocation without unnecessary duplication.

Key elements

Governance structure: Who has decision-making authority? Critical for change control, acceptance decisions, and escalations.
Key personnel: Named individuals create dependencies and may require substitution provisions. Consider: minimum qualification requirements, customer approval rights for substitutions, notice periods.
RACI matrix: Should cover all significant project activities. Pay particular attention to activities at interface between parties (e.g., testing, deployment, training).

Where party interests may deviate…

Key personnel: Customers typically want named individuals locked in; service providers want flexibility. Compromise: name key roles (e.g., project manager, technical lead) with qualification requirements and substitution only with equivalent or better qualified personnel and customer consent (not to be unreasonably withheld).
Customer resource commitments: Service providers may want customer to commit named (or non-switching) resources or minimum time commitments. Customers resist binding obligations about their own resources. If included, ensure consequences of customer resource unavailability are proportionate (time extension, possibly price adjustment, but not wholesale relief from performance obligations).
Decision-making authority: Who can approve changes, accept deliverables, agree variations? Service providers want clear, limited list (reduces risk of unauthorised variations or acceptance disputes). Customers want flexibility. Consider: general authority levels in MSA, specific authority matrix for this SOW.
Escalation: Cases of disagreement should be addressed in the MSA, but failing a proper de-escalation, in case of large or complex SOW-projects, stipulating for an escalation is recommended (bote that periodical evaluations or a small-scale dispute resolution ‘board’ may be equally effective). In some cultures, escalation is truly undesirable. Service providers want rapid escalation to prevent delays; customers want working-level resolution before escalation. Tiered escalation (working level > project sponsor > executive) with defined timeframes at each tier is typical.

6. Project management and governance of SOW-projects

Purpose and importance

Establishes how project will be managed and how parties interact. Good governance prevents disputes by identifying and addressing issues early. Poor governance leads to ‘surprise’ problems at project end.

Key elements

Methodology: If service provider prefers a specific methodology (Agile, Waterfall, Prince2), make this explicit. It affects how scope, changes and acceptance testing are managed.
Change control (variation): Changes or variations procedures should be provided in the MSA (and if so, likely be avoided in the SOW, except if the scope or nature of the SOW ‘dictates’ a more finetuned or accelerated approach. Detailed process for identifying, assessing, approving and implementing changes. Such arrangement must specify who can request changes (authorisation), assessment timeline, approval authority and impact on price and timeline.
Risk and issue management: Process for identifying, escalating, and resolving risks and issues. Without formal process, parties may not understand severity or required actions.
Reporting: Frequency, content, and format. Should include progress against plan, risks, issues, and changes. Essential for customer’s own governance and early warning of problems.

Where party interests may deviate…

Methodology: Service providers want freedom to use their preferred methodology; customers may have mandated approaches or want oversight of methodology choice. If Agile methodology, pay careful attention to how deliverables and acceptance are defined (traditional acceptance model does not fit Agile well).
Reporting burden: Customers want detailed, frequent reporting (as it reinforces some level of discipline on time spent and means to spot and interfere in delays); service providers view it as unproductive overhead. Balance based on project risk, complexity, and value. Consider: standard template reports, exceptions-based reporting for routine projects, dashboard/portal access in lieu of formal reports.
Change control (variations) formality: Service providers want formal change control for everything (protects against scope creep); customers want flexibility for minor changes. Consider: de minimis threshold below which informal changes allowed, expedited process for urgent changes, formal process only for changes affecting price or critical milestones.
Meeting cadence: Customers want frequent meetings; service providers want to minimise time spent in meetings. Specify minimum meeting requirements (weekly status, fortnightly governance) but allow parties to agree more or less frequent meetings as project progresses.

7. Customer obligations under a Statement of Work

Purpose and importance

Often underemphasised but critical for service provider risk management. If customer fails to meet obligations, service provider should have remedies (time extensions, price adjustments, suspension rights or even termination). Without express obligations, proving customer caused delays is difficult.

Key elements

Information provision: What information must customer provide, when, and in what format? Consider: accuracy warranties (does customer warrant that provided data and information be accurate or provided “as is”?).
Decision-making timeframes: Critical for maintaining project timeline. Without defined deadlines, customer can stall project indefinitely. Should mirror project timeline assumptions.
Third-party arrangements: Identify where customer must procure third-party services or licences necessary for SOW-project success.
Access: Physical access to premises, systems access, access to personnel for interviews/workshops. Include security requirements and notice periods.

Negotiation considerations

Consequences of breach: Service providers may want strong remedies including suspension and termination rights; customers resist these strongly. Compromise: time extensions and price adjustments as primary remedies, suspension only after repeated breaches and escalation, termination only for persistent material breaches.
Materiality threshold: Not all customer obligations are equally important. Consider categorising: critical obligations (delay triggers immediate relief), material obligations (delay triggers relief after notice period), administrative obligations (breach doesn’t necessarily trigger damages but may be relevant to overall performance assessment).
Customer resources: If customer must provide resources (e.g., business analysts, testing team), specify: quantity, qualifications, availability, as well as consequences if not provided. Customers should resist making resource provision a condition precedent to service provider’s obligations.

8. Service provider obligations under an SOW

Purpose and importance

Complements scope of work with operational and qualitative obligations. Whilst scope defines what service provider will deliver, this section defines how and to what standard.

Key elements

Quality standards: Applicable professional standards, industry codes or customer standards. Consider: ISO standards, industry-specific standards (e.g., BSI standards), customer’s internal standards.
Knowledge transfer: How will service provider ensure customer can operate/maintain deliverables? Formal training, documentation, shadowing, warranties period with support.
Documentation: What documentation must service provider produce? Technical documentation, user guides, training materials, source code comments, architecture diagrams.
Compliance: Must service provider comply with customer policies (e.g., security policies, code of conduct, local site regulations)? Consider: which policies, how notified, consequences of non-compliance.

Negotiation considerations

Duty of care vs fitness for purpose: Service providers typically offer to perform with ‘reasonable skill and care’ or ‘make reasonable endeavours’ (professional services standard); customers often want ‘fit for purpose’ warranty (outcome-based standard). Former is more favourable to service provider and typical for bespoke development; latter is more appropriate for off-the-shelf solutions. Consider hybrid: reasonable skill and care for services, fitness for purpose for deliverables meeting agreed specifications.
Knowledge transfer scope: How much knowledge transfer is included in base price? Service providers want to limit (e.g., train-the-trainer model, documentation only); customers want comprehensive training for all users. Consider: core training included, additional training as optional variation.
Standards applicable: Customers want compliance with high or defined standards (ISO 1certifications, industry best practice); service providers want flexibility or to apply their own standards. Specify: must comply with X standard, or will comply with own professional standards (not less demanding than Y standard).
Documentation format: Service providers want to provide documentation in their standard format; customers may require specific formats or integration with their documentation systems. Agree format requirements early to avoid surprises at delivery.

9. SOW service levels and SOW performance standards

Purpose and importance

Often omitted from project-based SOWs but can be critical for longer-term projects or where SOW includes support/maintenance elements. Provides objective performance measurement and remedies for underperformance.

Key elements

Targets: What level of performance is required? Consider: industry norms, customer’s business requirements, service provider’s capability. Should be realistic but stretching.
Metrics: What will be measured? Uptime, response times, defect rates, delivery timeliness. Must be objectively measurable.
Measurement methodology: How will performance be measured? Who measures? What data sources? What happens if measurement systems fail?
Remedies: What happens if targets are not met? Service credits, price reductions, additional resources, termination rights?

Negotiation considerations

Applicability: Are SLA metrics appropriate for this project? Typically more relevant for ongoing services or operational support than one-off delivery projects. For delivery projects, acceptance criteria usually suffice.
Service credits vs termination: Service providers prefer service credits (predictable, capped financial consequence); customers want termination rights for persistent underperformance. Consider: service credits for individual breaches, termination rights if persistent or severe underperformance.
Baseline period: For newly developed systems, consider baseline period during which SLA metrics don’t apply or reduced targets apply (system stabilisation period).
Customer dependencies: Service provider will want SLA metrics to be suspended or performance excused if customer causes or contributes to performance issues. Customers should ensure this relief is proportionate and requires notice.

10. Charges and payment terms in a Statement of Work

Purpose and importance

Core commercial terms. Must be clear, comprehensive, and aligned with the project structure and deliverables. Needless to say that ambiguity leads to disputes and postponed payment.

Key elements

Fee structure: Fixed price, time and materials (T&M), or a mix. Fixed price transfers delivery risk to service provider; T&M limits service provider risk but creates budget uncertainty for customer.
Payment schedule: Linked to milestones or deliverables, or periodic (monthly)? Milestone-based is typical for project work and aligns payment with value delivery.
Rate card: If any T&M elements, rates for each resource type. Should specify: currency, what’s included (expenses?), variation mechanism.
Expenses: What expenses are reimbursable? Typical categories: travel, accommodation, materials. Consider: pre-approval requirements, caps, expense or reimbursement policy compliance.
- The following should be addressed in the MSA (and not be addressed or deviated from in an SOW):
Price variation mechanisms: For longer projects, service providers may want price escalation provisions (CPI-linked or other). Customers typically resist. If included: specify index, frequency of adjustment, caps.
Payment terms: Service providers want short payment terms (14-30 days); customers often have standard terms (30-60 days) and resist special terms for individual suppliers. Late payment interest and suspension rights are typically in MSA but may need SOW-specific provisions.
Tax treatment: Is price inclusive or exclusive of VAT? Who bears risk of tax changes? Typically, prices are exclusive of VAT and customer bears VAT, but service provider bears risk of other tax obligations.

Negotiation considerations

Payment trigger: Although these parameters should be in the MSA, SOW-particularities may ‘demand’ tailored provisions on when payment obligations arise. Service providers want: invoice on delivery; customers want: invoice after acceptance. Compromise: invoice on delivery, payment after acceptance, or invoice after acceptance but customer must accept or reject within defined timeframe otherwise acceptance is deemed to be given and invoice becomes payable.
Retentions: Customers often want to retain portion of price (typically 10% to 20%) until final acceptance or defects liability period expires. Service providers resist retentions strongly (cash flow impact). If included, specify: amount, release triggers, whether retention earns interest.
Variation pricing: How are changes priced? T&M rates, fixed price quotations, or both? Who approves variations? Consider: threshold below which service provider can proceed, larger variations require advance approval.

11. Intellectual property rights in an SOW (?)

Purpose and importance

Often the most heavily negotiated section and therefore to be addressed in the MSA. Only justified SOW-particularities (and then only for deviations that could not reasonably generally be anticipated in the MSA) regarding IP might appear in an SOW. Otherwise, customer must reject all arrangements. Determines who owns and can use project outputs, which has long-term commercial implications for both parties.

Key elements

Background IP: IP each party brings to the SOW-project. Typically, background IP remains owned by the contributing party, with licence to other party as necessary for the project and project-purposes.
Project IP: IP created during project. Ownership options: customer owns all; service provider owns all (customer gets licence); joint ownership; mixed (service provider owns tools/methodologies, customer owns deliverables).
Third-party IP: If service provider will incorporate third-party IP, specify: what IP, licensing arrangements, who procures licences, ongoing licence costs.
Moral rights: In most jurisdictions, a natural person-author has moral rights (right to attribution, integrity) even if they don’t own the copyright in their work. Service providers should waive moral rights in customer-commissioned work (and obtain the same from their co-workers).

Negotiation considerations

Project IP ownership: Most contentious issue. Customers typically want to own everything created for them (‘foreground IP’); service providers want to retain ownership of reusable components, tools, and methodologies. Compromise approaches:
‘Field of use’: either party will own with either, if customer will be the owner, a non-exclusive licence back to service provider or, if service provider will be the owner, an exclusive licence to customer in respect of all use and modifications within the field of use (and, depending on the context of developed designs, products or processes, non-exclusive for any use or modification outside the field of use).
Severance: Service provider owns generic, reusable components; customer owns bespoke deliverables.
Specifications-based: Customer owns deliverables meeting specifications; service provider owns other project IP.
Customer ownership with broad licence back: Customer owns all, but grants service provider perpetual, royalty-free licence to use non-confidential elements for other clients.
Licence scope: Depending on context of the developed designs, products or processes, if service provider retains ownership, licence terms are critical. Consider differentiation for geographical, time-restricted or internal/external reuse aspects:
Exclusivity: Exclusive to customer (service provider can’t use for others) or non-exclusive?
Territory: Worldwide or specific territories?
Usage rights: Modify? Create derivatives? Transfer to affiliates? Sub-license?
Term: Perpetual or limited term? If limited, what happens at expiry?
Background IP licences: Customers should ensure licences are broad enough for intended use and do not expire if the SOW is completed or terminates. Service providers should limit licences to what’s necessary and protect their commercial interests in proprietary tools.
Escrow: For software deliverables, customers often want source code escrow to ensure access if service provider becomes insolvent. Service providers should resist escrow or limit release triggers and ensure their confidential information is protected.
Open source: If deliverables include open source software, specify: what open source is included, relevant licences, compliance obligations. Customers typically want to exclude copyleft licences (GPL) that could require their proprietary code to be open-sourced.
IP warranties: Service providers typically warrant they have right to grant licences and deliverables won’t infringe third-party IP. Customers want broad warranties; service providers want limitations (e.g., warranty doesn’t apply if infringement caused by customer modifications). Indemnities typically in MSA but may need project-specific provisions.

12. Changes and variations in Statement of Work (template)?

Purpose and importance

Provisions on changes or variation should be addressed in the MSA (and not be addressed or deviated from in an SOW). Nevertheless, SOW-project particularities may justify a specific change or variation procedure in respect of certain deliverables or milestones (e.g. certain key components can only be modified following a change or variation process imposed by the respective supplier, or lead time arrangements for key components do not permit changes according to the MSA-agreed process). Generally, a robust change control process is essential to maintain scope, budget, and timeline integrity whilst allowing necessary flexibility.

Key elements

Change identification: Who can identify potential changes? Both parties should be able to raise changes, but process may distinguish between customer requests and service provider proposals.
Change request form: Standard template ensures all necessary information is captured (description, justification, impact assessment, pricing).
Impact assessment: Service provider must assess impact on scope, price, timeline, resources, dependencies before change approved. Define assessment timeframe.
Approval process: Who can approve changes? Consider: materiality thresholds (minor changes by project manager, major changes by governance board), approval timeframes (if customer doesn’t respond, what happens?).

Where party interests may deviate…

What constitutes a change: Service providers want narrow scope definition so more things are changes; customers want broad scope so fewer changes needed. Key battlegrounds:
Bug fixes: Are defect corrections chargeable changes or included in base price? Typically defects in deliverables are service provider’s obligation, but enhancements or new requirements are changes.
Clarifications: If specifications are ambiguous, is clarifying them a change? Should incentivise clear initial specifications.
Customer-requested enhancements vs service provider-recommended changes: Different pricing and approval processes may apply.
Pricing methodology: How are changes priced? Options:
T&M at rate card: Simple but gives customer less cost certainty.
Fixed price quotation: Customer gets certainty but adds administrative overhead.
Hybrid: Small changes at T&M, larger changes require quotation.
Change uplift: Some customers want changes priced below normal rates to discourage over-specifying or gold-plating.
Approval timeframes: Service providers want quick approval (or deemed approval) to avoid project delays; customers want adequate time to assess business case. Consider: expedited process for urgent changes, longer timeframes for significant changes.
Bundling changes: Service providers may want to bundle multiple small changes to reduce administrative burden; customers may want each change separately assessed. Consider: regular change review meetings where accumulated minor changes are assessed collectively.
Unapproved changes: What if service provider performs work without approved change? Typically, customer has no obligation to pay, but consider: good faith exception if customer requested orally, or work was urgent and customer’s designated authority was unavailable.

13. Acceptance testing and criteria

Purpose and importance

Provisions on testing and acceptance processes of SOW deliverables should be addressed in the MSA (and not be addressed or deviated from in an SOW). Nevertheless, particularities of deliverables or milestones may justify a specific procedure or criteria in respect of certain deliverables or milestones. Typically, acceptance is the moment when risk transfers from service provider to customer and payment becomes due (if milestone-based). Disputes about acceptance are common and costly. Clear criteria and process are essential.

Key elements

Acceptance test procedures: Who performs testing? Where? What environment? What test data? What constitutes a test?
Acceptance criteria: Objective, verifiable criteria that determine whether deliverable is acceptable. Should mirror deliverable specifications exactly.
Defect classification: Not all defects are equally serious. Typical classifications: critical (prevents use), major (significant functionality impaired), minor (cosmetic or workaround available).
Timeframes: Customer must test within defined period. Service provider must remediate within defined period (possibly differentiating for defect classification). Indefinite testing periods are unacceptable to both parties.
Rejection and remediation: What happens if deliverable rejected? How many remediation attempts? What if service provider can’t fix defects?

Where party interests may deviate…

Acceptance criteria objectivity: Service providers want purely objective, technical criteria; customers want criteria to include functional/business requirements. Tension between “built to specification” (service provider preference) and “fit for purpose” (customer preference). Consider: objective criteria for acceptance, but service provider warrants deliverable will be fit for stated purpose.
Testing environment: Who provides it? Production environment or test environment? If test environment, who ensures it mirrors production? If production environment, what restrictions on testing (e.g., can’t test during business hours)?
Deemed acceptance: Service providers typically want deemed acceptance if customer doesn’t complete testing within specified period. Customers strongly resist (could accept defective deliverable). Compromises:
Extended testing periods: Reduce need for deemed acceptance by giving customer adequate time.
Partial deemed acceptance: Criteria elements not rejected are deemed accepted.
Qualified deemed acceptance: Deemed acceptance doesn’t waive customer’s rights for latent defects.
Remediation attempts: Service providers want multiple attempts; customers want quick resolution. Consider: two remediation attempts as standard, with option for third attempt by agreement, but if service provider can’t remediate after third attempt, customer can require price reduction or terminate.
Acceptance vs warranty: Acceptance means deliverable meets acceptance criteria, not that it is free from all defects. Service provider should provide a warranty period after acceptance during which defects can be raised (to be fixed under the warranty). Specify warranty period length and remedies for warranty breaches.
Partial acceptance: Can some deliverables be accepted whilst others remain in testing? Generally yes, particularly if payment linked to individual deliverables. But consider dependencies—accepting underlying infrastructure shouldn’t prevent rejecting applications that depend on it.

14. Warranties and representations in an SOW

Purpose and importance

Representations (as distinguished from warranties under common law) should not be in an SOW. Furthermore, general warranties on SOW deliverables should be in the MSA (and not be addressed or deviated from in an SOW). Nevertheless, MSA-unforeseeable particularities of a deliverable or milestone may justify a specific warranty, since such particularity, if unforeseeable, might require to reallocate risk for quality, compliance, or legal issues. Determines remedies if deliverables or services are defective or breach legal requirements. Often duplicates or elaborates on MSA warranties but with project-specific detail.

Key elements

Performance warranties: Service provider warrants it will perform to specified standards (reasonable skill and care, industry standards, compliance with law).
Deliverable warranties: Deliverables will meet specifications, be free from material defects, be fit for stated purpose (if agreed).
Compliance warranties: Compliance with laws, regulations, safety standards, industry codes.
IP warranties: Service provider has right to use/license IP, deliverables don’t infringe third-party IP.
Personnel warranties: Personnel have requisite qualifications and experience.
Warranty period: How long do warranties last? Typically 3-12 months after acceptance for defects, longer for latent defects.

Negotiation considerations

Standard of performance: ‘Reasonable skill and care’ (professional services standard) vs ‘fit for a specific purpose’ (outcome-based warranty). Former is service provider-friendly and typical for bespoke work; latter is customer-friendly and appropriate for standardised solutions. Consider hybrid: reasonable skill and care for services, fitness for purpose for specified deliverables.
Warranty scope: Service providers want to limit warranties to express statements in SOW; customers want implied warranties (fitness for purpose, merchantability) to apply. In UK, implied warranties can be excluded if reasonable, but exclusion must be express and clear.
Warranty limitations: Service providers typically (and justifiably) want warranties not to apply if:
Customer modifies deliverables.
Customer uses deliverables in a manner beyond specifications or in violation of clear instructions.
Defect caused by customer-provided information, instructions or systems.
Customer does not install updates or patches.
Service provider should ensure limitations are reasonable and don’t prevent normal use.
Warranty remedies: What can customer do if warranty breached? Typical remedies: service provider must repair/replace, or if can’t, price reduction or termination. Customers want full range of remedies; service providers want exclusive repair/replace remedy with price reduction/termination only as last resort.
Latent defects: How long can customer claim for defects not discoverable during warranty period? Service providers want short period (warranty period only); customers want longer period for latent defects. Consider: express warranty period for patent defects, statutory limitation period for latent defects (compromise: specific latent defect period, e.g., 18-24 months).
IP indemnity: Typically in MSA but may need elaboration. Service provider indemnifies customer against IP infringement claims relating to deliverables. Key issues:
Scope: Only infringement by deliverables as delivered, or also customer’s use?
Exclusions: Typically excludes infringement caused by customer modifications, use with non-approved third-party products, or compliance with customer specifications.
Cap: Usually higher cap than general liability cap (often uncapped or capped at total SOW value). Service providers want lower caps.
Mitigation: If infringement claim arises, service provider typically has option to: obtain licence for customer, modify deliverables to be non-infringing, or replace deliverables. Only if none of these possible should service provider be liable for damages.

15. Term and termination (of a Statement of Work)

Purpose and importance

Defines project duration and circumstances in which either party can exit. Critical for risk management and ensuring parties have appropriate remedies if project fails or becomes uncommercial.

Key elements

Commencement and duration: When does SOW start? When does it end? Fixed end date or event-based (e.g., “completion of deliverables and expiry of warranty period”)?
Termination rights: In addition to MSA termination rights, what SOW-specific termination rights exist?
Termination for project issues: Service provider inability to meet milestones, persistent quality issues, key personnel departure.
Termination for cause: Breach of SOW-specific obligations, repeated failures, insolvency, change of control.
Termination for convenience: Can customer terminate without cause? Typically yes, on notice (30-90 days). Service provider termination for convenience rare.
Wind-down obligations: Transition assistance, return of materials, final reporting, settlement of accounts.
Consequences of termination: What happens to work in progress? Partial deliverables? Payment for work done? IP ownership?

Negotiation considerations

Customer termination for convenience: Service providers strongly resist or want full payment for remaining work; customers want flexibility. Compromises:
Payment for work done: Customer pays for all completed deliverables plus reasonable costs for work in progress. Define: what’s “completed” (accepted deliverables only or also unaccepted?), what’s “reasonable costs” (based on time spent or percentage of deliverable price?).
Notice period: Longer notice period reduces service provider’s risk. Typical: 30-90 days.
Early termination fee: Service provider may want fee to compensate for lost profit and demobilisation costs. Customers resist. If included, should be declining percentage as project progresses (reflects reducing loss of profit opportunity).
Service provider termination rights: Very limited. Typically only for: persistent material customer breach after notice and opportunity to cure (e.g., non-payment, repeated failure to provide access), customer insolvency. Customers resist service provider termination for convenience entirely.
Termination for persistent failure: If service provider consistently misses milestones or deliverables are repeatedly rejected, customer wants termination right. Service providers resist, arguing they should have opportunity to remediate. Consider: termination right if X deliverables rejected or Y milestones missed within Z-month period, with escalation and remediation opportunity before termination effective.
Payment on termination: Most contentious issue.
Accepted deliverables: Service provider clearly entitled to payment.
Unaccepted deliverables: Service provider typically argues it should be paid proportion of price based on work done; customer argues nothing should be paid if deliverable not accepted. Consider: put deliverables through accelerated acceptance process on termination, with customer obliged to accept or reject within short period (e.g., 10 business days).
Work in progress: Service provider wants payment for time/costs incurred; customer wants no payment for incomplete work. Consider: customer pays reasonable value of work done that’s actually useful to customer (e.g., design documents, partially developed code that can be completed by replacement supplier).
IP on termination: What happens to project IP created before termination?
If customer ordinarily would own IP: customer owns IP created pre-termination.
If service provider ordinarily would own IP: does customer get licence to use incomplete deliverables? Typically yes, if customer paid for work, but licence may be non-exclusive and limited to completed elements.
Transition assistance: Customers want service provider to provide reasonable transition assistance to replacement supplier. Service providers willing to provide if paid for it. Consider: fixed period of transition assistance (e.g., 30 days) included in wind-down obligations, with option to extend at T&M rates.
Survival: Which obligations survive termination? Typically: confidentiality, IP warranties, indemnities, payment obligations, wind-down obligations. Should mirror MSA survival provisions but may need project-specific additions.

16. Transition and handover specific to Statements of Work

Purpose and importance

Often overlooked but critical for project success, particularly for longer-term projects or where deliverables must be maintained by customer or third party post-completion. Poor transition leads to operational failures and disputes about whether project is truly complete.

Key elements

Transition-in: How will service provider get up to speed at project start? Access to customer systems, information, personnel? Who provides training to service provider team?
Knowledge transfer: How will service provider transfer knowledge to customer? Documentation, training, mentoring, shadowing?
Documentation: What documentation must be provided? Technical documentation, user documentation, operational runbooks, source code comments?
Handover acceptance: Is there separate acceptance process for handover (in addition to deliverable acceptance)? What are criteria?
Post-completion support: Will service provider provide support after completion? For how long? At what cost? What level of support?

Where party interests may deviate…

Knowledge transfer scope: Customers want comprehensive training for all users; service providers want to limit training to minimise cost. Consider: tiered approach (train-the-trainer included, end-user training as optional extra), or minimum training days included with additional training at T&M rates.
Documentation level: Service providers want to provide minimal documentation in their standard format; customers want extensive documentation integrated with their systems. Consider: specify minimum documentation requirements (e.g., technical architecture, API documentation, user guides) and required format early in project to avoid surprises.
Handover timing: When does handover occur? After final acceptance (service provider-preferred—reduces risk of extended handover) or as separate phase after acceptance (customer-preferred—ensures smooth transition)? Consider: handover during warranty period so service provider still has obligation to support if handover issues arise.
Post-completion support: Service providers often want to sell maintenance/support contracts; customers may want time-limited support included in base price to ensure stable transition. Consider: 3-6 month warranty period with support included (defect fixes), followed by optional paid maintenance (enhancements, ongoing support).
Transition assistance pricing: If transition assistance required (e.g., helping replacement supplier or customer team), should this be included in base price or paid separately? Generally, reasonable transition assistance (e.g., answering questions, explaining design decisions) should be included; extensive assistance (e.g., training replacement team) should be paid.
Transition on early termination: Handover provisions typically assume successful completion, but customer needs transition assistance if project terminates early. Consider: abbreviated transition process on termination, with essential documentation and knowledge transfer only.

17. Location and working arrangements

Purpose and importance

Post-Covid, working arrangements are increasingly important. Determines where work occurs, which affects cost, security, supervision, and IP risk. Also impacts employment law (if personnel working on customer premises for extended periods).

Key elements

Work location: On-site at customer premises, off-site at service provider premises, hybrid, remote? Percentages?
Customer site access: Security clearance requirements, visitor management, workspace provision, IT equipment provision?
Working hours: Must service provider work customer’s core hours? Flexibility for different time zones?
Security requirements: Data handling, device security, network security when working remotely?

Where party interests may deviate…

On-site vs remote work: Customers traditionally wanted most work on-site for oversight and IP security; service providers prefer off-site for cost and flexibility. Post-COVID, remote work more acceptable. Consider: initial phase on-site for requirements and design, development off-site, testing and deployment on-site.
Cost implications: On-site work typically costs more (travel, accommodation, service provider’s opportunity cost of having staff at customer site). Should be reflected in pricing.
Security requirements: If remote work permitted, customers often want: encrypted devices, VPN access only, no data on personal devices, audit rights. Service providers should ensure requirements are reasonable and commercially practical.
Personnel behaviour: If on-site, service provider personnel must comply with customer’s site rules, security policies, code of conduct. Consider: which customer policies apply? How are they provided to service provider personnel? Consequences of breaches?
IR35 considerations: In UK, if service provider personnel work on customer premises under customer supervision with minimal autonomy, HMRC may treat them as employees for tax purposes (IR35). Parties should consider: who bears IR35 risk? Should contract terms be adjusted to ensure service provider personnel genuinely operate as independent contractors (e.g., service provider controls how and when work is done, service provider can substitute personnel)?

18. Confidentiality and data protection in SOWs

Purpose and importance

An MSA will likely already contain general confidentiality and data protection provisions (or a DPA attached), but SOWs may need project-specific detail, particularly regarding data processing arrangements and security requirements.

Key elements

Project-specific confidential information: What information exchanged for this project is confidential? Sometimes broader or narrower than general MSA definition.
Data protection: If service provider will process personal data on customer’s behalf, Data Processing Agreement (DPA) required under GDPR. Can be incorporated in SOW or separate document.
Security requirements: Technical and organisational measures service provider must implement. May be general (e.g., “industry standard security”) or specific (e.g., “ISO 27001 certified, encryption at rest and in transit, MFA for all access”).
Data retention and deletion: How long will service provider retain customer data? When and how must it be deleted?

Although these should not be negotiated…

DPA requirements: If processing personal data, DPA is legally required under GDPR. Key issues:
Processing scope: What personal data? For what purposes? On whose instructions?
Sub-processors: Can service provider use sub-contractors to process data? Customer typically wants list of sub-processors and approval right for new ones.
Data subject rights: How will service provider assist customer in responding to data subject access requests, erasure requests, etc.?
Data breach notification: Service provider must notify customer promptly of personal data breaches. Define “promptly” (e.g., within 24 hours of discovery).
Audit rights: Customer typically wants audit rights to verify compliance. Service provider wants to limit to reasonable frequency and timing.
Security requirements: Customers want high security standards; service providers want flexibility and to avoid gold-plating. Consider: specify minimum standards (e.g., ISO 27001 or equivalent) rather than prescriptive technical measures, with option to agree specific measures by schedule.
Data location: Under GDPR, transfers of personal data outside UK/EEA require additional safeguards. If service provider will process data outside UK/EEA, must use: adequacy decision jurisdiction, or Standard Contractual Clauses, or other approved mechanism. Customers often want data to remain in UK/EEA; service providers may want flexibility to use global resources.
Data deletion: Customers want assurance data is securely deleted post-project; service providers want to retain for reasonable period for backup/dispute resolution. Consider: customer data deleted within X days of project completion, except customer can request immediate deletion, and except service provider can retain minimum necessary data for dispute resolution/legal compliance for up to Y months.
Confidentiality carve-outs: Standard confidentiality exceptions (publicly available, independently developed, etc.) but consider: can service provider use project learnings for other clients (with customer’s confidential information removed)? Customers typically resist; service providers want ability to leverage experience. Compromise: service provider can use general learnings and methodologies but not customer-specific information or deliverables.

19. Insurance and liability in an (template) SOW

Purpose and importance

An MSA typically contains insurance and liability provisions, but high-value or high-risk projects may require additional insurance or ‘justify’ a different liability cap (especially when a significant part of the Statement of Work is sourced from third parties (which impose different limitations of liability), where a back-to-back or knock-for-knock teaming-like arrangement is appropriate). This section captures project-specific variations.

Key elements

Additional insurance: Does this project require insurance beyond MSA requirements? Common examples: increased professional indemnity, project-specific insurance, cyber insurance.
Liability caps: Does this project require different liability caps than MSA? Higher caps for high-value projects, or lower caps for low-risk projects?
Insurance certificates: When must service provider provide insurance certificates? Typically before work commences and annually thereafter.

Negotiation considerations

Professional indemnity (PI) insurance: Normally, an MSA requires minimum PI cover (e.g., 2-5 million euro). For high-value projects, customers may want increased cover (e.g., 10 million euro). Service providers should check: is additional cover available? At what cost? Consider: customer pays premium for additional cover, or increased cover only required if project value exceeds threshold.
Project-specific insurance: For very large, complex or unique projects, consider project-specific insurance policy covering all parties. Typically customer procures and pays for this. Covers: construction/erection all risks (if physical infrastructure), professional indemnity, third-party liability.
Cyber insurance: Increasingly important for IT projects. Covers: data breach costs, cyber incident response, business interruption due to cyber attack. Consider: minimum cover level, must cover both parties, must include regulatory defence costs.
Liability cap variations: MSA liability cap (typically 100-200% of annual fees or total MSA value) may be inappropriate for individual SOW. Consider:
High-value projects: Cap based on SOW value rather than MSA value may be appropriate (e.g., 100% of SOW value).
High-risk projects: Higher cap (e.g., 150-200% of SOW value) or uncapped liability for certain breaches (IP infringement, data breaches).
Low-risk projects: Lower cap (e.g., 50% of SOW value) may be acceptable if project is low-risk and low-value.
Uncapped liabilities: MSA typically excludes certain liabilities from cap (death/personal injury, fraud, IP infringement). Consider whether this list should be expanded for specific project (e.g., data breach liabilities uncapped for projects involving sensitive personal data).

20. Compliance and regulatory requirements in a Statement of Work

Purpose and importance

Many projects are subject to specific regulatory requirements beyond general law. This section ensures compliance obligations are clearly defined and allocated. Non-compliance can lead to regulatory penalties, project delays, or unacceptability of deliverables.

Key elements

Applicable regulations: What laws and regulations apply to this project? Examples: financial services regulation, healthcare regulation, data protection (GDPR), export controls, product safety standards.
Compliance obligations: What must service provider do to ensure compliance? Obtain certifications, follow specific processes, provide compliance documentation?
Audit rights: Can customer (or regulators) audit service provider’s compliance? How often? At whose cost?
Regulatory approvals: Are regulatory approvals required before deliverables can be deployed? Who obtains them? Who bears risk/cost of approval delays?

Where party interests may deviate…

Regulated industries: If customer operates in regulated industry (financial services, healthcare, telecoms), deliverables may need to comply with specific regulations. Examples:
Financial services: Regulatory requirements for systems and controls, operational resilience, outsourcing.
Telecoms: Ofcom requirements, network security standards. Service provider may not be familiar with these regulations; customer should provide clear guidance or make compliance verification part of acceptance criteria.
Compliance responsibility allocation: Who is responsible for ensuring compliance? Typically: service provider ensures deliverables comply with technical regulations/standards; customer ensures solution as deployed complies with business/operational regulations. But boundaries can be unclear. Consider: service provider provides compliance declarations/certifications; customer validates compliance in context of its business.
Audit rights: Customers and regulators often want audit rights. Service providers should ensure: reasonable advance notice (e.g., 30 days except for regulatory audits), reasonable frequency (e.g., once per year), reasonable scope (compliance with SOW only, not service provider’s general practices), customer bears cost unless audit reveals material non-compliance.
Regulatory change: What if regulations change during project? Typically: service provider must comply with regulations in force at delivery date, even if they changed after contract signature. But if change is fundamental and affects deliverables materially, service provider may want change control/price adjustment right. Consider: minor regulatory changes are service provider’s risk; material changes trigger change control.
Export controls: If deliverables involve encryption or other controlled technology, export controls may apply. Service provider should warrant it has necessary export licences; customer should confirm intended use/users comply with export controls.

21. Dispute resolution for an SOW

Purpose and importance

An MSA will invariably contain dispute resolution provisions, but project-specific escalation and resolution procedures can prevent disputes escalating to formal processes. Particularly important for longer projects where disputes may arise and need resolution without terminating the relationship (and where over time, balancing of judgement is possible, which is facilitated by an appointed dispute resolution board that meets at a set frequency).

Key elements

Escalation process: Before invoking formal MSA dispute resolution, project disputes should go through escalation: working level → project sponsors → executive level.
Expert determination: For technical disputes (e.g., whether deliverable meets specifications), parties may agree expert determination rather than litigation/arbitration (faster, cheaper, technically informed).
Dispute resolution timescales: Define response times at each escalation level to prevent disputes stalling project.

Where party interests may deviate…

Escalation process formality: Service providers want formal escalation (ensures disputes addressed promptly, creates clear record); customers may prefer informal resolution. Consider: mandatory escalation for material disputes (e.g., acceptance disputes, payment disputes, changes affecting price/timeline by >X%), optional escalation for minor issues.
Expert determination: Particularly useful for technical disputes. Consider: parties jointly appoint expert (agreement on expert, or failing agreement, appointed by professional body), expert’s decision is binding or advisory? typically binding on technical questions but advisory on legal/commercial questions, costs borne equally or by losing party? typically equally.
Continuing performance: Should parties continue performing whilst dispute is being resolved? Generally yes (maintains project momentum), except: customer need not pay disputed invoices until dispute resolved, service provider may suspend if customer fails to pay undisputed amounts.
Relationship with MSA: SOW escalation/resolution procedures should be additional to, not replacement for, MSA procedures. After exhausting SOW escalation, parties should have recourse to MSA dispute resolution (litigation, arbitration, or mediation as specified in MSA).

22. Definitions and interpretation

Purpose and importance

Ensures key terms have clear, agreed meaning. Particularly important for technical terms or terms with special meaning in this project. Prevents disputes arising from different understandings of terminology.

Key elements

SOW-specific definitions: Terms used in SOW that aren’t defined in MSA or have different meaning in SOW context.
Technical abbreviations: Projects often use jargon and abbreviations that may not be universally understood.
Reference to MSA definitions: Confirm that MSA definitions apply unless specifically overridden in SOW.
Interpretation rules: Headings, examples, “including” (inclusive or exhaustive?), singular/plural.

Negotiation considerations

Definition scope: Service providers often want broad definitions of their obligations (e.g., “reasonable endeavours” rather than “best endeavours”); customers want narrow, specific definitions. For key obligation terms, ensure definition is clear and matches parties’ intentions.
Technical terms: If project involves specialised technology, define technical terms clearly. Consider: glossary in schedule rather than in definitions section (easier to read, less cluttered).
“Including”: Does “including” mean “including but not limited to” (inclusive) or “including only” (exhaustive)? UK law default is inclusive, but specify to avoid doubt.
Business days: If timelines measured in “business days”, define precisely: whose business days? (customer’s, service provider’s, or UK bank holidays?) Exclude: weekends, public holidays in [country], other specified dates (e.g., customer’s mandatory closure periods).
Affiliate definitions: If SOW allows or requires involvement of affiliates (e.g., customer can use deliverables within group, or service provider can use affiliate resources), define “affiliate” clearly. Typical: entities controlled by, controlling, or under common control with party; “control” means >50% voting rights.

24. Schedules and appendices to a Statement of Work (template)

Purpose and importance

Schedules contain detailed project information that would make SOW body unwieldy if included there. Essential reference documents that form part of the SOW and are legally binding.

Key schedules

Schedule 1 – Detailed deliverables specification: Technical specifications, functional requirements, non-functional requirements, acceptance criteria for each deliverable. Most important schedule—forms basis of service provider’s obligations and customer’s acceptance decisions.
Schedule 2 – RACI matrix: Lists all project activities/decisions with assignment of Responsible, Accountable, Consulted, and Informed roles. Prevents gaps and overlaps in responsibilities.
Schedule 3 – Project plan and timeline: Detailed project plan showing tasks, dependencies, milestones, and dates. May be high-level in SOW with detailed plan to be developed and agreed after signature (if so, approval process and timeline for detailed plan must be specified).
Schedule 4 – Pricing schedule: Detailed breakdown of charges (by deliverable, by phase, by resource, or by time period). If T&M elements, rate card for each resource level. If expenses reimbursable, expense categories and any caps.
Schedule 5 – Acceptance criteria: For each deliverable, specific, objective, verifiable criteria that determine whether it’s acceptable. Should match specifications in Schedule 1 but presented in test-oriented format.
Schedule 6 – Change request form template: Standard form for requesting changes. Ensures all necessary information captured (change description, justification, impact on scope/price/timeline/resources/dependencies, priority).
Schedule 7 – Key personnel: Names, roles, and qualifications of key personnel. May include CVs. If personnel substitution allowed, criteria for substitutes and approval process.
Schedule 8 – Customer systems and infrastructure: Description of customer’s existing systems, infrastructure, and environment that service provider will interface with or depend on. Helps manage dependencies and assumptions.
Schedule 9 – Data Processing Agreement: If processing personal data, DPA required under GDPR. Can be standalone document or schedule to SOW. Contains data protection-specific provisions (processing scope, sub-processors, data subject rights, security measures, audit rights, breach notification).
Schedule 10 – Service levels and performance standards: Detailed SLAs if applicable (metrics, targets, measurement methodology, reporting, service credits/remedies).

Where party interests may deviate…

Schedule development timing: Some schedules (particularly detailed technical specifications and project plan) may not be finalised at SOW signature. Consider: high-level version in SOW, detailed version to be developed in initial project phase and approved via change control. But specify: approval process, timeline, consequences if parties can’t agree (typically either party can terminate without penalty).
Schedule amendments: Can schedules be amended more easily than SOW body? Sometimes yes—allows flexibility for minor changes without formal variation. But specify: what changes allowed (e.g., project plan dates can be adjusted within overall milestone dates without variation), approval process (typically project managers can approve minor schedule changes, but material changes require change control).
Schedule conflicts: What if schedules conflict with each other or with SOW body? Specify order of precedence. Typical: SOW body > Schedule 1 (deliverables spec) > Schedule 2 (RACI) > other schedules. But consider project-specific needs.
Schedule format: Customers often want schedules in their standard templates; service providers want to use their own formats. Consider: agree format requirements early, or specify minimum content requirements but allow flexibility in format.