The 7 Addendums Every Cloud Services Agreement Needs
A Cloud Services Agreement is only the foundation. The addendums are where the real detail lives - data protection, AI governance, service levels, support commitments, and more. Here's what each one does and why it matters.
Why Addendums, Not One Big Contract?
A Cloud Services Agreement (CSA) establishes the core commercial relationship - access rights, fees, restrictions, IP ownership, confidentiality, and termination. But the details of how the service is delivered, protected, and supported need dedicated treatment.
Addendums serve three purposes. They keep the core agreement clean and readable. They allow each subject to be addressed with the depth it requires. And they create a modular structure where addendums can be included, excluded, or customised per deal without rewriting the master terms.
The Cover Page lists which addendums apply. A precedence clause governs conflicts: Special Terms prevail over Addendums, which prevail over the Terms and Conditions. Between addendums, the more specific addendum on the subject matter prevails.
The 7 Addendums
Termination for Convenience
Allows the customer to exit early, with a fair early termination charge.
Aggregated & Anonymised Data
Governs how the provider can use de-identified data for analytics and improvement.
AI Features
Sets rules for AI functionality, inputs/outputs ownership, and responsible use.
Data Protection (DPA)
POPIA-compliant data processing terms between controller and processor.
Service Levels (SLA)
Uptime commitments, service credits, and remedies for chronic failure.
Support
Defines support hours, channels, incident priority levels, and response times.
Professional Services
Governs implementation, consulting, and custom work delivered via Statements of Work.
Termination for Convenience
Gives the customer the right to exit the agreement early - for any reason or no reason - subject to a fair early termination charge.
How It Works
Cloud services agreements are typically fixed-term subscriptions. Without this addendum, the customer is locked in for the full committed term. The TFC addendum creates a structured exit path that balances flexibility for the customer with fair compensation for the provider.
30-day written notice
The customer must give at least 30 days' prior written notice specifying the effective termination date.
Per-order termination
The customer can terminate the entire agreement or specific orders individually - you don't have to exit everything at once.
Accrued fees still owed
Termination for convenience doesn't erase existing obligations. All undisputed fees for services already delivered remain payable.
Early termination charge
Covers the provider's unrecovered onboarding and implementation costs, plus a reasonable estimate of lost profit for the remaining term.
Genuine pre-estimate, not a penalty
The charge is structured as a compensatory pre-estimate of loss - not a contractual penalty - to ensure enforceability under South African law.
The Early Termination Charge
The charge has two components:
1. Unrecovered Costs
Non-recurring costs the provider incurred specifically for this customer (onboarding, third-party licence commitments, infrastructure setup) that were intended to be recovered over the full term, less any portion already recovered through fees paid.
2. Net Lost Profit
Fees that would have been payable for the remaining term, minus variable costs the provider expects to avoid (e.g. usage-based third-party costs tied to the customer's consumption).
SA Legal Context: Penalties vs Pre-Estimates
South African law distinguishes between unenforceable contractual penalties and enforceable pre-estimates of loss. The Conventional Penalties Act allows courts to reduce penalties that are out of proportion to the actual loss. By structuring the charge as a genuine pre-estimate tied to actual unrecovered costs and net lost profit, the addendum ensures enforceability.
Aggregated and Anonymised Data
Governs how the provider may derive, use, and own de-identified data created from customer data - for analytics, benchmarking, and service improvement.
What This Addendum Covers
SaaS providers need to analyse usage patterns, improve their products, and publish benchmarks. This addendum creates the legal framework for doing so - authorising the provider to derive insights from customer data, but only after it has been genuinely anonymised or aggregated so it can never be traced back.
Aggregated Data
Customer data combined with data from other customers in summary form so it cannot reasonably be linked back to the customer or any individual.
Anonymised Data
Customer data that has been de-identified in accordance with POPIA so it cannot be re-identified by any reasonably foreseeable method.
Permitted uses
The provider may use aggregated and anonymised data for operating, improving, and securing its services, training models, and publishing benchmarks - provided the data never identifies the customer.
Anti-re-identification safeguards
The provider must maintain technical and organisational measures to prevent re-identification, and must never attempt to reverse the anonymisation.
Relationship with DPA
Once data is genuinely anonymised or aggregated, it exits the DPA's scope. But the transformation itself must comply with data protection laws.
Provider ownership
The provider owns the aggregated and anonymised data it creates - including any derivatives, insights, models, and analytics derived from it.
POPIA and Anonymisation
Under POPIA, once data has been de-identified such that it can no longer be linked to a specific data subject, it falls outside the scope of the Act. But the de-identification must be genuine - "any reasonably foreseeable method" of re-identification must be prevented. The addendum requires both technical measures and business processes to ensure this threshold is met.
AI Features
Sets the ground rules for AI functionality within the cloud service - ownership of inputs and outputs, training restrictions, responsible use obligations, and disclaimers.
What This Addendum Covers
As AI features become standard in SaaS products, contracts need to address questions that traditional software agreements never contemplated: who owns the output of an AI model? Can the provider train its models on your data? What happens when AI generates incorrect or harmful content?
Input ownership stays with the customer
Prompts, queries, uploads and configuration submitted to AI features remain the customer's data, subject to confidentiality and data protection obligations.
Output ownership stays with the customer
Results generated by AI features belong to the customer. However, similar outputs may be generated for other customers from different inputs.
Human review required
The customer must apply human oversight before relying on any AI output for legal, commercial, compliance, or other material decisions.
Training restrictions
The provider may only use inputs and outputs for AI training after they have been anonymised or aggregated under the A&A Data Addendum.
No accuracy warranty
AI outputs are generated by automated systems and may be inaccurate, incomplete, or unsuitable without review. The provider does not warrant correctness.
Prohibited uses
Customers must not use AI features for automated decisions with legal effects without human review, discriminatory purposes, or to train competing models.
Third-Party AI Providers
Most SaaS providers don't build their own AI models from scratch - they integrate third-party AI infrastructure (OpenAI, Google, Anthropic, etc.). This addendum addresses this reality:
- Third-party AI providers are listed as sub-processors under the DPA
- They must be bound by protections no less stringent than the agreement
- Applicable third-party terms must be shared with the customer in advance
Why AI Governance Matters
Without an AI addendum, it is unclear whether the provider can train its models on your data, who owns the AI-generated content, and what liability exists when AI produces incorrect results. This addendum creates certainty on all three points - protecting both parties as AI becomes increasingly integrated into business operations.
Data Protection (DPA)
The POPIA-compliant data processing agreement that governs how the provider handles personal information as an operator on behalf of the customer.
What This Addendum Covers
POPIA Section 21 requires that when a responsible party (the customer) engages an operator (the provider) to process personal information, there must be a written contract in place. This addendum fulfils that obligation, defining each party's roles, obligations, and the safeguards around protected data.
POPIA-aligned terminology
Uses South African data protection concepts - the customer is the "responsible party" (controller) and the provider is the "operator" (processor).
Controller obligations
The customer must determine lawful bases for processing, maintain consents, ensure data quality, and not submit special personal information without prior agreement.
Processor obligations
The provider must keep data confidential, process it solely as instructed, restrict access to authorised persons, and never sell or use data for its own purposes.
Sub-processor management
The provider must maintain an up-to-date sub-processor list, notify the customer of changes, and ensure sub-processors are bound by equivalent protections.
Data incident notification
The provider must notify the customer without undue delay of any security compromise, with details of the breach, affected data, and remediation steps.
Return and deletion
On termination, the customer chooses: data returned in a machine-readable format, or securely deleted. Either must happen within 30 days.
Cross-border transfers
Any restricted transfer outside South Africa must ensure "adequate protection" - substantially similar safeguards to POPIA, including onward transfer protections.
Categories of Protected Data
A well-drafted DPA specifies the types of personal information that will be processed:
- Names and contact information (email, phone, address)
- Employment and financial information
- Transactional and user activity data
- Location information and device identifiers
Special personal information (health, biometrics, religion, criminal history) and children's data are prohibited unless expressly agreed in writing with additional safeguards.
POPIA Section 72: Cross-Border Transfers
If the provider (or any sub-processor) stores or accesses data from outside South Africa, the DPA must ensure "adequate protection" - meaning the recipient country or entity provides safeguards substantially similar to POPIA, including restrictions on onward transfers. This is particularly relevant for providers using cloud infrastructure hosted by AWS, Azure, or GCP in foreign regions.
Service Levels (SLA)
Defines measurable uptime commitments, service credits for failures, and the customer's remedies when the provider consistently fails to meet targets.
What This Addendum Covers
The SLA transforms uptime promises from marketing claims into contractual commitments with financial consequences. It defines how availability is measured, what counts as downtime, and what happens when the provider falls short.
Target availability (e.g. 99.9%)
The provider commits to a monthly uptime percentage, measured by its monitoring systems. Excluded downtime (maintenance, force majeure, customer misuse) is carved out.
Service credit table
A tiered credit structure: small shortfalls earn modest credits (e.g. 5%), while significant outages earn larger credits (up to 50% of monthly fees).
Claim procedure
Customers must submit a written service credit request within 30 days of the affected month, with details of the suspected outage. The provider verifies against its systems.
Chronic failure termination
If availability falls below target for two consecutive months or three months in any rolling 12-month period, the customer can terminate and receive a refund of prepaid fees.
Exclusive remedy
Service credits and chronic failure termination are the sole remedies for uptime failures - this caps the provider's liability for availability issues.
Service Credit Table
Credits are calculated as a percentage of the monthly fee for the affected service:
Excluded Downtime
Not all unavailability counts against the target. Excluded downtime typically includes planned maintenance, customer misuse, third-party infrastructure failures outside the provider's control, and force majeure events. Understanding these carve-outs is essential to knowing what the SLA actually guarantees.
Support
Defines how the provider handles incidents - support hours, contact channels, priority classifications, and target response times.
What This Addendum Covers
When something goes wrong, the support addendum tells you exactly what to expect - how to report the issue, how it will be classified, and how quickly the provider commits to responding. It sets expectations for both sides and prevents disputes about response obligations.
Support hours
Typically business hours (e.g. 08:30-17:00 SAST, Monday to Friday, excluding public holidays) unless the agreement specifies extended or 24/7 coverage.
Priority levels
P1 (Critical) - system down, no workaround; P2 (High) - severely degraded; P3 (Medium) - non-critical issue with workaround; P4 (Low) - minor issue or feature request.
Target response times
Response time commitments by priority: P1 within 1 business hour, P2 within 1 business day, P3 within 2 business days, P4 within 3-5 business days.
Response vs resolution
Response time is acknowledgement and triage - not full resolution. The addendum sets effort standards, not resolution guarantees.
Customer cooperation
The customer must provide sufficient detail when logging incidents: description, business impact, steps to reproduce, screenshots, and any workarounds discovered.
Priority Levels & Response Times
System down, no workaround
Target response: 1 business hour
Severely degraded, key features affected
Target response: 1 business day
Non-critical issue, workaround available
Target response: 2 business days
Minor issue, cosmetic, or feature request
Target response: 3-5 business days
Response Time vs Resolution Time
A common misunderstanding: the target response time is the time for the provider to acknowledge receipt and begin investigation - not to fully resolve the issue. The addendum sets an effort standard (commercially reasonable efforts) for resolution, not a guaranteed resolution timeframe. Complex issues may require multiple iterations to resolve.
Professional Services
Governs implementation, configuration, consulting, integration, data migration, and other custom work - delivered via individual Statements of Work.
What This Addendum Covers
Cloud services don't always work out of the box. Enterprise customers need implementation support, custom integrations, data migration, and training. This addendum creates the framework for delivering those professional services alongside the subscription - with clear scope control, IP allocation, and acceptance procedures.
Scope via Statements of Work
Each engagement is defined in a SoW covering scope, deliverables, milestones, timetable, customer responsibilities, assumptions, and fees.
Change control
No changes to scope, fees, or timeline without a written Change Order signed by both parties. The provider needn't start changed work until the Change Order is agreed.
Pricing models
SoWs can use time-and-materials (daily/hourly rates with estimated totals) or fixed-price billing. Expenses are reimbursed at cost with pre-approval.
IP allocation
Provider retains IP in deliverables (configurations, integrations, templates, scripts) unless the SoW says otherwise. The customer gets a licence to use deliverables with the cloud services.
Acceptance testing
Deliverables go through a formal acceptance period (default 10 business days). The customer tests against SoW criteria, and can reject with a deficiency notice.
Delay provisions
If the customer causes delays (late materials, missed decisions), the provider can reschedule and charge for additional costs. Accountability runs both ways.
What Goes in a Statement of Work
Each SoW should describe, at minimum:
- Scope of professional services and deliverables
- Project phases, milestones, and timetable
- Customer responsibilities and assumptions
- Fees, expenses, and invoicing schedule
- Any special terms unique to that engagement
IP Ownership: Provider Default
Unless the SoW says otherwise, the provider owns the IP in all deliverables - configurations, integrations, templates, scripts, and reports. The customer receives a licence to use them with the cloud services. This is standard practice because deliverables typically build on the provider's pre-existing tools and know-how. If you need to own specific deliverables, negotiate that in the SoW.
All 7 Addendums at a Glance
A quick reference showing each addendum's purpose and who it primarily protects.
Termination for Convenience
Customer exit flexibility
Customer (exit rights), Provider (cost recovery)
Aggregated & Anonymised Data
Data-derived insights
Provider (data rights), Customer (privacy)
AI Features
AI governance
Both (IP, responsible use, training restrictions)
Data Protection (DPA)
Privacy compliance
Customer (data control), Data subjects (rights)
Service Levels (SLA)
Uptime commitments
Customer (availability guarantees, remedies)
Support
Incident management
Customer (response times), Provider (scope limits)
Professional Services
Implementation & custom work
Both (scope control, IP, acceptance)
The Addendums Work as a System
These addendums don't operate in isolation - they cross-reference and depend on each other.
DPA + A&A Data + AI Features
The DPA governs how personal data is processed. The A&A Data Addendum defines when data exits the DPA's scope (once anonymised). The AI Addendum requires anonymisation under the A&A Addendum before training. They form a data governance chain.
SLA + Support + Professional Services
The SLA defines availability targets. Support defines how incidents are handled when those targets are missed. Professional Services covers the custom work that falls outside both standard cloud operations and standard support scope.
TFC + DPA (Data Return)
The TFC Addendum creates the exit right. The DPA's return and deletion clause governs what happens to the customer's data on exit - ensuring data portability, secure deletion, and a clean break from the relationship.
Related Guides
Continue learning with these related resources.
Ready to Build Your Cloud Services Agreement?
MyContracts helps you assemble professional Cloud Services Agreements with all the right addendums - from data protection and AI governance to service levels and support. One platform for your entire contract suite.