Salesforce holds your customers’ personal information, including names, emails, phone numbers, addresses, and payment details. Regulations like GDPR and CCPA require you to protect this data, and breaches carry financial penalties, legal liability, and damage to customer trust. This guide explains what qualifies as personally identifiable information, how to protect it inside Salesforce using field-level security and encryption, and what controls you need when that data moves to other systems through integrations or exports.
What Is PII and Why Does It Matter
PII stands for personally identifiable information, which is any data that can identify a person either on its own or when combined with other information.
- Obvious examples: Full name, email address, phone number, and home address. Government identifiers like Social Security numbers, passport numbers, and driver’s license numbers also qualify as PII. Financial information such as credit card numbers and bank account details fall into this category.
- Less obvious examples: IP addresses, device IDs, and purchase history tied to an account. When you combine indirect data points like job title, company, and location, they become PII because together they can identify an individual.
Sensitive PII Carries Higher Stakes
Regulations draw a line between ordinary PII and sensitive categories that require stronger protection.
- Sensitive PII includes government IDs, financial accounts, health records, biometric data, racial or ethnic origin, and religious beliefs.
- GDPR Article 9 requires explicit consent and additional safeguards for these sensitive categories.
- CCPA gives consumers extra rights over sensitive personal information beyond what they have for standard PII.
- Storing sensitive PII without proper controls creates compliance risk that exceeds the risk of mishandling standard contact information.
What Happens If You Fail to Protect PII
The consequences of a PII breach are financial, legal, and reputational.
- GDPR fines can reach €20 million or 4% of global annual revenue, whichever is higher.
- CCPA allows consumers to sue for $100 to $750 per incident in statutory damages.
- IBM’s 2024 Cost of a Data Breach Report found the average breach cost $4.88 million when accounting for investigation, remediation, and lost business.
- Beyond fines, customer trust erodes after a breach, sales cycles lengthen as prospects demand security attestations you cannot provide, and contracts require compliance certifications that take months to rebuild.
Regulations You Need to Know About
Different laws apply depending on where your customers live, not where your company is located.
GDPR applies if you process data of EU residents, regardless of your company’s location or size. CCPA and CPRA apply to California residents and cover businesses over $25 million in revenue or those handling data from 100,000 or more consumers. HIPAA applies to healthcare organizations and their business associates handling protected health information. PCI DSS applies to any organization that processes, stores, or transmits credit card data, regardless of industry. State laws in Virginia, Colorado, Connecticut, and other states have passed their own privacy regulations that may apply to your business based on where your customers reside.
Where PII Lives in Your Salesforce Org
Organizations need to identify every location where PII exists in Salesforce, including standard objects, custom fields, free-text areas, and file attachments, before they can implement appropriate security controls or respond to data subject access requests.
Standard Objects That Store PII
Salesforce’s built-in objects are designed to hold customer and prospect data. Contact records store names, emails, phone numbers, mailing addresses, and birthdates. Lead records contain similar information for prospects who have not yet converted. Account records hold company information that may include addresses and phone numbers.
Custom Objects Your Team Built
Any custom object created to store customer or employee information likely contains PII. Customer portal or community user records include login credentials and contact information. Employee management objects track personal details. Registration objects for events or webinars collect attendee names and email addresses.
Free-Text Fields
Users type PII into fields you did not intend for that purpose. Description fields on Cases often contain customer phone numbers or account details that support agents paste during troubleshooting. Notes and comment fields on any object can contain identifying information. These unstructured fields create compliance challenges because you cannot easily identify or redact the PII they contain.
Files and Attachments
Documents uploaded to Salesforce may contain PII that does not appear in structured fields. Contracts include customer names, addresses, and signatures. Invoices list billing information and payment details. Scanned documents like driver’s licenses or government IDs contain sensitive PII that requires special protection.
How to Find and Classify PII in Your Org
You need a systematic audit of your Salesforce configuration to locate all PII fields, categorize them by sensitivity level, and document which regulations apply to each data type.
Conduct a Field-by-Field Audit
Review every object in your org and identify which fields contain or could contain PII. Start with standard objects:
- Contact
- Lead
- Account
- Case
- User
Move them to custom objects, especially those related to customers, employees, or transactions, and flag free-text fields that users might use to enter personal information. Be sure to document each field’s purpose and the type of PII it holds.
Use Salesforce Data Classification
Salesforce provides a built-in way to tag fields by sensitivity level. Go to Setup, then Data Classification under Security to access the tool. Assign compliance categories to fields such as PII, PCI, HIPAA, or custom labels that match your industry requirements. Set sensitivity levels ranging from Public to Internal, Confidential, or Restricted based on the data’s risk profile.
Identify High-Risk Fields
Some fields require stronger protection than others based on what they contain and how you use them. Government IDs and financial data are high-risk and require encryption and restricted access. Health information triggers HIPAA requirements if you operate in healthcare or handle protected health information. Fields used in integrations are higher risk because data leaves Salesforce and enters systems you may not fully control.
Create a Data Inventory Document
Write down what you found so it becomes usable for security decisions and audits. List each PII field, its object, its sensitivity level, and which regulations apply to it. Note which roles or teams need access and document the business justification for that access. Record which integrations read from each field so you can assess data flow risks. Update the document when you add new fields or change access permissions to keep it accurate.
Limitations of Salesforce Protection Stops
The controls described above work inside Salesforce. They do not protect data once it leaves your org.
- Integrations Create Copies of Your Data: When Salesforce connects to other systems, PII moves outside your Salesforce security controls. The data now exists in multiple locations, each requiring its own protection measures.
- Integration Users Often Have Broad Access: The user accounts that power integrations typically have more access than human users because they need permissions to read and write data across multiple objects. This elevated access creates risk if credentials are compromised or if the integration pulls more data than necessary.
- Receiving Systems Have Their Own Rules: Your Salesforce security configuration does not transfer to other platforms that receive the data. Each system applies its own access controls, encryption standards, and retention policies that may not meet the same compliance requirements you enforce in Salesforce.
- You’re Still Responsible for That Data: Regulators do not care which system holds the PII or whether a third party manages it. They hold you accountable for protecting customer data throughout its lifecycle, regardless of where it travels after leaving Salesforce.
How to Protect PII When It Leaves Salesforce
Organizations must map every integration that extracts PII from Salesforce, restrict what each connection can access, encrypt data in transit, verify security controls in destination systems, and monitor all data movement to maintain compliance when PII crosses system boundaries.
Map Every Integration and Data Flow
You need a complete picture of where Salesforce data moves to understand your full risk exposure. List every system that reads data from Salesforce, including marketing tools, ERP systems, analytics platforms, and data warehouses. Document which objects and fields each integration accesses so you know exactly what data leaves your org. Note where the data lands and how long it is retained to assess compliance with data minimization requirements.
Limit What Each Integration Can Access
Apply the principle of least privilege to system connections, not just human users. Create dedicated integration users with restricted profiles that cannot access data beyond what the integration requires. Grant access only to the objects and fields the integration actually needs for its business function. Review integration permissions regularly, the same way you review employee access, to catch permission creep. Revoke access immediately when an integration is retired to eliminate unused pathways into your data.
Require Encryption for Data in Transit
Protect PII as it moves between systems to prevent interception during transmission. Require TLS encryption for all API connections that carry customer data. Use OAuth or token-based authentication instead of storing passwords that could be compromised. Encrypt files before transferring them between systems, even when using secure transfer protocols. Reject connections from systems that do not meet your encryption standards to maintain consistent protection.
Verify Protection in Destination Systems
PII landing in an unprotected system is a breach waiting to happen, regardless of how well you secured it in Salesforce. Confirm that receiving systems have tools to flag the movement of PII within your systems. Check whether sensitive PII is encrypted at rest in the destination, not just during transit. Verify that audit logging exists for PII access in each system so you can trace who accessed what data. Document destination security controls for compliance records and vendor risk assessments.
Monitor Data Movement
Visibility into integration activity helps you catch problems early before they become full breaches. Log integration activity including what data moved, when it moved, and where it went. Set alerts for unusual patterns such as large exports, off-hours activity, or new destinations that were not previously authorized. Review logs regularly as part of your security routine to identify potential issues. Retain logs long enough to support compliance audits and incident investigations, which may require records from months or years prior.
How to Keep PII Protection Working Over Time
Organizations must assign clear ownership for data governance, conduct quarterly access reviews, respond immediately to configuration changes, and test incident response procedures to prevent PII protection from degrading as systems and teams evolve.
Assign Someone to Own It
Without clear ownership, PII protection degrades as priorities shift and teams change. Designate a person or team responsible for Salesforce data governance and make it their explicit accountability. Make integration security part of their scope, not just Salesforce-native controls, because PII protection extends beyond the platform. Give them authority to enforce policies and block non-compliant requests that would introduce security gaps.
Review Access Quarterly
Regular reviews catch permission creep before it becomes a compliance problem. Audit Salesforce profiles, permission sets, and sharing rules to identify users with access they no longer need. Review integration user permissions alongside human user access because system accounts often accumulate excessive privileges over time. Check that data classification stays current as new fields are added to ensure sensitivity labels reflect actual risk.
Respond to Changes Immediately
Certain events should trigger an immediate security review rather than waiting for the next quarterly cycle. Adding a new integration that accesses Salesforce data requires verification that it meets your security standards before activation. Creating new objects or fields that contain PII demands classification and appropriate access restrictions from day one. Employees changing roles or leaving the organization require immediate permission updates to prevent unauthorized access.
Test Your Incident Response Plan
A breach response plan only works if people know how to execute it under pressure. Define what constitutes a reportable PII incident so teams can recognize when to activate the plan. Document who to notify internally and externally, and establish timeframes for each notification. Assign specific roles so everyone knows their responsibilities: who investigates, who contains the breach, and who communicates with affected parties. Run a tabletop exercise at least once a year to find gaps in your plan before a real incident exposes them.
Extend PII Protection to Every System That Touches Salesforce
Salesforce gives you the tools to classify, restrict, encrypt, and monitor PII inside your org. Those controls work. The gap appears when data moves to marketing platforms, ERPs, data warehouses, and other systems through integrations. Your compliance obligations follow that data, but your Salesforce controls do not.
Closing the gap requires visibility into every integration, restrictions on what each connection can access, encryption for data in transit, and equivalent protections in receiving systems.
Data Tools to Identify PII Moving In Your Systems
Organizations need visibility into how PII flows through their integration architecture to identify compliance risks and respond to data subject access requests.
Boomi DataDetective Visualizes PII Movement
Boomi DataDetective lets you visualize the movement of personally identifiable information between integration connections. The agent classifies data as PII by analyzing field names and process step names, then displays which data fields, connectors, processes, and countries are involved in moving that data. DataDetective refreshes weekly from your Integration account and uses customer-agnostic de-identified metadata, meaning it analyzes field structure rather than the actual customer data flowing through your integrations.
Implement PII Guardrails for Agentic Tools
AI governance tools like Boomi Agentstudio help ensure that PII stored in Salesforce is protected from being inappropriately accessed by AI Agents, enabling you to use AI securely. AgentStudio ensures that sensitive information remains protected throughout its lifecycle by allowing organizations to define and enforce data governance policies, it ensures that PII is handled in compliance with regulatory requirements. With features like real-time monitoring and auditing capabilities, Boomi AgentStudio helps organizations maintain visibility and control over their data flows, significantly reducing the risk of unauthorized access or data breaches.
Analyze PII Statistics By Category and Location
You can analyze PII data statistics using a detailed table view that breaks down information by data field, connector, process, and country. Filter by five PII categories including Financial, Health, Job, Personal, and Sensitive to see which integrations handle each type of data. The table displays up to 1,000 data fields and lets you group results by data field or by process to match your analysis needs.
Manage PII Data Field Classification
DataDetective lets you suggest tracking new data fields and changes to the categories of existing data fields. You can suggest whether a field should be classified as PII or Sensitive, and for PII fields you can select subcategories including Financial, Health, Job, and Personal. These suggestions help refine how your organization categorizes sensitive data without affecting integration performance or functionality.
The Boomi Enterprise Platform connects Salesforce to your other business applications through pre-built connectors that communicate over HTTPS, with data governance and API management built into the same environment. Organizations using Boomi can control which Salesforce objects and fields each integration accesses, encrypt data as it moves between systems, and maintain audit trails for compliance.
When PII protection extends beyond Salesforce to cover every system in your data ecosystem, you reduce breach risk and simplify the audit conversations that follow.
Explore Boomi’s Salesforce integration capabilities to see how organizations connect their CRM data to the rest of their tech stack.