Privacy requests: destruction, complaints and escalation

Read this before a request arrives, not while one is sitting in the inbox. It exists because the Children's Online Privacy Code (ss 32, 36) requires a formal destruction-request channel and a child-friendly complaints process with an anonymous option — see issue #228 and docs/privacy_posture.md §4.2. At current scale (one owner, ~10 users) this is a support email plus a documented process, not a ticketing system.

The channel is privacy@brendanpatch.com. How that mailbox is wired up (a Proton address, filed by a filter into one folder) is a separate document — docs/runbooks/privacy-mailbox.md — because setting it up once and working a request are different jobs read at different times.

What exists today vs what is planned

This procedure has to work against the app as it actually is, not the app the encryption plan describes. Two things are still planned, not built, and are marked as such everywhere below:

• End-to-end encryption of chat, photos and baby notes (docs/encryption_plan.md). Today none of that content is end-to-end encrypted. It sits in a database access-controlled by Row Level Security, and — at this app's current scale — the owner, as the person who operates it, is technically able to look up a specific row if a request genuinely needs it and cannot be actioned any other way. That is stated here plainly rather than left to be discovered, because AGENTS.md is explicit that this app must never claim an encryption property the code does not have.
• Child accounts (WS8, shipped 2026-09-08 — 20260908043933, docs/pia/child-accounts.md). A person aged 13–17 may hold an account in a group, created by an adult member who declares the age (allowed_emails.child_of + birth_month, carried into child_guardians and user_birth_months when they sign up). So "a request made by or about a child" now has two shapes: a child asking about their OWN account — which they may do themselves, and their in-app page ("What your parent can see", app/child-privacy.tsx) tells them this address and that a complaint needs no name — and a parent or guardian asking on behalf of a child under 15 (the guardian is a child_guardians row, readable with the service role). A guardian's own erasure is REFUSED while a dependant under 18 names them (delete-account returns 409 and says so); a child's erasure goes through the ordinary path and cascades their links. The Baby Tracker case below is unchanged.

Once end-to-end encryption ships for a given content type, the "technically able to look up a specific row" sentence above stops being true for that type, and the in-app self-service routes below (poster/admin deletes a photo, sender deletes a message) become the only way a specific item can be removed — nobody at GroupApp will be able to identify which photo or message a request is about. This procedure is written to work in both states without needing a rewrite: follow the self-service routes first regardless, and treat "we can look it up directly" as a fallback that already has a use-by date.

Who may ask

• A user, about their own information — access, correction, export, deletion, or destruction of something specific they hold. Corresponds to Code s 32.
• A parent or guardian, on behalf of a person under 15 — the Code (s 32) and the Privacy Act's general guidance both route consent and destruction requests for a person under 15 through a parent or guardian. In practice this means a parent asking about their baby's Baby Tracker records, or — since WS8 — a guardian asking about a child account they created; a child of any age may also ask about their own account themselves (s 32(1)(b), s 36(1)(c)).
• Anyone, anonymously, for a complaint — Code s 36 requires a child-friendly complaints process with an anonymous option. A complaint doesn't have to name an account or identify a specific item; "I think GroupApp handled something badly" is a complete complaint. A destruction request is different — see below — because acting on it requires knowing what to destroy, which an anonymous requester cannot practically supply.

How

Email privacy@brendanpatch.com. There is no other channel today — no in-app request form, no phone line. The address is named in the privacy policy and on the in-app "What the assistant can see" page (constants/legalTexts.ts, constants/aiTransparency.ts).

What we do on receipt

1. Acknowledge within 3 business days. A short reply confirming the request has arrived, who is handling it (the owner — there is no support team), and that a full written response follows within 30 days.
2. A 30-day clock to a written response, from the date the request was received. This is the Code's own figure (ss 32, 36) and matches what the existing privacy policy already promises for access/correction/erasure requests.
3. Refusal reasons are given in writing, using the template below, whenever any part of a request is not actioned.
4. Escalation to the OAIC is named as an option in every substantive response — the Office of the Australian Information Commissioner, https://www.oaic.gov.au/privacy/privacy-complaints. Naming it is not an admission that the response was wrong; it is what the Code and ordinary good practice both expect.

Working a request: the owner's checklist

1. Label the thread privacy request or complaint in Proton Mail (docs/runbooks/privacy-mailbox.md). The tag and the thread itself are the record — there is no separate log to keep in step, and keeping one would mean holding a second copy of whatever personal information the request contains.
2. Acknowledge within 3 business days (see above).
3. Work out what's actually being asked. In rough order of how often each comes up:
   • Whole-account deletion — point them at "Delete my account & data" in the app's Settings. It is immediate and self-service; there is normally nothing for the owner to do by hand.
   • A specific item — a photo, a chat message, a Baby Tracker entry. Work out who can act on it directly (the table below) and tell the requester exactly how, in the app's own words.
   • Correction of inaccurate data — most fields are editable in-app; point at the relevant screen. A field that genuinely cannot be edited by the user is worth noting in the PIA register as a gap, not just fixed one-off by hand in the database.
   • Export — "Download my data" in Settings, self-service.
   • A general complaint about how information was or wasn't handled, with no specific item named. Read it, respond honestly, and say what (if anything) will change.
4. If a request needs support to act because the requester genuinely cannot (for example: the photo's poster has left the household and no admin remains active, or the requester cannot use the app themselves) — see "Who can act on a specific item" below for what is and isn't possible today, and say so plainly rather than promising a capability that doesn't exist.
5. If any part is refused, use the template below. State the specific reason — do not send a form refusal with no reason, which is exactly what s 32/36 exist to prevent.
6. Send the written response within 30 days of receipt, naming the OAIC as an escalation option.
7. Leave the final reply in the thread. The thread, tagged, is the whole record — there is nothing else to update.
8. Watch the saved search for privacy-tagged mail older than 20 days (set up per the mailbox runbook) as the early warning that the 30-day clock is running out on something still open.
9. If the same kind of request keeps recurring and the app has no in-app way to satisfy it, that's a product gap, not an indefinite manual-support burden — note it against the PIA register or as a new issue, rather than quietly repeating the same by-hand fix every time.

Who can act on a specific item, and how

This is the part that must be told to the requester in the reply, not just known internally.

If the person who can act (the poster, the sender, an active member) is unwilling or genuinely unreachable — for example an estranged parent who posted a photo of a child and will not remove it — say so plainly rather than promising a workaround. Today, because content is not yet end-to-end encrypted, the owner can look up and remove a specific row directly as a last resort; this is a manual one-off action recorded in the request thread (there is no separate log, and keeping one would hold a second copy of the request), not a standing capability, and it stops being available once end-to-end encryption ships for that content type (see "What exists today vs what is planned" above). At that point the honest answer for an unreachable poster becomes: ask another admin, or the group as a whole, or — if the content genuinely cannot be removed by anyone in the household — leaving the group is the remaining option, and that should be said rather than implied.

Refusal template

Use this whenever any part of a request is refused, in whole or in part. Fill in the brackets; do not send a refusal with no stated reason.

Subject: Re: your request of [date]

Hi [name],

Thank you for your request on [date] regarding [what was asked]. I've looked into this, and I'm not able to [action] in full, because [specific reason — e.g. "this message can only be deleted by the person who sent it, and I don't have a way to do that on their behalf" or "this would also remove records that other members of your household rely on, and it isn't mine alone to remove"].

What I can do: [alternative, if any — e.g. "ask an admin of your group to remove the photo", "correct the specific field you flagged", "delete your own account and data in full"].

If you're not satisfied with this response, you can make a complaint to the Office of the Australian Information Commissioner: https://www.oaic.gov.au/privacy/privacy-complaints.

[Owner's name] privacy@brendanpatch.com

What this procedure does not cover

• Reports of inappropriate content (a photo, a review) already have their own in-app report flow, which goes to the group's own admins for the photo wall (AGENTS.md § "The Photo Wall") or to the automated moderation checker for public reviews. This procedure is for privacy requests and complaints specifically, not content moderation.
• Requests about the age-restricted social media ban or the under-16 child-account design belong to that programme of work (docs/privacy_posture.md §5, issue #282), not this one — if one arrives here, forward it into that work rather than answering it as a standard destruction request.