Column-Level Encryption Enterprise (CLEE) is the right answer when regulators demand encryption at rest beyond the platform default. It is the wrong answer when someone wants “encryption” as a vague compliance gesture. The tradeoffs are real and they shape every downstream design decision.
What encryption actually breaks
An encrypted field is opaque to the database. That means: no LIKE searches, no STARTSWITH, no list filtering on the encrypted column, no indexes that use the column, no joins on the column, no reports that group or aggregate by it. Reference fields cannot point to encrypted reference targets. The only operations that work are exact-match equality for fields encrypted with deterministic encryption, and “show me this one record” by sys_id.
If your stakeholder wants to “search by encrypted SSN,” the answer is no. Not in any reasonable performance budget.
Equality search needs deterministic encryption
CLEE supports two modes: equality-preserving (deterministic) and standard (non-deterministic). Deterministic encryption lets you do addQuery('u_ssn', userInput) and get a match. Non-deterministic encryption is more secure but only allows retrieval by sys_id. Choose based on workflow, not on a generic preference for “stronger encryption.”
Design with a tokenization layer instead
For most use cases, the better pattern is to encrypt only a few fields and add a tokenized lookup field that contains a hash or last-four-digits version. Users search on the lookup field, the system retrieves the record, and the encrypted field is decrypted only when displayed. This pattern preserves UX while keeping the sensitive column genuinely opaque.
Performance impact is real on bulk operations
Decryption happens on read. A list view of 50 records with three encrypted fields decrypts 150 values per page render. On heavily used tables, this adds 50 to 200ms of latency per list view. Reports that touch encrypted columns are usually 5 to 10x slower than equivalent reports on plain columns. Plan accordingly and avoid putting encrypted fields in default list views.
Key rotation is a multi-week project
Rotating encryption keys requires re-encrypting every value in the column. On a million-row table, expect several hours of background work and elevated load. Schedule rotations during low-volume windows and have a rollback plan that can pause mid-rotation. Test the rotation in a clone first, every time.
Cloning copies the ciphertext, not the keys
Clones do not automatically carry the production encryption keys. If you need to read encrypted data in sub-prod for testing, you must explicitly clone the keys, which is itself a security-sensitive operation requiring approval. Many teams discover this the day after their first clone and lose hours debugging “decryption failed” errors.
Audit access to decrypted views
Reading an encrypted field should generate an audit event. Configure glide.encryption.audit_access=true and review the audit log monthly. Patterns of decryption activity are themselves useful security signals; an account that suddenly starts decrypting hundreds of SSN values per hour is worth a phone call.
What to do this week: list every encrypted field, classify each as deterministic or non-deterministic, and confirm there is a tokenized search field for any user-facing lookup.
