Data security is not a setting, it is an architectural choice

Many organizations approach data security in Salesforce as a checklist. Turn on MFA, encrypt a few fields, run the Security Health Check and tick the box. That is understandable: Salesforce offers so many security options that it is hard to know where to begin.

But genuine data security is not a checklist. It is a coherent set of choices that determines who sees which data, under which circumstances and with which guarantees. Those choices touch the access model, the technical configuration and the operational processes simultaneously.

In this practical guide we walk through the full breadth of Salesforce data security, from the foundations to advanced measures, so that you have a clear picture of what is possible and what is relevant for your situation.

Step 1: Understand Salesforce's layered security model

Salesforce works with a layered security model in which each layer answers a specific question. It is essential to understand this model before you change configurations, because changes in one layer affect the others.

The layers from the inside out:

Organization level: the base settings that apply to all users in your Salesforce org. Think of password policy, session management, IP restrictions and login hours. This is the first line of defense.

Object level: who can read, create, edit or delete records of a specific object? This is regulated through profiles and permission sets.

Field level: which fields within an object are visible or editable? Field-level security determines which users can see or modify specific data.

Record level: which records of an object can a user actually see? This is regulated through organization-wide defaults, the role hierarchy, sharing rules and manual sharing.

Each level needs to be configured deliberately. A user who has object-level access to Accounts but at record level only sees their own accounts has a fundamentally different experience from someone with access to all accounts. Both configurations can be correct, depending on the function.

Step 2: Configure organization-wide defaults correctly

The organization-wide defaults (OWD) determine the baseline level of visibility for each object. This is the starting point for all record-level security.

The available options per object are:

• Private: users only see records they own
• Public Read Only: users see all records but can only edit their own
• Public Read/Write: users can see and edit all records
• Controlled by Parent: visibility is determined by the parent object

The golden rule is: configure OWD as restrictive as possible without hindering business operations. It is always easier to grant more access through sharing rules than to correct overly restrictive settings later on.

For most sensitive objects, such as financial data, personal data or contracts, Private is the right default, supplemented with targeted sharing rules for the exceptions.

Step 3: Design a scalable sharing model

Based on the OWD settings, you decide how records are shared with users who are not the owner. Salesforce offers several mechanisms for this:

Role hierarchy: users higher in the hierarchy automatically see the records of users lower in the hierarchy, unless this is disabled per object. The role hierarchy is intended for reporting and management visibility, not as the primary access management mechanism.

Sharing rules: automatic rules that share records with specific groups or roles based on criteria. Sharing rules are additive: they can only grant more access than the OWD setting, never less.

Manual sharing: individual users can share specific records manually with others. This is useful for exceptions but difficult to manage at scale and difficult to audit.

Apex managed sharing: programmatic sharing through code, for complex scenarios that cannot be solved with standard sharing rules. Requires solid documentation because the logic is not visible in the standard Salesforce interface.

Teams: Account Teams, Opportunity Teams and Case Teams provide a structured way to share records within a collaboration, without the need for manual sharing.

A healthy sharing model is as simple as possible. The more exceptions, manual sharing and Apex managed sharing it contains, the harder the model is to understand, manage and audit.

Step 4: Encrypt sensitive data with Platform Encryption

Salesforce Platform Encryption, part of Salesforce Shield, encrypts data at rest at the field level. Even if someone gains direct access to the underlying database, the encrypted fields are unreadable without the proper keys.

Important considerations when implementing Platform Encryption:

Not every field can be encrypted: Salesforce supports encryption for a specific set of field types. Check the compatibility matrix before you start.

Encryption impacts search and reporting: encrypted fields cannot be used in SOQL WHERE clauses, certain report filters or external search indexes. Analyze the impact on your current usage before enabling encryption.

Key management is critical: Platform Encryption works with encryption keys you manage yourself through the Salesforce Key Management infrastructure. Establish clear processes for key rotation, backup and recovery.

Step 5: Protect data in non-production environments

An often overlooked aspect of data security is the protection of data in sandboxes and other non-production environments. Developers and testers have access to sandboxes, and if those sandboxes contain production data, you have effectively bypassed a large part of your security measures.

Salesforce offers Data Mask as the solution: a tool that replaces sensitive data in sandboxes with realistic but fake data. Names are replaced by random names, email addresses by fake addresses, financial amounts by random numbers within a realistic range.

Data Mask can be configured with three levels of masking per field: anonymize, replace with random data, or replace with data from a defined list. The production sandbox remains fully functional for testing, without containing real personal data.

Step 6: Actively monitor data usage

The previous steps protect data structurally. But even with the best access controls and encryption, data can be misused by users who legitimately have access. An employee who exports their own customer database for a competitor, or an administrator who downloads reports outside their remit: these are scenarios that technical security measures alone do not prevent.

Event Monitoring, discussed in an earlier article, is the layer that makes this visible. Specifically for data security, the following event types are most relevant:

• Report events: who exports which reports, how often and how many records?
• Bulk API events: large data transfers that fall outside normal usage patterns
• Login events: login attempts from unfamiliar locations or outside expected hours

Combine Event Monitoring with Transaction Security Policies to intervene automatically on suspicious behavior, such as blocking large exports or notifying an administrator on unusual activity.

Step 7: Make data security part of your change management

Data security is not a one-off implementation. Every change in your Salesforce environment, a new object, a new field, a new integration, a new user group, potentially affects your security model.

Make data security a fixed part of your change management process:

• New objects and fields: always assess which profiles and permission sets need access, and whether the field requires encryption
• New integrations: assess which data the integration needs and limit the service account's access accordingly
• New user groups or functions: assess whether the existing sharing and access structure needs adjustment
• Periodic review: evaluate at least twice a year whether the current configuration still aligns with the organizational structure and the risk assessments

Conclusion

Data security in Salesforce is broad, layered and demands continuous attention. This guide has walked through the seven most important steps: from base settings at the organizational level to encryption, data protection in sandboxes and active monitoring.

The organizations that have set this up well share one trait: they treat data security not as an IT project but as a business responsibility. Every layer of security is a deliberate choice, documented and maintained over time.

That is the difference between a Salesforce environment that happens to be reasonably secure, and one that is demonstrably secure.

Want a practical assessment of your current Salesforce data security? Schedule a no-obligation conversation