CRM Security Checklist: 15 Questions for a Vendor Security Review

A CRM vendor security review is a written questionnaire covering six areas: who can see a record, who changed it and when, how backups work, where the data lives and who else touches it, what happens after an incident, and how you get your data out. Fifteen questions cover all six below.

What is a CRM vendor security review, and who needs the full one?

A vendor security review is a written questionnaire you send a CRM provider before you sign, or before you renew, covering how it protects your records, who inside the vendor’s company can reach them, and what it does if something goes wrong. It exists because a CRM isn’t one dataset among many: it’s your whole customer relationship history, including anything a rep typed into a note field that they probably shouldn’t have.

Most lists you’ll find online treat “do you have SOC 2?” as the review. It’s a starting point, not the answer. A SOC 2 report, per the AICPA’s own description of the SOC suite, is an outside auditor’s opinion that a vendor’s controls, over a defined period and a defined scope, matched what the vendor said they would do. It doesn’t tell you which fields a rep can see, how long a backup is kept, or who your data gets shared with, and plenty of CRMs still growing into that audit, Senitix included, don’t have one yet. Ask the fifteen questions below either way; a certification is a supplement to specific answers, not a replacement for them.

A regulated buyer, or anyone signing a multi-year contract, should run the full fifteen and get every answer attached to the contract in writing. A five-person team on a monthly plan can start narrower: access control and data export are the two questions that are expensive to discover the answer to too late, so don’t skip those even on a short review. Example: picture an operations manager at a 40-person distribution company running a shortened version of this list against three CRM vendors before ever booking a demo. Two get cut on the first two questions alone, because neither can say, in writing, who inside their own company can see a customer’s records.

Access control

• “Who inside your company can see a specific field, like a deal’s value, and how is that enforced?” A good answer names the actual mechanism (role, department, field-level permission), not just “we have permissions.” A red flag is anyone with a login being able to see everything by default.
• “Can we require single sign-on, and which protocol?” A good answer names the standard (OpenID Connect and SAML are not the same thing) and which plan or tier it’s available on. A red flag is a vendor that promises SSO but can’t say which one they actually support.
• “What happens to a user’s access the day they leave our company?” A good answer describes a specific admin action (deactivating the user, reassigning their records), not an automatic timer. A red flag is “we don’t have a documented process for that.”

Audit and change history

• “Is there a record of who changed a specific field and when, and how far back does it go?” A good answer names what’s actually logged (field-level changes, not just who logged in) and a retention window. A red flag is “we can look in the database if you ask us.”
• “Is there a separate log of administrative changes (new users, permission changes, deleted records) from ordinary record edits?” A good answer distinguishes an admin or setup audit trail from everyday field history, and says which plan tier includes it if it’s gated. A red flag is treating “we have logs” as if it already answered this.

Backups and recovery

• “How often is data backed up, and is the backup encrypted and stored somewhere other than the primary database?” A good answer names a cadence (daily and monthly, for example), confirms encryption, and describes a separate location or region for the copy. A red flag is “regularly,” with nothing more specific.
• “How far back can you restore a specific record’s history, versus restoring the whole database?” A good answer distinguishes point-in-time recovery of one record from a full-database restore, since they’re different operations with different windows. A red flag is no distinction offered at all.
• “When did you last actually test a restore, not just take a backup?” A good answer names a recent, dated drill and a rough recovery time. A red flag is “we’ve never had to.”

Subprocessors and data location

• “Where is the data physically hosted, and does that ever change without notice?” A good answer names the region and provider, confirms it’s consistent across the environment, and commits to notice before a change. A red flag is “wherever is fastest that day.”
• “Can you give us a current, named list of subprocessors: who else touches the data, and for what?” A vendor should already have this list ready. A good answer is a maintained list (hosting, email delivery, error monitoring, and similar), not “just us.”
• “Is there a signed data processing agreement we can review before we commit, not after?” A good answer is a standing DPA available on request. A red flag is “our legal team will draft something once you’ve signed.”

Incident response

• “If there’s a security incident involving our data, how and how fast do you tell us?” A good answer names a specific timeframe and a channel (email to a named contact within a stated number of business days of confirming it), matching what the DPA commits to. A red flag is no committed timeframe at all.
• “What information do we actually get (which records, what happened, what you did about it), or just a notice that something happened?” A good answer describes the scope and remediation detail a past notification has included, even in general terms. A red flag is a vendor that can’t describe what that communication has looked like.

Data export on exit

• “If we leave, can we export every record, including custom fields and activity history, in a format we can actually use?” A good answer is a full export in a standard format like CSV or Excel, included on every plan rather than sold as an add-on.
• “How long after we cancel do we still have access to get that export, and what happens to the data after?” A good answer states a defined access window after cancellation and what happens to the data once it closes. This is often the vaguest of the fifteen answers, so get it in writing.

What a vendor’s answer tells you

A few patterns are worth watching for across all fifteen answers, not just any single one of them.

A specific mechanism, a named plan tier, and a comfortable “not yet” about something genuinely not built are all good signs: they mean you’re talking to someone who knows the product rather than reading a script. Reciting a certification instead of the specific answer, refusing to put anything in writing, or giving you marketing copy word-for-word from the website are the opposite signal.

Get every answer in writing and attach it to the contract or the data processing agreement, not just a sales call. Re-ask before a renewal or a plan change, too: a vendor’s answer from eighteen months ago describes an eighteen-month-old product, not the one you’re renewing.

Where Senitix fits

Senitix CRM’s own answers to most of the questions above (encryption, backup cadence, access control and audit history) are published on the security page, and the current data processing agreement is on the DPA page. Ask for both in writing before you sign, the same way you would with any vendor on this list.

For how the access-control side specifically is structured in Senitix CRM (roles, record ownership and field-level security), see our guide to CRM permissions. If you’re still comparing vendors more broadly, the best CRM software guide covers the wider field, and Senitix CRM pricing has the plan details.

Frequently asked questions

How is a CRM security review different from a general SaaS vendor questionnaire?

The questions overlap, but a CRM holds your whole customer relationship history in one place: every note, email and deal detail a rep has ever typed. That raises the stakes on access control and data export specifically, which is why this list weights them more heavily than a generic IT questionnaire would.

What if a vendor won’t put any of these answers in writing?

Treat it as an answer in itself. A vendor confident in its controls can put them in an email, a security page, or a DPA without much friction; one that won’t is asking you to take a verbal claim on faith for something you can’t verify later.

How often should we re-run this review?

At renewal, at minimum, and again any time you add a use case that touches more sensitive data (importing financial fields, connecting a new integration, adding a regulated business unit). A vendor’s security posture changes as it grows, and your review should catch up to it.

Who inside our company should own this checklist?

Whoever owns the contract, usually sales operations, ops or IT, should collect the answers, but a manager who knows what data will actually live in the CRM should review them: the person negotiating price isn’t always the person who knows which fields are sensitive.