How Do I Know Whether My CRM Data Is Encrypted and Who Can Access It?

October 23, 2026 · 7 min read

To determine whether CRM customer data is protected, verify that the vendor encrypts it both in transit and at rest, then inspect which users, support staff, integrations, and administrators can decrypt or view it. Encryption protects stored and transmitted data, but permissions, multifactor authentication, logging, and export controls determine who can actually reach the readable version.

Is CRM data encrypted at rest and in transit?

CRM data should be encrypted in both places, but you need to confirm the answer in your vendor documentation and configuration rather than assume it. Data at rest is information stored in the CRM platform. Data in transit is information moving between a browser, an API, an integration, or another system.

CISA defines encryption as making sensitive information unreadable unless an authorized party has the key, and recommends protecting sensitive data while stored and while sent across the internet. Customer details, financial records, health or insurance records, employee records, and client data are among the types it identifies for priority protection.

Use the two-location check. Ask the vendor or review its security materials for a direct answer to these two questions: “Is customer data encrypted while it is stored on the platform?” and “Is customer data encrypted while it moves between users, APIs, and connected services?” Then ask what is excluded. A broad claim about encryption is not a configuration review.

For a concrete product example, Salesforce Help states that Shield Platform Encryption field-level encryption and database encryption use symmetric 256-bit AES for data stored on its platform. That describes encryption at rest for those features; it does not replace a review of access rights, integrations, or the fields your organization actually uses.

Can a CRM vendor read my customer data if it is encrypted?

Yes, an authorized vendor user may be able to read customer data through the application even when the underlying stored data is encrypted. Encryption at rest protects the stored form of data; it does not automatically block a person or service that has valid access to the object, record, and field from seeing plaintext through the CRM.

Salesforce says this plainly for its platform: encryption and decryption occur on application servers for user-interface and API access. Its documentation also says support representatives can see encrypted data if they have access to the relevant object, record, and field. The useful question is not merely “Is it encrypted?” It is “Who has a route to the decrypted view?”

Run the access-path review. List the people and systems that can reach sensitive CRM data: regular users, administrators, support access, API integrations, and export-capable roles. For each one, record the business reason, the permissions granted, and whether MFA is required. This turns a vague security promise into a short list an administrator can challenge.

Customer-managed keys can change part of the key-control model. Salesforce documents options in which a customer-controlled key is retrieved from a key service outside Salesforce. That is a key-management capability, not a substitute for permissions. If an authorized application can decrypt data for a permitted user, the user can still read it.

What is the difference between field-level encryption and database encryption in a CRM?

Field-level encryption protects selected values, while database encryption protects the broader transactional database. Use field-level encryption when particular fields carry the most sensitive customer information; use database encryption when the product and your risk assessment call for protection across the transactional data store.

Salesforce describes field-level encryption as an administrator-selected control for supported standard and custom fields. Its documented custom field types include Email, Phone, Text, Text Area, Long Text Area, Rich Text Area, Date, Date/Time, and URL. Database Encryption, by contrast, can encrypt the entire transactional database.

Think in terms of precision versus coverage. Field-level encryption gives you a focused control: identify sensitive fields and protect those values. Database encryption provides wider storage coverage. Neither option is a permission model, so pair either choice with careful object, record, and field access settings.

There is another practical distinction. CISA notes that file encryption can protect document contents while some metadata remains visible. The same discipline applies to CRM planning: define what data is sensitive, where it appears, and what surrounding information remains accessible. Do not label a record “protected” until you have checked its fields, attachments, exports, and connected systems.

Do I need encrypted fields for customer contact information?

Encrypted fields may be appropriate for customer contact information when your risk assessment and CRM capabilities support them, but encryption alone is not the decision. Contact information is personally identifiable information, which CISA lists among data types to prioritize for encryption. The operational answer is to protect the fields and reduce access to only the people who need them.

NIST SP 1800-28, finalized in February 2024, frames confidentiality across data in storage, processing, and transit. It recommends an integrated approach: identify the data, apply access controls, encrypt it, authenticate users, and log activity. That sequence matters because encryption without a role review can leave a large group of authorized users able to view contact details.

Review item	What to verify	Practical administrator action
Data inventory	Which fields contain names, email addresses, phone numbers, and other customer details	Mark the sensitive fields and identify where they are used in records, APIs, and exports.
Encryption scope	Whether the CRM encrypts data at rest and in transit, and whether selected fields can be encrypted	Request the vendor's documented scope and compare it with your marked fields.
Permissions	Who can view each object, record, and field	Remove access that has no current business reason; review administrator and support-access paths separately.
MFA	Whether privileged accounts and sensitive-data users require more than one verification method	Require MFA first for administrators and employees handling sensitive data.
Logging and exports	Whether logins, access, changes, and high-risk activity are recorded and protected	Enable relevant logging, alert on failed logins and privilege escalation, and review who can export data.

The MFA step is not decorative. CISA recommends requiring MFA wherever possible, starting with administrator accounts and employees who handle sensitive data. It also advises checking every remote-access path and privileged account. A strong encrypted-field policy loses value if a compromised administrator account can simply open the record.

Logging closes the loop. CISA explains that logs can record logins, file access, and system changes, including who accessed what, when, and from where. Its guidance calls for protection of logs from unauthorized access or deletion and alerts for high-risk events such as failed login attempts and privilege escalation. Treat logs as the receipt for your access policy, not a technical afterthought.

For privacy obligations, keep the scope honest. GDPR Article 32 identifies encryption and pseudonymisation as measures to consider where appropriate, within security measures proportionate to risk. It also covers confidentiality, integrity, availability, resilience, restoration, and regular evaluation. Encryption helps with the security work; it does not by itself answer every privacy or compliance obligation.

Run this week’s drill: pick one sensitive contact field, trace every role and integration that can read it, confirm whether MFA applies, and locate the log entries that would show access or export activity. If you cannot state the answer in one sentence for each path, the control is not yet operational.

Frequently Asked Questions

How do I restrict sales representatives from viewing sensitive CRM records?

Use role-based access controls to limit access to the objects, records, and fields each sales role needs. Review access at the object, record, and field levels, then use audit logs to confirm that the policy is working and to investigate unusual activity. NIST identifies role-based access controls and logging as part of an integrated confidentiality approach.

What CRM security settings should a small business review first?

Start with MFA for administrator accounts and staff who handle sensitive data, then review roles, privileged accounts, remote-access paths, logging, and export permissions. CISA specifically advises starting MFA with admin accounts and employees who handle sensitive data. Confirm that logs cover logins, file access, and system changes, and protect those logs from deletion or unauthorized access.

Does CRM encryption help with GDPR and other privacy requirements?

Encryption can support privacy obligations, but it is not a complete compliance result by itself. GDPR Article 32 calls for security measures appropriate to risk and identifies pseudonymisation and encryption as measures to consider where appropriate. It also calls for ongoing confidentiality, integrity, availability, resilience, restoration capability, and regular testing and evaluation.

Sources

Written and reviewed by the Find Answers Today Editorial Team. Learn how we create content.