CRM & security
Choosing a CRM when confidentiality actually matters
For most businesses, CRM security is a checkbox. If you're a law firm, adviser, broker or anyone whose clients trust you with sensitive information, it's the whole question. Here's what to actually demand — beyond the badge wall.
Why the badge wall isn't the answer
Every CRM website has the same trust section: ISO logos, SOC 2, "bank-grade encryption". Useful — and largely beside the point. Those attestations mostly describe the vendor's processes, not the architectural question that matters to a confidentiality-driven firm: who is technically capable of reading your client records? In most mainstream CRMs the honest answer is: the vendor's staff (under policy controls), any attacker who compromises the vendor, and anyone with lawful process against the vendor. "Encryption at rest" means the disks are encrypted — the application, and therefore the provider, still reads your data in the clear to operate.
The questions that separate marketing from architecture
- Can your staff read our records, even in principle? The follow-up: "under what controls, and how is access logged?" Watch for the difference between policy ("we don't") and architecture ("we can't").
- Where does encryption happen? At-rest and in-transit are table stakes. Client-side (end-to-end) encryption — data encrypted before it leaves your device, keys never held usably by the provider — is the standard that turns "trust us" into "you don't have to".
- How is our tenant isolated from other customers? Shared databases with a customer-ID column, or genuine per-tenant separation with per-tenant keys? Cross-tenant bugs are a recurring breach class; isolation is your blast wall.
- Where does the data live, legally? UK/EU residency, which sub-processors touch it, and what happens on a foreign legal demand.
- What does the audit trail capture? Every read, or only edits? When a client asks "who has viewed my file", you want a report, not a shrug.
- How do we leave? Full structured export, key handling on exit, and deletion certification. Confidentiality includes the ending.
The trade-offs, honestly
Strong architecture has costs. True client-side encryption complicates server-side search (solvable with techniques like blind indexing, but ask how), some integrations, and password recovery — if the provider can reset your keys, the provider effectively holds them. A vendor who explains these trade-offs candidly is telling you they've actually built the architecture; a vendor who promises everything with no trade-offs is describing a brochure.
Where we fit in
Power Analytix builds in this space directly — our own CRM product is architected around client-side encryption and per-tenant key isolation precisely because of the questions above — scoped in writing, priced fixed, delivered by senior engineers. If you'd rather have it done than read about it, book a free scoping call.
The one-line test
Ask the vendor to complete this sentence in writing: "If our entire infrastructure were seized or breached tonight, your client records would be…" The acceptable ending is "unreadable ciphertext without keys we do not hold." Anything longer is a policy, not a protection. For how this fits a wider systems strategy in a regulated firm, our build-vs-buy guide covers when the right CRM is one built around you.