B2B SaaS Customer Contract Checklist for Indian Startups: MSA, SLA, Data, IP, Payment and Liability Terms
Indian B2B SaaS founders should not sign enterprise customer contracts only for logo value. Before signing an MSA, pilot agreement, subscription order form or annual software contract, the company should check…
Direct answer for founders
Indian B2B SaaS founders should not sign enterprise customer contracts only for logo value. Before signing an MSA, pilot agreement, subscription order form or annual software contract, the company should check scope, payment terms, service levels, data use, IP ownership, confidentiality, liability cap, indemnity, renewal, termination, audit rights, security obligations and dispute forum.
The practical risk is simple. A startup can close a customer and still create a bad contract: unlimited liability, unclear deliverables, free customisation, broad customer audit rights, weak payment protection, no suspension right, unclear DPDP allocation or IP language that accidentally gives the customer ownership over the product.
The legal base is not exotic. The Indian Contract Act, 1872 supports enforceable contracts and should be the first reference point for commercial obligations (https://www.indiacode.nic.in/handle/123456789/2187). The Information Technology Act, 2000 is relevant for electronic records and digital contracting context (https://www.indiacode.nic.in/handle/123456789/1999). If the SaaS product processes digital personal data, founders should also review the Digital Personal Data Protection Act, 2023 through MeitY resources (https://www.meity.gov.in/data-protection-framework). Company authority, board approvals, related-party points and records sit under the Companies Act, 2013 (https://www.mca.gov.in/Ministry/pdf/CompaniesAct2013.pdf).
The contract stack founders should understand
| Document | What it should do | Founder risk if ignored |
|---|---|---|
| Master Services Agreement | Sets legal and commercial base for the relationship | Customer terms may override startup controls |
| Order Form or SOW | Records product, users, price, term, support and deliverables | Sales promises become open-ended obligations |
| SLA | Defines uptime, support response and service credits | Every outage becomes a negotiation |
| Data Processing Addendum | Allocates data roles, processing purpose, security and deletion | DPDP and privacy questions remain unresolved |
| Security Schedule | Explains controls, incident notice, audit and access standards | Security promises become unrealistic |
| Pilot or POC Agreement | Limits trial scope, duration, data, fees and conversion | Free pilots turn into unpaid implementation work |
Clause-by-clause checklist
1. Scope of product and services
Define the subscribed product, modules, number of users, usage limits, implementation services, integrations, reporting, APIs, training and support channel. Do not allow a generic line such as “all services required for successful deployment” unless the price and delivery team can support it.
For a startup, scope creep is a cash-flow issue. A customer may expect custom dashboards, migration, integrations, support calls, security reviews and training without realising each request consumes founder time.
2. Fees, invoicing and taxes
The agreement should say whether pricing is monthly, annual, per user, usage-based, platform fee, implementation fee or minimum commitment. Check GST, TDS, withholding, foreign remittance, late payment, invoice disputes and whether fees are refundable.
Useful controls:
- Invoice due date should be clear.
- Taxes should be charged as applicable.
- Undisputed invoices should be paid even if one small item is disputed.
- Late payment should allow suspension after notice.
- Renewal pricing should not be left uncertain where the customer expects a fixed commercial path.
3. Service levels and support
Service levels should match the stage of the product. A seed-stage startup should be careful before accepting enterprise-grade 99.99 percent uptime, 24×7 phone support, severe service credits or immediate incident response if the team cannot deliver that operationally.
| SLA item | Founder question |
|---|---|
| Uptime | Is the commitment technically realistic? |
| Exclusions | Are planned maintenance, force majeure, customer systems and third-party outages excluded? |
| Support hours | Does the team actually provide weekend or night support? |
| Response time | Is it response time or resolution time? |
| Service credit | Is the credit capped and is it the customer’s only remedy for SLA failure? |
4. Data, DPDP and security
If the product handles employee data, customer data, payment data, health data, financial data, user behaviour or voice records, the contract should say what data is processed, for what purpose, who instructs processing, how deletion works, what security controls apply and what happens after termination.
Founders should prepare:
- Privacy notice.
- Data processing addendum.
- Security control summary.
- Incident response process.
- Access control and sub-processor list.
- Data retention and deletion policy.
- Logs showing who can access customer environments.
DPDP readiness is not only a legal page on the website. It must appear in product design, contracts, vendor flows and incident handling.
5. IP ownership and product improvements
The startup should retain ownership of its platform, source code, models, workflows, documentation, templates, connectors, analytics and general product improvements. The customer may own its data, brand assets, uploaded content and specific confidential materials.
Be careful with clauses saying the customer owns “all work product” or “all developments arising from the services”. That wording can accidentally capture reusable software improvements. If the customer pays for custom work, define whether it is exclusive, non-exclusive, assigned, licensed or reusable.
6. Confidentiality
Confidentiality should protect pricing, roadmaps, security details, customer data, product architecture, audit reports, source code, business plans and non-public performance data. The clause should cover oral, electronic, visual and written disclosures. It should also define who inside the customer’s organisation can access sensitive material.
Free Weekly Newsletter
Subscribe to BSA startup funding alerts
- Every Sunday, all Indian startup funding alerts in one place
- Monthly funding report on the last day of the month
- Free, concise, founder-focused, and easy to unsubscribe
Get the complete Indian startup funding roundup in your inbox, covering deals, sectors, investor moves, and founder readiness notes from the week.
Built for founders, investors, CFOs, and advisors
No spam. Unsubscribe anytime.
7. Liability cap
Unlimited liability can make one customer contract larger than the startup’s entire balance sheet. A common founder-friendly structure is a liability cap linked to fees paid in the previous 6 or 12 months, with carefully drafted exceptions for confidentiality, IP infringement, wilful misconduct, payment obligations and data breach depending on negotiation strength.
The key is not to copy a cap from another contract. The cap should reflect deal value, product risk, data sensitivity, insurance, customer leverage and the startup’s ability to survive a claim.
8. Indemnity
Customers often ask the SaaS company to indemnify them for IP infringement, data breach, confidentiality breach, third-party claims and regulatory violations. Founders should check:
- What claims are covered.
- Whether defence control is clear.
- Whether the customer must notify promptly.
- Whether settlement needs consent.
- Whether indemnity is subject to the liability cap.
- Whether exclusions apply where the claim arises from customer data, misuse, unauthorised modifications or third-party integrations.
9. Audit and security review
Enterprise customers may ask for penetration-test reports, SOC reports, ISO certificates, audit access, vendor questionnaires and on-site review. Early-stage startups should offer reasonable documentation but avoid open-ended audit rights that disrupt operations or expose other customer information.
10. Termination, renewal and exit
The contract should explain initial term, renewal, termination for breach, termination for convenience, unpaid invoices, effect of termination, data export, deletion, transition support and survival of key clauses.
Founders should avoid silent auto-renewal surprises on both sides. If renewal is automatic, state notice period and pricing clearly. If the customer can terminate for convenience, check whether prepaid fees are refundable.
Founder diligence folder for customer contracts
| Folder | Documents to keep |
|---|---|
| Signed contracts | MSA, SOW, order form, SLA, DPA, amendments |
| Contract tracker | Customer, term, renewal date, payment terms, liability cap, governing law |
| Security | Security questionnaire, incident process, access controls, audit reports |
| Data | DPA, sub-processor list, retention policy, deletion certificate template |
| Finance | Invoices, GST records, TDS, receivables ageing and payment disputes |
| Product | Custom commitments, roadmap promises, integration scope and support notes |
Common mistakes founders should avoid
- Signing the customer’s procurement template without marking business-critical changes.
- Accepting unlimited liability to win a small annual contract.
- Giving away product IP through broad work-product language.
- Promising security certifications the company does not have.
- Treating DPDP as a website-policy issue instead of a contract and product issue.
- Leaving renewal dates and price changes outside the contract tracker.
- Letting sales teams promise custom features without product and legal sign-off.
- Ignoring GST, TDS and withholding language in cross-border or enterprise deals.
A seven-day cleanup plan
| Day | Action |
|---|---|
| 1 | List all live customer contracts and renewal dates |
| 2 | Mark liability caps, termination rights and payment terms |
| 3 | Check data-processing and security commitments |
| 4 | Identify custom commitments and roadmap promises |
| 5 | Reconcile invoices, receivables, GST and TDS positions |
| 6 | Prepare standard MSA, DPA, SLA and order-form templates |
| 7 | Build a contract approval workflow for sales, product, finance and founders |
Founder next steps
Create one standard contract stack before the next enterprise negotiation: MSA, order form, DPA, SLA and security annexure. Then create a contract tracker that the founder, finance lead and sales owner actually update. The Best CS Firm In India approach is to make customer contracting disciplined without slowing good sales momentum.
Sources
- Indian Contract Act, 1872 on India Code: https://www.indiacode.nic.in/handle/123456789/2187
- Information Technology Act, 2000 on India Code: https://www.indiacode.nic.in/handle/123456789/1999
- Digital Personal Data Protection Act, 2023 resources, MeitY: https://www.meity.gov.in/data-protection-framework
- Companies Act, 2013, Ministry of Corporate Affairs: https://www.mca.gov.in/Ministry/pdf/CompaniesAct2013.pdf
FAQ Section
Does every SaaS startup need an MSA?
If the startup signs B2B or enterprise customers, an MSA is strongly recommended because it keeps legal terms separate from changing order forms, pilots and subscription details.
Should a SaaS startup accept the customer’s contract template?
Sometimes, but only after review. Customer templates often include broad indemnity, audit rights, data obligations, security commitments and liability exposure that may not fit an early-stage startup.
What is the biggest risk in SaaS customer contracts?
The biggest risk is taking operational or financial responsibility that the startup cannot actually support, especially unlimited liability, unrealistic SLA commitments and broad data-security promises.
Is a privacy policy enough for DPDP readiness?
No. SaaS startups should also review data roles, processing purpose, security, sub-processors, deletion, incident response and customer instructions in contracts and product workflows.
What should investors check in customer contracts?
Investors usually check revenue quality, renewal risk, payment disputes, liability caps, customer concentration, IP ownership, data obligations and unusual termination rights.
Founder / Business Takeaway
A signed customer logo is valuable only when the contract is operable. Founders should protect revenue, data, IP and delivery capacity before a contract becomes an investor diligence file.
Need expert support?
BSA helps Indian startups prepare SaaS customer contracts, DPAs, SLAs, vendor terms, IP clauses, compliance trackers and investor-ready contract data rooms.
Need expert support?
BSA supports founders across India with ROC, FEMA, due diligence, fundraising readiness, and company secretarial execution.
