Software as a service agreements and the clauses that decide the deal

The document in front of you

Whether you are about to subscribe to a cloud product or you are the provider putting your own terms in front of customers, a software as a service agreement (SaaS agreement) is the document that governs the deal. It often arrives as a click-through screen during sign-up, or as a long PDF attached to an email in a negotiated sale, and it is rarely read as carefully as it deserves.

A SaaS agreement grants a licence to access software hosted by the provider, rather than a transfer of the software itself. It sets out how long the subscription runs, what it costs, what happens when the service is down, how data is handled, who owns the intellectual property, and who is liable if something goes wrong. In a negotiated enterprise deal it operates as a master agreement that sits above service schedules and statements of work, and it will usually state that it prevails over the provider's website terms and privacy policy where the two conflict.

The clauses that decide how the deal runs

The clauses below appear in almost every SaaS agreement in one form or another. Each one is a point where the interests of the provider and the customer genuinely diverge, which is why they are the ones worth reading closely before anyone signs.

What you are actually getting

The core of the agreement is the definition of the service: which plan, which features, which functionality, and what the customer is entitled to expect. The drafting choice that matters most is specificity. A service defined by reference to a written specification or feature schedule gives any dispute an objective reference point, while a service described only as "the software" invites argument about what was promised.

Marketing materials: the provider will usually say that the website and sales materials do not form part of the contract, so promises made during the sales process can evaporate unless they are written into the agreement.
"As available" language: providers often hedge every promise about functionality; the customer should push for a defined specification instead.
Acceptance criteria: where the deal involves customisation or integration, the agreement should say when the service counts as delivered and what happens if it does not meet the specification.

How long it runs and how it renews

SaaS subscriptions are typically month to month or fixed term, with fees payable monthly or annually in advance or arrears, and the service suspended if the customer does not pay. Enterprise deals are usually annual with a minimum term, while consumer and small business subscriptions tend to be month to month with the flexibility to scale usage and plans up and down.

Automatic renewal: the agreement may renew automatically unless the customer gives notice, often 30 days before the end of the term. Providers rely on this for recurring revenue; customers should diarise the notice window.
Suspension for non-payment: providers want the right to suspend access promptly for unpaid fees. Customers should ask for notice before suspension and a commitment that data will not be deleted while an account is suspended.
Minimum terms and exit fees: enterprise deals may lock the customer in for a year or more. The term matters less than the path out of the agreement, which comes back to the data clause below.

What it costs and who can change the price

Fees may be flat, tiered, per user, or based on data volumes, and many agreements let the customer scale usage up and down. The clause to watch is the one that lets the provider change the price, or the terms generally, on notice.

Price variation clauses in standard form contracts are a live concern under the unfair contract terms regime. Under s 23 of schedule 2 of the Competition and Consumer Act 2010 (Cth) (the ACL), a term of a standard form consumer or small business contract is void if it is unfair, and since the 2022 amendments the regulator can seek pecuniary penalties for proposing or relying on an unfair term. The upfront price itself is exempt from review under s 26, but a clause allowing the provider to change it later without giving the customer a genuine way out can be unfair.

Unilateral variation: a term allowing price or feature changes on short notice, with no real option to exit without penalty, is the classic target of the regime.
Per-seat counting: disputes regularly turn on how "users" are counted and whether inactive accounts still count towards the bill.
Overage charges: the agreement should say what happens when usage exceeds the plan, whether the customer is billed extra or the service is throttled.

What happens when the service is down

Customers want assurance that the service will be available, usually expressed as an availability percentage such as 99%. The service level agreement (SLA) should say how availability is measured, what scheduled maintenance is excluded from the calculation, and what the customer receives if the target is missed, typically a service credit.

Credit formula: the credit is usually a percentage of the monthly fee, capped at that fee. The provider will want the credit to be the sole and exclusive remedy for downtime, so the level of the credit matters.
Sole remedy: if the credits are the only remedy, the customer cannot terminate or claim other losses for a failure to meet the SLA, which is exactly why providers push for the wording.
Response versus rectification: providers often promise a response time rather than a time to actually fix the problem; customers should push for both.

What happens to your data

The customer's data belongs to the customer. The agreement gives the provider a licence to use it to run the service, and the customer usually warrants that it has the right to supply the data and that the data will not infringe third party rights or breach any laws. Providers also commonly require the customer to warrant the integrity of the data it uploads, so that poor data does not become the provider's problem.

Where the data includes personal information, the Privacy Act 1988 (Cth) applies to APP entities. APP 11 requires an entity holding personal information to take reasonable steps to protect it from misuse, interference, loss and unauthorised access, including technical and organisational measures. If there is an eligible data breach, the notifiable data breaches scheme in Part IIIC of the Act requires the entity to notify affected individuals and the Office of the Australian Information Commissioner.

Data on exit: the most neglected clause is what happens to the data when the agreement ends: the timeframe for export, the format, and the provider's obligation to delete remaining copies.
Security commitments: beyond the statutory baseline, customers handling sensitive information should ask for express security obligations and breach notification commitments.
Data integrity: the agreement should allocate the risk if bad input data produces bad results, which providers will want placed on the customer.

Where your data goes

Customers increasingly ask where data is hosted and by whom, and providers handling health information often host in Australia. The hosting location is worth agreeing expressly, because regulated health records can carry their own storage requirements.

If personal information is disclosed to a recipient outside Australia, APP 8 requires the provider to take reasonable steps to ensure the recipient does not breach the Australian Privacy Principles in relation to the information, and the provider can be accountable for what the overseas recipient does with it. A provider that uses offshore infrastructure, sub-processors or support teams should be able to show how it meets that requirement.

Who owns the software and the customisations

The provider owns the software and the customer gets a licence to use it. The point of divergence is customisation: code written for one customer can often be reused for others.

Under the Copyright Act 1968 (Cth), the author of a work owns the copyright, subject to any agreement to the contrary. Works created by employees in the course of employment vest in the employer, but there is no automatic vesting for work created by contractors or consultants. Who owns a customisation therefore depends on who wrote it and what the agreement says, which makes the clause worth checking rather than assuming.

Licence rather than assignment: the usual compromise is a licence to the customer covering its use of the customised service, while the provider keeps ownership and the ability to reuse the code for other customers.
Reuse rights: if the customer has paid for something bespoke, it should check how broadly the provider can reuse it and whether any confidential elements are protected.
Contractor code: where third party developers are involved, the agreement should ensure their rights are assigned to the right party, otherwise the default ownership rules apply.

What the provider is liable for

Every SaaS agreement limits the provider's liability, usually to the fees paid, and excludes indirect, special and consequential losses, loss of profits, and loss of data. These clauses do important work, but in Australia they operate inside a statutory regime that limits how far they can go.

If the customer is a consumer, the ACL implies guarantees that services will be rendered with due care and skill and be reasonably fit for the purpose disclosed to the supplier. Section 64 of the ACL voids any term that purports to exclude, restrict or modify those guarantees. For services other than those ordinarily acquired for personal, domestic or household use, s 64A lets a supplier limit its liability for a failure to comply with a guarantee to re-supplying the services or paying the cost of having them supplied again. A liability cap and an exclusion clause drafted without regard to those provisions are partly or wholly void.

The unfair contract terms regime also applies to standard form contracts with consumers and small businesses, defined as a business with fewer than 100 employees or turnover under $10 million. Australian courts have struck down liability and exclusion terms in standard form service contracts, including in ACCC v JJ Richards & Sons Pty Ltd [2017] FCA 1224 and ACCC v Fuji Xerox Australia Pty Ltd [2021] FCA 153. The drafting choice that matters is to make the cap proportionate to the deal, express the exclusions clearly, and carve out the guarantees rather than pretending they do not apply.

Clauses worth asking for, or resisting

Depending on the deal, a handful of additional clauses are worth raising even though they do not always appear:

IP infringement indemnity: worth asking for when the customer wants protection if the software infringes a third party's rights, and worth scoping carefully when you are the provider.
Security and audit rights: worth including when the customer handles sensitive or regulated data and needs to verify the provider's security, with certifications such as SOC 2 or ISO 27001 as a lighter alternative.
Change control for customisations: worth including whenever bespoke development is involved, so that scope changes are priced and documented rather than absorbed.
Data export and transition assistance: worth asking for when the customer cannot afford to be locked in, with an agreed format and timeframe for getting data back.
Survival clauses: worth checking so that confidentiality, indemnities and licences that need to outlast the agreement actually do.

How an Artificer Legal practitioner would review it

A lawyer's review of a SaaS agreement usually starts with the definition of the service and works outwards, because every other clause hangs off what was promised. We would then check the price variation and liability clauses against the unfair contract terms regime and the consumer guarantees, and insist that the data clause deal expressly with export and deletion on exit rather than leaving it to chance.

Order matters. We would negotiate the scope of the service and the data handling first, because they determine value and risk, then the term and the fees, then the SLA and the liability cap, making sure the cap tracks the fees actually paid in the period of the loss rather than a lifetime figure. If you are the provider, we would make sure the exclusion and limitation clauses are drafted to sit inside s 64A of the ACL rather than as a blanket exclusion that s 64 renders void, and that the unfair contract terms exposure in your standard form terms is addressed before the regulator comes looking.

The clause that decides most SaaS disputes

If a SaaS agreement ends up in a dispute, the fight is usually over the liability clause: the cap, the exclusions, and what is carved out of them. That is where a provider's template most often fails, by purporting to exclude consumer guarantees that s 64 of the ACL voids, and where a customer most often fails, by relying on a cap that the unfair contract terms regime strikes down. Drafting that clause to sit inside the Australian statutory framework, rather than pretending the framework does not exist, is the choice that separates an agreement that works from one that collapses when something goes wrong.

The rest follows from the same discipline: define the service precisely, agree how long the subscription runs and what it costs, put a real SLA behind the availability promise, and decide in writing what happens to the data, the hosting and the customisations when the deal ends. A SaaS agreement that answers those questions in plain language is one your business can rely on.