Get straight answers on CRM data residency in Australia

There is no general rule in Australian federal privacy law that personal information must be stored in Australia. The Privacy Act 1988 and the Australian Privacy Principles regulate how personal information is handled, not where the servers sit. Buyers often start a CRM evaluation assuming an onshore mandate exists, then find the real obligations are about accountability, security and disclosure. Narrower residency rules do exist in specific places, including the My Health Records framework, some government procurement arrangements that rely on hosting certification, and state-level health and justice requirements. The answer depends on who you are and what data you hold.

What applies to almost every commercial buyer is APP 8 on cross-border disclosure, APP 11 on security, and the Notifiable Data Breaches scheme. Together they mean you stay responsible for personal information you send offshore, you must protect it with reasonable steps, and you must assess and report qualifying breaches to the OAIC and to affected individuals. Penalties for serious or repeated interference with privacy have risen substantially, and further reform of the Privacy Act has been progressing in stages. A control framework built to today's bare minimum tends to age badly and gets re-examined at the worst moment.

So the practical goal is not to find a vendor with an Australian flag on its pricing page. It is to know where the data goes, to hold contract terms that survive scrutiny, and to be able to show your working when a regulator or a large enterprise customer asks. That is a documentation exercise as much as a technical one, and it is far cheaper to complete during evaluation than to reconstruct two years into a contract with a tender deadline running. Ask the questions while you still have the leverage of an unsigned order form, because vendors answer more precisely before the deal closes.

APP 8 requires an entity to take steps that are reasonable in the circumstances to ensure an overseas recipient does not breach the APPs, before disclosing personal information to that recipient. In practice, reasonable steps usually means enforceable contract terms covering handling, subcontracting, complaint processes and breach notification. The expected effort scales with the sensitivity of the information and the risk involved, and cost or inconvenience alone is not accepted as a reason to skip it. Exceptions exist, including where the recipient is subject to a substantially similar law with an accessible enforcement mechanism, or where the individual gives informed consent.

Section 16C is the part procurement teams should read closely. If an overseas recipient does something that would breach the APPs, that act is treated as having been done by the Australian entity. Taking reasonable steps does not move the liability across. This is why contract quality matters more than a badge on a vendor website. Your agreement should state what the vendor may do with the data, bind subprocessors to equivalent terms, require assistance with access and correction requests, and set breach notification timing that leaves you room to meet your own obligations.

There is also a long-standing distinction between use and disclosure for cloud services. OAIC guidance accepts that giving personal information to an overseas cloud provider may be a use rather than a disclosure where a binding contract limits the provider to handling the data for your purposes, binds its subcontractors equally, and leaves you in effective control, able to access, retrieve, correct and require deletion. If that is your arrangement, APP 8 disclosure duties may not be triggered. You still hold the information, and every other APP, including APP 11, continues to apply in full.

APP 11 requires reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure, and to destroy or de-identify it when it is no longer needed. What counts as reasonable depends on the volume and sensitivity of the information and the harm that would follow a compromise. A CRM holding thousands of named contacts, mobile numbers, deal notes and email history sits squarely in the range where encryption, access control, logging and a defined deletion path are expected rather than treated as optional extras.

HelloGrowthCRM protects data in transit with TLS and encrypts data at rest. Customer data sits in Supabase-managed Postgres on AWS, with row-level security enforcing tenant isolation. Role-based access control governs which of your users can see which records. Production access on our side is least-privilege, multi-factor gated, logged and reviewed periodically. Automated backups run with point-in-time recovery. Soor LLC completed a SOC 2 Type II examination covering a February to June 2025 observation window, and the report is available under NDA from sales@hellogrowthcrm.com. We make no claim to ISO 27001 or PCI DSS.

Under the Notifiable Data Breaches scheme, an eligible data breach, meaning unauthorised access, disclosure or loss likely to result in serious harm, must be assessed promptly and notified to the OAIC and to affected individuals. If a vendor is slow to tell you, your own assessment window is already consuming itself. Soor LLC maintains a documented incident-response workflow that includes customer notification, and publishes a vulnerability disclosure process at /legal/vulnerability-disclosure so researchers have a defined route to report problems rather than posting them publicly. Check that your contract with any vendor sets notification timing you can actually work with, not timing that consumes your entire assessment window before you hear anything.

HelloGrowthCRM runs on Supabase-managed Postgres hosted on AWS. The region that applies to a given account is confirmed during onboarding or a security review rather than assumed from a marketing page. If Australian hosting is a requirement for your organisation, because of a government contract, a health-sector rule, an internal policy or a commitment you made to your own customers, raise it before you sign. Ask us to confirm in writing which region your account will use and whether the region you need is available for your deployment, then keep that confirmation with your assessment.

Do not treat an Australian sales presence, a local phone number or an .au domain as evidence of local hosting, from us or from any vendor. Ask the same question of every shortlisted supplier and ask it precisely. Which region holds the primary database? Where do backups and read replicas live? From where does support access customer data? Are logs, product analytics, email content and file attachments in the same region as the database, or somewhere else? Which subprocessors touch the data and where do they operate? Our subprocessor list at /subprocessors answers the last one publicly.

If offshore processing turns out to be acceptable for your use case, which it often is, document why. Record the reasonable steps you took, the contract terms you relied on, whether you treated the arrangement as a use or a disclosure, and who signed it off. An assessment written at purchase time takes an afternoon. The same assessment reconstructed under pressure during a tender response or a regulator enquiry takes far longer and reads as considerably weaker. A Data Processing Agreement is available from us to sit behind that record.

Start with documents. Ask for the data processing agreement, the subprocessor list, the security overview and the most recent independent assurance report. For Soor LLC that is a SOC 2 Type II report covering a February to June 2025 observation window, available under NDA. Read the scope section rather than the cover page, because the value of a report lies in which systems and criteria it covers and which exceptions were noted. If a vendor offers only a completed self-assessment questionnaire and nothing independent, that is an answer in itself.

Then test the operational claims in a trial account rather than in a sales call. Can an administrator export all account data without vendor help? Ours can, at any time. Can you delete a contact and have it stay deleted, understanding that backups hold data for a recovery window? Can you restrict a user to a subset of records through roles? Is there a documented process for data rights requests, and is it published? Ours is at /legal/data-rights. Answers you can verify yourself are worth considerably more than answers you are given.

Finally, watch how a vendor behaves when it does not have a good answer. Precise statements about what is and is not offered are a better signal than an unbroken run of yes responses. We do not hold ISO 27001 certification. We do not hold PCI DSS certification. We do not publish uptime figures on this page. The hosting region for your account is confirmed with you directly rather than promised in advertising. If those answers rule us out for a particular tender, it is better to establish that during evaluation than after migration.