Is database-level encryption enough, or do we need field-level encryption for sensitive columns?

For most systems, volume or database-level encryption is the baseline and it is what auditors expect to see. Field-level encryption is an additional control that answers a different threat, and it is worth adding when the threat it answers is real for you. Disk-level encryption protects against someone obtaining the physical or virtual storage — a decommissioned disk, a copied snapshot, a stolen backup file. It does nothing against an attacker who has valid database credentials, because to that attacker the data is simply readable. Field-level or application-level encryption of specific columns protects against that second case, at the cost of losing the ability to index, sort, search, or join on those columns, plus real key management work. The usual sensible line is to encrypt the whole store at rest, then selectively encrypt at the application layer the handful of fields that are both highly sensitive and rarely queried — government identifiers, payment credentials, clinical free text, secrets. Encrypting every column by default usually produces a system that is slow, hard to debug, and no more defensible than the simpler design.

Do backups need to be encrypted separately from the primary database?

Yes, in the sense that the primary database being encrypted tells you nothing about the backup. They are separate objects in separate storage with separate configuration, and encryption does not travel with the data by itself. A snapshot taken by a managed service usually inherits the source volume's encryption, but a logical dump written by your own job — a pg_dump to a bucket, an export to a shared drive, a nightly file a vendor pulls — is exactly as encrypted as whatever destination you wrote it to, and no more. This is one of the most common gaps found during an audit, and the reason it is common is that backups are frequently built by a different person, at a different time, than the production database. Treat every copy as its own asset: confirm encryption on the snapshot, on the object storage bucket, on any exported file, and on any replica or staging restore. Check the restore path too, since a restored copy landing in an unencrypted staging environment reopens the hole you closed.

Does using a managed database service (RDS, Cloud SQL, etc.) handle this automatically?

Largely, but 'automatically' is doing too much work in that sentence, and the details vary by provider and change over time — verify against current vendor documentation rather than trusting a blog post. Managed database services offer encryption at rest using provider-managed keys, and on current versions it is commonly enabled by default for new instances. What it does not do is cover everything around the database: your object storage buckets, your log aggregation, your analytics warehouse, your search index, your queue, and any exported file are each configured independently. It also does not answer the key management questions an auditor will ask — who can use the key, who can administer it, whether you need customer-managed keys for a specific customer commitment, and how rotation is handled. And there is a version and age trap: older instances created before defaults changed may still be unencrypted, and on some platforms encryption cannot be turned on in place, requiring a restore into a new encrypted instance. Check your actual resources rather than assuming the default applied.

Encryption at rest: what SOC 2 and HIPAA each actually require

Neither framework hands you an algorithm to check off. SOC 2 is principle-based and HIPAA calls encryption 'addressable' — here is what that really means, where encryption at rest gets missed, and why key management is the part that fails an audit.

The checkbox that does not exist

Almost every engineer arrives at this topic expecting a rule. They have read a questionnaire asking "is data encrypted at rest?" and they assume that somewhere in SOC 2 or HIPAA sits a line stating an algorithm and a key length — AES-256, probably — that they either satisfy or do not.

The line is not there. Neither framework works that way, and the reason matters more than the trivia, because it changes what you build and what you have to be able to say about it.

SOC 2 is an examination against criteria that describe outcomes. HIPAA's Security Rule is deliberately technology-neutral and scaled to the size and risk of the organization, because it had to apply to both a solo practice and a national insurer. Both were written to survive the obsolescence of any particular cipher, so neither will tell you which one to use.

What has happened instead is convention. Strong symmetric encryption with well-known algorithms is so universal — the default on every major cloud platform, the assumption behind every security questionnaire — that it functions as a de facto requirement even though it is not a literal one. The practical answer is still "yes, use strong modern encryption at rest, everywhere." The point of knowing it is convention rather than statute is that it tells you what an auditor will actually do: they will not check your algorithm against a list. They will ask you to explain your decision, show it is applied consistently across every place the data lives, and demonstrate that you manage the keys properly. That is where audits are lost, and none of it is solved by picking a cipher.

What SOC 2 actually asks

SOC 2 examinations are conducted against the Trust Services Criteria, which are principle-based. The criteria relevant here concern protecting information during storage and restricting logical access to it. They describe what must be true, not how to make it true.

So encryption at rest is not literally named as a mandatory control in a specific form. It is, however, the control a reasonable organization handling confidential data selects to satisfy those criteria, and what an auditor expects to find. Choosing not to encrypt would require an argument, and there is essentially no good one available in a cloud environment where encryption is a free default.

The consequence is that the burden shifts. Instead of proving conformance to a stated standard, you demonstrate that you made a defensible decision and carry it out consistently. Concretely, an auditor is likely to want:

A written statement of what you encrypt and where. Not a policy sentence saying "data is encrypted at rest," but an inventory: these stores hold confidential data, this is how each is encrypted, this is who manages the keys. A policy without an inventory behind it is a claim.

Evidence that the setting is actually on. A configuration screenshot, an infrastructure-as-code definition, a cloud posture report. Auditors test the state of the system, not your description of it.

Consistency across the environment. This is the one that bites. If the primary database is encrypted and the analytics replica is not, the hole is the finding. Auditors sample, and sampling finds the store somebody forgot.

A risk assessment that connects the two. The criteria expect controls to follow from an assessment of your risks, so the chain has to be coherent: this data is an asset requiring protection, therefore these stores are encrypted. That coherence is what a principle-based framework is testing.

What HIPAA actually asks

HIPAA is where the surprise lives, and where the misunderstanding is most dangerous in both directions.

The Security Rule organizes requirements into standards with implementation specifications, each labeled either required or addressable. Encryption of electronic protected health information at rest is addressable, not required.

People hear "addressable" and read "optional." It is not. Addressable means the covered entity or business associate must assess whether the specification is a reasonable and appropriate safeguard in its environment, then do one of three things: implement it; implement an equivalent alternative that achieves the same protection, documenting why the substitution is reasonable; or, if neither is reasonable and appropriate, document that determination. The obligation is not to encrypt. The obligation is to reach and document a defensible decision about encrypting.

That flexibility exists for real reasons — the Rule applies across an enormous range of organizations, and a mandate written in the technology language of its era would have aged badly. But in a modern hosted system handling ePHI, the flexibility is theoretical, because every practical path leads back to encrypting.

The alternative is unsellable to a reviewer: explaining why encrypting a database of patient records was not reasonable and appropriate, when the encryption is a checkbox on your cloud console, is not a conversation with a good ending. Breach exposure changes entirely, because HHS guidance describes conditions under which PHI is considered rendered unusable, unreadable, or indecipherable, and data meeting that bar changes the analysis of whether notification is required at all — which does more to drive real-world adoption than the Rule's text does. And your customers impose it contractually regardless: business associate agreements and hospital security reviews routinely set expectations stricter and more specific than the Rule, so the framework's flexibility does not survive contact with a health system's procurement process.

So the honest summary is: HIPAA gives you a documented off-ramp that no competent organization should take. What it does require, unambiguously, is that you performed the analysis and wrote down the outcome. If you encrypt everything and never documented why, you have the right control with the wrong paperwork — and the paperwork is what gets sampled. The broader pattern of which HIPAA requirements map onto SOC 2 controls, and where the two frameworks genuinely diverge, is worked through in SOC 2 vs. HIPAA.

Where encryption at rest gets missed

Nobody forgets the production database. The findings come from everywhere else, because "at rest" means every place bytes are durably stored, and most systems store the same data in more places than anyone has counted.

Database backups and snapshots. Automated snapshots typically inherit the source's encryption, but logical dumps inherit nothing — a pg_dump written by a cron job is encrypted only if its destination is. Older backups taken before encryption was enabled still sit there in their original state, and backups are often the longest-lived copy of your data, retained for years after the production rows were deleted.

Log files with full request and response bodies. The most under-appreciated one. A team encrypts every data store carefully, then runs request logging that captures complete JSON payloads, ships them to a log aggregation platform, retains them for months, and makes them searchable by anyone with a login. If those payloads contain ePHI or confidential customer data, your logging platform is now a regulated data store, subject to the same expectations, configured by someone who did not think of it that way. The fix is upstream: redact sensitive fields before they are written, rather than securing a pipeline that should never have received them.

Object storage for uploads. Uploaded documents, scanned records, generated PDFs, exported reports, profile images that turn out to be photographs of insurance cards. Buckets get created by hand for one-off needs, and encryption settings are per-bucket. Any bucket outside your infrastructure-as-code is one nobody audited.

Analytics warehouses, search indexes, and caches. The copy in the warehouse is a copy. So is the document in the search index, the row in the queue, the object in the cache, the file in the pipeline's staging area. Each is separately configured, often owned by a different team, and every one is "at rest."

Non-production environments. A production dump restored into staging so somebody could reproduce a bug, or a CSV a developer exported for analysis, is a routine real-world exposure. Disk encryption on laptops is table stakes; the harder control is not putting real data outside production in the first place.

Third-party services holding your data. Support tooling, CRM, email platforms, error trackers capturing request context, AI providers processing your content. Encryption is their responsibility; demonstrating it is yours, which is what vendor review and, for ePHI, a business associate agreement exist to do. Routing regulated data through an AI provider raises this in sharper form, covered in HIPAA-compliant AI and LLM architecture.

The exercise that finds all of this is boring and effective: trace where a single sensitive record travels from the moment it enters your system, and list every place a durable copy comes to rest. The list is always longer than expected, and the entries you did not expect are the findings.

Key management is the part people skip

Encryption converts a data protection problem into a key protection problem. If you do not then solve the key protection problem, you have not protected anything — you have moved the target and told yourself it was gone. This is where auditors probe, and there are four questions worth answering without hesitation.

Where do the keys live? Not in the application repository, not in a committed config file, and above all not in the same store as the data they protect — a key beside its ciphertext hands an attacker both halves at once. Keys belong in a dedicated key management service or hardware-backed store.

Who can use a key, and who can administer it? These are different permissions, and conflating them is a common design error. The service that decrypts records at runtime needs to use the key; it should not be able to delete, disable, export, or repolicy it. Separating use from administration limits what a compromised service account can do, and it is a concrete thing to point at when an auditor asks how key access is controlled. How human access gets scoped is RBAC and SSO territory.

Is key access logged? Key usage and administration events belong in your audit trail. An unusual pattern of decryption requests is one of the clearer signals of exfiltration in progress, and unrecorded key operations cannot be reconstructed afterwards.

How does rotation work, and have you ever done it? A rotation policy nobody has exercised is a plan, not a control. Managed key services can rotate automatically while retaining prior key versions so existing ciphertext stays readable — but you still need to know whether anything in your system holds a cached key or a hardcoded reference, and what the procedure is for an emergency rotation after a suspected compromise. Test it once in a non-production environment; the failure modes surface immediately.

The deciding question underneath all four is simple: if an attacker obtained a full copy of your storage, would they also have obtained the means to read it? If the answer is yes through any path — keys in the same backup, an over-permissioned role, a secret in a repository — then the encryption is decoration.

At rest versus in transit

These get conflated constantly, including in questionnaires that ask about them in a single question, so it is worth stating the difference plainly.

Encryption in transit protects data while it moves between systems — browser to server, service to database, application to third-party API — which in practice means TLS on every connection, modern protocol versions, no silent fallback. The threat is interception. Encryption at rest protects data sitting in durable storage, and the threat is unauthorized access to the storage itself: a copied snapshot, a discarded disk, a misconfigured bucket.

Neither substitutes for the other. TLS between your application and your database does nothing for the backup sitting in a bucket; an encrypted volume does nothing for a request crossing an unencrypted internal connection. Both frameworks expect both, and both have the same shape of gap: the internal hops nobody thought about. The public endpoint is always on HTTPS. The connection to the cache, the replication link between regions, the pull from a partner's SFTP server, the webhook to an internal service — that is where unencrypted transit survives, for the same reason unencrypted storage survives in the analytics warehouse. Nobody looked.

One more distinction worth keeping straight, because questionnaires increasingly ask: neither control protects data while it is being processed in memory. That is a separate, much more specialized category, and if a reviewer asks about it they are asking about something you almost certainly are not doing. Say so plainly rather than blurring it into your at-rest answer — precise questionnaire answers build more trust than expansive ones, a pattern covered in the enterprise security questionnaire guide.

What good looks like

You can name every store holding sensitive data and, for each, state how it is encrypted and who holds the keys — backups, logs, object storage, and analytics copies included, not just the production database. Keys live in a managed key service, separated from the data, with use and administration split and key operations in your audit trail. TLS is enforced on internal hops as well as public ones. And you have written down why you made these choices, which for HIPAA is not bureaucratic overhead but the literal thing an addressable specification asks of you.

None of that is expensive if it is designed in. All of it is expensive to retrofit, mostly because retrofitting means finding every copy of the data you made while not thinking about it — the argument for building on compliance-ready architecture before the first enterprise customer asks.