Trust / Encryption
Encrypted at rest, and still searchable
Personal information is encrypted at the application layer — not merely on the disk volume — while a keyed blind index keeps names, emails and phone numbers searchable without decrypting them.
Volume encryption protects you from a stolen disk. Application-layer encryption protects you from everything that reads the database legitimately and should not see the field.
Ask how the blind index worksIf encryption is real, how does search still work?
A blind index: a keyed one-way transform of the searchable value, stored alongside the ciphertext. Searching for a surname hashes the search term with the same key and matches on the index — so the platform finds the record without ever decrypting the column, and the index tells an attacker nothing without the key.
Field by field
What is encrypted, and what happens to it
- 01
Names, emails, phone numbers
Encrypted at the application layer and searchable through the keyed blind index. Your staff search normally; the stored column is ciphertext.
- 02
Tax identifiers and dates of birth
Encrypted and additionally masked from non-administrative roles. A person who does not need the full value does not receive it, even inside your own organization.
- 03
Free-text notes
Encrypted. File notes are where the most sensitive material actually accumulates — medical detail, allegations, negotiation posture — and treating them as ordinary text would undo the rest.
- 04
Integration credentials
Write-only from the interface’s perspective: once saved, a credential is never returned to any screen or API response. A support session cannot read your carrier password back to you, because nothing can.
- 05
Logs and journals
Redacted at the point of writing. A contact search for a surname does not put that surname into the system journal — journals get shipped to monitoring tools and retained on schedules nobody remembers.
The uncomfortable questions
Answers we give before you ask
These are the questions that separate real encryption from a checkbox. If a vendor cannot answer them specifically, the encryption is probably volume-level and the conversation should continue.
Disk or field?
Field. Application-layer encryption of specific columns, not just an encrypted volume
Can you search encrypted names?
Yes, via a keyed blind index — no decryption occurs during search
Who can read a tax identifier?
Administrative roles only; masked for everyone else
Can support read our credentials?
No. Credentials are never returned to any screen once saved
Do names reach the logs?
No. Redaction happens at write time, before anything is shipped to monitoring
Does a restore prove decryption?
Only if somebody reads a real name on screen — which is the drill’s mandatory final step
Are reads audited?
Yes on sensitive endpoints — who looked at a record is often the question that matters
The limits of encryption at rest
Encryption protects data from the wrong reader. It does nothing about the right reader making the wrong decision, and it is not a key-management story on its own.
Not protection from authorized users
Somebody with a legitimate role and entitlement reads plaintext by design. That risk is managed by access control and by the audit trail on sensitive reads, not by encryption.
Blind index trade-offs
A blind index supports exact-match search, not arbitrary fuzzy matching on encrypted fields. Where you need loose matching on a protected column, we will tell you that rather than pretending.
Key management is the real question
Encryption is only as good as key custody. Ask us specifically about key handling and rotation — it is a fair question and we would rather answer it than have it assumed.