HIPAA Compliant Cloud Backup: What To Look For

A backup can upload successfully and still let you down when you need to restore it. For healthcare teams, choosing HIPAA-compliant cloud backup means checking how patient data is protected, which recovery copies survive a mistake or attack, and whether you can get usable records back in time.

In this guide, we’ll explain HIPAA backup requirements, the difference between cloud storage and cloud backup, and what to check when comparing providers. Whether you’re evaluating HIPAA-compliant online backup services or building an offsite backup workflow, you’ll learn how to assess agreements, security controls, and recovery capabilities against the data and systems you need to restore.

What is HIPAA-compliant cloud backup?

HIPAA-compliant cloud backup is a cloud-based process for creating and maintaining recoverable copies of electronic protected health information (ePHI), with safeguards and agreements that support the organization's HIPAA obligations. Compliance depends on the provider, the configuration, and how your team manages the backups.

The HIPAA Security Rule's contingency-plan requirements include maintaining retrievable exact copies of ePHI, restoring lost data, and protecting ePHI during emergency operations. A backup service supports that work, but doesn't replace your contingency plan.

Why HIPAA-compliant cloud backup is essential in healthcare

A secure cloud backup service may offer encryption and reliable storage, but healthcare teams also need an appropriate BAA, documented responsibilities, and a recovery process that supports their HIPAA obligations. Choosing a service around those needs offers four practical benefits:

• Regulatory compliance. The right agreements and safeguards support your backup, disaster recovery, and emergency-operation plans. A security claim alone doesn't establish that the service is suitable for ePHI.
• Resilience against healthcare risks. Protected recovery copies can help your team recover patient records after ransomware, accidental deletion, or hardware failure, provided clean copies survive the incident.
• Continuity of care. Tested backups give your team a recovery route when essential records become unavailable. Knowing what you can restore and how long it takes helps you plan for disruption to patient care.
• Simpler audits and reporting. Accessible logs, documented backup procedures, and restore-test records make it easier to explain how ePHI is protected and investigate problems. They support compliance reviews without guaranteeing a successful audit.

What to look for in HIPAA-compliant backup services

1. A BAA covering the service you'll actually use

Before uploading ePHI, confirm that the provider will sign a Business Associate Agreement (BAA) for the service and plan you'll use. Our healthcare MFT selection guide explains how to evaluate the agreement alongside the service's controls. Check responsibilities for incident reporting, subcontractors, data access, and returning or destroying data when the agreement ends.

HHS cloud-computing guidance explains that a provider maintaining ePHI can be a business associate even when the data is encrypted and it doesn't hold the decryption key. Encryption doesn't remove the need for the appropriate BAA.

2. Encryption with a workable recovery-key process

Check encryption in transit and at rest, including SFTP encryption when you use SFTP to upload backup files. Ask who controls the keys and how you'll recover data if a key is lost or an administrator is unavailable.

Under the current technical-safeguard requirements, encryption is an addressable implementation specification. That isn't permission to ignore it: assess whether it's reasonable and appropriate, implement it when it is, and document the required reasoning and alternatives when it isn't. HIPAA doesn't prescribe AES-256 or a particular transfer protocol.

For procurement, encrypted storage and transport are sensible starting requirements. File-level PGP encryption can add protection when backup files move between systems, provided you retain the private keys needed for recovery.

3. Recovery copies protected from deletion and overwriting

Ask what happens if someone deletes a folder, overwrites a file, or uploads ransomware-encrypted data. Can you recover an earlier clean copy, and for how long?

Look for version history, configurable retention, and an isolated or immutable recovery copy where your risk assessment calls for it. Immutable backups resist changes or deletion during a defined retention period. CISA's ransomware guidance recommends offline, encrypted backups and regular recovery testing.

Redundancy helps keep storage available, but it doesn't establish that you can recover yesterday's uncorrupted file. Ask how backups remain accessible during a regional or service outage, and get the provider's deletion, versioning, and recovery behavior in writing.

4. Restricted access and useful audit records

Use separate identities for backup jobs and administrators, and configure SFTP access controls to restrict each to the files and operations it needs. Use MFA for human access where supported, and check whether inbound IP restrictions can limit where backup credentials are used. Confirm that those credentials can't delete the only recovery copy.

Ask the provider to show you records of uploads, downloads, deletions, failed access attempts, and administrative changes. Confirm how long logs are retained and how you'll export and review them. If you use a SIEM, check whether events can be streamed into it and which alerts your team needs to configure.

5. Restore testing against clear recovery targets

Define two targets before comparing services:

• Recovery point objective (RPO): How much recent data can you afford to lose?
• Recovery time objective (RTO): How long can the affected workflow be unavailable?

Then restore a representative backup into a separate test environment. Check that the files open, the application can use them, and decryption works. Record how long the recovery took and who performed it.

For a database or EHR, confirm whether you need application-aware backups, transaction logs, configuration, or a vendor-specific restore procedure. Copying an export file doesn't establish that you can rebuild the entire system.

6. Reliable scheduling, failure detection, and realistic costs

Automation should make backups consistent and failures visible. Ask how the service handles missed jobs, partial uploads, retries, and a day when no expected file arrives. An upload notification alone won't tell you that a backup is missing. Our guides to healthcare SFTP automation and secure file transfer automation explain how file processing, notifications, and application handoffs can work together.

Price the storage for retained copies as well as current data, and check storage, file-size, and processing limits against expected growth. Include restore downloads, bandwidth, support, and any charges for monitoring or retention features. A low monthly storage price won't tell you what a full recovery costs.

Cloud backup vs. cloud storage vs. file transfer

Healthcare organizations often use these terms interchangeably, but each serves a different purpose.

HIPAA-compliant cloud storage can hold your backup files, but you still need a process that creates those backups, keeps earlier copies, and lets you restore them. Simply syncing files to the cloud may also copy accidental changes or delete the cloud copy when the original is deleted. Check that you can recover an earlier, usable version if something goes wrong.

How to build a secure file backup workflow with SFTP To Go

SFTP To Go combines managed file transfer with S3-backed storage. It supports encrypted transfers over SFTP, FTPS, and HTTPS, with AES-256 encryption at rest. For HIPAA-compliant SFTP and storage, BAAs are available on eligible plans; confirm the agreement and required features before using the service for ePHI.

For healthcare teams whose applications produce backup files or scheduled exports, a practical workflow is:

1. Create the backup at the source. Use your application or backup software to produce a consistent backup and upload it through a dedicated credential with restricted directory access.
2. Process the uploaded file. Use native file automations to copy files into dated folders and send a notification or webhook after the action succeeds. If you need file-level encryption, native PGP actions support individual files up to 100 MB; larger files can be PGP-encrypted before upload. Native PGP encryption creates an encrypted copy and keeps the original, which you can remove with a separate action if needed.
3. Protect retained copies. Give recovery copies unique names and disable Overwrite existing files on applicable single-file actions to prevent those actions from replacing an existing file. Restrict deletion permissions and keep independently protected recovery copies where your backup strategy requires them. Review workflow history for failures and retries.
4. Keep decryption possible. SFTP To Go stores imported private PGP keys and passphrases encrypted in a separate secrets store. Keep your own protected copies, including any earlier keys needed to decrypt retained backups, because those secrets aren't displayed again after import.
5. Monitor and test. Review audit logs, and use near-real-time streaming to supported SIEM or observability destinations where your plan supports it. Use your backup software or a monitoring check to alert you if an expected upload hasn't arrived, then test downloading, decrypting where applicable, and restoring a retained backup.

Your source application creates the backup and performs the application-specific restore. SFTP To Go handles secure file transfer, storage, and file processing around those steps. This gives you a managed destination and native workflow tools without having to maintain your own transfer server.

Contact SFTP To Go to discuss the BAA, storage, automation, and monitoring you need. For the broader compliance work, use our guide to HIPAA security officer responsibilities.

Frequently asked questions