If you’re building a health platform, AI product, or even a tool that touches patient data, you need to understand Australian privacy law. Not because compliance is fun-it isn’t-but because getting it wrong costs money, breaks trust, and can kill your company before it ships.
The Australian Privacy Act isn’t optional window dressing. It’s the legal backbone, and it changes how you architect, store, and handle data. Let’s walk through what that means for founders and builders.
What Actually Counts as “Health Information”
The Privacy Act defines health information broadly. It’s not just medical records. It includes:
- Diagnostic information (test results, scans, pathology)
- Treatment information (medications, procedures, therapies)
- Disability or condition data (even if inferred)
- Genetic information
- Counselling records
- Aged care, disability support details
The tricky part: this covers inferred health data too. If your app tracks sleep patterns, mood, or biometric data, and someone could reasonably infer a health condition from that, it counts. A fitness app that logs depression indicators is handling health information. A menstrual tracking app absolutely is. That changes your entire compliance posture.
Many founders discover this too late. A health-adjacent product they thought was low-risk suddenly needs serious privacy governance. The time to sort this out is in design, not after you’ve shipped.
The Australian Privacy Principles (APPs) That Matter Most
The Privacy Act contains 13 Australian Privacy Principles. For health software, six of them will shape your build.
- APP 1 (Management of personal information): You need a privacy policy, privacy impact assessments, and staff training. This is the governance layer.
- APP 3 (Collection of solicited personal information): Only collect what you need. If you’re asking for historical diagnoses when you don’t need them, you’re breaking this one.
- APP 5 (Notification): Tell users what you’re collecting and why, before or at the point of collection. Bury it in a 50-page terms document and you’ve failed.
- APP 11 (Security of personal information): Encrypt at rest and in transit. Limit access. Audit logs. Incident response plans. This is where architecture decisions matter.
- APP 12 (Access and correction): Users must be able to access their own data and request corrections. Your API and UI need to support this.
- APP 13 (Complaints): You need a process to handle privacy complaints. Document it.
APP 11 is where engineering meets compliance. If you’re storing encrypted data, you need proper key management. Rotating keys, access controls, audit trails-these aren’t nice-to-haves. They’re required. If you’re using third-party hosting (AWS, Azure, Google Cloud), you need documented data processing agreements with your infrastructure provider.
De-identification and Why It’s Harder Than You Think
The Privacy Act recognises de-identified information. De-identify your data and it’s no longer regulated as personal information. This sounds useful until you understand the bar.
De-identification isn’t just stripping names and ID numbers. The Privacy Act requires that a reasonable person would not be able to identify the individual, directly or indirectly. The Australian Information Commissioner’s office sets a high bar here. Indirect identification includes combinations of characteristics: age + postcode + rare condition = identified, even if you removed the name.
Most founders assume their de-identification logic is solid. Many have to rebuild it later. If you’re planning to use health data for research, analytics, or training an AI model, plan for de-identification from day one. It’s not a feature you bolt on; it’s an architecture choice.
Real talk: if your business model depends on de-identified health data, get legal advice early. What looks de-identified to you might not pass OCO scrutiny, and re-identification via linkage attacks is a real risk.
Cross-Border Data and Australian Hosting
Here’s a practical constraint: APP 1 requires you to take reasonable steps to ensure overseas recipients comply with the APPs, or comply with substantially similar privacy law.
If your database sits in a US cloud region, you’re liable for that. You need contractual protections, and you need to understand the legal framework of the jurisdiction where data sits. US cloud providers have US court obligations (CLOUD Act, data requests). EU providers have GDPR. Australian data should genuinely stay in Australia, or at least in a jurisdiction with comparable privacy protection.
For health data especially, this isn’t paranoia. It’s the law. If you’re bootstrapping costs by using cheap offshore infrastructure, your health data strategy needs rethinking. Consider Australian cloud services (AWS Sydney, Microsoft Azure Australia, Google Cloud Australia). They cost more, but they’re simpler from a compliance angle.
What Your First Privacy Impact Assessment Should Cover
You don’t need a 100-page document. You need clarity on your actual risks. Start with this:
- What health information are you collecting? (Be specific.)
- Why are you collecting it? (Justify each field.)
- How long are you storing it?
- Who inside your company has access? (Document this.)
- Where is it stored and how is it encrypted?
- What happens to it if you shut down? (Data deletion plan.)
- Could a breach happen? (Threat modelling. Yes, really.)
- How will users delete their data?
This becomes your baseline. It’s also the thing auditors, investors, and enterprise customers will ask about. Having a clear answer ready speeds up every conversation.
Building for Compliance From Day One
The worst position is building fast, shipping, then retrofitting privacy. It breaks things. It’s expensive. It’s risky.
Instead, build privacy into your 28-day MVP. It’s not slow. It’s actually faster because you’re not guessing. Encrypt by default. Limit data collection to what you need. Build access logs. Document your decisions.
If you’re shipping health software in Australia and you’re unsure whether your approach is compliant, talk to Amora about your build. We work with founders on this regularly. We understand the Privacy Act, we understand infrastructure, and we build systems that are compliant from launch, not patched afterward.
Health data is valuable. That’s why it’s protected. Respect that from the start, and you’ll build something that lasts.
Got something you want built?
Amora Digital is an Australian software and AI agency. We scope it, build it, and ship it – live in 28 days. No offshore teams. No surprises.