Can We Store Patient Records in Google Drive or Dropbox?
Yes, but only under conditions that many clinics accidentally skip.
HIPAA does not ban cloud storage. What HIPAA does require is that if a cloud service provider is creating, receiving, maintaining, or transmitting electronic protected health information (ePHI) on your behalf, that provider is a business associate and you must have a HIPAA-compliant business associate agreement (BAA) in place, and you must still comply with the HIPAA Rules. This is true even if the cloud provider only stores encrypted data and does not have the encryption key. [1][2]
So the real answer is:
You can store patient records in Google Drive or Dropbox if you are using an eligible business product that will sign a BAA for the relevant services, and you configure and operate it in a way that meets the Security Rule and Privacy Rule requirements that apply to your environment. [1][3][4]
Informational note: This article is for informational purposes only and does not constitute legal advice.
Why this is a HIPAA question at all
Cloud storage is not just “a folder on the internet.” Under HIPAA, it is typically a vendor relationship that involves maintaining ePHI. That triggers two simultaneous obligations:
First, you need the contractual layer. HIPAA generally requires written satisfactory assurances from business associates, implemented through a BAA with required terms. [2][5][6]
Second, you need the operational layer. HIPAA expects you to conduct a risk analysis and implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. When you introduce cloud storage into the environment, your risk analysis and risk management plan must account for how ePHI is stored, accessed, shared, and recovered, including vendor responsibilities and your own configuration. [1][7]
A BAA is necessary, but it is not a force field. A BAA does not prevent mis-sharing, overbroad access, or staff exporting files to personal devices. It mainly establishes permitted uses, required safeguards, reporting duties, and subcontractor flow-down obligations. Your configuration and operations determine whether the system is defensible in practice. [5][6]
The simplest compliance line: no BAA, no PHI
HHS is unusually direct on this point. If you use a cloud service provider to maintain ePHI without first entering into a BAA with that provider, the covered entity (or business associate) is in violation of the HIPAA Rules. [1]
That is why personal, consumer-style accounts are so risky. The main issue is not whether the technology is “secure enough.” The main issue is that consumer services often do not provide a BAA pathway, centralized administrative controls, or audit capabilities appropriate for regulated use. If you cannot execute a BAA for the specific service and account context, the compliance path is to not store PHI there.
What “using Google Drive” means under HIPAA
The phrase “Google Drive” is ambiguous. HIPAA viability depends on whether Drive is being used as part of Google Workspace under Google’s HIPAA terms, and whether the services you are using are within Google’s listed HIPAA included functionality.
Google’s own admin guidance states that customers who have not signed a BAA with Google must not use PHI in Google Workspace or Cloud Identity services, and administrators must review and accept a BAA before using PHI in Google services. [3]
Google also publishes a “HIPAA Included Functionality” list. As of September 30, 2025, that list explicitly includes Google Drive and related apps such as Docs, Forms, Sheets, and Slides as included functionality under the applicable HIPAA Business Associate Addendum, along with other Workspace services. [8] Google’s BAA terms apply only to the extent PHI is created, received, maintained, or transmitted via a “Covered Service,” which is why it matters whether the specific service is on the included functionality list. [9]
Operationally, this gives clinics a defensible structure:
If you are using Google Workspace, you execute the BAA, confirm that the specific services you are using for PHI are within the included functionality list, and then you configure access control, sharing, auditing, retention, and endpoint rules so that Drive behaves like a controlled records repository rather than a casual file-sharing tool. [3][8][9]
What “using Dropbox” means under HIPAA
Dropbox addresses HIPAA in a way that is refreshingly blunt: there is no official HIPAA or HITECH certification, and responsibility for compliance ultimately remains with the customer. Dropbox also states that for customers subject to HIPAA and HITECH, a BAA must be in place before you transfer PHI into your Dropbox account, and that admins of a Dropbox team account can sign a BAA electronically from the admin console. [4]
Dropbox also warns about an area clinics frequently miss: third-party apps and integrations connected to your Dropbox account are not automatically part of Dropbox’s included services and may not be covered under the Dropbox BAA. You are responsible for evaluating those add-ons for your regulatory requirements. [4]
In practice, Dropbox can be used for PHI when you are on an appropriate team plan with a signed BAA and you configure security controls to prevent common exposure patterns. But it is not “HIPAA by default,” and the integration ecosystem can quietly expand your PHI footprint if you do not govern it. [4][1]
The compliance risk is rarely “cloud storage,” it is how clinics use it
Most HIPAA problems with Drive or Dropbox are not about Google or Dropbox failing cryptography. They are about clinics using cloud storage like consumer file sharing.
The failure modes are predictable:
One is oversharing. Public links, external sharing, guest access, and “anyone with the link” settings are convenient, but convenience is not a HIPAA control. When the wrong link is forwarded, or a folder is shared too broadly, you can create an impermissible disclosure that triggers incident analysis, and in some cases breach analysis.
Another is uncontrolled endpoints. Even if cloud storage is configured well, staff can sync files to personal laptops, personal phones, or unmanaged home computers. That is how ePHI ends up outside the administrative and audit boundary of the clinic.
A third is lack of auditability. HIPAA’s Security Rule expects audit controls, meaning you implement mechanisms that record and examine system activity in information systems that contain or use ePHI. If you cannot determine who accessed what, when, and from where, your ability to investigate incidents and demonstrate accountability is weak. [10]
A fourth is role confusion. Clinics often give front desk staff the same storage access as clinicians because it is simpler. HIPAA’s approach is the opposite: implement policies and procedures for authorizing access to ePHI and ensuring workforce members have appropriate access, aligned to their roles. This is where minimum necessary meets access management in real operations. [7][10]
Finally, organizations underestimate that “backups” and “archives” are part of the ePHI footprint. If you store records in Drive or Dropbox, you need to understand where versions, deleted files, retention holds, and backups exist, and how you would respond to ransomware or account compromise. HHS cloud guidance explicitly ties cloud adoption to your risk analysis and risk management obligations. [1][2]
What a defensible configuration posture looks like
HIPAA does not prescribe a single configuration template. It expects you to implement safeguards based on risk analysis, and it expects you to be able to justify your choices.
That said, there are baseline control themes that show up repeatedly across Security Rule requirements:
Access control and authentication should be role-based and strongly authenticated. This includes unique user identification and controlling who can access what, with rapid deprovisioning when staff leave. [7][10]
Auditability should be enabled and reviewed. Audit controls are a direct Security Rule requirement, and cloud storage is one of the easiest places to satisfy it if you actually turn logging on and treat it as an operational input rather than a checkbox. [10]
Transmission and storage protections should be aligned to risk. The Security Rule requires transmission security protections for ePHI transmitted over networks, and encryption is an addressable specification, meaning you implement it or document an equivalent alternative. If you are using cloud storage, you should be able to explain how ePHI is protected in transit and at rest within your chosen configuration. [10]
Sharing should be governed. If external sharing is allowed at all, it should be intentional, limited, and reviewable. Many clinics adopt a default-deny posture for external sharing and then create controlled exceptions.
Third-party integrations should be treated as additional vendors. Dropbox explicitly warns that third-party apps are not necessarily covered by the Dropbox BAA. The same principle applies broadly: if an add-on touches PHI, you need to evaluate it as its own relationship, not as “part of Drive” or “part of Dropbox.” [4][1]
This is also a place where NIST guidance can be useful. NIST SP 800-66 Rev. 2 is designed to help regulated entities implement the Security Rule and translate requirements like risk analysis, access control, audit controls, and transmission security into a practical security program. [11]
A practical decision rule for small clinics
If the clinic needs cloud storage for patient records, the cleanest approach is to treat it like a regulated system, not a convenience tool.
Start with the BAA. If you cannot get a BAA for the specific service and account environment, stop there. [1][3][4]
Next, confirm service scope. For Google, confirm the PHI-relevant services you use are in Google’s HIPAA included functionality list, not just “Google-branded.” [8][9]
Then configure and document. Risk analysis is not optional, and a cloud storage decision should be reflected in it. You are not only choosing a vendor, you are defining part of your ePHI boundary. [1][7]
Finally, govern daily behavior. Even a well-configured Drive or Dropbox can be undermined by staff workflows that export files, share links casually, or sync PHI onto unmanaged devices. Your policies, training, and operational checks are what make “cloud storage” defensible. [7][10]
If you want to keep this operationally manageable, tools like Timber can help you track BAAs, vendor inventories, configuration tasks, access-review routines, and evidence that controls are maintained, even if the actual clinical records live in your EHR and your file repository lives in Drive or Dropbox.
Sources
[1] HHS OCR, Guidance on HIPAA and Cloud Computing
https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
[2] HHS OCR FAQ 2075, May a covered entity or business associate use a cloud service to store or process ePHI?
https://www.hhs.gov/hipaa/for-professionals/faq/2075/may-a-hipaa-covered-entity-or-business-associate-use-cloud-service-to-store-or-process-ephi/index.html
[3] Google Workspace Admin Help, HIPAA Compliance with Google Workspace and Cloud Identity (BAA required before using PHI)
https://support.google.com/a/answer/3407054
[4] Dropbox Help, Dropbox and HIPAA/HITECH (BAA required before transferring PHI; third-party apps not covered by BAA)
https://help.dropbox.com/security/hipaa-hitech-overview
[5] 45 CFR § 164.502(e), Business associate standard
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502
[6] 45 CFR § 164.504(e), Business associate contract requirements
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504
[7] 45 CFR § 164.308(a)(1)(ii)(A)-(B), Risk analysis and risk management
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
[8] Google Workspace, HIPAA Included Functionality list (includes Google Drive and related apps under the BAA as of Sep 30, 2025)
https://workspace.google.com/terms/2015/1/hipaa_functionality/
[9] Google Workspace, HIPAA Business Associate Addendum terms (applies to “Covered Services”)
https://workspace.google.com/terms/2015/1/hipaa_baa/
[10] 45 CFR § 164.312, Technical safeguards including access control, audit controls, and transmission security
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
[11] NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf