Data sovereignty

Residency is where your data sits. Sovereignty is whose law can reach it.

Most support platforms will now store your data in Sydney. Almost none of them are Australian. Those are different facts, and only one of them survives a question from your auditor.

The question that actually matters

When a support platform holds your customers' correspondence, the useful question is not where is it stored. Every serious vendor can answer that one, and most will say Sydney.

The question is: who can be compelled to hand it over, and who carries the liability when they do?

Two facts shape the answer, and both are checkable by your own counsel rather than taken on our word.

Storage location does not determine legal reach

The United States CLOUD Act reaches a service provider under US jurisdiction regardless of where the data is stored. Choosing an Australian hosting region changes the physical location of the servers. It does not change which company is served the production order, or which country's courts issue it.

There is an Australia–United States CLOUD Act Agreement that adds safeguards and process to how such requests are made. It does not remove the jurisdiction; it governs how it is exercised.

Under APP 8, the liability stays with you

Australian Privacy Principle 8 governs cross-border disclosure. If you disclose personal information to an overseas recipient and that recipient mishandles it, you are treated as having breached the Privacy Principles yourself. The accountability does not transfer to the vendor you chose, however large they are.

Which means the vendor's compliance page is not the end of your analysis. It is the beginning of yours.

Where SupportAndGo sits

SupportAndGo is operated by Fintech Development Pty Ltd, ABN 78 655 608 969 — an Australian company. Not an Australian region of a foreign company, and not an Australian reseller of a foreign platform.

The practical consequence for you: there is no cross-border disclosure. Your customers' support data is disclosed to an Australian company, stored in Australia and processed in Australia, so APP 8's overseas-recipient regime does not engage at all. There is no chain of foreign entities to assess, and no foreign parent to be served.

SydneyEvery data store, function and queue runs in australia-southeast1. Never the US or EU.
OnshoreAI classification of personal information runs on an Australian endpoint and fails closed rather than falling back offshore.
AustralianThe operating company, the jurisdiction and the courts are all Australian.

Fails closed, not falls back

This is the detail worth checking with any vendor claiming onshore AI. When our Australian AI endpoint is unavailable, classification simply does not happen and the ticket is handled without it. It does not quietly retry against an overseas model — which is the failure mode that turns a sovereignty claim into an incident report, because nothing in the request path would report it.

What you can hold us to

Sovereignty is only worth anything if it produces evidence. On the Business tier these are contractual rather than aspirational:

  • Contracted Australian residency — the location commitment in writing, not a configuration setting we could change.
  • Audit log export — an immutable record of every state change against a ticket, exportable for your own retention.
  • Deletion certificate on exit — a signed record of exactly what was erased and when, including the count of stored files.
  • Tenant isolation — every ticket, message and file is scoped to your tenant in the storage path itself. Isolation is structural, not a filter applied to a shared pool.

One honest note on the deletion certificate: deleted files remain recoverable from backup for seven days before they are permanently gone. We say so on the certificate. A deletion record that claims instant, irreversible erasure would be easier to sell and would not be true.

Common questions

Is my current provider actually a problem?

Not necessarily, and we are not going to tell you it is. Most Australian businesses use a foreign support platform without incident. The question is whether your organisation has an obligation — regulatory, contractual, or from a large customer — that makes foreign jurisdiction a risk you have to document. If it does not, this page is not aimed at you and we would rather say so than sell you something you do not need.

Does the Australia–US CLOUD Act Agreement solve this?

It adds safeguards to how cross-border requests are made and handled between the two governments. It does not remove US jurisdiction over US-owned providers. If your analysis needs to conclude that no foreign legal process reaches the data, an agreement governing that process is not the same as its absence.

Do I need the Business tier to get Australian hosting?

No. Every tier, including the free one, runs entirely in Sydney — that is how the product is built, not something we sell you. What Business adds is the contractual commitment, the audit export and the deletion certificate: the evidence, rather than the fact.

Where should I verify this rather than take your word?

Ask us for the operating entity's ABN and check it on ABN Lookup. Ask which region every data store runs in and what happens when the AI endpoint fails. Ask whether any sub-processor is foreign-owned. Then ask the same three questions of your current vendor. The answers are more persuasive from them than from us.

This page describes our architecture and corporate structure. It is not legal advice, and your obligations depend on your own circumstances — your counsel should confirm what applies to you.

See what it costs

Priced per desk rather than per agent, in Australian dollars, with the AI in the price.