Salesforce security failures rarely originate from platform vulnerabilities. They stem from misconfigurations, governance gaps, and integration blind spots that organizations create through everyday operations. Active threat groups exploit this reality: the FBI and CISA identified UNC6040 and UNC6395 specifically targeting OAuth tokens and third-party integrations to compromise Salesforce environments, while data breaches continue to cost organizations an average of $4.4 million globally.

Managing Salesforce risk effectively requires a proactive, layered security strategy that addresses these threats at their source. Most vulnerabilities arise from what organizations do with the platform, not from Salesforce itself. By implementing intentional and preventive controls across platform configuration, development pipelines, and integration security, enterprises can significantly reduce exposure while building Salesforce environments that remain trustworthy and resilient at scale.

This article delivers a practical framework for that transformation, including the monitoring and automation capabilities that enable continuous validation at enterprise scale.

Understanding Configuration Risk

Configuration errors represent the primary vulnerability in cloud environments, fundamentally shifting security priorities from infrastructure hardening to configuration management. Understanding the specific types of misconfigurations that expose Salesforce data provides the foundation for implementing effective controls.

Platform misconfigurations fall into four categories that directly affect data access and user permissions:

1. Sharing rules granting excessive access beyond business requirements
2. Profile permissions enabling unauthorized actions on restricted objects
3. Permission sets bypassing intended access restrictions
4. Organization-wide defaults exposing sensitive records to all users

These configuration errors carry consequences beyond theoretical risk. Misconfigured Salesforce Community sites have exposed private case details containing customer data, financial records, and protected health information to unauthenticated users. Because these vulnerabilities stem from how organizations configure Salesforce rather than from platform defects, prevention requires understanding which controls are mandatory versus discretionary under the regulatory frameworks that govern different industries.

Regulatory Requirements That Drive Security Architecture

Regulatory compliance determines which security controls are mandatory versus optional, making requirements analysis the essential first step before implementing technical measures. Five major frameworks govern Salesforce implementations depending on the industries organizations serve and the types of data they process: GDPR for EU personal data, HIPAA for Protected Health Information, PCI-DSS for payment card data, SOX for financial reporting data, and FedRAMP for government cloud services.

GDPR: Data Protection by Design

GDPR applies to organizations processing personal data of EU residents regardless of where the organization is located. Salesforce's GDPR documentation establishes that customer organizations are data controllers responsible for implementing Article 32 technical measures that protect personal data throughout its lifecycle:

• Encryption of personal data during storage and transmission
• Role-based access controls limiting data access to authorized personnel
• Ability to ensure ongoing confidentiality and integrity of processing systems

Organizations face maximum fines reaching €20 million or 4% of annual global turnover for serious violations, creating significant financial exposure that makes GDPR compliance a priority for organizations processing EU personal data.

HIPAA: Technical Safeguards

HIPAA governs healthcare entities and their business associates who handle Protected Health Information in any form. The HHS Office for Civil Rights enforces penalties from $1,000 to $50,000 per violation, with annual maximums between $1.5 million and $1.9 million per category.

Organizations handling Protected Health Information in Salesforce must implement specific technical safeguards that protect data throughout its lifecycle:

• Unique user identification enabling activity attribution to individual users
• Encryption at rest and in transit protecting data during storage and transmission
• Audit controls tracking all PHI access with tamper-proof logs
• Integrity controls verifying data is not improperly altered through checksums or validation
• Audit log retention supporting investigation and compliance verification

These safeguards create the technical foundation for HIPAA compliance while providing security benefits that extend beyond regulatory requirements.

PCI-DSS: Cardholder Data Protection

PCI-DSS applies to any organization that stores, processes, or transmits payment card data. The PCI Security Standards Council maintains twelve interconnected security requirements that create defense in depth for cardholder data protection:

• Restricting access to cardholder data by business need-to-know
• Identifying and authenticating access to system components using unique IDs
• Tracking and monitoring all access to network resources with tamper-proof audit trails
• Prohibition on storing Primary Account Numbers in clear text without tokenization or encryption

These requirements establish minimum security baselines that organizations must meet to process payment card transactions through Salesforce.

SOX: Internal Controls Over Financial Reporting

SOX applies to publicly traded companies and mandates internal controls ensuring financial data accuracy. Section 404 requires specific controls that prevent fraud and ensure data integrity:

• Segregation of duties preventing single individuals from controlling critical financial processes end-to-end
• Role-based permissions aligned with job functions enforcing need-to-know access
• Change management controls requiring documented approval for configuration changes affecting financial data
• Comprehensive audit trails documenting all changes with user attribution and timestamps

SOX requirements focus specifically on the integrity of financial reporting systems, making Salesforce configurations that affect financial data subject to rigorous control requirements.

FedRAMP: Federal Cloud Security Standards

FedRAMP applies to cloud service providers offering services to U.S. federal agencies, establishing standardized security requirements based on NIST Special Publication 800-53 controls. Salesforce maintains FedRAMP authorization for government cloud offerings, but customer organizations must implement their own controls to achieve authorization for systems built on the platform.

Authorization levels correspond to data sensitivity classifications under FIPS 199, with each level requiring progressively more stringent controls:

• Low: Systems where loss of confidentiality, integrity, or availability would have limited adverse effect on operations or assets
• Moderate: Systems where loss would have serious adverse effect, representing the baseline for most federal implementations
• High: Systems where loss would have severe or catastrophic effect, requiring the most comprehensive control implementation

Organizations pursuing FedRAMP authorization must implement specific technical controls that align with other regulatory frameworks:

• Access control mechanisms enforcing least privilege and separation of duties
• Audit logging capturing all security-relevant events with tamper-proof retention
• Continuous monitoring providing ongoing security assessment rather than point-in-time authorization
• Incident response capabilities enabling rapid detection, reporting, and containment
• Encryption protecting data at rest and in transit using FIPS 140-2 validated cryptographic modules

FedRAMP's continuous monitoring requirement distinguishes it from frameworks that focus primarily on point-in-time compliance. Organizations must demonstrate ongoing security posture through regular vulnerability scanning, configuration monitoring, and annual assessments that verify controls remain effective throughout the authorization period.

Shared Control Objectives

Despite differing in specific requirements and enforcement mechanisms, these regulatory frameworks converge on common control objectives that inform security architecture design. Understanding these shared objectives enables organizations to implement unified controls that satisfy multiple regulations simultaneously rather than creating separate compliance silos.

All frameworks require:

• Access management that restricts data to authorized users based on legitimate business need
• Encryption that protects data during storage and transmission to maintain confidentiality even if the infrastructure is compromised
• Audit trails that document all access and modifications to enable forensic investigation when incidents occur
• Retention policies that manage the data lifecycle from creation through deletion according to regulatory timeframes
• Incident response capabilities that enable breach notification within regulatory deadlines 

These shared control objectives provide the foundation for the security control architecture detailed in the following section.

Security Control Architecture

Effective Salesforce security requires implementing controls across four distinct layers that address different attack vectors and operational stages. Each layer operates independently but reinforces protections from other layers, creating defense in depth that remains effective even when individual controls fail.

The four layers work together to provide comprehensive protection:

1. Platform configuration governs user interactions with data through permissions, sharing rules, and access controls
2. Development pipeline prevents vulnerabilities from reaching production through automated validation and code review
3. Integration security protects connections to external systems where data crosses trust boundaries
4. Monitoring and detection provides visibility into system activity, enabling rapid identification of threats that bypass preventive controls

This layered approach ensures that security does not depend on any single control functioning perfectly. When preventive controls fail, detective controls identify the breach. When configuration errors occur, pipeline validation catches them before deployment. When integrations are compromised, monitoring detects anomalous behavior.

Platform Configuration Controls

Platform configuration establishes the baseline security posture that governs every user interaction with Salesforce data. These controls operate at runtime to enforce permissions whenever users attempt to view records, access fields, or execute functionality, making proper configuration essential before users gain system access.

Organization-Wide Defaults

Organization-wide defaults set the foundation by establishing the most restrictive access level that meets business requirements, then using additional mechanisms to grant access where business processes require it. The Salesforce Security Implementation Guide establishes that effective data governance begins with a default-deny approach that grants access explicitly rather than restricting it after the fact.

Organizations should configure defaults based on data sensitivity and business requirements:

• Private: For custom objects containing sensitive data requiring explicit sharing for access
• Public Read Only: For reference data that all users need to view but not modify
• Controlled by Parent: For detail objects in master-detail relationships inheriting security from parent records

These defaults create the baseline security posture that subsequent sharing rules and permission sets build upon.

Role Hierarchies

Role hierarchies enable appropriate visibility up organizational reporting lines while maintaining horizontal segregation between departments or business units. Effective hierarchy design balances operational needs with security constraints, ensuring managers can supervise their teams without gaining unnecessary access to unrelated data.

Organizations should limit hierarchy depth to maintain query performance, as deeper hierarchies increase the computational cost of sharing calculations. Configure "Grant Access Using Hierarchies" on a per-object basis rather than globally to ensure hierarchical access aligns with business requirements:

• Enable: For sales objects where managers need visibility into their team's pipeline and forecasting data
• Disable: For sensitive objects containing HR records, financial data, or protected health information where organizational reporting should not automatically grant access

Role hierarchies provide the organizational structure that enables appropriate managerial oversight while maintaining security boundaries.

Sharing Rules

Sharing rules enable controlled access expansion based on specific criteria when business processes require cross-organizational collaboration that role hierarchies cannot accommodate. Each sharing rule creates an exception to organization-wide defaults, granting access that would otherwise be restricted.

Organizations should document business justification explaining why cross-organizational access is required for operational processes, and include regulatory compliance rationale demonstrating how the access satisfies legitimate need-to-know under applicable frameworks. This documentation facilitates audit preparation and enables periodic access reviews to remove rules no longer needed. Sharing rules provide the flexibility to support complex business processes while maintaining auditability.

Field-Level Security

Field-level security provides column-level protection that enforces restrictions regardless of how users access data. Relying solely on page layouts to hide sensitive fields creates a false sense of security that fails when users access data through APIs, reports, list views, or mobile applications that ignore page layout restrictions.

Field-level security enforces restrictions at the database level regardless of access method. Organizations should configure field-level security for all fields containing data types that regulatory frameworks specifically protect:

• Personally identifiable information covered by GDPR and privacy regulations
• Protected health information governed by HIPAA requirements
• Payment card data regulated by PCI-DSS standards
• Financial reporting data subject to SOX internal controls

Field-level security ensures that access controls apply consistently across all channels through which users access Salesforce data.

Profiles and Permission Sets

Profiles and permission sets work together to define what users can do within Salesforce, with profiles establishing baseline capabilities and permission sets adding specialized access. Profiles establish standard access levels for broad user categories, defining object access, field permissions, page layouts, and system permissions. Permission sets provide additional permissions beyond the profile baseline without creating profile proliferation that becomes difficult to manage.

Organizations should validate configurations regularly to ensure permissions align with business requirements and security policies:

• Only System Administrator profile has View Setup and Configuration enabled, preventing unauthorized users from modifying security settings
• No permission sets grant Modify All Data to non-administrative users unless documented business justification exists and has been approved
• Permission set assignments are reviewed quarterly to remove access when job functions change or users transfer to different roles

This combination of profiles and permission sets enables flexible access management without sacrificing security control.

External User Controls

External user controls manage community and partner portal access with heightened security requirements appropriate for users outside the organization. External users operate outside the organization's direct control, making regular oversight essential to maintain security boundaries:

• Audit Community configurations quarterly to identify permission creep and unauthorized access grants
• Validate guest user profiles have minimal permissions appropriate for unauthenticated access
• Confirm external organization-wide defaults are Private for all objects containing sensitive data

External user controls create additional security boundaries between internal data and external access channels.

Shield Platform Encryption

Shield Platform Encryption provides encryption at rest using customer-managed keys that remain under organizational control. Shield Platform Encryption enables field-level encryption where data remains encrypted in Salesforce's database, satisfying regulatory requirements for encryption even if the underlying infrastructure is compromised.

These eight platform configuration mechanisms create layered security where multiple controls must fail before unauthorized access occurs. However, platform configuration only protects against runtime access violations; it cannot prevent security vulnerabilities from being introduced during development and deployment. Development pipeline controls complement platform configuration by validating security before changes reach production, catching misconfigurations when remediation costs are lowest.

Development Pipeline Controls

Development pipeline security prevents vulnerabilities from reaching production environments through automated validation at each stage of the software development lifecycle. These controls catch misconfigurations during code review and testing rather than discovering them post-deployment when remediation is more costly and data may already be exposed.

NIST Security Requirements

NIST establishes government standards that reflect security best practices applicable to all organizations using automated deployment processes. NIST Special Publication 800-204D mandates that automated checks on pull request artifacts validate security before code enters the main branch:

• Unit tests validating code coverage meets minimum thresholds for security-critical functionality
• Linters checking syntax violations that could introduce vulnerabilities
• Integrity tests verifying metadata structure and dependencies remain intact
• Security checks identifying potential vulnerabilities in custom code and configuration

These automated checks create quality gates that prevent insecure code from progressing through the development pipeline.

Static Application Security Testing

Static application security testing analyzes code for security vulnerabilities before deployment, catching issues during development when remediation costs are lowest. Integration into Git pre-commit hooks provides immediate feedback to developers, preventing insecure code from entering version control in the first place.

Organizations should implement SAST scanning across all custom development:

• Apex code scanning for security anti-patterns like hardcoded credentials and SQL injection vulnerabilities
• Lightning Web Components analysis for cross-site scripting vulnerabilities and insecure data handling
• Configuration metadata validation for permission misconfigurations that could expose sensitive data

Progressive validation runs checks at different pipeline stages optimized for speed and thoroughness. Pre-commit hooks perform fast syntax validation and basic security pattern matching to provide immediate developer feedback. Continuous integration runs comprehensive SAST scanning and metadata validation on the complete changeset. Staging environments execute integration testing and field-level security verification with production-equivalent data volumes. This progressive approach balances rapid feedback with thorough security validation.

Branch Protection

Branch protection enforces code review and approval workflows that catch security issues through human analysis, complementing automated scanning. Research published in security journals establishes that integrating code review into DevSecOps pipelines enables proactive identification of security vulnerabilities during development when remediation costs are lowest.

Organizations should configure branch protection to prevent single points of failure in security review:

• Require multiple reviewer approvals for production branches, ensuring independent security validation
• Mandate signed commits for critical environments ensuring code provenance and non-repudiation
• Block direct pushes to protected branch,es forcing all changes through pull request review process

Branch protection creates human oversight that complements automated security scanning.

Policy-as-Code

Policy-as-code enables automated compliance validation that enforces organizational security standards without requiring manual review of every deployment. System administrators define security policies as code stored in version control, enabling versioning, review, and automated enforcement of security requirements.

Implementation includes automated checks that validate configurations before deployment reaches production:

• Validate all profiles have View Setup and Configuration disabled except System Administrator, preventing unauthorized configuration changes
• Confirm no permission sets grant Modify All Data to non-administrative users unless explicitly documented and approved, enforcing least privilege
• Verify all external integrations use named credentials rather than hardcoded passwords in code, preventing credential exposure in version control
• Check field-level security enforcement on all fields containing PII, PHI, or payment card data, satisfying regulatory requirements

Policy-as-code transforms security requirements from documentation into executable validation that runs automatically with every deployment.

Integration Security Controls

Integration security protects connections between Salesforce and external systems where data crosses trust boundaries and may be exposed to systems with weaker security controls. The FBI and CISA documented that threat actors frequently compromise external systems then pivot into Salesforce through trusted integration connections, making integration security essential for comprehensive protection.

OAuth 2.0 Authentication

OAuth 2.0 provides token-based authentication that eliminates password storage in integration code and enables granular permission scoping limiting what integrated applications can access. Salesforce's OAuth documentation specifies OAuth 2.0 is required for all API integrations, providing time-limited access tokens rather than requiring applications to store usernames and passwords directly.

Threat actors UNC6040 and UNC6395 actively target OAuth tokens to gain unauthorized Salesforce access through multiple attack vectors:

• Phishing attacks tricking users into authorizing malicious applications
• Malware stealing tokens from application memory or local storage
• Man-in-the-middle attacks intercepting token exchange during OAuth flows

Understanding these attack patterns enables organizations to implement OAuth configurations that mitigate token theft risk.

Connected App Configuration

Connected App configuration must enforce security restrictions that limit the potential damage from token theft or compromise. Organizations should enable multiple layers of protection in Connected App settings:

• Require Secret for Web Server Flow prevents token interception attacks where attackers without the client secret cannot complete OAuth flows
• IP restrictions limit token usage to known application servers, preventing token usage from attacker-controlled infrastructure
• Token refresh policies with short-lived access tokens limit the window where stolen tokens remain valid
• User approval requirement for sensitive scopes ensures users explicitly consent before applications access protected data

These configurations create multiple barriers that limit the impact of token compromise.

API Security Testing

API security testing validates that field-level security enforcement applies consistently across all access methods, bridging platform configuration with integration security. Organizations must verify that security controls configured in Setup apply uniformly regardless of whether data is accessed through the user interface or programmatically:

• API requests from users without field access receive responses with those fields excluded rather than returning error messages revealing field existence
• Attempts to update restricted fields via API fail with appropriate error messages rather than silently ignoring updates
• Query results respect sharing rules so API users cannot access records they couldn't view through the user interface

API security testing ensures that security controls apply uniformly across all data access channels.

Named Credentials

Named Credentials eliminate hardcoded passwords that expose credentials in version control systems, application logs, and debug output. Organizations should use Named Credentials for all external system authentication:

• Encrypted at rest using platform encryption protecting credentials even if database backups are compromised
• Centrally managed in Setup UI rather than scattered across multiple code files requiring individual updates
• Referenced by name in code rather than hardcoded as plain text that appears in version control and debug logs

Named Credentials provide secure credential management that prevents the exposure of authentication secrets in code repositories. Together, these integration security controls protect the connections between Salesforce and external systems where data crosses trust boundaries.

Monitoring and Detection Controls

The first three security layers focus on preventing unauthorized access before it occurs. The fourth layer, monitoring and detection, provides visibility into system activity that enables organizations to identify when preventive controls are bypassed, system behavior deviates from baseline patterns, or attackers gain unauthorized access despite other safeguards.

Monitoring serves two essential functions: it provides the audit trails required by all major regulatory frameworks, and it enables rapid incident detection that significantly reduces the time required to contain breaches and limit damage. Organizations that detect breaches quickly contain damage more effectively than those relying solely on preventive measures.

Event Monitoring

Event Monitoring provides comprehensive activity logging that captures all significant Salesforce events, creating the audit trail foundation required by regulatory frameworks. Salesforce's Transaction Security documentation confirms Event Monitoring logs activity across all access methods and user types.

Event Monitoring captures activity patterns that enable security teams to identify unauthorized access and suspicious behavior:

• API usage patterns revealing unusual call volumes or access to unexpected objects
• Data export operations flagging large data downloads that may indicate data exfiltration attempts
• Login activity including failed attempts identifying brute force attacks or credential stuffing campaigns
• Report execution detecting unauthorized access to sensitive reports containing protected data
• Changes to sensitive data tracking modifications to financial records or protected health information

Event Monitoring retains event data accessible via API for integration with security information and event management systems or through the Event Monitoring Analytics App for investigation. This retention satisfies GDPR Article 30 record-keeping requirements, HIPAA audit control requirements, SOX Section 404 documentation requirements, and PCI-DSS Requirement 10 tracking and monitoring requirements. Event Monitoring creates the data foundation that subsequent security capabilities build upon.

Transaction Security

Transaction Security enables real-time policy enforcement that automates response to suspicious activity without requiring human intervention. Transaction Security builds on Event Monitoring's data collection by adding policy-based automation that responds to suspicious patterns within milliseconds of detecting them rather than requiring human analysis of logs after incidents occur.

Organizations can configure policies that respond automatically to security events:

• Block API calls originating from unexpected geographic locations preventing access from compromised credentials used outside normal business regions
• Require step-up multi-factor authentication when sensitive data is accessed adding verification for protected health information or payment card data
• Trigger alerts when users export large data volumes detecting potential data exfiltration attempts in progress
• Terminate sessions when anomalous behavior is detected containing potential compromises automatically without waiting for manual review

Transaction Security transforms passive event logging into active defense through automated policy enforcement.

Setup Audit Trail

Setup Audit Trail tracks administrative configuration changes that affect security posture, providing accountability for modifications to security settings. Setup Audit Trail maintains administrative changes with complete forensic detail supporting investigation and compliance verification.

The audit trail documents critical information for each configuration change:

• Who made configuration changes enabling accountability for security modifications
• What specific settings were modified providing forensic detail for incident investigation
• When those changes occurred establishing timeline correlation with security events

This documentation satisfies SOX change management documentation requirements by proving that all configuration changes followed documented approval processes and enables forensic investigation by showing what changed before security incidents occurred. Setup Audit Trail provides configuration change visibility that complements Event Monitoring's user activity tracking.

Field History Tracking

Field History Tracking maintains data modification records for sensitive fields requiring detailed audit trails beyond general activity logging. Organizations can track field modifications with standard Salesforce or expand tracking capacity with Salesforce Shield, recording complete modification history for regulatory compliance and fraud investigation.

Each tracked field modification captures information supporting compliance verification and forensic analysis:

• Old value before each change providing baseline for comparing modifications
• New value after the change showing the complete audit trail of data evolution
• User who made modification enabling accountability for data changes
• Timestamp when it occurred establishing timeline for regulatory reporting and investigation

Field History Tracking satisfies HIPAA integrity control requirements proving data has not been improperly altered and supports regulatory audits by demonstrating data changes followed appropriate business processes.

These four monitoring mechanisms work together to create comprehensive visibility into Salesforce activity, completing the fourth layer of the security control architecture.

Incident Response Capabilities

Preventive and detective controls reduce breach likelihood, but organizations must prepare for incidents that bypass these defenses. Regulatory frameworks impose strict notification deadlines that require documented response procedures, trained personnel, and tested communication channels before incidents occur.

Notification Deadlines by Framework

Each regulatory framework establishes specific timelines that determine how quickly organizations must respond once a breach is confirmed:

• GDPR: 72 hours to notify supervisory authorities of personal data breaches, with affected individuals notified "without undue delay" when breaches pose high risk to their rights
• HIPAA: 60 days to notify affected individuals and HHS for breaches affecting 500 or more individuals, with immediate notification to HHS for breaches affecting fewer individuals required within 60 days of calendar year end
• PCI-DSS: Immediate notification to payment card brands and acquiring banks upon confirmed cardholder data compromise, with specific timelines varying by card brand
• FedRAMP: 1 hour to report confirmed incidents to the authorizing agency, with detailed incident reports required within specific timeframes based on incident severity

These compressed timelines make advance preparation essential. Organizations cannot develop response procedures during an active incident and still meet regulatory deadlines.

Response Plan Components

Effective incident response requires documented procedures that personnel can execute under pressure. Response plans should address five phases that align with NIST Cybersecurity Framework guidance:

• Identification: Procedures for confirming whether security events constitute actual breaches requiring notification, including criteria for escalation and designated personnel authorized to make breach determinations
• Containment: Technical procedures for isolating affected systems, revoking compromised credentials, and preventing further data exposure while preserving forensic evidence
• Eradication: Steps for removing threat actor access, closing exploited vulnerabilities, and validating that attack vectors have been eliminated before restoration
• Recovery: Procedures for restoring affected systems to normal operation, including validation testing that confirms security controls are functioning before returning systems to production
• Post-Incident Review: Requirements for documenting lessons learned, updating response procedures, and implementing controls that prevent similar incidents

Organizations should test response plans through tabletop exercises that simulate breach scenarios, validating that personnel understand their roles and that communication channels function as expected.

Salesforce-Specific Response Considerations

Incident response in Salesforce environments requires specific technical capabilities that support investigation and containment:

• Session termination: Ability to immediately revoke all active sessions for compromised users, forcing re-authentication
• Permission revocation: Procedures for rapidly removing access from compromised accounts or connected applications without disrupting legitimate business operations
• Forensic data preservation: Methods for exporting Event Monitoring logs and field history data before retention periods expire, preserving evidence for investigation
• Connected app review: Processes for identifying and revoking OAuth tokens for applications that may have been compromised or used as attack vectors

These capabilities should be documented and tested before incidents occur, ensuring response teams can execute containment procedures without delay.

Data Retention and Lifecycle Management

Regulatory frameworks require organizations to retain data for specified periods while also mandating deletion when retention requirements expire. Balancing these obligations requires documented retention policies, technical controls that enforce retention periods, and procedures for responding to deletion requests.

Retention Requirements by Framework

Each framework establishes minimum retention periods that organizations must satisfy. These requirements vary significantly based on data type and regulatory purpose, ranging from months for operational logs to years for financial records. Organizations must understand specific timeframes for each framework governing their data to configure appropriate retention controls and avoid both premature deletion and unnecessary storage costs.

• GDPR: No fixed retention period; data must be kept only as long as necessary for the purposes for which it was collected, requiring organizations to define and justify retention periods for each data category
• HIPAA: Six years for policies, procedures, and documentation; medical records retention varies by state law, often ranging from seven to ten years
• PCI-DSS: One year of audit trail history immediately available for analysis, with three months of logs available within 30 minutes for investigation
• SOX: Seven years for audit workpapers and financial records supporting public company reporting
• FedRAMP: Three years for security assessment documentation, with system logs retained according to NIST 800-53 requirements based on impact level

Organizations processing data under multiple frameworks must track the longest applicable retention period for each data category to avoid premature deletion.

Implementing Retention Controls in Salesforce

Salesforce provides several mechanisms for managing data lifecycle that organizations should configure based on retention requirements. These tools address different aspects of retention management, selecting the appropriate combination depends on data volume, regulatory requirements, and whether records must remain queryable after their active use period ends.

• Data retention policies: Automated deletion of records based on age or status criteria, removing data that has exceeded retention requirements
• Archiving solutions: Moving historical data to external storage systems that maintain accessibility for compliance purposes while reducing active database volume
• Field history retention: Configuring appropriate retention periods for field history tracking data that supports audit requirements
• Event log retention: Understanding standard Event Monitoring retention periods and implementing log export procedures if longer retention is required

Organizations should document retention configurations and validate through periodic audits that automated deletion processes function correctly without removing data still subject to legal holds or ongoing retention requirements.

Deletion and Right to Erasure

GDPR Article 17 establishes the right to erasure, requiring organizations to delete personal data upon request when specific conditions are met. Implementing this requirement in Salesforce presents technical challenges that organizations must address:

• Record identification: Procedures for locating all records containing personal data for a specific individual across standard and custom objects
• Cascading relationships: Understanding how record deletion affects related records in master-detail and lookup relationships
• Backup implications: Ensuring deletion requests propagate to backup systems where personal data may persist after production deletion
• Retention conflicts: Procedures for handling erasure requests when legal holds or other retention requirements prevent immediate deletion

Organizations should document their erasure procedures and maintain logs demonstrating compliance with deletion requests, including the specific records deleted and the date deletion was completed.

Legal Holds

Litigation and regulatory investigations may require organizations to preserve data that would otherwise be deleted under normal retention policies. Legal hold procedures must override automated deletion to prevent spoliation:

• Hold identification: Processes for determining which records fall within the scope of legal holds based on subject matter, custodians, or date ranges
• Automated deletion suspension: Technical controls that prevent retention policies from deleting records subject to active holds
• Hold release: Procedures for releasing holds when litigation concludes, allowing normal retention policies to resume
• Documentation: Records demonstrating that holds were implemented and maintained throughout the required preservation period

Failure to preserve data subject to legal holds can result in adverse inference instructions, sanctions, or case dismissal, making hold procedures as important as deletion procedures in comprehensive lifecycle management.

Operationalizing Security Through Automation

The security controls detailed in previous sections require ongoing validation to remain effective as Salesforce environments evolve. Manual security validation introduces delays and creates opportunities for human error that undermine even well-designed security architectures. The financial case for automation is substantial: organizations with extensive security AI and automation capabilities save an average of $1.9 million in breach-related costs compared to organizations without these capabilities.

Effective security automation addresses three operational challenges that manual processes cannot scale to meet:

• Deployment validation prevents misconfigured sharing rules and permission sets from reaching production by validating every deployment against organizational security policies before release.
• Audit trail maintenance satisfies regulatory requirements by automatically documenting who approved changes, what security reviews were completed, when deployments occurred, and what configurations were modified.
• Policy-as-code enforcement validates security settings like profile permissions, organization-wide defaults, and external user access before deployment rather than discovering violations during audits.

Flosum provides Salesforce DevSecOps capabilities that automate these requirements throughout the development lifecycle. The platform validates deployments against security policies before production release, maintains immutable audit trails satisfying SOX Section 404 requirements, and enforces field-level security settings, profile permissions, and sharing rules automatically.

Request a demo with Flosum to see how automated security validation catches misconfigurations before production deployment and policy-as-code enforcement validates configurations against GDPR, HIPAA, PCI-DSS, and SOX requirements.