Notifications
Clear all
Topic starter
20/08/2026 5:32 pm
TL;DR: Non-covered entities under HIPAA can still expose electronic protected health information through SaaS, cloud, endpoints, and AI workflows, and Strac’s article argues that classification alone does not reduce the underlying data-loss risk. The practical issue is governance: organisations outside HIPAA scope still need discovery, redaction, access control, and auditability where health data moves through modern systems.
NHIMG editorial — based on content published by Strac: What is Not a Covered Entity Under HIPAA in 2026
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should organisations protect e-PHI if they are not a HIPAA covered entity?
A: They should treat HIPAA status as a legal classification, not a security boundary.
Q: Why do health-data workflows create risk outside HIPAA scope?
A: Because data follows operational workflows, not regulatory labels.
Q: What do security teams get wrong about business associate agreements?
A: They often treat BAAs as a substitute for technical control.
Practitioner guidance
- Map e-PHI data paths across SaaS and AI tools Identify where health data enters collaboration apps, tickets, cloud storage, and MCP-connected workflows, then document who and what can access each path.
- Enforce identity-aware access controls on sensitive datasets Limit access with role-based and attribute-based policies for users, service accounts, and AI agents that handle e-PHI.
- Deploy discovery, redaction, and revocation together Use discovery to find PHI in files, chats, tickets, screenshots, and prompts, then apply redaction or tokenisation and revoke access when exposure exceeds the business need.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves for the source:
- Classification examples for covered versus non-covered entities across healthcare providers, health plans, and clearinghouses
- The specific BAA conditions that apply when non-covered organisations act on behalf of covered entities
- Operational DLP features for PHI discovery, redaction, tokenisation, and audit trails across SaaS and AI workflows
- MCP and GenAI workflow protections for PHI flowing between applications and AI agents
👉 Read Strac's guidance on HIPAA non-covered entities and e-PHI controls →
HIPAA non-covered entities: what controls still matter for e-PHI?
Explore further
20/08/2026 6:19 pm
Non-covered status is not a data-governance exemption. HIPAA classification answers a regulatory question, but it does not solve the access problem created by SaaS sharing, cloud replication, endpoint sync, and AI workflow reuse. Once e-PHI moves across systems, the organisation still needs identity-aware control over who can touch it and where it can flow. Practitioners should treat legal scope and operational exposure as separate decisions.
A question worth separating out:
Q: How can teams tell whether PHI controls are actually working?
A: Look for proof that sensitive data is discovered quickly, redacted where needed, and accessible only to authorised identities and workflows. Strong programmes can show who accessed e-PHI, where it moved, whether it was masked, and how quickly access was removed after use. If those answers are missing, the controls are mostly theoretical.
👉 Read our full editorial: HIPAA non-covered entities still need data controls for e-PHI
