The first time a software as a service (SaaS) agreement crosses your desk, you are usually on one of two sides of it. Either you have built a product, you are putting it on a subscription model, and a customer has asked for your terms, or you run a business that has just signed up for cloud software and the provider has sent through a thirty-page document to approve. Both positions have the same problem: the document is dense, and the parts that will actually matter in two years are not the parts that look important today.
A SaaS agreement is the contract that governs software delivered over the internet on a subscription basis. The software is centrally hosted and accessed through a browser or an app rather than installed on the customer's machine. It is a licence, not a sale: the customer never owns the software, only the right to use it while the subscription runs. The agreement usually sits alongside a privacy policy and sometimes a separate data processing agreement, and it replaces the older style of perpetual software licence where the customer paid once and ran the software on its own servers.
The clauses that define the deal
What the software actually does
The scope clause is where disputes start. It should describe, in enough detail to be enforceable, what functionality the customer is paying for: the modules and features included, any caps on usage, and what is deliberately excluded. The drafting choice that matters most here is deciding whether the contract references your marketing materials. If the agreement says the service is provided "as described on our website", every claim on that page becomes part of the bargain. Most providers instead include a clause stating that the agreement prevails over marketing materials, so a feature mentioned in a sales deck does not become a contractual promise. The scope clause should also deal expressly with:
- Exclusions: list what the service does not include, such as data migration, training, or integration work.
- Third-party elements: state where the service relies on platforms you do not control, such as cloud hosting or payment processing.
- Custom work: if the customer wants tailored features, push that into a separate statement of work or customisation agreement with its own deliverables, timeframe and costs, rather than stretching the main agreement.
Who gets to use it and how
The access clause sets out who can log in, how they are authenticated, and from where. The usual model is named users or seats, where each licence is tied to a specific person, with a defined process for adding and removing users. Decide whether users need an account, whether the service is bought per seat or as a one-off purchase, and which devices or platforms are supported.
The variant customers push for is unlimited users at a fixed price. It sounds like a simple accommodation, but it removes your ability to price by usage and invites password sharing. The trap that causes downstream problems is failing to define who counts as a user, which produces the classic dispute about whether a contractor or a second device needs a licence. If you plan to geo-block the service, the banned locations should be listed, and the clause should say what happens when a user tries to access the service from one of them.
What the customer can and can't do
The acceptable use clause sets out the obligations the customer accepts and the activities that are prohibited. Typical prohibitions include:
- reverse engineering, decompiling or tampering with the software;
- reselling, sublicensing or sharing access outside the licensed users;
- using the service for unlawful purposes or to store unlawful content;
- scraping or extracting data beyond what the service is designed to produce; and
- attempting to breach security, or probing the service beyond normal use.
The customer should also warrant that the information it provides is true and accurate, and that it will notify the provider of security incidents involving its accounts. The drafting trap here is overreach. An acceptable use clause that prohibits criticism of the product, or that gives the provider an unlimited right to suspend accounts, can be struck down under the unfair contract terms rules discussed below. The licence itself should be described as non-exclusive and revocable when the subscription ends, so there is no suggestion that the customer acquired a permanent right.
What it costs and how you get paid
The payment clause covers the subscription fee, the billing cycle, and what happens if payment fails. The important drafting choices are around renewal and variation:
- Auto-renewal: state whether the subscription renews automatically, how much notice the customer gets before renewal, and how either party cancels.
- Failed payments: set out the notification method and a cure period before access is suspended, so a genuine billing error does not immediately cut off the customer's operations.
- Fee increases: specify how much notice you must give before raising the price. A clause that allows the provider to vary fees without notice is a known unfair contract terms concern.
- Refunds: deal with when refunds are available, such as a defect in the service or cancellation within a cooling-off arrangement, and when they are not.
If the customer has multiple licensed users, the clause should confirm that one subscription covers all of them, so they do not have to re-subscribe individually.
Data, privacy and intellectual property
What happens to the data
For most SaaS products, the customer's data is the substance of the deal: their records, documents, client lists and employee details sit on your servers. The agreement should allocate responsibility for that data clearly. If your business is covered by the Privacy Act 1988 (Cth) (the Act), you must comply with the Australian Privacy Principles in handling it. Most businesses with an annual turnover above $3 million are covered; smaller businesses are generally exempt under s 6D of the Act, though there are exceptions and the exemption is slated for removal in future reform.
The Notifiable Data Breaches scheme in Part IIIC of the Act also matters here. If you become aware of an eligible data breach, you must notify the Office of the Australian Information Commissioner and affected individuals as soon as practicable (s 26WL), and a suspected breach must be assessed within 30 days (s 26WH). A SaaS agreement should make clear who carries those obligations: the provider for the system itself, and the customer for data the customer puts into the system. The agreement should also address:
- Customer warranties: the customer warrants it has the consents and authorisations needed to upload its employees' and clients' information.
- Security commitments: keep these tied to what you actually do. Promising encryption, backups and access controls you do not implement creates liability and can amount to misleading conduct.
- Confidentiality: both parties' confidential information should be protected, with the usual carve-outs for disclosure required by law.
- Data location: state where data is stored, because a customer may have its own reasons (including tax or client requirements) for objecting to offshore hosting.
Who owns what
The intellectual property clause is the heart of the licensing arrangement. Computer programs are protected as literary works under the Copyright Act 1968 (Cth), so the provider owns the copyright in the software and grants the customer a limited, non-exclusive licence to use it for the subscription term. The clause should also deal with the reverse direction: the customer owns its own data and content, and grants the provider a licence back to host and process that content in order to run the service.
Two drafting choices deserve attention. First, decide what happens to feedback and feature suggestions the customer sends you. A clause that assigns ownership of all feedback to the provider is common, but it can read as one-sided if it is buried. Second, decide whether the provider may use aggregated, de-identified usage data to improve the product. If so, say so, and make clear that individual customer data is not part of that use.
Keeping the service running and ending it cleanly
Updates, downtime and support
Software changes constantly, and the agreement needs to say how. The provider should have the right to update the service, with notice of changes that are material, and the customer should accept that continued use of the service after an update means acceptance of the updated terms. Where the provider's terms change with each release, the agreement should make clear which version of the terms applies.
The availability and support clause is where promises become remedies. If you commit to a monthly uptime percentage, the clause should also say what the customer gets if you miss it, typically a service credit against the next invoice. Without that, the uptime figure is a statement of intent rather than a commitment. The clause should record support channels, response times, and how maintenance windows are communicated.
How long it runs and how it ends
The term and termination clause covers the subscription period, renewal, and the grounds on which either party can end the agreement. Common grounds include material breach that is not remedied, insolvency of either party, and the provider being unable to supply the service due to circumstances beyond its control, which is where a force majeure clause lives. Consider also whether either party can terminate for convenience on notice, and how long that notice must be.
The part that is most often skimmed is what happens to the customer's data on exit. The agreement should provide for the customer to export its data in a usable format during and after the term, a defined period after termination during which the provider will assist with transition, and deletion of the data once that period ends. A provider that keeps customer data after termination without a contractual right to do so exposes itself to a privacy complaint, and a customer that has not negotiated data export rights can find its entire business records locked inside a product it no longer uses.
Who carries the risk
Liability caps, guarantees and disclaimers
The liability clause determines what each party can recover when something goes wrong. Australian consumer law constrains how far a provider can push risk onto the customer. Where services are supplied to a consumer, the Australian Consumer Law (the ACL, which is Sch 2 to the Competition and Consumer Act 2010 (Cth)) implies guarantees that the services will be supplied with due care and skill (s 60) and will be reasonably fit for any purpose the customer made known (s 61). A person acquires services as a consumer where the price is no more than $100,000 or the services are of a kind ordinarily acquired for personal, domestic or household use (s 3). Many business-to-business SaaS deals sit outside that definition, but low-cost subscriptions and consumer-facing products do not.
Two sections matter most when drafting the exclusions. Under s 64 of the ACL, a term that purports to exclude the consumer guarantees is void, so a blanket "no liability whatsoever" clause will not survive. Under s 64A, for services not ordinarily acquired for personal, domestic or household use, the provider's liability for a failure to comply with a guarantee can be limited to supplying the services again or paying the cost of having them supplied again, provided it is fair and reasonable to rely on the term. That is the standard shape of a compliant limitation of liability clause: cap total liability at the fees paid over a defined period, carve out the guarantees you cannot exclude, and keep the rest.
The other constraint is the unfair contract terms regime. A term of a standard form consumer or small business contract is void if it is unfair (s 23 of the ACL), and since the reforms that took effect on 9 November 2023, proposing or relying on an unfair term is itself a contravention attracting substantial penalties. A term is unfair if it causes a significant imbalance in the parties' rights, is not reasonably necessary to protect the legitimate interests of the advantaged party, and would cause detriment (s 24). A small business contract is one where a party has fewer than 100 employees or turnover below $10 million (s 23(4)), which captures most Australian SaaS customers, and a contract is presumed to be a standard form contract unless proved otherwise (s 27). One-sided indemnities, unilateral suspension rights and automatic renewal without notice are the clauses most likely to be challenged.
The rest of the risk section should cover:
- Indemnities: the customer indemnifies the provider for misuse of the service, breach of the agreement, or claims arising from data the customer uploaded.
- Disclaimers: the provider disclaims responsibility for outcomes the service cannot control, such as operating system incompatibility or third-party integrations.
- Insurance: the provider should state what insurance it holds, so the customer can see the risk is backed by something.
- Survival: terms that must continue after termination, such as confidentiality, indemnities and the liability cap.
How disputes get resolved
The dispute resolution clause should set out a progression: negotiation between senior representatives, then mediation with an impartial third party, and litigation only as a last resort. It should also nominate the governing law and the courts that will hear disputes. An Australian provider contracting with Australian customers should generally choose an Australian state's law and courts, and should resist a counterparty's push for a foreign forum, which turns any dispute into a costly jurisdictional fight before the merits are even reached.
Clauses worth adding when the deal calls for it
Most SaaS agreements work with the clauses above, but several additions become important in particular deals:
- Source code escrow: worth including when the customer's business continuity depends on the software and the provider is a small company, so the customer can access the source code if the provider fails.
- Data processing agreement: worth adding when the customer processes personal information of its own clients or employees inside the software, which makes the provider a processor under the Privacy Act 1988 (Cth).
- Statement of work: needed whenever the deal includes bespoke development, so the custom work has its own scope, milestones and pricing instead of being absorbed into the subscription.
- White-labelling or reseller terms: needed when another business will sell the software under its own brand, which requires separate branding, support and liability arrangements.
- Audit and compliance rights: relevant for customers in regulated industries such as financial services or health, who will ask to verify your security controls.
When to bring in a lawyer
A SaaS agreement is one of those documents where a lawyer's review pays for itself quickly, because the expensive mistakes are not visible in the draft. An Artificer Legal practitioner reviewing your agreement would start with the three clauses that decide most outcomes: the scope of the service, the liability and guarantee provisions, and what happens to data on termination. We would push back on terms that breach s 64 of the ACL or expose you to the unfair contract terms regime, such as blanket exclusions of liability, unlimited indemnities, unilateral price variation, and silent auto-renewal. We would insist on a data export and deletion pathway in every agreement we draft, because that is the clause that protects your customers' business records and your own privacy position. And we would negotiate in a sensible order: the commercial terms first, then the risk allocation, then the boilerplate, so that the discussion about who carries liability happens while there is still commercial goodwill to resolve it.
Drafting for the day the relationship ends
Every SaaS agreement is drafted for the day it is signed and enforced on the day it ends. The clause that most often separates an agreement that works from one that does not is the exit clause: what happens to the customer's data, on what timeline, and with what assistance, once the subscription stops. Providers skip it because it sounds like planning for failure, and customers skip it because they assume it will never matter. But the party that controls the data controls the commercial relationship, and the provider that has drafted a clean exit pathway has removed the most common reason a customer refuses to leave or a dispute starts.
A well-drafted SaaS agreement defines the service precisely, licences it on clear terms, allocates the risk in a way the ACL permits, and above all sets out what happens to the data when the relationship ends. The consumer guarantees in ss 60 and 61 of the ACL, the limits in ss 64 and 64A, and the unfair contract terms regime in s 23 all constrain how far a provider can push risk onto a customer, and getting those boundaries wrong can void the very clauses you rely on. If you are drafting or reviewing one, work through the clauses in the order they will bite: scope, access, acceptable use, payment, data, intellectual property, updates and support, termination, liability and dispute resolution, and make sure the exit is drafted before you sign.