# Cloud Storage and HIPAA Compliance: What Connected Device Makers Get Wrong Source: https://scadable.com/blog/cloud-storage-hipaa-compliance Published: 2026-07-12 --- **The most common HIPAA gap in a connected device company is not malicious. It is architectural: a cloud telemetry pipeline gets built first for uptime and observability, long before anyone decides the product will touch patient data, and nobody goes back to re-audit it once it does. Protected health information ends up in access logs, analytics tools, support dashboards, and backups without a single deliberate decision that it should be there.** That is worth sitting with, because most HIPAA advice assumes the gap is a missing policy or a vendor nobody vetted. The more common version is quieter than that. A team builds a cloud pipeline to keep devices online and debuggable, ships it, adds features, and only later signs a deal with a hospital or clinic that requires a Business Associate Agreement. By the time that happens, the pipeline already has months or years of design decisions baked in, none of which were made with PHI in mind, and nobody has gone back through them one by one. ## Where does PHI end up without anyone deciding it should? Four places, consistently. Access logs are the first: a system that logs which user viewed which record, for debugging and audit purposes, often logs the patient identifier right alongside the operational metadata, because at the time nobody was thinking of that identifier as PHI, just as a request parameter. Third-party analytics and crash reporting tools are the second: when an error is captured or an event is tracked, the full request payload frequently goes with it, and if a PHI field happens to be part of that payload, a vendor that was never evaluated for HIPAA is now holding patient data. Support and debugging tooling is the third, and often the hardest to see because it looks like normal engineering practice: giving engineers direct visibility into production data so they can troubleshoot a customer issue is a completely ordinary thing to build, and it is also direct, often unaudited access to PHI by people whose job has nothing to do with handling it. The fourth is backup and archival systems, which inherit whatever was in the primary store at the time of the snapshot. A primary database can have strong encryption and tight access control while its backup, built earlier and left alone, has neither, because nobody thought to ask whether the backup needed its own review once the primary system started handling patient data. None of these are decisions anyone made about PHI specifically. They are decisions made about uptime, debuggability, and operational visibility, and PHI arrived as a side effect once the product's use case changed. Our [HIPAA framework page](/frameworks/hipaa) covers the same pattern under "the part device makers actually get wrong," and it is the piece most teams miss when they think about HIPAA scope only in terms of the primary database. ## Why does this happen even at careful companies? Because the pipeline was correct when it was built. A telemetry system designed for uptime and observability is judged against uptime and observability requirements, and it can satisfy those requirements completely while having no encryption-at-rest policy, no access scoping, and no audit logging, because none of that was relevant to the job it was built for. The system does not become wrong the day the product starts handling patient data. It becomes out of scope for a regulation nobody re-checked it against, which is a different failure than negligence, but produces the same gap. The trigger event, usually a hospital or clinic asking for a signed BAA, arrives at the business layer: sales, product, or a founder. It does not automatically arrive at the infrastructure layer, where the actual pipeline design lives. Someone has to make the connection between "we just signed our first covered-entity customer" and "every system that will now see this customer's data needs a security review," and that connection is easy to miss because it requires knowing both the business context and the technical architecture at the same time. For the fuller picture of when HIPAA applies to a device company in the first place, not just the cloud storage piece, [what actually triggers HIPAA obligations for a medical device company](/blog/hipaa-requirements-medical-device-companies) is the earlier question worth answering. ## What actually needs to change once a pipeline touches PHI? Every system that touches the data needs the same three things the HIPAA Security Rule requires of any system holding protected health information: encryption in transit and at rest, access controls scoped to who actually needs the data for their job, and audit logging of who accessed what and when. That is straightforward to state and genuinely tedious to apply, because it has to be applied to each system individually rather than once at the primary database. Access logs that capture patient identifiers need the same encryption and access restriction as the records they describe, and the retention policy has to account for the fact that the log itself is now PHI, not just a reference to it. Third-party analytics and crash reporting either need PHI fields stripped from the payload before it leaves the product, or the vendor needs to be brought under a Business Associate Agreement and evaluated the same way any subprocessor touching PHI would be. Support and debugging tooling needs access scoped down to what a given engineer actually needs for the specific issue they are working, with that access logged, rather than standing production visibility for anyone on the team. Backup and archival systems need their own encryption and access review, not an assumption that whatever the primary database does automatically covers them. ## What is the practical fix, if you cannot rebuild everything? Treat every system PHI touches as in scope from the start, not just the primary data store, and re-audit the systems that already exist the moment the product starts handling patient data, rather than assuming the original architecture is still fine because it worked before. That re-audit does not mean ripping out the cloud tools that got the product this far. It means walking the actual path PHI takes through the stack, logs, analytics, support tooling, backups, and everywhere else, and checking each stop against the same three requirements: is it encrypted, is access scoped to who needs it, and is access logged. Most of these fixes are narrower than they sound, stripping a field from an analytics payload, adding an access scope to a support tool, turning on encryption for a backup bucket, but they only happen if someone actually goes looking, because none of these systems will flag themselves. ## Frequently asked questions **Does HIPAA apply to cloud storage, not just a hospital database?** Yes. HIPAA does not care whether protected health information sits in a hospital system or a device makers cloud platform. Any system that stores, processes, or transmits PHI is in scope for the Security Rule, including the access logs, analytics tools, and backups that sit around the primary database, not just the database itself. **What is the most common HIPAA gap in a connected device cloud pipeline?** A telemetry pipeline built early for uptime and observability, before the product handled patient data, that never gets re-audited once it does. Access logs, third-party analytics, support tooling, and backups quietly end up holding PHI without anyone making a deliberate decision that they should. **Does third-party analytics or crash reporting count as a HIPAA risk?** It can. If a request payload sent to an analytics or crash reporting tool includes PHI fields, that vendor is now handling protected health information, whether or not the integration was set up with that in mind. A Business Associate Agreement and the same Security Rule safeguards apply to that vendor as to the primary data store. **Do backups need the same HIPAA safeguards as the primary database?** Yes. A backup or archival system inherits whatever data was in the primary store at the time of the snapshot, including any PHI. If the backup system does not have its own encryption, access controls, and audit logging, it is a gap even if the primary database is fully compliant. **What does the HIPAA Security Rule actually require for a cloud pipeline?** Encryption in transit and at rest, access controls scoped to who actually needs the data, and audit logging of who accessed what, applied to every system that touches protected health information, not only the system of record. **How should a device maker fix a cloud pipeline that already touches PHI?** Map every place PHI actually flows, including logs, analytics, support tooling, and backups, then apply the Security Rule safeguards to each one. The fix is not to stop using cloud tools, it is to treat every system PHI touches as in scope and re-audit the existing pipeline the moment the product starts handling patient data. Last reviewed: July 12, 2026. ## Where Scadable fits This is exactly the gap Scadable closes. Scadable maps where PHI actually flows through a product's full stack, not just the obvious primary data store, so the access logs, analytics integrations, support tooling, and backups that quietly ended up in scope get found instead of assumed away. From there, Scadable implements the Security Rule safeguards, encryption, scoped access, audit logging, across every system that touches the data, and helps get Business Associate Agreements in place with the vendors that need them. [Book a call](https://cal.com/rahbaral/quick-chat) to see what that mapping looks like for your pipeline.