Data minimization

Metadata only

1. Define task. L101 only needs to record who exported which file, when, and with what result. No export or stored log exists yet. The source contains driver D101, homeAddress 10 Example Lane and clearance eligible, all synthetic. The exercise defines L101’s purpose as actor, file, time and result. The two paths start independently with the same retained R101 and no earlier log. Approval for the staffing export is an explicit assumption; these four fields are not asserted to satisfy every possible investigation.
2. Build export. The authorized staffing export creates X101 with the same roster row. R101 stays unchanged; the log is still absent. The fixture makes an independent copy for the same approved staffing recipient in both paths. It does not remove the address or clearance from the staffing record. X101 exists only after the copy operation completes. Changing what the event log retains is separate from changing the legitimate export itself.
3. Write log. L101 stores actor, file, time and result. It leaves the roster payload out of this new event record. The stored object is {actor: Kael, file: R101, time: 2026-09-30T09:00:00Z, result: exported}. It contains exactly those four keys and no homeAddress, clearance or nested source row. The alternate stores the same metadata plus a record field containing the entire roster row. Both copies of the source remain unchanged. Logging is a new data-processing action; no existing full-row log is retroactively cleaned up.
4. Read log. An independent read returns the four metadata fields without the home address or clearance flag. The staffing export still works. GET /logs/L101 returns HTTP 200 with actor, file, time and result in the minimized path. The comparison returns those keys plus the full record payload. A separate read of X101 still returns the original staffing row in both runs. The minimized log documents the defined event without making another payload copy. This verifies newly stored content only; retention limits, earlier copies, permitted reuse and privacy/legal review remain unfinished.

Metadata + whole row

1. Define task. L101 only needs to record who exported which file, when, and with what result. No export or stored log exists yet. The source contains driver D101, homeAddress 10 Example Lane and clearance eligible, all synthetic. The exercise defines L101’s purpose as actor, file, time and result. The two paths start independently with the same retained R101 and no earlier log. Approval for the staffing export is an explicit assumption; these four fields are not asserted to satisfy every possible investigation.
2. Build export. The authorized staffing export creates X101 with the same roster row. R101 stays unchanged; the log is still absent. The fixture makes an independent copy for the same approved staffing recipient in both paths. It does not remove the address or clearance from the staffing record. X101 exists only after the copy operation completes. Changing what the event log retains is separate from changing the legitimate export itself.
3. Write log. L101 stores the same event metadata plus the whole roster row. The log now has another home-address and clearance copy. This path stores the same actor, file, time and result metadata plus a record field containing R101’s whole synthetic row. L101 now has five top-level keys, including another homeAddress and clearance copy inside record. Those personal values are unnecessary for the log’s stated four-field event purpose, although they remain needed in the assumed staffing record. The metadata-only path leaves record out. Both R101 and authorized X101 remain unchanged. This creates a fresh log; no earlier full-row log is deleted or retroactively minimized.
4. Read log. An independent read returns the event metadata and the whole sensitive row. The staffing export is unchanged, so that extra log payload was unnecessary here. GET /logs/L101 returns HTTP 200 with actor, file, time and result in the minimized path. The comparison returns those keys plus the full record payload. A separate read of X101 still returns the original staffing row in both runs. The minimized log documents the defined event without making another payload copy. This verifies newly stored content only; retention limits, earlier copies, permitted reuse and privacy/legal review remain unfinished.

The four fields are sufficient for this defined exercise, not every investigation. Actor and time are controlled fixture inputs, not independent attribution or tamper-proof evidence. Original R101 and authorized X101 still contain personal data. Collection, future reuse, existing copies and retention need separate decisions; this log change does not finish privacy work.

Flow references: NIST Privacy Framework 1.0: processing risk and minimized logs · NIST SP 800-53 Rev. 5: processing purposes and security attributes