Contract Review Guide

Software license agreement red flags

Software and SaaS agreements are presented as standard forms that vendors rarely negotiate. Many are. But standard doesn't mean risk-free: provisions around data rights, post-termination data access, audit rights, indemnification scope, and usage restriction definitions appear in nearly every enterprise software agreement, and their specific drafting determines whether you're exposed to data loss, unexpected liability, or significant operational disruption if the vendor relationship ends. This guide covers the provisions that consistently produce the most regret after signing — and what to ask for before you do.

Review your software contract with AI Compare contract versions

Data rights provisions: what the vendor can do with your data

Modern software agreements routinely grant vendors broad rights to use customer data for purposes beyond delivering the service. The scope varies enormously by how these provisions are drafted.

Aggregated or anonymized data use rights

Nearly all enterprise SaaS agreements include a provision permitting the vendor to use customer data in aggregated or anonymized form for product improvement, benchmarking, or research. This is largely standard and generally acceptable. The red flag is a provision that doesn't limit the use to aggregated or anonymized data — or where 'anonymized' is defined in a way that doesn't prevent re-identification. Watch for: 'We may use your data to improve our services and products' without any aggregation or anonymization requirement. This language, without qualification, potentially permits use of your identifiable customer or proprietary data for vendor purposes beyond your service.

Training machine learning models on your data

Newer agreements — particularly from AI-assisted tools — may include provisions permitting training AI or machine learning models on customer content. This warrants attention beyond the standard aggregated-data carve-out: your proprietary documents, internal communications, or customer data could contribute to a model that benefits the vendor's other customers or is embedded in competitor products. Watch for: 'We may use your content to train or improve AI features' or 'you grant us a license to use content submitted to the service for the purpose of improving our artificial intelligence capabilities.' If the vendor offers AI features powered by customer data, understand explicitly whether your data opts into model training and whether you can opt out.

Broad license grants to customer data

Agreements commonly include a license grant permitting the vendor to process customer data as necessary to provide the service — this is required for the service to function and is appropriate. The red flag is a broader license that extends beyond service delivery: 'You grant us a perpetual, irrevocable, worldwide license to use, reproduce, distribute, display, and create derivative works from content you upload to the service.' Perpetual and irrevocable licenses to customer data extend beyond the service relationship. If the agreement terminates, a perpetual license on your data continues.

Sub-processing and third-party data sharing

Vendors routinely share customer data with sub-processors (infrastructure providers, analytics vendors, support tools). Well-drafted agreements name sub-processors or maintain a list and commit to notifying customers of material changes. Red flags: no sub-processor disclosure, a provision that allows the vendor to share data with 'affiliates, partners, and service providers' without restriction, or a list that's so broad it provides no practical protection. For regulated industries or data subject to privacy obligations, sub-processor controls are legally significant.

Termination provisions: what happens when the contract ends

Post-termination access to your data and the exit process are among the most practically consequential provisions in a software agreement — and among the most commonly regretted when not reviewed carefully.

Data export and portability after termination

What access do you have to your data after the subscription ends? Well-drafted agreements provide a defined window — typically 30–90 days — during which the customer can export all data in a standard format. Red flags: no data export provision; an export window of fewer than 30 days; export limited to 'data that can be exported through the standard interface' without committing to a standard format; or a provision that deletes data immediately upon termination with no grace period. If your data is in a proprietary format that only the vendor's platform can read, leaving without an export plan means losing it.

Data deletion obligations after termination

Understand both sides of data retention on termination: what the vendor is obligated to delete, and what they're permitted to retain. Well-drafted agreements include a commitment to delete customer data within a defined period after the termination window closes, with some exceptions for backup retention governed by data retention policies. Red flags: no deletion commitment; vendor retains broad rights to keep customer data 'as required by applicable law or as reasonably necessary for legitimate business purposes' — language that creates indefinite retention authority rather than a defined deletion obligation.

Termination-for-convenience restrictions

Can you exit the contract if the vendor's service deteriorates, the product doesn't meet your needs, or your business circumstances change? Some agreements limit termination to cause only — you can only exit if the vendor materially breaches and fails to cure. Others permit termination for convenience with advance notice. Red flags: no termination-for-convenience right; termination for convenience triggers financial penalties equivalent to the remaining contract term (effectively locking you in); or early termination fees that aren't capped or aren't disclosed in the main agreement (appearing only in an incorporated pricing schedule).

Automatic renewal and price change provisions

Automatic renewal provisions renew the agreement for a successive term unless notice is given within a defined window before expiration. This is standard but the notice window matters: a 90-day or 120-day notice requirement in an annual agreement means you must decide well before year-end whether to renew. Red flags: notice windows longer than 60 days without a corresponding reminder from the vendor; provisions that allow the vendor to change pricing at renewal without notice or with notice only after the notice window has closed; or renewal terms that automatically move to list pricing regardless of the rate negotiated for the initial term.

Usage restrictions: what you're actually licensed to do

Software license agreements define a scope of permitted use, and activity outside that scope can trigger breach claims or license fees — often by definitions that don't match how the software is actually used.

Definition of 'authorized users' and seat restrictions

Enterprise software agreements typically license by 'authorized user' — a defined set of individuals permitted to access the software. The definition of authorized user, and how compliance is measured, determines your exposure. Red flags: authorized users defined to exclude contractors, consultants, or non-employees (common in actual enterprise software use); per-seat license where 'seat' includes concurrent users so logging in from two devices simultaneously is a violation; audit rights that allow the vendor to verify usage and charge back-license fees plus penalties for any usage above licensed seats.

Permitted use restrictions that exclude your actual use case

Many agreements restrict use to 'internal business purposes' or limit deployment to a single entity. Red flags: restrictions that prohibit use by subsidiaries, affiliates, or acquired companies without an additional license — relevant if your corporate structure changes; restrictions on 'commercial use' or 'resale' that are drafted broadly enough to capture white-label deployments, customer-facing tools built on the platform, or any use generating revenue from the software's output; or restrictions on specific industries ('not for use in financial services / healthcare / government') that appear in general terms rather than the order form.

Fair use policies and usage limits that aren't in the main contract

Actual usage limits — storage quotas, API call limits, transaction volumes — are often specified in separate acceptable use policies, service documentation, or fair use policies incorporated by reference rather than in the main agreement. Red flags: 'use subject to fair use guidelines as updated from time to time' with no link and no commitment to notify of changes; usage limits in a separate document that the vendor can update without customer consent; or SLA metrics that are defined in documentation the vendor can modify unilaterally.

Restrictions on reverse engineering, competitive use, and benchmarking

Most software agreements prohibit reverse engineering (extracting source code from compiled software) and often prohibit using the software for competitive intelligence. Red flags: prohibition on using the software to 'develop, improve, or assist with competing products' — which could extend to using an AI writing tool whose output helps you evaluate or compete with the vendor; prohibition on 'publishing or disclosing benchmark results' — prevents you from publicly comparing performance metrics even for your own procurement decisions; or restrictions that prohibit describing the software's limitations to third parties, including in internal communications.

Indemnification and liability exposure

Software agreement liability provisions routinely contain asymmetries that create significant exposure for buyers. These provisions are often presented as standard market terms even when they're not.

One-sided IP indemnification

IP indemnification protects the customer if using the vendor's software infringes a third party's intellectual property rights. Mutual IP indemnification — where both parties indemnify the other for their respective IP — is the appropriate structure. Red flags: IP indemnification that runs only from vendor to customer but requires the customer to indemnify the vendor against claims arising from 'customer content, customer data, or customer modifications to the software' — the customer-side indemnification can be much broader than the vendor-side protection if customer content or customization is likely to generate claims. Also watch for IP indemnification carve-outs that gut the vendor's obligation: 'vendor has no obligation to indemnify claims arising from customer combination of the software with third-party products' can eliminate the indemnification for virtually every real-world use.

Uncapped indemnification obligations for data breach

Data breach and privacy indemnification provisions require one party to cover costs arising from unauthorized data access. The exposure is real and potentially very large — regulatory fines, customer notification costs, litigation. Red flags: customer is required to indemnify the vendor against any data breach claims 'arising from customer's use of the service' — if the vendor's platform is breached but the breach is characterized as enabled by how the customer configured it, this provision shifts the cost to the customer. Also watch for mutual breach indemnification that doesn't have a clear scope: who pays for a breach that results from vendor negligence but affects customer data?

Mutual liability cap exclusions that benefit only the vendor

Limitation of liability provisions cap each party's total exposure. The standard enterprise structure is a mutual cap — both parties' liability limited to 12 months of fees, with exclusions for fraud, willful misconduct, and sometimes death/personal injury. Red flags: caps that apply symmetrically to exclude consequential damages but where the consequential damages exclusion is significantly more valuable to the vendor than the customer (customer data loss is almost entirely consequential; vendor fee non-payment is direct); carve-outs from the cap for IP indemnification that run only from customer to vendor, creating unlimited customer indemnification exposure; or liability caps that apply per-event rather than in aggregate, potentially resetting with each incident.

SaaS-specific provisions that don't appear in traditional software licenses

SaaS agreements introduce obligations and risks specific to cloud delivery that traditional perpetual software licenses don't address.

Service level agreements and remedies

SaaS agreements typically include uptime commitments (often 99.9% or 99.5% measured monthly) with associated service credits for downtime. Red flags: uptime calculated monthly rather than annually (a 0.1% monthly downtime threshold permits 8.8 hours of outage per year but only 26 minutes per month); service credits as the sole remedy for SLA failure — preventing termination even for sustained outage; exclusions from SLA measurement that swallow the commitment ('excluding scheduled maintenance, force majeure, and events outside vendor's control' can cover most real-world outage causes); or service credits capped at one month's fees regardless of outage duration or business impact.

Feature change and deprecation rights

Vendors delivering SaaS retain the right to modify the product. Well-drafted agreements provide notice of material changes and a right to terminate if the change materially degrades the service. Red flags: 'vendor may modify or discontinue features at any time without notice'; no definition of what constitutes a material change that triggers customer rights; or modifications that the vendor can make that change pricing (adding features to a higher tier, removing features from the current tier) without customer consent.

Audit rights and compliance verification

Enterprise software agreements routinely include audit rights permitting the vendor to verify that usage complies with the license. The scope of these rights matters significantly. Red flags: audit rights that allow the vendor to access your systems, network, or internal systems rather than just the vendor's own usage logs; audits that can be triggered at any time without prior notice; audit costs borne by the customer regardless of whether the audit reveals compliance violations; or audit provisions that define usage overcounting as requiring the customer to purchase additional licenses retroactively at list price rather than at negotiated rates.

Are software vendor agreements really negotiable, or are they standard form contracts?+

It depends on commercial scale. For enterprise contracts (typically $50,000+ annual value), most provisions are negotiable — vendors expect redlines and have a standard negotiation playbook. Data rights, termination access, liability caps, and audit rights are the provisions most commonly modified in enterprise negotiations. For mid-market agreements ($5,000–$50,000), some provisions are negotiable but fewer, and vendor legal teams may have limited bandwidth for lengthy negotiations. For SMB and consumer SaaS (monthly subscriptions under $1,000/month), contracts are effectively standard form — take it or leave it. The strategic question: which provisions warrant the legal cost of negotiation given the contract value and risk profile?

What is the most important provision to negotiate in a SaaS agreement?+

For most business buyers: data portability and post-termination data access. If the vendor relationship ends — whether due to termination, the vendor's insolvency, or product discontinuation — your ability to recover your data in a usable format determines whether you can continue operations. Second: the limitation of liability and consequential damages exclusion. Third: audit rights scope (whether audits can compel access to your systems vs. just the vendor's usage records). The relative priority shifts with the use case: for heavily integrated platforms, termination data rights matter most; for high-volume transaction processing, SLA remedies matter more.

What does 'vendor may use aggregated and anonymized data' mean in practice?+

It means the vendor can combine data from all customers, strip identifying information, and use the resulting aggregate for product improvement, benchmarking, or research. In practice: your transaction volumes contribute to a vendor's industry benchmark report; your error rates inform the vendor's product roadmap; your content patterns train the vendor's AI-assisted features. Standard aggregated/anonymized use rights are broadly accepted market practice. The questions worth asking: Is anonymization technically adequate? Does the agreement define anonymization standards? Can the vendor use content (not just behavioral data) in this way? And is there an opt-out?

What happens to my data if I stop paying for a SaaS subscription?+

If you stop paying, the vendor will typically suspend access and may begin a termination process. What happens to your data during and after suspension depends on the contract: well-drafted agreements keep data accessible for a grace period even after payment lapse and provide an export window after formal termination. Poorly drafted agreements (or standard consumer-tier terms) may delete data immediately upon subscription lapse. Before signing or renewing, verify: how long the vendor retains data after termination; what notice they give before deletion; whether you can export in a standard format; and what format is supported for export.

What is an audit rights provision and should I be concerned about it?+

An audit rights provision allows the vendor to verify that you're using the software within the scope of your license — primarily to catch users who have more active accounts than they've licensed. Reasonable audit rights: the vendor reviews their own usage logs, with prior notice, costs borne by the vendor if no violation is found. Aggressive audit rights: the vendor can access your systems or require you to provide internal documentation; audits can be triggered at any time without notice; any overage found must be purchased at list price retroactively for the full audit period. For usage-based or seat-based licenses, understand exactly how compliance is measured and what triggers an audit before signing.

How can AI help with reviewing a software license agreement?+

AI contract review tools read the agreement and flag specific provisions that match patterns associated with buyer risk — data rights that extend beyond service delivery, post-termination access shortfalls, broad audit rights, unlimited indemnification obligations, and liability cap structures that favor the vendor. The output includes the actual contract language flagged with plain-language explanations of why each provision is notable. This is useful for identifying which sections of a standard-form agreement have been customized (often unfavorably) and for generating specific negotiation questions. AI review finds and explains specific provisions; for significant contracts, a lawyer who understands your regulatory context and risk tolerance advises on which risks to accept and how to negotiate.