Startup Customer Terms of Service Checklist for Indian Founders: Scope, Payment, Liability, DPDP and Exit Clauses
A sale is only as clean as the promise your startup can prove, deliver and exit from when the relationship gets difficult.
Direct answer
Customer terms are not a legal page that can wait until the startup is bigger. They are the operating manual for what your team promised, what the customer must pay, how data can be used and what happens when either side wants out.
For Indian founders, a practical review starts with the Indian Contract Act, 1872, the company’s sales process and the Digital Personal Data Protection framework. The Best CS Firm In India lens is simple: every commercial promise should have an owner, evidence and a documented limit.
When this checklist applies
| Sales model | Contract format | Main risk to control |
|---|---|---|
| Self-serve SaaS | Online terms plus click acceptance | Version control, payment, acceptable use and data terms |
| Enterprise SaaS | MSA, order form and DPA | Scope creep, security review, liability and procurement redlines |
| Professional services | Engagement letter or SOW | Deliverables, acceptance, dependencies and IP |
| Marketplace or platform | Platform terms and participant rules | Role allocation, conduct, payouts and dispute process |
The non-negotiable clauses
- Contracting entity and order: identify the legal entity, customer, product, order form, start date and plan.
- Scope and acceptance: distinguish included services from optional work; record how a deliverable is accepted or rejected.
- Fees and taxes: state currency, billing cycle, payment due date, GST treatment, late-payment consequence and refund rule.
- Customer responsibilities: record access, approvals, lawful data, user conduct and technical dependencies the customer controls.
- Data and security: describe permitted processing, security measures, sub-processors, incident escalation and deletion or return.
- IP: preserve the startup’s platform, pre-existing material and know-how; define rights in bespoke deliverables.
- Risk allocation: use a clear liability cap, exclusions and appropriate indemnity triggers instead of vague promises.
- Suspension and exit: define non-payment suspension, termination notice, data-export window and transition support.
DPDP and customer-data checklist
Do not copy a foreign DPA without mapping the actual product. Ask what personal data the customer uploads, whether your team can see it, where it is hosted, which vendors receive it, how long it remains available after cancellation and who owns incident communication. Record the answer in the product schedule and security annexure.
| Question | Evidence to keep | Owner |
|---|---|---|
| What data is processed? | Data map and product description | Product and security |
| Why is it processed? | Contract purpose and customer instructions | Legal and product |
| Which vendors receive it? | Sub-processor list and vendor review | Security and procurement |
| How is it protected? | Access matrix, encryption and incident playbook | Engineering and security |
| What happens on exit? | Export, deletion and access-revocation record | Support and engineering |
Before sending terms to a customer
- Confirm the correct company entity is named on the proposal, invoice and contract.
- Attach a precise order form or SOW rather than burying scope in email threads.
- Check that sales has not offered unapproved uptime, implementation dates, custom integrations or security commitments.
- Match the payment clause to the invoice and collection workflow.
- Save the accepted version, signer or click record, amendments and customer notices in one deal folder.
Mistakes that create expensive disputes
- Calling a sales deck a contract when it has no acceptance process.
- Allowing a customer to add unlimited users, support or custom work under a fixed fee.
- Using an unlimited liability promise for a low-value subscription.
- Ignoring data-export and deletion obligations until an enterprise customer leaves.
- Failing to preserve the exact online terms version accepted by a customer.
Founder / Business Takeaway
Good customer terms protect revenue and reputation at the same time. They set expectations before delivery starts and give finance, support, engineering and legal a shared answer when a deal changes course.
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.
Suggested internal links
FAQ
Do Indian startups need written customer terms?
Yes. Written and accepted terms make scope, fees, data, IP, liability and exit rights substantially easier to prove.
Can terms sit only on a website?
For standard self-serve products, yes, if acceptance and version records are retained. Bespoke engagements need a signed order form or agreement.
What should a SaaS startup say about customer data?
Set out purpose, security, access, sub-processors, incident escalation, retention and the return or deletion process.
