Personal Data Inventory

The second document is a personal data inventory. It is not a findings report: it is a map of what personal data the platform holds and where each element physically lives, built by reading the code rather than by asking anyone.

The numbers

Two of those rows are the ones to bring to a planning session.

218 of 286 elements have no enforced retention. Not “a retention policy that is too long”, but no mechanism that deletes anything. Data accumulates until someone writes a job.

38 elements are committed into git across at least ten repositories. That is personal data inside the version control history, which means it is in every clone, on every developer laptop, and in every fork. It is the same structural problem as the committed credentials in MGR-H01, MGR-H06 and MGR-H24, and it has the same property: removing the file does not remove the data.

Special-category data: three limbs, and one dominates

31 elements are special-category, and they fall into exactly three groups. The largest by a wide margin is precise location.

Precise location is special-category here because of what the product is. A coordinate paired with a timestamp and an account is a movement record. Ten sources feed it:

1. Sighting coordinates, plus the reverse-geocoded street address derived from them.
2. A coordinate trail table, which role user reads unscoped (MGR-H11).
3. Drop submission coordinates.
4. A 20 Hz device sidecar embedded into a signed provenance manifest. Because the manifest is signed, the location trace inside it is not removable by design: stripping it breaks the signature. This is the single item on this page that a retention job cannot fix.
5. Two committed telemetry fixtures, 584 and 270 samples, in git.
6. A committed coordinate seed of 8 records, one of them at 15-decimal precision.
7. Drop verification coordinate columns.
8. The telemetry batch job’s error stream, which is the only location path in the platform that does not coarsen coordinates before writing them out.
9. Document-store shoot records.
10. Production-to-staging replication, running every five minutes, which copies the whole picture into a lower-tier environment.

The counterweight, and it deserves recording: two code paths coarsen coordinates correctly and deliberately, in the push-notification path and the flight-hint path. The platform knows how to do this. It does it in two places out of eleven.

The 40 protection priorities

The inventory ends with 40 items that need a decision, banded by urgency.

Band A is a ten-item list, not a programme. Treat it as the privacy equivalent of Tier 1 on the fixes page.

What to file

Four epics, and they do not map onto the root-cause epics because this is a different axis of the same estate.

Epic P-1: Retention exists

Today, nothing expires. Pick the elements where retention is a legal or product requirement rather than a preference, define a period for each, and build one deletion mechanism that several elements can share. The mechanism is the deliverable; the periods are a series of small decisions that can land afterwards. Starting with the periods produces a policy document and no code.

Epic P-2: Get personal data out of git

38 elements across ten or more repositories. Sequence it exactly like the credential work: inventory, then stop the bleeding, then clean up. Add an ingest check that fails a commit adding a fixture with real coordinates or real contact detail, so the count stops growing while you work through the existing 38. Note that the fixtures are the easy half: a fixture can be regenerated with synthetic data, which a production record cannot.

Epic P-3: Coarsen by default on the location paths

Nine of eleven location paths keep full precision. Two coarsen. Invert the default: coarsen at the boundary, and require a specific, named reason for any path that keeps full precision. The batch job’s error stream is the clearest single fix, because it is the only path that does not coarsen and it writes to a log.

The signed manifest sidecar is the hard case and needs a product decision rather than a code change: either stop embedding a 20 Hz trace in a signed artifact, or accept that those artifacts carry a non-removable movement record and say so where the artifact is produced. Do not let this one item block the other eight.

Epic P-4: Assert encryption at rest where it matters

85 elements have no encryption at rest asserted in code. That phrasing is deliberate and it caps what you can conclude: a provider-level default may well be encrypting several of these, and the inventory could not see that from source. The first ticket in this epic is a read-only inventory against the live accounts, which will convert most of the 85 into evidenced negatives and leave a much shorter list of real gaps. Filing 85 tickets before that lookup would waste most of the effort.

The one that crosses over

Production-to-staging replication every five minutes is on this page and it is also the thing that makes several findings on the weaknesses page worse than they look. A weakness in a development or staging environment is usually bounded by that environment holding less interesting data. Here it does not, because the data is copied in every five minutes. See Q-6, which asks the direct version of this question and is worth answering early.