SaaS + Legal

Privacy compliance isn't optional past $3M turnover. It's a legal requirement backed by the Office of the Australian Information Commissioner (OAIC). Breach the Privacy Act 1988 and you face civil penalties up to $50M, criminal prosecution, or a mandated audit. Most SaaS founders ignore it because it's unsexy. That's a bet. One customer lawsuit or a regulator investigation costs 10× more to defend than shipping compliance infrastructure upfront. Velocity X SaaS clients ship privacy controls on day one. Not as an afterthought. As a required feature set.

The Privacy Act at a Glance

The Privacy Act 1988 (Cth) is Australia's primary privacy law. It applies to organisations with annual turnover of $3M or more, or organisations in the health sector (no turnover threshold). The Australian Privacy Principles (APPs) are 13 enforceable rules. Breach one and you've breached the Act. The OAIC can investigate complaints, issue enforcement notices, and refer cases to the Federal Court. The Australian Information Commissioner has teeth.

Why does this matter for SaaS? Because you collect customer data (email, payment info, usage logs, personal details). That data is personal information under the Act. You must handle it according to the APPs. If you don't, you're liable. The fine is not a cost of doing business — it's existential.

The 13 Australian Privacy Principles (APPs)

APP 1: Open and Transparent Management of Personal Information

You must have a clear, accessible privacy policy that explains: what personal information you collect, why, who you share it with, how long you keep it, how users can access/correct/delete their data, how they complain, and how you handle breaches. Not a 500-word boilerplate. A real document that a customer can read and understand. Specificity matters. "We collect data necessary to provide services" is vague. "We collect email, name, payment method, and IP address for account creation, billing, and fraud detection" is concrete. OAIC audits read these closely.

APP 2: Collection of Personal Information

You can only collect personal information that's necessary for your function. Don't collect data you don't use. If you're a CRM, you collect email, phone, company name. You don't collect passport numbers or birthdays unless you have a documented reason. Collect only what you need. Store it cleanly. Document your collection logic in brand.json under a privacy section so it's auditable: which fields, why, retention window, third-party recipients.

APP 3: Collection Notification

When you collect personal information, you must notify the individual about your privacy policy and practices — or take reasonable steps to do so. At signup, link to your privacy policy and get explicit consent if you're collecting sensitive data (health info, financial details, government ID). A checkbox that reads "I agree to the privacy policy" does the job. No consent = no collection.

APP 4: Use or Disclosure

You can only use or share personal information for the purpose you collected it (or a directly related purpose). If you collect email to send transactional emails, you can't sell it to a marketing list. You can't share it with third parties without explicit consent. If you do share it (e.g. payment processor, analytics, email service), you must disclose that in your privacy policy by name. Many SaaS use Supabase, Stripe, and Segment — all three must be listed.

APP 5: Data Quality and Data Integrity

Personal information must be accurate, up-to-date, and complete. If a customer tells you their email changed, update it. Don't let stale data sit in your database for years. Periodically audit your database for orphaned records, invalid entries, or duplicates. If you find a customer's data is wrong, take steps to correct it. Document your data quality process.

APP 6: Data Security

You must take reasonable steps to protect personal information from misuse, loss, unauthorized access, modification, or disclosure. This is where the technical stack matters. Encrypt data in transit (HTTPS). Encrypt data at rest if it's sensitive (Supabase encryption). Use strong authentication (no shared passwords). Restrict database access to authorized staff. Conduct regular security audits (run SecurityHeaders checks, penetration testing, dependency scanning). If you're hacked and customer data leaks, you breach APP 6 even if you had a policy. Security isn't optional.

APP 7: Data Breach Notification

If a data breach is likely to cause serious harm, you must notify affected individuals "without unreasonable delay" and the OAIC within 30 days. Serious harm means identity theft, financial loss, damage to reputation, or psychological distress. A breach of 5 customer emails is probably not serious harm. A breach of 10,000 customers' payment methods is. The NDB scheme (below) details this.

APP 8: Open and Transparent Management — Transfer of Personal Information Overseas

If you store data on AWS us-east-1 or transfer data to a country with weaker privacy laws, you must notify customers and ensure the overseas recipient complies with the APPs (or equivalent). This is a trap for many SaaS. If your Supabase instance is in us-east-1, you're transferring Australian customer data to the US. Your privacy policy must disclose this. The US doesn't have equivalent privacy protections, so you need customer consent or a data processing agreement. Simplest solution: host in ap-southeast-2 (Sydney) if your customers are Australian.

APP 9: Individual Access

A customer can request access to their personal information. You must provide it within 30 days, in a clear format, usually a CSV or JSON export. No redactions (except for third-party references that don't identify the requester). Implement a data export endpoint in Supabase: query the user table, orders table, logs table — anything tied to that user — and export as JSON. Make it self-service so customers don't email you support requests. This is low-hanging fruit for compliance.

APP 10: Correction of Personal Information

If a customer's data is inaccurate, you must correct it if they request. Provide a mechanism (e.g. settings page) where users can update their own data. If they request a correction you believe is wrong, you can refuse but must explain why. Document these refusals. Most of the time, the customer is right — update the record and move on.

APP 11: Security of Personal Information

Same as APP 6 but specific to security incidents. If you discover unauthorized access, log the incident, assess risk, notify affected parties, and file a report with the OAIC if required. Have an incident response plan before you need it. Define roles (who discovers, who assesses, who notifies, who logs), timelines, communication templates. A week of chaos after a breach is costly.

APP 12: Access and Correction — Information Available

You must make it easy for customers to request access or correction. Publish a contact email in your privacy policy (privacy@yourcompany.com). Respond within 30 days. Log every request. If you're denying access or refusing a correction, document your reasoning. This creates an audit trail if the OAIC investigates.

APP 13: Complaints Management

You must have a complaints process. A customer files a complaint (privacy breach, data denial, poor handling). You acknowledge it within 1 day, investigate within 30 days, respond with a decision and reasoning. If they're unhappy, they can escalate to the OAIC. Document every complaint and your response. This is low-friction — most customers just want to be heard.

The National Breach Disclosure (NDB) Scheme

The NDB scheme (Australian Privacy Principles Amendment Rules 2018) mandates breach notification. If a data breach is "likely to result in serious harm" to an individual, you must notify them and the OAIC without unreasonable delay. Serious harm is a legal threshold, not a number. One stolen credit card? Probably serious harm. A list of 100 email addresses (assuming no associated secrets)? Probably not. The OAIC publishes a guidance document to help you assess.

Notification timeline: within 30 calendar days of becoming aware of the breach. If you discover on a Friday and email notifications over the weekend, you're fine. If you notice 45 days later, you're not.

What to include in notification: your organization's name and contact, a description of the breach, types of information compromised, likely consequences for the individual, steps you're taking to manage the breach, and recommended action (change passwords, monitor accounts, credit freeze). Be honest. "We were hacked, here's what happened, here's what we're doing, here's how to protect yourself" builds trust.

Implement breach notification automation in your app: a background job that monitors your security monitoring (CloudTrail logs, Supabase activity logs, WAF alerts). If suspicious activity is detected, trigger a manual review and escalate. Have templates ready so you can draft a notification email in hours, not days. A notification sent in 24 hours beats a notification sent in 29 days.

Why Template Privacy Policies Fail

Most founders grab a privacy policy template from iubenda or Termly, plug in their company name, and ship it. Those templates are generic cover-your-ass documents, not compliance artifacts. They fail audits because they don't match your actual practices. Example: the template says "we don't share data with third parties" but you use Stripe (payment processing), Segment (analytics), and SendGrid (email). You just violated your own policy. The OAIC investigates complaints and finds the mismatch — instant credibility damage and enforcement action.

A real privacy policy is written for your product. It lists your exact data flows: "We collect email and payment method at signup (Stripe processing), location data for map features (stored in Supabase ap-southeast-2), and usage logs for product analytics (Segment)." It matches your architecture. It's auditable. It's defensible.

Data Subject Access Patterns in Supabase

APP 9 requires users to request access to their data. Implement a self-service export endpoint. Here's the pattern: authenticated user hits `/api/export-data`, which queries all tables related to that user_id, serializes as JSON, and serves as a downloadable file. Pseudocode:

// /api/export-data (POST)
1. Verify user authentication (check JWT)
2. Query: SELECT * FROM users WHERE id = user_id
3. Query: SELECT * FROM orders WHERE user_id = user_id
4. Query: SELECT * FROM logs WHERE user_id = user_id
5. Query: SELECT * FROM preferences WHERE user_id = user_id
6. Combine into JSON object
7. Return as attachment: Content-Disposition: attachment; filename="my-data.json"
8. Log the request in audit_log table (date, user_id, "data_export")

// For deletion (right to be forgotten):
// After 30-day retention window, hard-delete via BEFORE DELETE trigger or cron job

Most customers export their data once — they want to know you have it and can give it back. The export endpoint also satisfies "proof of compliance" if audited. You have a log of every data export request.

Six FAQs

Does the Privacy Act apply to me at $3M turnover, or only after?

At $3M. The threshold is annual turnover of $3M or more. Once you hit it, all 13 APPs apply retroactively. If you cross $3M mid-year, the APPs apply from that day forward. Plan ahead — start shipping privacy controls before you hit the threshold so you're not scrambling.

What if I'm a US startup serving Australian customers?

The Privacy Act applies if you're targeting Australian residents and collecting their personal information. It doesn't matter where you're incorporated. You're subject to the Act. You must comply with the APPs, notify the OAIC of breaches, and respond to complaints. The OAIC can't fine you, but it can issue enforcement notices. Ignore them and you face Federal Court. If you're serious about the AU market, host data in ap-southeast-2 and build privacy controls into your product.

Is it cheaper to avoid Australian customers than to comply?

Mathematically, no. Compliance (privacy policy, data export endpoint, breach monitoring) costs weeks of engineering. A lawsuit or regulator investigation costs months and legal fees. If you're profitable, compliance is the cheaper bet. If you're pre-product-market-fit, you might not be in scope (if you're under $3M). But plan ahead. Don't discover this requirement mid-growth.

Can I use Supabase (US-based company) to host Australian data?

Supabase is a US company, but you can deploy instances to ap-southeast-2 (Sydney). If you do, data lives in Australia, so you're not breaching APP 8 (overseas transfer). If you deploy to us-east-1, you're transferring data to the US. You must disclose this and ensure the US recipient has data protection measures (Supabase has data processing agreements). Simplest: deploy to ap-southeast-2 if your user base is Australian.

What counts as a "serious harm" breach?

The OAIC provides guidance: stolen credit card numbers, health records, government ID, passwords, or anything that could lead to identity theft, financial loss, or reputational damage. A list of email addresses with no associated secrets is probably not serious harm. A database dump with emails, phone numbers, and addresses is. When in doubt, notify. The cost of notification is low. The cost of a coverup is existential.

Do I need a Data Protection Officer (DPO)?

No. DPOs are a GDPR requirement (EU). Australia doesn't require a DPO under the Privacy Act. But you do need a named contact responsible for privacy compliance. Put it in the privacy policy: "privacy@yourcompany.com, monitored by [name]". When the OAIC has questions, they know who to call.

The Bottom Line

Privacy compliance isn't a compliance checkbox — it's a competitive advantage. Customers trust you more if you handle their data transparently. Regulators respect you if you're upfront. Investors see lower risk. The 13 APPs are digestible rules, not a maze. Privacy policy (match your actual practices). Data export endpoint (APP 9 solved). Breach monitoring (automated alerts). Data retention schedule (delete old logs). Complaint process (respond in 30 days). That's the core. It takes weeks to wire, zero runtime cost, and it positions you ahead of 90% of Australian SaaS.

Building a SaaS product with real Australian customers and privacy is still an open question? Check out Aidxn Design's privacy audit service for a compliance audit and architecture review, or dig deeper into how to balance security and performance in shipping security headers alongside privacy controls.