Home Health Cloud Security Policy: Template & Best Practices

Most home health agencies run almost entirely on cloud services now — the EHR, email, scheduling, even payroll — and almost none of them have a written policy governing how those services get used, who can access them, or what has to happen before a new one gets adopted. That gap doesn't stay theoretical for long. An office manager signs up for a free file-sharing tool to send a care plan to a family member, nobody checks whether that tool will sign a BAA, and the agency now has PHI sitting with a vendor it has no contract with and no visibility into.

A cloud security policy closes that gap by writing down, in advance, which services are approved and why, so the decision isn't being made ad hoc by whoever hit a wall at 4pm on a Friday. Below is coverage of what the policy needs to address, plus actual template language you can adapt directly — replace the bracketed placeholders with your agency's specifics and this becomes a usable first draft, not just a description of what a policy should contain.

Which Cloud Services Actually Need a Policy

Three categories cover almost everything a home health agency touches: productivity suites (Microsoft 365 or Google Workspace, handling email, document storage, and calendaring), the EHR platform itself (Homecare Homebase, WellSky, MatrixCare, Axxess, Brightree, or similar, almost always cloud-hosted today), and a long tail of smaller tools — scheduling apps, e-fax services, billing platforms, file-sharing tools — that individually look low-risk but collectively handle a surprising amount of PHI once you add them up.

Both Microsoft 365 and Google Workspace offer a Business Associate Agreement for their eligible business and enterprise plans, but the BAA isn't automatic — it has to be requested and signed before the service is used for anything involving PHI, and only the specific services named in that BAA are actually covered. Using a Microsoft or Google product that falls outside the BAA's listed scope for PHI is the same compliance problem as using an unapproved vendor with no BAA at all, even though the login screen looks identical.

HIPAA's Cloud BAA Requirements

HIPAA treats a cloud provider that stores, processes, or transmits PHI on an agency's behalf as a business associate, full stop, regardless of how the provider markets itself or whether anyone thinks of "the cloud" as a vendor relationship at all. The Security Rule (45 CFR § 164.308(b)) and the Business Associate Contracts provisions (45 CFR § 164.314(a)) require a written BAA in place before that relationship begins, obligating the vendor to protect the PHI with safeguards that meet the Security Rule and to report any breach back to the agency.

The practical risk isn't usually the big, obvious vendors — the EHR company has signed hundreds of BAAs and has a standard process for it. The risk is the smaller, incidental tool an employee adopts without anyone in the loop: a personal Dropbox account to send a large file, a free e-signature tool for a form, a scheduling app a field supervisor found and liked. None of these are inherently unsafe, but none of them have a BAA either, unless someone checks first — which is exactly what a written policy forces to happen.

Key Elements a Cloud Security Policy Needs

A policy that actually gets followed covers a short, specific list rather than a long list of generic principles: which services are approved, what has to happen before a new service gets added to that list, who is allowed to access each approved service and at what level, what encryption and authentication the service has to support, what's explicitly prohibited, and what happens when someone violates the policy or leaves the organization.

Template: Cloud Security Policy

The sections below are written as adaptable template text. Replace the bracketed placeholders with your agency's actual details, and remove or adjust any section that doesn't apply to your operation.

1. Purpose and Scope

This policy governs [Agency Name]'s use of cloud-based software and services that store, process, or transmit protected health information (PHI) or other sensitive agency data. It applies to all employees, contractors, and volunteers who access [Agency Name]'s systems, regardless of device or location.

2. Approved Cloud Services

Only cloud services listed in [Agency Name]'s Approved Vendor List may be used to store, process, or transmit PHI. The current Approved Vendor List is maintained by [title/role, e.g., Compliance Officer] and includes, at minimum: [EHR platform name], [email/productivity suite], and [backup provider]. A current Business Associate Agreement (BAA) must be on file for every vendor on this list before PHI may be stored or transmitted through that service.

3. Adding a New Cloud Service

No employee may begin using a new cloud service to handle agency data, PHI or otherwise, without prior written approval from [title/role]. Requests must identify what data the service will handle, whether PHI is involved, and whether the vendor will sign a BAA. A service that will not sign a BAA may not be used for any PHI under any circumstances, regardless of the business justification.

4. Access Control and Authentication

Access to any approved cloud service containing PHI requires a unique login credential per user — shared or generic logins are not permitted. Multi-factor authentication (MFA) is required for all cloud services containing PHI, with no exceptions for convenience or role. Access is granted based on job function (minimum necessary) and must be revoked within [24 hours / one business day] of an employee's termination or role change.

5. Data Handling and Encryption

PHI stored in or transmitted through an approved cloud service must be encrypted both at rest and in transit, consistent with the service's native security configuration and [Agency Name]'s configuration standards. PHI may not be downloaded to a personal device or a non-approved storage location, including personal email accounts, personal cloud storage, or removable media, except as explicitly authorized under [Agency Name]'s mobile device policy.

6. Prohibited Services (Shadow IT)

Employees may not use any cloud service not on the Approved Vendor List to send, store, or process PHI, including free file-sharing tools, personal messaging apps, personal email accounts, or consumer-grade note-taking and productivity apps. Discovery of PHI stored or transmitted through an unapproved service must be reported immediately to [title/role] under the agency's incident response procedure, regardless of how the data got there.

7. Incident Reporting

Any suspected or confirmed security incident involving a cloud service — unauthorized access, a vendor-reported breach, a misdirected file, a lost credential — must be reported to [title/role] immediately upon discovery, and no later than [timeframe]. Approved vendor BAAs must include a provision requiring the vendor to notify [Agency Name] of any breach involving [Agency Name]'s data without unreasonable delay.

8. Policy Review

This policy will be reviewed at least annually, and whenever a new category of cloud service is adopted agency-wide, by [title/role]. All employees must acknowledge this policy in writing upon hire and upon any material update.

Common Mistakes Agencies Make With This Policy

The most common failure isn't having no policy at all — it's having a policy that was written once, filed away, and never actually enforced. A handful of patterns show up repeatedly in agencies that run into trouble:

• The Approved Vendor List exists but nobody checks it. A policy document naming three approved services doesn't stop a fourth, unapproved one from quietly becoming the way a department actually works, especially if it's more convenient than the approved option.
• BAAs are signed but never tracked. A BAA signed three years ago with a vendor that has since changed its product, been acquired, or quietly dropped HIPAA support isn't protecting anything — someone needs to own tracking which BAAs exist, with which vendor, covering which specific services, and when each one needs review.
• MFA is "required" but optional in practice. A policy that requires MFA on paper while allowing exceptions for convenience, or that was never actually configured to enforce it at the account level, provides none of the protection the written policy claims to provide.
• New hires never see the policy. A policy only works if people actually know it exists and know specifically what's approved. Folding it into onboarding, rather than leaving it in a shared drive nobody opens, is what makes the difference between a document and an actual control.

Where This Fits Into a Larger Compliance Program

A cloud security policy is a piece of the administrative safeguards HIPAA's Security Rule requires, alongside a device policy, an incident response plan, and a documented risk analysis — it isn't a substitute for any of those, and a policy that exists only on paper without actual enforcement (unused BAAs, MFA that's optional in practice, an Approved Vendor List nobody checks) provides little real protection and even less of a defensible compliance posture if an incident occurs. ShieldForce manages the technical side of this policy automatically as part of the home health cybersecurity platform we run for agencies — enforcing MFA, flagging unapproved services in use, and maintaining the vendor and BAA inventory this policy depends on. For the full threat landscape and HIPAA Security Rule mapping beyond cloud services specifically, see our home health cybersecurity guide.

Frequently Asked Questions

Do Microsoft 365 and Google Workspace sign HIPAA BAAs?

Yes, both offer a Business Associate Agreement for eligible business and enterprise plans, but it has to be requested and signed before the service is used for PHI, and only the specific services listed in that BAA are actually covered. Using a feature outside the BAA's scope for PHI is the same compliance gap as using a vendor with no BAA at all.

Does every cloud tool an agency uses need a BAA?

Any cloud service that stores, processes, or transmits PHI needs a signed BAA under HIPAA, regardless of how small or incidental the tool seems. A free file-sharing or e-signature tool an employee picks up independently is just as much a business associate as the EHR vendor if PHI passes through it, and it almost never has a BAA unless someone specifically checks.

What is "shadow IT" and why does it matter for HIPAA compliance?

Shadow IT refers to cloud services employees adopt on their own without going through an approval process — a personal Dropbox account, a messaging app, a note-taking tool. These services typically have no BAA and no oversight from the agency, which means any PHI that ends up in them sits outside the agency's compliance program entirely, often without anyone realizing it happened.

Who should be responsible for approving new cloud services?

A single named role — typically a compliance officer, office manager, or whoever holds that responsibility — should have sole authority to approve new cloud services for PHI use, with a documented checklist covering BAA availability, encryption, and MFA support. Without a single point of approval, services tend to get adopted informally by whichever employee hit a need first.

How often should a cloud security policy be reviewed?

At least annually, and additionally whenever the agency adopts a new category of cloud service or changes EHR or productivity platforms. A policy that references a vendor the agency stopped using two years ago, or omits one it adopted last year, isn't providing real protection even though it technically exists.