Skip to contentCYBERINFO
|

Control 8.11 : Data Masking

Summary

Data masking should be used in accordance with the organization's topic-specific policy on access control and other related topic-specific policies, and business requirements, taking into consideration relevant legislation. This ensures that sensitive data is obscured when displayed to users who do not have a specific need to see the full details.

Applicability

In-Scope: Mandatory for organizations handling highly sensitive PII, financial data, or health records. It is a key technical requirement for meeting privacy regulations like Law 25 and GDPR while allowing for data processing and support activities.

Out-of-Scope: Only reducible for organizations that process zero sensitive data types that require masking, though basic PII protection remains a standard expectation.

Implementation Guidance

Microsoft 365 / Entra ID

  • Dynamic Data Masking: Utilize Azure SQL Database features to apply dynamic data masking, ensuring that sensitive fields (like credit card numbers) are only visible to authorized personnel.

  • Sensitivity Labels: Use Microsoft Purview Information Protection to apply visual markings and watermarks to sensitive documents, acting as a manual form of data awareness.

  • Data Loss Prevention (DLP): Configure Purview DLP rules to detect sensitive information in emails and automatically apply masking if the content is permitted to be sent but needs to be obscured.

Evidence Checklist

  • Data Masking Policy: Documented rules defining which data fields require masking and for which user roles.

  • System Configurations: Screenshots of database or application settings showing active masking rules for sensitive fields.

  • Sample Outputs: Redacted or masked reports demonstrating that the technical controls are functioning as intended.

Practical Audit Advice

Here are some questions the auditor might ask:

  • How does the organization identify which specific data elements require masking versus full encryption?

  • Can you demonstrate that a developer or support agent cannot see the full PII of a customer while performing a routine database query?

  • What process is in place to ensure that masked data cannot be re-identified by combining it with other available data sets?

  • How are the masking rules updated when a new regulatory requirement or data type is introduced?