Every year, security researchers publish findings about sophisticated nation-state attacks, zero-day exploits, and novel malware strains. CISOs read these reports and picture their adversaries as hooded figures in dark basements, running custom intrusion tools against hardened perimeters.
That picture is largely wrong — at least when it comes to your Salesforce org.
The Verizon Data Breach Investigations Report consistently finds that 74% of breaches involve a human element: phishing, credential theft, insider misuse, or simple misconfiguration. Seventeen percent involve internal actors. The mechanisms are rarely sophisticated. They exploit defaults that were never changed, permissions that were never reviewed, and data that was never deleted.
In Salesforce environments, this problem has a name: security debt. It accumulates silently, one convenience decision at a time, until the configuration of your CRM looks nothing like what any reasonable security policy would sanction — and everything like an open door.
What Security Debt Actually Looks Like
Security debt in a Salesforce org is not a theoretical concept. It shows up in specific, auditable ways. It is the system administrator profile assigned to an integration user because it was easier than building a custom permission set. It is the Communities site where publicly shared objects were never restricted because the project launched under a deadline. It is the sandbox that contains a full copy of production data, accessible to consultants whose NDAs expired two years ago.
It is, above all, the accumulated weight of thousands of small decisions made by people under pressure, who chose the path of least resistance and moved on.
Organizations that understand this dynamic stop looking for the exotic threat and start auditing the mundane one. The results are consistently alarming.
The System Administrator Problem
Ask a security-mature organization how many users hold the System Administrator profile in their Salesforce org. The answer should be between two and five. In practice, it is often ten, twelve, or more.
The System Administrator profile is the master key to your CRM. It bypasses field-level security. It overrides sharing rules. It can export any data, modify any record, and alter any configuration — including the audit trail settings that would catch it doing so. Handing that profile to twelve people is not a security posture. It is an abdication of one.
The pattern that creates this situation is familiar to anyone who has managed a Salesforce implementation. A developer needs to troubleshoot a data issue: easiest solution is to give them sysadmin temporarily. A power user needs to run a report that the standard profile won't allow: grant sysadmin and circle back to fix it later. A consultant joins for a three-month engagement: sysadmin is the path of least friction. Later never comes. The consultant leaves. The profile remains.
The System Administrator profile is the master key to your CRM. Handing it to twelve people is not a security posture — it is an abdication of one.
The remediation path is well understood: audit your sysadmin users quarterly, build custom permission sets that grant only the specific access each user needs, and treat the sysadmin profile as a standing exception that requires documented justification. The implementation is straightforward. The discipline to maintain it is not.
Integration Users: The Highest-Risk Profile in Your Org
If over-provisioned human users represent one category of risk, integration users represent something worse: a user account with sysadmin-level access that no human monitors because no human ever logs into it.
Integration users are accounts created to allow external systems — marketing platforms, ERP systems, data warehouses, custom APIs — to connect to Salesforce. In a well-architected org, each integration has its own named user with the minimum permissions required to perform its specific function. In the average enterprise Salesforce org, integration users frequently run on the System Administrator profile because the developers building the integration did not want to spend time scoping permissions.
The security implications compound in two directions. First, a compromised integration user credential grants an attacker unrestricted access to your CRM, with no multi-factor authentication challenge because integration accounts typically cannot complete MFA flows. Second, because no human is logging in as that user, anomalous activity — bulk data exports, record deletions, configuration changes — may go undetected for weeks or months.
Salesforce offers a dedicated Integration User license at approximately $120 per year. It is specifically designed for this purpose, with a profile architecture that supports tight permission scoping. Most organizations that are running integration users on sysadmin profiles are doing so not because the Integration User license is cost-prohibitive, but because the architectural work to scope permissions was never prioritized.
A compromised integration user credential grants an attacker unrestricted access to your CRM — with no MFA challenge, because integration accounts typically cannot complete MFA flows.
The fix is to audit every integration user in your org, identify those running on sysadmin or other over-privileged profiles, and rebuild their permission sets from scratch using least-privilege principles. For each integration, ask: which objects does this system need to read? Which does it need to write? Does it ever need to delete? Does it need to access any fields containing PII or financial data that its function does not require? The resulting permission set will be tighter, more auditable, and dramatically safer.
Communities and the Public Object Problem
Salesforce Communities — now rebranded as Experience Cloud — is one of the platform's most powerful features. It allows organizations to build external portals for customers, partners, or employees, with data surfaced directly from the CRM.
It is also, consistently, one of the most misconfigured components in any Salesforce deployment.
Analysis of Communities deployments across enterprise customers finds that over 70% have at least one object with sharing settings that expose data to unauthenticated or lightly authenticated external users. In many cases, these are objects that were shared during early development — when the portal was being built and developers needed quick access to test data — and the sharing settings were never tightened before the site went live.
The consequences can be severe. A misconfigured sharing rule on an Account or Contact object can expose your entire customer database to anyone who knows how to query the Communities API. A misconfigured Case object can expose support tickets containing confidential details about your customers' operations. A misconfigured custom object can expose proprietary pricing, contract terms, or partner information.
The audit process is not complex: review the sharing settings for every object accessible through your Communities site, verify that guest user profiles have access only to what they explicitly require, and ensure that any objects containing PII or commercially sensitive data are restricted to authenticated users with documented business justification for access. Run this audit before every Communities release, not just at initial deployment.
The Data You Are Storing That You Should Not Be
There is a useful heuristic for thinking about CRM data: at any given time, approximately 30% of the records in your Salesforce org are actively relevant to your business. The remaining 70% — closed deals from three years ago, churned customers with no re-engagement potential, contacts who have not opened an email since the Obama administration — are organizational sediment. They serve no business purpose. They are maintained out of inertia.
From a security and liability standpoint, that sediment costs you exactly as much as your active data. Every contact record in your org is subject to data subject access requests under GDPR and equivalent regulations. Every account record containing PII must be protected under the same security controls as your most sensitive customer data. A breach that exposes records from 2019 is legally identical to a breach that exposes records from last week.
Seventy percent of the data in your Salesforce org is obsolete — but it carries the same legal liability as the data you use every day. You are paying to protect a liability, not an asset.
The discipline of data minimization — retaining only the data you need for as long as you need it — is required by GDPR's storage limitation principle and supported by straightforward business logic. An org that contains only relevant, current data is smaller, faster, cheaper to back up, easier to audit, and significantly less liable in the event of a breach.
Building a data retention policy is the work of an afternoon. Implementing it requires cross-functional alignment — legal, compliance, sales leadership, and the Salesforce team all need to agree on retention windows. But the technical implementation, once policy is agreed, is entirely within the capabilities of any Salesforce administrator. Archive or delete inactive contacts and leads on a defined schedule. Hard-delete closed opportunities beyond your retention window. Document what you are keeping and why.
The AI Shadow Usage Problem
There is a new category of security risk that most Salesforce security frameworks have not yet fully accounted for, and it is growing faster than any technical vulnerability: employees copying CRM data into unapproved AI tools.
The pattern is intuitive and understandable. A sales manager wants to analyze their pipeline. They export account data from Salesforce, paste it into ChatGPT, and ask for a summary. A customer success manager is writing a renewal proposal. They copy contact notes from Salesforce into an AI writing tool to generate a first draft. A support lead is trying to understand case patterns. They export case histories and paste them into a generative AI interface to identify trends.
Each of these actions may or may not violate the terms of service of the AI tool in question. Each may or may not result in that data being used to train future models. What is certain is that the moment Salesforce data containing PII leaves your controlled environment and enters an unapproved third-party service, you have experienced a data breach under most regulatory frameworks. Your employees are not acting maliciously. They are acting efficiently. The result is the same.
Addressing this requires both technical and organizational responses. On the technical side, Event Monitoring can detect anomalous bulk data exports that may indicate AI-feeding behavior. Data Loss Prevention tools can flag or block transfers to known AI endpoints. On the organizational side, the response is clear policy, communicated clearly: CRM data stays in approved systems, and AI tools for analyzing CRM data must be vetted and approved before use. The policy itself is simple. Making it stick requires a security culture that most organizations are still building.
Sandbox Security: The Breach You Are Not Counting
Full copy sandboxes exist for legitimate reasons. Testing data migration scripts on production-scale data. Validating complex integrations against real record volumes. Reproducing production issues that cannot be replicated in partial or developer sandboxes. These are valid use cases.
They do not justify treating sandbox environments as security second-class citizens.
A full copy sandbox contains an exact replica of your production data: every customer record, every contact, every deal history, every support case. It is, for all practical purposes, a second copy of your most sensitive data. In most organizations, it receives a fraction of the security attention that production does.
A breach is a breach whether it happens in production or in a full copy sandbox. The data is identical. The liability is identical. The only thing that differs is that most organizations have no controls in the sandbox at all.
Sandbox users frequently have sysadmin access because it is easier to grant broad permissions in a non-production environment. External consultants may have sandbox access that was provisioned for a project years ago and never revoked. Sandbox orgs may not have MFA enforced. They may not be included in security audits. They may not be covered by your organization's DLP policies.
The remediation framework is straightforward: apply the same security standards to full copy sandboxes that you apply to production. Mask or anonymize PII at the time of sandbox creation if the use case permits. Conduct quarterly access reviews of sandbox users with the same rigor as production. Revoke consultant access immediately when engagements conclude. Treat any anomalous sandbox activity as a potential production-level security event.
Event Monitoring: Your Minimum Viable Security Layer
You cannot manage what you cannot see. In Salesforce, the tool that lets you see is Salesforce Shield Event Monitoring.
Event Monitoring provides granular log data on what is happening in your org: who logged in and from where, which reports were run and exported, which API calls were made by which users, when bulk record operations occurred, and dozens of other event types. Without it, your ability to detect and investigate security incidents in your Salesforce environment is fundamentally limited.
The use cases are immediate and practical. An employee is terminated. Event Monitoring lets you verify whether they bulk-exported customer data in the hours before their departure. A competitor appears to have access to your pricing. Event Monitoring lets you trace who accessed your price book records and when. An integration starts behaving anomalously. Event Monitoring lets you identify exactly what API calls it is making and how that compares to its historical baseline.
Organizations that treat Event Monitoring as a nice-to-have are making a category error. In any environment where Salesforce contains material business data — which is to say, virtually every enterprise Salesforce deployment — Event Monitoring is the minimum viable security layer. The question is not whether it is worth the investment. It is what you are willing to be unable to investigate.
Beyond detection, Event Monitoring data integrates with SIEM platforms, allowing your security operations team to correlate Salesforce events with activity in other systems. A login from an unusual geography combined with an immediate bulk export, occurring outside business hours, is a pattern that a human reviewer might miss in isolation but that a properly tuned SIEM rule will catch reliably.
Building the Audit Habit
Security debt is not eliminated by a single remediation project. It accumulates continuously, driven by the same organizational dynamics that created it in the first place. Addressing it requires not a project but a practice: a regular, disciplined audit cycle that catches new debt before it compounds.
For most enterprise Salesforce orgs, a quarterly security review should cover the following at minimum: total count of System Administrator profile users with justification for each; all integration users and their associated profiles and permission sets; Communities sharing settings with specific attention to guest user access; bulk data export events from the prior quarter; user access for departed employees and inactive contractors; and sandbox access lists against a current roster of authorized users.
This is not a substitute for continuous monitoring. It is the baseline. Organizations that cannot answer each of these questions in under an hour have a security posture problem regardless of how sophisticated their other controls are.
Salesforce's Health Check tool is a useful starting point: it provides a score against Salesforce's baseline security settings and surfaces the most common misconfigurations. It is not comprehensive — it does not cover user access patterns, data retention, or integration user permissions — but it is a floor, and organizations scoring below 80 should treat that as a signal that more fundamental remediation work is required.
The Compounding Cost of Inaction
Security debt, like financial debt, compounds. A misconfiguration that goes unaddressed for six months is not just a six-month-old problem. It is a problem that has been active for six months, during which the user or system it enables may have accessed data they should not have, exported information that should have stayed in the org, or created further configurations that depend on the original misconfiguration and will need to be unwound when it is finally corrected.
The regulatory environment is not static. GDPR enforcement actions have reached hundreds of millions of euros. State privacy laws in the United States are proliferating. The concept of data minimization, which once seemed like a compliance abstraction, is now a litigation exposure. Organizations that have not built the practice of data hygiene are not just non-compliant in theory: they are accumulating liability that will eventually be enforced.
The Salesforce platform provides the tools required to maintain a strong security posture. Permission sets, integration user licenses, Event Monitoring, Health Check, sandbox data masking — these exist precisely because the risks they address are real and common. The gap between what the platform makes possible and what most organizations actually implement is where security debt lives.
Where to Start
For organizations beginning this work, the priority sequence is clear.
Start with users. Pull a list of every user holding the System Administrator profile. Justify each one or remove the profile. Pull a list of every integration user and verify that none are running on sysadmin. If they are, rebuild their permission sets.
Move to data. Run your Health Check and address anything below your target score. Review your Communities sharing settings. Establish a data retention policy and implement it.
Then build the monitoring layer. Deploy Event Monitoring if you have not already. Connect it to your SIEM. Define the alert conditions that matter for your environment. Run your first bulk export report and look at what comes back.
Finally, institutionalize the practice. Build the quarterly audit into your security calendar. Assign ownership. Track the metrics over time.
None of this requires exotic expertise or significant budget. It requires the organizational will to treat Salesforce as what it actually is: one of the most data-rich systems in your enterprise, deserving of security attention commensurate with the value and risk of what it holds.
The organizations that get breached through their Salesforce org are not, in retrospect, surprised. The risks were visible. The remediations were available. The decision was made — implicitly, through inaction — not to prioritize them.
The breach that exposes your Salesforce data will most likely not arrive through a zero-day exploit or a nation-state intrusion. It will arrive through a credential that was phished from a user with sysadmin access, or an integration user that was never locked down, or a Communities portal that was never properly secured, or a bulk export that went undetected because nobody was watching.
Fix your defaults. Audit your profiles. Archive your data. Watch what is happening. The sophistication required to protect your Salesforce org is modest. The discipline required is not — but it is available to any organization that decides to exercise it.