Most Salesforce security failures aren’t caused by the platform—they come from overlooked configuration gaps, over-permissioned users, and integrations that silently widen your attack surface. In an environment this customizable, ad-hoc fixes won’t cut it. You need a clear, repeatable set of steps that exposes hidden risks and strengthens your security posture before attackers exploit it.

This playbook organizes Salesforce security into four domains: governance, identity, data protection, and continuous monitoring. Each domain includes practical tasks you can apply immediately to reduce risk and maintain a consistently resilient environment.

1. Establish Governance and Compliance Requirements

Salesforce governance starts with a regulatory question: which laws control how data flows through the platform? Organizations that postpone this analysis until deployment face expensive retrofits when auditors identify compliance gaps requiring architectural changes rather than simple policy updates.

Map Compliance Requirements to Platform Governance

Modern compliance requirements create technical constraints that must inform platform design from day one. 

• GDPR mandates data portability and erasure mechanisms affecting backup retention policies
• HIPAA requires audit trails comprehensive enough to reconstruct access patterns months after incidents occur.
• FedRAMP demands network segmentation that constrains integration architectures

These translate directly into Salesforce capabilities that must be enabled, configured, and monitored. Transforms regulatory language into platform-specific controls through formal mapping documentation. 

• Field-level encryption satisfies GDPR Article 32 requirements for protecting personal data during processing
• Event Monitoring provides the access logs HIPAA §164.308 demands
• Tamper-proof backup storage addresses GDPR's data integrity mandates and HIPAA's contingency planning requirements
• Role-based access control through Profiles and Permission Sets implements the least-privilege principle appearing across every major framework

This mapping creates shared language between compliance officers who speak in regulatory requirements and technical teams who work in platform capabilities. The resulting artifact becomes the foundation for audit responses, demonstrating that security architecture stems from regulatory analysis.

Operationalize Compliance Through Structured Ownership

Documentation alone doesn't enforce compliance; operational governance translates requirements into daily workflows. Security champions embedded in each business unit gain authority to halt releases that break established baselines. Change control boards review high-risk modifications: third-party application installations, permission scope expansions, integration architectures that move data across boundaries. Each review requires documented risk assessment tracing proposed changes back to the compliance mapping.

These human review processes catch deliberate changes that require compliance evaluation, but they can't scale to validate every code commit or configuration adjustment developers make throughout the workday. Manual gates work for major releases; continuous delivery demands automated enforcement.

Modern release pipelines close this gap by integrating code quality scanners, policy verification engines, and separation-of-duties checks that execute on every commit. When developers add permissions violating the least-privilege matrix, automated blocks prevent merge while alerting security champions. The combination of human oversight for strategic decisions and automated validation for tactical changes shifts compliance enforcement from periodic audit preparations into continuous validation.

With governance structure operational, attention turns to identity: the authentication and authorization controls that satisfy regulatory requirements while blocking credential compromise patterns driving current breaches.

2. Implement Identity and Access Controls

Identity-based attacks succeed because stolen credentials make attackers appear as legitimate users until they export data or modify critical configurations. Traditional perimeter defenses can't distinguish compromised accounts from authorized access. An attacker with valid credentials bypasses firewalls, intrusion detection systems, and network segmentation entirely. The solution requires identity controls that authenticate continuously and limit damage even when credentials are stolen.

Establish Security Baseline and Enforce Authentication Requirements

Security posture becomes measurable through the Security Health Check available in Setup > Security > Health Check. This assessment compares org configuration against Salesforce-recommended baselines, highlighting the riskiest gaps:

• Relaxed password policies
• Inactive session timeouts
• Profiles with excessive permissions

The resulting score provides executives and auditors a single metric demonstrating security program maturity, while "High Risk" findings identify the exact misconfigurations attackers scan for during reconnaissance.

With baseline documented, multi-factor authentication becomes the first technical control:

1. Navigate to Setup > Identity > MFA and require MFA for all interactive users
2. Select strong factors such as Salesforce Authenticator, hardware security keys, or biometric authentication
3. Set "Session Security Level Required at Login" to High Assurance
4. Convert API-only and integration users to certificate-based authentication flows
5. Monitor remaining gaps through Identity > MFA dashboards for personal access tokens lacking multi-factor protection

Centralize Authentication and Eliminate Password Sprawl

Each password creates attack surface. Single Sign-On (SSO) eliminates that surface by routing authentication through a central identity provider where conditional access policies already exist. Configure SSO with standard authentication protocols (SAML, OpenID Connect) to subject Salesforce logins to the same device compliance checks, geographic restrictions, and risk-based authentication enforced across other enterprise applications. Set "Login via SSO only" on profiles to block native credentials entirely.

This consolidation compounds security improvements: when identity teams deploy passwordless authentication or enhanced behavioral analytics at the identity provider level, those protections immediately apply to Salesforce without additional configuration. The security benefit increases over time as identity infrastructure matures.

Apply Least Privilege Principles Across All Access Layers

With authentication strengthened, attention shifts to authorization: ensuring authenticated users access only what their role requires. Start with role hierarchy review, checking for unnecessary "view all" or "modify all" rights that grant visibility beyond job requirements. Examine profiles for unused object and field permissions; access reviews frequently reveal that substantial portions of assigned permissions go unused, representing attack surface with zero business value.

Permission sets provide more surgical precision than profiles allow. A sales operations analyst needs the opportunity to edit rights during quarter-end processes, not year-round. Create targeted permission sets aligned to specific job functions, then assign them with time bounds when possible. Quarterly access reviews transform least privilege from one-time cleanup into a continuous discipline that adapts as roles evolve.

Third-party applications represent another privilege layer requiring scrutiny:

• Inspect connected apps and revoke authorization scopes exceeding minimum need
• Define tight login IP ranges on high-privilege profiles, allowlisting only trusted corporate gateways
• Enable "High Assurance" sessions for sensitive operations requiring re-authentication when users move outside controlled networks

Many applications request broad data access during installation, but use only a fraction of granted permissions in practice.

Implement Session Protections Against Credential Theft

Authentication and authorization determine who gains access and what they can do; session controls limit exposure after successful login:

• Set idle timeouts based on user role and data sensitivity, forcing re-authentication during periods of inactivity
• Enable "Lock sessions to the IP address from which they originated" to prevent stolen session identifiers from working on different networks

These controls operate silently during normal use but create significant friction for attackers. An attacker who steals a session token finds it worthless if locked to the victim's IP address. Idle timeouts close the window of vulnerability from unattended workstations. The combination defends against the period between initial compromise and detection.

Identity controls validate who accesses the platform and restrict what they can do, but even properly authenticated users can expose data through misconfiguration, accidents, or coercion. Data protection controls defend against these scenarios.

3. Protect Data Integrity and Availability

Encryption and access controls protect data during normal operations, but only a tested backup enables recovery when prevention fails. Data breaches average $4.35 million per incident, with greater costs from lost trust and downtime. Three complementary protections work together to safeguard data: encryption defends confidentiality while data is accessed, field-level restrictions limit who can see decrypted information, and comprehensive backup ensures rapid recovery from deletion or corruption.

Implement Encryption for Sensitive Data

Shield encryption operates at the application layer, meaning data remains encrypted in backups, logs, and database storage while allowing Salesforce to process it for workflows and reports. Standard encryption enables exact-match searches and maintains referential integrity for lookups, making it suitable for identifiers like account numbers. Advanced encryption provides stronger protection for truly sensitive data like social security numbers, but prevents any search or matching operations.

Before deploying Shield:

• Create an inventory of candidate fields, as encrypted field length varies by type
• Identify fields where search or formula operations are required
• Note that certain formula outputs remain ineligible for encryption

Understanding these distinctions prevents deployments that either over-encrypt and break functionality or under-encrypt and leave sensitive data exposed.

Enforce Field-Level Access Restrictions

Field-level security creates defense in depth beyond encryption by ensuring that even users with record access cannot view specific sensitive fields. This granular control matters because encryption keys eventually reach authorized users who can decrypt data. Field-level security adds a second authorization check that persists regardless of encryption status.

To enforce restrictions effectively:

• Run "Field Accessibility" audits to surface who can read or edit high-risk fields across profiles, permission sets, and role hierarchy
• Remove unused permissions and tighten sharing rules, especially for external apps with broad authorization scopes
• Combine with record-level sharing rules defaulting to private

External integrations frequently receive broader field access than necessary because developers grant full object permissions rather than specific field lists, creating unnecessary exposure that field accessibility audits reveal.

Deploy Comprehensive Backup Strategies

Backup frequency must match acceptable data loss windows, typically measured in recovery point objective. Daily backups mean accepting up to 24 hours of data loss, which fails to meet requirements for high-velocity organizations processing thousands of records daily. More frequent incremental backups reduce potential data loss without proportionally increasing storage costs because they capture only changed records.

The platform's weekly export and Data Recovery Service lack the speed and granularity most enterprises need. A comprehensive approach includes:

• Daily incremental backups capturing only changed records
• Weekly full backups for baseline recovery points
• Monthly archive backups are stored outside production
• Solutions like Flosum Backup & Archive that let administrators launch backups and restores inside Salesforce while actual data resides in encrypted external storage
• Restore capabilities at any level, from a single field to the entire org

External storage matters for ransomware defense; separating backup storage from production systems prevents attackers from destroying both simultaneously, making independent backup storage essential for business continuity.

Encryption, field-level security, and backup protect data at rest and enable recovery, but these static defenses cannot detect emerging threats or stop attacks in progress—continuous monitoring closes that gap.

4. Continuously Monitor and Respond to Threats

Attackers probe for misconfigurations, dormant authorization tokens, and unmonitored behavior continuously. Static defenses prevent some attacks but cannot detect threats already inside the perimeter or adapt to changing attacker tactics. Real-time monitoring detects suspicious activity as it occurs, automated policies block risky actions before data leaves the platform, and disciplined incident response transforms detection into containment. Together, these create a closed feedback loop that identifies threats, prevents damage, and refines controls based on actual attack patterns.

Deploy Comprehensive Activity Monitoring

Event Monitoring tracks every significant interaction: logins, report exports, API calls, permission changes, and mass data operations. This creates an immutable audit trail that reconstructs attacker actions during forensic investigations and proves control effectiveness during compliance audits.

Raw logs alone overwhelm security teams with noise. Correlation engines solve this by applying threat intelligence and behavioral baselines to surface genuinely suspicious patterns: bulk record exports from new geographic locations, permission escalation immediately before data access, API activity volumes inconsistent with normal usage. Advanced implementations feed these events into behavioral analytics platforms that build per-user baselines and flag deviations, catching insider threats and compromised accounts that simple rule-based detection misses.

To implement effective monitoring:

• Enable Event Monitoring in Setup to track login, data export, report, and API activity
• Stream events to Security Information and Event Management (SIEM) platforms for correlation with threats across other systems
• Configure automated anomaly detection to flag suspicious data download spikes or permission set changes
• Establish baseline activity patterns before tuning alert thresholds

Implement Automated Enforcement Policies

Monitoring identifies threats; enforcement stops them. Transaction Security Policies evaluate every event and block risky activity before data leaves the platform, rather than discovering violations hours later in log analysis. This real-time enforcement prevents data exfiltration during the narrow window between compromise and detection that attackers exploit.

Policy design requires balance. Overly restrictive rules generate false positives that train users to seek workarounds, while permissive rules fail to block actual threats. Effective policies start narrow, targeting only the riskiest actions, then expand coverage as security teams validate detection accuracy.

Common Transaction Security Policy use cases include:

• Preventing record exports outside business hours
• Blocking logins from untrusted IP ranges
• Requiring additional authentication for sensitive object access
• Generating audit trails when high-privilege users modify security configurations

Gain Unified Visibility Across Environments

Organizations running multiple Salesforce instances face fragmented visibility. Security configurations diverge between production, sandbox, and development environments. Production maintains strong controls while lower environments relax restrictions, creating privilege escalation paths when developers migrate code upward.

Security Center provides a unified dashboard that aggregates security posture across multiple Salesforce instances. Rather than logging into each org separately to run Health Checks or review event logs, administrators view consolidated metrics showing where configurations diverge and which environments fall below security baselines.

This centralized visibility enables several critical capabilities:

• Monitor weak password policies and inactive users with elevated permissions across all orgs
• Detect configuration drift between production and non-production instances
• Surface inconsistent security implementations across business units running separate Salesforce instances
• Enable enterprise security standards that survive organizational silos

Establish Incident Response Workflows

Detection without response wastes monitoring investment. Incident response playbooks transform chaotic security events into structured workflows that minimize damage and capture learning. Pre-defined severity thresholds determine escalation paths and response timelines, preventing both under-reaction to serious threats and over-reaction to routine events.

Effective incident response follows a structured process:

1. Triage incidents quickly upon detection using severity criteria
2. Contain threats by revoking compromised tokens, freezing accounts, or blocking IP ranges
3. Eradicate root causes by correcting the misconfiguration or vulnerability that enabled the incident
4. Recover by restoring affected data from backup and validating system integrity
5. Review events in post-incident meetings to identify detection gaps and control weaknesses

Organizations that document and rehearse these playbooks through tabletop exercises respond faster and more effectively when real incidents occur. Post-incident reviews feed improvements back into monitoring rules and preventive controls, closing the feedback loop.

Active monitoring and disciplined response generate immutable evidence for regulatory audits while proving continuous improvement to executives. This closed loop ensures technical controls satisfy the regulatory mandates established in section one while adapting to evolving threats discovered through detection.

Build Continuous Security Posture Management

Security controls degrade without continuous maintenance. Permission creep, monitoring rule staleness, and configuration drift accumulate as integrations multiply and teams expand. Quarterly reviews that trigger root cause analysis rather than checkbox remediation keep controls effective over time.

The shared responsibility model places configuration, monitoring, and response with the organization, yet most teams lack dedicated security resources to maintain these disciplines consistently. Salesforce-native security automation embeds security operations directly into the platform where data and configuration already reside, allowing smaller teams to maintain enterprise-grade security posture without proportional headcount expansion.

Request a demo with Flosum to see how Salesforce-native DevOps and backup automation strengthen identity controls, data protection, and threat monitoring while maintaining the deployment velocity compliance-focused organizations require.