HIPAA and PCI Encryption Requirements

How HIPAA views encryption

HIPAA does not list specific algorithms, but it treats encryption of electronic protected health information (ePHI) as an “addressable” implementation specification:

“Addressable” does not mean optional in practice.
You must assess whether encryption is a reasonable and appropriate safeguard.
If you decide not to encrypt, you must document why and what you are doing instead.

Given the scale of breaches in healthcare, most serious organisations treat strong encryption at rest and in transit as mandatory for ePHI.

How PCI-DSS views encryption

PCI-DSS is more prescriptive for cardholder data:

Cardholder data must be encrypted when stored, except where strictly necessary in specific flows.
Keys must be protected, rotated, and managed under strict controls.
Transmission of cardholder data over open networks must use strong cryptography.

In practice:

PAN (primary account numbers) and sensitive authentication data are encrypted with strong symmetric ciphers (for example, AES-256).
Keys are often kept in HSMs or strong KMS setups.

PCI-DSS is focused on storage and movement of card data specifically; it does not try to govern every note or log, but anything touching card data falls under its rules.

What “strong encryption” looks like in HIPAA/PCI contexts

Regulators and assessors look for:

Modern, public algorithms:
Symmetric encryption with something like AES-256-GCM.
Correct key sizes and modes.
Strong key derivation or key management:
Password-based keys derived via KDFs such as PBKDF2 with high iteration counts.
Centrally managed keys stored in HSMs or KMS for server-side systems.
Defense in depth:
Encryption at rest.
Encryption in transit (for example, TLS 1.2+ with good cipher suites).

In a zero-knowledge, client-side encrypted system such as Inkrypt:

The browser uses the Web Crypto API.
Keys are derived from passwords using PBKDF2 (310k iterations).
Notes are encrypted with AES-256-GCM and a new IV per save.
Servers store only ciphertext, salt, IV, and metadata.

For more technical detail:

Where zero-knowledge, client-side encryption fits into HIPAA/PCI

Zero-knowledge designs can be attractive in regulated environments because:

The provider cannot decrypt stored data.
Backend compromise yields only ciphertext.
Insider and subpoena risks are reduced on the provider side.

However:

You are still responsible for:
Access control at the endpoints.
Device and identity management.
Data classification and usage policies.
Regulators focus on the entire environment, not just one vendor’s crypto design.

Inkrypt can reasonably be used for:

Storing and sharing notes about systems that handle PHI or cardholder data, rather than the raw data itself.
Incident documentation, procedures, and secrets that support regulated systems.

You should decide, in your own policies, whether primary PHI or PAN data is allowed in external tools at all, even if encrypted.

FAQ: HIPAA, PCI, and encryption

Q1. Does HIPAA mandate encryption for all ePHI?

HIPAA labels encryption of ePHI as “addressable,” but in practice regulators expect it unless you have a strong, documented reason not to. Most serious environments treat it as de facto mandatory.

Q2. Does PCI-DSS mandate encryption for all cardholder data?

PCI-DSS requires strong encryption of stored cardholder data and when it is transmitted over open networks, with tightly controlled key management. Only a few narrow cases allow temporary exposure.

Q3. Can I rely on a zero-knowledge tool like Inkrypt for HIPAA/PCI data?

You can use zero-knowledge tools to reduce risk, but responsibility stays with you. Many organisations restrict external tools from holding raw PHI or PAN data at all, even when encrypted. Using Inkrypt for supporting notes, not primary records, is often the more defensible pattern.

Q4. What algorithms are safe to reference in HIPAA/PCI documentation?

Algorithms like AES-256-GCM, with keys managed or derived via robust mechanisms (for example, PBKDF2 with high iteration counts or HSM/KMS-backed keys), are standard choices in regulated contexts.

Q5. How does Inkrypt’s design help in a regulated environment?

Inkrypt encrypts notes entirely in the browser via the Web Crypto API, using PBKDF2 (310k iterations) and AES-256-GCM. The server never sees passwords or keys and stores only ciphertext, reducing the impact of backend compromise for the data you choose to store there.

Where to go next

To understand our encryption architecture in more depth:

Then, if you want a zero-knowledge encrypted note layer to sit alongside your HIPAA- or PCI-scoped systems, start using Inkrypt at https://www.inkrypt.online and incorporate it into your internal security guidelines.