Understanding the Salesforce Data Security Model: Top Strategies and Best Practices

CRM systems have become irreplaceable tools for businesses, with millions of companies worldwide relying on platforms like Salesforce.com to help improve their business operations and customer relationships. This, however, comes with its own set of risks. The biggest risk involved here is that a single breach of data may result in serious damage to the service as well as its users. CRMs also continually collect and store large volumes of data, from business to customer information, most of which is bound by various regulations or compliance frameworks. A breach in data may have drastic consequences not only in the immediate destruction of data but also in compliance violations that could cripple the company in the long run.

Data breaches have become all-too-common in many tech industries; CRM software is no exception. To eliminate the risks for your company leverage Salesforce’s native capabilities, complemented by third-party solutions for data security when necessary. 

This article describes the Salesforce Data Security Model applied to safeguard different information categories. Moreover, the features included in this model, recommendations on data storage, best practices in developing Salesforce applications, as well as a number of case studies for different use cases.

Common Salesforce and Data Security Incidents and Risks

Data security is a problem for organizations big and small, and Salesforce isn’t an exception either, having its share of security incidents. Events like this always point to one important lesson learned: no platform, no matter how large and successful, can afford to be slack on security.

Salesforce Data Leak 2019: In late 2019, Salesforce experienced a data breach, wherein for a period of six months, the hackers had access to customer data. It was reported that they found this compromised database on the dark web.

Salesforce Data Outage of 2019: A data outage that occurred in 2019 due to some sort of error in the scripting, had accidentally granted higher permissions to several users. The aftermath was the suspension of some accounts and disruption of services.

With the data leakage or outage incidents that may occur, it’s crucial to focus on data security strategies to protect your company data.

How the Salesforce Data Security Model Works

Salesforce’s data security measures are a set of systems and rules that make it more challenging for a customer’s data to be accessed by unauthorized users. This kind of goal might seem simple at first, but the sheer scope of operations for an average Salesforce environment does make it a lot more difficult than one could imagine at first.

Salesforce Security Levels Compared

To simplify the topic in question and make it more manageable, Salesforce has introduced its own approach to data security with four distinct levels: Organizational level, Object level, Field level, and Record level. Here is how the four-tiered structure compares against one another in terms of scope and granularity before taking one tier at a time:

Security Level	Scope	Granularity	Example Use Case
Organizational	Entire Salesforce environment	Broadest	Restricting login hours or IP ranges for all users
Object	A specific data set (e.g., Accounts, Opportunities)	High-level	Preventing a role from accessing the Contracts object
Field	A single column within an object	Granular	Hiding a Social Security Number field from most users
Record	A single row within an object	Most granular	Allowing a rep to see only their own Opportunities

With each level becoming progressively narrower than the previous one, the permissions start at the widest possible level and go down to individual data rows within tables. The following sections explain how each one works and how to better configure them all.

Organizational-Level Security in Salesforce

The “highest” possible security level that covers overarching data protection measures. One of the most fundamental goals of this level is to prevent unauthorized access to restricted information. Salesforce can use its Login Hours feature in order to restrict specific users from accessing the solution in a dedicated time frame each day. 

Preventing a specific login IP range from accessing the environment or allowing it is within the range of Salesforce’s capabilities at this stage. Password requirement configuration and the addition of extensive security features such as Salesforce Shield (which will be discussed later in the article) are also a part of this security level.

Object-Level Security in Salesforce

This security level is slightly “lower,” which offers it the ability to be a bit more granular with its restrictions and configurations. An “object” in Salesforce is a domain-level data set – the closest analogy would be a table or a sheet from Microsoft Excel or other similar solutions.

Object-level permissions allow administrators to restrict access to specific information, preventing the majority of users from opening or modifying the data in question. These permissions were set up via specific user profiles for a while before Salesforce’s implementation of Permission Sets was introduced.

Creating either a Permission Set or a Permission Set Group is the recommended action now, removing the need to manually set every single user’s permissions by hand. What you can do now is to set up rule sets, such as to allow everyone in the environment who has a specific job role to access the target information.

Field-Level Security in Salesforce

Following the analogy mentioned above, a field in Salesforce is similar to a column in Excel. Being able to access a specific field in Salesforce does not provide the same user access to the entire file, offering even more flexibility and granularity. 

Similar to the previous example, Salesforce does recommend using Permission Sets and Permission Set Groups to manage field-level access, but these kinds of permissions can also be set for every single user separately via their profile.

Record-Level Security in Salesforce

The smallest entry of the four security levels, the record-level security, is the ability to restrict access to very small parts of the file, such as a single row of information from a large spreadsheet. Both object-level and field-level permissions make it possible for users to create new records and modify existing ones. However, this kind of approach would not be particularly useful in collaboration, so Salesforce can provide four different methods of record management capabilities to its users:

• Company-wide defaults refer to the most basic approach to record permissions: all users in the company have the same level of access to the record except for its owner.
• Role hierarchy implies the creation of a priority list for different positions in the company, with the users that have a higher hierarchy level having complete access to all records made by users placed below them.
• Sharing rules are another method of information exchange that revolves around public groups – making it possible for each user to share all of its records with the rest of the group.
• Manual sharing specifically covers individual record sharing with a single other person; it is only useful in specific situations and would be very tedious to perform in large teams.

CRUD Permissions and Their Configuration

CRUD permissions define what the user can do to records within an object, working together with the object-level security described previously. Whereas object-level security controls if a user can access an object at all, CRUD permissions specify what exactly they can do:

• Create – the ability to add new records to an object
• Read – the ability to view existing records
• Update – the ability to edit the values of existing records
• Delete – the ability to permanently remove records

Each of these four permissions are independent from one another; for example, you can give a user the permission to Read and Update but not the ability to Create and Delete. Like the majority of permission sets described above, CRUD settings are applied using Profiles or, more importantly, Permission Sets and Permission Set Groups that can then be distributed to groups of users without the need to modify each user’s profile individually.

Salesforce Organization-Wide Defaults

Setting defaults for an entire organization in Salesforce with Organization-Wide Defaults (OWD) defines the broadest level of access to records for a specific object in a Salesforce account. They answer a single question: “What can users see by default, before any additional sharing mechanism is applied?” 

Every object in a given org can be configured as follows:

OWD type	Configuration
Private	Only the record owner and users above them in the role hierarchy can access it
Public Read Only	All users can view records, but only the owner (and those above them) can edit them
Public Read/Write	All users can view and edit any record, regardless of ownership
Controlled by Parent	Access to a related record follows the access level of its parent record

Since OWN is the most restrictive way to access any records, it generally is configured as Private or Public Read Only for any sensitive object. After that, role hierarchies, sharing rules, and manual sharing can only expand access further; none of them are capable of overriding OWD, making access even more restrictive than the existing baseline.

That’s why setting an appropriate OWD for each object is so important – you’re actually creating the baseline for every other kind of sharing.

Using Role Hierarchies, Sharing Rules, and Manual Sharing to Control Record Access

Role hierarchies push access up automatically depending on a user’s position in the organization. Any user in a higher position in the org chart than another gets the exact same record access. It’s a built-in, automatic process that perfectly matches how just about every company’s employees report to one another. Because of this, it’s a favorite feature for managers that need visibility into their team’s records.

Note: In Salesforce, you can disassociate role hierarchy from the organizational chart entirely if they don’t align perfectly.

Sharing rules provide access based on group membership, not role hierarchy. An admin can define a set of criteria – such as the user’s role, public group, or territory – and Salesforce will make the specified Read or Read/Write access available to all who meet the criteria. It’s the baseline approach for any cross-function access scenario; for example, you could use sharing rules to make an entire sales operations team able to read records owned by all sales reps without needing to set permission on each user individually.

The most granular and least scalable of the three is manual sharing. This method is available to a record owner or a comparable user, and allowing to share one record on a case-by-case basis to a specified colleague. This can be performed on a record-by-record basis using the Sharing button on the record itself. The “one record at a time” approach makes it the most suitable for exceptions and emergencies, such as single collaboration efforts or an occasional access.

All three methods can only expand the access defined by Organization-Wide Defaults and not tighten any of them. The choice between these depends on scale and predictability. For the repetitive rule-based access, hierarchy and sharing rules would be preferable. For one-time special access, manual sharing would work better.

Scoping Rules vs. Sharing Rules

Sharing rules directly control data access. These rules determine if a specific user can see or edit a record. 

Scoping rules address a separate issue: they don’t control whether someone can access a record or not, but rather control the default contents of the users’ list views, related lists, and reports. Scoping rules allow administrators to clean up lists and improve performance in large orgs without directly changing what each user can see.

Thus, a user may have a large number of fully accessible records due to the existing sharing rules, but may only ever see a small subset of them in a day-to-day view whenever a scoping rule is in place. In conclusion:

• Sharing rules control permission
• Scoping rules control visibility within that permission

	Scoping Rules	Sharing Rules
Affects	What appears in views/reports	Underlying record access
Changes permissions?	No	Yes
Typical use case	Reducing visual clutter in large data sets	Extending access to a group of users

Authentication in Salesforce

Both permissions and sharing rules are only valuable once a user’s identity is verified. Users can prove who they are to Salesforce via multiple methods that are not mutually exclusive and operate in tandem in any competent org.

Salesforce Authentication Methods

It’s rare for a Salesforce production environment to have a single login method governing everything – most use some form of layered security consisting of methods chosen based on factors like risk level and data sensitivity. Three fundamental measures in this field are known to practically anyone:

• Username and password combination
• Multi-Factor Authentication (MFA)
• Single Sign-On (SSO)

Salesforce also includes Social Sign-On allowing users to sign in with their Google, Facebook, or other third-party credentials. More often than not, this method is used for community and portal users but rarely anyone from the internal team.

Finally, there’re Connected Apps with OAuth 2.0 – used primarily for token-based authentication into API and third-party applications instead of direct log-ins. 

Note: The topic of Salesforce integrations will be covered later on in the article.

Improving Salesforce Security with Multi-Factor Authentication

MFA requires at least two of three factor types to match before authenticating a user:

• Something the user knows: a password
• Something the user has: a phone, a hardware key, an authenticator app
• Something the user is: a fingerprint, other biometric marker

The need for a second factor during every authentication prevents user accounts from being breached once its password is stolen.

This practice also stopped being optional in Salesforce as far back as February 2022, requiring MFA usage for all users logging in since then. Salesforce does allow third-party options for both hardware and authenticator apps, but the requirement for a second factor during authentication has to be satisfied one way or another.

SSO vs. Native Salesforce Authentication

A choice between SSO and native Salesforce authentication is decided by where the org wants to manage its risk. 

SSO pulls all authentication calls through a single identity provider, allowing users to jump between Salesforce and other business applications without re-entering credentials. When that user leaves the company – SSO removes all of its access permissions at once by revoking just one account. Native authenticators ignore that dependency completely, storing credentials in Salesforce itself so there’re no external interfaces or dependencies on any third-party software.

Edge cases are where this discrepancy matters most. A full-time employee tasked with using half a dozen internal tools definitely sees value in SSO’s single-identity policy, especially when it comes to offboarding. Alternatively, a contractor that only ever touches Salesforce sees significantly less value in integration with an enterprise-wide identity provider – native login measures are both less complex and no less secure in their narrow use case. 

A lot of businesses use a combination of SSO and native tools in their environments, avoiding the topic of comparison entirely. In this case, SSO is processing general internal access, while native login is left for isolated or external use cases when there isn’t much point in full integration.

Key Components of the Salesforce Data Security Model

With that being said, permission management is not the only security measure Salesforce can offer. In fact, the total number of built-in security capabilities in Salesforce is surprisingly high, and we are going to try and go over most of them below.

First of all, it is important to understand what Salesforce has to do per its agreement with all clients and what is left for the end user to work with. The Shared Responsibility Model that Salesforce uses is similar to how a lot of cloud-based solutions in different fields operate. 

Salesforce is responsible for protecting its own platform and the underlying cloud infrastructure, including both hardware servers and software applications that help the platform work as intended. It is also up to Salesforce to maintain compliance with regulations and industry standards both at the platform level and the infrastructure level.

That is the extent of what Salesforce has to do; the rest of the security matters are completely in the hands of the end user – including data backup and recovery, user access control, data management, compliance management (in cases where the platform itself does not cover a specific regulation or industry rule, such as PCI DSS).

Now that we have gone over the topic of the shared responsibility model, we can finally cover the most noteworthy elements of the Salesforce Data Security Model.

Evaluating Salesforce Security With Health Check

Salesforce Health Check is used to answer the question, “Where do I start?” in terms of security vulnerabilities. It is a useful tool that can help users analyze their Salesforce environment for potential issues and offer ways to resolve them all. 

The ability to customize the stringency of the analysis is what makes it incredibly useful as a part of the SFDC (SalesforceDotCom) security model, offering plenty of insight into each company’s environment with the potential resolutions to these issues.

Strengthening Salesforce Security With Role-Based Access Control

RBAC is a well-known data security concept that provides customizable data access restrictions at scale. It relies a lot on different user roles that are used to determine the responsibilities and access levels for each user group.

The topic in question mirrors a lot of what we already covered before – a hierarchical approach to the organization’s structure, different data access levels, and so on. This system can be highly useful when configured correctly, but finding the balance between security and flexibility can be somewhat challenging in many environment types.

Protecting Salesforce Data With Encryption

It would be difficult to find a modern security system that does not use encryption in some way. Encryption itself has become one of the cornerstones for data security at this day and age, making sure that sensitive information cannot be accessed even if it was stolen or somehow misplaced. 

Encryption efforts tend to differ depending on the state of the data itself. Encryption at rest is made possible by various encryption algorithms such as AES, while encryption in transit can be implemented by using dedicated data transfer protocols (HTTPS). Salesforce offers two different encryption levels, one of which is only accessible as a part of the Salesforce Shield feature set.

Securing Sensitive Information With Salesforce Data Masking

A security technique that is slightly less common than the ones mentioned above is data masking – a way of obfuscating sensitive information by replacing it with realistic-looking fictional data. It is a very useful practice for financial details, confidential business data, PIIs, and any other data type that needs to be protected in multiple ways without affecting its part in the company’s day-to-day operations.

Salesforce Data Mask is a native solution for this exact purpose, offering the ability to replace sensitive information with masked or anonymized values when necessary. It can be used in training, testing, and development environments while also providing several different approaches:

• Pseudonymization is used to alter the information without disrupting the original structure, such as replacing real names with fake ones.
• Anonymization is completely replacing sensitive information with unidentifiable random values.
• Deletion might seem like an obvious option, but it is also considered a part of data masking – setting the value of sensitive information to blank to eliminate any exposure risk.

Data masking acts as another layer of security that decreases the risk of data exposure without disrupting the consistency of the information and also helps with compliance matters.

Enhancing the Salesforce Data Security Model With Salesforce Shield

Salesforce Shield is supposed to be a combination of advanced security measures with the primary goal of enhancing Salesforce’s existing capabilities. Shield has several primary capabilities it can offer:

• Event Monitoring, which includes extensive log creation and the ability to perform a thorough security analysis based on the information gathered. These records can also greatly assist with meeting the audit trail requirements in specific compliance frameworks.
• Transaction Security, providing real-time threat detection with the ability to change and fine-tune them when necessary with completely custom policies.
• Advanced Encryption, unlocking support for a larger number of data forms than in the original Salesforce, including files, fields, attachments, etc. This feature also covers key management, offering the ability to store customer-managed keys in external hardware security modules.
• Field Audit Trail, an elaboration on the topic of extensive audits with the ability to track data changes over time with up to 10 years of history, if such requirements are necessary for data governance or other purposes. All of the retention limits can be freely customized to satisfy all of the necessary compliance frameworks.

Managing Secure Access With Salesforce Identity

Salesforce Identity is another helpful solution in the context of information security, which can offer extensive user authentication capabilities with plenty of customization and added features. It is an Identity and Access Management tool tasked with improving information security while also simplifying the process of user identity management.

Single Sign-On is one of the primary features of Salesforce Identity, making it possible to use the same combination of credentials to access multiple services and applications, including both built-in and third-party ones. It works with various communication protocols, such as OAuth 2.0, SAML, OpenID Connect, and so on. The status of Salesforce Identity as both a service provider and identity provider makes it easy for the solution to be integrated with other similar products from Google, Microsoft, Okta, etc.

Multi-Factor Authentication is another helpful feature of Salesforce Identity, providing an extra layer of security by creating a requirement for two or more verification factors to be used for logging in – be it passwords, hardware tokens, software tokens, etc. Salesforce has a dedicated Authenticator app for this exact purpose while also supporting other MFA providers on both the software and the hardware side – YubiKey, Google Authenticator, Microsoft Authenticator, etc.

Other notable features of Salesforce Identity include:

• My Domain (custom branded login pages)
• Identity Connect (seamless integration with Microsoft AD)
• Centralized user management
• RBAC permission management
• Monitoring and auditing, etc.

Salesforce Data Security Model Best Practices

It would be easy to see how a wide range of existing measures and capabilities can make it look like the Salesforce system is completely secure if all of these measures are implemented. Unfortunately, that is not the case, and there are still plenty of potential attack vectors and other inconveniences that have to be taken care of before they can be exploited in some way.

The list below includes some of the most commonly used best practices for information security in Salesforce:

Conduct Regular Salesforce Security Audits

Regular security audits should be able to locate most, if not all, of the potential security issues and vulnerabilities in your system. The aforementioned Health Check tool is a great start, although there are multiple other examples that can also be useful in their own way:

• Apex PMD Tool
• Salesforce CLI Scanner Plug-in
• Checkmarx Code Scanner
• Clayton.io

Provide Regular Salesforce Security Training

All of your staff should be aware of how destructive data breaches are and how important security awareness is in a modern tech environment. Try to mix basic recommendations about strong passwords with common security pitfalls and the most popular attack angles for phishing scams. All of your security policies should be reviewed and updated on a regular basis to ensure the highest possible level of both security and awareness.

The lack of proper security training in place dramatically increases the risk of sensitive information being compromized through either actions or inactions of the end user. Uninformed employees are going to have a much easier time discerning phishing attacks and other social engineering practices from genuine messages.

Surprisingly enough, there are plenty of solutions and platforms that can provide extensive training and simulation capabilities to simplify the aforementioned processes. The most common examples of such software are:

• Cofense
• KnowBe4
• SANS Security Awareness

Perform Salesforce Penetration Testing

Malicious actors are not the only ones that can perform cyber attacks on your environment. Penetration testing is the same process but conducted by a trusted third party, making it possible to find potential weak spots in your security system and close them before real criminals can abuse them.

The lack of penetration testing or some other kind of vulnerability analysis makes it significantly more difficult to find vulnerabilities in your environment before they can be exploited by someone with malicious intent. The sheer variety of potential weaknesses makes it challenging to find them all without performing these tests – since practically anything as simple as a misconfigured security setting might be the gateway into your system for a cybercriminal.

Nessus can be used to scan the system for vulnerabilities, Burp Suite performs extensive security testing for web applications, and OWASP ZAP does the same while being completely open-source. Of course, this is far from a complete list, but it should be enough to provide an understanding that there are plenty of options to scan your system for weaknesses, including both third-party options and built-in solutions.

Review Salesforce Permission and Access Configurations

As we have mentioned multiple times by now, permission configurations are extremely important in an environment such as Salesforce. It should be reviewed and updated on a regular basis to reduce the possibility of permission mismanagement or other potentially malicious errors in this field.

Excessive privileges might not seem like a big problem in itself, but it opens up opportunities for a surprisingly large number of different attacks. Not only do the over-privileged accounts now have an increased chance of accidental data misuse, but it also makes these accounts prime targets for external attacks while simultaneously increasing the potential damages of an insider threat.

The permission review process can be conducted by both internal and external tools. The aforementioned Salesforce Health Check is one such solution, and there are also many other alternatives to choose from: 

• Varonis
• Vigilant Software’s Data Flow Mapping Tool, etc.

Monitor Salesforce for Unusual User Behavior

Real-time analysis and monitoring capabilities are the best possible way to detect anomalous behavior and prevent various cybersecurity incidents before they can steal or compromise sensitive information. The aforementioned Salesforce Shield is a great solution for this recommendation – with detailed activity logs capable of providing extensive visibility into user activity within the platform, as well as security analytics capabilities to inspect activity logs for signs of security breaches, unauthorized access, and other anomalies.

Failure to monitor the environment for signs of unusual behavior leads to an increased probability of many different event types, from unauthorized access to malicious activity, security breaches, and more. The lack of proper monitoring drastically limits the company’s ability to respond to threats while also providing attackers a lot more time to steal or manipulate sensitive information.

Solutions such as LogRhythm or Splunk work well as third-party alternatives to Salesforce Shield when it comes to performing continuous monitoring over a Salesforce environment.

Salesforce Logs and Evidence Collection for GDPR, SOX, and Audits

Detecting anomalies on the fly is just half the job, as regulators and auditors also expect proof of what happened in retrospect. Logs can help with that, if they remain retained and retrievable long after the action itself happened. 

GDPR and SOX are two good examples of how a single requirement can be pulled in different directions.

GDPR worries about personal data: who looked at a particular record, when, and why – as an extension of data subjects having a right to know what happened to their data. On the other hand there’s SOX, which focuses on the integrity of financial reporting, expecting the audit trail to provide information about who altered a financial data , when it happened, and if the change was authorized appropriately.

Field Audit Trail that was mentioned earlier as part of Salesforce Shield can turn this type of historical record-keeping from theoretical to practical because of its ability to to retain field history for up to 10 years at a time. 10 years is enough to cover most retention windows either regulation could ask for. Without it, companies are confined to the default field history tracking: storing only a small number of changes per field and utterly incapable of handling regulatory retention periods.

If an organization needs to produce evidence during an actual audit, retention length and specificity are going to be a lot more important than the exact regulation being applied: they have to show not only the fact that something changed, but also who changed it, under what permission set, and whether that permission was appropriate at the time.

Create a Salesforce Backup and Recovery Strategy

Information is an incredibly valuable resource for any organization, and it is very difficult to have any kind of business continuity without a proper backup and recovery system in place. Backups can serve as the means of preventing not only malicious cyber attacks but also reverting accidental data loss, data corruption instances, and more. The ability to recover information within a specific time frame is also a part of multiple compliance frameworks, be it FINRA, HIPAA, GDPR, or others.

Salesforce does not offer any built-in backup solutions, but it does have some services that can assist with data exporting, at the very least. Salesforce Data Export Service makes it possible to export Salesforce data as a set of CSV files, manually or according to a pre-defined schedule. However, it does not include metadata and can only be performed once a week (or once a month for non-enterprise users), which makes it less than ideal.Luckily, there is a large market of third-party Salesforce backup tools that offer extensive backup and recovery capabilities with different backup types, granular restore, in-depth configuration, and more. There are plenty of different options to choose from, including both solutions that specialize in Salesforce data management tasks, such as GRAX or software that can offer a boatload of other features alongside Salesforce compatibility, such as Druva or Veeam.

Follow Salesforce Secure Coding Practices

Since application development can be a substantial part of many Salesforce environments, appropriate code management should also be a top priority for such users and companies. The code in question should only retrieve the data it needs from client sites, and all of the user credentials should be stored with the appropriate security measures.

Software such as Clayton.io can also be useful in identifying various code vulnerabilities, and the principle of least privilege should be commonplace in all of your development efforts.

GRAX in a Salesforce Data Security and Recovery Strategy

GRAX differs a lot from many of its competitors when it comes to where the data ends up being stored: it replicates the client’s Salesforce data into their own environment in near-real-time. That way, companies still own and control their backups without relying on a third-party infrastructure to access this data when needed. The continuous capture model also provides point-in-time recovery capabilities, allowing businesses to roll data back to a specific moment in time when necessary – such as before some kind of problem occurred.

Designing User Access and Identity Management in Salesforce

While authentication decides who makes it through the front door, everything we explore in this section is about controlling who they talk to when they reach it. It’s all about how profiles, permission sets, roles, and sharing rules are combined to turn a verified identity into an actual, day-to-day level of access.

The Role of Profiles, Permission Sets, and Permission Set Groups

Every Salesforce user has exactly one profile. That profile used to be the primary way to control what a user can see and do, like object access, field visibility, CRUD permissions, page layouts, and login-related restrictions. The main problem of this approach only appeared once orgs started growing: any user that has even a single different access need requires a duplicate profile or a manual exception, while general profile sprawl becomes more challenging to manage at scale.

Permission sets resolve this by disconnecting additional access from the profile in question. Administrators can provide a baseline access profile to a large group of users and then extend that with targeted permission sets for the individuals or subsets that need something extra. A good example of such an approach would be a support rep who needs read access to a finance object now doesn’t have to create a completely separate profile for a single exception.

Permission set groups act as an extension for that, bundling several permission sets into one assignable unit, which becomes incredibly convenient for certain roles that consistently require the same combination of five or six individual permission sets. With permission set groups, there’s no need to assign each of those permissions separately every time.

The Influence of Roles and Role Hierarchies on Data Visibility

Profiles and permission sets determine what users can do – which objects, fields, or actions they have access to. Roles and role hierarchies work on a completely different plane, determining which specific records a user can see based on how they are positioned in relation to other users in the org. A user with full CRUD permissions for an object might still see none of the actual records in that object if their role in the hierarchy doesn’t allow it.

Making sure these two systems are distinct in practice is much more important than what one could expect at first. A common issue in this field is to assume that permissions alone assume what users can see, while record visibility is not only ignored but also decided in another place entirely.

Sharing Rules vs. Manual Sharing

Between sharing rules and manual sharing, the real difference lies in the dimensions of scale against specificity:

	Sharing Rules	Manual Sharing
Applies to	All users matching a defined criteria	One specific user, one specific record
Setup	Automatic, ongoing	Applied by hand, case by case
Best suited for	Standing access needs across a group	One-off exceptions

Sharing rules are more suitable whenever access needs to be provided to a group on an ongoing basis because those rules can apply themselves once configured. Manual sharing doesn’t have that level of scalability, but it does fill the gap for rare exception cases that can’t become the justification to build an entire rule around them.

Salesforce Data Security Recommendations for App Development

Since Salesforce App Development is a noteworthy topic in this context, we would like to dedicate another section of the article to code-related threats. Salesforce makes it possible to create Visualforce or Apex pages using Lightning Platform, among other use cases. Some of the most common aspects of application development that are important in the context of information security are:

Preventing SOQL Injection in Salesforce Applications

SOQL is a database query language that Salesforce uses to perform certain actions. If an attacker is capable of modifying unvalidated user input queries for malicious intent, it leaves the potential for malicious actions to occur. Salesforce offers a separate web page dedicated to recommendations on how to avoid SOQL injection opportunities during the development process.

Preventing Cross-Site Scripting in Salesforce

Applications that use dynamic web page content have the potential to compromise user interactions with security attackers, opening opportunities for malicious code execution, session control, and more. The issue itself is made worse by the fact that XSS does not rely on user action or authentication to activate, making it genuinely terrifying for the end user. Luckily, such scenarios can be excluded when following Salesforce’s strict guidelines on how to avoid such attacks from being launched.

Preventing Cross-Site Request Forgery in Salesforce

Most CSRF attack angles follow the same process as XSS – a dynamic web page content that opens up opportunities for the end user to be compromised, with the possibility of causing plenty of issues as a result. The primary difference between the two is that CSRF relies a lot more on user interactions to begin with, meaning that its capabilities are often limited to what the user is going to do before realizing the issue. Salesforce attempts to avoid such attacks by using anti-CSRF tokens and several other measures outlined in a dedicated Salesforce article.

The Impact of Salesforce Flows and Automation on Data Security 

An automation tool like Salesforce Flow, if configured incorrectly, could quite literally ignore the entire permission model discussed earlier in the article. These tools are not meant to have the same constraints as a user clicking their way through an application, designed to run with elevated permissions from the beginning.

Security Considerations for Salesforce Flow

At its most fundamental level, the decision behind the security posture of every Flow environment comes down to what context it runs in. A Flow that runs in System Context is always going to have full permissions against any object and field irrespective of the running user’s own permissions. Alternatively, you can build a Flow to run in User Context to make it respect the security permissions of whoever kicks it off. It’ll be the same set of permissions that a user performing the same action directly would have.

The difference is practical and comes into view fairly quickly. If your Flow, created to update a Contact record whenever a related case is closed, runs in System Context – it will make an update regardless of whether the user performing the action has any editing rights to Contacts. It’s essentially a backdoor into the system. Apply that one possibility across multiple years of work under disparate admins, and the extent to which automation represents one of the more easily overlooked origins of privilege creep in a mature Salesforce org becomes clear.

Unintentional Data Exposure and Privilege Escalation Through Automation

It’s not just System Context that opens a door into this problem. There are a number of different automation functions in Salesforce as a whole that can give users more access without explicitly meaning to do so:

• Process Builder processes
• Apex triggers and classes declared without sharing
• Flows running in System Context

Note: Process Builder support was relinquished by Salesforce as of December 31, 2025, but many of the older orgs still use it in some capacity to this day.

Each of these tools bypasses the logged-in user’s real permissions differently but all accomplish the same result: the user now has read/write capabilities for data they were never directly granted access to, made possible by an automation process. 

For organizations who have had a long history of ad-hoc automation, the risk compounds even further. Older Flow automations developed ages ago with a very specific use case remain active long after the reasoning for its permission level has been forgotten, subtly widening access with none the wiser.

Testing Salesforce Automation for Secure Behavior

The “fix” here is less about tools and more about process: each and every Flow, Process Builder process, and Apex class executed with elevated context needs to be tested against a restricted test user (not an administrator) before the time of deployment. Running that same check from time to time on existing automation could help find privilege creep before it becomes an actual issue.

Salesforce Security Tools and Practices for Developers

Aside from the potential attack angles mentioned above, Salesforce developers should also be aware of several other best practices and recommendations when it comes to coding and data sharing. For example, the Salesforce Security Scanner is a convenient way to look for different cases of insecure data handling, XSS injections, SOQL vulnerabilities, and so on.

It is also recommended that various security-related tools, such as Salesforce DX, be integrated into the development process to simplify the development process and have the ability to review code for security issues on a constant basis.

Managing Custom Application Data Access in Salesforce

Other potentially useful recommendations include delicate control over sensitive data access in custom apps, which can be managed using everything we mentioned before – sharing rules, permission sets, profiles, and so on. All custom applications should enforce data access controls and respect user roles to decrease the probability of unauthorized data manipulation.

Hardcoded access permissions should be avoided in favor of Salesforce’s security model, which is much more flexible and versatile. These custom applications should also follow all of the organization-wide defaults and sharing restrictions, if there are any, to ensure consistency in the data security process.

Securing Salesforce Integrations in Custom Applications

Custom applications do not have to stay within the borders of Salesforce, either. There are plenty of opportunities to be found in third-party app integration, but these processes should also be implemented with all the necessary precautions in mind. This includes API access limitation with the principle of least privilege and the adherence to secure encryption protocols such as TLS. Monitoring API calls on a regular basis to look for signs of abnormal activity is also a good idea.

Salesforce API access can also be provided within reason – you can implement OAuth 2.0 to simplify the logging-in process while also limiting the scope of the API access to avoid unnecessary permissions.

Configuring Connected Apps and OAuth Scopes

Every Connected App in Salesforce asks for a specific set of OAuth scopes. A principle guiding their configuration is straightforward, to “ask for no more than what the integration needs to operate”. 

Here are a few examples of the most commonly requested scopes:

• api
• refresh_token
• web
• full

At first glance, these don’t seem that much different from each other, but the actual gap between them is substantial. full provides practically unrestricted access to the org on user’s behalf. api limits the scope of integration to REST/SOAP API calls specifically. A Connected App that asks for full even though it only needs api happens often enough to be treated as common oversight in the field – quietly expanding what a compromised integration can do if it was ever exposed in some way.

Security Risks Affecting Salesforce Bulk and Streaming APIs

The risk profiles of standard REST calls and Bulk and Streaming APIs are significantly different from each other, on top of Bulk API and Streaming API not having much in common to begin with.

Bulk API is designed for large data loads in a single transaction; therefore, if integration with this API were compromised, far more records could be at risk at once compared to a standard API call. Ironically enough, its effectiveness at bulk data transfer in many ways translates directly into its detriment in case of a security failure.

Streaming API works differently. Instead of accepting an individual API request at a time, the application delivers an ongoing event data stream that makes it more difficult to monitor after the fact. There’s no single call for audit that one could look for; it’s just a continuous flow of information that has to be watched as it happens.

Secure Storage and Rotation of Integration Credentials and Access Tokens

None of the credentials or tokens used in integrations should exist in code, configuration files, or anywhere else they could be inadvertently taken to a repository. Salesforce’s Named Credentials feature is built to resolve this exact problem for the most part: allowing authentication credentials to be stored apart from the code that uses them while performing the authentication handshake for you when necessary without exposing the underlying secret at all. Rotation is just as important as storage, considering that tokens or credentials that never expire provide attackers with an unlimited time to make use of them when compromised. Every integration should have a rotation schedule, even the ones that don’t prompt for it. 

Performing Security Testing for Salesforce Custom Applications

The aforementioned security testing and monitoring should also be applied to custom apps, including both code analysis and penetration testing. Apex PMD and Checkmarx would do a great job in finding various code vulnerabilities when set up correctly. Even your CI/CD pipelines should incorporate security testing as a part of the workflow, to ensure that no code is deployed without going through a rigorous security validation process. That way, vulnerabilities can be caught and resolved early instead of being found post-deployment in a data breach of sorts.

Conclusion

Information security is one of the biggest considerations for any business in the modern world. Companies operate and process massive amounts of data continuously; a significant portion of this information becomes sensitive or valuable for one reason or another. The protection of this information without sacrificing a degree of flexibility in the existing workflows is an equally important concern for Salesforce and its clients alike.

Salesforce is responsible for the protection of infrastructure and the integrity of the platform, while Salesforce customers are themselves responsible for protection of the data of end-users since it is a function the clients should be managing themselves.

Thus, periodic revision of security strategies within Salesforce is crucial as a means of preventing data breaches in whatever form they occur. You can secure your Salesforce data now by following our recommendations in terms of best practices and security tools discussed above. The enhanced security model is just a few steps away.

FAQs

What Are the Main Components of Salesforce Data Security?

Salesforce Data Security Model consists of multiple layers of security operating in tandem, including:

• Organizational, Object, Field, and Record-level security
• Role hierarchies, sharing rules, manual sharing
• Standard and Shield-level encryption
• Event Monitoring, Transaction Security, Field Audit Trail
• Salesforce Identity capabilities: SSO, MFA
• Data masking

Why Is a Layered Security Model Important in Salesforce?

As stated multiple times throughout this article: “no individual security measure protects every possible failure point at once”. It’s the biggest reason why Salesforce’s protection efforts are spread across several standalone layers: a strong password policy is useless against a user whose role hierarchy gains them access to records they’re not supposed to see, and the lack of monitoring systems means that there’s no point in airtight field-level permissions in the first place.

A layered approach for all these mechanisms creates the possibility of oversight failure in a specific area being caught or contained by another area before evolving into a full-blown data breach.

How Can Organizations Strengthen Their Salesforce Data Security Model?

Consistency is key when it comes to data security in Salesforce. Regular reviews of permissions and sharing settings, least-privilege access model enforced for any new role, and a combination of monitoring and audit tools remaining active at all times is the bare-bones package for maintaining acceptable security level. An organization that only treats these measures as one-time events should not be surprised when they drift out of alignment with their own security model in just a year or two since initial setup.

What Salesforce Security Tools are Recommended for SOC 2 and HIPAA Compliance?

Each framework requires its own evidence, and the right tool mostly depends on which requirement has to be satisfied:

Tool	Relevant For
Field Audit Trail	Long-term change history for SOC 2 audit evidence
Event Monitoring	Access logs tied to specific users and timestamps
Salesforce Data Mask	De-identifying PII in sandboxes, relevant to HIPAA
Shield Platform Encryption	Protecting sensitive fields at rest
Third-party backup tools (e.g., GRAX)	Satisfying obligations about data recovery and retention

On their own, these tools aren’t going to grant compliance as-is. Both SOC 2 and HIPAA evaluate practices and controls instead of software licenses. These tools matter only as far as their participation in the compliance program goes when they’re properly configured and monitored.

Why Do Companies Need Salesforce Security Tools?

Salesforce has a strong permission model out-of-the-box that sufficiently protects information only when it’s configured properly and monitored as the company grows. Additional security tools aim to cover a lot of issues that default configuration can’t, be it catching misconfigurations early on or monitoring for irregular behavior. That’s not to say that any company skipping these tools immediately becomes unprotected, even though it does rely entirely on administrators not making any mistakes and no accounts being compromised ever. 

Who is Responsible for Salesforce Security?

Responsibility is split between Salesforce and the customer. The former secures the platform and its infrastructure, while the latter covers everything that happens in their org, like user access, data configuration, or compliance. This is the nature of the Shared Responsibility Model covered earlier in the article – a single most common point of confusion in Salesforce security.