What Is Field-Level Encryption? (And Why Your CRM Probably Doesn't Have It)

Field-level encryption means specific, sensitive fields — a revenue figure, a contract value, a phone number — are individually encrypted with their own keys, so that even someone holding the raw database sees ciphertext where that data should be. That's the whole definition. The interesting part is everything it implies, and how rarely CRMs actually do it.

Most vendors will tell you they encrypt your data. Almost all of them are telling the truth and answering a different question than the one you should be asking.

Encryption at rest vs. field-level encryption

"Encrypted at rest" usually means the entire database — the disk, the volume, the backup — is encrypted as one big block. The database itself decrypts everything transparently the moment it's queried. It protects you against exactly one threat: someone physically walking off with the hard drive.

That's worth having. It's also the floor, not the ceiling. Because for the system to function, the data sits decrypted in memory, readable by the application, the database process, anyone with production access, and anyone who compromises a running server. Whole-database encryption is a locked warehouse where, once you're inside, every box is open.

Field-level encryption flips the model. Instead of encrypting the warehouse, you encrypt the boxes — and only the ones that hold something sensitive. The revenue column, the contract terms, the personal contact details get encrypted individually, with keys scoped to your account, before they're ever written down. The database stores and serves them without being able to read them. To turn the ciphertext back into a number, you need the key, and the key isn't sitting in the same place as the data.

You'll sometimes see this compared as field-level encryption vs. database encryption or vs. column encryption. The short version: database encryption protects the whole store against theft of the medium; column or field-level encryption protects individual values against everything that happens after someone is already inside.

Why most CRMs stop at "encrypted at rest"

Not because they're careless — because field-level encryption is genuinely more work, and it costs them something. Encrypted fields can't be casually indexed, searched, or sorted by the database the way plaintext can. The vendor has to design around that. Most decide the marketing line "bank-level encryption at rest" is close enough and move on.

It also quietly removes a capability vendors like having: the ability to read your data. Whole-database encryption keeps everything legible to the people running the service. Plenty of business models — analytics, "enrichment," support tooling, training data — assume the vendor can see what's in your account. True field-level encryption with keys you control takes that off the table, which is exactly why it's worth asking about.

When the encryption is real, you can also see who touched what. A privacy posture is only as good as its audit trail — here's FlowGrid's, logging every action with the actor, the event, and the object affected:

What field-level encryption actually protects you from

Three real scenarios, none of them exotic:

• A database breach. Someone exfiltrates your CRM's database. With whole-disk encryption, they now have a readable copy of every customer record. With field-level encryption, the sensitive fields are ciphertext without the keys — the blast radius shrinks from "everything" to "the columns we left in plaintext on purpose."
• Insider and provider access. Field-level encryption with tenant-scoped keys means the vendor's own staff — and their database host — can't quietly read your encrypted fields. Not "promise not to," but "can't without your active session."
• Backups and copies. Backups are where data quietly leaks: old snapshots, a misconfigured bucket, a laptop. Encrypted-at-the-field-level data stays encrypted in all of them.

Now the honest caveat, because overclaiming here is exactly the temptation. Field-level encryption is not a force field. It protects the fields you encrypt, not every byte in the system, and it does nothing about a compromise of your own logged-in session — if an attacker is you, they see what you see. No encryption scheme removes the need to trust your provider's operational security; it just shrinks how much you have to trust it. Anyone selling encryption as "unbreachable" is selling. The right frame is blast radius: when something goes wrong, how much is exposed?

Field-level encryption and the big CRMs

It's a fair question to ask of any vendor, including the incumbents. Salesforce, for instance, does offer field-level encryption — through Shield Platform Encryption, a paid add-on layered on top of the base product, configured per field. If "field-level encryption" matters to you and you're evaluating a large CRM, the questions to ask are: is it included or an upgrade, which fields can actually be encrypted, and who holds the keys? "We support it" and "it's on by default for you" are very different answers.

How FlowGrid does it

Field-level encryption isn't an enterprise add-on at FlowGrid — it's the default, on every plan, including the free one. Sensitive fields are encrypted with AES-256-GCM using tenant-specific keys, so your data is cryptographically separated from every other workspace, and the fields you encrypt aren't readable by us without your active session. Every change is captured in the audit log above, your data is hosted in the EU (Zurich region), and the GDPR paperwork — including a DPA — is ready when your legal contact asks.

If you want the fuller picture of how this fits a privacy-first setup, our security overview lays out the architecture, and the privacy-first CRM comparison walks through what else to evaluate beyond encryption — data residency, subprocessors, trackers, and the right-to-be-forgotten tooling that turns "we take privacy seriously" into something you can verify.

Start Free — encrypted by default, no credit card.