Website terms and privacy policy clauses every Australian business should review

You have a developer link in front of you, a footer with two empty placeholders, and a template a previous founder dropped into the site three years ago. The terms reference a company you no longer trade as. The privacy policy promises behaviours your business does not actually perform. You want to know what these documents should say, not in the abstract, but in the form a competent reviewer would mark up before they let it go live.

A website's terms of use is a unilateral contract between you (the operator) and any visitor who uses the site — formed by their continued use after notice. It governs access, content reuse, and acceptable conduct, and it sits alongside (not in place of) your sale contracts, supply terms, or membership terms. A privacy policy is a separate, statutorily-required document for any entity caught by the Privacy Act, describing how the entity manages personal information across its whole operation — not just the website. Drafted together because they live in the same footer, but they do different work and have different consequences when they fail.

Acceptance and scope (website terms)

The first clause sets how a visitor becomes bound. A browse-wrap model — "by using this website you agree to these terms" — is standard for a content site. If your site does anything transactional (account creation, checkout, paid downloads), upgrade to click-wrap at the relevant gate: a tick-box beside a link to the terms, captured server-side with timestamp and IP. Courts treat acceptance as a question of notice and assent; a footer link alone is weaker evidence than a checkbox at sign-up.

Scope should name the URL or domain the terms govern, and exclude anything operating under separate terms (your SaaS product T&Cs, supplier agreements, membership terms). Otherwise a customer reading an inconsistency between your website terms and your subscription contract will argue the more favourable one wins.

Drafting minimums:

• Identify the operating entity by ACN, not just trading name.
• State the version date and reserve a right to amend with notice (a banner, an email to account holders, or a noted "last updated" date).
• Make clear which terms govern transactions and which govern browsing.

Disclaimer of accuracy and limitation of liability

This is the clause the source article rightly treats as central, and the one where templates most commonly overreach. You can disclaim accuracy of general content (blog posts, calculators, guides) and tell visitors they use the site at their own risk. You cannot, by contract, exclude the consumer guarantees that apply when you supply goods or services to a consumer — the Australian Consumer Law guarantees apply automatically and cannot be excluded, restricted or modified by your terms.

The drafting move is to limit, not exclude. State that to the extent permitted by law, liability for loss arising from use of the site is excluded; and where law prevents exclusion, liability is limited (commonly, to resupply of the service or the cost of resupply, for services other than goods of a kind ordinarily acquired for personal use). A flat "we are not liable for anything" clause is unenforceable against a consumer and arguably misleading conduct if held out as binding.

Traps:

• Excluding liability for personal injury caused by negligence — void under most state laws.
• Disclaiming "all warranties express or implied" without the ACL carve-out — invites a misleading-representations complaint.
• Forgetting that B2B supplies under $100,000 are also consumer supplies under the ACL.

Intellectual property and licence to users

State that you (or your licensors) own the site's content, trade marks, and code. Grant the user a narrow, personal, non-commercial licence to view and download for their own use. Prohibit reproduction, framing, scraping, and use of content to train any model without written consent — this last carve-out is worth adding given how content is now being ingested into AI training corpora.

If you accept user-generated content (comments, reviews, uploads), you need a reverse licence from the user to you: a perpetual, royalty-free, sublicensable licence to host, display, and modify the content for the operation and promotion of the site. Without it you cannot lawfully republish a customer review as a testimonial. A useful sub-list of things to include:

• A list of trade marks claimed (with TM or registered symbols correctly applied).
• A takedown contact for infringement notices.
• An express prohibition on automated scraping and on use of content as model training data.

Acceptable use

A short, plain list of what visitors must not do: unlawful conduct, uploading malware, harvesting personal information of other users, attempting to defeat security controls, framing the site, or impersonating another person. Keep it specific enough that you could point to a breach and enforce a ban; avoid the catch-all "anything we consider inappropriate", which courts read narrowly against the drafter.

Third-party links and affiliate disclosure

External links should be disclaimed — you do not endorse and cannot control linked sites. If you earn commissions on outbound links, you must disclose the commercial relationship clearly enough that a reasonable visitor would understand it before clicking. A buried line in the terms is not enough; the disclosure usually sits beside the link itself, with the terms providing the general statement.

Governing law and jurisdiction

Pick a single Australian jurisdiction (commonly the state of the operating entity's registered office) and submit to its courts. Avoid arbitration clauses on a consumer-facing site — they are often unenforceable against consumers and add cost when you actually need to enforce.

Privacy policy: who must have one

A privacy policy is mandatory for any APP entity. You are an APP entity if you are a body corporate or other organisation that is not a small business operator, or if you fall into one of the categories that lose the small business exemption regardless of turnover. Under section 6D of the Privacy Act 1988 (Cth), a small business operator is an entity with an annual turnover of $3 million or less in the previous financial year. The exemption is lost — and a privacy policy required — where the business:

• provides a health service and holds health information;
• discloses personal information about an individual to anyone else for a benefit, service or advantage (trading in personal information);
• is a contracted service provider for a Commonwealth contract; or
• is related to a body corporate that is itself an APP entity.

Privacy law reform is in progress and the small-business exemption has been flagged for review at the policy level; a business sitting close to or below the threshold should expect the obligations to broaden rather than narrow over the next legislative cycle. Even where not yet compulsory, voluntarily complying signals good handling to customers and reduces remediation cost if the threshold drops.

Privacy policy: required contents

APP 1.4 sets the mandatory contents. A compliant policy must include:

• the kinds of personal information collected and held;
• how the entity collects and holds that information;
• the purposes for which the entity collects, holds, uses, and discloses it;
• how an individual may access their personal information and seek correction;
• how an individual may complain about a breach of the APPs, and how the entity will handle the complaint; and
• whether the entity is likely to disclose personal information to overseas recipients, and (if practicable) the countries those recipients are in.

The drafting choice that matters most here is specificity. APP 1.3 requires the policy to be "clearly expressed and up-to-date". A generic template that lists every conceivable collection method ("we may collect information through cookies, forms, telephone, in person, third parties...") fails this test if half of those methods do not apply. Describe what your business actually does. If you use third-party analytics, name the category (or the vendor). If you share data with an overseas processor (e.g. a US-hosted CRM), name the country.

Common traps in this section:

• Listing data categories you do not collect, to look more comprehensive — this is itself a misleading representation.
• Omitting overseas disclosures because the data sits with a SaaS vendor — vendor hosting in another country is a disclosure for APP purposes if the vendor can access the data.
• Failing to name a complaints contact and external escalation route to the OAIC.

Collection notices (APP 5)

Separate from the policy itself, APP 5 requires a short notice at or before the point of collection. The website implementation is a one-line notice beside any form that collects personal information ("We collect this to respond to your enquiry — see our privacy policy"), with a link to the full policy. The privacy policy is the long-form reference; the collection notice is the just-in-time disclosure. Templates routinely omit the collection notice, leaving an APP 5 gap even where the policy itself is compliant.

Cookies, analytics, and direct marketing

Cookies that capture personal information (including IP addresses tied to a user, or fingerprinting identifiers) trigger APP obligations even when the cookie is set by a third-party script. The drafting choice is whether to use a true consent banner (block scripts until accept) or a notice banner (inform but not block). True consent is closer to the OAIC's expectation for sensitive categories; notice banners are common and tolerated for ordinary analytics.

Direct marketing by email or SMS is also caught by the Spam Act 2003 (Cth), which requires consent, sender identification, and a working unsubscribe. Address both in the policy: APP 7 conditions for using personal information in direct marketing, and Spam Act conditions for sending the message. Treating "they gave us their email at checkout" as consent for marketing is a common drafting and operational error.

Optional and situational clauses

• Indemnity from the user — for user-generated content sites or platforms hosting third-party listings; the user indemnifies you against claims arising from their content.
• Force majeure — useful where the site provides scheduled services or content access tied to a paid plan.
• Survival — name which clauses (IP, liability limits, governing law) survive termination of access.
• Children's data — required if your site is directed at users under 18, with specific handling for under-13s where parental consent applies.
• Notifiable data breach commitment — a short clause referencing your obligations under Part IIIC of the Privacy Act reassures enterprise customers reviewing your policy in procurement.

How an Artificer Legal lawyer reviews these documents

We work through the documents in the order they bite. First, the liability and consumer-guarantee carve-out — most templates carry a clause we would not let our client rely on. Second, the IP and user-content licence — we add the model-training carve-out and the inbound licence from users, because both are gaps in templates written before 2023. Third, we audit the privacy policy against your actual data flows: a thirty-minute walk through the website forms, the CRM, the analytics stack, and the offshore processors usually surfaces three or four disclosures the current policy misses. Fourth, the collection notices on each form — this is the cheapest fix and the one most often skipped. Where you sit close to the $3 million turnover threshold or you are growing into it, we draft to the APP standard from day one so the documents do not need a rebuild later.

When negotiating bespoke terms (for a marketplace, a SaaS portal, or a content licensing arrangement), the negotiation order is acceptance mechanism, then liability cap, then IP licence, then dispute resolution. The clause we push back hardest on, from a counterparty, is any attempt to disclaim consumer guarantees against an Australian end user — that one always comes out.

The clause that decides whether the document works

The single clause that most often distinguishes a working set from a failing one is the limitation-of-liability — specifically, the carve-out that preserves the ACL. A blanket exclusion is worse than no exclusion: it tells a regulator and a court that you intended to mislead consumers about their rights. A properly drafted limit, calibrated to the type of supply and citing the ACL expressly, gives you protection where the law allows it and credibility where it does not.

Treat the website terms and the privacy policy as two documents doing different work in the same footer. The terms set the acceptance mechanism, narrow the IP licence to the user, limit liability inside the room the ACL leaves you, and govern conduct. The privacy policy describes what data your business actually handles, how, why, and where it goes, in language a non-lawyer customer can follow. Both documents are versioned, dated, and reviewed when your practices change — not as an annual ritual, but at the moment a new form, a new vendor, or a new offshore processor enters the stack.