A CRM usually holds more concentrated information about people than almost any other business system: names, contact details, purchase history, conversation notes, and sometimes payment or contract details. It is also used daily by many people, connected to many other tools, and often configured by whoever needed something quickly. That combination makes a documented security baseline worth the effort. A baseline is simply the minimum set of settings and practices you expect every CRM environment to meet, written down so it can be checked.

Start With What You Are Protecting

Before touching settings, list the categories of data the CRM holds and who depends on it. A system that stores only business contact details has a different risk profile from one that also stores support transcripts, health-related notes, or financial terms. Rank the data by how much harm would follow if it were exposed or altered. This ranking decides where your strictest controls belong, and it keeps the baseline proportionate instead of treating every field as equally sensitive.

The Core Baseline Areas

Most CRM baselines cover the same handful of areas. The exact setting names differ by platform, so check the vendor’s current documentation for how each is configured.

Authentication. Require strong authentication for every user, ideally through your central identity provider with single sign-on, and enforce multi-factor authentication. Shared logins defeat accountability and should not exist.

Authorization. Grant the least access a role needs. Review profiles and permission sets so that exporting, bulk editing, and deleting records are available only to people who need them.

Data protection. Confirm encryption in transit is enforced, understand what the vendor offers for encryption at rest, and decide whether any especially sensitive fields need extra handling such as masking.

Logging. Make sure sign-in events, permission changes, and data exports are recorded and retained long enough to investigate an incident.

Integrations. Inventory every connected application, API key, and automation, and confirm each has an owner and a narrow scope.

Recovery. Know how data is backed up, who can restore it, and whether a restore has ever actually been tested.

A Baseline Review Checklist

Use a table like this one as a working document. Assign each row an owner and a review date.

Area	Question to answer	Evidence to keep
Authentication	Is MFA enforced for all users, including admins and service accounts where supported?	Screenshot or export of the policy setting
Authorization	Who can export or delete records in bulk?	Permission report reviewed by the data owner
Data protection	Which fields hold the most sensitive data, and how are they protected?	Data classification list
Logging	Are admin and export actions logged and retained?	Log retention setting and a sample query
Integrations	Does every connected app have a named owner?	Integration register
Recovery	When was the last restore test?	Test record with date and result

Prioritize Gaps by Exposure, Not Convenience

When the review turns up problems, resist fixing the easiest ones first. Sort findings by two questions: how likely is this to be exploited, and how much data would be affected? An unprotected admin account with export rights outranks an untidy field naming convention. Quick wins still matter, though, so pair one or two high-impact fixes with a couple of fast ones to show progress and keep momentum.

Common Weak Spots Worth Checking Early

Some issues appear in CRM environments repeatedly. Former employees and contractors keep active accounts. Sales teams share a single export file by email. A trial integration from a past project still holds a broad API token. Report and dashboard sharing settings expose data to an entire organization when only one team needs it. None of these requires advanced attacks to cause harm; they are ordinary gaps that accumulate when nobody owns the review.

A Realistic Example

Imagine a mid-sized services firm whose CRM was set up by a sales operations lead several years ago. A security owner runs the baseline review for the first time and finds three things: two accounts belonging to people who left the company, a connected marketing tool with full read and write access when it only needed to read contacts, and no record of who can export the full customer list. None of these had caused a known incident. The team disables the stale accounts the same day, narrows the integration’s scope with the marketing owner, and adds export permission to a short list of named roles. The review took an afternoon and removed the most obvious routes to a data leak.

Make the Baseline Repeatable

A baseline that is checked once decays quickly, because new users, integrations, and custom objects keep arriving. Schedule a recurring review, tie it to events such as a new integration or a role change, and keep the evidence you collect. Treat the CRM administrator and the security owner as partners: the administrator knows how the system is actually used, and the security owner knows what risk the organization will accept. Document exceptions explicitly, with a reason and an expiry date, so they get revisited instead of forgotten.

Frequently Asked Questions

Is the vendor responsible for securing our CRM? Responsibility is shared. The vendor secures the underlying platform, while your organization is responsible for configuration, user access, connected applications, and how data is used. Read the vendor’s shared responsibility documentation to see where the line sits.

How often should we review the baseline? A regular cadence, such as quarterly, works for many teams, plus a review whenever you add a major integration, change a role structure, or have a security incident. Higher-risk data justifies more frequent checks.

Do small businesses need a formal baseline? Yes, though it can be a one-page document. Smaller teams often have fewer controls and less monitoring, so a short written list of required settings is particularly valuable.

Should we encrypt every field in the CRM? Not necessarily. Encrypting everything can break search, reporting, and integrations. Focus extra protection on the fields that carry the most sensitive information, and confirm what the platform supports before designing around it.

Who should own the CRM security baseline? Ideally a named security or IT owner accountable for the standard, working with the CRM administrator who applies it and a business owner who accepts residual risk. Shared ownership without a named lead usually means nobody acts.

Next Step

Pick the six areas above, assign an owner to each, and complete your first review this month. Record what you find, fix the highest-exposure gap first, and book the next review before you close the document. Requirements and expectations vary by industry and jurisdiction, so involve qualified security and legal professionals where your data or obligations warrant it.