Consider the artifact first. An analytics dataset, documented in your data catalog as pseudonymised. Its mapping table — the lookup that links pseudonyms back to real identifiers — sits in an adjacent schema inside the same warehouse. Eleven administrators have read access to both. A single JOIN query reconnects them in under a second. Nothing has been breached. No control has failed in any formal sense. The transformation record says the dataset is protected. The access-control record does not exist.
That gap is the problem this article addresses. The protective effect of de-identification does not live in the transformed dataset. It lives in the controls governing the mapping. When those controls are filed under "data transformation" rather than "access management," they fall out of every process that would otherwise re-test them: access review cycles, privileged access management audits, joiner-mover-leaver workflows. The dataset stays documented as safe while the protection quietly degrades.
The argument here is precise: this is not a claim that de-identification fails. It is a claim about where the protection is located and therefore what governance category must own it.
The dataset that was safe and reversible in one query
Pseudonymisation replaces direct identifiers with tokens or codes, preserving analytical utility while allowing re-identification through a mapping that must be kept separately. The separation between the de-identified copy and the mapping is the mechanism by which the protection is supposed to work.
In practice, the separation often exists only at the schema level. When the de-identified dataset and its mapping table live in the same warehouse, under the same administrative boundary, the logical separation does not constitute a meaningful access boundary. An administrator with read privileges on the warehouse can query both objects. So can an analytics engineer who has been granted broad access for a project that concluded two quarters ago.
The re-identification risk does not require a sophisticated attacker. It requires a JOIN. The mapping table is a privileged credential in functional terms: whoever can read it can reverse the transformation. That is the right mental model. A mapping table held adjacent to its de-identified dataset, under shared administration, is equivalent to a password hash file stored next to the service it authenticates — the transformation exists, but the protection it implies does not.
This is the condition under which the hypothesis holds: the mapping is accessible to the same population that can read the de-identified copy. Where a programme holds the mapping in a genuinely separate domain — different warehouse, different administrative tier, hardware-isolated, with distinct approval chains — the protection shifts toward the data architecture. That separation is not the common case; it is the goal that access controls are meant to enforce.
What the transformation establishes
NIST SP 800-188 establishes that organisations must identify all locations where sensitive data is stored before applying de-identification controls, and that an incomplete data inventory produces partial de-identification — where untreated copies of the original data remain sensitive even when the primary dataset is treated (Source: csrc.nist.gov, https://csrc.nist.gov/pubs/sp/800/188/final). The guidance is load-bearing for this argument in a specific way: removing direct identifiers does not by itself prevent re-identification, and the standard requires that organisations identify the risks involved. It does not certify that any particular transformation achieves a defined protection level. That assessment remains the organisation's responsibility.
What the transformation record establishes is the technical operation that was performed: which fields were replaced, by which method, at what point in the pipeline. It is a fact about the data's history. It is not a statement about the current access posture of the mapping.
The transformation record does not update when an administrator is added to the warehouse role. It does not flag when the mapping schema is moved into the same database as the de-identified copy during a consolidation project. It does not reflect that the original dataset was replicated to a development environment where the pseudonymisation was not applied. The record is static; the access posture is not.
Treating the transformation record as the primary evidence of protection can create a gap in programmes that rely on periodic data-protection attestations. The attestation process tends to ask "was this dataset de-identified?" rather than "who can currently read the mapping, and is that population reviewed?" The first question has a stable answer. The second has a current one.
Where the protection actually lives
The protection lives in four properties of the mapping's access posture. None of them appears in a transformation record. All four are access-control questions.
The parallel to key custody is precise. Key custody concerns who can access the material that makes an encryption control reversible. The same logic governs mapping custody: the mapping is the material that makes pseudonymisation reversible, and the controls on it determine whether the transformation is protective or merely documented. Filing those controls under transformation records rather than access management removes them from privileged access audits and from the identity lifecycle processes that would otherwise catch them.
Access reviews, PAM programmes, and joiner-mover-leaver workflows are triggered by access-control classifications. A protection recorded only in a transformation log is not visible to any of those processes. It does not get re-tested at the next quarterly access review. It does not get revoked when the analyst who needed it moves to a different team. It does not get escalated when an administrator account is deprovisioned late. The classification error is not cosmetic — it determines which operational processes see the control and which do not.
The four controls that carry it
| Control | Category it is filed under | Category that governs it | Re-tested by | What happens if it lapses |
|---|---|---|---|---|
| Read access to the mapping table | Data transformation record | Access management | Periodic access review, PAM audit | Any warehouse user with broad grants can JOIN the mapping to the de-identified copy and reverse the transformation |
| Audit logging of mapping reads | Monitoring configuration | Privileged access monitoring | SIEM alert tuning review; log-source validation | Re-identification queries run silently; no detection signal is generated |
| Isolation of the mapping from the de-identified copy's trust domain | Architecture documentation | Access boundary governance | Joiner-mover-leaver review; infrastructure access audit | Administrators of the de-identified dataset automatically inherit access to the mapping without a separate approval |
| Separation of re-identification approver from re-identification requester | Process documentation | Identity governance / SOD controls | Segregation-of-duties review | A single actor can both initiate and approve re-identification, removing the control that limits re-identification to authorised purposes |
| Pseudonymisation itself (the token-to-identifier mapping is stored nowhere accessible) | Data transformation record | Data architecture (protection is a property of the data) | Cryptographic or format review; token-space analysis | N/A — this is the condition under which the protection genuinely lives in the data rather than in access controls |
The last row is the bound. If a programme generates tokens using a keyed function and stores neither the key nor a lookup table in any accessible location, re-identification requires the key, not a join. In that architecture, the protection is genuinely a property of the data. The access controls on the key then carry the same governing logic described above. For lookup-based pseudonymisation, the four controls in rows one through four are the operative protection.
NIST SP 800-188 requires that organisations assess re-identification risk as part of any de-identification programme, which means the controls above need a documented risk owner and a re-test cadence — not a one-time entry in a data catalog (Source: csrc.nist.gov, https://csrc.nist.gov/pubs/sp/800/188/final). The cadence should reflect the organisation's access review frequency, its change rate for warehouse roles, and its JML process latency. A defined interval — for example, aligned to quarterly access reviews or to material changes in the administrator population — is illustrative; the appropriate frequency is determined by those operational factors, not by a universal standard.
Purpose limitation constrains how re-identification may be used once access to the mapping is granted. The four controls above govern whether access to that mapping can be obtained in the first place. Both layers are necessary; neither substitutes for the other.
What to record about the mapping
The transformation record captures what was done to the data. What needs a separate, maintained record is the access posture of the mapping itself: who is authorised to read it, under what approval, with what logging, and in which trust domain.
A mapping custody record, distinct from the transformation log, can make these four properties visible to the processes that need to re-test them. The record should capture: the identity of the data store holding the mapping; the role or group with read access; the approval authority for that access; the logging destination for reads; and whether the mapping store sits within the same administrative boundary as the de-identified dataset. Each of those fields corresponds to one of the four controls and connects it to the operational process responsible for re-testing it.
Deletion of the mapping, or confirmed absence of a reversible lookup, changes the category of the problem. Where a programme can demonstrate that no mapping exists — and where the de-identification technique does not depend on a stored key or table — re-identification is computationally constrained rather than administratively controlled. The protection is then a property of the data. Deletion workflows that confirm mapping destruction belong in the same record
The recordable set of facts is small: where the mapping lives, who can read it, whether that is logged, whether the trust boundary is separate, and whether re-identification requires a second approver. Record those facts in the same system that owns access reviews, not in the system that owns transformation logs. That placement is the operational expression of the thesis: the protection is an access control, and it should be governed by the processes that maintain access controls.
Sources
- csrc.nist.gov: https://csrc.nist.gov/pubs/sp/800/188/final
