Masking Actor Identity in Published Lineage

Part of: Access Control and Redaction for Lineage Records

Provenance models name agents, and agents are frequently people. A lineage record saying that a named surveyor edited a parcel boundary on a given afternoon is personal data, it is an employment record, and published unchanged it is a disclosure nobody agreed to. This how-to masks actor identity in published lineage while keeping the accountability that made recording the actor worthwhile in the first place.

The tension to hold: accountability requires knowing who; publication requires not saying. Both are legitimate and the resolution is not to stop recording actors — it is to separate the internal record, which names them, from the published view, which does not, with a controlled path between the two.

Prerequisites

  • Actors recorded as identifiers rather than as free-text names, per Access Control and Redaction for Lineage Records.
  • A separation between the internal store and the published view.
  • A stated lawful basis and retention period for the actor data.
  • A process for re-identification requests, with an approver.

Record the Role, Publish the Role, Keep the Person

The single design move that resolves most of this is separating the two facts that a name currently carries.

Split the actor into a role and a controlled identity The published record carries a role and an opaque token; the mapping from token to person is held separately with its own access control and retention. INTERNAL RECORD actor: staff:4471 (A. Lindqvist) role: surveyor, cadastral team action: boundary amendment PUBLISHED RECORD actor: agent-7f2c (opaque token) role: surveyor, cadastral team action: boundary amendment MAPPING TABLE — agent-7f2c → staff:4471 · separate store, separate access, separate retention Re-identification is a request against this table, logged, approved, and time-bounded. The role is what most readers actually need. The name is what almost nobody needs and everybody stores.

The italic line is the observation that makes this easy to sell. Nearly every legitimate use of the actor field is satisfied by the role — was this change made by someone qualified to make it, by an automated process, by an external contributor? — and the individual’s name adds nothing to those answers.

Keep the token stable per person, not per record. A token that changes every time destroys the ability to see that the same actor made a related sequence of changes, which is a genuine analytical use, and it does not improve the protection meaningfully.

Delete the mapping when the retention period for the personal data expires, leaving the lineage record intact. The provenance survives; the personal data does not, which is exactly what a retention obligation asks for and what deleting the whole record would fail to achieve.

Pseudonymisation Is Not Anonymisation

The distinction is legal as well as technical and getting it wrong misstates the obligation.

A record with an opaque token and a mapping held anywhere is pseudonymous, not anonymous. It remains personal data, the retention and access obligations still apply, and a published dataset carrying such tokens has not escaped them.

The published record becomes anonymous only when re-identification is impossible for anyone — which in practice means the mapping is destroyed. Until then, treat the tokens as personal data in every assessment.

Say which one you have in the documentation. A system described as anonymising when it pseudonymises will fail a review, and the failure will be about the description rather than about the engineering, which is a frustrating way to fail.

The Re-Identification Channel Needs Ceremony

An actor mapping that any engineer can query is not a control, and the ceremony around it is the point rather than an obstacle.

The re-identification path A request with a stated reason, approved outside the requesting team, granted for a bounded period, and logged where the data protection function can see it. request with a stated reason approval outside the team grant one token, 24 hours log visible to DP function One token per request — never a bulk export of the mapping. A bulk grant recreates the unprotected table it was meant to replace. A rate of zero requests per year means the mapping is not needed. Review it, and consider destroying the mapping to move from pseudonymous to anonymous.

The bottom block is worth acting on rather than merely noting. Many organisations discover that the actor mapping has never been consulted, at which point holding it is pure risk with no realised benefit, and destroying it upgrades the entire published corpus from pseudonymous to anonymous at a stroke.

Approve outside the requesting team. Self-approval within a team makes the control procedural rather than real, and it is the first thing a reviewer tests.

Grant one token at a time. A request for “the mapping for last quarter’s edits” is a bulk export wearing a request form, and it should be refused by design rather than by judgement.

Retention for the Mapping, Not for the Lineage

The two have different clocks and running them on one schedule fails one obligation or the other.

Lineage retention is usually driven by how long the products it describes remain in circulation, which can be decades for cadastral or environmental records. Actor retention is driven by employment and data-protection rules, which are typically measured in a small number of years. Applying the longer period to both keeps personal data far past its basis; applying the shorter to both destroys provenance that is still needed.

Separating the mapping table is what makes two clocks possible. The lineage record keeps its token forever; the mapping row expires on its own schedule, after which the token is permanently unresolvable and the record has become genuinely anonymous rather than merely pseudonymous.

Record the expiry date on the mapping row rather than computing it from the lineage record’s date. The obligation attaches to when the personal data was collected, and a record amended years later should not restart the clock on the person named in the original.

Log the deletions. A mapping row expiring is a data-protection event worth being able to evidence, and a count of expiries per month is the cheapest demonstration that the retention policy is actually running rather than merely written down.

Automated Actors Need Care Too

Service accounts feel safe to publish and frequently are not.

An account named after the person who created it, or a personal credential used by a scheduled job, carries an identity into every record it touches. Audit the actor values actually present rather than assuming the automated ones are impersonal.

Publish the service identity, not the credential. A record naming the credential that ran a job discloses part of the authentication surface, and rotating that credential then makes historical records inconsistent.

Where an automated action was initiated by a person — a manually triggered rerun — record both, and mask the person under the same rule as any other actor. The initiator is the accountable party and is also personal data.

Publish the Rule, Not the Exceptions

A masking scheme that is applied inconsistently is worse than none, because the inconsistencies are what identify people.

Exceptions in a masking rule identify what is masked Uniform masking reveals nothing; a rule that exempts some categories makes the masked records a labelled minority. UNIFORM RULE agent-7f2c · surveyor agent-91ab · surveyor agent-3d04 · reviewer agent-be77 · contractor nothing distinguishes any row RULE WITH EXCEPTIONS A. Lindqvist · chief surveyor agent-91ab · surveyor M. Adeyemi · head of review agent-be77 · contractor the masked rows are now a labelled set Exceptions usually arrive as "senior staff are happy to be named". Their consent does not extend to narrowing who the remaining tokens could be.

The consent point in the caption is the argument that settles this in practice. An individual can consent to their own name being published; they cannot consent on behalf of the colleagues whose anonymity their exception erodes, and framing it that way usually ends the request.

Publish the rule itself so that readers know masking was applied uniformly. A published record with no explanation of the tokens invites readers to guess, and some will guess correctly.

Apply the rule at the point of publication rather than at the point of recording, so the internal record keeps its accountability value. Masking on write throws away the thing you were storing the actor for.

Re-run the rule over previously published exports when it changes. A corpus published under two rules can be aligned by anyone holding both, and the older, weaker export governs.

Verification

Assert no personal identifier appears in a published export by scanning a fixture that contains one in every actor field, and confirming the published output contains none of them.

Assert token stability by publishing the same actor’s records twice and confirming the token matches, then confirming two different actors never share one.

Assert mapping deletion leaves records intact: delete a mapping entry and confirm the lineage record still validates and still carries its role.

Assert the bulk-request refusal by requesting more than one token in a single call and confirming it is rejected rather than fulfilled.

Gotchas & edge cases

  • Free-text fields carry names. A change-set note reading “corrected after A. Lindqvist’s site visit” defeats every structural control. Scan text fields, or do not publish them.
  • Small teams are identifying. A role of “the only hydrographer” is a name. Where a role has one holder, publish a coarser role or suppress the field.
  • Timing patterns identify people. Edits clustered in one person’s working hours, or absent during their leave, re-identify them across a corpus. Round timestamps in published records.
  • The token must not be derived from the name. A hash of the employee identifier is reversible by anyone with the staff list. Use a random token stored in the mapping.
  • Subject access requests reach lineage. A person may ask what records name them, and the mapping is what makes that answerable. Destroying it removes the personal data and also the ability to answer — decide which obligation dominates before acting.