Consult with the Business
The first step to any encryption project is to understand which fields and objects might contain sensitive data. If API access is enabled, create an Encrypted Fields Report and use it as a basis for this discussion. Here are some discovery questions that you can use with your customers:
- Is the business subject to regulatory compliance law? If so, which fields and objects might be subject to this law?
- Does the business plan to use any free text fields where sensitive data might be stored? For example, are there notes fields that might contain Personally identifiable information (PII)?
- How are features such as Chatter and file attachments used? Often times, users inadvertently put sensitive data into Chatter posts and attachments.
Consider Use Cases
Once you have identified which fields need protection, next think about how the data is used. Because MVISION Cloud supports multiple encryption schemes, each of which preserves different levels of functionality, it is important to understand your use cases. Some fields need to support search, others need to be sorted, others have formats that must be preserved – consider all these important elements when deciding which encryption scheme to use.
When you begin to develop your initial encryption settings, it's best to start slow. A good way to begin is to create an Encrypted Fields Report, and review what you have. Then decide from there, one at a time.
What Fields Should Not be Encrypted?
Just as you must decide which fields should be encrypted, it is as important to know which fields should not be encrypted. Fields such as amounts, quantities, and percentages don’t generally mean anything without the context of an account name, a contact name, or an opportunity description, and so they should not be encrypted. Those latter pieces of information (name, address, description) identify the record much more than numbers.
In addition, these types of fields are often used in calculations, so it is best to leave them unencrypted to allow things like forecasting roll up reports to work as expected. With that in mind, here are the types of fields we recommend NOT to be encrypted:
Consider the Encryption Scheme
Other fields need a specific type of encryption. While selecting the encryption type for Master-detail relationship/lookup fields (like the Account Name field in a Contact object), do not select Standard Encryption, Length Preserving Encryption, or any other non-deterministic encryption scheme that returns different cipher text for the same clear text. This would cause validation failure – account name does not exist – because we would generate different cipher text for the same clear text.
For more information, see Encryption Schemes.