> ## Content Index > Fetch the complete content index at: https://www.techloy.com/llms.txt > Use this file to discover other available public pages before exploring further. # The BAA Isn’t a Security Blanket: What Health-Tech Teams Still Own in the Cloud - URL: https://www.techloy.com/the-baa-isnt-a-security-blanket-what-health-tech-teams-still-own-in-the-cloud/ - Published: 2026-10-06T14:41:06.000Z - Updated: 2026-10-06T14:41:06.000Z - Description: Engineering knows the vendor can handle protected health information. Everyone feels a little better about the infrastructure. - Author: Partner Content - Tags: / Featured, Cloud Security, Health Tech A health-tech team signs a Business Associate Agreement with its cloud provider. Legal checks the box. Engineering knows the vendor can handle protected health information. Everyone feels a little better about the infrastructure. Then someone leaves an old administrator account active for six months. Or a database snapshot gets copied into a development environment that has weaker access controls. Or backups run every night, but nobody has tried restoring one since the application launched. The BAA is still sitting there, properly signed. It just doesn’t solve any of those problems. **A BAA sets boundaries, not your security posture** A Business Associate Agreement matters because it defines what a vendor can do with protected health information and what obligations that vendor accepts. For healthcare companies using cloud infrastructure, signing one with the right providers is part of the job. The mistake is treating the signature as evidence that the whole environment is now compliant. The distinction is fairly clear in[ ](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html)[HHS guidance on HIPAA and cloud computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html). Covered entities and business associates still have to analyze the risks to electronic protected health information, even when the infrastructure is operated by a cloud service provider. The provider has responsibilities, but so does the company configuring and using the service. That changes how teams should evaluate a [HIPAA-compliant cloud environment](https://www.atlantic.net/hipaa-compliant-hosting/). A signed BAA is one requirement, but the working environment also depends on how encryption, authentication, logging, backups, network controls and recovery are configured around the application. A provider can give a team a suitable foundation without making every decision built on top of it automatically safe. Consider a telehealth company with separate production, staging and development environments. Production might be locked down properly while an engineer copies real patient records into staging to reproduce a difficult bug. The hosting provider didn’t create that workflow. The BAA didn’t approve it. The application team created a second location for sensitive data and now has to account for who can reach it, how long it stays there and whether the copy was necessary in the first place. That’s part of the broader problem with[ ](https://www.techloy.com/cloud-infrastructure-for-regulated-software-what-developers-should-know/)[cloud infrastructure for regulated software](https://www.techloy.com/cloud-infrastructure-for-regulated-software-what-developers-should-know/). Infrastructure decisions and application decisions overlap. Compliance problems often appear in the space between them, especially when teams assume somebody else owns a control. **The dangerous settings are usually the boring ones** Most cloud mistakes don’t look especially dramatic in a dashboard. They’re ordinary configuration choices that accumulated over time. A developer gets temporary database access during an incident. Nobody removes it. A contractor needs server access for a migration and keeps the account afterward. The support team receives broader permissions because creating separate roles would take another afternoon. Logging exists, but logs are retained for such a short period that an investigation three months later has little to work with. These decisions are understandable individually. Together, they can produce an environment where far more people can reach patient data than anyone intended. Access deserves particular scrutiny because the answer to “Who can see this?” tends to become vague as a company grows. A 12-person startup might know every administrator personally. At 80 people, it may have engineering, support, analytics, contractors and several automated services touching the same application. Accounts and permissions that made sense during the first year can quietly survive several reorganizations. Good execution is less glamorous. Production access is tied to named identities rather than shared credentials. Multi-factor authentication is enforced where it matters. People receive enough permission to perform their jobs without automatically receiving administrator rights. Departing employees lose access immediately, and elevated access has an owner and an expiration point. Cloud controls themselves also need attention. Techloy’s[ ](https://www.techloy.com/what-is-cloud-security/)[cloud security guide](https://www.techloy.com/what-is-cloud-security/) makes a useful point that’s easy to miss: the provider can lock down the infrastructure, but it can’t stop a team from giving the wrong person too much access or leaving a service exposed. Those are decisions made inside the customer’s own environment, and they’re often the ones that cause trouble later. A useful test is to pick one real patient record and trace everywhere it can go. Which database holds it? Can support staff view it? Does it appear in application logs? Is it copied to analytics systems? Does a debugging service receive part of it? Can engineers download it locally? That exercise tends to reveal more than another hour spent reading vendor compliance pages. **Backups count only when you can recover from them** Teams frequently say they have backups when what they really mean is that a backup job appears to run. Those aren’t the same thing. A backup can complete successfully every night and still fail the company when it’s needed. The credentials required to restore it might be unavailable during an outage. The backup could contain corrupted data that nobody noticed. It could sit in the same environment compromised by an attacker. [HHS ransomware guidance](https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/ransomware-fact-sheet/index.html) specifically points to backups, disaster recovery and periodic testing as parts of contingency planning. The important word for an engineering team is testing. A screenshot showing that yesterday’s backup completed is not the same evidence as restoring the data and proving the application can use it. The practical version is a scheduled recovery exercise. Take a backup, restore it into an isolated environment and record what happens. How long does the database restoration take? Are encryption keys available? Do dependencies come back in the correct order? Can the application authenticate users afterward? Does someone actually know who decides to fail over? This gets uncomfortable in a useful way. A company might discover that its database can be restored in 40 minutes but its object storage needs another six hours. Another might learn that its written recovery procedure mentions an employee who left eight months ago. The point isn’t to produce a perfect disaster-recovery binder. It’s to know whether the service can actually come back before a real incident forces the experiment. **Your vendor can’t operate your company for you** A strong cloud provider can take a substantial amount of infrastructure work off a health-tech team. It can operate physical facilities, maintain underlying systems, offer security controls, support encryption, retain logs, provide backups and accept contractual obligations around protected information. It can’t decide whether your support staff should be able to export 20,000 patient records. It can’t know that a developer pasted production data into a project-management ticket. It won’t necessarily know that an abandoned integration still has an API key with broad permissions. It can’t make the product team remove sensitive fields from an analytics event that never needed them. The[ ](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html)[HHS provisions for business associate contracts](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html) require business associates to accept specific safeguards and restrictions, including obligations around subcontractors and security incidents. Those agreements matter, especially when health data moves through several vendors. They don’t replace the company’s own decisions about data collection, retention and access. The same issue appears after incidents. Techloy’s reporting on a[ ](https://www.techloy.com/a-major-us-health-records-system-was-breached-patients-still-dont-know-what-was-exposed/)[breach involving a US health-records system](https://www.techloy.com/a-major-us-health-records-system-was-breached-patients-still-dont-know-what-was-exposed/) shows why determining what was accessed can become difficult once an intrusion has happened. Teams need useful logs, clear ownership and an accurate picture of where sensitive information lives before an incident begins. One question exposes a lot of weakness: if suspicious access happened at 2:00 a.m. last Tuesday, could your team determine which account was involved, what it accessed and whether patient information left the system? If the answer is “probably,” there’s work to do. **Wrap-up takeaway** Most teams won’t get tripped up by the BAA itself. The problems usually show up months later, after permissions have piled up, a test environment has become permanent, or nobody remembers the last time a backup was actually restored. Those are small operational decisions, but they’re the ones that determine whether the setup holds up when something goes wrong. A good place to start is with one simple question: if you had to explain exactly where patient data travels today, could you do it without guessing? If not, trace one real workflow and see where the answers get fuzzy.