Access control alone does not stop sensitive data from being entered into records, file uploads, or message threads. PHI often arrives through forms, emails, scans, and integrations, then remains readable inside standard objects unless it is detected and redacted. That creates compliance risk because the data is present, searchable, and reusable across workflows.
Why This Matters for Security Teams
Salesforce access controls reduce who can view a record, but they do not stop protected health information from being introduced into the platform in the first place. PHI can arrive through case notes, free-text fields, file attachments, email-to-case, web forms, and integrations, then persist in searchable objects, comments, and activity timelines. That makes exposure possible even when role design looks correct on paper.
The operational risk is that healthcare teams often treat the CRM as a controlled workspace rather than a data intake and processing environment. Once PHI is stored, it can be copied into reports, synchronized to downstream systems, or surfaced in support workflows that were never designed for regulated content. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes that governance, data protection, and monitoring have to work together, not in isolation.
In practice, many security teams encounter PHI exposure only after a workflow has already been operationalized, rather than through intentional data classification and intake design.
How It Works in Practice
The practical problem is not just access to records. It is the combination of ingestion, persistence, replication, and reuse. A user may be permitted to open a case, but the case may include an attachment containing a referral letter, a scan with diagnosis details, or a message thread where staff paste chart excerpts. Standard object permissions do not automatically inspect or remove sensitive data.
Controls need to address the full path of PHI through the system:
- limit what can enter the platform through forms, APIs, and email channels
- detect PHI in free text and files before it is stored or shared
- apply redaction or tokenisation where business use does not require full disclosure
- restrict integration scopes and service accounts so downstream copies are not broader than necessary
- log access and changes to sensitive fields for review and investigation
That last point matters because many healthcare workflows rely on non-human identities such as sync jobs, notification services, and automation rules. If those credentials are over-permissioned or unmanaged, they can move PHI across objects and tenants faster than human reviewers can notice. The OWASP guidance on the OWASP Non-Human Identity Top 10 is relevant here because machine accounts often become the hidden path for data propagation.
For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it maps well to access enforcement, audit logging, data retention, and information flow restrictions. These controls tend to break down when multiple healthcare business units share the same Salesforce instance and custom integrations bypass the normal field-level review process.
Common Variations and Edge Cases
Tighter content controls often increase workflow friction, requiring organisations to balance clinical or operational speed against privacy assurance. That tradeoff becomes sharper when staff need to capture patient context quickly, because too much friction drives users back to email, chat, or copy-paste habits that create even larger exposure trails.
There is no universal standard for every Salesforce healthcare deployment because risk depends on how PHI enters, where it is stored, and whether the org includes managed packages, external portals, or AI-assisted summarisation. Best practice is evolving, especially where agentic automation drafts notes or classifies cases from unstructured inputs. In those environments, the biggest risk is not the user who already has access, but the workflow that silently expands the amount of PHI being captured.
The Anthropic report on AI-orchestrated cyber espionage is not healthcare-specific, but it is a reminder that automated systems can amplify data movement once they are given tool access and broad context. For organisations using AI inside Salesforce, governance should focus on what the model can ingest, retain, and echo back into records. In these environments, controls often fail when teams assume platform permissions are equivalent to content safety, because PHI can still be introduced through automation, then reused in ways security owners did not intend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | PHI exposure is a data security problem, not just an access problem. |
| NIST AI RMF | AI-assisted workflows can ingest and reproduce PHI if not governed. | |
| OWASP Non-Human Identity Top 10 | Service accounts and automations often move PHI beyond human review. | |
| NIST SP 800-53 Rev 5 | AU-2 | Auditability is needed to trace where PHI entered and spread in Salesforce. |
| MITRE ATLAS | AI features can leak or transform sensitive data through model-assisted workflows. |
Set governance for any AI feature that sees healthcare data before it can store or emit PHI.
