When regulators audit your Salesforce environment, they are not evaluating Salesforce's controls. They evaluate your organization's evidence, configuration, and governance decisions under pressure. Salesforce's platform certifications cover Salesforce infrastructure controls, not your compliance obligations inside the tenant. Salesforce secures infrastructure. Your organization is accountable for every configuration, access, and governance decision built on top of it.

This article maps the exact boundaries of customer liability and shows where regulated organizations carry non-delegable accountability in Salesforce. It identifies where native Salesforce capabilities fall short of compliance requirements and outlines what organizations must implement independently. IT Compliance Managers preparing for audits and DevOps Engineers managing deployment pipelines will gain a clear, actionable view of their organization's obligations.

The financial stakes reinforce the urgency. Organizations that misunderstand the shared responsibility boundary risk increased compliance failures and potential breach costs.

How Salesforce Divides Security Responsibilities

Salesforce's security model includes various levels of permissions and responsibility, often discussed in terms of shared and customer responsibilities. Understanding these layers determines which controls your organization must implement, fund, and document for auditors. The Well-Architected Framework and Salesforce Security site draw a clear line between these obligations. 

• Salesforce is responsible for securing the underlying cloud infrastructure, including physical servers, networks, and platform services.
• Customers are responsible for securing everything they build and configure inside their tenant, from access controls and data protection to deployment governance.

Layer 1: What Salesforce owns

Salesforce maintains responsibility for physical infrastructure, network architecture, platform availability, vulnerability patching, and platform-level certifications under a shared responsibility model. Enterprise-grade protections include:

• Physically secured data centers with network segmentation between tenants
• Real-time intrusion detection and encrypted communications using TLS 1.3 by default
• Secure development lifecycle with built-in code reviews, static analysis, and regular penetration testing
• Simultaneous vulnerability patching across all production instances, eliminating exposure windows common in on-premise systems
• Disk-level encryption for data at rest, with Shield customers gaining field-level encryption using customer-controlled keys

Three-layer security architecture

Salesforce categorizes its security architecture into three layers:

1. Foundationals — protections "built into our infrastructure and our platform, and are always working in the background"
2. Configurables — settings that shift responsibility toward the customer
3. Enhanceables — advanced capabilities that shift responsibility toward the customer

This means that while Salesforce secures the cloud itself, platform security alone cannot prevent data exposure through misconfiguration or privilege misuse—organizations must focus on the critical handoff where infrastructure meets administrative decisions.

Platform certifications

Salesforce holds certifications across multiple regulatory standards:

• ISO 27001 — covers office sites, development centers, support centers, and data centers, with certifications running for 3 years (renewal audits) and annual surveillance audits
• SOC 1, SOC 2, SOC 3 — service organization control reports
• FedRAMP — Salesforce has maintained an Authority to Operate (ATO) at the Moderate Impact level for the Salesforce Government Cloud since May 2014
• ISO 27017 and ISO 27018 — cloud-specific security and privacy standards
• PCI-DSS — payment card industry compliance

These certifications confirm that Salesforce meets stringent regulatory standards, giving organizations pre-validated controls that simplify audit preparation and let them focus on their own configurations.

Where Salesforce's responsibility ends

However, these certifications cover Salesforce's infrastructure obligations, not customer-side controls. Customers manage configurations and data security within their tenant. Platform-level security obligations are non-delegable to customers — organizations cannot assume responsibility for patching Salesforce servers or managing data center security. Customer-side responsibilities remain fully with the organization.

Layer 2: What your organization owns

Customers bear explicit responsibility for all configuration decisions within their tenant. Every setting your organization enables, modifies, or leaves at its default becomes part of your auditable control environment. These decisions fall into three key areas:

• Identity and access management: MFA enforcement, user provisioning, permission sets, and role hierarchies. These controls determine who can access your Salesforce data and what actions they can perform. Misconfigured access is one of the most common findings in compliance audits.
• Data security: encryption setup and key management, field-level security, and sharing rules. These configurations govern how sensitive data is protected at rest and who can view specific fields and records. In regulated environments, a single overly permissive sharing rule can constitute a compliance violation.
• Session policies: timeout settings and login restrictions. These controls limit exposure from unattended sessions and enforce boundaries on where and how users can authenticate.

Getting these configurations right is not just best practice; it is an auditable obligation. The Well-Architected Framework identifies specific anti-patterns that create liability when organizations neglect these areas:

• Shared accounts that prevent individual user attribution
• Missing MFA enforcement that leaves authentication vulnerable
• Failure to implement least privilege principles, granting users broader access than their role requires

Layer 3: What requires additional investment

Advanced capabilities required by regulated industries are not included in standard Salesforce licensing. They require Salesforce Shield, a separate paid subscription with four components:

• Platform Encryption upgrades standard disk-level encryption to AES 256-bit field-level encryption across standard and custom fields, files, and attachments — while preserving search, workflows, and validation rules. Organizations can manage their own keys through BYOK or store key material externally using the Cache-Only Key Service.
• Event Monitoring tracks 50+ events including logins, API calls, report exports, and Apex executions, providing the granular user-activity visibility auditors expect. Event logs can be exported to SIEMs for centralized monitoring and automated threat response.
• Field Audit Trail extends standard field history tracking from 20 to 60 fields per object and retains history for up to 10 years, recording old and new values, timestamps, and the responsible user — essential evidence for demonstrating data integrity.
• Data Detect scans your Salesforce database to identify and classify sensitive data such as PII stored in unexpected fields, enabling teams to apply appropriate encryption, field-level security, and sharing rules before auditors flag the exposure.

Shield pricing is calculated as a percentage of total Salesforce spend, with estimates placing the full bundle at approximately 30% of total license costs. Components are available individually or as a full suite. For organizations in healthcare, financial services, or the public sector — where frameworks like HIPAA and SOX impose strict data protection requirements — this investment is difficult to avoid. However, Shield strengthens security but doesn't guarantee compliance on its own. Organizations must still configure encryption policies, permissions, and audit retention correctly to satisfy specific regulatory requirements.

Where Standard Salesforce Tools Fall Short

Even with Shield in place, native Salesforce capabilities leave measurable gaps between what the platform provides and what regulations require. Compliance Managers and DevOps Engineers who recognize these shortfalls early can address them through additional tooling before they surface as findings during audit cycles.

The most critical gap is audit log retention. Key logs have hard retention caps that fall well short of common regulatory evidence timelines:

• Setup Audit Trail and Login History: six months
• Free-tier Event Log Files: one day
• Shield Event Monitoring: one year

Compare those caps to actual regulatory requirements: SOX mandates seven years of audit documentation, and HIPAA mandates six years. Even the longest native retention period — one year with Shield — covers a fraction of what either framework demands. Meeting these timelines requires organizations to export and retain logs outside Salesforce entirely.

Field-level tracking presents a similar challenge. Standard Field History Tracking covers only 20 fields per object, and while Shield's Field Audit Trail extends that limit, the archived data is logged directly in the FieldHistoryArchive Big Object rather than remaining accessible through the standard Salesforce UI. Retrieving it generally requires SOQL queries through the Salesforce API, adding operational complexity for teams that need to pull evidence during audits. 

To build a more complete picture, many organizations complement these native capabilities by streaming event data to third-party SIEM platforms for consolidated analysis and alerting — effectively bridging the gap between what Salesforce retains and what compliance programs require.

Compliance Obligations Your Organization Cannot Delegate

Four major regulatory frameworks apply to Salesforce environments, and each preserves non-delegable customer accountability. This section consolidates the specific obligations under HIPAA, SOX, GDPR, and SOC 2 that your organization must fulfill regardless of Salesforce's platform certifications. Mapping these obligations prevents gaps during regulatory examinations.

HIPAA

Both covered entities and business associates face enforcement, creating dual accountability. Customers must implement security management processes under 45 CFR 164.308, maintain audit controls under 45 CFR 164.312(b), and retain documentation for six years. A Salesforce Business Associate Addendum does not transfer covered entity liability. It creates parallel accountability.

SOX

Under Sections 302 and 404, company management cannot delegate ICFR certification to any service organization. Customers should monitor Salesforce's control environment (often using SOC 1 reports) and document complementary user entity controls; auditors subject to PCAOB AS 1215 must retain their audit documentation, including evidence related to service organizations, for seven years.

GDPR

Even though Salesforce processes data, the 72-hour notice obligation to supervisory authorities rests with the customer controller. Customers must maintain Article 30 records and conduct impact assessments for certain high-risk processing activities under GDPR. They are also responsible for responding to data requests as data controllers when using platforms like Salesforce.

SOC 2

Salesforce's SOC 2 report assigns customers Complementary User Entity Controls that they must independently implement. These include user access, configuration management, change management with rollback procedures, and monitoring and incident response documentation.

What an Effective Governance Solution Requires

Closing the shared responsibility gap demands capabilities that span change management, deployment governance, and audit evidence generation. Each requirement below aligns to the control frameworks referenced above and addresses specific gaps in native Salesforce tooling. DevOps Engineers and Compliance Managers need these capabilities working together, not as isolated point solutions.

Automated change control with version history

Organizations should establish and document configuration baselines as part of their configuration management practices, ensuring a stable foundation for change control processes. Manual change tracking across Salesforce metadata creates documentation gaps that auditors flag. Automated version control systems in Salesforce DevOps can be configured to capture configuration changes along with timestamps and authors; however, capturing approval records typically requires additional setup and is not universally automatic.

Policy-enforced deployment pipelines

Some regulatory and control frameworks (such as SOX Section 404 and certain NIST controls) require documented approvals for specific types of system changes, but technical safeguard requirements across industries do not uniformly or explicitly demand formal change request processes with documented approvals before every production deployment. 

GSA resources generally discuss NIST SP 800-53 controls related to configuration management but do not specifically map them to Salesforce processes in the way described. Organizations need deployment workflows that block unauthorized changes automatically rather than relying on manual review.

Persistent audit trail generation

Compliance audit obligations require continuous evidence of who changed what, when, and with whose approval. This evidence must persist for mandated retention periods, far exceeding what native tools provide. Automated audit trail generation eliminates manual documentation and supports regulatory examinations without weeks of preparation.

Environment separation with rollback capability

SOC 2 change management criteria involve ensuring that changes are authorized, tested, and implemented in a controlled manner before they are promoted to production, as stated in CC7.4 and CC7.5 of the framework. Testing changes through a progression from development to staging to production is a practical way to satisfy that expectation.

When production deployments cause issues, reliable rollback procedures prevent extended outages and maintain data integrity.

Closing the Shared Responsibility Gap

The responsibilities outlined above are permanent organizational obligations. Salesforce certifications cover infrastructure and core platform services but exclude customer-side configuration, access governance, and deployment controls. Customers are responsible for these under the shared responsibility model. Organizations that treat these obligations as future initiatives accumulate compliance debt that compounds with every deployment cycle.

DevOps solutions purpose-built for Salesforce address the governance requirements described above by connecting deployment governance to audit-ready evidence. Flosum provides automated deployment pipelines for Salesforce metadata and generates audit trails for compliance reporting, replacing manual change processes that create documentation gaps.

These required capabilities reduce the risk of production incidents and tighten change accountability without adding weeks of manual audit preparation. They also support CI/CD workflows within Salesforce environments, tying release activity to the compliance evidence chain.

When audit deadlines approach, having complete deployment history and change documentation accelerates preparation. Request a demo with Flosum to explore how automated audit trails support your compliance requirements.