Salesforce Data Protection: Best Practices to Strengthen Data Privacy, Security and Compliance

Customer records, financial information, sales pipelines, employee data — Salesforce routinely stores some of the most sensitive information an organization deals with. As such, the sheer scale and interconnected nature of it turns Salesforce data protection into a business-critical priority, not a simple compliance checkbox. Having a firm grasp of the risks, trust implications, and the overall regulatory landscape is the foundation for all subsequent controls.

Why Does Data Protection Matter in Salesforce?

What are the business and legal risks of inadequate Salesforce data protection?

Poor Salesforce data security results in many operational, financial, and legal risks. A misconfigured permission set, an exposed API credential, or an unencrypted field can be enough to trigger consequences that would be significantly more expensive than the cost of implementing the controls that could have prevented them.

The most significant risks organizations face include:

• Regulatory fines and penalties — For example, GDPR violations are fined €20 million or 4% of global annual revenue, whichever is greater
• Litigation exposure — Data breaches exposing customer or employee records frequently result in class-action lawsuits, expanding financial damage well beyond the initial incident
• Operational disruption — A breach or ransomware event directly impacts revenue generation in Salesforce since they often can halt sales, service, and support operations
• Loss of competitive advantage — Proprietary pipeline data, pricing strategies, and customer intelligence stored in Salesforce all represent assets that are difficult or impossible to recover once they have been exposed

Neither business nor legal risks are theoretical in their nature. Regulatory bodies have long since shown that they are willing to impose the highest penalties on organizations incapable of establishing that demonstrable and strong data protection controls were in place.

How does a Salesforce data breach affect customer trust and revenue?

Customer trust is difficult to quantify until it is lost. Whenever Salesforce data breaches reveal sensitive or financial information of an individual, customers are faced with a choice of whether to continue the relationship with the organization or not — and there is plenty of research showing that a significant portion of customers chooses not to do so.

The immediate costs are visible and often easy to quantify: breach notification, forensic investigation, and regulatory response all hit the balance sheet quickly enough. The long-term damage, on the other hand, is not always visible — and also much more difficult to reverse.

Customer churn, stalled enterprise deals, and reputational drag on partnership conversations can keep happening years after the incident itself. In companies that keep Salesforce as the system of record for customer relationships, a single breach is not just about data exposure itself, but it also undermines the very customer relationships this sensitive data represents.

Which security and compliance frameworks commonly apply to Salesforce data?

Almost all organizations that store customer or employee data in Salesforce fall under one or several regulatory frameworks. The exact framework applicable to a specific organization depends on industry, geography, and the data types the Salesforce org processes:

Framework	Scope	Salesforce Relevance
GDPR	EU personal data	Governs data subject rights, consent, retention, and breach notification for any EU resident data stored in Salesforce
CCPA / CPRA	California consumer data	Requires data inventory, deletion rights, and opt-out controls that directly affect Salesforce records
HIPAA	US healthcare data	Applies when Salesforce stores Protected Health Information (PHI); requires a BAA with Salesforce
SOC 2	Service organization controls	Relevant for SaaS vendors; auditors will review Salesforce access controls and logging practices
ISO 27001	Information security management	Requires documented controls across access, encryption, and incident response that map to Salesforce configurations
PCI DSS	Payment card data	Applies when Salesforce is used in any payment processing workflow, even indirectly

Organizations which fall under several frameworks must map their Salesforce data protection controls to each applicable framework in order to prevent redundant work and identify gaps.

What are the unique data protection challenges of a multi-tenant SaaS platform?

Salesforce works using a multi-tenant architecture, meaning that the underlying infrastructure is shared across thousands of customers at the same time. Although Salesforce does provide a strong logical separation of tenants, this model does present some data protection implications that would’ve been non-existent in single-tenant or on-premise environments.

Customers have no control over the underlying infrastructure, therefore physical security, network segmentation, and hypervisor-level controls are all within Salesforce’s purview. On the other hand, the shared responsibility model also means that configuration, access control, integration security, and data classification are all positioned squarely on the shoulders of the customer. Unfortunately, there are many misunderstandings about where this kind of boundary actually is — so much so that misunderstandings are one of the most common sources of Salesforce data protection gaps.

How Should You Classify, Inventory, and Manage Data for Salesforce Data Protection?

The process of protecting Salesforce data begins before any technical control is implemented. The first goal of any organization should be to understand what kind of data lives in their Salesforce org, where it flows, and how sensitive it is. Classification and inventory are the building blocks of all access controls, all encryption decisions, and all retention policies.

How is data collected, stored, and handled across Salesforce objects and workflows?

Salesforce ingests data via multiple sources at the same time. Web-to-lead forms, API integrations, manual entry, third-party connectors, and automated workflows all introduce records into the org, often with no transparent mechanism showing what is arriving or where it is going to land.

The core Salesforce objects that most commonly carry sensitive data include:

• Contacts and Leads — Names, email addresses, phone numbers, and often demographic data that qualifies as personal data under GDPR and CCPA
• Accounts — Business relationships, revenue figures, and contractual details
• Opportunities — Pipeline values, deal terms, and competitive intelligence
• Cases — Customer complaints, support history, and sometimes health or financial details depending on the industry
• Custom Objects — Org-specific data whose sensitivity varies widely and is frequently underdocumented

It’s important to know both where the data is stored and how it moves through workflows — including all the automation rules, Flow processes, and external integrations. Data that is used and discarded mid-workflow could still lead to compliance exposure if it was logged or cached along the way. 

What personal data, customer data, and sensitivity levels exist in Salesforce?

Not all data residing in Salesforce carries the same level of risk. A robust data classification model allows companies to implement controls that are proportionate to the risk — with stronger protections being attributed to places where exposure would cause the most harm.

The following tier model is a practical starting point for most Salesforce orgs:

Classification Tier	Description	Salesforce Examples
Public	No harm if disclosed	Marketing content, published pricing, product documentation
Internal	Low risk; intended for employees only	Internal account notes, general pipeline summaries
Confidential	Material harm if disclosed	Customer PII, contract terms, financial records, health data
Restricted	Severe harm or regulatory violation if disclosed	PHI, payment card data, authentication credentials, government IDs

Data classification becomes actionable once these tiers are applied to individual Salesforce fields. It’s completely possible for a single Contact record to contain both public data (job title) and restricted data (social security number) at the same time.

How can you discover and map where sensitive data lives in Salesforce?

It is not that common for sensitive data to stay where it was first introduced. It spreads through workflows, gets copied into reports, flows into integrated systems, and even accumulates in fields that were never designed to hold it in the first place. In order to surface what actually exists, not just what was intended, a structured data discovery process is mandatory.

The most effective approach is a combination of automated scanning tools with manual review of custom objects, Flow logic, and integration payloads. Neither automation nor manual review is enough by itself — with automation tools often missing context, while manual reviews lack the scalability.

Who should own data classification and inventory responsibilities?

Data classification is not a task that is owned exclusively by IT. Its ownership should be distributed across three primary groups:

• Data stewards that have the business context of each object
• Salesforce admin team that understands the technical structure
• Privacy or compliance function responsible for applying regulatory requirements to classification decisions

Inventories quickly go stale without a clear ownership in place. It is a good idea to assign actual named individuals (not just teams) to specific data domains, helping ensure accountability once classifications have to be updated or challenged.

How often should inventories and classifications be reviewed and updated?

Data inventory should not be considered a one-time exercise, but an ongoing process. Salesforce orgs change constantly, with new fields being added, new integrations connected, and business processes evolving. A classification that was accurate at the moment of implementation can become dangerously incomplete a mere year later.

At minimum, inventories should be reviewed annually. Beyond that baseline, specific events should trigger an immediate review:

• Deployment of a new integration or connected app
• Introduction of a new custom object or significant field additions
• A change in applicable regulatory requirements
• A security incident or near-miss involving data exposure
• Significant business changes such as a merger, acquisition, or new product line

How can organizations protect personal data and prioritize data protection during data mapping?

The data mapping process itself inherently creates risk. Mapping exercises often involve exporting field lists, object schemas, and sample records — all of which can expose the very data they’re intended to document, if handled carelessly.

Only the individuals directly involved with data mapping should have any access to mapping outputs. Sample data used for validation purposes should be either synthetically generated or anonymized instead of pulling data as-is from production records. Even access to the mapping documentation should be restricted at the same level as the sensitivity of the underlying data — while being stored in a secure location. 

Data mapping, by itself, is a compliance asset, which means that it should also be protected accordingly.

What Access Controls Are Essential for Salesforce Data Protection?

Even the most well-secured Salesforce org can become vulnerable if the wrong people can gain access to its data. Access control ensures that a user is only given visibility into and ability to interact with data that is required for their role — and nothing else. All the controls discussed in this section create the first and most important line of defense in any Salesforce data protection strategy.

How should you manage data access to ensure only authorized users can view key data?

The proper entry point into data access management for Salesforce is the configuration of an organization-wide default (OWD) setting for each object. OWDs set the lowest level of visibility that applies to every user before any role, profile, or sharing rule is assigned. Using OWDs at the most restrictive suitable level (and then opening access deliberately) is a much safer option than starting with an open security model and attempting to lock things down afterward.

Access levels should be determined by the actual job function of each user. A support agent has no need to have access to information about opportunity financials, a sales rep doesn’t require access to HR-related custom objects, etc. 

Consistently enforcing that kind of boundary and reviewing when roles change is what defines day-to-day operation of Salesforce data access management.

How should you design role-based access control (RBAC) for Salesforce?

Salesforce’s implementation of role-based access controls uses a layered model. Since each layer is applied on top of the previous one, a single miscommunication at any level would be able to either over-expose data or lead to unnecessary restriction of legitimate access.

The layers, from broadest to most granular, work as follows:

• Organization-Wide Defaults (OWDs) — Set the baseline record visibility for every object across the entire org. This is the floor, not the ceiling.
• Role Hierarchy — Determines record access based on reporting structure. Users higher in the hierarchy can typically see records owned by those below them.
• Profiles — Define what a user can do: which objects they can access, which fields they can read or edit, and which system permissions they hold.
• Permission Sets — Extend individual permissions beyond what a profile grants, without requiring a separate profile for every permission variation.
• Sharing Rules — Open access to specific records or groups of records beyond what the role hierarchy provides.
• Manual Sharing — Allows record owners to share individual records with specific users or groups on an ad hoc basis.

RBAC must be designed with each layer being treated as a deliberate decision, not a default one. The majority of organizations tend to accumulate permissions over time instead of designing them intentionally from the start, leading to consistently over-privileged users becoming a constant risk.

When should you use least privilege and permission sets vs. profiles?

Least privilege principle dictates that each user is only given the permissions required to do their job — and nothing else. Implementing the principle of least privilege in Salesforce involves actively refraining from assigning broad profiles due to their ease of deployment, choosing to create custom permission sets instead (that are based on real needs).

The primary differences between permission sets and profiles, on the other hand, is highlighted in the table below:

	Profiles	Permission Sets
Scope	Broad baseline permissions for a user type	Targeted permissions for specific functions or needs
Flexibility	One profile per user	Multiple permission sets per user
Best used for	Defining what a user cannot do	Extending what a user can do beyond their profile
Least privilege fit	Moderate — profiles tend toward over-permissioning	High — permission sets enable surgical access control

The most suitable approach here is to keep profiles minimal and use permission sets (or permission set groups) to grant specific capabilities to certain users that genuinely need them.

How can Multi-Factor Authentication (MFA) and SSO improve security?

Multi-factor authentication offers users to prove their identity via something other than their password — typically an authenticator app or a hardware token. MFA has been a requirement in Salesforce since 2022 for all direct logins. However, the unfortunate reality is that many orgs still have gaps in MFA enforcement, especially when it comes to API users, integration accounts, and users that authenticate using connected apps.

Single sign-on (SSO) works in tandem with MFA, centralizing authentication using an identity provider (Okta, Azure AD, Ping, etc.). SSO assists by reducing the overall attack surface via eliminating Salesforce-specific passwords while enforcing consistent authentication policies across the org and simplifying deprovisioning.

A combination of SSO and MFA effectively reduces the risk of credential-based attacks that are still the most prevalent attack vector for unauthorized access to Salesforce.

What strong data governance controls help keep data secure across teams?

Access control cannot operate in isolation. Data governance controls are necessary to give technical access controls their meaning and consistency in implementation — including all the policies, processes, and accountability structures determining how data is managed.

At the access level, governance is all about the following:

• Defining who is authorized to grant permissions
• Establishing a review and approval process for elevated access requests
• Ensuring that access challenges are properly documented

Without these governance elements, even a well-designed permission model is going to drift toward over-permissioning as teams make one-off exceptions that are never revisited.

What monitoring and alerting should be in place for privileged access?

Providing users with the appropriate access levels is only part of the equation. There is also the need to monitor how privileged access is used — responding accordingly whenever usage patterns suggest misuse, compromise, or error.

Key activities and events that should be monitored include:

• Login anomalies — Logins from unexpected geographies, IP addresses outside approved ranges, or at unusual hours
• Mass data exports — Large report runs, data loader exports, or API queries that retrieve unusually high record volumes
• Permission changes — Any modification to profiles, permission sets, or sharing rules, particularly outside of change management windows
• Failed login attempts — Repeated failures on a single account, which may indicate a brute-force or credential-stuffing attempt
• Access to restricted objects — Any access to objects containing confidential or restricted data by users whose role does not clearly require it

Salesforce Event Monitoring (part of Salesforce Shield) offers the logging infrastructure for most of these signals. Routing these logs to a SIEM platform introduces capabilities like real-time alerting and long-term audit retention.

How Do You Apply Technical Controls for Salesforce Data Protection?

Technical controls are the system-level mechanisms responsible for enforcing Salesforce data protection irrespective of user behavior or policy adherence. They include things like encryption, transport security, and threat mitigation measures capable of operating whether or not the user is aware of them. Being able to identify what Salesforce offers out-of-the-box and where organizational configuration is required — it’s essential for creating an effective set of controls.

What does Salesforce already do natively to protect my data?

As an active participant of the shared responsibility model, Salesforce possesses a substantial list of native security controls that are enforced at the infrastructure level and require no prior configuration from the customer side. This includes:

• Physical security — Salesforce data centers are SOC 2 Type II certified and include biometric access controls, 24/7 monitoring, and redundant power and cooling
• Network-level controls — Salesforce operates dedicated firewall infrastructure, intrusion detection systems, and DDoS mitigation at the platform level
• TLS encryption in transit — All data transmitted to and from Salesforce is encrypted using TLS 1.2 or higher by default
• Audit logging — Salesforce maintains system-level logs of platform activity, separate from the Event Monitoring logs available to customers
• Vulnerability management — Salesforce operates a continuous vulnerability disclosure and patching program across its platform infrastructure

Knowing the limits of these standard defenses is important because it shows what the customer is responsible for. Native security controls are primarily targeting the infrastructure itself, while everything above that layer becomes the organization’s responsibility to both configure and maintain.

Which data security measures and robust security standards should every Salesforce org implement?

In addition to Salesforce’s native capabilities, all orgs should implement a baseline set of measures in regards to data security. These are not supposed to be highly advanced configurations, but the bare-minimum measures that auditors, regulators, and security frameworks consistently expect to find.

A baseline Salesforce security configuration should include:

• MFA enforcement across all user authentication methods, including SSO-connected users where applicable
• IP allowlisting to restrict Salesforce access to known, trusted network ranges
• Session timeout policies configured to automatically expire inactive sessions
• Password policies that enforce minimum length, complexity, and rotation requirements
• Login hour restrictions that limit when specific profiles can authenticate
• Field-level security applied to all objects containing confidential or restricted data
• Audit trail activation with Event Monitoring enabled and logs exported to a SIEM
• Regular permission reviews conducted on a defined schedule, not just at onboarding

Data security measures like these are the foundation, while any controls that are more advanced than that (encryption, BYOK, Shield) work off of this foundation instead of attempting to replace it.

What encryption options does Salesforce provide for data at rest?

There are two fundamentally different methods for encryption at rest available in Salesforce. These options vary greatly in terms of their scale, key management, and performance implications:

	Classic Encryption	Shield Platform Encryption
Scope	Individual custom fields only	Standard and custom fields, files, attachments, and more
Key management	Salesforce-managed	Customer-managed, with optional BYOK
Search compatibility	Full	Limited — some encrypted fields cannot be searched or used in filters
Performance impact	Minimal	Moderate — encryption and decryption add processing overhead
Compliance suitability	Low-to-moderate sensitivity data	High-sensitivity and regulated data (PHI, PII, financial records)
Additional cost	Included	Requires Salesforce Shield license

Classic Encryption is more than sufficient for organizations with minor requirements in terms of encryption at rest. Meanwhile, organizations that are subject to GDPR, HIPAA, or any other data privacy laws with strong encryption controls typically have to invest into Shield Platform Encryption instead.

How can you ensure secure transport of data to and from Salesforce?

TLS (Transport Layer Security) is a cryptographic protocol applied to all data transferred between users and Salesforce. Even though TLS is enforced by Salesforce at the platform level, secure data transport still requires a certain degree of attention beyond the browser session — especially when it comes to API integrations, middleware platforms, and third-party connectors that programmatically exchange data with Salesforce.

It’s not uncommon for secure data transport to be assumed instead of verified, which is where exposure is born. Every integration endpoint that either sends of receives data from Salesforce is required to:

• Enforce TLS 1.2 or higher
• Validate certificates instead of accepting self-signed certificates without scrutiny
• Avoid transmitting sensitive field data in URL parameters (as they can be captured from there to server logs or browser history)

When should you consider bring-your-own-key (BYOK) or Shield Platform Encryption?

Shield Platform Encryption expands Salesforce’s native encryption capabilities to a much longer list of data types, such as standard fields, files, attachments, and Chatter content. It uses AES-256 encryption, making it the suitable option for any organization that stores sensitive PII (personally identifiable information), PCI (payment card industry) data, or PHI (protected health information) in Salesforce. 

Bring-your-own-key (BYOK) goes a step beyond that, allowing organizations to generate, manage, and rotate their own encryption keys independently of Salesforce’s infrastructure. BYOK works best in organizations that are under stringent regulatory requirements in terms of key custody — which includes financial services and the healthcare industry — as well as organizations whose internal security policy forbids third parties from holding their keys to sensitive data. 

Operational complexity is the biggest trade-off of the BYOK approach. The responsibility for rotating, backing up, and revoking encryption keys falls to the organizations, and a lost or corrupted encryption key can render encrypted information permanently unavailable.

What security threats most commonly put Salesforce data at risk?

Technical controls become their most effective when they are designed against real threat patterns. The most common security threats that result in data leakage from the Salesforce environment are not special or exotic. In fact, they are predictable, well-documented, and largely preventable with proper configuration.

The most common threats include:

• Credential compromise — Phishing, credential stuffing, and password reuse attacks targeting Salesforce user accounts remain the leading cause of unauthorized access
• Misconfigured sharing settings — OWDs, sharing rules, or community access configured too broadly, exposing records to users or external parties who should not see them
• Over-permissioned users — Profiles and permission sets that grant access well beyond what a user’s role requires, increasing blast radius when an account is compromised
• Unsecured API integrations — Connected apps with excessive OAuth scopes, unrotated API keys, or no IP restrictions
• Insider threats — Authorized users exfiltrating data through mass exports, report downloads, or third-party integrations
• Third-party app vulnerabilities — AppExchange applications that request broad permissions or handle data insecurely outside of Salesforce’s environment

Being aware of these security threats helps determine which technical controls should be implemented with priority. An org with a high primary risk of credential compromise needs to invest heavily in MFA and login monitoring. Alternatively, an org whose risk profile centers on insider threats should focus on Event Monitoring and data export restrictions as their primary investments.

What are the trade-offs between native encryption and application-level encryption?

Organizations with advanced security requirements sometimes implement application-level encryption — a process of data encryption that happens before said data enters Salesforce — instead of relying on Salesforce’s native encryption capabilities. There are a few notable differences between these two options, highlighted in the table below:

	Native Encryption (Shield)	Application-Level Encryption
Where encryption occurs	Within Salesforce platform	Before data reaches Salesforce
Key control	Salesforce or BYOK	Fully customer-controlled
Salesforce functionality	Mostly preserved (with some search limitations)	Significantly reduced — reports, workflows, and search may not function on encrypted values
Implementation complexity	Low-to-moderate	High — requires custom development and ongoing maintenance
Regulatory fit	Strong for most frameworks	Required by some highly regulated environments

Application-level encryption is not the most rational choice for the majority of Salesforce users. The loss of several core Salesforce capabilities like reporting, automation, and search is a significant trade-off that can only be justified by regulatory requirements that explicitly mandate customer-controlled encryption before data leaves the organization’s own systems.

How can you ensure strong data encryption so customer information remains protected?

Strong data encryption in Salesforce cannot be configured from a single setting — it’s a collection of decisions made across field classification, key management, transport security, and integration design. Companies that successfully implement it embrace encryption as an ongoing discipline instead of a one-time implementation.

The fundamental steps for ensuring strong data encryption in Salesforce include the following:

1. Start with a complete field-level inventory that identifies which data requires encryption under applicable regulations
2. Apply Shield Platform Encryption to those fields
3. Configure key rotation on a defined schedule
4. Extend the same degree of scrutiny to data in transit through every integration connected to the org
5. Review encryption coverage whenever new objects, fields, or integrations are introduced

Data encryption that was complete at go-live will develop gaps over time in the absence of an ongoing review process.

How Should API and Integration Security Support Salesforce Data Protection?

All third-party systems connected to Salesforce are entry points for unauthorized access. API and integration security is one of the most overlooked dimensions of Salesforce data protection. This happens not because organizations are unaware of it, but because the pace of new integrations being introduced quickly outruns the pace of security reviews. The end goal of this is to ensure that each connected app, middleware platform, and data sync represents a channel that must be explicitly secured.

How can you secure external integrations and connected apps?

Connected apps authenticate to Salesforce via OAuth — granting them access to org data on behalf of users or through dedicated service accounts. The level of security for an access point like this is almost entirely determined by how the connected app is configured. Salesforce does not restrict integration access by default (outside of what the authorizing user’s permissions allow).

Key controls for securing external integrations include:

• Restrict OAuth scopes to the minimum required for the integration’s function — avoid granting full access when read-only or object-specific scopes are sufficient
• Assign dedicated integration users with purpose-built profiles rather than authenticating integrations under named user accounts
• Apply IP restrictions to connected apps so that API calls are only accepted from known, trusted source IP ranges
• Enable refresh token policies that expire tokens after a defined period of inactivity rather than allowing indefinite access
• Audit connected app usage regularly to identify integrations that are inactive, over-permissioned, or no longer in use

The total inventory of connected apps in most mature Salesforce orgs include applications that were approved years ago, as well as the ones whose owners have changed and whose access was never reviewed after initiation. 

External integrations that are no longer maintained create some of the highest-risk access points in the entire org.

What best practices exist for managing OAuth tokens and API keys?

OAuth tokens provide integrations with the ability to perform actions within Salesforce on behalf of an authenticated user or service account. The security of such tokens relies entirely on the way they are issued, stored, and rotated. 

Tokens should never be embedded in the application code, and storing them in version control is also not recommended — as both of these approaches are known mistakes that can expose credentials to anyone with an access to a repository. The better approach is to store such tokens in a secrets management platform with tight access control, be it HashiCorp Vault, AWS Secrets Manager, or an equivalent.

API keys used by integrations authenticating outside of OAuth carry remarkably similar risks. Keys that were never rotated become permanent credentials — and remain valid indefinitely, making their exposure very dangerous. 

The most basic control that should always be applied here is a rotation schedule. It significantly reduces the window of exposure following an undetected compromise. Any key suspected of compromise must be disabled immediately instead of simply being rotated on the next scheduled cycle.

How should you limit API access by scope, client, and IP restrictions?

API access limitations help reduce the potential “blast radius” of a compromised integration. Even in situations where an OAuth token or API key is stolen, the damage it can deal is reduced according to the restrictions placed on the integration that holds it.

Salesforce supports several mechanisms for constraining API access:

• OAuth scope restrictions — Limit what data and actions a connected app can access, regardless of the authorizing user’s own permissions
• IP allowlisting at the connected app level — Restrict API calls to specific source IP addresses or CIDR ranges
• Per-user API access controls — Remove API access entirely from profiles where programmatic access is not required
• API usage limits — Monitor and cap the volume of API calls an integration can make within a given period, which helps detect abnormal data extraction behavior

These restrictions, when applied at both the connected app level and the user profile level, help ensure that API access controls will remain in effect even if an integration manages to authenticate under a user account with more extensive permissions.

What testing and validation should occur before deploying integrations?

Integrations are at their most vulnerable during their deployment. Configuration errors, overly broad permission grants, and untested authentication flows are all much easier to catch before integration reaches production. 

Before going live, any new integration should be validated against a specific security checklist:

• OAuth scopes reviewed against the principle of least privilege
• IP restrictions confirmed
• Token storage verified as compliant with secrets management policy
• Integration user permissions audited against what the integration actually requires

Testing must be conducted in a sandbox environment where the data classifications reflect those in production — instead of using the production itself or a sandbox with live customer records.

The integration deployment process should include not only the sign-off from the development team, but also from whoever owns the Salesforce security function — for integration security reasons. It’s important to remember that security compliance and technical correctness are different standards that both have to be met before a new external connection is granted access to production data.

What Data Backup, Recovery, and Retention Strategies Are Recommended?

Data in Salesforce is protected from unauthorized access using access controls and encryption. Backup and recovery strategies are what protects data from different kinds of loss – be it integration errors, accidental deletion, malicious action, or platform incidents. The ability to restore data quickly and completely is as important as the ability to protect it when it comes to organizations where Salesforce is a system of record.

How often should you back up Salesforce data and metadata?

Daily backups of Salesforce data is the minimum acceptable frequency for most businesses. There are also certain situations where an organization should consider even more frequent incremental backups to reduce the volume of changes in case of data loss — it’s a particularly important consideration for high-transaction orgs (processing thousands of records per day).

Metadata is, unfortunately, where many backup strategies start to fall short of expectations.

Many configuration changes (custom objects, Flow definitions, validation rules, permission sets) tend to be completely excluded from backup schedules. A deployment corrupting a critical Flow or deleting a custom object can be just as damaging as data loss, and attempting recovery without a recent metadata backup would mean rebuilding from memory or version control instead of using a known-good backup to begin with.

What options exist for native vs. third-party backup solutions?

Salesforce has two built-in mechanisms for data export: the Data Export Service that produces scheduled CSV exports, and the Metadata API that can retrieve configuration components. Neither of these was designed as a comprehensive backup solution from the get-go, and both have an abundance of nuances to them:

	Native (Data Export + Metadata API)	Third-Party Backup Solutions
Coverage	Data and basic metadata only	Data, metadata, and often attachments and files
Frequency	Weekly or monthly (Data Export)	Daily or continuous, depending on the solution
Restoration	Manual — requires re-import and mapping	Automated — point-in-time restore to specific records or objects
Relationship preservation	Not guaranteed	Maintained by purpose-built solutions
Audit and compliance features	Minimal	Built-in retention policies, access logs, and compliance reporting
Operational overhead	High	Low

These native tools work well for organizations with minimal recovery requirements and dedicated resources for managing restoration processes manually. However, third-party backup solutions purpose-built for Salesforce are going to deliver meaningfully better recovery outcomes for most production orgs — and with significantly less operational burden.

How do you define recovery time objectives (RTO) and recovery point objectives (RPO)?

Recovery time objectives determine how long an organization is going to survive with degraded data or Salesforce being unavailable before the business impact becomes unacceptable. 

Recovery point objectives, on the other hand, define how much data loss is acceptable — but measures it in time passed since the breach. An RPO of four hours would mean that the organization can accept losing up to four hours of transactions in a worst-case recovery scenario.

These two metrics directly influence most of the backup architecture decisions. An org would not be able to survive with an RTO of two hours and an RPO of one hour while only performing weekly CSV exports with manual re-import. Defining RTO and RPO beforehand helps ensure that the backup solution of an organization’s choice would be analyzed with actual business requirements in mind instead of just using whatever is available by default.

The best backup strategy is the one capable of meeting your RTOs and RPOs under incident conditions, and not just in theory.

What retention policies should you apply for regulatory and business needs?

A good retention policy design for Salesforce data needs to find a balance between regulatory requirements, business utility, and storage practicality. Keeping all data indefinitely and not having a retention policy at all is not a strategy — it is an incorrect approach that brings in compliance issues, increases storage expenses, and greatly complicates data access requests.

Retention decisions should be made at the data classification level, not the object level:

• Public and internal data — Retain for as long as operationally useful; no regulatory floor in most frameworks
• Customer PII — Retain only as long as the business relationship or legal basis for processing exists; GDPR and CCPA both establish deletion rights that must be honored
• Financial and transactional records — Typically subject to a minimum retention floor of 5–7 years under tax and accounting regulations
• Health information (PHI) — HIPAA mandates a minimum of six years from creation or last effective date
• Audit logs and access records — Retain long enough to support forensic investigation; most security frameworks recommend a minimum of one year, with 90 days in hot storage for active querying
• Backup snapshots themselves — Define a retention window for backup data that aligns with RPO requirements and regulatory obligations, then enforce it — stale backups that are never pruned create their own compliance exposure

How Can GRAX Help Keep Data Secure, Recoverable, and Audit-Ready in Salesforce?

The backup, recovery, and compliance gaps that we address in this article are not purely hypothetical — they exist in the majority of Salesforce orgs that only use native security tools. GRAX as a solution is purpose-built to close those gaps, offering comprehensive data protection capabilities for Salesforce environments that store backup copies directly in the organization’s own cloud storage environment, whether it’s AWS, Google Cloud, or Azure. Such architecture means that the organization retains complete control and ownership of their Salesforce backup data, with no intermediary holding copies being made on its behalf.

Outside of the realms of backup frequency and storage ownership, GRAX also covers the audit-readiness requirements that are becoming increasingly common in the eyes of both regulators and internal security teams. Every single record change is logged with a complete history, allowing users to reconstruct the state of any Salesforce record at any point in time. That capability facilitates data subject access requests, litigation holds, and compliance audits without the need for manual reconstruction or forensic investigation.

Recovery is where the practical difference is at its most visible. Instead of re-importing CSVs and rebuilding record relationships manually, GRAX offers the ability to conduct point-in-time restoration at the record, object, or org level — which significantly reduces recovery time while preserving relationship integrity.

For those organizations that are unable to meet their RPO/RTO requirements with Salesforce’s native export tools alone, GRAX offers the infrastructure to make those targets possible under real incident conditions.

How Can You Monitor and Respond to Threats Against SFDC Data Protection?

Detection and response parts of Salesforce data security are responsible for determining how much damage a threat is going to cause. While prevention controls are tasked with reducing the probability of an incident, monitoring and response controls are all about reducing the potential impact of said incident if prevention measures fail.

What logging and audit capabilities should you enable in Salesforce?

Salesforce creates a ton of activity data, yet nearly all of it is not captured, retained, or routed to where it can be acted on without deliberate configuration. Only a small segment of the platform activity is covered using the default audit trail — and expanding it is one of the most high-value, low-cost steps an org can take toward meaningful threat monitoring.

The logging and audit capabilities that every org should have active include:

• Setup Audit Trail — Tracks configuration changes made by administrators, including permission changes, field additions, and connected app modifications; retained for 180 days natively
• Login History — Records every login attempt, including failures, source IP, and authentication method; essential for detecting credential-based attacks
• Field History Tracking — Captures before-and-after values for up to 20 fields per object; critical for detecting unauthorized record modifications on sensitive objects
• Event Monitoring — Provides granular logs of user activity including report exports, API calls, and Lightning page interactions; requires a Salesforce Shield or Event Monitoring add-on license
• Transaction Security Policies — Real-time policy enforcement that can block or alert on specific actions — such as mass data exports — at the moment they occur
• Debug Logs — Useful during investigations to reconstruct what automated processes or API calls did at a specific point in time

It’s highly advisable to route these logs to external storage or a SIEM platform, as Salesforce’s native retention periods are short, and the audit capabilities can only offer a limited forensic value if they expire before an investigation even begins.

How can SIEM and SOAR tools integrate with Salesforce logs?

A SIEM platform — Security Information and Event Management — collects logs from the entire technological stack of an organization and applies correlation rules to locate trends that might not be obvious from a single log source on its own. 

Salesforce logs that were sent to a SIEM can be correlated with identify provider logs, network activity, and endpoint telemetry in order to detect cross-system threats. Native Salesforce connectors or REST API ingestion capabilities are present in most major SIEM platforms — Splunk, Microsoft Sentinel, IBM QRadar, etc. These connectors can usually be configured to pull Event Monitoring and login data continuously.

A SOAR platform — Security Orchestration, Automation, and Response — extends the capabilities of SIEM by automating the post-detection response actions. Once a SIEM raises an alarm about a Salesforce user performing mass export, a SOAR playbook would be able to suspend the session, notify the security team, and create an incident ticket — all completely automatically, without the need for any manual intervention.

The reduction in response time is highly important, as the window between detection and containment is where the most data loss occurs. Now, automation can close that window in ways that human-reliant processes won’t be able to match in a reliable fashion.

What does an effective incident response playbook for Salesforce look like?

It is completely normal for organizations to have a standard incident response plan in place. However, few organizations bother creating a plan that addresses Salesforce-specific scenarios. The gap between these two becomes obvious once an actual incident occurs and responders have no choice but to improvise containment steps in real-time.

The goal of an effective Salesforce incident response playbook is to pre-define the exact course of actions for each plausible scenario, including:

• A compromised user account
• A mass data export
• An unauthorized configuration change
• A confirmed data breach

In each scenario, the playbook needs to specify who is responsible for the containment procedure, what evidence must be preserved before remediation begins, who needs to be identified and when, and what criteria are going to define if the incident is declared closed or not. 

These playbooks have to be tested via tabletop exercises at least once per year. Any written procedures that were never rehearsed are highly likely to break down at the most important stage after a real incident.

When and how should you notify regulators under privacy laws and data privacy regulations?

Regulatory notification no longer remains optional once a qualifying breach has occurred. Both the obligation to report and the timeline for reporting are defined by the frameworks under which the organization operates — and the timelines in question are often a lot shorter than most teams anticipate.

Key notification windows for major frameworks include:

• GDPR’s 72-hour requirement to notify the relevant supervisory authority following discovery of a breach affecting the personal data of EU residents
• HIPAA’s 60-day window for notifying affected individuals and the Department of Health and Human Services
• CCPA’s requirement to notify affected California residents “in the most expedient time possible”

It’s also important to document the notification process itself in advance, specifying who makes the decision about the breach being notifiable, who drafts the regulatory communication, which legal counsel reviews it, and where the notification record is stored. 

Reactive handling of regulatory notifications (as in, without any pre-defined ownership decisions or templates) regularly results in missed deadlines, incomplete disclosures, and even additional penalties that follow both of the previous options.

How Do Development and Customization Practices Affect SFDC Data Protection?

If organizational security is constantly treated as an afterthought — there isn’t a single custom Apex class, Flow, or Lightning component in Salesforce that cannot be used as a potential vector for unauthorized data access. SFDC data protection is not something that ends at platform configuration, since it also includes protecting every line of custom code and every automated process that touches sensitive data. Development and customization capabilities define whether the controls established elsewhere in the org can hold up in practice.

What secure development lifecycle (SDL) practices apply to Salesforce apps?

While generic SDL frameworks cover general concepts in software security for the most part, there is a list of Salesforce-specific risks that generic guidance cannot cover in its entirety. Salesforce-specific SDL practices are outright necessary when it comes to catching certain vulnerabilities, including:

• Apex code that runs without sharing enforcement
• Flow processes that bypass field-level security
• Lightning components that expose record data through client-side JavaScript

Security reviews must be treated as a gate, not a suggestion, in order to create the foundation for a secure development lifecycle. 

Every new Apex class must be reviewed for sharing enforcement — the choice between “with sharing” and “without sharing” is not stylistic, but rather a data access decision. Every Flow that works with sensitive fields needs to be assessed for whether it could expose those fields to users without the appropriate permissions (via the underlying profile or permission set). 

Building checkpoints like these into the development process before the code can reach a sandbox is what helps prevent the far more disruptive work of remediating exposure after deployment.

How should sandboxes be configured and sanitized for testing?

Production data in sandboxes is one of the most common Salesforce security failures. Full and partial sandboxes refresh copy live records (including customer PII, financial data, and health information) into environments that are often much less secured than production, shared with broader teams, and sometimes even connected to external development tools with their own access controls.

Effective sandbox sanitization requires deliberate action before development teams gain access:

• Data masking — Replace real field values with realistic but fictitious equivalents; names, email addresses, phone numbers, and identifiers should all be masked before a sandbox is made available
• Anonymization of sensitive fields — Fields containing PHI, payment data, or government identifiers should be anonymized or replaced with synthetic values rather than simply masked
• Restriction of sandbox access — Sandbox org access should be limited to the developers and testers who actively need it, not granted to the full user base by default
• Disconnection of live integrations — Any integration that would write data back to a connected system should be disabled or redirected in sandbox environments to prevent test activity from affecting production data stores
• Refresh policies — Define how frequently sandboxes are refreshed and ensure that sanitization runs automatically as part of the refresh process, not as a manual step that can be skipped under deadline pressure

The best indication of a safe sandbox is where a developer can’t tell the difference between real and synthetic data — it should be realistic enough to still test against, but also contain nothing in it that could create compliance exposure whenever the environments are compromised.

When is field-level security and record-level sharing crucial for custom code?

Even though Salesforce enforces field-level security and record-level sharing automatically, custom Apex code would still be able to bypass both of those measures if the developers have not accounted for that beforehand. 

A class that was declared without sharing is going to ignore the entire record-level sharing model, exposing records to the current user that they would never see via a standard Salesforce page. The Schema.describeSObjectType check works in a similar fashion — if used without enforcing FLS, it returns field values that the user has no permission to view via any of the permission sets or configured profiles.

Field-level security enforcement in custom code becomes mandatory once sensitive data is involved. It is highly recommended to use with sharing option on every Apex class unless there is a specific, documented and reviewed reason to do otherwise. FLS checks should also be implemented on any code path that reads or writes fields classified as confidential or restricted. 

None of these examples are edge cases. They are among the most commonly flagged findings in Salesforce security reviews.

How can code reviews and automated scanning reduce data exposure risks?

Code reviews in Salesforce development have two primary purposes:

• Catching functional defects 
• Surfacing security gaps that individual developers may not recognize as risks

A reviewer that knows to look for without sharing declarations, hardcoded credentials, exposed API endpoints in Lightning components, and unencrypted data written to custom logging objects is greatly improving the security value of the process beyond what automated tools already provide. Creating a security-focused checklist as part of the standard pull request process is recommended to make sure that those checks are going to be performed regularly instead of relying entirely on reviewer familiarity with security concepts.

Automated scanning tools extend the abovementioned coverage to the full codebase continuously. PMD with the Apex ruleset, Salesforce Code Analyzer, and dedicated AppSec platforms such as Checkmarx and Veracode all support Salesforce-specific rules that flag common data exposure patterns in Apex and Lightning Web Components. 

Running these tools in the CI/CD pipeline — not just on demand — means that security regressions introduced by new commits are caught before they reach a sandbox or production deployment. The combination of human review for context and automated scanning for coverage is more reliable than either approach in isolation.

What Policies, Training, and Governance Are Required for Salesforce Data Protection?

Technical controls can only enforce the rules that were defined by people beforehand. Any properly configured Salesforce org will end up with data protection gaps as teams change, roles change, and business processes evolve if it doesn’t have clear policies, consistent training, and accountable governance structures. Policies and governance are not administrative overhead — they are what enables technical controls to stay relevant in time.

What core data protection policies should you establish for Salesforce users?

Most generic IT security policies are incapable of addressing the specifics of how Salesforce data is accessed, shared, or exported. Salesforce-specific policies are necessary so that they would account for the platform’s unique capabilities, setting clear expectations for users at every permission level.

Policies that every Salesforce-using organization should have formally documented include:

• Acceptable use policy — Defines what users may and may not do with Salesforce data, including restrictions on personal device access, data export for personal storage, and sharing records outside approved channels
• Data classification and handling policy — Specifies how each sensitivity tier should be treated within Salesforce, including which fields may be exported, who may view restricted data, and how data should be disposed of when no longer needed
• Access request and provisioning policy — Establishes the process for requesting, approving, and revoking Salesforce access, including timelines for deprovisioning departing employees
• Incident reporting policy — Defines what constitutes a reportable security event in Salesforce, who to notify, and what information to preserve when reporting
• Third-party and integration policy — Sets requirements for how connected apps and external integrations are approved, audited, and revoked

Policies without enforcement are nothing else but aspirational documents. Each policy has to specify who’s responsible for compliance monitoring and what the consequences for violation would be.

How should you train employees and admins on secure Salesforce practices?

The primary focus of the end user training should be the actions and behavior most likely to compromise the data:

• Recognizing phishing attempts targeting Salesforce credentials
• Understanding what data they are permitted to export and where it may be stored
• Knowing how to report suspicious activity or accidental disclosure

It isn’t enough to deliver training during onboarding and never again. Any users who regularly access sensitive Salesforce data should be trained annually, and when significant policy changes occur.

There is also a higher technical bar associated with admin and developer training. The individuals who configure permissions, deploy code, and manage integrations need a good understanding of Salesforce’s security model — sharing architecture, FLS enforcement in Apex, OAuth scope management, and Event Monitoring interpretations. 

General security awareness training does not cover the secure Salesforce practices for admins — they require platform-specific education via Salesforce Trailhead security modules, dedicated security certifications, or structured internal knowledge transfer from more experienced practitioners.

How do privacy policies, privacy laws, and General Data Protection Regulation requirements shape Salesforce governance?

Privacy laws don’t simply impose obligations on data — they impose obligations on the systems and processes that handle it. 

GDPR demands that organizations can demonstrate that personal data is processed lawfully, stored only as long as necessary, and protected by appropriate technical and organizational measures. All these requirements translate directly into Salesforce governance decisions:

• Which fields hold personal data
• Who has access to them
• How long records are retained
• What controls prevent unauthorized processing

The practical implications for governance mean that the privacy rules have to be mapped to actual Salesforce configurations and policies instead of being handled at the organizational level alone. 

The Article 30 of GDPR (record of processing activities) should include Salesforce as a named processing system with documented data flows, retention periods, and access controls. CCPA-compliant organizations have to be able to fulfill deletion requests that include Salesforce records — implying that they need to know exactly where personal data lives, as well.

Who should sit on a data governance council and what decisions should they make?

A data governance council is the group responsible for making and enforcing the decisions keeping Salesforce data protection policies consistent, up-to-date, and aligned with both business needs and regulatory requirements. In the absence of a named group with clear authority, governance decisions are defaulting to whoever happens to be involved in a given incident or project — producing inconsistent outcomes and diffusing accountability.

The council should include the Salesforce platform owner or lead administrator, a representative from the legal or compliance function, the data privacy officer where one exists, a representative from the business units that are the primary Salesforce users, and the information security function. The decisions within the council’s scope should include: 

• Data classification changes
• Access policy exceptions
• New integration approvals
• Retention policy updates
• The organization’s response to changes in applicable privacy law

Representation matters less than clarity of mandate — a small council with well-defined decision rights will outperform a large one where nobody is certain what requires a formal decision. 

How do you measure maturity, ensure compliance, and strengthen your Salesforce data protection program?

If you can’t measure your data protection program — you can’t improve it, either. Most organizations have a better picture of their Salesforce feature adoption than their security maturity. In a situation like this, gaps persist not from the lack of effort, but from the lack of visibility into where the program actually stands.

The following maturity model provides a practical self-assessment framework:

Maturity Level	Characteristics	Typical Gaps
Initial	Ad hoc controls, no formal policies, reactive response to incidents	No data inventory, inconsistent access control, no backup strategy
Developing	Basic policies documented, MFA enforced, annual access reviews	Incomplete classification, limited logging, no incident playbook
Defined	Formal governance structure, classification applied, monitoring active	Gaps in integration security, sandbox sanitization inconsistent
Managed	Controls measured and tracked, regular audits, SIEM integration active	BYOK not implemented, training not role-differentiated
Optimizing	Continuous improvement cycle, automated compliance monitoring, proactive threat hunting	Program refinement rather than gap remediation

It’s important to note that the progress between these levels is not linear — organization can be at the Managed level for access controls and at the Initial level for integration security simultaneously. The most productive use of this framework is to identify what domains are lagging in relation to others and invest into them directly instead of pursuing uniform advancement across all areas at the same time.

FAQ

Can deleted Salesforce records still expose compliance risk if backups are incomplete?

Yes — deleted Salesforce records remain in the Recycle Bin for up to 15 days and may persist in backup snapshots, audit logs, and integrated systems long after they are removed from the org itself. Organizations subject to GDPR or CCPA deletion rights must account for every location where a record exists (not just the primary Salesforce object) to fulfill a deletion request completely.

How do third-party AppExchange apps impact Salesforce data privacy?

AppExchange applications frequently request broad OAuth permissions and may process or store Salesforce data outside of the platform in environments that are not subject to your organization’s security controls. Every AppExchange app in use should be reviewed for: 

• the data it accesses
• where that data is stored
• whether its privacy practices align with the regulatory obligations that govern your Salesforce org

What happens to Salesforce data protection when employees leave the company?

An employee’s departure creates two distinct risks: 

• the window between their last day 
• the deactivation of their Salesforce account — during which their credentials remain valid, and the data they may have exported or transferred prior to leaving

Deprovisioning should be executed on the employee’s last active day as a non-negotiable process step, and Event Monitoring logs should be reviewed for unusual export activity in the period leading up to the departure.