Why engineers should read the Privacy Act
The Privacy Act 1988 is the main federal law governing personal information in Australia, and Schedule 1 sets out the thirteen Australian Privacy Principles. Most organisations with annual turnover above three million dollars are covered, and so are private health service providers and businesses that trade in personal information regardless of turnover. If your product holds information about identifiable Australians, the Act very likely applies to you or to the organisations that deploy your software.
The Act does not read like a technical standard. It sets outcomes: collect only what is reasonably necessary, use it for the purpose you collected it for, keep it secure, give people access to it, and take care when it leaves the country. Whether those outcomes are met is decided by choices engineers make: the fields on the signup form, what the services log, where the database lives, whether a deletion actually deletes. The privacy policy describes the system. When something goes wrong, the OAIC assesses the system itself.
Personal information is information or an opinion about an identified or reasonably identifiable individual, a definition that reaches further than most schemas assume. A device identifier joined to an account, free text in a support ticket and a voice recording can all qualify, and each carries the obligations below.
Collection and use limits live in the schema
APP 3 permits collection of personal information only where it is reasonably necessary for one of the organisation's functions or activities, and sensitive information, which includes health information and biometric templates, generally needs consent on top of necessity. Every form field, every analytics event property and every schema column either passes that test or it does not, and the field nobody can justify is the field to remove before launch. Our note on collecting less covers the discipline in depth.
APP 5 requires you to tell people, at or around the time of collection, what you are collecting and why. That notice has to match what the system actually does, and drift is common: the form says the phone number is for delivery updates, and eighteen months later a marketing automation is texting it. The drift is where APP 6 bites. Use and disclosure are limited to the purpose of collection, or to a related secondary purpose the person would reasonably expect, unless consent or another exception applies. For sensitive information the secondary purpose must be directly related.
The engineering consequence is that purpose is metadata worth recording. A schema that notes why each class of personal information exists gives you something to test new features against. When someone proposes training a model on support transcripts or joining the operational database to the marketing platform, you can look up what the data was collected for and ask whether the new use sits within a reasonable person's expectations. Without that record the call gets made by instinct, and instinct tends to answer yes.
APP 11 is judged after the breach
APP 11 requires reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification and disclosure. The Act never defines reasonable as a checklist; it scales with the sensitivity and volume of what you hold and the harm a breach would cause, so a multi-tenant clinical product carries a heavier obligation than a newsletter list. That is why our clinical software venture treats tenant isolation and Australian data residency as first-order engineering requirements rather than settings to revisit later.
APP 11 is usually assessed in hindsight, after a breach, and the answer draws on unglamorous engineering: patching cadence, multi-factor authentication, access that follows role, encryption in transit and at rest, logs that show who touched what, offboarding that revokes accounts promptly. The Notifiable Data Breaches scheme in Part IIIC turns that hindsight into a deadline: a suspected eligible breach gives you at most 30 days to complete the assessment, and a breach likely to result in serious harm must be notified to the OAIC and to affected individuals.
APP 11 has a second limb: once personal information is no longer needed for a purpose permitted under the APPs, and no law requires you to keep it, you must take reasonable steps to destroy or de-identify it. Retention is a security control, because the record you no longer hold cannot leak. The stakes changed in 2022, when the maximum penalty for a serious or repeated interference with privacy rose to whichever is greatest of fifty million dollars, three times the value of any benefit obtained from the breach, or thirty percent of adjusted turnover during the breach period.
Access and correction are features, whether or not you built them
APP 12 gives individuals the right to ask for the personal information you hold about them, and APP 13 the right to have it corrected. An organisation must respond within a reasonable period and give access in the manner requested where that is reasonable and practicable. Grounds for refusal exist and they are narrow. The obligation applies whether or not anyone ever built an export feature.
Most teams discover the gap the first time a real request arrives. The honest answer to what do you hold about this person spans the primary database, application logs, the analytics platform, the support desk, marketing tools, spreadsheets and backups, and if assembling it takes a week of ad hoc queries, the system has a missing feature.
Run a subject access dry run before a real request forces one. Pick a real customer record, set a time box, and answer as if the request were live:
- Can you enumerate every system holding personal information about one person, starting from a name or an email address?
- Can you produce their information in readable form without exporting other people's records alongside it?
- Does a correction reach the copies, and where you disclosed the information to another organisation, can you pass the correction on?
- Would anything embarrassing surface, such as passwords captured in logs or a stale customer export in a mailbox?
Overseas disclosure follows the architecture diagram
APP 8 governs disclosure of personal information to overseas recipients. Before disclosing, you must take reasonable steps, in practice contractual terms and verification, to ensure the recipient will handle the information consistently with the APPs, and in many cases the Australian entity remains accountable for what the overseas recipient does with the data. Exceptions exist, including informed consent, and they are narrower than teams tend to assume.
Read against a modern architecture diagram, that principle covers a lot of arrows. The log platform in a US region, the transactional email provider, the support desk, an LLM API: each one receiving personal information is a potential overseas disclosure. Where the legal line falls between use and disclosure is fact specific, so treat every offshore processor as in scope and make region a deliberate choice. Most major platforms offer Australian regions, and selecting them is a configuration decision with a compliance outcome.
APP 1 adds a transparency hook. Your privacy policy must say whether you are likely to disclose personal information to overseas recipients and, where practicable, which countries. If the engineering team cannot produce that list, the policy is guesswork. A processor inventory with regions recorded, reviewed whenever a vendor changes, answers both the policy question and the APP 8 question.
Where the Act is heading
Reform is live. A first tranche of amendments passed in December 2024, introducing a statutory tort for serious invasions of privacy, tiered penalties for less serious breaches, and a requirement, arriving after a transition period, for privacy policies to describe automated decisions that use personal information and significantly affect people's rights or interests. That last change is squarely an engineering question, because nobody can describe the organisation's significant automated decisions until someone has catalogued which systems make them.
Further change has been flagged. The Government's response to the Privacy Act Review agreed in principle to proposals including a fair and reasonable test for collection and use, and a narrowing of the small business exemption, which would bring many currently exempt organisations into scope. At the time of writing those proposals have not been legislated. The safe planning assumption is directional: coverage broadens, expectations tighten, and a system built to collect less, know what it holds, and keep data onshore by default will absorb the changes with far less rework.
None of this needs a legal department to begin. Run the necessity test over your collection points, record purpose alongside data, rehearse an access request, and put regions on the processor inventory. The depth behind each of those steps is where we work: mapping the obligations onto a specific stack, testing whether the reasonable steps hold against an attacker, and producing evidence an assessor will accept. This note is general information and does not constitute legal advice on your obligations under the Privacy Act 1988.