Personal data, properly

Security and spend covered the technical controls — keeping secrets out of your repo, turning on row level security, not trusting the browser. This page is the other half: the obligations that come with holding information about real people, and a practical program you can actually run alone.

What counts as personal information

Much more than founders expect. If it can reasonably identify someone, on its own or combined with something else, it counts:

• Name, email, phone, address — the obvious ones
• IP addresses, device identifiers, cookie IDs, session data
• Photos, voice recordings, anything user-uploaded
• Free-text notes about a person — including the ones your users type about their customers
• Behavioural data tied to an account: what they clicked, when they logged in

A smaller, stricter category gets special treatment nearly everywhere: health and medical information, biometrics, racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal record, and in some places financial detail. If your product touches any of these, the bar rises sharply and you should get advice early rather than late.

Which law applies to you

The thing that catches Australian founders out: privacy law follows the user, not the business. Being in Melbourne doesn't exempt you from European rules if you have European users. In practice, if you're an Australian product with any international customers, assume two or three regimes apply at once — and design for the strictest.

The Australian small business exemption — and why not to rely on it

Businesses with annual turnover of A$3 million or less are generally exempt from the Privacy Act. That sounds like it covers you, and today it might. Four reasons to behave as though it doesn't:

1. The exceptions are broad. They include health service providers, anyone trading in personal information, contractors to the Commonwealth, and businesses related to larger entities. Plenty of small startups fall into one without realising.
2. It's under active reform. Australian privacy law has been through a significant round of amendment, with further tranches flagged — narrowing or removing this exemption has been repeatedly on the table. Building a business on an exemption that's expected to shrink is a poor bet.
3. It doesn't touch GDPR. One European user and you're in scope there regardless of your turnover.
4. Customers don't care about the exemption. The first serious business customer will send you a security and privacy questionnaire. "We're legally exempt" is not an answer that wins deals.

What they all want, in plain terms

The regimes differ in detail and agree almost entirely on substance. If you do these six things you are most of the way there under any of them:

1. Collect less. Only what you actually need, for a purpose you can state. Every field you don't collect is one you can't leak, can't be asked for, and don't have to protect.
2. Tell people, before or when you collect. What you take, why, who else sees it, where it goes, how long you keep it, and how to contact you. That's your privacy policy's job.
3. Use it only for what you said. Data collected to deliver a service isn't automatically yours to market with, sell, or feed into a model.
4. Secure it proportionately. More sensitive means more protection. This is where the technical controls become a legal obligation rather than good practice.
5. Let people see it, correct it and — in Europe and the UK — delete it. Which means you need to be able to actually do that.
6. Report breaches, fast. Know your clock before you need it: 72 hours in the EU and UK.

Where your data physically is

Sending personal information overseas is regulated in all three regimes — Australia's APP 8 holds you accountable for what an overseas recipient does with it, and the EU and UK restrict transfers to countries without adequate protection.

You will do this immediately and by accident: your host, your database, your email sender and your analytics are all likely to be US companies. Three practical steps:

• Choose Sydney regions where offered. Supabase asks at project creation and can't change it later. This is the single highest-leverage decision on this page.
• Know your subprocessors. Keep a list: every service that touches personal data, what it holds, and which country it's in. Your first enterprise customer will ask for exactly this list.
• Disclose it. Your privacy policy should say that data may be handled overseas, and roughly where.

The program, for one person

Half a day, and you're ahead of most seed-stage companies.

1. Write down what you hold

One page. Every kind of personal information in your product: what it is, why you have it, which table it's in, who can see it, how long you keep it, and which third parties get a copy. Everything else on this page depends on having this.

2. Delete what you don't need

Go through it and cut. Do you need date of birth, or just "over 18"? Full address, or postcode? Phone number at all? Each deletion permanently reduces your risk.

3. Make deletion actually work

"Delete account" must delete, not hide. Consider the copies: backups, logs, your email provider, your analytics, your error tracker. Being able to say "we delete within 30 days including backups" is both an honest answer and a good one.

4. Set retention periods

Keeping everything forever is a liability, not an asset. Decide how long each kind of data lives, and automate the deletion.

5. Lock down your own access

Who can read the production database? Right now that's you — keep it that way, and don't pull production data onto your laptop "just to check something". When you add a contractor, give them development data, not real records.

6. Write a breach playbook before you need one

One page in docs/: who you call, how you'd work out what was exposed, how you'd stop it spreading, the notification clocks, and a draft of what you'd say. At 2am with your heart racing is not when you want to be reading legislation.

Other jurisdictions

This page covers Australia, the EU and the UK because that's where most Australian products' users are. If you have customers elsewhere, the same shape of law usually applies with different names, thresholds and deadlines — New Zealand's Privacy Act, Canada's PIPEDA, Singapore's PDPA, and a growing patchwork of US state laws including California's, several of which reach businesses well outside their borders.

Check the rules where your users actually are, not just where you are. The practical answer is almost always the same — collect less, say what you do, secure it, delete on request, report breaches quickly — but the deadlines and thresholds differ, and those are the details that bite.

Act as a privacy analyst. Read this project and build me a data inventory — I'm a solo founder and I've never done this.

For every piece of personal information the app collects or stores, give me a table row with:
1. What it is, and which database table and column it lives in
2. Why the app collects it (based on how it's actually used in the code — and flag anything collected but never used)
3. Who can read it: which users, which roles, and whether row level security actually enforces that
4. Which third-party services receive a copy, and which country each stores it in
5. How long it's kept, and whether anything deletes it
6. Whether it would count as sensitive information under Australian, EU or UK law

Then tell me:
- What I'm collecting that I could stop collecting entirely
- Anything a user could not currently get deleted if they asked
- Anything that would be hard to explain in a privacy policy

Save it to docs/data-inventory.md.

Trace what would happen if a user asked me to delete their account and all their data.

1. Follow the deletion path through the code, if one exists, and tell me exactly what it removes.
2. List everything that would be LEFT BEHIND: other tables, rows referencing them, logs, error-tracking records, analytics, email provider records, backups, cached data, uploaded files.
3. Tell me which of those I'm legally expected to remove under Australian, EU and UK rules, and where deletion can legitimately be deferred — backups in particular.
4. Show me what a complete, honest deletion flow would look like for this app.
5. Tell me what I should say in my privacy policy about deletion timing, so that it's both accurate and achievable.

Be blunt if the honest answer is "you cannot currently delete a user properly".

A business customer has asked about how we handle their data. Based on this project's actual architecture, draft honest answers to the questions they'll ask:

- Where is our data physically stored, and in which country?
- Who at your company can access it?
- Is it encrypted in transit and at rest?
- What third parties does it pass through, and where are they?
- How do you back it up, and have you tested a restore?
- What happens to our data if we leave?
- What's your process if you have a data breach?
- Do you use our data for anything other than providing the service, including training AI models?

For each: give me the truthful answer based on the code and infrastructure as it actually is, flag where the honest answer is weak, and tell me what the cheapest fix would be. I want to improve the real answers, not learn to phrase bad ones well.

Based on this project's actual data handling, draft the content a lawyer would need to produce a privacy policy for me — an Australian business with users in Australia, and some in the EU and UK.

Cover: what's collected and why, the legal basis for each use, who it's shared with, where it's stored and transferred, how long it's kept, individual rights under Australian, EU and UK rules, how someone contacts me, and how I handle complaints.

Be explicit about anything I'd have to fix before I could truthfully make these statements — for example if I claim data is deleted within 30 days but nothing actually deletes it.

Make clear this is a starting point for a lawyer to review, not a finished policy.