What are the main Salesforce data security risks teams should look for first?

The first risks to look for are publicly shared sensitive files, credentials stored in plain text, credit card numbers in plain text, restricted data placed in non-production environments, and European personal data stored outside the EU. These conditions combine exposure, compliance, and governance issues, so they should be prioritized before broader policy tuning or deeper control automation.

Salesforce data security problems usually surface first as exposure problems, not sophisticated intrusion problems. Publicly shared files, credentials stored in plain text, and credit card numbers left in plain text create immediate loss of confidentiality and a fast path to downstream abuse. Those issues are more urgent than broader policy tuning because they are directly observable, directly exploitable, and often already in production.

For teams reviewing a Salesforce environment, the practical order is to find what is already exposed, then trace where that data can be copied, exported, or reused. A file that is shared too broadly, or a field that contains secrets in readable form, can bypass many of the controls people assume will save them later. The same is true for sensitive payment data, which can create both breach impact and compliance exposure. In practice, the highest-risk findings are usually the ones that require no special technique to abuse.

One useful signal from wider security research is that leaked secrets are slow to fix in the real world, with an average remediation time of 27 days in one study of secrets management practices. That matters here because a plaintext credential in CRM data is not just a policy violation, it is a durable access path until someone actively removes it. The State of Secrets in AppSec reinforces that secret exposure tends to persist long enough to become operationally significant.

In practice, teams usually discover these issues only after an export, integration, or access review exposes how much sensitive data was already sitting in reachable fields or shared files.

Environment Boundaries and Residency Rules Turn Simple Misplacements Into Real Risk

Non-production Salesforce environments are a common place where security intent and actual data handling drift apart. Copying restricted data into sandboxes, test orgs, or development instances expands the number of people, tools, and integrations that can see information that should have stayed constrained. That is not just a hygiene issue, it changes the trust boundary around the data.

Restricted records in non-production often have weaker access discipline than production.
Test data is frequently cloned, refreshed, exported, or shared more broadly than intended.
Integration credentials and debug output can make hidden data easier to recover.
Residency issues matter when personal data crosses regions without a justified control basis.

European personal data stored outside the EU deserves early attention because it combines security and governance risk. Even if the information is otherwise protected, the placement itself can create regulatory and contractual problems. The same review should ask whether the non-production environment is receiving full production data when masked or minimised data would satisfy the use case. The key question is not whether the team trusts the sandbox, but whether the sandbox needs the data at all. NIST Privacy Framework is useful here because it keeps the focus on data processing, minimisation, and governance outcomes rather than only technical controls.

These controls tend to break down when sandbox refreshes are routine but data classification is still handled manually, because the copying happens faster than the review.

Common Edge Cases That Change Priority

Tighter Salesforce data control often increases friction for sales, service, and analytics teams, so the right balance is usually to stop the most dangerous exposures first and then refine the broader governance model. The main trade-off is speed versus containment: the more convenience you preserve, the more carefully you need to prove that sensitive data is not being exposed through fields, files, exports, or downstream copies.

Two edge cases matter early. First, a field may look harmless until an integration or report makes it broadly readable. Second, data that is not obviously sensitive in production can become sensitive once it is copied into another system that has weaker controls or a wider audience. That is why the first pass should focus on the data objects and sharing paths that can leak immediately, not on abstract policy language.

For teams that want a practical triage rule, treat anything that can be exposed without authentication, anything that can authenticate elsewhere, and anything that carries legal or payment impact as a first-wave finding. Broader hardening still matters, but it should not displace the items that create immediate exposure or compliance breach. The State of Secrets in AppSec is also a reminder that teams often overestimate their control maturity, so the safest assumption is to verify the actual storage and sharing state rather than trust policy intent.

When organisations have many integrations, exports, and cloned environments, the first risk set is usually smaller than the full control backlog but more urgent than the teams expect.

Risk and Threat Considerations

The material risk is that exposed Salesforce data can be copied, reused, or redistributed long before anyone notices. Plain-text credentials and publicly shared files create direct compromise paths, while restricted data in test or non-production environments expands the number of places an attacker or insider may find usable information.

Failure mechanism: Misconfigured sharing, weak field hygiene, and unrestricted exports let sensitive records escape the intended trust boundary. Once a credential or payment value appears in readable form, the exposure is often durable because the data can be harvested silently and used later through other systems.

Impact: Teams can face account compromise, unauthorized access to connected systems, payment data exposure, and residency or privacy violations that are expensive to unwind. The operational impact is usually wider than the single record at fault because one exposed field can become a reusable access path or a reportable compliance event.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	3 — Data Protection	Controls sensitive data exposure in CRM fields, files, and exports.
	6 — Access Control Management	Limits who can reach exposed records and non-production copies.
Recommendation — Classify sensitive Salesforce data and restrict storage, sharing, and transfer paths. Review and remove excess access to Salesforce objects, files, and environments.
NIST CSF 2.0	PR.DS — Data Security	Directly addresses protection of data at rest, in transit, and in use.
	GV.RM — Risk Management Strategy	Helps prioritise the highest-impact Salesforce data risks first.
Recommendation — Apply data-security controls to prevent plain-text exposure and uncontrolled sharing. Rank exposed secrets, payment data, and residency issues as immediate remediation items.
NIST SP 800-63	IAL — Identity Assurance Level	Relevant where exposed credentials can be reused to reach linked systems.
Recommendation — Require stronger assurance for any identity path that can be reached from exposed data.

Practitioner Guidance

What to prioritise: Start with a literal exposure sweep, shared files, readable secret fields, plain-text payment data, and any non-production copy that contains restricted or EU personal data. If a finding can be abused without further exploitation, it belongs ahead of broader tuning work.

What to verify: Confirm whether each sensitive field is actually needed in Salesforce, whether it is masked outside production, and whether any integration, report, or export path makes it visible to more people than intended. The control is only real if the data cannot be recovered through an ordinary user path.

Practitioner takeaway: The fastest risk reduction comes from removing already-exposed data and constraining where sensitive records can exist, because a clean policy model means little if readable secrets or restricted data are already reachable.