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.
This control maps to 32 controls across 19 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.11 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 32 it maps to, and the evidence behind each claim, over MCP and REST.