What is privacy compliance?
Privacy compliance means building the technical features that allow your application to meet its legal obligations around personal data — both under the Australian Privacy Act 1988 and, if you have European users, the GDPR. Both frameworks operate on similar principles: collect only what you need, be transparent about how you use it, and give users meaningful control over their data.
The core technical implementations are: consent management (capturing and recording what users have agreed to), data subject rights (the ability to export or erase a user's personal data on request), data retention policies (not keeping data longer than necessary), and audit trails that prove your practices match your policy.
These aren't just legal checkboxes. Privacy-conscious design builds trust — and with Australian regulators increasing enforcement activity, it's also increasingly a business risk to ignore.
When does your app need it?
- You collect personal information from Australian users (the Privacy Act applies to most businesses with turnover over $3M, and some smaller ones)
- You have European users or plan to expand there (GDPR applies)
- Your privacy policy promises things (data deletion, access requests) that your system doesn't actually support yet
- Enterprise or government customers are asking about your privacy practices as part of procurement
- You use third-party analytics or marketing tools that set cookies without user consent
- You're in a regulated sector: health, financial services, aged care
How much does it cost?
Adding privacy compliance features typically adds 5–11 hours of development — roughly $1,000–$2,000 AUD.
Lower end: Cookie consent banner (with granular categories and proper opt-out), a "delete my account" feature that anonymises rather than hard-deletes records (preserving referential integrity), and a basic "export my data" function. These three cover the most common user-facing requirements.
Higher end: Full consent audit trail (logging every consent event with timestamp and version of the policy accepted), granular marketing preference management, automated data retention jobs that purge old records on schedule, a data subject request workflow for the ops team, and a data processing register. Integration with a consent management platform (Cookiebot, Axeptio) for multi-jurisdictional compliance.
How it's typically built
The most important technical pattern is soft deletion with anonymisation. Rather than deleting a user record (which breaks foreign key references and audit trails), personal fields are overwritten with anonymised values — name becomes "Deleted User", email becomes a UUID, phone number is cleared. The record remains for referential integrity; the person is gone.
Data export generates a structured archive (JSON or CSV) of everything you hold about a user — profile data, activity history, files, preferences. This is typically a background job, with the download link emailed when ready.
Consent is stored as a log of events: user X accepted version Y of the privacy policy at timestamp Z, via source W. This is append-only — you never update consent records, only add new ones.
Cookie consent on the frontend requires that analytics and marketing scripts are not loaded until consent is granted. This means conditionally loading scripts based on consent state, not just displaying a banner.
Questions to ask your developer
- Does your "delete my account" feature actually remove personal data? Many implementations only deactivate the account — that's not compliant with erasure requests.
- Is your cookie consent banner blocking third-party scripts until consent is given? A banner that loads analytics scripts before the user clicks accept is still non-compliant.
- How are consent records stored? You need to be able to prove, at a specific point in time, what a user consented to.
- Do you have a data retention schedule? Knowing when data should be deleted and having a job that does it are different things.
- Have you reviewed your third-party integrations? Every analytics tool, support platform, and marketing service you use is a data processor — they need to be in your DPA.
See also: Security audit and pen test · SOC 2 readiness · App cost calculator