We earlier talked about reducing production data. The third step to reducing data in your Salesforce org is to define retention policies.
The idea here is to identify what type of data you have, classify it, and apply retention policies that are in line with the security and compliance requirements of your organization.
The third step to reducing data in your Salesforce org is to define retention policies. The idea here is to identify what type of data you have, classify it, and applying retention policies that are in line with the security and compliance requirements of your organization.
Here’s how this works. The first step is to classify personal and sensitive data in your org. Personal data again, as defined by GDPR, CCPA/CPRA, or any other regulations and by legal and compliance.
The business-sensitive data typically would be trade secrets. To whom do you sell? How much do you sell it for? And other non-public information that is also non-personally identifiable information but has value for your organization.
In addition to this, you may also have other kinds of information such as security policies, technology optimization, set up information, audit trails, and things like that that you may not want to keep after a particular amount of time.
A very important aspect of how to classify and what to classify is to be able to assist the typical drivers of a policy. These requirements almost always come from your business, legal and compliance folks.
Personal data is very directly correlated with privacy laws, such as GDPR. And other lawful basis or security policies.
Business sensitive data is driven by security policies or technology optimization of your business. Finally, other kinds of information may come from your CISO or from your network security and other similar organizations.
Once you have established the typical drivers of policies, then you come to the point of defining policies and this breaks down into two key areas.
You would have retention policies for production Salesforce org and your choices typically are masking or deleting information.
Your organization may choose to mask information of leads with which no business was conducted over a particular period of time. You may choose to mask ex-customer data after say three years.
Similarly, you may choose to delete a lot of information that has no business value for your company and is also required by the law. Cases, Tasks, Contacts, Leads, Community users, users as ex-employees, and a number of other personally identifiable information-carrying objects are perfect candidates for retention policies for masking and deleting.
Similarly, you might choose to mask or delete business-sensitive data, primarily from a corporation standpoint of trade secrets and proprietary information.
In addition. When you look at other kinds of information, such as security policies, network settings, IP white lists and other similar kinds of parameters you may choose to just delete this information. A similar effort is then taken for your sandbox data. You may have different masking policies for sandbox than from your production.
A key reason for that is driven by the purpose for which a sandbox is used. So if you have sandboxes that are used by internal employees for production support and to try production fixes, the classic example is a hotfix environment. Then you may mask very limited information if any, at all.
Then you may not mask any data on it, because you want to be sure that your production fixes are going to work in that full copy sandbox.
On the other hand, if you have another full or partial copy sandbox that is accessed by third-party contractors, consulting companies, and such, and there’s really no need for personal information or business-sensitive information to be there, then you could choose to mask or delete that information.
In particular masking personal data is a really good idea, especially for training and testing sandboxes.
The masked data in those cases need to be relatable so that people who are testing are not trying to figure out looking at gibberish data. This is a key step in defining policies and helps us ensure that your data in Salesforce production and sandbox environments are secured. Thank you so much.
Get The 5 steps to reducing your data footprint in Salesforce from our website.
Saurabh is an Enterprise Architect and seasoned entrepreneur spearheading a Salesforce security and AI startup with inventive contributions recognized by a patent.
Get a clear understanding of the GDPR’s impact on Salesforce and explores the benefits of automating RTBF and Data Portability.
Because in the realm of data security, especially concerning Salesforce, understanding the holistic approach to data protection is not just beneficial – it’s essential.
Explores how data masking is key to strengthening your Salesforce security.
Disclaimer: To all readers, please note that this not legal advice, nor is this coming from Salesforce. This is strictly my personal opinion and perspective
Marathon runners obsess over their socks and shoes – because to outdo their past performance, they need to take advantage of everything at their disposal.
Reducing Salesforce data footprint directly reduces the cost and risks of potential data leaks and embarrassment, as well as benefits your organization. Here are
We talked earlier about masking sandboxes. The second step is to reduce production data. The idea here is that obsolete information in your Salesforce production
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
