Data masking

What the requirement asks

Data masking is to be applied as directed by the access control policy, related topic policies and what the business needs, with applicable law taken into account. Purpose: reduce how far sensitive data such as PII is exposed, and meet legal, regulatory and contractual obligations. Guidance: where protecting sensitive data such as PII matters, consider concealing it through masking, pseudonymization or anonymization, which can hide PII, obscure who the PII principals really are or other sensitive details, and break the link between the data and the person or other sensitive information. Verify that pseudonymization or anonymization is adequate; anonymization must address every element of the information, since a person can be identified indirectly through remaining data even when direct identifiers are removed. Other masking techniques include encryption with keys held by authorized users, nulling or deleting characters, varying numbers and dates, substituting values, and replacing values with hashes. When implementing masking consider: showing each user only the minimum data needed through designed queries and masks; obfuscating certain records within a data set where parts of the data are to stay hidden, for example allowing only specific roles to see a patient's records when clinically useful; letting PII principals require that users cannot even tell data has been obfuscated; and legal or regulatory requirements such as masking payment card data in processing or storage. When using these techniques consider the strength suited to how the data will be used, access controls on the processed data, agreements or restrictions on its use, prohibiting combining it with other information to re-identify the PII principal, and tracking who provides and receives it. Other information: anonymization irreversibly prevents direct or indirect identification; pseudonymization substitutes an alias, and whoever knows the algorithm or additional information can re-identify to some degree, so that must be kept separate and protected, though pseudonymized data is often more useful for statistics; masking can be static, dynamic or on-the-fly; hashing PII for anonymization should always be salted to resist enumeration; PII should be kept out of identifiers such as file names and URLs or anonymized there; ISO/IEC 27018 and ISO/IEC 20889 give more. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Data masking reduces exposure in test and analytics. The guidance asks for the data, the technique, the test and the approval.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep policy or standard specifying where masking, pseudonymization or anonymization is required, based on access control policy, business needs and law and one live sample together.

Evidence an assessor asks for

• Data maskingPolicy or standard specifying where masking, pseudonymization or anonymization is required, based on access control policy, business needs and law
• Data maskingMasking configurations in applications, databases and reports showing minimum necessary data displayed per role
• Data maskingVerification or re-identification risk assessments demonstrating that anonymization or pseudonymization is adequate
• Data maskingProtection and separation of pseudonymization keys or additional information
• Data maskingEvidence of legally required masking, for example of payment card numbers in storage and display
• Data maskingAgreements restricting use of masked or pseudonymized data sets and prohibiting re-identification, with records of who supplied and received them

The question an assessor will ask

An assessor will ask for policy or standard specifying where masking, pseudonymization or anonymization is required, based on access control policy, business needs and law, then trace it to the system it protects. For A.8.11 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Data labelled as anonymized can be re-identified by combining remaining fields
• Hashes of identifiers are unsalted and easily reversed by enumeration
• Pseudonymization keys are stored alongside the pseudonymized data
• Full production data is visible to all users of support and reporting tools

Before the next audit

Before the next audit, check one live sample for this gap: data labelled as anonymized can be re-identified by combining remaining fields.