The Australian Rules for Health Data in HubSpot and Shopify: the Privacy Act and the APPs

If your data protection policy says HIPAA, it is the policy for a different country. The Health Insurance Portability and Accountability Act is United States law and it has no reach over an Australian business. Nobody at the Office of the Australian Information Commissioner is going to ask you about Protected Health Information, ePHI or a Business Associate Agreement.

They are going to ask you about the Privacy Act 1988.

This is more than a terminology fix, because the two regimes want different things from you. HIPAA is organised around covered entities and the business associates they hand data to. The Australian Privacy Principles are organised around the life of a piece of information: how you collected it, what you may use it for, how you protect it, when someone can ask to see it, and when you have to get rid of it. Work through a HIPAA checklist for an Australian clinic or an Australian online store and you will pass a test nobody is setting, while the obligations that genuinely apply to you go unread.

Who is covered, and the exemption that catches people out

The Privacy Act carries a small business exemption based on annual turnover, and that is where most people stop reading. It is also exactly where health data changes the answer: a business that provides a health service and holds health information is covered even when it would otherwise be small enough to be exempt. A two person physio practice is in. A telehealth startup with four staff is in. An online store that collects a customer's medical conditions so it can advise them on a product is closer to that line than its founders usually think.

So the first question is whether you are holding health information at all, before you get anywhere near which platform it sits in. Most teams find they are holding more of it than anyone decided to.

Health information is sensitive information, and APP 3 is stricter about it

APP 3 governs collection, and it treats health information as sensitive information, which means a higher bar. In general you need the person's consent to collect it, and it has to be reasonably necessary for something your organisation actually does. The full set of principles is on the OAIC site, and APP 3 and APP 11 are the two that will shape your build.

In practice that gives you two tests before you add a field to a Shopify checkout or a HubSpot contact record. Do we need this to do the thing the customer asked us to do. Did they agree to give it to us for that.

A free text notes field fails both. Whatever ends up in there was never collected on purpose, nobody consented to it, and you now hold it. This is the most common way a business that never set out to collect health information ends up holding it in places nobody can list.

Date of birth is worth a mention here, because people either ignore it or over-classify it. It is personal information and it is not sensitive information in the Act's defined sense, so APP 3's consent rule does not bite on it the way it does on a diagnosis. It is still one of the first fields we find readable by everyone in a portal. Here is our approach to handling a contact's date of birth as sensitive data in HubSpot, which keeps the age calculation without leaving the raw date sitting on every record.

APP 11 is two obligations, and the second one never gets done

APP 11.1 is the one everybody knows: take reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure. Encryption, permissions, two factor authentication. Fine.

APP 11.2 is the one that gets skipped. When you no longer need the information for any purpose you are permitted to use it for, you have to destroy it or de-identify it. There is no retention project in most portals. There is an old contact record with a condition typed into a note, kept because deleting things feels risky, which is a liability carrying no upside at all.

Someone can ask to see it, and ask you to fix it

The HIPAA Privacy Rule gave patients a right to their own health information. The Australian version of that is APP 12 and APP 13: on request you give a person access to the personal information you hold about them, and you correct it when it is wrong. The practical question is whether you could answer that request today. If health details are spread across a Shopify order note, a HubSpot property and a free text field, finding all of it is the hard part, which is another argument for collecting less of it.

The Notifiable Data Breaches scheme is what replaces breach notification

If breach notification was the part of your old HIPAA policy you actually understood, its Australian counterpart is the Notifiable Data Breaches scheme. An eligible data breach is unauthorised access to, unauthorised disclosure of, or loss of personal information that is likely to result in serious harm. When one happens you have to notify the OAIC and the individuals affected. If you suspect one and cannot tell, you have to assess it, and the window to do that is short.

Health information moves that likely to result in serious harm test a long way. A leaked mailing list is bad. A leaked mailing list with conditions attached is a different category of event, and the assessment clock starts the moment somebody in your business suspects something has gone wrong.

So the preparation that helps here is a name. Who decides whether this is an eligible breach, who they call, and where the access logs are.

What to change in Shopify

Staff permissions, and two factor for everyone

Give staff accounts the narrowest permission set that lets them do the job, and turn on two factor authentication across the board. Unauthorised access through a login somebody should never have had is a common thread in reported breaches, and role based permissions are what stop one compromised account from becoming an export of the whole customer list.

The forms, and what you ask them for

Shopify encrypts form and checkout data in transit as standard, so the technical side is mostly handled for you. The risk that is yours is the questions. Every field you add that could hold a health detail is a field you now have to secure, justify and eventually delete, and a free text box invites all three problems at once.

Encryption, and the way people defeat it

Data is encrypted at rest and in transit using AES and TLS, with key management handled by the platform. Your job is to avoid undoing that: the CSV export sitting in someone's Downloads folder, the customer list emailed to an agency, the spreadsheet on a personal laptop. Every one of those is a copy the encryption no longer protects.

Logs you can actually read

Shopify records staff activity. Go and look at it once before you need it, because who accessed this record and when is the first question in a breach assessment, and that is a poor moment to learn where the answer lives.

What to change in HubSpot

Mark the properties that hold it, and restrict who sees them

HubSpot has a sensitive data setting for properties that hold information like this, and permissions that can keep a field visible to the clinical team and hidden from everyone else. Both depend on your subscription, so check what your portal includes before you plan around them. What is not optional is knowing which properties are in scope, and that is a list you can build in an afternoon.

Build the retention rule as a workflow

APP 11.2 is the obligation a CRM is actually good at. A workflow that clears a sensitive property a set number of days after the last relevant activity turns a policy nobody follows into something that happens on its own. Pick the number with whoever owns your clinical or legal risk, then build it.

The sync between the two is where this gets missed

Connect Shopify to HubSpot and order data, contact detail and whatever custom fields you mapped now exist twice, under two sets of permissions, with two export paths and two audit trails. APP 11 applies to both copies. So does APP 8: if personal information goes to an overseas recipient, you stay accountable for how it is handled there, which makes the hosting region of your portal a question worth answering instead of assuming.

The fix is boring and it works. Map the minimum. Review the field mapping when someone adds a property, because that is when scope creeps.

Where we see this go wrong

Three patterns, in the order we find them. Free text fields holding things nobody chose to collect. A sync copying more than anyone intended, set up once and never reviewed. And no retention rule anywhere, so the portal only ever grows.

Worth saying too: the Privacy Act is not the only law in the room. What you may store and what you may send are different questions, and the Spam Act governs the second one. If you are about to email a list you have not touched in two years, start with keeping a re-engagement send Spam Act safe.

Most of this is configuration rather than construction, which is why it tends to sit undone. If you would like it done by someone who does it weekly, that is our RevOps and HubSpot work.

The controls, and which principle each one answers to

Control	What it is for	Principle
Roles and staff permissions	Limits who can open the record at all	APP 11
Two factor authentication	Stops a reused password becoming a breach	APP 11
TLS on forms and checkout	Protects data while it moves between systems	APP 11
Encryption at rest	Protects the stored copy	APP 11
Activity and audit logs	Answers who accessed what, the first question in a breach assessment	APP 11 and the NDB scheme
Asking only for the fields you need	Keeps the collection lawful in the first place	APP 3
Consent at the point of collection	Required before you collect health information	APP 3
Knowing where every copy of a person's data sits	You have to be able to give them access to it, and correct it	APP 12 and APP 13
Retention and deletion rules	Destroys or de-identifies it once you no longer need it	APP 11.2
Checking where the data is hosted	You stay accountable for anything sent offshore	APP 8

Here is the exercise worth doing this week. Open your portal, go through your properties, and count the ones that could hold a health detail. If that number surprises you, the harder question is the one behind it: who decided how long you keep them?