What a SaaS agreement is — and isn’t
Software as a Service is not, technically, software — it is access. A SaaS provider operates the software on its own (or third-party) cloud infrastructure; the customer never possesses an executable copy. This single architectural choice cascades into every part of the legal framework: there is no transfer of a copy, so no question of perpetual ownership; there is continuous service delivery, so contract performance is ongoing rather than instantaneous; there is data flowing into the platform, so personal-information processing is implicated from day one.
South African law treats a SaaS agreement as a hybrid: part service contract, part licence, part data-processing arrangement. The Copyright Act 98 of 1978 still applies to the underlying software (computer programs are protected as literary works under section 2(1)(i)), but the customer’s relationship with the software is mediated entirely through the vendor’s infrastructure. The Consumer Protection Act, where applicable, treats SaaS subscriptions as continuous services subject to the section 14 fixed-term cap and the section 16 cooling-off right. ECTA gives the entire arrangement legal effect (sections 11 to 13, 22), governs the website disclosures the vendor must make to attract consumers (section 43), and creates the cooling-off right that consumers can exercise within seven days (section 44). POPIA imposes the operator-agreement obligation (section 21), the security duty (section 19), the breach-notification regime (section 22), and the cross-border transfer restriction (section 72).
What a SaaS agreement is not: a one-time licence. The distinction matters in disputes. A SaaS customer who pays a final invoice and then stops paying is not entitled to continue using the platform — the access right ended with the subscription. A perpetual software licensee who pays once and stops paying for support is still entitled to use the software, just without the support. This distinction is often misunderstood and produces avoidable litigation when the contractual language is unclear.
The seven structural sections
A complete SaaS agreement has seven sections that do most of the work. Smaller or self-service products may collapse some of these into compact provisions; enterprise deals will have each of these as a full schedule or annexure. The rest of this guide walks through each section in detail.
- 1. Access grant + acceptable use — what the customer can do with the software, what it cannot do, how many users.
- 2. Subscription fees + payment — how much, when, in what currency, with what escalation rules.
- 3. Service level agreement (SLA) — uptime, response times, support tiers, service credits.
- 4. Data ownership + processing — who owns customer data, how the operator handles it, POPIA compliance.
- 5. IP, warranties + indemnities — what the vendor warrants, what it indemnifies for, what survives termination.
- 6. Limitation of liability — caps, exclusions, carve-outs, POPIA penalty treatment.
- 7. Term, renewal + exit — duration, auto-renewal, termination rights, data return, wind-down.
1. Access grant + acceptable use
The access grant defines what the customer is allowed to do. The acceptable-use policy defines what the customer is not allowed to do. Together they bound the commercial relationship at the level of basic permitted activity. A well-drafted access grant addresses: the scope of permitted use (own business operations, by named users or by user count, in defined territories); restrictions on resale, sublicensing, or making the platform available to third parties; specific prohibited uses (reverse engineering, benchmarking for competitive purposes, integration with the vendor’s competitors).
User-based licensing (per-seat) is the dominant pricing model for B2B SaaS. The agreement should define what a "user" is — typically a named natural person whose access credentials are unique and non-shared — and should address what happens when users leave the business (deprovisioning), what counts as concurrent versus named usage, and how the platform’s user-management features enforce these definitions. Usage-based pricing (per transaction, per API call, per GB processed) is increasingly common for infrastructure-style SaaS and creates different metering and dispute questions.
The acceptable-use policy should list specific prohibited activities: hosting illegal content; using the platform to send unsolicited communications in breach of POPIA section 69 or the Direct Marketing Code; using the platform for activities that breach the Cybercrimes Act (data interference, electronic fraud, cyber extortion); using the platform in a way that overloads the infrastructure or interferes with other customers; reverse-engineering or attempting to discover the source code; using the platform to develop a competing product. Acceptable-use breaches should give the vendor termination rights with limited notice; the agreement should specify whether such termination triggers any refund.
2. Subscription fees + payment
The fee section answers four questions: how much, when, in what currency, and with what escalation. For SA-domestic deals, fees are quoted in Rand and exclude VAT (or include it where the customer is a non-VAT-registered consumer). For cross-border deals, fees are quoted in USD, EUR or GBP and the agreement should address: who bears exchange-rate risk between invoice and payment; whether the customer can elect to pay in Rand at a published rate; and the impact of South African exchange control on payment processing (the South African Reserve Bank’s authorised dealer framework applies to most cross-border service payments).
Escalation clauses are commercially important and legally tricky. Vendors prefer wide discretion to increase fees on renewal; customers prefer fixed pricing or, failing that, CPI-linked escalation. Where the customer is a CPA-protected consumer or small business, unilateral fee-escalation rights without notice may be challenged as unfair terms under section 48 of the CPA. A defensible compromise: CPI-linked escalation up to a cap (typically 8 to 10 per cent annually), with material escalations above the cap triggering a customer termination right.
Late-payment clauses should specify: the grace period before late-payment penalties accrue (typically 7 to 14 days after invoice due date); the interest rate on overdue amounts (commonly prime plus 2 per cent, or a fixed rate disclosed up-front); the vendor’s right to suspend service for non-payment and the notice required before suspension; the customer’s right to receive a copy of overdue invoices and to dispute charges within a defined period. For consumers under the CPA, the National Credit Act may also apply where the subscription is structured as an instalment sale or credit agreement — most pure subscription SaaS falls outside the NCA but the analysis should be checked.
3. Service level agreement (SLA)
The SLA translates the vendor’s service promises into measurable, enforceable commitments. A robust SLA addresses uptime (the percentage of time the service is available, measured monthly or quarterly), response times (how quickly the support team acknowledges issues), resolution times (how quickly issues are fixed), and remedies (typically service credits applied against future invoices).
Uptime is usually expressed as a percentage of monthly availability. A 99.9 per cent SLA permits approximately 43 minutes of downtime per month; 99.95 per cent permits 22 minutes; 99.99 per cent permits 4 minutes. The agreement must define how uptime is measured (the vendor’s monitoring or a third-party monitoring service), what counts as downtime (full service unavailability versus partial degradation), what is excluded from uptime calculations (planned maintenance windows, force majeure, customer-caused outages, third-party infrastructure failures outside the vendor’s control), and how disputes about measurement are resolved.
Response and resolution times are usually tiered by severity. A typical four-tier scheme: Severity 1 (full service outage affecting all users) — response within 30 minutes, resolution target 4 hours; Severity 2 (major functionality affected, business operations impaired) — response within 2 hours, resolution target 24 hours; Severity 3 (minor functionality issues) — response within 8 business hours, resolution target 5 business days; Severity 4 (questions, documentation requests) — response within 1 business day, no resolution target.
Service credits are the standard remedy for SLA breach. A typical structure: for each percentage point of uptime below the guaranteed threshold, the customer receives a service credit equal to a defined percentage of the monthly fee. Credits are usually applied against the next invoice rather than paid out in cash, and are capped at a percentage of the monthly fee (commonly 25 to 50 per cent). Customers should also negotiate a "chronic failure" termination right — the ability to exit the agreement without penalty if the vendor breaches the SLA in multiple consecutive months.
4. Data ownership + processing (POPIA)
The data section addresses two distinct questions: who owns the data, and how is the data processed. Ownership concerns the legal entitlement to use and control the data — typically the customer owns all "customer data" uploaded to or generated within the platform, while the vendor owns the software, underlying technology, and any aggregated or anonymised data derived from the platform’s operation. Processing concerns the POPIA-mandated rules for how the vendor handles personal information on the customer’s behalf.
On ownership, the agreement should distinguish: (1) customer data — information uploaded by the customer or generated by the customer’s users on the platform — which the customer owns; (2) service data — metadata about how the customer uses the platform, performance metrics, usage analytics — which the vendor typically owns but the customer may have access to; (3) derived data — aggregated, anonymised, or analytical insights generated by the platform from customer data — which is often contested but increasingly recognised as the vendor’s with restrictions on use against the customer. Anonymisation must be genuine: under POPIA, "anonymised" information is information from which the data subject cannot be re-identified, which is a higher standard than mere pseudonymisation.
On processing, section 21 of POPIA mandates a written operator agreement between the responsible party (the customer) and the operator (the vendor) whenever the operator processes personal information on the responsible party’s behalf. The operator agreement must cover: the scope and purpose of processing; the categories of personal information and data subjects; the security measures the operator will maintain; the operator’s confidentiality obligations; the operator’s obligation to notify the responsible party of security compromises; restrictions on sub-processing; data return or destruction at the end of the engagement; and (where relevant) section 72 cross-border transfer mechanics. The operator agreement is often embedded as a schedule to the master SaaS agreement; sophisticated enterprise customers usually demand a separate Data Processing Agreement that the customer has reviewed and amended.
Cross-border transfers under section 72 require careful drafting where the SaaS infrastructure sits outside South Africa. Lawful bases include: (i) the recipient country has adequate data-protection law (no jurisdiction has yet been formally designated by the Information Regulator); (ii) the recipient is bound by a binding contractual agreement providing protection substantially similar to POPIA (the most common mechanism — most international SaaS providers offer POPIA-aligned Data Processing Addenda); (iii) data-subject consent after disclosure of the risks; (iv) contractual necessity. Customers should not simply trust the vendor’s claim of compliance — the underlying DPA should be reviewed and, where necessary, amended.
5. IP, warranties + indemnities
The IP section confirms that the vendor owns the platform and grants only an access right to the customer. The warranty section is what the vendor stands behind. The indemnity section is who pays when warranties are breached or third parties claim infringement. These three concepts run together and should be drafted as an integrated package.
Standard IP confirmations: the vendor owns the platform, underlying software, technology, documentation, and all improvements made to the platform during the engagement; the customer owns its customer data; any feedback or suggestions provided by the customer to improve the platform are licensed (or assigned) to the vendor on a non-exclusive, perpetual, royalty-free basis. The agreement should be clear about what happens to customer-specific configurations, integrations, and customisations — typically the underlying configuration framework belongs to the vendor, while the specific configuration parameters set by the customer belong to the customer.
Vendor warranties typically include: that the vendor has the right to grant the access granted in the agreement; that the platform will substantially conform to the documentation; that the vendor has not knowingly introduced malware or back-doors; that the platform does not infringe third-party intellectual property rights; that the vendor will maintain appropriate security measures throughout the engagement. Disclaimer clauses then exclude implied warranties (fitness for purpose, merchantability) and warn that the vendor does not guarantee the platform will be error-free or uninterrupted.
Indemnities cover specific risk categories rather than general breach of warranty. The vendor typically indemnifies the customer against: third-party claims that the platform infringes intellectual property rights; third-party claims arising from a security breach caused by the vendor; regulatory penalties imposed on the customer arising from the vendor’s failure to perform its operator obligations under POPIA. The customer typically indemnifies the vendor against: third-party claims arising from the customer’s data or use of the platform; regulatory penalties arising from the customer’s failure to comply with its responsible-party obligations under POPIA. Indemnities are subject to the limitation-of-liability cap unless specifically carved out.
6. Limitation of liability
The limitation of liability clause caps the vendor’s financial exposure if things go wrong. It is the most heavily-negotiated commercial provision in any SaaS agreement, and the answer depends on the size of the deal, the sensitivity of the customer’s data, and the regulatory environment.
Market-standard for B2B SaaS: a cap of 12 months of fees paid by the customer at the time the liability arose. So if the customer paid R200,000 in the preceding year, the vendor’s total cumulative liability is capped at R200,000. The cap typically covers all direct damages — contract damages, negligence damages, breach-of-warranty damages — but excludes indirect, consequential, and special damages (loss of profits, loss of business opportunity, reputational harm).
Carve-outs from the cap are where the real negotiation happens. Standard carve-outs (uncapped or specifically-capped at a higher amount): (i) IP infringement indemnification — vendors take significant risk on third-party IP claims; (ii) confidentiality breach — once data is leaked, the harm can dwarf annual fees; (iii) gross negligence and wilful misconduct — capped damages should not shield egregious behaviour; (iv) fraud; (v) breach of POPIA — increasingly a hard carve-out as the Information Regulator’s enforcement activity has expanded. Sophisticated customers also seek carve-outs for: breach of data-handling obligations specifically, regulatory penalties imposed on the customer arising from the vendor’s breach, and damages flowing from the vendor’s breach of warranties of non-infringement.
For consumer-facing SaaS subject to the CPA, the limitation of liability must navigate section 51, which restricts agreements that purport to limit a supplier’s liability in respect of injury or death, or that limit the supplier’s liability for gross negligence or intentional misconduct. Section 61 imposes strict product liability for goods supplied, which may extend to SaaS products in certain analyses though the question remains open in SA case law. Aggressive limitations against CPA-protected customers face section 48 unfair-term scrutiny.
7. Term, renewal + exit
The lifecycle section addresses how long the agreement runs, how it renews, how it ends, and what happens to data when it does. For business customers, typical initial terms are 12 to 36 months with annual auto-renewal unless cancelled with defined notice. For CPA-protected customers, section 14 caps fixed-term agreements at 24 months and requires 40 to 80 business days’ advance notice of expiry — non-compliance renders the auto-renewal unenforceable.
Termination rights typically include: termination for material breach with a defined cure period (usually 30 days); termination for insolvency, business rescue, or liquidation of either party; termination for sustained failure to meet SLA targets (chronic-failure right); termination on a change of control of either party (often a vendor-favoured right rather than a customer-favoured one); termination for convenience (typically a customer-only right with substantial notice and a fair early-termination fee for multi-year agreements). Termination for convenience clauses are commercially valuable to customers in fast-moving markets where business needs can change before a multi-year SaaS commitment expires.
Data return and destruction on termination is critical. The agreement should provide: a defined post-termination data-retrieval window (typically 30 to 90 days) during which the customer can export its data in standard, machine-readable formats (CSV, JSON, or via API); the vendor’s obligation to permanently and irrecoverably delete all copies of customer data after the retrieval window, including backups, with written confirmation of deletion; treatment of personal information under POPIA section 14 retention rules; data-portability obligations to assist the customer in migrating to a successor platform. Vendors typically resist long retrieval windows and detailed cooperation; customers should treat data portability as a deal-critical issue.
Transition assistance — the vendor’s obligation to actively help the customer migrate to a successor — is typically commercial-negotiated rather than legally-mandated. Best-practice clauses cover: continued service availability for a defined wind-down period (typically 30 to 90 days post-termination); documentation handover (data schemas, API documentation, configuration export); technical-staff availability for migration-related questions; cost of transition assistance (included in subscription fees or charged at agreed hourly rates).
Enterprise add-ons: order forms + DPAs
For enterprise sales, the master SaaS agreement is usually layered with two additional documents: an order form (the per-deal commercial schedule) and a Data Processing Agreement (the POPIA-mandated processing terms). This three-layer structure — master subscription agreement + order form + DPA — is the modern enterprise SaaS standard and produces cleaner negotiations than trying to fit everything into a single document.
The order form sits underneath the master and specifies: the specific products or modules the customer is subscribing to; the number of users or transaction volume; the subscription term; the fees and payment schedule; any deal-specific deviations from the master. Order forms are signed at deal close; the master is signed once at the start of the customer relationship and re-used across multiple deals. This structure makes it easy to add new modules or expand seats without re-negotiating the whole agreement, but requires careful drafting of the order-of-precedence clause (what governs if the master and the order form conflict).
The DPA can be embedded in the master as a schedule or stand alone as a separate document referenced by the master. For SaaS providers selling to multiple enterprise customers, a standalone, well-drafted DPA is more efficient — the customer can review and negotiate the DPA separately, and the same DPA can be re-used across many customers (assuming the underlying processing is materially similar). For more on POPIA DPA content, see our DPA template guide.
Common SA pitfalls
Using foreign-drafted SaaS templates wholesale
US/UK SaaS templates frequently miss POPIA section 21 operator-agreement coverage, mis-state cross-border transfer mechanics under section 72, and impose governing-law and forum clauses that produce friction in SA enforcement. Adapting takes longer than drafting from scratch.
Ignoring the CPA where it applies
Many SA SaaS vendors assume the CPA does not apply because their customers are businesses. But the CPA covers juristic persons below the prescribed threshold (currently asset value or turnover below R2 million). Many small-business customers are CPA-protected.
Unilateral amendment clauses
Clauses allowing the vendor to modify terms unilaterally with mere website posting are vulnerable to section 48 unfair-term challenge for CPA customers, and produce unstable contract relationships even for non-CPA customers. Best practice: advance notice with the customer’s right to terminate for material adverse changes.
Skipping the operator agreement
Section 21 of POPIA is mandatory: no operator agreement, no lawful processing on behalf of the responsible party. Some SaaS vendors quietly omit this hoping customers will not notice; the absence is itself a contravention regardless of whether any breach occurs.
Weak SLAs without enforceable remedies
"Best efforts" uptime targets without quantifiable percentages, response times without resolution times, and service credits without cap-out triggers all produce SLAs that read well but enforce poorly. Quantified targets + service credits + chronic-failure termination rights make an SLA actually useful.
No exit plan
Vendor lock-in is the single largest commercial risk in SaaS. Without data export rights, transition assistance obligations, and post-termination data retention windows, exiting a SaaS relationship becomes practically infeasible even when contractually permitted.
Frequently asked
What makes a SaaS agreement different from a software licence?
A software licence transfers a right to install and use a copy of software — typically perpetual, on-premises, with the customer retaining the installed copy after termination. A SaaS agreement grants a right to access hosted software for the duration of a subscription, with no installed copy and no ongoing access after termination. Under SA law, the difference matters for several reasons: ECTA section 22 governs SaaS contract formation; the Consumer Protection Act applies more directly to subscription services; POPIA section 21 operator obligations attach to SaaS providers; section 72 cross-border transfer rules apply when the SaaS provider hosts data outside SA.
Who is the "operator" and who is the "responsible party" in a SaaS arrangement under POPIA?
The customer (the subscribing business) is almost always the responsible party in relation to the personal information of its own customers, employees, and other data subjects whose data it uploads to or generates within the SaaS platform. The SaaS provider is the operator processing that data on the customer's behalf, under the customer's instructions. The SaaS provider may simultaneously be a responsible party in relation to its own customers (the businesses subscribing to its service) — this dual role is common and requires careful contractual treatment.
What is the typical liability cap structure in a SA SaaS agreement?
Market-standard for B2B SaaS: a cap of 12 months of fees paid by the customer (i.e. the annual subscription value), with carve-outs for: confidentiality breach, infringement of third-party IP, gross negligence, wilful misconduct, fraud, and (increasingly) POPIA penalties imposed by the Information Regulator. Higher caps (24 months, 2x annual fees, or uncapped for specific risks) are negotiated for enterprise customers, regulated industries, or where the SaaS handles particularly sensitive data. Sub-12-month caps are aggressive and increasingly resisted by buyers.
Are click-wrap SaaS agreements enforceable against business customers in South Africa?
Yes — ECTA section 22 confirms electronic agreement formation; section 13 confirms electronic signatures. But the more important practical question is whether the customer's acceptance was informed and intentional. Click-wrap acceptance with terms made readily available (linked in a checkbox, not buried) and meaningful affirmative action (a clicked checkbox or "I agree" button, not browse-wrap) is generally enforceable. Browse-wrap terms (where continued use implies acceptance) are weaker and may fail unfair-term scrutiny under section 48 of the CPA where the customer is also a consumer or small business.
How long should a SA SaaS agreement run, and what auto-renewal rules apply?
Typical B2B initial terms: 12 to 36 months, with annual auto-renewal unless cancelled. For customers who qualify as consumers under the CPA (natural persons, and juristic persons below the asset / turnover threshold), section 14 of the CPA caps fixed-term agreements at 24 months and requires 40 to 80 business days' advance notice of expiry. Auto-renewal clauses that do not comply with section 14 are unenforceable against CPA-protected customers. For pure B2B-enterprise contracts above the threshold, longer terms are permissible but increasingly resisted by sophisticated buyers.
Can a SaaS provider use customer data to train AI models?
Only with explicit contractual permission. The default position under POPIA: data processed by an operator (the SaaS provider) may only be used for the purposes the responsible party (the customer) has authorised. Using customer data for AI model training is a separate processing purpose and requires either: (i) the customer's explicit instruction or consent, or (ii) effective anonymisation that removes the data from POPIA's scope. Many SaaS providers attempt to slip training-rights into their default T&Cs — review carefully and negotiate carve-outs where the customer's data is sensitive or commercially valuable.
What happens to customer data if the SaaS provider goes insolvent?
Without contractual protection: nothing good. The data may be sold as part of the insolvent estate, deleted as part of wind-down, or held in limbo while creditors are resolved. Contractual protections to negotiate: a perpetual right to data export in standard formats; a data-trustee arrangement with an independent third party who holds keys/credentials in escrow; provisions requiring the SaaS provider to maintain operational continuity for a defined wind-down period; and (for mission-critical platforms) source-code escrow allowing the customer to operate the platform itself if necessary.
How does South African exchange control affect cross-border SaaS payments?
SA customers paying foreign SaaS providers in USD, EUR or GBP transact via the Reserve Bank's exchange-control framework. Routine SaaS subscriptions of moderate value are processed automatically by authorised dealers (commercial banks). Larger annual commitments, especially those involving prepayment or material capital commitments, may require Reserve Bank authorisation. Tax characterisation matters too — under section 35 of the Income Tax Act, payments to foreign service providers may attract withholding tax depending on whether they are characterised as royalties, services, or licence fees.
What governing law should an SA SaaS agreement use?
For SA-domestic SaaS (SA provider, SA customer): South African law, with the High Court of South Africa as the forum. For SA-customer / foreign-provider: push for South African law and SA arbitration (AFSA) where possible; failing that, neutral arbitration under a recognised body (ICC, LCIA) is preferable to foreign-court jurisdiction. For SA-provider selling to foreign customers: the provider's preference is South African law, but commercial reality often forces compromise. Whatever the choice, governing law and dispute-resolution forum should be consistent — mismatched choices produce procedural friction.
How often should SaaS terms be updated?
Annual review is good practice. Trigger an immediate review when: POPIA, ECTA, CPA, or Cybercrimes Act amendments take effect; the Information Regulator issues new guidance materially affecting operator obligations; the SaaS product's functionality changes (new modules, new data flows, new sub-processors); the customer base shifts (entering regulated industries, going cross-border, adding consumer-facing channels); or pricing structure changes. Auto-renewal clauses providing for unilateral term changes are vulnerable to CPA section 48 challenge — material amendments should be notified with adequate advance notice.
Need a SaaS agreement drafted or reviewed?
We draft bespoke SaaS contract stacks (MSA + SLA + DPA + T&Cs + privacy) under SA law, and review SaaS agreements being signed by SA businesses with foreign vendors. From R12,000 for a single bespoke document, R25,000–R35,000 for a complete stack.