The HIPAA Privacy Rule has been in force since 2003. The Security Rule since 2005. And yet, two decades later, healthcare organizations and their cloud-native engineering teams keep discovering Protected Health Information in places where it was never supposed to land. Not because engineers are careless, but because the infrastructure they work inside is genuinely complex and the definition of PHI is broader than most people intuitively expect.
We are not talking about catastrophic breaches with stolen credentials. We are talking about something quieter: PHI that flows downstream through normal, expected engineering operations, ends up in a staging table or a logging pipeline, and then sits there uncategorized for months because nobody thought to look.
What counts as PHI in a cloud context
The HIPAA Privacy Rule defines PHI as individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. That definition turns out to be surprisingly broad when applied to modern cloud infrastructure.
Date of birth combined with a zip code and a diagnosis code is PHI. Account IDs linked to insurance claims are PHI. Even IP addresses, when they can be tied back to a patient accessing a health portal, can become PHI depending on context. The key phrase in 45 CFR 164.514(b) is that any identifier that could be used to identify an individual, paired with health information, qualifies.
When we scan cloud environments for healthcare customers, the identifier combinations that appear most unexpectedly are not full medical records. They are partial demographic fields attached to behavioral or transactional data. A patient's date of birth and member ID sitting in a Redshift staging table alongside appointment scheduling records. A first name, last name, and prescription refill timestamp stored in a Kinesis Firehose delivery bucket that was created to capture product usage analytics.
The pipeline problem: data flows further than intended
Healthcare engineering teams build data pipelines the same way any engineering team does. An event fires, a payload is serialized, the payload moves through a queue or stream, and eventually it lands in a data store. The PHI problem is that the payload design rarely starts with "what identifiers does this carry?" as a first question. It starts with "what does the downstream consumer need?"
Consider a common pattern: a patient scheduling system emits events when an appointment is created or modified. The engineering team building an analytics dashboard for operational capacity planning subscribes to that event stream. They need appointment timestamps and provider IDs. But the event payload also contains the patient's member ID and date of birth because the source system included them as standard fields. The analytics pipeline ingests everything, stores it in a BigQuery dataset partitioned by date, and from that point forward there is PHI in an analytics store that was never designed, documented, or evaluated as a PHI environment.
This is not a hypothetical edge case. It is the default behavior of event-driven architectures when payload schemas are not explicitly stripped or filtered before crossing a compliance boundary.
SaaS integrations and the log problem
Modern healthcare operations rely heavily on SaaS tools. Support ticketing systems, CRM platforms, scheduling applications, patient communication tools. When these systems integrate with each other via webhooks or APIs, the integration logs frequently capture more than intended.
Webhook payloads sent between systems often carry patient-identifiable fields because the sending system does not know which fields the receiving system will use. An integration between an EHR and a patient messaging platform might log the full request payload to help with debugging, including the patient's name, date of birth, and appointment reason. That log lands in a centralized logging service, where it sits indexed and queryable by anyone with log read access.
The HIPAA Security Rule (45 CFR Part 164 Subpart C) requires that ePHI be protected wherever it is stored, transmitted, or processed. It does not carve out exceptions for debug logs or integration middleware. Business Associate Agreements need to cover every system that touches PHI in any form, including the logging infrastructure. That is a coverage gap that is genuinely difficult to track manually.
Development and staging environment exposure
A persistent source of PHI exposure is the practice of using production data subsets in development and staging environments. It is common, it is often genuinely necessary for realistic testing, and it is consistently underdocumented in security inventories.
The HIPAA Security Rule does not prohibit using PHI in test environments. But it requires the same administrative, technical, and physical safeguards to apply regardless of environment designation. In practice, staging environments frequently have weaker access controls, longer data retention than production, and broader access grants to engineering and QA teams who do not need PHI access to do their jobs.
We are not saying that using production-like data in testing is inherently wrong. The problem is that it tends to be undeclared and therefore ungoverned. When a DSPM scan finds PHI in a staging dataset, the first question is whether anyone formally acknowledged that environment as a PHI environment subject to HIPAA safeguards. The answer is almost always no.
Data warehouse staging and the retention gap
One of the most consistent patterns we see is PHI accumulating in data warehouse staging areas. The pattern: a pipeline ingests raw data from source systems into a staging schema, transforms it into clean fact and dimension tables, and the staging area is supposed to be truncated after each successful load. But truncation logic has bugs. Pipelines get interrupted. Teams add new source feeds and forget to update the cleanup jobs.
In one environment we analyzed, a healthcare analytics team had a Snowflake internal staging schema that was supposed to hold raw data for less than 24 hours. Because of a missed cleanup job added six months prior, that staging schema had accumulated 14 months of raw patient records, including diagnosis codes, member IDs, and dates of birth. The production tables were clean and properly governed. The staging layer was not in anyone's security documentation because it was supposed to be transient.
Transient data stores that become permanent are a structural problem in data warehousing. The fix is not adding more cleanup jobs. The fix is continuous discovery that treats staging schemas as part of the PHI inventory, not as infrastructure plumbing that is exempt from classification requirements.
The BAA coverage gap that shows up in cloud inventories
HIPAA requires covered entities to execute Business Associate Agreements with every vendor that creates, receives, maintains, or transmits PHI on their behalf. In cloud environments, that list is longer than most compliance teams realize.
The obvious BAs are the EHR vendor, the cloud infrastructure provider (AWS, Azure, and GCP all offer HIPAA BAA programs), and major SaaS partners. The less obvious ones are the analytics tools, the monitoring platforms, the data pipeline orchestrators, and the log management services that touch PHI as a byproduct of their function rather than as their primary purpose. When PHI lands in a logging pipeline or a monitoring system, that vendor becomes a business associate whether or not they were expected to play that role.
Knowing which systems actually hold PHI, as opposed to which systems were designed to hold PHI, is the precondition for knowing whether your BAA coverage is complete. That is a data discovery question, not a vendor management question.
What a practical PHI inventory looks like
The goal is not a perfect, comprehensive PHI map produced once a year during a compliance review. That kind of inventory is outdated before the ink dries. The goal is continuous visibility into where PHI is landing as a byproduct of normal engineering operations.
The signals to scan for, in rough priority order: structured data stores (databases, data warehouses, object storage buckets) for fields matching HIPAA identifier patterns; logging and monitoring infrastructure for PHI appearing in event payloads; data pipelines and staging areas for PHI that should have been filtered or truncated; and SaaS integration points for PHI appearing in webhook payloads and API response logs.
Classification at this level requires more than regex matching against field names. A field called member_id in one context carries PHI. The same field name in a different schema might be a product membership ID with no health information attached. Context matters, and that is where automated classification that understands data lineage and schema context produces meaningfully different results from naive pattern matching.
For healthcare organizations specifically, the compliance question and the security question are the same question: where is PHI, who can reach it, and is it governed appropriately? The cloud has not made that question easier to answer. It has just distributed it across more surfaces than any manual inventory was designed to handle.