Where your data
lives

"Where your data lives" sounds like a single fact, but it actually answers two separate questions that get conflated constantly in vendor conversations. Data residency is the physical question: in which country do the servers holding the primary copy and the backup actually sit. Data sovereignty is the legal question: which country's courts, regulators and law enforcement can compel access to that data, regardless of where the hardware happens to be.

The two usually line up for a genuinely Australian vendor, but they don't always line up for an Australian arm of a foreign company running Australian data centres, or for a platform that stores data in Australia while routing part of its processing through offshore infrastructure. A practice manager who asks "is our data in Australia?" and stops there has answered the residency question and left the sovereignty question completely open.

The Privacy Act 1988 (Cth) and the Australian Privacy Principles it contains treat health information as sensitive information, which sets a higher bar for its collection and use than applies to ordinary personal information. The cross-border disclosure principle in the APPs, generally referred to as APP 8, requires an organisation to take reasonable steps before disclosing personal information to an overseas recipient, and in most cases the disclosing entity remains accountable for what that overseas recipient then does with the information.

That accountability point matters more than most practices realise. If a clinic's scribe, billing platform or practice management system sends data to an offshore subcontractor and something goes wrong, the practice, not just the vendor, can carry regulatory exposure under the Privacy Act. The Office of the Australian Information Commissioner (OAIC) is the regulator that assesses these matters, and its guidance consistently treats cross-border handling as a chain of accountability rather than a box ticked once at onboarding.

A vendor's marketing page will say "secure" and "compliant." Neither word tells a practice manager anything specific. The questions that actually surface a real answer are narrower and more mechanical than that, and worth reading alongside the detail in Security and data handling:

• Which country holds the primary copy of the data, and which country holds the backup, by name.
• Is the vendor an Australian-incorporated entity, or an Australian-facing arm of a foreign parent, and does that change which country's law enforcement can compel access.
• Is each record encrypted individually, or is the protection a single layer wrapped around the whole database.
• Does the vendor keep a tamper-evident audit trail of every access to a record, not just a login log.
• What happens to the data, and to the practice's ability to retrieve it, if the vendor is acquired or stops trading.

Many vendors describe a "backup" location as though naming it settles the residency question. It doesn't. A backup that sits in a second Australian city protects a practice against a regional outage or a single data centre failure without changing the sovereignty position, because both locations remain under Australian jurisdiction. A backup that sits offshore, even briefly, or that runs through an offshore disaster-recovery contract, reopens the cross-border question this article has already described, and it does so for every record the practice has ever generated.

The practical test is simple: ask the vendor to name the country of the backup rather than just confirm one exists. A vendor that has to check before answering doesn't manage that decision deliberately enough for a health record.

"Encrypted" is another word that can hide a real design decision. Encryption applied once, around an entire database, protects against someone stealing the physical disk. Encryption applied per record protects against a far more common failure: a compromised staff credential, a misconfigured permission, or a vendor employee holding broader access than their role requires. That second failure mode is the one that actually shows up in breach notifications, which is why the distinction is worth asking about directly rather than accepting the word "encrypted" on its own.

The audit trail matters just as much. A basic access log records that someone logged in. A tamper-evident audit trail records who touched a specific record, when, and what they did, in a form that can't be quietly edited afterwards, which is what a practice needs if it ever has to reconstruct events for AHPRA, for a Medicare compliance review, or for a legal process years later. Retention periods for health records are set by state and territory legislation and vary by jurisdiction and by the patient's age at the time of the record, so the useful question for a vendor isn't "how long do you keep records," it's whether the retention period can be configured to match whatever the practice is legally required to meet.

Data residency doesn't sit apart from the rest of a practice's regulatory obligations. It touches several of them directly, and the fuller picture is set out in Compliance and privacy:

• AHPRA's expectations around clinical record-keeping assume a practitioner can retrieve an accurate, complete record on demand, which is harder to guarantee if a vendor's storage arrangement is unclear.
• The Medicare Benefits Schedule requires a contemporaneous, clinically relevant record to support the item billed, and that record has to actually exist somewhere the practice can produce it.
• My Health Record, operated by the Australian Digital Health Agency, is a separate system with its own consent and upload rules; a scribe or practice system storing data in Australia doesn't automatically mean anything has been shared to My Health Record, and the two shouldn't be conflated.
• RACGP standards for general practice expect a practice to know, and be able to explain, how patient information is stored and protected, which is difficult to do if the practice hasn't asked the vendor the residency question directly.