← All privacy impact assessments

PIA: <feature name>

Status: Draft — gates <workstream> / Current / Retrospective Written: YYYY-MM-DD · Author: <who> · Issue: #NNN Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).

Delete any heading that has nothing to say, and say so in one line rather than padding it. A four-line assessment for a feature that turns out to be boring is a success, not a failure.

1. Purpose and scope

What the feature is for, in the terms a user would use. What is in scope for this assessment and — importantly — what is out of scope and covered elsewhere.

If the answer to "why are we building this" is not one sentence, the design is not finished.

2. Data involved

• Kind — the actual columns and objects, named. Not "user content".
• Whose — the member's own, another member's, a child's, a non-user's (a guest, a contact, another group's member).
• Children's — is this personal information about someone under 18, whether or not they hold an account? A baby's feed log is a child's personal information; so is a photograph of a nine-year-old posted by their parent.
• Sensitive — health information, and anything the Privacy Act treats as a sensitive category. Say why, not just yes.
• Free text — a field a person types into is a field that can contain anything, including the categories the schema was designed to avoid. Name every one.

State plainly what is not collected and could have been. That is usually the most useful row in the table.

3. Flows and locations

Where each kind of data physically goes. Be specific about the boundary crossings, because those are the ones that carry obligations.

• Which reads and writes happen on the device and never leave it.
• What is stored at rest, in what form (plaintext / sealed / hashed), and under whose keys.
• What reaches a model, from which surface, under which consent, and in which region — a global endpoint means processing anywhere the provider chooses (see docs/privacy_posture.md §8 and the AI Model Strategy table in AGENTS.md).
• What reaches a log, and what a log retains after an erasure (AGENTS.md → Identifiers In LOGS Are Data An Erasure Cannot Reach).
• What crosses a group boundary, and to whom.

4. Legal basis and consents

Which consent purposes from the ledger (#219, WS2) this feature relies on — the closed list is terms, baby_summary_to_model, assistant, voice, on_device_brief, read_receipts, dish_photo_moderation, cross_group_events, improve_app_traces, overseas_processing. The ledger is planned, not built; until it ships, say which switch column carries the current state and note that no consent act is recorded.

For each purpose: who gives it (self, a guardian, an admin on the group's behalf), what they are told at the moment they give it, how they withdraw it, and what happens when it expires at twelve months (exposure draft ss 15–16). Consent must be voluntary, informed, current, specific and unambiguous, and must not be bundled (s 14(3)(b)).

Where a guardian consents on a child's behalf (s 13), record what the child is told.

5. Risks and mitigations

One row per risk that is specific to this feature. A risk that applies to the whole app belongs in docs/privacy_posture.md, not here.

Write the risk as a sentence about a person, not a category: "a parent's separated ex-partner, still a member of the group, reads a log entry about a medical appointment" beats "unauthorised access".

6. Structural versus conventional

The section this template exists for. Two columns, and everything in the design goes in one of them.

• Structural — enforced by RLS, a foreign key, a CHECK constraint, a trigger, a unique index, the absence of a grant, a key that does not exist on the server, or a string comparison that runs before any model does. A property the database or the cryptography can prove. It survives a careless PR.
• Conventional — enforced by copy, by a code review, by a comment, by a test that a future agent could delete, or by everyone remembering. Legitimate, often the right trade, and always the thing to name, because the next reader will otherwise assume it is structural.

A test that pins a conventional property (a source scan, a copy assertion, a mutation-tested guard) sits between the two: it is not proof, but it fails loudly. Say so.

If a property is claimed in user-facing copy, it must be at least test-pinned. A promise held up only by good intentions is the class of thing lib/__tests__/aiTransparency.test.ts exists to catch.

7. Best interests of the child

Required where children are involved (exposure draft s 10). Not required where they genuinely are not — say which, and why.

This is not a paragraph about how much we care. It is reasoning that could be disagreed with:

• What does this feature give a child that is good for them?
• What does it cost them — in exposure, in autonomy, in a record that outlives their interest in it?
• What would the safer design have been, and why was it not chosen?
• Where the interests of the child and of the parent diverge, whose won, and why? (A tracker that helps an exhausted parent and a child who will one day be an adult with a permanent record of their infancy is the standing example.)
• What does the child get told, at an age-appropriate level, about what the adults around them can see (the s 33 posture)?

8. Residual risk accepted by the owner

The risks that are real, are not mitigated, and are being lived with. Each one in the owner's terms, with the reason.

An empty section here is nearly always a sign the assessment is not finished. Every design has something in it.

9. Review trigger

The specific event that means this document is re-read — not a date. "This table gains a column", "this surface starts sending data to a model", "the absence this argument leans on stops being true", "the feature ships and the retrospective replaces the draft".

The two triggers in the register's README (Code registration; sign-up opening) apply to every assessment and need not be repeated.

10. Checklist against exposure draft s 38(2) (verified 2026-09-08)

The Code lists what a privacy impact assessment must contain. Say where each is answered:

s 38(3): conducted before the service or change is made available. s 39: listed on the published register.

11. Sources

Primary sources, with links. Where a primary source could not be reached, say so and say what was used instead. Do not cite third-party summaries or benchmark sites for a legal proposition.

In-repo sources count and should be named by path: the migration, the test that pins the property, the module the copy is rendered from.