PRO TIPS

An Overview of Salesforce Data Security

A headshot for Jay Mehta, Prolocity's PROserve Essential lead

Jay Mehta
PROserve Essentials Lead

Lately, we've gotten more questions regarding Salesforce's data security and privacy tools and policies. Especially nonprofits that serve vulnerable populations have expressed concern that data they hold can be used to harm their constituents. In this PRO Tips, we'll walk you through some components of data security and privacy that you might want to consider in designing a security policy and introduce you to some of the Salesforce tools you can use to enforce them.

The first thing you should consider is that security and privacy require multiple layers of policies and technical tools to enforce properly. You should also consider that you're not solely concerned with protecting against outside malicious actors. Nearly a decade ago, IBM's research showed that the majority of data breaches–60 percent–came from internal sources. So, you'll want to make sure that you're considering whether your internal users may have access to data that they should not be able to see. After all, a user can't disclose data they can't see.

The Basics: You Should Definitely Consider These

Before getting into more technical solutions, you should consider whether you've set the basics correctly: object and field level security control the visibility of tabs, objects, and the fields on them. Sharing settings control the records within an object that a user can see. Retention policies can then control how much data you leave in the system and for what period of time.

Object and Field Level Security

Let's start with the base layer of Salesforce permissions–objects and fields. Object data represents data types like Accounts, Contacts, Cases, and Opportunities, whereas field level data represents individual fields on each object. In Salesforce, you may grant a user the ability to create, edit, or delete records in objects, and the ability to view or edit any field on those objects.

In most organizations, the need to see object or field data is often driven by a person's role. For example, development and fundraising staff members likely need to be able to at least view Opportunity data (which is how most nonprofits using NPSP record donations). Managers may need to be able to edit records created by their staff members. And often, other staff members need to merely be able to see that a Contact is a donor and maybe see aggregated amounts.

You can establish these permissions in Object settings in either Profiles or Permission Sets that are assigned to users. You may have heard that Salesforce is deprecating security settings on profiles. This is true–Salesforce originally announced that they'd be making this change in the Spring '26 release in February of next year. But Salesforce quietly backed away from that deadline without announcing a new one. The official guidance is to still move toward assigning object and field level security on Permission Sets, but with no announced deadline.

Record Level Security: Org-Wide Defaults and Sharing Settings

Granting Object level security to, for instance, the Opportunity object determines if a user can see the object at all. If a user doesn't have read access to the Opportunity object, they won't even see the table for it in the user interface. But just because you've given a user read permissions on an object doesn't mean that they can actually see any records. That's where sharing settings come into play.
Sharing Settings (found in Setup->Sharing Settings) determine which records a user can see. You can think of these settings as setting a base level of permissions that can be opened up by sharing rules or manual sharing.
For most objects, you get three options for the Org-Wide default (OWD):
  • Private–only record owners can view or edit the record
  • Public Read Only–all users can view but only owners can edit the record
  • Public Read/Write–all users can view and edit

There are a couple of extra wrinkles. First and foremost is Role Hierarchy. In many orgs, roles roughly follow the org chart and are set up at levels like user, manager, and executive. Most standard objects like Accounts use role hierarchy to grant read/write permissions on records. So, a manager will have access to edit records that are owned by the users below them in the role hierarchy.
There are also special settings on the Object level security we looked at above called View all Records and Modify all Records. If a user has this permission either from a profile or permission set, Salesforce will disregard the OWD for that object.
If you set an object's OWD to Private or Public Read Only, you can also set up Sharing Rules to enable access to records that are owned by certain roles or groups of users, or share records based on values found on the record. For instance, you could use a criteria-based rule to set all Accounts with billing addresses in California to a specific role or group of users.

Setting Retention Policies

After setting base security, you'll also want to think about record retention. Data that is no longer relevant to your business may be best archived or deleted so that is it not available in the online Salesforce environment. After all, data that is no longer present can't be accidentally disclosed. Archiving also has other benefits, like decreasing data storage and improving database performance.

While there is not out of the box retention management tool, there are a number of products that can achieve archiving and deletion functionality. Salesforce themselves recently purchased one of the best known products and integrated it into the platform as Salesforce Archive. Using a tool like this you can set archive and delete rules that, for example, allow you to remove data that's more than seven years old.

Advanced Topics: For orgs with special concerns

Some customers have asked about Salesforce's stance on sharing data with legal authorities. They've also asked about Salesforce's technical ability to comply with a request. While we cannot give legal advice, we can point you to the guidance Salesforce has provided.

Salesforce's Policies on Government Data Requests

In 2020, Salesforce published a document that covers their standard principles in handling government data requests, including warrants.

First and foremost, Salesforce states that the company will always notify customers affected by government data requests, unless they are legally barred from doing so. They further say that they believe that data requests are better handled directly between agencies and customers. To that end, where legally permissible, Salesforce makes the effort to direct the agency directly to the customer.

Salesforce's guidance says that they assess every request to determine if it appears to be lawful, and if it follows the appropriate legal process for the relevant jurisdictions. If that review determines that a request is unlawful, Salesforce states they will try to challenge it. Note that that isn't a guarantee, however.

In general, you should expect a notification if a government entity makes a request for your data. But if Salesforce believes the request is lawful and properly executed, they may comply to meet their legal requirements.

Encryption & Salesforce Shield

Organizations with serious data concerns may consider implementing Salesforce Shield to encrypt their data in the database at rest. First off, know that Shield does not prevent users from seeing data in Salesforce. That is, it won't star out sensitive data like Social Security Numbers.

What Shield does do is encrypt data where it sits in the database–what's call "at rest" encryption. Although it is unlikely that this data could ever be compromised, data encrypted with Shield can't be decrypted if it ever is.

Shield provides multiple options for deriving encryption keys and storing them–varying from relying on Salesforce's systems for doing so, or providing full BYOK (Bring Your Own Key) functionality. In the latter scenario, only you control the decryption keys. You grant Salesforce secure access to your key store to use the key to decrypt the data when necessary.

This can greatly reduce the ability for any party–including Salesforce–to decrypt your data. But it also means you need a sophisticated understanding of key management. If you lose your keys, your data can't be decrypted, and even Salesforce can't help you in certain configuration scenarios.

Ultimately, your security concerns and needs are subject to your own judgment. That evaluation must be done on a number of angles–legal, ethical, and technological–to come to the correct answer.

Bonus: How to see what users can access

As you plot your data security design, it's often the case that you'll come to moments where you need to determine what objects or fields a specific user can see, and what Profile or Permission Set gives them access. This used to be somewhat difficult. But Salesforce has made major improvements to user access summary tools in the past several releases. As a bonus, here's a quick video on how to use these tools to help you identify the source of a user's permissions.