TL;DR: Sensitive data in Salesforce accumulates in case comments, email-to-case bodies, attachments, Chatter threads, rich-text fields, and unmasked sandbox copies, where excessive permissions, stale OAuth grants from third-party apps, and missing classification turn everyday work into exposure that endpoint and network tools cannot see. Effective Salesforce data loss prevention runs at the application layer: You want to discover and classify actual field content instead of field names, tighten admin profiles and integration credentials, mask sandboxes and encrypt regulated fields, and then remediate findings automatically rather than adding them to a backlog.
Your Salesforce org holds more sensitive data than your data map admits. Social Security numbers get pasted into case comments; bank details arrive through email-to-case and sit in the message body forever; signed contracts, invoices, and scanned IDs pile up as attachments that nobody has opened since 2019. And every sandbox refresh from production clones all of it again, usually without masking.
Here's the uncomfortable part: Salesforce data loss rarely starts with an attacker; it starts with regular people doing regular work in an org configured for speed, not containment. This article covers where the exposure actually happens, which risk factors create it, what Salesforce secures versus what falls on you under the shared responsibility model, and the controls that prevent Salesforce data loss in practice. You'll also see why endpoint and network tools stay blind to every example above and what effective Salesforce data loss prevention has to look like instead.
{{banner-large="/banners"}}
Where Salesforce Data Loss Actually Happens
Ask a security team where the sensitive data in Salesforce lives, and you'll usually get a short list of fields: contact records, opportunity amounts, maybe a custom SSN field on a loan object. That list is almost always wrong, or at least, badly incomplete. The data that creates real exposure tends to sit in the places nobody thought to inventory, which is exactly why Salesforce data loss prevention programs stall before they start.
Where Sensitive Data Hides Across Salesforce
Structured fields are the easy part; the hard part is everything that gets typed, pasted, or attached during normal support and sales work. Here are the locations that surface again and again in real customer environments:
- Case objects and case comments: Agents paste Social Security numbers, card details, and dates of birth into comments to move a ticket forward, then leave them there permanently.
- Email-to-case bodies: Customers send account numbers, routing details, and medical context in inbound email, and the full body is stored as a record.
- File attachments and ContentDocuments: This includes scanned IDs, invoices, signed agreements, and spreadsheets exported from other systems, often with inline images and embedded tables.
- Chatter, feed comments, and live chat transcripts: This category includes unstructured PII from agent conversations plus the occasional credential shared for convenience.
- Rich-text fields, custom objects, and custom fields: Here, for example, you find free-form notes on objects an admin built three years ago, named something no pattern-matching tool would ever flag.
- Sandbox copies: This includes full production data, cloned on refresh, with looser access and more users.
Almost every one of these is free text or a binary file. That is the blind spot that most Salesforce DLP tooling never covers because it was built to read schemas rather than content.
Why This Is a Discovery Problem Before It's a Security Problem
You cannot enforce a policy against data you have not located. Most Salesforce data loss starts here: Sensitive records are scattered across dozens of objects and thousands of free-text fields, not sitting in one tidy, well-labeled column. Schema-based tools scan field names, find nothing suspicious, and report a clean org while the actual regulated data sits in comment threads and PDF attachments.
The fix is sensitive data discovery that reads the values, not the labels, and covers attachments, transcripts, and rich text alongside standard fields. Once you know what lives where, the follow-on controls stop being guesswork.
Every control you apply later (e.g., encryption, access limits, retention, and masking) is only as good as the map underneath it.
So the sequence to prevent Salesforce data loss is straightforward: Discover what is actually in the org, classify it accurately enough to distinguish a test record from a real medical claim, then enforce controls that match the sensitivity you found.
The Risk Factors Behind Salesforce Data Exposure
Across many organizations, the answer keeps landing on the same three compounding factors:
- Permissions that outgrew governance
- Blind spots nobody owns
- Copies of production data sitting in places with no controls attached
Each one on its own is manageable, but taken together, they're the reason Salesforce data loss keeps happening to companies that thought they were covered.
Misconfiguration and Excessive Access
Salesforce hands you an enormous amount of configuration power, which means it also hands you an enormous amount of room to get it wrong. Sharing rules stack on top of role hierarchies, which stack on top of permission sets, which stack on top of profiles. Nobody sits down and decides to give a contractor read access to every closed account. It happens because someone cloned a profile during onboarding and it was never reviewed again.
These are the access patterns that cause the most damage, and they show up consistently in orgs of every size:
- Over-permissioned guest users: Experience Cloud (formerly Community) sites configured with guest user profiles that can query far more objects than the public page needs, turning a marketing microsite into an unauthenticated data endpoint
- Admin profile sprawl: Too many System Administrator profiles, often granted to solve one urgent ticket and never revoked, each one carrying full export capability
- Blanket data permissions: Broad “Modify All Data” and “View All Data” permissions attached to permission sets that get assigned in bulk, quietly bypassing every sharing rule underneath them
- Shared integration credentials: Integration users authenticating with shared logins and admin-level scope, so a single compromised token inherits the keys to the entire org
None of this requires an attacker to be clever. It requires an insider, phished session, or stale OAuth grant.
Blind Spots Most Teams Never Close
Ask who owns Salesforce data security, and you'll usually get a pause. The Salesforce admin reports into RevOps or IT. Security owns the perimeter and identity. Compliance owns the policy document. The data itself sits between them, which means audits cover standard objects and stop there. Custom objects, free-form text fields, and rich-text areas rarely make it into scope because they don't map to a known schema.
Third-party integrations widen the gap further. AppExchange packages, marketing automation, support tooling, and analytics connectors all request scopes at install time, and those grants outlive the project that justified them. The August 2025 campaign against Salesforce customers, reported by Google Threat Intelligence Group, worked exactly this way: Attackers used stolen OAuth tokens tied to a third-party chat integration to pull data from hundreds of connected orgs. The Salesforce platform was never breached; the trust relationships around it were.
Sandboxes and Unclassified Data
Every full sandbox refresh copies production records into an environment with looser access, more admins, and less monitoring. Developers, contractors, and offshore teams get logins there that they'd never receive in production. If the data wasn't masked or anonymized on the way in, you'll duplicate your regulated records into a space with a fraction of the controls, and most teams never count those copies when they map data sprawl.
Underneath that sits the bigger issue: Most companies have no classification scheme applied inside Salesforce at all. PII, PHI, cardholder data, and API keys stored in text fields all carry the same label, which is no label. You can't enforce a retention policy, masking rule, or access review against data you haven't tagged. Classification is the dependency everything else waits on.
The Real Cost of an Exposure
Salesforce holds customer records, which means an exposure triggers obligations rather than an internal cleanup. Depending on what leaked, that means HIPAA breach notification, PCI DSS reporting to your acquirer, GDPR's 72-hour supervisory authority window, CCPA statutory damages, and SOX implications when financial records are involved. Then come the notification letters, credit monitoring, and sales cycles that stall while prospects ask what happened.
The global average cost of a data breach has reached $4.99 million, a 12% increase and a record high, driven by higher detection, escalation, and lost business costs.
What Salesforce Secures Versus What You Own
Salesforce operates on a shared responsibility model, and the line is cleaner than most teams assume. Salesforce secures the infrastructure, application code, physical data centers, network layer, and platform availability. You own configuration, user access, and everything at the data level.
The native toolset helps, and you should be using it. Shield Platform Encryption protects specified fields at rest, Event Monitoring surfaces login and export activity, Setup Audit Trail records administrative changes, and Security Health Check scores your settings against a baseline. What none of them do is tell you which fields contain Social Security numbers, redact a card number pasted into a case comment, or open an attachment and read it. Salesforce ships no built-in DLP. Encryption without classification just protects unknown content very well.
Why Endpoint and Network DLP Fail at the SaaS Layer
Endpoint agents watch files leaving a laptop, while network DLP inspects traffic crossing a gateway. Neither one can see inside an authenticated HTTPS session to a tenant your users are supposed to be in, doing work they're supposed to be doing. A support agent typing a bank account number into a case comment generates no file transfer and no anomalous traffic, so both layers stay silent.
API-based scanners get closer but stop short. They read structured fields well but miss inline images, embedded PDFs, rich-text markup, Chatter threads, and live chat transcripts where unstructured PII actually accumulates. Add contractors on unmanaged devices and sandbox environments that sit outside the corporate network entirely, and the coverage gap becomes structural. To prevent Salesforce data loss, enforcement has to happen at the application layer, inside the organization, at the moment the data is created. That is the bar any Salesforce DLP approach has to clear.
{{cs-1="/banners"}}
How to Prevent Salesforce Data Loss
Everything above points to the same conclusion: Controls have to sit next to the data, inside the organization, and they have to run on something more reliable than field names. Here's the sequence that works, in the order it actually has to happen.
Lock Down Access and Permissions
Least privilege in Salesforce is less a policy statement than a cleanup project, and it pays back faster than anything else on this list. Every admin profile you remove shrinks the blast radius of a single compromised session, which is why any serious Salesforce data loss prevention effort starts with permissions rather than tooling.
Here is a practical order of operations for tightening a firm that has drifted over several years of quick fixes and one-off requests:
- Benchmark your baseline: Run a Security Health Check against the Salesforce Baseline Standard and record the starting score, so you have evidence of movement for your next audit cycle.
- Justify every admin: Pull the list of users with the System Administrator profile and write down a business reason for each one. Anything without a named reason gets downgraded to a permission set with scoped rights.
- Hunt the override permissions: Audit every assignment of “Modify All Data” and “View All Data,” including permission sets and permission set groups, since these silently override the sharing rules sitting underneath them.
- Separate your integrations: Give each integration its own connected app and dedicated credentials. Shared service accounts make it impossible to tell which system pulled 200,000 records at 3 am.
- Harden the login path: Enforce MFA, and route all human logins through your identity provider via SSO, then set login IP ranges and session timeouts by profile.
- Check the public edges: Review guest user access on every Experience Cloud site and confirm which objects those profiles can actually query.
Work through that list, and you close the majority of the paths that turn one phished credential into a full export. It also gives you a defensible answer when an auditor asks who can see what, which is usually the harder question to answer on the spot.
Find and Classify Sensitive Data First
Access controls determine who reaches the data. Classification determines which data deserves protection in the first place, and without it every downstream control is guesswork. You need coverage across standard and custom objects, every field type including rich text, file attachments, and the free-form content buried in Chatter posts and chat transcripts, which is where sensitive detail tends to accumulate quietly.
Label what you find by category: PII, cardholder data, PHI, credentials, and business-critical IP. That labeling is what makes a retention rule, an entitlement review, or a masking job enforceable instead of aspirational. Schema-driven scanners struggle here because a heavily customized org names its objects after internal projects rather than data types, so the classifier has to read content and context.
Classification you can defend in an audit is the difference between a policy document and an enforced control.
Mask Sandboxes and Encrypt Data at Rest
Sandbox refreshes are the easiest win available. Salesforce ships Data Mask for anonymizing production records after a copy, and applying it belongs in the refresh runbook as a required step, not an optional one. Anything genuinely unnecessary in a lower environment should be deleted outright rather than masked, since a record that never lands in the sandbox cannot leak from it.
For production, apply Shield Platform Encryption to the fields your classification pass flagged as regulated, and manage keys with bring-your-own-key so key custody stays with you. Be clear-eyed about the limitations: Encryption protects data at rest but does nothing about a card number sitting in plain text in a case comment that a thousand users can read. It is one layer of Salesforce DLP, and its value depends entirely on knowing which fields to cover. Pair it with controls that prevent data exposure at the point where records are read, shared, and exported, and you close the gap that encryption alone leaves open.
Closing the Gap Between Detection and Remediation
Most Salesforce security programs stall in the same place. A scan runs, a report lands, and a list of findings goes into a queue that never empties. The exposure is documented but still exposed. The distance between “we found it” and “it's fixed” is where the actual risk lives, and in most orgs that distance is measured in weeks. Effective Salesforce data loss prevention starts with shortening that distance, not producing a longer report.
Monitor Continuously, Including What AI Agents Can Reach
Quarterly scans tell you what your organization looked like a quarter ago. Salesforce changes daily: new custom fields, permission set assignments, integration users, and case comments. Monitoring has to run at the same cadence the data does, with policy-based controls on the actions that carry real blast radius, such as bulk exports, permission grants that add “View All Data,” and API calls from IP ranges you don't recognize. That cadence is what separates a functioning Salesforce DLP program from an annual compliance exercise.
Then there's the newer surface. Agentforce, copilots, and MCP-connected assistants query records on a user's behalf and surface them in a chat window, which means an agent inherits whatever the underlying permissions allow, including the case comment nobody classified. If you can't answer what your AI agents can reach inside Salesforce, you don't have an AI governance story.
Detection and remediation belong in one workflow. Split them across two tools and two teams, and the lag between them becomes your exposure window.
Teleskope for Salesforce Data Loss Prevention
Teleskope is an official Salesforce partner, and the reason the integration matters is what happens after a finding. Classification is context-aware rather than schema-driven, so heavily customized and in-house-built orgs (where field names tell you nothing) still get accurate results across standard objects, custom objects, fields, attachments, and unstructured text. The data map updates continuously instead of arriving as a snapshot, so the picture you act on is the picture that exists right now.
The table below compares how a conventional scanner and Teleskope handle the four areas where most Salesforce data loss actually happens.
Every action carries a full audit trail and stays reversible, which is what makes automation defensible in front of an auditor and survivable for the admin who has to explain it. Sandbox refreshes get synthetic or masked values that preserve relationships, so testing still works. To prevent Salesforce data loss without stalling the business, move in stages: Start with discovery, add human-in-the-loop enforcement on high-confidence findings, then widen the scope once the team trusts the results. That is the same “find the risk, fix the risk” loop that keeps findings from piling up in a queue nobody works.
Book a call to see how Teleskope resolves Salesforce data exposure.
{{cs-2="/banners"}}
Conclusion
Companies rarely get burned because their infrastructure was flimsy. They get burned because nobody could say, with any evidence behind it, what was sitting in a rich-text field on a custom object somebody built four years ago, or which of the 40 connected apps still had a live token. That gap is fixable, and the sequence matters more than the tooling. Know what you hold, know who and what can reach it, then actually close the findings instead of logging them in a spreadsheet nobody opens. Most Salesforce data loss starts in that unmapped middle ground.
Pick one place to start this quarter: Run Health Check and count how many profiles carry admin rights, or scan a single high-volume object like Case and read what people have typed into the comments. Whatever turns up will build the business case better than any deck. From there, judge every Salesforce DLP option against one question: Once it flags something, who does the work? If the answer is your team, you have bought a longer to-do list. The tools worth choosing are the ones that remediate, not just report.
