Cloud Services Agreement Template and How to Draft One (2026)

What is a cloud services agreement, and when do you need one? A cloud services agreement is the contract between a cloud provider and a customer for hosting, infrastructure or software delivered over the internet. It covers infrastructure (IaaS), platform (PaaS) and, most commonly, software (SaaS). It defines what the service is, how available it must be, what happens to the customer's data, how security and privacy are handled, what each side pays and owes, and what happens when the relationship ends. It is usually made up of a main agreement plus a service level agreement (SLA), an acceptable use policy and a data processing addendum. You need one whenever a business runs on, or provides, a cloud service. For the customer, the risks are concentrated in a few places: uptime, data ownership and portability, security, and the ability to get your data out and move on. For the provider, the agreement manages liability, acceptable use and payment. Because cloud is delivered continuously and holds the customer's data, the two hardest questions are "how available will it be, and what do I get if it is not" and "whose data is it, and how do I get it back". This article is general guidance, not legal advice. Cloud contracts engage data protection, consumer and sector-specific rules that vary by jurisdiction, so have a qualified professional review any agreement before you rely on it. ## Cloud services agreement template Copy the block below and fill the bracketed fields. ```

CLOUD SERVICES AGREEMENT This Cloud Services Agreement ("Agreement") is made on [DATE] BETWEEN: [PROVIDER NAME], [address] ("Provider") AND [CUSTOMER NAME], [address] ("Customer") 1. SERVICES The Provider will make the cloud service described in Schedule 1 (the "Service") available to the Customer on the terms below, during the Term. 2. SERVICE LEVELS (SLA) The Provider will meet the availability and support targets in Schedule 2, including a target uptime of [e.g. 99.9%] per month measured as [method]. If the Provider misses a target, the Customer's remedy is [service credits as set out in Schedule 2]. 3. CUSTOMER DATA AND OWNERSHIP As between the parties, the Customer owns all Customer Data. The Provider may use Customer Data only to provide and support the Service and as the Data Processing Addendum (Schedule 3) allows. The Provider claims no ownership of Customer Data. 4. SECURITY AND PRIVACY The Provider will maintain [appropriate technical and organisational security measures, described in Schedule 4] and will process personal data under the Data Processing Addendum. [State any certifications only if actually held and dated.] 5. ACCEPTABLE USE AND SUSPENSION The Customer will not use the Service unlawfully or in breach of the acceptable use policy (Schedule 5). The Provider may suspend the Service for [a serious security risk / non-payment after notice / material AUP breach], giving [notice where practicable] and restoring it promptly once resolved. 6. FEES AND PAYMENT The Customer will pay the fees in Schedule 1. Fees are due within [N] days of invoice. [State whether fees can change, and on what notice, at renewal.] 7. INTELLECTUAL PROPERTY The Provider owns the Service and its software; the Customer gets a non-exclusive right to use it during the Term. Each party keeps its own background IP. 8. WARRANTIES AND LIABILITY The Provider warrants it will provide the Service with reasonable skill and care. To the extent the law allows, liability for indirect or consequential loss is excluded, and each party's total liability is capped at [e.g. the fees paid in the prior 12 months], with [carve-outs for confidentiality, data breach, IP indemnity and amounts that cannot be limited by law]. 9. TERM, TERMINATION AND EXIT This Agreement runs for [Term] and renews [automatically unless notice is given]. Either party may terminate for material breach not cured within [N] days. On termination, the Provider will, for [N] days, let the Customer export Customer Data in [a usable format], then delete it under the DPA. 10. GOVERNING LAW AND DISPUTES This Agreement is governed by the laws of [jurisdiction], with disputes subject to [courts / arbitration seat]. Schedules: 1 Service & fees; 2 SLA; 3 Data Processing Addendum; 4 Security; 5 Acceptable Use Policy. Signed for the Provider: __________ Signed for the Customer: __________

- **Customer data and ownership (clause 3).** The customer should own its data outright, and the provider's rights to use it should be limited to running the service. This is non-negotiable for most customers.
- **Security and privacy (clause 4).** Attach a real security schedule and a data processing addendum. State certifications only if they are genuinely held, with a date; never imply a certification you do not have.
- **Suspension (clause 5).** Providers need the right to suspend for serious risks or non-payment, but customers should insist on notice where practicable and prompt restoration, so suspension is not used as leverage.
- **Liability (clause 8).** Expect a cap (often tied to fees paid) and an exclusion of indirect loss, with carve-outs for things like data breach, confidentiality and IP indemnities. This clause is where real risk is allocated.
- **Exit (clause 9).** The most overlooked clause. Require a defined period after termination to export your data in a usable format before it is deleted, so you are never locked in or cut off. ## Common mistakes to avoid - Accepting an uptime number with no remedy, or credits so small they mean nothing.
- Not securing clear customer ownership of data and a real export right on exit.
- No data processing addendum, so personal data handling is undefined.
- Ignoring the liability cap and its carve-outs, which decide who bears a breach.
- Auto-renewal with a long notice window, so you are locked in by missing a date. ## A note on jurisdiction Cloud contracts engage law that varies by jurisdiction. In India, the agreement is a contract under the Indian Contract Act, 1872; personal data handling increasingly engages the Digital Personal Data Protection Act, 2023 as it comes into force; GST applies to the service; and regulated sectors (for example banking under RBI rules) have extra data-localisation and outsourcing requirements. In the EU and UK, the GDPR governs personal data and often requires Standard Contractual Clauses for transfers; the US has sector and state laws; and Singapore and Australia have their own regimes and, in some sectors, localisation rules. The safe approach is to attach a jurisdiction-appropriate data processing addendum, check sector rules, and say "varies by jurisdiction" rather than assume one answer fits all. Last verified October 2026. ## Where a contract workspace helps A cloud services agreement is where the risk hides in the detail: SLA and uptime remedies, data-ownership and export rights, liability caps, and auto-renewals that lock you in by default across many providers. Drafting, reviewing, tracking and governing a cloud services agreement can live in one AI workspace tuned to how your company buys cloud, with the SLA, data, liability and exit terms flagged in plain language and renewal and notice dates kept as alerts. [Adira](https://adiralaw.com) is one tool built around that single-workspace idea for vendor contracts like a cloud services agreement. This template alone is enough to put a fair cloud services agreement in place.