Protect the replacement map in reversible pseudonymisation

A reversible replacement map is a set of instructions for reconnecting pseudonyms to original values. If the map is stored beside the transformed export with the same access permissions, the intended separation may be largely lost.

The map needs its own purpose, owner and access rules. Start by asking why restoration is required at all. If the recipient never needs to recover the original, a reversible design may create a capability the workflow does not need.

Define the permitted recovery action

Consider a hypothetical analytics service that replaces customer identifiers before preparing reports. A separate support process occasionally needs to reconnect a disputed transaction to the customer account.

The design should describe that recovery narrowly: which role may request it, for which purpose, against which records and with what approval or evidence. “Administrators can access everything” is not a sufficiently specific recovery policy.

NIST’s de-identification guidance explains that pseudonymisation and the information available to recipients affect re-identification risk. A reversible map should therefore be treated as sensitive material, even when the transformed dataset no longer displays direct identifiers.

Choose the scope of token consistency

A stable token is useful when records must be linked. It also makes linkage easier wherever that token travels. Decide whether consistency is required within one document, one customer case, one tenant or the whole service.

For the analytics example, a global token reused across unrelated clients may create unnecessary connections. Tenant-specific or purpose-specific scope can reduce that exposure, provided the implementation reliably enforces the boundary.

Document how new tokens are assigned and how collisions or repeated requests are handled. Concurrent processing can create inconsistent mappings if the operation is not designed for it.

Presidio’s pseudonymisation sample demonstrates restoration using a mapping and explicitly warns that the sample is not thread safe. A demonstration is a useful explanation of a mechanism; it is not a production token-vault specification.

Separate routine processing from restoration

Most components that produce a pseudonymised output should not also be able to restore every original value. Give each service only the capability required for its task.

The transformation path may need to create or look up a token. The report renderer may need only the transformed data. A restricted recovery service may require additional authorisation before returning a specific original.

Apply authorisation to each recovery request. The OWASP authorisation guidance recommends least privilege, denying access by default and validating permissions on every request. A token supplied by a caller should not itself grant access to the corresponding identity.

In a multi-tenant service, validate the tenant relationship using trusted identity and membership information. The recovery lookup should be scoped to that verified context, not merely to an identifier copied from the request body.

Protect the surrounding paths

The map is not the only place originals can appear. Transformation errors, debug logs, request traces and backups may capture the values before replacement. Include those paths in the design review.

Protect storage and transport with appropriate controls, restrict administrative access and keep operational secrets separate from datasets. Avoid inventing a custom cryptographic construction simply to make tokens look random. Use a reviewed design appropriate to the threat model and deployment.

Audit recovery events without copying the recovered value into the audit log. A useful record can identify the authorised actor, purpose, record reference, decision and time. Those references can themselves remain personal data and require controlled access.

Plan deletion and recovery together

If the map is deleted while transformed records remain, some planned recovery may become impossible. If transformed records are deleted while a broad map persists indefinitely, unnecessary identifying material remains.

Define retention for both sides of the relationship and for backups, caches and exports. A deletion procedure should explain what happens to orphaned mappings and how legal retention requirements are handled. Do not claim that deleting a mapping automatically makes every associated dataset anonymous.

Before release, test:

• An unauthorised actor cannot restore a value.
• One tenant cannot use another tenant’s token to obtain an identity.
• Concurrent requests preserve the intended mapping behaviour.
• Logs and error reports do not reveal the mapping or original values.
• Retention and deletion outcomes match the documented recovery policy.

The map’s value is precisely that it preserves a relationship. Protect that relationship as a deliberate privilege, and remove it when the approved workflow no longer needs it.