Payment card data is a prime target for attackers, and any lapse in controls is expensive. Regulatory fines for Payment Card Industry Data Security Standard (PCI DSS) violations alone range from $5,000 to $100,000 per month if a breach occurs, not counting legal fees or lost revenue. Most incidents still trace back to basic compliance gaps, such as misconfigured access, unencrypted storage, or unsecured integrations, rather than sophisticated attacks.

Your Salesforce org sits at the center of customer transactions, with a huge amount of payments processed on the platform every day. Salesforce's infrastructure is audited annually by Qualified Security Assessors and certified at PCI DSS Level 1, but that certification stops at the platform boundary. The moment you create custom objects, install an AppExchange package, or integrate a payment gateway, the compliance burden shifts squarely onto your team.

Meeting PCI DSS requirements inside Salesforce means more than checking a box; you need airtight configurations, continuous monitoring, and clear documentation that proves every control operates as designed. This comprehensive resource walks you through exactly how to achieve that, clarifying where Salesforce's responsibilities end and where yours—and your ISV partners'—begin so that you can process payments with confidence.

What Is PCI Compliance and Why Is It Important?

The PCI DSS is the global rulebook for protecting cardholder data. It distills security best practices into 12 high-level requirements—spanning network security, encryption, access control, monitoring, and policy management—supported by roughly 300 individual controls. If an organization handles, stores, or transmits payment card information, meeting these controls is not optional; it is a contractual obligation imposed by the major card brands.

Ignoring PCI DSS brings severe financial consequences; a single breach often brings reputational damage, customer lawsuits, and costly forensic investigations, in addition to hefty fines. Data protection is both a legal requirement and a risk-management imperative.

PCI DSS operates as a shared-responsibility framework: Salesforce secures the physical and virtual infrastructure, while Salesforce customers enforce the controls that auditors will inspect inside their org. Understanding this boundary is the first step toward a compliant—and breach-resilient—Salesforce environment.

Understanding and Fulfilling PCI Compliance Responsibilities in Salesforce

Salesforce is a PCI DSS–certified Level 1 service provider, meaning its infrastructure and core platform services have met the most rigorous security standards for handling payment card data. This certification covers Salesforce’s data centers, network architecture, and baseline security controls—but it does not apply to how individual customers configure their orgs, build custom apps, or manage integrations. PCI compliance within Salesforce follows a shared responsibility model: Salesforce secures the platform, while customers and Independent Software Vendors (ISVs) are responsible for everything built, deployed, or extended on top of it.

1. Install and Maintain a Firewall Configuration to Protect Cardholder Data

While traditional firewalls don’t apply to Salesforce the same way they would to on-premise networks, segmentation is still essential. Salesforce provides features like IP restrictions and login-hour controls to help customers reduce the attack surface and restrict unauthorized access.

• Salesforce: Provides “Login IP Ranges” for profiles and “Trusted IP Ranges” for org-wide access control. Also supports login-hour restrictions to limit exposure during non-business hours.
• You (Customer): Must configure IP and login policies based on user roles and operational hours. This includes enforcing stricter rules for privileged accounts and integration users.
• ISVs: Should not introduce external endpoints or services that bypass org-level IP restrictions or authentication controls.

2. Do Not Use Vendor-Supplied Defaults for System Passwords and Security Parameters

Default credentials and out-of-the-box settings pose a major risk in any system. Within Salesforce, this requirement emphasizes hardening security configurations after deployment and ensuring that no default access paths remain.

• Salesforce: Allows full customization of security parameters, including password policies, session settings, and MFA enforcement.
• You: Must replace any default passwords, disable unused default community sites, and review sandbox or packaged deployments for leftover sample credentials. Enforce strong password rules and require MFA for all users with access to sensitive data.
• ISVs: Must avoid including default admin credentials, hardcoded secrets, or unprotected access endpoints in any managed package or integration.

3. Protect Stored Cardholder Data

Salesforce does not store payment card data by default—but many orgs use it to process transactions, issue refunds, or verify identity. In those cases, encryption and field-level masking must be implemented appropriately.

• Salesforce: Offers Shield Platform Encryption, Encrypted Custom Fields, and field-level security settings to control access and visibility.
• You: Decide whether to store, tokenize, or externalize cardholder data. If storing any part of PAN, encrypt it and configure field-level visibility so only masked values (e.g., last four digits) are shown. Manage encryption keys carefully and document access policies.
• ISVs: Should never store raw card data unless they hold their own PCI certification. Prefer delegated storage models using tokenized payment processors or PCI-compliant services.

4. Encrypt Transmission of Cardholder Data Across Open, Public Networks

Salesforce encrypts data in transit using strong TLS protocols, but encryption responsibilities extend to any integrations or client applications that transmit cardholder data. Weak encryption at the integration layer can still expose sensitive data.

• Salesforce: Enforces TLS 1.2+ on all platform endpoints.
• You: Must enforce HTTPS on all integrations, including middleware and third-party connectors. Disable outdated ciphers in session settings and validate that all integrations meet encryption requirements.
• ISVs: Responsible for ensuring apps and APIs support TLS 1.2+ and do not fall back to insecure protocols or unencrypted transmission paths.

5. Protect All Systems Against Malware and Regularly Update Anti-Virus Software

Salesforce maintains anti-malware protections at the data center level, but endpoint security and third-party code remain customer responsibilities. Browser extensions, unmanaged apps, or infected client machines can all compromise data within the platform.

• Salesforce: Protects its infrastructure using internal malware detection and prevention tools.
• You: Must secure endpoints used to access Salesforce, including anti-virus tools, browser plugin vetting, and security baselines for devices used by staff who interact with sensitive data.
• ISVs: Should maintain secure software development practices, issue regular security updates, and provide signed packages free of known malware.

6. Develop and Maintain Secure Systems and Applications

Building on Salesforce introduces new attack surfaces, particularly when writing custom Apex, Visualforce, or Lightning Web Components. Secure development practices help avoid vulnerabilities like SOQL injection or insecure object access.

• Salesforce: Maintains the security of its platform services and patches known vulnerabilities across shared infrastructure.
• You: Are responsible for the security of all custom code and integrations. This includes embedding static code analysis into your CI/CD pipeline, reviewing pull requests for insecure patterns, and following Salesforce’s secure coding guidelines.
• ISVs: Must follow secure SDLC practices and ensure compatibility with Salesforce’s security features and APIs. Vulnerabilities in third-party code still count against your org in audits.

7. Restrict Access to Cardholder Data by Business Need-To-Know

Overprovisioned access is one of the most common compliance failures. Salesforce’s granular access controls make it possible to restrict data visibility by role—but only if configured with care.

• Salesforce: Offers profiles, permission sets, and role hierarchies to enforce least-privilege access models.
• You: Must design access models that avoid elevated permissions like “Modify All Data” or “View All Data” except where absolutely necessary. Use break-glass accounts sparingly and log their use.
• ISVs: Should integrate with native access controls, inherit permission sets, and never create custom access pathways that circumvent admin oversight.

8. Identify and Authenticate Access to System Components

All access to Salesforce—whether from users, apps, or scripts—must be uniquely identified and authenticated. Strong authentication protocols help detect unauthorized access and reduce the risk of account compromise.

• Salesforce: Supports user-level logging, SSO, MFA, login history tracking, and session timeout configuration.
• You: Must require unique credentials for every user or integration, enforce MFA on privileged roles, and review login history regularly. Session timeouts and IP restrictions should be tuned based on risk level.
• ISVs: Should not reuse credentials across tenants or offer “shared admin” modes. Apps must integrate cleanly with your authentication model.

9. Restrict Physical Access to Cardholder Data

Although Salesforce data is stored in secure, SOC-audited facilities, customers must still control the physical environments where users operate—especially if reports are downloaded or data is exported.

• Salesforce: Manages physical access at the data center level, including surveillance, biometric access, and disaster recovery protections.
• You: Must secure endpoints, laptops, or local devices used by staff accessing or exporting sensitive data. Encrypt devices and use screen locks where appropriate.
• ISVs: Should avoid creating features that encourage offline access to raw cardholder data or allow local storage of sensitive exports.

10. Track and Monitor All Access to Network Resources and Cardholder Data

Monitoring is a core requirement of PCI compliance. Salesforce provides audit trail tools, but customers must activate, store, and review them. Without a retention and analysis strategy, logs provide little compliance value.

• Salesforce: Offers Event Monitoring, Field Audit Trail, and login history reporting APIs to support logging and monitoring.
• You: Must activate these tools, retain logs for PCI-required durations, and regularly review access and change histories. Integrating with your SIEM or alerting systems is strongly recommended.
• ISVs: Should expose relevant application logs to customers, support integration with Salesforce’s monitoring tools, and avoid logging sensitive data in cleartext.

11. Regularly Test Security Systems and Processes

Salesforce conducts regular infrastructure testing, but any code, configuration, or integration added to your org must be tested independently. Custom Apex code or unaudited AppExchange apps can create blind spots.

• Salesforce: Performs continuous vulnerability scanning and penetration testing on the platform itself.
• You: Must test your own codebase and configurations, especially when handling cardholder data. This includes periodic penetration testing and source code reviews.
• ISVs: Should provide documentation on known issues, update schedules, and security testing procedures. Customers should review these before installing packages.

12. Maintain a Policy That Addresses Information Security for Employees and Contractors

Tools alone do not satisfy PCI requirements—security policies and user training are equally important. Anyone with access to payment data should understand their obligations and follow documented procedures.

• Salesforce: Publishes detailed security posture documentation and notifies customers of emerging risks through the Trust site.
• You: Must create and maintain written policies covering access control, incident response, and user behavior expectations. Regular training for Salesforce admins and users is required.
• ISVs: Should provide clear documentation on their security practices and communicate any incidents that could affect your PCI posture.

Why the Shared Responsibility Model Matters

PCI compliance inside Salesforce cannot be achieved through platform security alone. Even though Salesforce provides encryption, access control, and logging capabilities, customers must configure and operate these features according to PCI requirements. Similarly, third-party apps must integrate securely, respect org policies, and avoid introducing risk.

Misunderstanding responsibility boundaries—such as assuming that Salesforce’s TLS protections extend to your custom middleware—is one of the most common ways audits fail. Solutions like Flosum can help fill these gaps: its native Salesforce deployment pipelines, audit trails, and access controls help enforce compliance rules at the metadata level. But platform tools only help if processes and roles are clearly defined.

Before launching a new integration or payment workflow, review Salesforce’s PCI DSS Shared Responsibility Matrix. Clarify who owns each control, document how it is enforced, and ensure that every stakeholder—internal or external—understands their role.

Preparing Your Salesforce Org for PCI Compliance

Configuration choices, custom code, and integrations are your responsibility, and any misstep can bring cardholder data into scope and trigger audit failures. A certified platform provides the foundation—you need disciplined preparation to satisfy controls and demonstrate compliance to auditors.

The most reliable approach follows a three-phase roadmap that guides you from discovery to audit-ready controls.

1. Scope

Establish exactly where payment data could appear and secure the resources needed for compliance.

• Secure an executive sponsor who can unblock budgets and enforce deadlines across departments.
• Create a comprehensive inventory of standard and custom objects, reports, files, and integrations that might store or transmit cardholder data. This becomes your compliance boundary—anything outside this scope reduces your audit burden.
• Allocate budget for essential security tooling such as Salesforce Shield encryption or tokenization apps. These investments reduce scope and audit effort by removing sensitive data from your environment.
• Document every data flow to prove that unencrypted PANs never cross unsecured boundaries. Clear data flow diagrams become critical evidence during audits.

2. Gap Analysis

Identify compliance gaps by assessing your current environment and comparing it to PCI DSS requirements.

• Run a Salesforce Health Check and review results for weak password policies, open network access, and inactive users with elevated rights.
• Commission an external vulnerability scan targeting your Salesforce login domains and connected apps. External validation carries more weight with auditors than internal assessments.
• Compare findings to the PCI Responsibility Matrix to clarify which gaps are your responsibility versus Salesforce’s. This prevents wasted effort on controls Salesforce already covers.
• Rank issues by risk to cardholder data, focusing first on access controls, encryption, and audit logging—areas auditors typically scrutinize.

3. Remediation

Address gaps with both technical fixes and audit-ready documentation.

• Implement technical controls such as MFA enablement, IP range restrictions, field-level encryption, and the removal of any stored PANs.
• Document every change with screenshots, approval tickets, and change-management logs. Auditors require clear evidence that controls are in place and functioning.
• Validate each fix through targeted testing and update your data flow diagrams and asset inventories to match the live environment.
• Schedule regular validation cycles to prevent configuration drift and maintain compliance between audits.

A Qualified Security Assessor (QSA) is an external auditor certified by the PCI Security Standards Council to assess and validate your compliance. Following this structured approach helps you build a tightly scoped, well-documented Salesforce org that aligns with every applicable PCI DSS requirement—before your QSA even arrives.

Step-by-Step Implementation Guide

Translating theory into day-to-day Salesforce operations requires concrete, measurable action. The steps below follow the structure of the standard itself, showing exactly what needs to be configured, documented, and monitored inside your org.

Build and Maintain a Secure Network and Systems

Create a secure perimeter by controlling how users and integrations reach Salesforce, and hardening access pathways across the org.

• Configure IP allow-lists using Login IP Ranges at the profile level to restrict access to trusted networks while supporting remote work.
• Set login-hour restrictions for roles that don’t require after-hours access, limiting exposure and providing clear evidence of network segmentation.
• Require Multi-Factor Authentication (MFA) for all users who can access cardholder data. Salesforce’s native MFA helps meet Requirement 8 and mitigates credential-based attacks.
• Remove default passwords, disable unused standard profiles, and verify that vendor-supplied defaults are not active—aligned with Requirement 2.
• Enable Shield Event Monitoring to log login activity and API access. These logs support forensic reviews but do not capture all network-layer traffic.
• Document each control in a central repository, including written policies and screenshots—auditors expect both configuration evidence and policy alignment.

Protect Cardholder Data

Minimise exposure by keeping raw cardholder data out of Salesforce wherever possible and applying strong protections when storage is unavoidable.

• Tokenize payment information via a PCI-certified gateway (e.g. Chargent), so only non-sensitive tokens are stored in Salesforce.
• Use Shield Platform Encryption to protect sensitive fields that must remain in the platform.
• Confirm that TLS 1.2+ is enforced end-to-end, including middleware and legacy integrations—Salesforce does this by default, but not all systems do.
• Mask all but the first six and last four digits of card numbers in reports and page layouts to comply with Requirement 3.3.
• Define and enforce data retention policies that purge tokens and metadata after their legal or business use ends.
• Check that email alerts, outbound messages, and any third-party transmissions do not include clear-text PAN or sensitive data.

Maintain a Vulnerability Management Program

Keep your environment secure by regularly scanning for vulnerabilities and applying secure development practices across your Salesforce codebase.

• Schedule monthly Salesforce Health Checks and document the trend line to demonstrate ongoing security monitoring.
• Keep AppExchange packages updated; patch notes often contain security fixes that auditors expect to be in place.
• Follow secure coding standards in Apex, Lightning Web Components, and Flows, including input validation and bulk-safe queries.
• Use change-management workflows to track all metadata updates. Flosum’s deployment automation captures deployment history, but should be supplemented with policy documentation.
• Conduct static and dynamic security testing before code reaches production. Document vulnerability resolution timelines to support Requirement 6.3.3.

Implement Strong Access Control Measures

Limit exposure with granular permissions and processes that enforce least privilege across users, roles, and integrations.

• Design role hierarchies, profiles, and permission sets so only those with a clear business need can view or export cardholder data.
• Lock down field-level access for PAN, CVV, and token fields—even for admin users.
• Use sharing rules to restrict record visibility based on role, region, or business unit.
• Maintain a current access matrix mapping each role to its approved objects and fields.
• Automate deprovisioning based on HR triggers to ensure accounts are disabled immediately upon employee separation.
• Perform quarterly access reviews and re-certifications—auditors frequently request this documentation.

Regularly Monitor and Test Networks

Monitor for anomalies and test your environment regularly to detect misconfigurations, drift, or suspicious behavior before they escalate.

• Enable Shield Event Monitoring to track logins, report exports, and bulk API calls.
• Configure alerts for threshold breaches—such as multiple failed MFA attempts—to trigger real-time SecOps investigations.
• Conduct penetration testing annually and after significant changes, and retain full reports (including summaries) to satisfy PCI DSS documentation requirements.
• Retain logs for at least one year, with three months immediately available for review, in alignment with Requirement 10.7.
• Use Flosum’s audit dashboard to correlate deployment events with security incidents.
• Monitor connected-app tokens for signs of unauthorized use or misuse.

Maintain an Information Security Policy

Support technical controls with clear, documented policies and ongoing user education to build a security-first culture.

• Write a Salesforce-specific security policy covering acceptable use, data handling, and incident response protocols.
• Require annual security training for all users involved in payment workflows. Track training completion in a custom object for audit visibility.
• Develop an incident response playbook that defines roles, notification steps, and evidence-collection protocols.
• Store policies in version control with documented approvals—auditors often ask to see policy history.
• Deliver quarterly security awareness refreshers focused on least privilege, phishing defense, and breach escalation.
• Review and re-approve policies annually, ensuring an executive is formally accountable, per Requirement 12.1.4.

Following these steps turns PCI DSS from a checklist into a living set of operational practices within Salesforce. The result is a hardened environment, audit-ready documentation, and reduced risk of payment data exposure.

Stay Compliant with Flosum

Once the initial audit is over, maintaining compliance becomes the challenge: every code push, permission change, or integration update can shift your org out of scope. Flosum’s native DevOps platform maintains operational alignment with standards without moving data outside Salesforce.

Because Flosum’s DevOps solution is hosted on the Salesforce platform, every deployment, metadata change, and audit log inherits the same physical security and encryption that protects your production org. This eliminates data-movement risks common to external CI/CD tools and simplifies auditor conversations about cardholder data flow.

Key capabilities for sustained compliance include:

• Automated change management that logs who changed what, when, and why—providing tamper-evident evidence for Requirements 6 and 10
• Role-based access controls tied to Salesforce profiles and permission sets, enforcing least-privilege for deployment approvals
• Secure development lifecycle enforcement with integrated static code analysis, blocking insecure Apex and Lightning components before production
• Deployment consistency through repeatable pipelines that prevent configuration drift, a frequent cause of accidental scope creep
• Real-time compliance dashboards that surface failed tests, unauthorized changes, or policy deviations when they occur

Flosum maintains third-party attestations—including SOC 2 Type II and ISO 27001—providing additional security team assurance of its control environment.

Talk with one of our experts to see how purpose-built DevOps keeps every release audit-ready.

Frequently Asked Questions

Can I store cardholder data in Salesforce?
Only under strict conditions. The standard forbids keeping full PAN or CVV in standard objects; Salesforce Billing never stores card numbers. If payment data storage is required, place it in encrypted custom fields, mask it in the UI, and restrict access through permission sets and profiles.

Does tokenization remove my org from PCI scope?
Tokenization reduces scope because sensitive PAN never touches Salesforce. However, systems that initiate token requests, display masked digits, or control user access remain in scope, requiring controls such as MFA, logging, and incident response.

How does Flosum help with audit logs?
Flosum records every deployment, configuration change, and approval directly inside Salesforce. Because logs are native, they inherit Shield Platform Encryption and Event Monitoring, providing tamper-evident evidence for Requirements 10 and 11 without exporting data to external SIEM systems.

What documents do auditors ask for?
Auditors typically request Salesforce's annual Attestation of Compliance, the responsibility matrix, change-management records, penetration-test results, and at least 12 months of access logs.

Is Salesforce Shield required for PCI?
Shield isn't mandatory, but auditors expect strong encryption, detailed event logs, and long-term field history. Shield Platform Encryption and Event Monitoring satisfy those controls more effectively than third-party add-ons.

How long must I retain logs?
The standard requires at least one year of log retention, with the most recent three months immediately available for review. Flosum uses Salesforce's immutable audit trail and may leverage additional export or archival strategies to meet the one-year requirement without relying exclusively on external storage.