2026-09-20 · ~22 min read · Decision records

The data anonymization and pseudonymization decision record: why the technique you chose determines your re-identification surface and your data subject rights fulfillment gap

The anonymization technique, pseudonymization key model, and pre-publication verification procedure are decisions that are almost never made explicitly — they emerge from a compliance checklist, a copied HMAC implementation, and an implicit assumption that removing direct identifiers is sufficient. Three failure patterns: the health tech team whose HIPAA Safe Harbor dataset was 74% re-identifiable because they retained a quasi-identifier combination that individually passed the checklist; the analytics team whose HMAC pseudonymization couldn't fulfill complete erasure requests for users who had changed their email address — the prior pseudonyms were unlinkable by design; and the corporate expense analytics team whose verified-anonymized transaction dataset allowed a researcher to identify individual executives by cross-referencing MCC codes with publicly posted conference schedules.

A 31-person health technology SaaS company built a patient engagement platform for mid-market healthcare providers — outpatient clinics, specialty practices, and regional hospital systems with 50 to 300 care providers each. The platform tracked patient appointment scheduling patterns, care adherence outcomes, and communication engagement for quality reporting and population health analytics. Two years after launch, the company entered a research partnership with an academic medical center, sharing a retrospective dataset of de-identified patient records for a study on outpatient care adherence patterns in chronic disease management. The data sharing agreement specified that the shared dataset had been de-identified using the HIPAA Safe Harbor method.

The compliance team reviewed the dataset against the 18 Safe Harbor identifiers and confirmed that all 18 had been removed or generalized: names, phone numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, and device identifiers were all removed; dates had been reduced to month and year only; ages had been reduced to year of birth; geographic subdivisions below the state level had been reviewed. The retained dataset contained: year of birth, five-digit ZIP code, ICD-10 diagnosis codes (primary and secondary), month and year of visit, and procedure type categories. The compliance team filed a documentation record stating that the dataset met HIPAA Safe Harbor de-identification requirements and cleared publication.

Four months after the dataset was shared with the research partner, a health data privacy researcher at a separate institution published a technical analysis demonstrating that 74% of records in the shared dataset could be uniquely linked to individual patients using publicly available CMS Medicare beneficiary enrollment data. For patients residing in ZIP codes with populations below 20,000 — rural counties and small suburban areas — the re-identification rate was 94%. The re-identification method did not require any sophisticated attack: the combination of five-digit ZIP code, year of birth, and primary ICD-10 diagnosis code produced a quasi-identifier triple that was unique or near-unique for a high fraction of records when cross-referenced against the CMS enrollment data, which contains the same three attributes for every Medicare beneficiary in the US. For rural ZIP codes, the population size was small enough that a specific combination of these three attributes pointed to a single patient with high confidence.

The compliance team's Safe Harbor review had been correct in one narrow sense: the 18 specific identifiers enumerated in the Safe Harbor method were absent from the dataset. Where the review failed was in its scope. The HIPAA Safe Harbor method includes a geographic subdivision requirement stating that geographic units smaller than a state must be generalized to contain populations of at least 20,000 people — the five-digit ZIP code fails this requirement for rural areas. The team had read this as applying to the retention decision for the ZIP code field itself (retain or remove), rather than as a requirement to verify that each retained five-digit ZIP code's underlying population exceeded the threshold. Rural ZIP codes with populations of 2,000 to 8,000 people had been retained because the field was not among the 18 enumerated identifiers to be categorically removed. The decision to use HIPAA Safe Harbor as the anonymization standard had been made without documenting what the standard required for the specific dataset being shared — which geographic granularity, which quasi-identifier combinations, and which external reference datasets would be tested before publication was cleared.

A 28-person B2B SaaS company built a customer journey analytics platform for direct-to-consumer e-commerce brands — a tool that tracked user behavior across onboarding flows, product discovery, cart interactions, and post-purchase sequences to help brand operators optimize conversion funnels and identify drop-off points. The platform processed behavioral event data for end consumers on behalf of brand customers. GDPR applied: the end consumers were data subjects, the brands were data controllers, and the analytics platform was a data processor operating under data processing agreements with each brand.

In their GDPR compliance sprint, the engineering team implemented pseudonymization for the user identifier stored with each analytics event. Before writing any event to the analytics database, the ingestion pipeline replaced the user's email address — the primary identifier shared by the brand's CRM and the analytics platform — with HMAC-SHA256(email, SECRET_KEY), where SECRET_KEY was a 32-byte random key generated at service launch and stored as an environment variable. The mapping was deterministic: the same email address always produced the same pseudonym. When a GDPR data subject access request arrived, the support team could derive the pseudonym from the user's email address and retrieve all analytics events for that pseudonym. The erasure procedure deleted all events for the derived pseudonym. The implementation was reviewed and documented as GDPR-compliant by the DPO.

Fourteen months after the pseudonymization was deployed, a user submitted a data subject erasure request. The support team ran the standard erasure: derived the pseudonym from the user's provided email address, deleted all matching events, confirmed zero records remaining, and closed the ticket. Two weeks later, the user reopened the ticket. They had checked with a brand's support team and learned that the brand's analytics dashboard still showed behavioral data attributed to them from eighteen months prior — a period when they had used a different email address for their account on that brand's platform. The user had changed their email address on the brand's platform twice in the preceding two years, creating three distinct identity states: the original email, an intermediate email used for nine months, and the current email.

The analytics platform had stored events under three different pseudonyms — one derived from each email address. The erasure job had deleted events under the current email's pseudonym only. Events under the prior two email addresses remained in the database as unlinkable records: HMAC-SHA256 is a one-way function, the analytics platform had no access to the brand's email change history, and there was no mapping table that associated the three pseudonyms with the same person. Fulfilling the complete erasure required the support team to contact the user for their prior email addresses, then cross-reference with the brand's CRM change log to confirm the history, then run two additional erasure jobs. The process took eleven days and required manual coordination with the brand's engineering team to extract the email change log.

A SOC 2 audit six months later surfaced two additional issues. The SECRET_KEY had not been rotated in 22 months — the "rotated on breach" policy documented at founding had no scheduled rotation cadence, and no rotation had been triggered. The auditor noted that anyone who gained access to the SECRET_KEY and any user's email address could reverse the pseudonymization for that user across every event in the database. The pseudonymization provided meaningful protection against database access by a party who did not know the user's email address, but no protection against an insider threat or a partial breach that exposed both the key and one of the identifier values from which the pseudonym was derived.

A 44-person B2B SaaS company built a corporate expense analytics platform for mid-market companies — a tool that aggregated corporate card transaction data from multiple card issuers and expense management platforms, normalized it into a unified spending model, and provided analytics dashboards, budget variance tracking, and policy compliance reporting for finance teams. Over three years, the platform had accumulated transaction data for approximately 180,000 corporate cardholders across 340 client companies in technology, professional services, and financial services industries.

The platform entered data sharing agreements with three banking research partners — two university-affiliated financial research institutes and one central bank analytics group — to provide anonymized transaction datasets for industry-level spending pattern studies. The data sharing agreements stated that data would be anonymized "in accordance with GDPR Article 89 safeguards." The anonymization procedure, performed by the data engineering team before each quarterly data transfer, removed: cardholder name, employee ID, email address, card number (last four digits retained for fraud pattern analysis), billing address (city and state retained), personal device identifiers, and direct transaction identifiers (replaced with randomly generated surrogate keys per cardholder). The procedure retained: merchant name was replaced with merchant category code (MCC), merchant state and city, transaction date (day-level precision), transaction amount, and expense category label from the platform's internal taxonomy.

In the third annual review meeting with one of the research partners, a data privacy officer raised a concern. A junior researcher on the partner's team had identified a specific individual — a CFO at a 200-person technology company — while exploring the dataset for a study on executive travel spending patterns. The researcher had found a cluster of transactions in the dataset: MCC 5812 (eating places and restaurants) and MCC 7011 (lodging — hotels and motels) in San Francisco over three consecutive days in March, followed by similar clusters in New York in June and Chicago in September. The transaction amounts and timing matched the executive-level pricing tier. The researcher had cross-referenced the timing with publicly available conference schedules for major technology industry events held in those cities on those dates and with the CFO's LinkedIn posts about attending those conferences. The combination was sufficient to identify the individual with high confidence without accessing any direct identifier that had been removed from the dataset.

The data engineering team's anonymization verification had confirmed that no records in the dataset contained cardholder names, card numbers, email addresses, or employee IDs. It had not modeled the quasi-identifier entropy of the retained fields in combination. The fundamental assumption in the verification — that MCC codes, transaction dates, and merchant locations were indirect attributes with high entropy — was valid for consumer card data, where transaction patterns are varied and public behavioral data is sparse. For corporate card data, the assumption failed: corporate travel patterns correlate strongly with publicly disclosed professional activities. Conference attendance is posted on LinkedIn; client visits are documented in press releases; board meeting locations are disclosed in governance filings. The retained attributes had lower entropy in the corporate card context than they would in a consumer card context, and the anonymization verification had not been designed to test for that difference. The data sharing agreement's Article 89 claim had been based on the removal of the 18-field checklist, not on a quasi-identifier combination analysis tailored to the characteristics of the specific dataset.

Structural properties set by the anonymization and pseudonymization decision

Three structural properties are determined when an engineering team establishes — or fails to establish — an anonymization and pseudonymization decision record: what the anonymization technique reveals about the residual re-identification surface after direct identifier removal, what the pseudonymization key model determines about the team's ability to fulfill data subject rights when identifier values change, and what the verification procedure requires before the team can assert that a dataset meets its claimed anonymization standard. None of these are labeled as decisions when the compliance team runs a HIPAA Safe Harbor checklist or the engineer copies an HMAC implementation from a GDPR tutorial — they emerge as operational constraints when the first re-identification attack is published, the first incomplete erasure request is reopened, or the first data sharing agreement's Article 89 assertion is tested against a motivated researcher's cross-reference.

Property 1: The anonymization technique and the re-identification surface. The re-identification surface is not defined by the direct identifiers present in a dataset — it is defined by the entropy of the retained attribute set in combination with external reference data. A dataset that contains no names, no SSNs, no email addresses, and no phone numbers can still be fully re-identifiable if the combination of retained attributes — age, location, diagnosis code, transaction date, category code — produces a low-entropy quasi-identifier set that matches external reference data at individual granularity. The anonymization technique determines how this surface is measured and what the team commits to doing when it exceeds the acceptable threshold. HIPAA Safe Harbor provides a categorical checklist for direct identifier removal; it does not guarantee that the residual quasi-identifier combination entropy is below a re-identification risk threshold, which is why the regulation also provides the Expert Determination method as an alternative pathway requiring a formal statistical analysis. Teams that run the Safe Harbor checklist and stop there have confirmed the absence of 18 specific fields, not the absence of re-identification risk. The data classification decision record connects at the sensitivity tier layer: the classification of a dataset as Regulated — health data, financial data, data involving vulnerable populations — determines the anonymization standard that must be applied, including the minimum k-anonymity threshold and the external reference datasets that must be tested in the verification. The data governance decision record connects at the lineage layer: understanding which attributes flow into a shared dataset, what transformations are applied at each stage, and which downstream copies exist is a prerequisite for identifying the quasi-identifier set that must be analyzed before publication — teams without documented data lineage cannot systematically enumerate what is present in the shared dataset and what the combination properties are.

Property 2: The pseudonymization model and the data subject rights fulfillment gap. The data subject rights fulfillment gap is the set of records attributed to a data subject that cannot be located and processed using the current pseudonymization mapping. The gap accumulates when the pseudonymization function is applied to a mutable identifier value rather than to a stable person identifier: every change to the identifier value creates a new pseudonym that is computationally unlinkable to the prior pseudonym, and the records stored under the prior pseudonym become orphaned — present in the database, attributed to the same person, and invisible to the rights fulfillment process that starts from the current identifier. Email addresses are the canonical mutable identifier: users change them through profile updates, employer transitions, and domain migrations. A pseudonymization scheme that derives the surrogate from the current email address produces a new unlinkable pseudonym with every address change. The correct anchor for pseudonymization is the stable internal user identifier — the primary key in the user table — which does not change across profile updates. Additionally, the pseudonymization key must be managed as a secret that is independent of the database containing pseudonymized records: co-locating the key with the data collapses the protection boundary, and the scheme must include a documented key rotation procedure with a re-pseudonymization migration to handle the key rotation without creating unlinkable records in the transition window. The customer data portability decision record connects at the rights fulfillment layer: the erasure flow must enumerate all systems where pseudonymized copies of a data subject's records exist — primary database, analytics warehouse, backup exports, third-party analytics integrations — and must address each system's pseudonym token, because erasure of the primary database record does not cascade to downstream copies. The consent management decision record connects at the legal basis layer: the lawful basis for processing determines whether pseudonymized data must honor data subject rights (processing under legitimate interest or contract requires rights fulfillment) or whether the data's anonymization standard is sufficient to release it from those obligations entirely.

Property 3: The anonymization verification procedure and the publication threshold. A verification procedure that checks for the presence or absence of direct identifiers is a checklist, not a re-identification risk analysis. The publication threshold — the maximum probability that any record in the shared dataset can be re-identified by a motivated party with access to plausible external reference data — is the metric the verification procedure must measure, not implied by the checklist completion. Setting and measuring the threshold requires three inputs: the quasi-identifier set (the retained attributes that individually or in combination could serve as external linkage keys), the minimum k-group size for that quasi-identifier set in the dataset (the k-anonymity value), and the plausible external reference datasets against which the quasi-identifier combination entropy will be tested. Corporate card data requires testing against professional profile databases and conference schedules; healthcare data requires testing against public enrollment data and medical record indexes; employment data requires testing against organizational chart data and industry employment surveys. The external reference test is context-dependent: the appropriate adversary model for a dataset shared with academic research partners differs from the adversary model for a dataset published in an open research repository, and the verification procedure must specify the adversary model explicitly so that the publication threshold can be calibrated to it. The data retention decision record connects at the retention basis layer: truly anonymized data — data that meets the publication threshold and has been verified against the adversary model — falls outside GDPR's scope and can be retained indefinitely for research and analytics purposes; data that does not meet the threshold remains personal data subject to retention limits, and the anonymization assertion in the data sharing agreement does not change that classification. The WhyChose extractor finds the anonymization decisions in your AI session history — the compliance sprint session where HIPAA Safe Harbor was adopted without modeling the quasi-identifier set, the GDPR implementation session where the pseudonymization key was anchored to the email address rather than the user ID, and the data partnership session where Article 89 compliance was asserted without specifying the verification methodology.

The data anonymization and pseudonymization ADR: five sections

Section 1: Anonymization standard selection and the quasi-identifier enumeration. Specify the anonymization standard that applies to each type of dataset the team produces or shares: HIPAA Safe Harbor (categorical checklist for US healthcare data — adequate for internal de-identification but insufficient as a sole standard for published research datasets), Expert Determination (statistical analysis by a qualified expert establishing re-identification risk below a documented threshold — appropriate for health or financial data shared with external research partners), k-anonymity with a specified minimum k (adequate for structured datasets where the quasi-identifier set is enumerable and external reference data is limited), or differential privacy (appropriate for published aggregate statistics and ML model outputs where arbitrary external information must be bounded). For each dataset category, enumerate the quasi-identifier set: all attributes that individually or in combination could serve as linkage keys in an external join against a plausible reference dataset. Quasi-identifiers are not only the attributes that look like identifiers — date of birth, location, demographic attributes — but also behavioral patterns, category codes, and temporal sequences that have low entropy in context. Document the adversary model: who is likely to attempt re-identification, what external data would they hold, and what linkage method would they use. For a healthcare dataset shared with academic researchers, the adversary model is a researcher with access to CMS enrollment data, public records, and local health system data. For a corporate transaction dataset shared with banking research partners, the adversary model is a researcher with access to professional profile databases, conference schedules, press releases, and public corporate governance filings. Connect this section to the data classification decision record for the sensitivity tier that determines which anonymization standard applies, and to the data governance decision record for the lineage documentation that enumerates which attributes flow into each shared dataset.

Section 2: Pre-publication verification procedure and the publication threshold. Specify the verification procedure that must be completed before any dataset is shared externally and the publication threshold that the procedure must confirm is met. The procedure has three steps. First, k-anonymity measurement: for the enumerated quasi-identifier set, compute the minimum group size across all quasi-identifier value combinations in the dataset. Any combination with group size below the minimum k threshold must be addressed through suppression (removing records that fall into small groups) or generalization (coarsening the attribute — replacing five-digit ZIP with three-digit ZIP, replacing exact date with month-year, replacing specific MCC code with MCC category group) before the dataset is shared. The minimum k threshold should be documented for each dataset sensitivity tier: k ≥ 5 for general structured datasets, k ≥ 10 for healthcare or financial data, k ≥ 20 for health data involving populations with rare conditions. Second, external linkage risk test: query the quasi-identifier combination distribution in the dataset against the most plausible external reference data available — CMS enrollment extracts for healthcare data, corporate directory data for employee and transaction datasets, conference attendance lists for corporate travel data. For datasets where direct external reference data is available, the team should attempt a sample linkage attack before publication. If a motivated attacker could produce high-confidence individual linkages from the sample, the quasi-identifier set is insufficiently generalized regardless of the k-anonymity result. Third, documentation: the verification result — the k value achieved, the suppression or generalization steps applied, the external linkage test result, and the publication threshold conclusion — should be filed with the data sharing agreement as the technical evidence underlying the anonymization assertion. The assertion in the agreement should specify the standard and the threshold, not only the conclusion. Connect this section to the data retention decision record for the regulatory basis distinction between truly anonymized data (outside GDPR scope, indefinite retention permissible) and pseudonymized data (personal data, retention limits apply).

Section 3: Pseudonymization key model and the stable identifier anchor. Specify the pseudonymization function, the identifier that serves as the input, the key management model, and the rotation procedure. The identifier anchor must be a stable internal identifier — the immutable primary key in the user or entity table — not a mutable value such as an email address, username, or phone number that changes through normal user activity. If the current integration surface exposes only mutable identifiers (the upstream system provides email addresses but not stable user IDs), establish a mapping layer that translates mutable identifiers to stable internal IDs before applying the pseudonymization function. The pseudonymization key must be stored in a dedicated secrets management system (not as an environment variable, not in application configuration, not in the same database as pseudonymized records) with access restricted to the pseudonymization service role. Key rotation procedure: generate a new key, run the re-pseudonymization migration (a batch job that reads each existing record's surrogate key, derives the original identifier using the old key, applies the new key to produce the new surrogate, and writes the new surrogate) as an online background job with duplicate-safe idempotency, run re-pseudonymization for all downstream copies (analytics warehouse, backup exports) before decommissioning the old key, and maintain dual-version decryption support during the rotation window for any in-flight requests that carry the old surrogate. Rotation cadence: annual scheduled rotation plus immediate rotation on any event that could expose the key (credential breach, engineer departure with key access, third-party audit finding). Connect this section to the customer data portability decision record for the downstream copy inventory — every system holding pseudonymized records requires its own erasure and access procedure, and the pseudonymization key used in each system must be tracked to enable rights fulfillment across the full record inventory.

Section 4: Data subject rights fulfillment procedure for pseudonymized records. Specify the procedure for fulfilling data subject access, erasure, rectification, and portability requests for pseudonymized records, including the handling of identifier change history. The fulfillment procedure has three components. Stable-to-surrogate mapping: the rights fulfillment system must be able to derive the surrogate key for a data subject from their current identifier value, via the stable internal user ID. If the data subject's mutable identifier (email address) has changed since the pseudonymized records were created, the fulfillment system must look up the stable internal user ID associated with the data subject's provided identifier value, and derive the surrogate from the stable ID rather than from the current email. This requires maintaining a mapping from stable internal IDs to their current and historical mutable identifier values — not as a pseudonymization mapping table (which would defeat the purpose of pseudonymization) but as part of the identity and account management system that already tracks profile changes. Cross-system inventory: for each erasure or access request, the fulfillment job must operate against every system holding pseudonymized records for the data subject's stable ID — the primary analytics database, the data warehouse, backup snapshots (documented overwrite schedule required), and any third-party systems that received pseudonymized exports. A rights fulfillment checklist enumerating each system, the deletion method, and the confirmation signal is required per request. Fulfillment logging: a deletion evidence log recording the request date, the systems addressed, the record counts deleted per system, and the completion timestamp must be retained in a compliance store that is not subject to the deletion request itself, for the duration of the applicable regulatory demonstration period. Connect this section to the consent management decision record for the lawful basis under which each category of pseudonymized data was collected — the lawful basis determines which rights apply (erasure rights are not absolute under all lawful bases) and which records are in scope for a given request.

Section 5: Data sharing agreement technical specifications and the anonymization assertion protocol. Specify what technical information must appear in data sharing agreements for externally shared datasets, and the internal approval procedure before any anonymization assertion is made in an agreement. The data sharing agreement must specify: the anonymization standard applied (HIPAA Safe Harbor / Expert Determination / k-anonymity with k value / differential privacy with epsilon value), the quasi-identifier set that was enumerated and verified, the minimum k-group size achieved after suppression and generalization steps, the adversary model assumed in the verification (what external reference data was tested), and the publication threshold concluded. A blanket assertion that data is "anonymized per GDPR Article 89" without specifying the technical standard and the verification methodology is not a technical specification — it is a legal characterization that has no operational content if the anonymization is challenged. The internal approval procedure: the pre-publication verification result (Section 2 output) must be reviewed by a qualified person — a data privacy officer, a privacy engineer, or an external privacy consultant for novel dataset types — before the data sharing agreement is signed. For datasets involving sensitive categories (health data, financial data, data about children, data about employees), the verification must include an external linkage risk test, not only a k-anonymity measurement. If the verification process identifies a quasi-identifier combination that produces groups below the minimum k threshold, the dataset must be re-generalized and re-verified before the sharing agreement proceeds — the agreement cannot be signed on the assumption that the suppression or generalization will be applied before transfer. Connect this section to the data governance decision record for the data sharing inventory (all active data sharing agreements, their technical specifications, and their renewal and audit cadences) and to the data classification decision record for the sensitivity tier classification that triggers the enhanced verification requirement.

FAQ

What is the difference between anonymization and pseudonymization under GDPR, and why does it matter for compliance obligations?

Under GDPR, anonymization means that the data can no longer be attributed to an identified or identifiable natural person by any means reasonably likely to be used. Truly anonymized data is no longer personal data and falls outside GDPR's scope entirely — it can be retained indefinitely, shared without a data sharing agreement, and used for any purpose. The standard for anonymization is high: it must be irreversible and must account for the combination of retained attributes against external reference datasets that could reasonably be available to a motivated party. Pseudonymization means that the data has been processed such that it can no longer be attributed to a specific data subject without the use of additional information, but that additional information exists and can be used to re-link records. Pseudonymized data is still personal data under GDPR — the data subject's rights (access, erasure, portability, rectification) apply to pseudonymized records, and the controller must be able to fulfill those rights. The practical implication: teams that treat pseudonymization as a form of anonymization and stop honoring data subject rights for pseudonymized data are in violation of GDPR, because the ability to re-link via the pseudonymization key means the data remains personal data. Conversely, teams that achieve true anonymization gain meaningful compliance relief, including exemption from retention limits and data subject access obligations.

How should teams choose between k-anonymity, l-diversity, t-closeness, and differential privacy for dataset anonymization?

The appropriate privacy model depends on the nature of the data, the sensitivity of the attributes, and the expected adversary's access to external reference data. K-anonymity ensures that each record is indistinguishable from at least k-1 other records with respect to the quasi-identifier set — no individual can be singled out from a group smaller than k. It is a useful baseline for datasets where quasi-identifier combinations are the primary linkage risk and sensitive attribute homogeneity is not a concern. K-anonymity is insufficient when sensitive attributes within a k-group are homogeneous — an attacker who knows a record belongs to a specific k-group learns the sensitive attribute even without identifying the individual. L-diversity adds a requirement that each k-group contains at least l distinct values of the sensitive attribute, preventing homogeneity attacks. T-closeness further requires that the distribution of sensitive attributes within each k-group approximates the overall distribution in the dataset, preventing skewness attacks. Differential privacy provides a mathematical guarantee that any single record's inclusion or exclusion in the dataset produces a bounded change in the output, regardless of what auxiliary information an adversary holds — it is the strongest standard and the most appropriate for published aggregate statistics, ML model outputs, or any dataset where the adversary may hold arbitrary external information. For most teams sharing business transaction or health data with research partners, k-anonymity with a minimum k of 5 for general datasets and k of 10 or higher for healthcare or financial data is a practical starting threshold, combined with l-diversity for sensitive categorical attributes.

What makes a HMAC-based pseudonymization scheme GDPR-compliant, and what makes one vulnerable to reversal or rights fulfillment failure?

A HMAC-based pseudonymization scheme maps a direct identifier to a surrogate key using a keyed hash function. The scheme provides meaningful protection when four requirements are met. First, the HMAC key must be stored in a secrets management system independent of the database containing pseudonymized records — co-locating the key with the data collapses the security boundary to the database alone, equivalent to not pseudonymizing. Second, the HMAC key must be rotatable with a documented re-pseudonymization procedure — all existing records must be re-keyed when the HMAC key is rotated, which requires an idempotent batch migration. Third, the pseudonymization must be applied to a stable person identifier, not to a mutable identifier value — email addresses change; if the pseudonym is derived from the current email, every email change creates a new unlinkable pseudonym and prior records become unreachable during rights fulfillment. The stable internal user ID (immutable primary key) is the correct anchor. Fourth, the rights fulfillment procedure must account for all systems where pseudonymized records exist — downstream data warehouse copies, backup exports, and third-party analytics integrations each require their own deletion procedure that starts from the stable identifier mapping, not from the current mutable identifier value.

How should teams structure the pre-publication anonymization verification for datasets shared with external research or analytics partners?

Pre-publication anonymization verification must answer two questions: can records be re-identified using retained attributes alone, and can records be re-identified by combining retained attributes with external reference data a motivated party could access. The procedure has three steps. First, enumerate the quasi-identifier set: all retained attributes that individually or in combination could serve as identifiers in an external linkage. This includes obvious quasi-identifiers (year of birth, ZIP code) but also contextual ones: MCC codes in corporate card data, conference attendance patterns, specialty diagnosis codes for rare conditions in health data. Second, test k-anonymity: for each combination of quasi-identifiers, verify that the minimum group size meets the chosen threshold. Groups below the threshold require suppression or generalization before the dataset is shared. Third, test external linkage risk: identify the most plausible external reference datasets that share quasi-identifier dimensions with the published dataset — CMS enrollment data for health records, professional profile databases for corporate data — and assess whether the quasi-identifier entropy produces high-confidence linkages. For corporate card data, accounting for the semi-public nature of executive professional activities is a required step that does not apply to consumer card data. The publication threshold — the maximum re-identification probability the team accepts — should be documented in the data sharing agreement rather than asserted as a compliance conclusion, so that the technical standard is reviewable if the assertion is challenged.

Structural properties set by the anonymization and pseudonymization decision

The data anonymization and pseudonymization ADR: five sections

FAQ

Further reading