Australian Privacy Act: What Software Teams Need

Australia’s Privacy Act has just undergone its first significant update in over a decade. If your team’s last thorough review of Australian privacy obligations was more than a year or two ago, a considerable amount has changed, and this warrants a careful examination before you make decisions that assume the old rules still fully apply.

The groundwork remains the Privacy Act 1988 and the Australian Privacy Principles it outlines, the thirteen principles guiding how organizations collect, use, disclose, store and provide individuals access to their personal information. What is new is a suite of reforms, the Privacy and Other Legislation Amendment Act 2024, which received royal assent in December 2024 and has been coming into effect since, as noted by legal experts as the first significant update to the Act since 2012.

What actually changed, and what it means for a build

A few of the changes are directly relevant to how a software product should be designed:

• A new legal remedy for severe privacy intrusions. As of mid 2025, individuals in Australia have a personal legal right to sue over a severe privacy intrusion, whether that is interference with their private affairs or misuse of their information. This elevates the practical consequences of data handling errors beyond regulatory penalties alone.
• Enhanced enforcement capabilities for the regulator. The Office of the Australian Information Commissioner can now send infringement and compliance notices directly, and there is a new mid-level civil penalty available for privacy breaches that are significant but not the most serious category.
• New transparency rules concerning automated decision making. If your product employs algorithms to impact decisions like eligibility, scoring, or recommendations with real-world consequences, the updates heightened what organisations must reveal about these systems.

There is also a Children’s Online Privacy Code under development, which will detail specifically how the Australian Privacy Principles apply to children’s personal data, including default privacy settings and age-appropriate consent. As of this writing, it has not been confirmed as final and in force. If your product’s user base includes or could plausibly include minors, track this directly with the OAIC rather than assuming the current general principles are the last word once the code is finalized.

For a team actually developing a product, the practical implications fall in a few areas. Data minimisation, only collecting what you genuinely need, matters more now that the cost of getting it wrong includes a personal right of action, not just a regulatory complaint. Consent flows and privacy notices need to detail what you actually do with data, since vague boilerplate is a weaker defence than it used to be. And if your product involves any form of automated decision making, even something as simple as a recommendation engine or an automated approval flow, document how that logic works well before a regulator or a curious customer asks.

Most Australian-focused products don’t require a compliance overhaul due to this. The changes mostly reinforce principles that were already best practice: collect less, be clear about why, secure what you hold, and be ready to explain automated decisions. The key difference now is that the consequences of getting these right are more tangible than they were two years ago, which makes it a reasonable time to actually revisit your data handling rather than treating it as a solved problem from an earlier build. A brief, honest audit of what personal data your systems actually collect, versus what you assumed they collect, is usually the fastest way to find the gap between your current practices and where the updated Act now expects you to be.