Security questionnaires are mostly theater. Both vendors check the boxes: SOC 2 Type II, AES-256 encryption at rest, TLS in transit. The questionnaire is satisfied. You move on to pricing.
But the security incidents that actually affect enterprise CRM customers almost never come from a breach of the encryption layer. They come from a support rep who can see deal values they shouldn't. From an API token scoped too broadly that gets rotated into the wrong environment. From an audit log with a gap exactly wide enough to make the incident hard to reconstruct. From a new feature shipped under pressure that forgot one WHERE clause — and suddenly User A can query records belonging to Org B.
The real security risks in multi-tenant CRM are in the access control layer, not the encryption layer. And most vendor security reviews never reach that layer, because the questions stop at the wrong level.
This post gives you a framework for going deeper: the Three-Layer Security Test, six vendor questions that actually reveal architecture, and a 15-item checklist you can apply to any platform you're evaluating.
Encryption protects data at rest and in transit. Access control determines who can reach it while it's active. Most CRM security failures happen in the access control layer — and most vendor security reviews never examine it.
The Three-Layer Security Test
Any multi-tenant CRM has three distinct security layers, each with its own failure modes. The test isn't pass/fail — it's a structured way to understand what the vendor has actually built and where the exposure lives.
Data Isolation: Where Is the Enforcement?
The question is not "is your data isolated?" Every vendor will say yes. The question is: where is isolation enforced — at the application layer or the database layer?
Application-layer enforcement means every query in the codebase includes a WHERE clause filtering by org ID. In theory, this works. In practice, it requires every developer, on every feature, in every hotfix, forever, to correctly include that filter. One missing clause — in a new endpoint, a third-party integration, a quick bug fix at 11pm — creates a cross-tenant exposure. The data is not returned to the user's screen, but it is returned to the query. Application-layer isolation is as strong as the least-careful commit in the codebase.
Database-layer enforcement (specifically, Postgres Row Level Security) attaches security policies directly to the table. Postgres enforces them before returning any rows, regardless of what the application code says. A SELECT * with no WHERE clause still returns only the current org's records. A missing application-layer filter doesn't create an exposure, because the database policy holds regardless.
A developer builds an internal admin endpoint to help debug a customer issue. They forget the org_id filter. The endpoint is never exposed in the UI, so it survives code review. Six months later, a malicious API request — or an automated scanner — discovers the endpoint and queries it with a crafted org_id. Application-layer isolation: the records are returned. Database-layer RLS: zero rows returned, regardless.
Role Propagation: What Does a New User Inherit?
When you provision a new user in a CRM, what permissions do they get before your admin configures anything? This is the difference between minimum-privilege defaults and maximum-privilege defaults — and it determines your blast radius when someone is provisioned incorrectly or an account is compromised.
Maximum-privilege defaults are common in platforms built for small teams, where ease of setup was the priority. A new user inherits broad access so they can "see everything and get started quickly." In practice, this means a contractor brought in for one quarter can see your entire pipeline, commission structures, and customer contact data — unless an admin explicitly locks them down. Most admins don't.
Minimum-privilege defaults require explicit permission grants before any access beyond the user's own records is available. Slower to set up. Dramatically smaller blast radius when an account is over-provisioned or compromised.
The role hierarchy matters as much as the defaults. A CRM with three roles — admin, user, read-only — forces privilege over-granting at every boundary. A support agent needs to resolve tickets. The only way to give them access is to make them a "user," which also gives them deal values, pipeline stages, and commission data they have no business seeing. Granular roles exist because "just make them a user" is how internal data leaks happen.
A company grants "user" access to a new SDR. The default role includes read access to all contacts and deals, not just their own. The SDR leaves three months later. In their final week, they export the full contact database. The platform logged the export. Nobody was watching the audit log.
Audit Completeness: Can You Reconstruct What Happened?
Many CRMs log actions. Far fewer log reads. And almost none make their audit logs tamper-proof. This distinction matters enormously when something goes wrong — a disputed commission, a data sharing claim, a compliance audit.
Action logging captures writes: contact created, deal updated, sequence enrolled. This is table stakes. You can verify what changed and who changed it.
Read logging captures visibility: which records a user accessed, which fields were displayed, which exports were generated. This is what you need to answer "did this person see this data?" — a question that comes up constantly in GDPR data subject requests, internal investigations, and security incidents.
Audit immutability is the property that determines whether your audit log is actually trustworthy. If audit records are written using the same credentials as user sessions, a sufficiently privileged user can modify or delete their own audit trail — eliminating evidence. Audit records should be written using service-role credentials that no user session can touch, even compromised ones.
A rep is accused of sharing a prospect list with a competitor before leaving. The CRM logs show the rep exported a list. The rep's account had admin access. The audit log entry for the export was deleted. The CRM has no read logs showing which records were accessed in the days prior. The investigation stalls. The compliance gap is the missing read log, not the missing export record.
Why AI Makes Layer 1 More Critical
Traditional CRM generates roughly 50-100 database operations per user per hour. An AI agent executing a single request — "brief me on all accounts with deals over $100K where last contact was more than 14 days ago" — makes 20-50 database operations in one response: contacts, deals, activities, notes, email threads, all queried and joined. Then it drafts a follow-up, logs the activity, and updates the deal stage. Another 10 operations.
At 50 reps making 20 AI interactions per day, the total database operation count is an order of magnitude higher than a traditional CRM. More operations means more surface area for any application-layer isolation failure to manifest as an actual incident.
Database-layer RLS (Layer 1) scales perfectly with this. Whether the AI makes 2 calls or 2,000, the Postgres policy applies to every one. You do not need to verify that every AI-generated query includes the right filter — the database will not return the wrong rows regardless of what the application code does.
This is why the AI integration question belongs in the Layer 1 test: if a vendor's AI operations bypass RLS for performance reasons — which is a real temptation, because RLS does add overhead — the entire value of database-level isolation is undermined at the moment your attack surface is largest.
A Note on Revian's Architecture
Revian uses Supabase, which is built on Postgres and has first-class support for Row Level Security. Our database tables have RLS policies that enforce org isolation at the database layer — application-layer filters are present as a belt-and-suspenders measure, not the primary enforcement mechanism. AI-generated queries go through the same Supabase client with the same RLS enforcement as UI-originated queries.
The honest tradeoff: RLS adds query planning overhead. For high-frequency AI operations, we've had to be deliberate about index design to keep that overhead acceptable. This is a real engineering cost of doing Layer 1 correctly, and any vendor who says database-level isolation has no performance tradeoffs is not being straight with you.
Audit records are written using service-role credentials that bypass RLS — intentionally, so that no user session can modify or delete audit entries. Read operations are logged for sensitive resources. Role defaults are minimum-privilege: a new user starts with access to only their own records until explicit grants are made.
Six Questions to Ask Any CRM Vendor
These questions are not softballs. A vendor who knows their architecture will answer each one in under 30 seconds. A vendor who hedges is telling you something important.
GDPR and the Audit Immutability Conflict
There is a genuine architectural tension worth understanding before you sign a contract with any CRM vendor: GDPR right-to-erasure conflicts directly with audit log immutability.
If audit logs capture full payloads — which they should, for complete auditability — they contain PII: names, email addresses, phone numbers, deal context that references the contact. Deleting the contact record doesn't delete the audit records containing their data. The audit log is required to be immutable for compliance. GDPR requires erasure. You can't fully satisfy both simultaneously without a specific architectural solution.
The correct solution is a PII-scrub endpoint: a dedicated operation that replaces identifiable fields in audit records with anonymized placeholders, while preserving the record structure and foreign key integrity. The event still exists — "contact updated on [date] by [user]" — but the specific PII fields are overwritten. Both requirements are satisfied: the audit record stands, and the personal data is erased.
Ask your vendor directly: "How do you handle GDPR right-to-erasure for PII that appears in audit log payloads?" A vendor who has solved this problem will answer immediately. A vendor who hasn't will either say "that's handled at the database level" (it's not — deleting a contact row doesn't scrub audit payloads) or they'll tell you their logs don't contain full payloads, which means their audit completeness is lower than you need.
The 15-Item Security Evaluation Checklist
Use this checklist during vendor evaluation. All 15 items should have clear, affirmative answers before a $50k+ platform decision.
Layer 1: Data Isolation
Tenant isolation is enforced at the database layer (Row Level Security), not solely at the application layer.
A missing application-layer filter does not result in cross-tenant data exposure — the database policy holds regardless.
The vendor can demonstrate RLS policies on their database tables (not proprietary, not sensitive to share).
AI-generated database queries go through the same isolation enforcement as UI-originated queries — no bypass or elevated credentials for AI operations.
DELETE operations explicitly verify org ownership before deleting — records cannot be deleted by ID alone without org_id confirmation.
Layer 2: Role Propagation
New users are provisioned with minimum-privilege defaults — access to their own records only, no implicit team or org-level access.
The role hierarchy has at least five distinct levels, with separate roles for support, external partners, and read-only contributors.
External/partner roles are scoped to specific resources, not org-wide read-only access — a deal room guest cannot see your full pipeline.
Support roles explicitly exclude access to deal values, pipeline stages, and commission data — financial data requires a separate role grant.
API tokens are scoped to the minimum permissions required — a token for a specific integration cannot access unrelated data types.
Layer 3: Audit Completeness
Audit records are written with service-role credentials — no user session, including admin, can modify or delete them.
Read operations on sensitive resources are logged, not just writes — you can reconstruct which records a user accessed on any given date.
Audit records capture: timestamp, user ID, org ID, action type, resource type, resource ID, input payload, output, and originating IP address.
The vendor has a specific mechanism for GDPR right-to-erasure that scrubs PII from audit payloads without deleting the audit record itself.
AI-initiated actions generate the same audit records as user-initiated actions — you can attribute every database mutation to either a human or an AI operation, with full context.
Send this list to the vendor's solutions engineer before your security review call. Ask them to confirm each item in writing before the meeting. Watch for hedges: "our process ensures..." and "our architecture prevents..." are not the same as "yes, this is enforced at the database layer." Hedged answers are no answers.
The Question That Ends Most Security Reviews Early
If you have time for only one question, ask this: "Can you show me the Postgres RLS policy on your contacts table?"
A vendor with genuine database-level isolation will answer in 60 seconds. The policy is two to four lines of SQL — there's no reason not to share it. If they can't produce it, or need to "check with engineering," or tell you it's proprietary, you have a complete answer about their Layer 1 posture. The rest of the security questionnaire becomes context for a different kind of decision.
Encryption is table stakes. Access control architecture is where the actual risk lives. The three-layer test is how you evaluate it systematically rather than trusting marketing language and SOC 2 summaries.
Security architecture that holds even when application code doesn't.
Postgres RLS at the database layer, 7-level RBAC with minimum-privilege defaults, immutable audit logs with read tracking, and GDPR PII scrubbing — built in, not bolted on.
Request a Technical Session