Pseudonymized Data & De-identification
Pseudonymization & De-identification
What is pseudonymized data?
- Direct identifiers removed, but still restorable
- Usable without consent for legally defined purposes
- Removing names alone does not make data pseudonymized
Once pseudonymization is in place, the question 'Can we use this data?' becomes 'For what purpose, under whose accountability, and through what procedure?' Instead of going back to collect consent again, you prove legitimacy through a lawful purpose and processing records, so the burden of proof shifts from the data subject’s consent to the processor’s documented procedures. The day-to-day difference is clear. It used to end with HR or security rejecting a business unit’s data request; now they can negotiate conditions instead of refusing, and fixing the pseudonymization purpose and target fields in writing becomes the first step of analysis design before any data is pulled.
Anonymized data falls outside personal information because it cannot be restored, but it loses analytical detail along with it. Pseudonymized data keeps that detail, and in exchange the safeguard obligations remain. Permitted purposes are limited to statistical compilation, scientific research, and public-interest record keeping. Statistics include commercial purposes, but the moment you pick out specific individuals for advertising or individual treatment, you are outside the scope. When combining pseudonymized data from different companies, you must go through a data-combination agency designated by the Personal Information Protection Commission, rather than having staff on each side match keys themselves. Processing techniques should also mix deletion, categorization, aggregation, and masking so that no small groups remain.
The most common misconception is that removing names and contact details makes data pseudonymized. If you only apply a hash with a fixed rule to employee IDs, or the original spreadsheet stays on an administrator’s PC, the requirement to store additional information separately is not met, and the processing itself may be judged unlawful. Attempting re-identification exposes you to criminal penalties and administrative fines, separate from any off-purpose use, and a single incident halts every analysis project under way. Pseudonymized data and additional information must be destroyed once the purpose is achieved, so if you do not set the retention period and the person responsible for destruction from the start, an audit a few years later will flag poor management. Detailed standards change as notices and guidelines are revised, so check the latest guidance before processing.
Jaryong KooMarketing PhD and leading authority on AI, data analytics, and personal branding
Seolyeong ParkGenerative AI and AX training specialist with 17 years of hands-on experience and 200+ sessions, making AI usable even for non-specialistsThe European GDPR defined pseudonymisation and made it a compromise between protecting and using personal data. In Korea, the 2020 amendments to the Personal Information Protection Act, the Network Act, and the Credit Information Act (the “Three Data Laws”) introduced the legal basis for processing pseudonymized data.
The Talent Development team at Company A, a manufacturer with 2,400 employees and annual revenue of about KRW 800 (≈ US$1) billion, wanted to join three years of training completion data with performance review data to see which courses actually lead to results. But the data request had been stalled in the legal team for two months. (Hypothetical example)
- When Manager Kim of the Talent Development team brought in the request form, the privacy officer said, “Performance statistics are fine, but if you write that you will use the results to select people for individual interviews, that is not allowed.” The team rewrote the purpose statement first.
- The two teams went through all 47 columns together and separated out 6 direct identifiers such as name, employee ID, and company email, and 11 quasi-identifiers such as birth date, department, and hire year that can reveal a person when combined.
- Birth dates were grouped into five-year age bands and the 127 departments into 9 divisions, and the 3 combinations that still left fewer than 5 people were merged further, down to job-grade ranges, so no one could be singled out.
- The mapping table used to replace employee IDs was moved out of the analytics environment onto the security team’s server. Access was limited to two people, the privacy officer and the team lead, and every lookup is logged automatically.
- As a result, a review that had been stuck for over two months was completed in three weeks, and the 4 later analysis projects, in areas such as marketing and safety training, followed the same procedure and received their data in 9 days on average.