Understanding Data Security in Salesforce

---

October 6, 2025

---

Introduction

What is Data Security?

• In today’s world, data is very valuable.
• Businesses depend on information about customers, partners, employees, and processes.
• If this information falls into the wrong hands, it can cause:
  • Reputational damage
  • Legal issues
  • Financial losses

That’s why Salesforce — a leader in CRM — offers various measures to protect data security.
Salesforce Data Security ensures that:

• Sensitive information is protected from unwanted access.
• Users can only see the data intended for them.
• Admins control how, when, and where data can be accessed.

Why Salesforce Needs a Security Model

• Unlike traditional databases, Salesforce is multi-tenant (different companies share the same platform).
• Therefore, Salesforce developed a security model to:
  • Protect each organization’s data.
  • Still allow flexible sharing within the company.

Why do we need Data Security in Salesforce?

• To prevent unauthorized access to customer information.
• To comply with regulations like GDPR, HIPAA, and CCPA.
• To reduce the risks of data leaks, insider threats, and cyberattacks.
• To balance business efficiency with data confidentiality.

Security Layers in Salesforce

Salesforce security operates like a four-layer defense system:

1. Organization-Level Security → Who can log in, where from, and when.
2. Object-Level Security → Access to entire objects (Account, Contact, Opportunity, etc.).
3. Field-Level Security → Control visibility/edit rights for specific fields.
4. Record-Level Security → Control access to individual records.

Analogy

• Data = Stored in a house
• Organization Security = Community gate
• Object Security = Main door of the house
• Field Security = Locks on cupboards
• Record Security = Which items in those cupboards you can see or touch

Organization Level Security

First line of defense — ensures that only trustworthy users can log in.
Key Features:

• Login IP Ranges → Restrict access to trusted IPs or corporate networks.
  • Example: A bank allows employees to log in only from its corporate VPN.
• Login Hours → Limit login times.
  • Example: Sales reps log in from 8 AM to 7 PM, but not at midnight.
• Two-Factor Authentication (MFA) → Extra verification (OTP, mobile app approval).
• Password Policies → Enforce password strength, expiry, and login attempts.
• Session Settings → Manage inactivity timeout, simultaneous sessions, and IP session security.

Real-world Example:

• A healthcare company enforces MFA + IP restrictions.
• Doctors can access Salesforce from the hospital but not from home Wi-Fi.

Object Level Security

Controls who can access entire objects (Account, Contact, Opportunity, or custom objects).

Managed through:

• Profiles
• Permission Sets

Available Permissions:

• Read → View records.
• Create → Insert records.
• Edit → Modify records.
• Delete → Remove records.

Examples:

• HR users → Access Employee object, but not Opportunity object.
• Sales reps → Access Accounts & Opportunities, but not HR records.

Best Practice:

• Avoid granting unnecessary Delete permissions.

Field Level Security

Controls access to specific fields within an object.

• A user may access a record but not sensitive fields.

Managed through:

• Profiles
• Permission Sets

Examples:

• Sales team → Can see Account Name, Industry, Phone.
• Sales team → Cannot see Annual Revenue.
• HR → Can see Employee Salary field.
• IT users → Cannot see Salary.

Why Important?

• Even if a record is visible, confidential fields (e.g., SSN) must remain hidden.

Record Level Security

Determines which individual records users can view once they have object access.

Methods:

• Organization-Wide Defaults (OWD): Set baseline access → Private, Public Read Only, Public Read/Write.
• Role Hierarchy: Higher roles inherit visibility from lower ones.
• Sharing Rules: Grant access based on record ownership or criteria.
• Manual Sharing: Record owner shares access with specific users.
• Teams (Account Teams, Opportunity Teams): Enable collaborative access.

Example:

• OWD = Private → Each sales rep sees only their own opportunities.
• Sales Manager → Can view all opportunities for their team.
• Sharing Rule → Indian sales team gets all accounts with billing country = India.

Best Practice:

• Keep OWD = Private, then open access where necessary.

Example Scenarios

• Restrict employees to log in only from the office (Login IP Ranges).
• Hide the Salary field from most users but allow HR (Field Level Security).
• Allow managers to view their team’s opportunities (Role Hierarchy).
• Make Accounts visible to everyone but keep Opportunities private (OWD).
• Give external partners access only to specific records (Partner Community Sharing).

Data Security Tools & Features in Salesforce

Beyond the 4 layers, Salesforce provides additional tools:

• Profiles → Define baseline access.
• Permission Sets → Grant extra access without changing profile.
• Roles → Hierarchical visibility model.
• OWD → Baseline record sharing model.
• Audit Trail → Track configuration changes (last 6 months).
• Login History → Monitor failed logins.
• Shield Platform Encryption → Encrypt sensitive fields (SSN, credit card).
• Event Monitoring → Track activities (API calls, data exports).
• Field Audit Trail → Keep historical field values.
• MFA (Multi-Factor Authentication) → Adds extra login security.

Salesforce Shield

For companies handling very sensitive data.

Features:

• Shield Platform Encryption → Protects data at rest and in transit.
• Event Monitoring → Logs detailed user activities (exports, logins, etc.).
• Field Audit Trail → Retains field history up to 10 years (vs. standard 18 months).

Example:

• A healthcare company encrypts patient medical records with Shield to comply with HIPAA.

Best Practices for Data Security

• Always follow Least Privilege Principle (minimum access).
• Use Permission Sets instead of too many Profiles.
• Enable MFA for all users.
• Encrypt sensitive fields with Shield.
• Avoid using View All Data & Modify All Data except for admins.
• Conduct quarterly audits of user access.
• Use WITH SECURITY_ENFORCED in Apex SOQL.
• Test access with dummy users.
• Keep OWD = Private → selectively open access.
• Monitor Login History for suspicious activity.

Common Pitfalls & Tips

• Don’t rely on page layouts to hide fields → Use Field-Level Security.
• Don’t give everyone System Admin
• Don’t forget Community/Partner users → Apply same rules.
• Don’t leave inactive users undeactivated.
• Don’t clone SysAdmin profiles unnecessarily.
• Use criteria-based sharing for flexibility.
• Train end-users on data security awareness.

SOQL and Security Enforcement

Even with SOQL queries in Apex → Security is enforced.

With SECURITY_ENFORCED:

SELECT Name, Salary__c

FROM Employee__c

WITH SECURITY_ENFORCED

• If user lacks access to Salary__c, query throws an error.
• Prevents unauthorized field exposure.

Real-World Case Study

Scenario: Financial Services Company

• OWD for Account = Private.
• Role Hierarchy = Regional Managers → Sales Managers → Sales Reps.
• Sharing Rule → Banking sector accounts shared with Finance team.
• Field Security → Credit Score field hidden from Sales Reps.
• Shield Encryption → SSN field encrypted.
• Event Monitoring → Tracks large data exports.

Result:

• Data remains secure.
• Employees get only the info they need.

Do’s vs Don’ts

Conclusion

• Data security in Salesforce is not just a feature — it’s a responsibility.
• Businesses deal with highly confidential data; even a small lapse can cause severe damage.
• By combining Organization, Object, Field, and Record-Level Security, admins can build a secure yet flexible system.
• Advanced tools like Shield, MFA, Event Monitoring make it stronger.
• Following best practices, regular audits, and user education ensures Salesforce remains trusted, compliant, and secure.

nsiQ