What breaks when Salesforce has no PHI detection for messages and attachments?

Why This Matters for Security Teams

When Salesforce stores messages and attachments without PHI detection, the problem is not only privacy leakage. It is also a control failure that weakens case handling, access governance, retention discipline, and audit readiness. Teams may assume that role-based access is enough, but PHI can spread into comments, files, and threaded conversations that are searchable, shared, and retained for legitimate business reasons. The result is data that remains operationally useful while becoming harder to classify, govern, and defend.

For healthcare-adjacent teams, this is where security, compliance, and operations collide. A record can contain diagnosis details, insurance identifiers, test results, or treatment notes, and those elements can persist across workflows that were never designed as clinical repositories. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that data governance and asset visibility are core security outcomes, not optional hygiene. Without content detection, teams lose the ability to apply handling rules at ingestion and after the fact.

In practice, many security teams encounter the PHI problem only after users have already copied sensitive content into records, instead of through intentional data classification at the point of entry.

How It Works in Practice

Effective PHI detection in Salesforce depends on scanning content where it appears, not just where it is stored. That means reviewing message bodies, case notes, file uploads, email-to-case content, and attachment text extraction. Detection usually combines pattern matching, contextual rules, and exception workflows. Best practice is evolving, but most mature programs treat PHI discovery as part of a broader data security and privacy control stack rather than a standalone filter.

A practical design usually includes:

• Pre-ingest or near-real-time scanning so sensitive content can be tagged before broad distribution.
• OCR or document parsing for scanned files, images, and PDFs that contain embedded text.
• Classification labels and handling rules that limit sharing, export, and downstream automation.
• Exception queues for ambiguous matches, because false positives are common with medical abbreviations and patient-like identifiers.
• Logging and audit trails that show when PHI was detected, who reviewed it, and what action was taken.

The control objective is not simply to block all sensitive content. It is to make sure PHI is visible enough for governance decisions, minimum-necessary access, and retention enforcement. That aligns well with the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls around access control, auditability, and information management. In parallel, operational teams often map the detection workflow into incident response so confirmed exposure can trigger containment, review, and notification steps without delay. These controls tend to break down when files are stored as images or free-text exports are copied into custom fields because the content no longer follows the same inspection path as standard CRM objects.

Common Variations and Edge Cases

Tighter PHI detection often increases review overhead, requiring organisations to balance privacy protection against workflow friction and false positives. That tradeoff is especially visible in Salesforce environments with heavy customization, multiple business units, or large volumes of customer communications.

One common edge case is contextual ambiguity. A term that looks medical in one case may be a product name, a city, or an internal abbreviation in another. Current guidance suggests using layered logic rather than relying on a single keyword list. Another edge case is inherited data. Historical attachments, imported cases, and integration-fed notes may already contain PHI before a control is introduced, so discovery and remediation matter as much as forward-looking detection.

There is also an important boundary between PHI detection and broader DLP. PHI rules should not be treated as a generic data-loss problem only; they need policy decisions about retention, masking, access, and deletion. Where workflows involve partners, call centers, or AI-assisted summarisation, the risk becomes larger because content can be copied into secondary systems with weaker governance. That is why the most reliable programs combine detection with role design, review processes, and content lifecycle controls, rather than assuming a single filter will solve the problem. The NIST SP 800-53 Rev 5 Security and Privacy Controls remains the clearest baseline for translating those policy choices into implementable safeguards.

Related resources from NHI Mgmt Group

• What breaks when refresh token rotation does not include reuse detection?
• What breaks when NHI detection lacks ownership context?
• What breaks when breach detection takes months?
• What breaks when an OAuth-connected app is compromised in Salesforce?