This post was originally released on the Salesforce.com blog, written by Pete Thurston, RevCult's VP of Business Technology. View the original article.
Salesforce Shield is a popular solution for many of our clients in highly regulated industries concerned about data encryption and security (for example, healthcare, financial services, and government). One of Shield’s core services, Platform Encryption, encrypts sensitive data at rest while preserving business application functionality (search, etc.). Salesforce delivers amazing product innovations on an ongoing basis, with 3 major releases per year that fully preserve existing functionality while enhancing the Shield feature set. Although there are always discussions around the initial implementation of Platform Encryption, however, what about ongoing maintenance to ensure regulatory compliance? Here are three reasons why you should continuously monitor and update your Shield Platform Encryption configuration, even with seamless upgrades from Salesforce:
1. Organization Changes
We all know your organization is always changing. Admins and developers are adding new fields, new reports, new list views, and implementing new features all the time. How do you ensure you're in compliance with your information security team’s security needs?
Before every release, conduct a data classification exercise to re-evaluate your compliance needs regarding Platform Encryption. Identify which fields should be encrypted based on regulatory, security, privacy, and compliance requirements.
Recognize which of these identified fields:
- Are already encrypted by Salesforce Shield
- Cannot be encrypted by Salesforce Shield
- Require certain mitigation actions before Salesforce Shield can encrypt the field
- Could negatively impact the organization if encrypted (for example, fields that are referenced in report filters or list views)
- Take the necessary mitigation steps to allow for desired fields to be encrypted.
After the release, use Salesforce Shield to encrypt these fields and ensure that any changes made have not invalidated or broken anything regarding existing encryption.
2. Platform Rule Changes
As Salesforce continues to evolve the Shield Platform Encryption offering, we are seeing a trend of easing the rules that might have previously been a barrier to encryption. There may be fields you wanted to encrypt previously but couldn’t — and with the new rule changes, you might be able to. However, you won't know this until you re-evaluate your compliance needs regarding Shield Platform Encryption.
3. Auditors Never Sleep
No matter what your compliance needs are, there's always an audit cycle — whether it’s quarterly, annually, or semiannually. Auditors are always going to come back, and they’ll want to see evidence of how you supported your compliance over time. To date, there's only one tool to give you easy access to know what fields are encrypted across your organization: Shield Security Cockpit.
In conclusion, keep in mind that your implementation of Salesforce Shield Platform Encryption is the beginning, not the end, of your efforts to secure your data in the cloud. You will want to develop an ongoing plan to keep up with changes (both yours and Salesforce’s) and review your implementation on a regular basis to record the state of your instance at points in time. Here at RevCult, we have developed tools to help with this as Shield Platform Encryption has evolved over the years. Feel free to reach out if you need any assistance putting a plan into action for your organization.
About the Author
Pete Thurston, VP of Business Technology at RevCult, is always looking for ways to apply technology in an elegantly simple fashion to overcome business challenges. After conducting many Salesforce Shield Platform Encryption implementations at RevCult, Pete led the development of Shield Security Cockpit in an effort to automate the manual process of encrypting fields with Shield Platform Encryption. Our app easily shows you the fields that are already encrypted, fields that are ready for encryption, fields that require mitigation before being ready for encryption and fields that might negatively impact your organization if encrypted.