What encrypted at rest actually means for a contact form
A form vendor’s pricing page had a bullet that read: “Encrypted at rest.” The clinic that asked us to evaluate them treated that bullet as the answer to their HIPAA question. It was not the answer. It was a phrase that, on its own, told them almost nothing about whether the form was safe to use for patient intake.
“Encrypted at rest” is a real technical term that has been worn down by marketing use until the meaningful version of it is hard to recognize. This post is what I wish I could hand to every practice manager evaluating a form vendor.
What “at rest” means in plain terms
Data lives in three states. It is in transit when it is moving between computers, like when a parent submits a form and the data travels from their browser to the vendor’s servers. It is in use when an application is actively reading or processing it. It is at rest when it is sitting on a disk somewhere, waiting to be read.
“Encrypted at rest” means the data is encrypted while it is sitting on a disk. If someone physically stole the disk, or got copy of the disk image, the data would be unreadable without the encryption key. That is the entire promise. It is a real and useful protection. It is also one of three places encryption has to live, and the easiest one to claim.
The four levels of “encrypted at rest”
Not all encrypted-at-rest claims are equal. There are at least four meaningful tiers, and vendors will use the phrase to mean any of them.
Level 1: Disk-level encryption. The cloud provider (AWS, Google Cloud, Azure) encrypts the volumes that host the database. This is on by default for most modern cloud services. It protects against physical theft of hard drives from a data center. It does not protect against anyone with database credentials, anyone with application access, or anyone with a backup. This is the lowest meaningful tier.
Level 2: Database-level encryption. The database engine encrypts the data files. Postgres TDE, MySQL data-at-rest encryption, MongoDB encrypted storage engine. Slightly better, because it protects against attackers who get the raw data files but not database credentials. Still does not protect against an attacker who has gained access to the application or the database itself.
Level 3: Column-level encryption. The application encrypts specific sensitive columns before writing them to the database, and decrypts them when reading them. The database itself sees ciphertext. Even an attacker who can run SQL queries cannot read the encrypted columns without the key. This is the level that meaningfully changes the threat model for PHI.
Level 4: Per-record encryption with key isolation. Each record (or each tenant, or each form submission) is encrypted with a unique key. The keys are stored in a separate key management service, not in the same database as the data. The application has to request the key per-read, and access can be revoked or audited. An attacker who gets the full database still has to compromise the key management service separately, and even then only gets one record at a time.
Most form vendors who advertise “encrypted at rest” are at Level 1. Some are at Level 2. Very few are at Level 3 unprompted. Level 4 is usually a custom build or a purpose-built product, not a checkbox feature.
The question to ask
When a vendor claims encrypted at rest, the diagnostic question is: “At which layer, and what does the encryption protect against?”
A vendor at Level 1 will say something like “all data is stored on encrypted volumes managed by AWS.” That is true. It is also the floor. It does not protect against the most common attack paths, which are application-level breaches and credential compromise.
A vendor at Level 3 or Level 4 will say something more specific. “Patient health information fields are encrypted at the application layer using AES-256 with keys held in [some key management system]. The database stores ciphertext. Decryption requires application-level authorization.” That sentence tells you something real.
If the vendor cannot describe their encryption at this level, the claim is decoration.
The four follow-up questions
Once you know which level the vendor is at, four follow-up questions sharpen the picture:
- Where are the keys held? Same database as the data is the worst answer. A managed key service like AWS KMS, Google Cloud KMS, or HashiCorp Vault is meaningfully better. An HSM is best for high-stakes deployments.
- Who can decrypt the data? Anyone with database access? Anyone with application admin access? Specific named roles? The smaller the access set, the better.
- Are backups also encrypted with the same approach? Backups are often the soft underbelly. A vendor with strong production encryption and unencrypted backups has a soft underbelly.
- What is encrypted in the notification email? If the form encrypts the field at rest and then emails it in plaintext to the office manager, the encryption was for show. We have written separately about that exact failure.
What it looks like done right
A form built with serious encryption posture for clinical use looks roughly like this. The browser submits over TLS 1.3. The form handler validates and routes the submission. PHI fields are encrypted at the application layer using a library like libsodium with per-record nonces and a key fetched from a key management service. The encrypted ciphertext is written to the database. The notification email contains a UUID, not the data. The admin who needs to read the form logs into an authenticated interface; the application requests the key, decrypts the record, and logs the access. After a configurable retention period (we use 14 days for intake), the record is hard-deleted from the database.
None of that is exotic technology. It is roughly 200 lines of code in any modern web framework. It is also not what almost any off-the-shelf form vendor does by default. This is why we built our own form layer for the medical practices we serve. The promise had to match the implementation.
The bottom line
“Encrypted at rest” on a vendor’s pricing page should trigger four questions, not satisfy one. The phrase is not a lie when used at Level 1. It is just not enough. The threat model for a clinic form includes credentialed insiders, compromised application accounts, leaked backups, and over-broad email notifications. Disk-level encryption does not address any of those. Column-level or per-record encryption with key isolation does.
If your form vendor’s answer is “we use encrypted volumes,” that is the start of the conversation, not the end. See the broader vendor procurement questions for context, and our plans page for how we structure form work around this standard.
