Field Compliance Categories and Masking

When a field is placed under CS:Govern protection, two basics pieces of information need to be supplied:

• A masking rule is required that determines what the field data will look like to a user who does not have permission to view the field unencrypted.
• One or more Compliance Categories should be applied to the field. Compliance Categories are combined with database user access rules to determine who should be able to see unencrypted field data.

Let’s look at a simple example for Account.ShippingCity:

In this case:

• The Compliance Category for ShippingCity is set to “PII”
• The Rule is set to “Random”

In practice this means:

• Database users allowed to see PII database will see Account.ShippingCity unencrypted.
• Databases users without PII privileges will see a ShippingCity like jkmIjlM,

If the Masking Rules was set to a different rule, such as Asterisks, then users without PII privileges would see *********** when querying the Account.ShippingCity field.

A best practice for the initial setup of CS:Govern protected fields and their associated Compliance Categories is to examine Salesforce field meta data and mimic these rules in CS:Govern . This is an easy best practice to adopt by using a feature on the Edit Field Rules tab.

• The Discover Sensitive Fields button (in the lower left corner) will scan Salesforce field metadata looking for encrypted/protected fields and suggest that the same fields be protected by CS:Govern .  Of course, CS:Govern’s suggestions can be completely or partially ignored but accepting them is quick and easy.

The easiest Masking Rule best practice is to let CS:Govern choose the rule. If you do not like CS:Govern’s choice, you can always override it.

By default, CS:Govern will choose a masking rule for a newly protected field. CS:Govern’s built in rules will choose:

• Asterisks for String fields.
• A simple constant base64 encoded string for BASE64 fields (like Attachment.Body)
• Randomized characters for Email and URL fields. The results will still be valid Email or Urls — but with random character substitution.
• A Null value for Picklist, Combobox, or Multipicklist field.
• A string with digits changed to asterisks for a Phone field.
• A Null value of all other field types.

If the Masking rule for a field is changed AFTER data has already been encrypted, the newly encrypted data will use the new masking rule but older fields will not be changed until their containing record is updated.  Additionally, a Remask Custodian will be created automatically that can be used to re-mask the exiting records in the database.

Please read this article to learn more about choosing an appropriate masking rule.