How to draft a Statement of Work that actually protects you
The SOW is where most B2B disputes originate. Vague language, missing acceptance criteria, and undefined change procedures cost companies millions every year.
A Statement of Work is the operational heart of any service engagement. While the MSA provides the legal framework, the SOW defines the actual deal: what is being built, by when, at what cost, and to what standard. A well-drafted SOW eliminates the most common sources of dispute before work begins. A poorly drafted one practically guarantees conflict.
The six essential components of every SOW
Every professional SOW, regardless of industry, must address six core questions. Missing any one of them creates a gap that will eventually be filled by disagreement.
Scope of work
A precise description of what will be delivered. Not "a website" — a specific list of pages, features, integrations, and functionalities.
Deliverables
The specific, tangible outputs: files, systems, reports, designs. Each deliverable should be named and described individually.
Timeline & milestones
Start date, milestone dates, final delivery date. Dependencies on the client (content, approvals, access) must be flagged explicitly.
Acceptance criteria
How will the client determine whether a deliverable is acceptable? Objective, measurable criteria eliminate subjective disputes about quality.
Payment schedule
When each payment is due, to what milestone it is tied, and what triggers the next invoice. Never "payment on completion" for multi-month projects.
Assumptions & exclusions
Everything the provider is assuming to be true, and everything explicitly not included in the scope. This is where "that was included" disputes die.
Scope creep: the silent project killer
Scope creep occurs when deliverables expand beyond the original agreement without corresponding adjustments to budget or timeline. It rarely happens through malice — usually a client makes a reasonable-sounding request, the provider agrees informally to avoid friction, and within weeks the project has doubled in complexity while the price remains fixed.
The solution is a formal change request process, which should be defined in the SOW itself. Every out-of-scope request must be documented in a written Change Order that specifies the additional work, the fee, the impact on timeline, and requires written approval from both parties before work begins.
If a client requests something and you are not sure whether it is in scope, it is not in scope. The scope is defined by what is written, not what is implied. When in doubt, raise a Change Order.
Writing acceptance criteria that work
Acceptance criteria are the most important and most neglected section of any SOW. "The deliverable must be of professional quality" is not an acceptance criterion — it is an invitation to disagree. "The e-commerce checkout flow must complete a test transaction from product page to order confirmation in under 4 seconds on a standard 4G connection with no errors" is an acceptance criterion.
For technical deliverables, acceptance criteria should specify performance benchmarks, error tolerance levels, compatibility requirements, and testing methodology. For creative deliverables, they should specify revision rounds, approval timelines, and the identity of the individual with final approval authority.
Milestone structure and payment design
The payment structure of an SOW should track the delivery of value, not the passage of time. Time-based payments (monthly retainers) work for ongoing services. Milestone-based payments work for project-based work. A typical structure for a six-month development project:
| Milestone | Deliverable | Payment |
|---|---|---|
| Project kickoff | Signed SOW, project plan, access provisioned | 30% of project fee |
| Design approval | Approved UI/UX designs and architecture docs | 20% of project fee |
| Development complete | All features delivered to staging environment | 25% of project fee |
| UAT sign-off | Client acceptance confirmed in writing | 15% of project fee |
| Go-live | Production deployment and handover complete | 10% of project fee |
Dependencies: the clause most SOWs ignore
Service providers cannot deliver on schedule if the client fails to provide required inputs on time. A client who delays providing content, approval, access credentials, or feedback is, in effect, extending the project timeline unilaterally — but the provider bears the commercial consequences unless the SOW addresses this explicitly.
Include a dependencies clause that lists every input required from the client, the date by which each must be provided, and the effect of a delay: a day-for-day extension of the timeline, and the right to invoice for delay costs if the delay exceeds a defined threshold.
If the client fails to provide [specified input] by [date], the timeline shall be extended by one day for each day of delay, and the provider reserves the right to charge a delay fee of [amount] per week after a 5-business-day grace period. Any revised timeline must be agreed in writing.
When the SOW conflicts with the MSA
SOWs and MSAs sometimes contain conflicting provisions — usually because a later SOW was drafted without checking the MSA it sits under. The governing precedence should be stated explicitly in the MSA. If the MSA is silent, courts generally apply the later-in-time document, which means a poorly considered SOW clause can inadvertently override carefully negotiated MSA terms.
Best practice: include a statement in every SOW that "except where this SOW expressly states otherwise, the terms of the Master Service Agreement dated [date] shall govern." This preserves the MSA's integrity while allowing the SOW to make specific overrides where genuinely needed.
IP assignment clauses:
who owns what and why it matters more than you think
When a company pays a vendor to create something, it often assumes it owns the result. That assumption is frequently wrong — and the consequences can be catastrophic.
Intellectual property disputes between companies and their service providers are among the most expensive and disruptive commercial conflicts in business. They arise not because anyone acted dishonestly, but because both parties had different assumptions about a question they never explicitly discussed: who owns the work?
In most jurisdictions, the default answer is: the person who created it. Not the person who paid for it. This default can be overridden by contract — but only if the contract does so clearly and correctly.
The three categories of IP in every service engagement
When a service provider delivers work to a client, the deliverable almost always contains three distinct types of intellectual property, each of which requires different legal treatment.
Background IP
IP the service provider brings to the engagement — proprietary tools, frameworks, code libraries, methodologies, templates. Created before the engagement began. The provider owns this and should never assign it.
Foreground IP
IP created specifically for the client under the SOW — custom software, unique designs, bespoke reports. This is what clients typically expect to own. Assignment to the client is standard upon full payment.
Derivative IP
New IP built on top of background IP — a customised version of the provider's framework, for example. Neither pure background nor pure foreground. Typically handled through a licence, not an assignment.
The assignment clause — what it must say
A valid IP assignment clause must do several things precisely. It must identify the IP being assigned (by reference to the SOW deliverables). It must state the moment of assignment — whether IP transfers on creation, on delivery, or on receipt of full payment. It must confirm that the assignment covers all rights including the right to sub-license, modify, and create derivative works. And in jurisdictions where moral rights exist, it must include a waiver of those rights.
An IP clause that says "all work product created hereunder is the property of the client" without specifying background IP exclusions is not a balanced agreement — it is an accidental transfer of the service provider's core technology.
The payment condition: protecting the provider
The most commercially sensible IP assignment clause conditions the transfer on receipt of full payment. IP vests in the client when the final invoice is paid, not before. Until that point, the client has a licence to use the deliverables but does not own them. This is the service provider's most powerful collection mechanism — and it should be stated explicitly in both the MSA and the SOW.
Licences vs assignments: the crucial distinction
Many IP clauses grant a "licence" where the client expects an "assignment." These are fundamentally different. An assignment permanently transfers ownership — like selling a house. A licence permits use without transferring ownership — like renting one. The distinction matters for several reasons: a licence can be terminated if the licensor ceases to exist or the contract is breached; an assignment cannot. A licence may restrict certain uses (sublicensing, resale, modification); an assignment does not.
Clients should insist that the IP assignment clause uses the word "assigns" or "transfers ownership" — not merely "grants a licence." If the deliverable contains background IP that cannot be assigned, the clause should explicitly grant a perpetual, irrevocable, royalty-free licence to that background IP, which survives termination of the MSA.
Open source: the hidden IP complication
Modern software development almost universally relies on open-source components. Most open-source licences are permissive (MIT, Apache, BSD) and impose minimal restrictions. But some — particularly the GPL family — are "copyleft" licences that require any derivative work to be released under the same licence. A service provider who embeds GPL-licensed code in a client's proprietary software system has potentially obligated the client to open-source its entire codebase.
Every IP assignment clause should require the service provider to deliver a bill of materials listing all open-source components used, their versions, and their licence types. The provider should warrant that no copyleft-licensed components are embedded in proprietary deliverables without prior written disclosure and client approval.
What every IP clause checklist should include
- Clear background IP carve-out. Provider retains all background IP. Client receives only a licence to use background IP embedded in deliverables.
- Assignment of foreground IP. All deliverables specified in the SOW are assigned to the client upon full payment.
- Breadth of assignment. Assignment includes all rights: reproduction, distribution, modification, sublicensing, and creation of derivative works.
- Moral rights waiver. To the extent permitted by applicable law, provider waives all moral rights in the deliverables.
- Survival of licence. Background IP licence survives termination of the MSA regardless of the reason for termination.
- Open source disclosure. Provider to deliver a complete open-source bill of materials with each SOW deliverable.
- IP indemnity. Provider indemnifies client against third-party IP infringement claims arising from the deliverables.
- Pre-existing client IP. Any client IP provided to the provider for the project remains the client's property.
Commercial arbitration in India:
a practical guide for businesses
India's arbitration landscape has been transformed over the last decade. Here is what businesses actually need to know when drafting dispute resolution clauses for Indian contracts.
Arbitration has become the preferred dispute resolution mechanism for commercial contracts in India — and for good reason. India's court system, despite significant reforms, still suffers from backlogs that can stretch commercial litigation across years and sometimes decades. Arbitration offers a faster, private, and increasingly reliable alternative.
But arbitration is only as good as the arbitration clause that invokes it. A poorly drafted clause can create more problems than it solves — leaving parties trapped in satellite litigation over jurisdiction, applicable law, and the validity of the clause itself before the substantive dispute is ever heard.
Arbitration vs litigation: the practical comparison
- Proceedings are public record
- Timeline typically 3–10+ years in commercial courts
- Limited cross-border enforceability
- Judges assigned by the system — no domain expertise choice
- Appeals available as of right — prolongs resolution
- Lower direct costs; high indirect costs from delay
- Confidential proceedings by default
- Award typically within 12–24 months
- Enforceable in 170+ countries (New York Convention)
- Parties choose arbitrators with relevant expertise
- Limited grounds for challenge — finality is a feature
- Higher upfront costs; lower total cost from speed
The legal framework: Arbitration and Conciliation Act, 1996
Indian arbitration is governed by the Arbitration and Conciliation Act, 1996 (the ACA), which was substantially amended in 2015, 2019, and 2021 to address systemic weaknesses. The 2015 amendments introduced time limits for arbitral proceedings (12 months, extendable to 18 months), restricted court intervention, and created a fast-track procedure for smaller disputes. The 2019 amendments established the Arbitration Council of India and introduced institutional arbitration as a preferred option for large commercial disputes.
The Act distinguishes between domestic arbitration (both parties are Indian) and international commercial arbitration (at least one party is foreign). Different procedural rules and enforcement mechanisms apply to each.
Institutional vs ad hoc arbitration
Indian contracts historically favoured ad hoc arbitration — a one-off process with procedures agreed between the parties for each dispute. Institutional arbitration, administered by a permanent arbitration institution under its own rules, has grown significantly in the last decade and is now strongly preferred for commercial contracts of any significance.
DIAC, Delhi
Government-established, strong for domestic commercial disputes. Good case management infrastructure.
MCIA, Mumbai
India's leading international arbitration institution. Modern rules, international panel of arbitrators, fast-track procedures.
SIAC, Singapore
Most popular seat for India-related cross-border disputes. Excellent enforceability and institutional reputation.
ICC, Paris
Preferred for high-value, complex disputes. Extensive international experience. Higher costs than Asian alternatives.
Drafting an effective arbitration clause
The arbitration clause must specify five elements without ambiguity: the scope of disputes covered, the institution whose rules apply, the seat (legal home) of the arbitration, the number of arbitrators, and the language of proceedings. Missing any one of these creates grounds for challenge.
Recommended domestic clause: "Any dispute arising out of or in connection with this Agreement, including any question regarding its existence, validity or termination, shall be referred to and finally resolved by arbitration administered by the Mumbai Centre for International Arbitration (MCIA) in accordance with the MCIA Arbitration Rules. The seat of arbitration shall be Mumbai. The number of arbitrators shall be [one/three]. The language of the arbitration shall be English."
The arbitration process: stage by stage
Notice of arbitration
The claimant files a notice identifying the dispute, the relief sought, and the proposed arbitrator. This formally commences proceedings and stops limitation periods from running.
Tribunal constitution
Arbitrators are appointed per the agreed procedure. For a three-member panel, each party appoints one, and the two appointees select the presiding arbitrator. Takes 4–8 weeks.
Pleadings and document disclosure
Statement of claim, defence, and counterclaim are filed. Documentary evidence is exchanged. Narrowing of issues occurs through procedural hearings.
Evidential hearing
Witnesses give oral evidence and are cross-examined. Expert witnesses present technical evidence. The tribunal may ask questions directly.
Award
The tribunal issues a reasoned written award. Under the ACA (post-2015), the tribunal must deliver the award within 12 months of constitution, extendable to 18 months with consent.
Enforcement
Domestic awards are enforceable as court decrees. Foreign awards (from New York Convention countries) are enforceable in India subject to limited public policy exceptions.
Seat vs venue: the distinction that trips everyone
The seat of arbitration determines the lex arbitri — the procedural law governing the arbitration. The venue is simply where hearings physically take place. An arbitration can have its seat in Mumbai (so Indian procedural law applies and Indian courts supervise) but hold hearings in Singapore for convenience. The seat is a legal concept; the venue is a logistical one. The arbitration clause must specify the seat, not just the venue.
SaaS-specific
MSA provisions
every tech contract needs
A generic MSA does not adequately cover a SaaS relationship. Uptime obligations, data portability, API usage rights, and multi-tenant liability require purpose-built contract language.
When a company subscribes to a SaaS platform, it is entering a fundamentally different type of commercial relationship than a traditional service engagement. The software is not delivered and owned — it is accessed over the internet, hosted by the provider, updated continuously, and can be switched off at will. This dynamic creates legal risks that a standard MSA, drafted for professional services, is completely unprepared to address.
SaaS agreements need purpose-built provisions on uptime, data ownership, security, API access, multi-tenancy, and the consequences of product discontinuation. Here is what belongs in every SaaS-specific MSA or Order Form.
How SaaS contracts differ from standard MSAs
The SLA: your minimum uptime guarantee
A Service Level Agreement defines the provider's availability commitment and the consequences of failing to meet it. The headline availability percentage — typically "99.9%" — sounds impressive but translates to 8.7 hours of permitted downtime per year. "99.99%" allows only 52 minutes. For mission-critical systems, 99.95% (4.4 hours/year) is a reasonable minimum.
But the availability percentage is only the start. The SLA must also define: how downtime is measured (third-party monitoring vs provider self-reporting), what constitutes an "outage" vs a "degraded service" event, the credit calculation methodology, the maximum total credit per billing period, and — crucially — whether credits are the exclusive remedy or whether the customer retains the right to terminate for persistent underperformance.
Maintenance windows
Scheduled maintenance windows are typically excluded from downtime calculations. Ensure the MSA specifies the maximum frequency and duration of maintenance windows, the advance notice period (typically 72 hours for standard maintenance, immediate for emergency), and restrictions on maintenance during your business-critical hours.
Data: the most important SaaS clause
Data ownership
Customer data is and remains the customer's property. The provider has a limited licence to process it solely for the purpose of delivering the service. The provider may never use customer data to train AI models, build derived products, or share with third parties without explicit written consent.
Data portability
Customer has the right to export all their data in a machine-readable, standard format (CSV, JSON, XML) at any time during the subscription. On termination, a minimum 30-day export window must be available before deletion.
Data deletion
On expiry or termination, the provider must delete all customer data within 90 days and provide a written confirmation of deletion. Any backup copies must be deleted within the same period.
Data residency
If data residency is required (India, EU, etc.), the contract must specify the geographic location of data storage and processing, and the provider must warrant that data will not be transferred outside the specified region without prior written consent.
Sub-processors
The provider must maintain a list of sub-processors (third-party services with access to customer data: cloud infrastructure, analytics tools, support platforms). Customer must be notified of any changes and retain the right to object.
Product changes and feature deprecation
Unlike a traditional service provider who changes scope only through a Change Order, a SaaS provider continuously updates its product. Features are added, modified, and removed. For enterprise customers, this unilateral change right creates a genuine business risk — a workflow built around a specific feature can be broken overnight by a product update.
The SaaS MSA should require the provider to give a minimum 90-day notice before removing or materially changing any feature that is listed in the Order Form or that the customer has demonstrated reliance on. It should also prohibit price increases during the current subscription term and restrict increases at renewal to a defined percentage (CPI + a cap).
Minimum SaaS contract checklist
- SLA with defined availability %, credit methodology, and termination right for persistent failure
- Data ownership, portability, deletion, and residency requirements
- Data Processing Agreement aligned to applicable law (DPDP Act in India, GDPR if EU data involved)
- Security standards: SOC 2 Type II, ISO 27001, or equivalent certification required
- Incident notification: breach notification within 72 hours of discovery
- Feature deprecation notice: minimum 90 days for material changes
- Price lock for current term; capped increase at renewal
- API access terms: rate limits, versioning policy, deprecation notice period
- Liability for data breach: should not be capped at 1 month's fees for enterprise data
- Right to audit security practices or accept third-party audit reports annually
Data Processing Agreements
under the DPDP Act 2023
India's Digital Personal Data Protection Act creates new contractual obligations for every company that shares personal data with a service provider. Here is what your contracts need to say.
The Digital Personal Data Protection Act, 2023 (DPDP Act) represents the most significant change to India's data privacy landscape in a generation. While rules and enforcement timelines are still being finalised, the Act's substantive obligations are clear — and they have direct, material implications for every commercial contract in which one party processes personal data on behalf of another.
If your company uses a cloud provider, a payroll processor, a CRM system, a marketing platform, or any service that handles the personal data of your employees or customers, you need a Data Processing Agreement (DPA) aligned to the DPDP Act. Here is what that means in practice.
Key definitions under the DPDP Act
Data Principal
The individual to whom personal data relates. Your customers, employees, and users. They have rights under the Act that must be facilitated by both the Data Fiduciary and the Data Processor.
Data Fiduciary
The entity that determines the purpose and means of processing personal data. Typically the company — the client in a B2B relationship. Bears primary legal responsibility under the Act.
Data Processor
The entity that processes personal data on behalf of the Data Fiduciary. The vendor, cloud provider, or service company. Must process only as directed — any independent processing makes them a Data Fiduciary.
Personal Data
Any data about an identifiable individual. Names, contact details, financial information, health data, device identifiers, location data, and any combination of data that can identify a person.
What the DPDP Act requires of Data Fiduciaries
The Act places the primary compliance burden on Data Fiduciaries. They must collect only the personal data that is necessary for the stated purpose (data minimisation), obtain valid consent before processing (with specific requirements for how consent is obtained and recorded), and ensure that any Data Processor they engage is contractually bound to the same standards.
This last obligation is the DPA trigger. The Act effectively requires that every arrangement in which a company shares personal data with a service provider be governed by a contract that meets the Act's requirements. A standard MSA confidentiality clause is not sufficient.
Mandatory clauses in every DPDP-compliant DPA
Processing purpose limitation
The Data Processor may process personal data only for the specific purposes instructed by the Data Fiduciary as set out in the agreement. Any processing for the Processor's own purposes (product improvement, analytics, AI training) is prohibited without express written consent.
Data Principal rights facilitation
The Processor must assist the Fiduciary in fulfilling Data Principal rights: access requests (within 72 hours), correction requests, erasure requests, grievance resolution, and nomination rights. Timelines for Processor response must be defined.
Security safeguards
The Processor must implement and maintain appropriate technical and organisational measures. Specific standards (ISO 27001, SOC 2, or equivalent) should be referenced. Annual certification or third-party audit reports should be required.
Data breach notification
The Processor must notify the Data Fiduciary of any personal data breach within 6 hours of discovery. The notification must include the nature of the breach, categories and volume of data affected, likely consequences, and measures taken or proposed.
Sub-processor control
The Processor may not engage sub-processors without the prior written consent of the Data Fiduciary. The Processor remains fully liable for the compliance of its sub-processors as if it were processing the data itself.
Cross-border transfer restrictions
Personal data of Indian residents may only be transferred to countries notified by the Central Government as permissible destinations. The DPA must restrict the Processor from transferring data outside permitted jurisdictions.
Return and deletion on termination
On termination of the agreement, the Processor must return all personal data to the Fiduciary in a standard format within 30 days, delete all copies (including backups), and provide written certification of deletion within 90 days.
Audit rights
The Data Fiduciary has the right to audit the Processor's compliance with the DPA annually, or following any security incident. The Processor must cooperate fully and provide access to relevant systems, records, and personnel.
Penalties under the DPDP Act
| Breach | Maximum penalty |
|---|---|
| Failure to implement security safeguards leading to a data breach | ₹250 crore |
| Failure to notify a data breach to the Data Protection Board | ₹200 crore |
| Non-fulfilment of Data Principal rights obligations | ₹150 crore |
| Processing children's data in violation of the Act | ₹200 crore |
| General violations of the Act and Rules | ₹50 crore |
The DPDP Act holds the Data Fiduciary primarily responsible — even for violations committed by the Data Processor. This makes a robust DPA not merely a compliance formality but a contractual indemnification mechanism. The DPA should require the Processor to indemnify the Fiduciary for any penalties arising from the Processor's non-compliance.
Significant Data Fiduciaries: additional obligations
The DPDP Act empowers the Central Government to designate certain entities as "Significant Data Fiduciaries" (SDFs) based on the volume and sensitivity of the personal data they process. SDFs face additional obligations including mandatory appointment of a Data Protection Officer, periodic data protection impact assessments, and algorithmic audits of their processing systems. If your company is designated an SDF — or if your Data Processor is — the DPA must reflect these heightened obligations.
Relationship with existing MSA and NDA provisions
A DPDP-compliant DPA should be incorporated into the MSA as either a schedule or a separate agreement, with a clear hierarchy clause (DPA prevails over MSA for all personal data processing matters). The MSA's confidentiality clause may continue to govern business confidential information, but personal data must be governed by the DPA exclusively. Mixing the two in a single confidentiality clause creates compliance uncertainty.
Comments
Post a Comment