Reversible Data Pseudonymization: Where to Store the Mapping Table

What is the risk

Ordinary masking solves only part of the problem. It hides a name, phone number, or IIN in the interface, but it does very little when a team investigates an incident and tries to connect events across logs, queues, and reports. That is why reversible pseudonymization seems convenient: the working data stays hidden, and if something serious happens, the original value can be restored.

The problem is that reversibility quickly blurs the line between "anonymous" and "almost open." If the rules are vague, almost any unusual case starts to look like a reason to reverse the substitution. At first, access is needed for one incident. Then for a customer complaint. Then to check a hypothesis "just in case." Before long, several employees are already used to looking at source data where pseudonyms would have been enough.

The mapping table itself becomes a separate attack target. If an attacker gets pseudonymized logs without it, the damage is often limited. If they get both the logs and the table, they can reconstruct the full picture: who did what, when they wrote, which fields they changed, and which documents they uploaded.

Usually the setup breaks in four places: the table is kept near working logs or in the same database, access is granted through a shared admin role, emergency rights are opened quickly and then forgotten, and reverse substitution happens without proper auditing.

This is especially dangerous during incidents. Pressure is high, the service has already gone down or a leak has happened, and people start cutting corners. In those hours, a temporary exception can easily become normal practice.

In LLM applications, the risk is even more obvious. A team may mask PII in prompts and keep audit data separately, but one poorly protected table links the user, the request, and the dialog content again. For banks, healthcare, telecom, and government systems, this is not a technical detail anymore, but an unnecessary disclosure of personal data.

When reversibility is truly needed

Reversible pseudonymization is not for convenience. It is for rare cases when you cannot verify an incident and fix the consequences without the original value. If the complaint says, "the model showed someone else’s data," an anonymized log is not enough. You need to understand whose request came in, which answer was sent, and whether a real person was affected.

Usually there are three situations. You need to confirm harm for a specific user, find all related events for one person or contract, or contact the affected customer if policy or law requires it.

Even then, you almost never need to restore the full profile. For an investigation, one or two fields are often enough: the customer’s internal ID, request number, phone number, or e-mail. Sometimes it is enough to restore only the last operations for a specific token. Full name, address, and date of birth do not help in such an investigation, but the risk keeps growing.

A simple rule is this: if a field does not help answer the question "what happened and who was affected," it should not be de-anonymized. In a leak review, it matters more to connect the log to the customer account than to open the whole set of personal data.

Non-reversible masking is enough where the team is looking for a general cause, not a specific person. For analyzing error frequency, prompt quality, checking limits, finding a routing failure in models, or comparing responses by request type, reversibility is usually unnecessary. If the task is "understand the pattern," the source values are probably not needed.

This is especially clear in LLM teams. A bank receives a complaint: a customer saw someone else’s contract number in the chat. To verify the fact, the team briefly restores the customer ID and contract number from the mapping table, checks the chain of requests, and closes the incident. For a weekly report on the cause of the error, those fields are no longer needed.

The reverse-lookup window should also be kept as short as possible. In many cases, 24 to 72 hours under an open ticket is enough. After the review, access is closed, the export is deleted, and a new de-anonymization can be triggered only through a fresh request with a clear reason. That way, reversible pseudonymization stays a working tool for rare investigations instead of a quiet back door into everyday access.

Where to store the mapping table

The setup stops working the moment the mapping table sits next to the main database, logs, or analytics exports. If an attacker gets one access path, they immediately see both the pseudonyms and the original values. After that, the protection exists only on paper.

It is safer to keep such a table in a separate environment. That can be a dedicated service, a protected storage system, or a separate database that the application reaches only when a reverse lookup is requested. The idea is simple: ordinary services, working logs, and employees should not see this table on the way.

The practical minimum is not complicated either. The table should be stored separately from the production database, logs, and BI exports. Access should be granted only through a separate service with an access log. Records should be encrypted with separate keys, not the same ones that protect the main database. Keys should be rotated on schedule, not only after an incident. And one more important thing: do not allow the table to be exported automatically to CSV, email, or shared folders.

Separate keys are needed for a simple reason. If the same secret combination protects the database, backups, and the mapping table, one compromised key opens everything at once. It is much safer to split these zones and define a rotation schedule in advance. For example, change production keys every quarter and verify that old versions can read archived records only through a controlled process.

It is a bad idea to copy matches into tickets, chats, and temporary files to "figure it out faster." In practice, those copies are the ones that live the longest. One CSV on an analyst’s laptop or one chat thread can cancel out the whole design.

If you work under Kazakhstan requirements, it is better to store the table inside the country, in the same legal environment where the other sensitive data lives. This is especially important for teams that already have local storage, PII masking, and audit controls in place. In such a setup, reverse lookup happens in a controlled environment instead of being sent to external systems.

A good sign of a healthy architecture is simple: the developer works with pseudonyms every day and never sees the source data. The mapping table lives separately and opens only for rare, verified cases.

Who should see the source data

Source data should not be visible to everyone involved in the investigation, only to the people without whom the incident cannot be closed. In most cases, the team only needs the pseudonym, event time, operation type, and an internal ID. If everyone gets access to de-anonymization right away, reversible pseudonymization loses its purpose.

The most common mistake is simple: the same person requests access, approves it for themselves, and then performs the reverse lookup. That approach should be ruled out. The initiator should submit a request for a specific incident and explain which fields are needed and why. The approver checks whether the request is justified and limits the amount of data and the access window. The executor reveals only the records that are actually needed for the review.

A developer, on-call engineer, or analyst usually does not need permanent access to the mapping table. They need the result of the check: whether the customer matched, whether there was a routing error, which session a record belongs to. The fewer people who see the source data, the lower the risk of leakage and unnecessary copying.

Access should be granted for the task and for a short time. A good rule is to open rights for one ticket, one set of fields, and a few hours, then close them automatically. If a person is investigating a log failure, they rarely need passport data or a full phone number. Often the last digits, the date, and the service identifier are enough.

For sensitive fields, a second approval layer is useful. This applies to payment data, health data, biometrics, the content of customer messages, and other records where a leak could seriously harm a person. One manager looks at the value for the investigation, the other at the privacy risk and legal requirements.

Break-glass access should be kept only for rare emergency cases: active fraud, a major outage, or an urgent leak stop. Such access should live for a very short time, require a reason, and go straight into the audit trail.

Every reverse lookup must be logged separately: who requested it, who approved it, who viewed it, for which incident, which fields were opened, and how many records were affected. Even if you already have PII masking and audit in your LLM infrastructure, you cannot lose this trail. Otherwise, after the incident, you will know the problem was found, but you will not be able to prove who actually saw the source data.

How to build the process

The workflow should be boring and strict. That is a good sign. When people improvise during an incident, access to source data quickly goes beyond what is needed.

First, define which fields you replace with tokens at all. Usually this is a phone number, e-mail, IIN, contract number, address, and device identifier. Technical fields that cannot identify a person are better left alone. Extra reversibility only adds risk.

Then issue stable tokens through a separate layer, not in each service’s code and not in analytics queries. The same e-mail within the chosen environment should always receive the same token, otherwise you lose event continuity and the investigation becomes painful. In practice, this is the most convenient option: the application writes events as usual, and a separate layer replaces fields before they are written to the log.

After that, sequence matters. The team describes the list of fields, the token format, and the retention period for matches. A separate service issues tokens and does not reveal source values to ordinary users. It saves the mapping record only after the event has successfully reached the log or storage. This step is often missed. If the table has already been updated but the event itself was not recorded, you end up with extra sensitive data and no value for the investigation.

The de-anonymization request should go through the incident number, with a reason, time window, and exact set of fields. The system shows only the needed records, then closes access after the review and keeps the trail in the audit log. It is much safer to open 3 to 5 specific records by tokens from the incident than a whole daily slice. That makes it easier to verify whether access was legitimate and almost impossible to carry out a quiet mass lookup.

After the review, access must be closed immediately, without "let’s leave it until tomorrow." Then the process owner runs a short review: who requested the reveal, what exactly was opened, whether that amount was enough, and whether the request was broader than necessary.

If LLM logs go through AI Router, it is convenient to use its PII masking, audit logs, and data storage inside Kazakhstan as part of the overall design. But the mapping table and the reverse-lookup rules are still better kept separate from the gateway itself, in a narrower access scope.

Example of an incident review

Imagine a common failure in an LLM application: the system accidentally mixed answers from two customer conversations. One user received a fragment of someone else’s answer, and the team learned about the incident through a complaint and through logs.

There are no full names, phone numbers, or e-mail addresses in the working logs. The team only sees customer tokens, request time, operation type, and a technical trail: which route the service chose, which prompt template fired, and where the answer jumped into another session. That is enough to localize the problem. But it is not enough to understand which two customers were affected or whether this is the same event across the CRM, the chat, and the application log.

The engineer does not need full access to the mapping table. They submit a targeted request: reveal only two records linked to specific tokens and a time window. The data owner checks the reason and grants access for one hour. The system immediately limits the scope: the engineer sees source data only for those two tokens, only for this incident, and only until the end of the approved window.

Then the team moves fast. It compares the two revealed records with the application logs, finds where the session layer mixed up the identifiers, fixes the routing or caching logic, checks that new responses no longer overlap, and closes the temporary access immediately.

This scenario does not break the minimal-access model. The engineer gets exactly as much data as needed to test the hypothesis. The rest of the records remain hidden, even if the incident affected a large event stream.

Audit is also necessary. The log keeps the employee name, request time, reason, list of revealed tokens, access window, and a note about who approved the reverse lookup. If a dispute comes up later, the company can see not only the fact that someone viewed the data, but also the context: why it was done and why those exact records were revealed.

Mistakes that break the setup

Reversible pseudonymization usually fails not because of the algorithm, but because of ordinary operational carelessness. The most common mistake is storing the mapping table next to the application’s working data, in the same database, the same cluster, or a shared backup environment. Then any employee or service that can see both parts can easily reconstruct the source values.

A similar problem appears when analysts, developers, or support teams are given permanent read access. For incident review, such access is needed rarely and only briefly. If a person can open de-anonymization any day without a request, approval, and end date, control is already lost. Audit helps, but it does not replace access limits.

Another typical problem is debug logs. Developers turn on verbose output to catch an error faster, and then phone numbers, e-mail addresses, IINs, or customer messages leak into it. After that, the source data no longer lives in one place, but in logs, alerts, tickets, and temporary copies used for investigation. Deleting the record from the main table is not enough if sensitive fields have already spread through the infrastructure.

There is also a quieter mistake: the same token is used in every system without a clear reason. At first this looks convenient because events are easier to join across CRM, analytics, and the internal portal. Later the token becomes a universal identifier that can be used to build a person’s profile even without direct access to the mapping table.

The setup works worst where people start handling everything manually. Someone exports matches to CSV for quick analysis, the file goes to email or chat, a copy stays on a laptop, and a month later nobody remembers who has it. For the same reason, teams often forget the access expiration date. Rights were granted for the duration of the incident, the incident was closed, but the access remained. Six months later it is used not for investigation, but simply because it is more convenient.

A mature process looks rather plain: the table lives separately, access is granted for hours, not forever, and nobody drags matches around in files. If even one of those points is missing, reversibility quickly turns into open de-anonymization.

Quick check before launch

Before moving to production, the setup should go through a short and strict test. It is more useful than a pretty diagram in the documentation. If the team is unsure about even one question, it is better to delay the launch.

Check the basics. The mapping table should live separately from the application, ordinary logs, and analytics dashboards. Every reverse-lookup request should have an owner, a reason, and a time limit. The service should reveal only the needed fields, not the entire customer profile. The audit trail should be kept by a separate system, where records cannot be quietly deleted or rewritten. And one more practical point: the administrator must be able to remove access immediately, without a long approval chain or manual workarounds.

There is another check that is often skipped. The team should run a mock incident review at least once. The scenario can be simple: someone found another person’s IIN in the request log, and the task is to understand whose request it was and who saw the data. Time the exercise, assign an investigation owner, and go all the way to access revocation. If people spend a long time searching for the mapping table, arguing about the right to reveal data, or failing to confirm the audit trail, the setup is not ready yet.

A good result looks simple: within 15 to 20 minutes, the team already knows who approves de-anonymization, which fields the system will reveal, and where the trace of each action will remain.

What to do next

Do not leave this setup for "later." Reversible pseudonymization fails not because of cryptography, but because of bad rules: it is unclear where the mapping table lives, who opens access, and how long the decoded data exists.

Start with a short 1-2 page policy. It only needs to cover four things: who creates pseudonyms, where the mapping table is stored, who approves reverse lookup, and how quickly the team must close access after an incident review. If this is missing, employees will start making decisions on the fly, and that almost always leads to extra data exposure.

Then pick one incident type and test the setup in practice. Not the whole catalog of cases, just one clear example: a customer complaint, a disputed transaction, or a scoring error. This quickly shows where the process gets stuck — in approvals, logs, or access rights.

For a self-check, a short list is enough. The mapping table is stored separately from working data and analytics exports. Access to de-anonymization is granted not to admins "by habit," but to specific roles by request. Every reveal of source data goes into the audit trail with a reason and a time. After the review, the system works only with pseudonyms again.

After that, run a mock investigation. Take a test incident, let the team follow a real approval path, and then check the audit logs. They should show who requested access, who approved it, which records were opened, and when access was closed. If even one step cannot be reconstructed from the logs, the process is still rough.

Also check whether your data storage matches your industry and jurisdiction rules. For a bank, clinic, and government body, the requirements often differ in retention periods, data location, and log content. The general logic is the same, but the details change the implementation a lot.

If you are building LLM services, check the platform even more strictly. It should support PII masking, audit logs, and controlled data storage. In that context, you can look at AI Router: it supports PII masking, audit logs, and data storage inside Kazakhstan. But even in such a setup, the mapping table and the de-anonymization procedure are better moved into a separate environment with narrow access.

A good first result looks simple: one scenario, one policy, one mock investigation, and complete logs for it.