Overview
Why should you mask data in Salesforce and what kind of data should you be masking to ensure security, compliance and trust.
Let’s take an example. You may have a policy that states that customer data should not be accessible in sandbox.
Very common if we are doing offshoring working with third party developers and consultants.
You also want to remove unnecessary business sensitive data from sandboxes. And delete and update anything else.
When you think about masking sensitive data, you want to do that across full, partial, developer and developer pro sandboxes.
Personal information is also present in your dev sandboxes because it includes user data.
So if you have 500 Salesforce users, their email address, phone number or anything else, is present in Dev and Dev Pro sandboxes.
Let’s take a look at how this can work across all of these sandboxes you may have. You may have personal data such as customer information.
You may have business sensitive data, such as opportunities, quotes, who do you sell to, how much do you sell it for? And you have other information.
In addition to this, of course you’re full and partial are a treasure trove of customer information in contacts, leads, community users.
You may also have a lot of personally identifiable data in Cases, in Opportunities, Orders and others. This is the information you definitely want to mask.
In addition, you may want to mask business sensitive data such as product and Pricebook, Quotes, Orders, things like that.
Finally, you may want to update setup, config data, such as custom settings, labels and remote site settings.
The second component is to delete unneeded data.
Obviously your Dev and Dev Pro don’t have additional data, but for full and partial, delete unstructured data, attachments, email history, chatter, files, tasks and other irrelevant data.
Particularly for large Salesforce orgs, you are better off masking what needs to be masked for testing, training and other usage. Anything else that you can get rid of by deletion, do that. That’s a much faster approach.
And finally for Dev and Dev Pro, you don’t need to do anything else.
This is just a step one in a data reduction framework. They could look at the link to see other steps you can take to ensure data security in your organization? Thank you so much.
Get the Free Trial of the Data Masker App from AppExchange
Related Resources
How to Evaluate Salesforce Data Masking Tools: 12 Criteria That Matter
What Is a Data Processing Agreement (DPA)?
A Data Processing Agreement is not optional paperwork. GDPR Article 28(3) requires a written contract whenever a processor handles personal data on your behalf, and it specifies eight things that contract must cover. Most DPA reviews check that one exists and skip what it says.
What Is a DPIA (Data Protection Impact Assessment)?
A Data Protection Impact Assessment is a documented risk assessment carried out before high-risk processing begins. GDPR Article 35 makes it mandatory in defined cases, and several of those cases are triggered by things Salesforce teams do routinely, including deploying AI features over customer data.
What Is a Record of Processing Activities (RoPA)?
The Record of Processing Activities is the document a regulator asks for first. Article 30 sets out exactly what it must contain. The under-250-employee exemption sounds broad and turns out to cover almost nobody, because it excludes any processing that is regular rather than occasional.
What Is a Sub-Processor?
Controller, processor, sub-processor is a chain of responsibility, and GDPR Article 28 governs how each link is authorised and contracted. Every vendor that touches personal data on your behalf becomes a link, which is why adding tools has a compliance cost that is separate from their licence fee.
Learn More About Cloud Compliance
Explore our native Salesforce data privacy products.