SaaS agreement checklist

Describe the service at the account boundary

Name the contracting entities, customer type, authorised users, account administrator, permitted use, usage limits, territories, environments, integrations, and technical dependencies. Explain how users authenticate, what the customer controls, and which actions the provider may take. A subscription for internal employee use differs from a platform embedded in the customer's customer workflow. If affiliates or contractors may use the service, define their position and the customer's responsibility. Address trials, beta features, free tiers, and preview functions separately, including data and support treatment. Product documentation and order forms should not contradict the agreement. Keep a versioned service description that sales cannot change through an informal promise. The licence or access grant, restrictions, feedback, benchmarking, reverse engineering, and acceptable-use rules need current legal review and should remain proportionate to the product.

Product ownership should be explicit.

• Entities, users, and account administrator
• Permitted use and technical limits
• Integrations and customer dependencies
• Trials, beta features, and previews
• Versioned product description

Make service and support promises measurable

State availability measure, exclusions, maintenance, incident channels, support hours, response targets, severity levels, credits, and any service-reporting process only after operations confirms the data can be produced. Distinguish response from resolution. Avoid a credit scheme so complicated neither side can calculate it. Security commitments should match the architecture and current control programme. If the agreement names a certification, encryption method, hosting location, backup period, recovery target, or penetration-test cadence, verify it and create an owner for changes. Deal with material feature changes, deprecated integrations, and notices in a way that gives the customer useful information without freezing development. The contract may reserve a right to change the service, but the product team still needs a process for changes that remove core functionality or affect regulated use. Promise what the system and team can evidence today.

• Availability measure and exclusions
• Support channel and severity rules
• Credits the billing team can calculate
• Verified security and recovery commitments
• Material-change and deprecation process

Trace data through the contract set

Draw the data flow across collection, customer input, hosting, support, analytics, subprocessors, exports, backups, and deletion. Separate customer content, account data, usage telemetry, support records, and provider-generated insights. The main agreement should allocate control and use at a readable level, while a data processing agreement and security schedule hold the required detail. Do not grant the provider a broad right to use customer data for any purpose if the product team means only service delivery and aggregated operations. AI training or model-improvement use needs explicit product, privacy, IP, confidentiality, and customer analysis. State breach cooperation, rights-request assistance, audit evidence, location, retention, return, and deletion consistently. The DPDP Act, final 2025 Rules, sector requirements, and other applicable regimes should be checked against the current data roles and commencement position.

Keep the map versioned.

• Data categories, purposes, and locations
• Customer and provider control points
• Subprocessors and support access
• AI or analytics use
• Return, retention, and deletion

Make billing, suspension, and exit survivable

Define subscription term, renewal, usage measurement, fees, taxes, invoice detail, payment date, disputed charges, price changes, and currency. Suspension should be tied to stated events such as security threats, unlawful use, or material non-payment, with notice where the circumstances allow and a route to restore service. Termination clauses need to distinguish breach, convenience if offered, insolvency, and prolonged service failure. The customer should know how and when it can export data, in which format, at what cost, and when access and backups end. The provider should know what support is included and what requires a paid transition. Liability, indemnity, warranty, governing law, and dispute terms need independent review against the risk and customer type. Test the contract against a missed renewal notice, a disputed usage bill, a security suspension, and a customer migration.

• Term, renewal, and usage billing
• Tax, currency, and invoice disputes
• Notice and restoration after suspension
• Export format and access window
• Transition support and deletion schedule