A.8.11
Data masking
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control requires the organization to limit unnecessary exposure of sensitive data, especially personal data, by applying techniques such as masking, pseudonymization, and anonymization in line with access rights, business need, and legal requirements. When data is shown on screen, used in development/test environments, or shared/analyzed externally, the original values should not be revealed in full, reducing the risk of unauthorized viewing and disclosure. The key is to strike a balance that preserves data usefulness while lowering re-identification potential to a controllable level.
Key checkpoints
- Are the target data (resident registration numbers, card numbers, contact details, account numbers, and so on) and the criteria for applying masking/pseudonymization/anonymization defined?
- Is the extent of exposure (full/partial disclosure, number of masked digits, and so on) differentiated according to access rights and business need?
- Are suitable transformed/synthetic data preferred for development/test/training, with any necessary real-data exception controlled through a lawful basis, approval, and safeguards?
- Are the applied techniques designed and validated so that re-identification risk (for example, through combinations of quasi-identifiers) is sufficiently reduced?
- When masking/pseudonymization/anonymization is applied, is compliance with applicable law such as Korea's Personal Information Protection Act (for pseudonymization: purpose limitation, separate storage of the additional information, prohibition of processing to re-identify individuals, and so on) reviewed and recorded?
- Are approval/logging controls in place for unmasking (viewing originals) and for exception handling?
Implementation guidance
- Identify the fields to be masked based on the data classification results, and document the applicable technique and exposure extent per field as a standard.
- Use static masking to transform values in copies such as test datasets, and dynamic masking to limit query output. Dynamic masking does not replace authorization at the underlying store; control direct queries and bypass paths as well.
- Select partial masking, substitution, shuffling, tokenization, pseudonymization, or synthetic data according to purpose and risk. Masked/pseudonymized data is not automatically anonymous, and synthetic data also needs assessment for source-data disclosure.
- Integrate with role-based access control (RBAC) to differentiate exposure by role/duty, and apply masking consistently across all output paths, including screens, APIs, downloads, and logs, not just the display.
- Assess re-identification through quasi-identifier combinations, linkage to other data, and inference. A single measure such as k-anonymity does not guarantee anonymity; reassess when data or its use environment changes.
- Store masking rules and the keys/mapping tables (additional information) used for pseudonymization securely and separately, and control access and change history.
Evidence
- Data masking policy/standard and the list of target fields
- Masking rule definitions and captures of applied screens/query results (including exposure differentiated by privilege)
- Non-production data generation procedures and records of pseudonymized/synthetic data output
- Re-identification risk assessment reports
- Approval and exception-handling logs for unmasking (viewing originals)
- Configuration values such as dynamic masking policies in the DBMS/security solution
Nonconformity examples
- Production data is copied unchanged into development/test without justified need, a lawful basis, approval, and safeguards.
- Masking is applied on screen, but plaintext is still exposed in API responses, downloaded files, and logs.
- With no masking criteria, application varies by field at the discretion of individual staff, resulting in inconsistency.
- Data is treated as fully anonymized even though re-identification is possible through combinations of quasi-identifiers.
- Unmasking (viewing originals) privileges are granted broadly and viewing history is not recorded.
- Pseudonymized data and re-identification mappings/keys lack physical or logical access separation, allowing ordinary users to access both.