HIPAA non-covered entities still need data controls for e-PHI

At a glance

What this is: This article explains who is not a covered entity under HIPAA and argues that non-covered organisations still need controls for sensitive health data moving through SaaS, cloud, and AI workflows.

Why it matters: It matters to IAM practitioners because access, sharing, and lifecycle controls still govern e-PHI exposure even when an organisation sits outside HIPAA’s formal covered-entity category.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Strac's guidance on HIPAA non-covered entities and e-PHI controls

Context

HIPAA scope is a classification problem, but data exposure is an access-control problem. Organisations can fall outside the covered-entity definition and still process electronic protected health information through SaaS platforms, cloud storage, endpoints, and AI tools. For identity teams, that means the absence of a HIPAA obligation does not remove the need to govern who can see, move, or exfiltrate sensitive health data.

The article’s core point is that modern workflows blur the line between regulated and unregulated environments. Once health data enters collaboration apps, external sharing channels, or MCP-connected AI workflows, traditional compliance boundaries stop being a reliable protection model. That starting position is common in digital operations and becomes more visible as AI assistants and workflow automation expand the data surface.

Key questions

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. If e-PHI exists in SaaS, cloud, endpoints, or AI workflows, organisations still need discovery, access control, redaction, logging, and revocation. The practical goal is to prevent unnecessary disclosure and preserve evidence for investigation, regardless of whether the entity is formally covered.

Q: Why do health-data workflows create risk outside HIPAA scope?

A: Because data follows operational workflows, not regulatory labels. Once health information moves into collaboration tools, external sharing paths, or AI systems, it can be copied, summarised, or exposed by identities that were never part of the original transaction. That makes governance, not classification alone, the deciding factor in exposure.

Q: What do security teams get wrong about business associate agreements?

A: They often treat BAAs as a substitute for technical control. A BAA matters for contractual accountability, but it does not stop excessive permissions, data sprawl, or AI-driven disclosure. Security teams need both legal review and runtime enforcement, because the breach usually happens in access paths, not in the contract itself.

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.

Technical breakdown

Why non-covered status does not remove e-PHI exposure

HIPAA covered-entity status determines regulatory obligations, not whether sensitive health data is actually present. A non-covered organisation can still collect, store, forward, or transform e-PHI in SaaS applications, cloud databases, endpoints, and AI tools. The technical risk is data movement across systems with different trust boundaries, where visibility and access control often lag behind the workflow. In practice, identity and data governance become the real control plane, because data handling continues even when HIPAA does not apply directly.

Practical implication: map where e-PHI travels across systems before relying on legal classification as a control boundary.

How MCP and AI workflows expand the health-data attack surface

MCP-connected AI workflows can pull data from one system and push it into another, which makes policy enforcement harder if controls are attached only to the original source. AI tools also create new disclosure paths through prompts, outputs, logs, and agent actions. If the organisation cannot track which identities, service accounts, or AI agents accessed the data, it cannot reliably prove containment or support investigation. That creates a governance gap between data protection policy and actual runtime behaviour.

Practical implication: apply identity-aware data controls to AI and MCP workflows, not just to the underlying applications.

What audit trails need to prove in healthcare-adjacent environments

Auditability in this context means more than logging a login event. Teams need to know which user, workload, or agent accessed e-PHI, what data was exposed, whether it was redacted or moved, and whether that access was authorised for the specific workflow. This is where data access controls, tokenisation, and revocation matter as much as classification. Without that evidence chain, organisations struggle to demonstrate due care even if they are formally outside HIPAA coverage.

Practical implication: retain evidence for access, redaction, and revocation decisions at the identity and data layer.

Threat narrative

Attacker objective: The attacker or accidental insider wants to move sensitive health data through ordinary collaboration and AI workflows in a way that bypasses effective detection and access governance.

1. Entry occurs when sensitive health data is introduced into SaaS, cloud, or AI workflows that were not designed around HIPAA-bound data controls.
2. Escalation happens when external sharing, excessive permissions, or AI agent access expands who can see or process that data beyond its original business purpose.
3. Impact is exposure of e-PHI through leakage, misrouted workflows, or inadequate auditability, which weakens both privacy protection and incident response.
4. Attacker objective is to obtain or propagate sensitive health information through trusted business workflows without triggering effective containment.

NHI Mgmt Group analysis

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.

Identity control is the missing layer in modern HIPAA-adjacent data protection. The article’s real signal is that data security now depends on user, service account, and agent permissions rather than on organisational labels alone. That intersection matters because AI assistants and MCP-connected workflows can expand who or what can access health data without a visible user session. Practitioners should align data policy with identity governance.

PHI discovery sprawl is the named concept this article exposes. Sensitive health data often appears first in messaging, tickets, documents, screenshots, and AI prompts before security teams classify it. That creates a discovery problem, not just a compliance problem, because the control failure begins before the data is even recognised as regulated. Practitioners should design for continuous discovery, not periodic classification.

BAA thinking is too narrow for cloud and AI workflows. A business associate agreement is a legal construct, but the operational risk sits in where data is stored, copied, and forwarded. If non-covered entities act as data processors in practical terms, their real exposure comes from excessive permissions, unreviewed integrations, and weak audit trails. Practitioners should pair contractual review with technical enforcement.

What this signals

PHI discovery sprawl is the operational problem this article surfaces, and it is getting harder to manage as AI tools ingest more business data. Teams that rely on static policy labels will miss the point, because the real control question is whether access can be discovered, justified, and revoked across SaaS, cloud, and AI workflows. Identity-aware data governance is now part of health-data protection, even where HIPAA does not apply directly.

The programme signal is clear: access reviews must extend beyond human users to service accounts and AI agents that can touch sensitive health data. Where NHI Lifecycle Management Guide and NIST Cybersecurity Framework 2.0 intersect with health-data handling, practitioners should focus on lifecycle, auditability, and revocation rather than one-time classification. If data movement cannot be traced end to end, compliance evidence will remain incomplete.

For practitioners

• 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. Treat the data path as the control boundary, not the HIPAA label.
• 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. Review external sharing, delegated access, and excessive permissions together because they create the same exposure outcome.
• 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. Stand-alone scanning is not enough without an enforcement step.
• Preserve audit evidence for every exposure decision Log which identity accessed the data, what was exposed, whether it was masked, and what response followed. That evidence supports investigations, HIPAA-adjacent assurance, and internal accountability even when the organisation is not a covered entity.

Key takeaways

• HIPAA non-covered status does not eliminate the security problem when e-PHI still moves through SaaS, cloud, and AI workflows.
• The main evidence gap is not policy language but auditability, because many organisations cannot track which identities or agents accessed sensitive data.
• Teams should pair discovery, redaction, access control, and revocation so health-data governance survives beyond the legal boundary of covered entities.

Key terms

• Covered Entity: A covered entity is an organisation that must follow HIPAA requirements because it creates, receives, maintains, or transmits PHI in the course of healthcare, insurance, or related processing. In practice, the term defines the primary compliance boundary for who must implement privacy, security, and breach controls.
• Protected Health Information: Protected Health Information is any health-related data that can identify a person and is covered by HIPAA protections. In practice, PHI can flow through applications, integrations, service accounts, and cloud systems, which is why identity governance matters as much as data governance.
• Business Associate: A business associate is any external organisation that handles PHI on behalf of a covered entity. The term matters because liability and security obligations extend beyond the primary healthcare provider, making third-party access governance, contract terms, and technical controls part of the same compliance chain.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

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

👉 Strac's full article covers the classification examples, BAA conditions, and DLP workflow details

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, identity lifecycle, and secrets management. It helps practitioners connect identity controls to the broader security programme they already run.