HIPAA Encryption Requirements for Health Tech Vendors: What Healthcare Organizations Ask and What to Answer

Many health tech vendors answer the encryption question on a healthcare security questionnaire the same way: "Yes, we encrypt data at rest and in transit." That answer is too thin for the reviewer on the other side, who needs specifics: what algorithm, what protocol version, where the keys live, and whether your backups and logs get the same treatment as your production database. HIPAA encryption requirements are addressable, and healthcare organizations already expect encryption in their questionnaires.

Under 45 CFR 164.312, encryption is an addressable implementation specification. That means you implement it, or you document why it is not reasonable and appropriate and use an equivalent alternative measure instead. In practice, healthcare security questionnaires already treat encryption of PHI at rest and in transit as expected, and reviewers look for specifics such as AES-256 at rest and TLS 1.2 or higher in transit. The real work is explaining exactly what you encrypt, proving it, and covering backups, logs, exports and third-party tools.

Key Points

• HIPAA lists encryption as "addressable" under 45 CFR 164.312, which means you either implement it or document why it is not reasonable and appropriate and use an equivalent alternative measure instead. In practice, healthcare customers' questionnaires already expect encryption of PHI at rest and in transit, and reviewers look for specifics such as AES-256 at rest and TLS 1.2 or higher.
• Security reviewers at healthcare organizations often follow up the initial encryption question by asking whether encryption is applied at the database or disk level, who manages the keys, whether backups and staging environments get the same encryption, and how third-party tools that touch PHI are handled.
• A complete encryption-at-rest answer names AES-256 and lists every place it applies, including production database, object storage, backups, application logs that might contain PHI fragments, and staging or QA environments that use production data.
• A complete encryption-in-transit answer covers every transmission path PHI travels. That includes browser to application over HTTPS with TLS 1.2 or higher, inbound and outbound API calls, internal service-to-service traffic, and database connections from application layer to database.
• Reviewers want to verify encryption statements with evidence such as the relevant section of your SOC 2 report covering encryption controls, configuration screenshots from the cloud console showing encryption enabled, TLS scan results showing supported protocol versions, and your written policy covering data classification and key management procedures.
• HHS published a proposed rule in January 2025 that would make encryption of ePHI at rest and in transit required, with limited exceptions. No final rule had been issued as of October 2026, and healthcare organizations already treat encryption as a hard requirement in their questionnaires.

What are HIPAA encryption requirements?

HIPAA encryption requirements refer to the technical safeguards covered entities and business associates must address to protect electronic protected health information (ePHI) from unauthorized access. The HIPAA Security Rule addresses encryption in two places under 45 CFR 164.312: as part of the access control standard for data at rest and under the transmission security standard for data in transit.

Both are listed as "addressable" implementation specifications. "Addressable" doesn't mean optional. It means you implement the specification if it is reasonable and appropriate in your environment. If it is not, you document why and implement an equivalent alternative measure if that is reasonable and appropriate, as 45 CFR 164.306(d)(3) sets out.

Can you skip encryption and document an alternative? The rule allows it only if encryption is not reasonable and appropriate in your environment, and you have to write down why.

In practice, try explaining to a healthcare organization's security reviewer that you chose not to encrypt their patients' data and rely on network segmentation instead. Expect that answer to stall the review.

What HHS proposed in January 2025

HHS published a proposed rule to strengthen the cybersecurity of electronic protected health information on January 6, 2025. Among other changes, it would remove the addressable category and require encryption of all ePHI at rest and in transit, with limited exceptions, for example a technology asset that cannot support encryption, paired with a written plan to migrate off it.

As of October 2026, no final rule has been issued.

Security questionnaires from healthcare customers already treat encryption as a hard requirement, so your answers need to meet that expectation today.

Why encryption matters for protecting ePHI

Encryption transforms readable ePHI into ciphertext that is useless without the decryption key. That single layer of defense addresses multiple risks at once.

If a laptop with full-disk encryption is stolen while powered off, the data on it stays protected. If a backup tape is lost in transit and the PHI on it was encrypted consistent with HHS breach notification guidance, which points to NIST SP 800-111 for stored data, and the key was kept separate and not compromised, it is not unsecured PHI, so the loss does not require breach notification. If an attacker copies a database snapshot without access to the key, the data stays unreadable.

Healthcare security teams review many vendors, and encryption is one of the baseline controls they expect to see. A clear answer on encryption at rest, in transit and key management settles that line item before it turns into a follow-up question.

What healthcare organizations ask about encryption in security questionnaires

If you've filled out more than a couple of healthcare security questionnaires, you've seen the question phrased many ways. They all ask the same thing.

How do you encrypt PHI at rest and in transit?

Sometimes it's a single line item. Sometimes it's broken into several sub-questions. A healthcare organization sent one of our software clients seven technical questions as part of an Authorization to Operate process, and one of those asked specifically for the encryption level the application uses for data at rest and in transit. We answered it in one line: AES-256 at rest, TLS 1.2 or higher in transit, and keys held in a managed key service with periodic rotation.

Most of the work is in the follow-ups. After the initial question, reviewers often ask about storage layer versus application layer, key ownership, scope, and third-party tools.

Storage layer versus application layer asks whether you encrypt at the storage layer (the disk or the database), in the application before data is stored, or both.

Key ownership asks who manages the keys. You, the cloud provider, or the customer.

Scope examines whether backups, logs, and staging environments get the same encryption.

Third-party tools raise questions about integrations or sub-processors that touch PHI.

A large financial services customer of a software company we support followed up on its questionnaire with two of them: is encryption at rest applied at the storage layer, and who manages the keys? The engineer's first draft said only that data was encrypted by the provider. The answer we wrote said which data stores are covered, that encryption is provided and managed by the cloud provider, and that customer-managed keys are not used today.

Encryption at rest: What a good answer covers

HIPAA encryption at rest covers every place PHI is stored, on disks, databases and storage services, while the data is not being read or written.

A good questionnaire answer names the algorithm, the scope, and the key arrangement.

Algorithm and scope

Expect reviewers to look for AES-256. The answer should confirm AES-256 and list where it applies.

Your production database, object storage, file systems, and any data warehouse or analytics store that holds PHI.

Then cover the places that are easy to forget. Does your backup system encrypt at rest with the same standard?

What about application logs that might contain PHI fragments? Exports or reports generated for customers?

Staging or QA environments that use production data?

Each of those is a place where unencrypted PHI can sit on disk, and each one can become a finding in an audit.

Devices you don't control

Some PHI sits on devices you don't own. In behavioral health software, a clinician may record a session offline on a device the company does not own and upload it later.

Your app doesn't control that device.

A behavioral health software company asked us what rules apply here. Our answer: record only with consent from everyone in the session, encrypt the local copy at rest with AES-256, and delete it as soon as the upload over TLS is confirmed.

Under HHS guidance, properly encrypted PHI that is lost doesn't trigger breach notification. Because the vendor can't control those devices, the encryption requirements go into the business associate agreement with the agency doing the recording, including a minimum security addendum and a right to audit.

NIST SP 800-111 provides guidance on storage encryption technologies for end user devices if you need a reference for your policy.

Encryption in transit: What a good answer covers

HIPAA encryption in transit protects PHI while it moves between systems. Your answer needs to name the protocol, the minimum version, and where it applies.

TLS 1.2 is the floor. TLS 1.3 is preferred.

NIST SP 800-52 Rev. 2 provides the guidelines for TLS implementations, and HHS breach notification guidance points to it for data in transit. Your answer should confirm that TLS 1.0 and 1.1 are disabled.

Every path PHI travels

Reviewers want to know that encryption covers every transmission path. Browser to application over HTTPS with TLS 1.2 or higher, inbound and outbound API calls that carry PHI, traffic between your own microservices, and connections from your application layer to the database.

Internal traffic is easy to miss. If your microservices talk to each other over unencrypted channels inside a VPC, that's a gap. Expect reviewers to ask about it.

Also consider whether any of your integrations involve tools that process PHI. If you send PHI to AI features, a question like is ChatGPT HIPAA compliant belongs in the same review, and your encryption-in-transit answer needs to cover those data flows too.

Key management: The follow-up question

After "what do you encrypt with," expect the next question to be "who holds the keys?"

Understanding the differences between symmetric vs asymmetric encryption helps here, but the questionnaire answer is more about operations than cryptography.

Your answer should specify where keys are stored, who can access them, and how often they rotate.

Many health tech vendors use a managed key service from their cloud provider (AWS KMS, Azure Key Vault, Google Cloud KMS). That's a reasonable answer. Say so clearly, and note whether you use provider-managed keys or customer-managed keys.

The financial services customer's follow-up asked about exactly this distinction.

Say what your SOC 2 report covers and what it carves out. When we answered the encryption question in the healthcare organization's Authorization to Operate review, we noted that the cloud host is carved out of the SOC 2 report, so the reviewer knew where to look for the infrastructure controls.

SOC 2 encryption requirements and HIPAA encryption requirements overlap here, and pointing the reviewer to the right section of your report speeds the review.

Data in transit vs data at rest

Data at rest means information stored on a disk, in a database, or in any persistent storage medium. When PHI sits in your production database, a backup file, or an export waiting for download, it is at rest. The risk is physical theft, unauthorized access to storage systems, or a breach that exposes the underlying files.

Data in transit means information moving between systems. When a patient's record travels from a browser to your application server, from your API to a third-party integration, or between microservices in your infrastructure, it is in transit. The risk is interception or exposure over unencrypted channels.

HIPAA requires you to address both. Encryption at rest protects stored data. Encryption in transit protects data while it moves. Healthcare reviewers ask about both because a gap in either one leaves PHI exposed.

Your questionnaire answer should treat them separately. Name the algorithm and scope for data at rest. Name the protocol and paths for data in transit. Reviewers want to see that you've thought through both scenarios and applied the right control to each.

How to implement HIPAA encryption requirements

Start by identifying every system that stores or transmits ePHI (if you're unsure what counts, start with what qualifies as PHI under HIPAA). That includes your production database, backups, logs, file storage, staging environments, and any third-party tools that touch PHI.

For each system, turn on encryption at rest using AES-256. Most cloud providers offer this as a setting in their console. Some services, such as Amazon RDS, only set encryption when the resource is created, so an existing unencrypted database has to be moved to an encrypted copy. Turn it on for databases, object storage buckets, and disk volumes. Verify that backups inherit the same encryption settings.

For data in transit, enforce TLS 1.2 or higher on every endpoint that handles PHI. Disable older protocol versions. Set up your load balancers and API gateways to reject connections that don't meet the minimum standard.

Set up key management through your cloud provider's key management service. Decide whether you will use provider-managed keys or customer-managed keys based on your customers' requirements. Document who has access to keys and how often they rotate.

Test your setup. Run a TLS scan against your public endpoints to confirm protocol versions and cipher suites. Review your infrastructure-as-code or setup scripts to ensure encryption settings are applied consistently across environments.

Document everything. Write a policy that names your encryption standards, lists the systems covered, and explains how you manage keys. Keep screenshots and audit evidence ready for security reviews.

Encryption tools and solutions

Many health tech vendors rely on encryption tools built into their cloud platform. AWS offers KMS for key management, RDS encryption for databases, and S3 encryption for object storage. Azure provides Key Vault and Transparent Data Encryption for SQL databases. Google Cloud has Cloud KMS and default encryption for Cloud Storage.

If you need application-layer encryption, libraries like OpenSSL and the cryptography modules in Python or Java provide AES-256 implementations. Use them when you need to encrypt data before it reaches the database or when you're building custom export or reporting features.

For TLS in transit, your load balancer or reverse proxy handles most of the work. AWS Application Load Balancer and NGINX both support TLS 1.2 and 1.3 with configurable cipher suites. Set the minimum version, disable weak ciphers, and test with SSL Labs or a similar scanner.

Key rotation can be automated through your cloud provider's key management service. AWS KMS and Azure Key Vault both support automatic rotation. If you manage keys yourself, build rotation into your deployment pipeline and document the schedule.

For sub-processors that handle PHI, confirm a business associate agreement is in place, and ask for their SOC 2 Type 2 report or security documentation. Verify that they encrypt data at rest and in transit, and confirm their key management approach. If they don't meet your standards, find a different vendor or carve PHI out of that integration.

Encryption best practices and ongoing compliance

Encrypt by default. Make encryption the standard setup for every new system or storage bucket you provision. That way you don't have to remember to turn it on later.

Automate your checks. Use infrastructure scanning tools to detect unencrypted resources. Set up alerts when a new data store is created without encryption enabled. Catch gaps before they become audit findings.

Review third-party vendors regularly. Every sub-processor that touches PHI should meet the same encryption standards you apply to your own systems. Ask for their SOC 2 report or security documentation, and verify how they encrypt during your annual vendor reviews.

Keep your evidence current. Update your encryption documentation whenever you add a new system, change how you manage keys, or upgrade a protocol version. Pre-stage the evidence healthcare reviewers ask for so you can respond quickly when a questionnaire arrives.

Train your team. Make sure engineers know the encryption standards you've committed to and understand how to set up new systems correctly. Include encryption requirements in your onboarding checklist and your change process.

Monitor for protocol deprecation. TLS 1.2 is the floor today, but that will change. Watch for NIST updates and plan to upgrade before your current protocol version becomes a gap.

Review encryption quarterly, checking for new data stores and new integrations that might have been missed. Keep your documentation and your evidence in sync with your actual setup.

The evidence reviewers ask for

Healthcare security reviewers want to verify your encryption statements, and they'll ask for documentation.

The artifacts they typically request include your SOC 2 report, screenshots, TLS scan results, and your encryption policy.

Your SOC 2 report should include the relevant section covering encryption controls, especially if your cloud infrastructure is in scope or carved out.

Screenshots show the cloud console with encryption enabled on storage, databases, and key management settings.

TLS scan results provide output from a TLS testing tool showing supported protocol versions and cipher suites.

Your encryption policy is your written policy covering data classification, encryption standards, and how you manage keys.

If you're pursuing HIPAA compliance alongside SOC 2, you'll find that both frameworks expect documented encryption controls. The evidence you prepare for one supports the other.

We helped ReadMe cut security questionnaire responses from 6 business days to 2 through GRC platform administration. Pre-staged evidence speeds up any questionnaire: encryption setups documented, SOC 2 sections bookmarked, key management details ready to paste.

Grab our free HIPAA Compliance Checklist to review your encryption documentation alongside the rest of your HIPAA program.

Where encryption answers go wrong

These data encryption mistakes are the ones that draw follow-up questions.

Too vague

"We use industry-standard encryption" tells the reviewer nothing.

Name the algorithm. Name the protocol version. Name the key management service. Vague answers trigger follow-up questions that delay your deal.

Incomplete scope

The production database is encrypted. That covers one data store.

What about backups sitting in a different storage bucket? Logs shipped to a monitoring tool? A CSV export a customer support agent generated last Tuesday?

Every data store that holds PHI needs the same treatment, and your answer needs to account for all of them.

Ignoring third parties

Any sub-processor that stores or receives PHI is part of your encryption answer.

If a third-party tool touches PHI and you haven't confirmed how it encrypts, you have a gap in your answer. Reviewers ask about this. Have the answer ready.

Confusing provider defaults with your controls

"Our cloud provider encrypts everything by default" is not true of every service, and it describes the provider's control rather than yours.

Your answer needs to explain what you've set up, what you've verified, and what the provider handles on your behalf. The distinction between provider-managed encryption and controls you own matters to reviewers.

What changes if HHS finalizes the proposed security rule

If HHS finalizes the rule as proposed, encryption of ePHI at rest and in transit becomes required. The addressable path goes away, and only the rule's listed exceptions remain, each of which you would have to document.

If you already encrypt PHI at rest and in transit because your healthcare customers expect it, little changes in practice.

The change matters more for your documentation. Today, when encryption is not reasonable and appropriate, a written justification and an equivalent alternative measure can stand in for it. Under the proposed rule, they could not, outside the listed exceptions.

Where it could matter is for edge cases. Vendors who've documented alternative measures for specific scenarios (legacy integrations, certain device types) would need to encrypt those workflows, redesign them, or show that a proposed exception applies, such as a technology asset that cannot support encryption paired with a written migration plan, or certain FDA-authorized medical devices. If your current documentation relies on any of those alternative measures, list them now so you know which workflows would change.

We helped Anterior, a healthcare AI company, become HITRUST-ready in 7 weeks to meet a customer's security demands. Moving that fast is easier when your encryption controls are already documented before the assessment starts.

Whether or not HHS finalizes the rule, healthcare customers ask for encryption at rest and in transit, named specifically and backed by evidence.

Frequently asked questions

What encryption does HIPAA require?

HIPAA treats encryption as an addressable specification, meaning you either implement it or document why it is not reasonable and appropriate and use an equivalent alternative measure instead. In practice, questionnaires from healthcare organizations ask how you encrypt ePHI at rest and in transit, and expect you to name exactly what you use and where it applies.

What are the HIPAA requirements for cybersecurity?

HIPAA's Security Rule requires covered entities and business associates to put in place administrative, physical and technical safeguards to protect electronic PHI. For vendors, that typically translates into being able to describe and evidence how you secure data across systems, including encryption, access controls, and vendor risk management.

What are the new HIPAA requirements for 2026?

As of October 2026, HHS has not finalized new Security Rule requirements. It issued a proposed rule in January 2025 aimed at strengthening cybersecurity protections for ePHI. If finalized as proposed, it would make encryption of ePHI at rest and in transit required, with limited documented exceptions. Teams should monitor the final rulemaking and plan for tighter documentation and enforcement expectations.

How do we prove encryption is actually enabled across environments during a healthcare security review?

Prepare a short evidence packet that maps each system that stores or transmits PHI to the specific proof a reviewer can validate. Relevant audit report excerpts and setup evidence work well. Keep it updated so you can respond consistently across questionnaires without relying on ad hoc engineering screenshots.

What should we include in a sub-processor encryption attestation so it satisfies healthcare procurement?

Include the exact data types the vendor touches, where the data is stored and processed, how the vendor encrypts storage and transport, and who manages the keys. Also confirm whether any data is used for secondary purposes (for example, model training) and reference the vendor's independent assurance reports where applicable.

How should we handle encryption requirements for customer-managed keys (CMK) requests without overcommitting?

Answer in a tiered way. State what you support today, what is configurable, and what would require a separate commercial and technical review. If you do not support CMK, clarify how you manage keys in your current architecture, what separation of duties exists, and what contractual or roadmap options are available for customers who require CMK.

Turn encryption answers into closed deals

Healthcare customers judge an encryption answer by how you handle follow-up questions, how quickly you produce evidence, and whether your documentation matches what your infrastructure actually does.

Get the scope right: production, backups, logs, exports, devices, and third parties. Name the standards (AES-256 and TLS 1.2 or higher). Explain how you manage keys. Pre-stage your evidence. Account for every path PHI travels through your system.

Once that work is done and kept current, you can reuse the same answers and evidence on each new questionnaire from a healthcare customer.

Get your encryption answers right and move deals forward

A specific encryption answer with evidence behind it gives the reviewer what they need the first time and leaves fewer follow-ups.

If your team is spending days on every healthcare security questionnaire and you're not sure your encryption answers hold up under follow-up questions, Cycore can help. We work as an embedded compliance and security team, handling questionnaire responses, audit prep, and the gap analysis that keeps your answers accurate.

Talk to an expert and let's get your encryption answers right. Cancel anytime. If you're not saving 100+ hours, you don't pay.