Salesforce environments hold the data that drives revenue: customer records, deal pipelines, and proprietary processes. A single configuration error or compromised credential can expose that data, disrupt workflows, and trigger costly regulatory investigations.
Most breaches occur when organizations mismanage their side of the shared responsibility framework. Understanding this division and implementing security at every layer protects data, safeguards revenue continuity, preserves brand trust, and accelerates compliant innovation.
Understanding Shared Responsibility
Salesforce operates on a shared responsibility model that clearly divides security duties. Salesforce handles security of the cloud—global data centers, network infrastructure, patching cycles, and baseline encryption. These controls are audited against certifications like SOC 2 and ISO 27001, giving every customer a hardened platform foundation.
What Salesforce doesn't control is how each organization configures and manages the platform. User provisioning, role hierarchies, permission sets, custom code, integrations, and ongoing monitoring all remain customer responsibilities. Missteps here, like an over-permissive profile, an unmanaged API token, or insecure custom code, are the gaps most frequently exploited by attackers.
For DevOps teams, this model means security considerations must be embedded throughout the deployment pipeline, from static code analysis before pushing Apex to automated compliance checks and secure backup strategies that protect both metadata and records.
Foundational Platform Security
Salesforce's infrastructure security creates the foundation for the other controls. The platform maintains enterprise-grade protections: physically secured data centers, network segmentation between tenants, real-time intrusion detection, and encrypted communications using TLS 1.3 by default.
The platform follows a secure development lifecycle with built-in code reviews, static analysis, and regular penetration testing. When vulnerabilities emerge, Salesforce patches all production instances simultaneously, eliminating the exposure windows common in on-premise systems. Data at rest is protected by disk-level encryption, with Shield customers gaining additional field-level encryption using customer-controlled keys.
Independent audits verify these controls through SOC 2 Type II, ISO 27001, and FedRAMP authorizations—certifications that reduce compliance burden for enterprise customers.
While this hardened foundation provides essential protection, platform security alone cannot prevent data exposure through misconfiguration or privilege misuse. Organizations must focus on the critical handoff point where infrastructure meets administrative decisions.
Access Control
Access control represents the handshake where platform infrastructure meets daily administrative decisions. This layer is critical because it determines not just who can enter your Salesforce org, but what they can do once inside. The combination of increasingly sophisticated phishing attacks and the trend toward remote work has made traditional username/password authentication insufficient, while poorly designed permission structures often grant far more access than users actually need for their roles. When access controls fail, the blast radius extends beyond data exposure to include workflow disruption, compliance violations, and the potential for attackers to establish persistent access through elevated privileges.
While Salesforce provides the authentication mechanisms—login flows, roles, profiles, permission sets—determining who can authenticate and what they can do once inside the org falls entirely within administrative control.
Strong Authentication
Multi-factor authentication now serves as the baseline requirement. Combine this with single sign-on integration to consolidate credentials under corporate policies while reducing password fatigue. When users can move seamlessly between systems without multiple authentication prompts, security improves without sacrificing user experience.
Principle of Least Privilege
Start with carefully crafted profiles that set baseline object, field, and system permissions. Resist the temptation to grant broad access "just in case." Use role hierarchies to cascade access upward only where business needs truly require it, and layer additional rights through permission sets rather than creating new profiles.
DevOps-Specific Controls
Service accounts used by CI/CD tools deserve special attention. Create dedicated profiles with API-only access and no interactive login privileges. This protects production data if pipeline credentials are ever exposed. Separate sandboxes should maintain different permission boundaries, allowing developers to test freely without risking over-privileged access.
Implementation Example: Create a "CI/CD Deployment" profile with these specific permissions:
- API Enabled: ✓
- Interactive Login: ✗
- Deploy Change Sets: ✓
- Modify All Data: ✗
- View Setup: ✓ (read-only)
Then authenticate using JWT bearer flow: sf auth jwt grant --username cicd@company.com --jwtkeyfile server.key
Data Protection
Strong access controls provide the foundation, but they mean nothing if the day-to-day configuration settings that govern data access are too permissive. This layer is where most data breaches actually occur—not through sophisticated hacking, but through organizations inadvertently exposing sensitive records through overly broad sharing rules, missing field-level security, or insecure configurations.
The complexity of Salesforce's permission model means that small configuration changes can have far-reaching consequences, potentially exposing customer data, financial information, or proprietary business processes to users who have no legitimate need to see them. Configuration drift over time compounds this risk, as permissions accumulate and expand without regular review, creating a growing attack surface that often goes unnoticed until a security incident occurs.
This layer transforms baseline settings into practical controls that protect individual records, fields, and data flows. It governs how data flows through the system—from organization-wide defaults that set the starting point for record access, to field-level security that protects sensitive information, to encryption that secures data at rest and in transit.
Organization-Wide Defaults and Sharing
Set organization-wide defaults (OWD) restrictively—mark objects like Cases or Opportunities as Private, then open access only where collaboration is required. Since every subsequent rule is additive, a restrictive baseline lets you grant access deliberately through role hierarchy and sharing rules.
Field-Level Protection
Field-level security prevents data leakage regardless of page layout configurations. This hides sensitive information—salary, health records, personally identifiable data—from users who don't explicitly need it. Combine this with object permissions to implement true least-privilege access. Permission sets refine this model further—a finance analyst maintains a conservative profile but receives temporary sets for quarter-end forecasting access.
Encryption and Advanced Protection
Shield Platform Encryption adds another protection layer for regulated fields, with customers gaining additional field-level encryption using customer-controlled keys. Event Monitoring and regular audits of login history reveal suspicious behavior before it escalates.
Development Security
Every line of custom code and every integration point represents a potential security vulnerability. This layer focuses on securing the custom development that extends Salesforce functionality, from Apex classes and Lightning Web Components to external integrations and API connections. The challenge is that developers often prioritize functionality over security, especially under tight deadlines, creating vulnerabilities that bypass even the most carefully configured platform security controls.
Custom Development Security
Every line of Apex, Lightning Web Components, and integration code must validate inputs, use parameterized queries, and enforce sharing rules. Implement peer reviews and automated security scans in CI/CD pipelines to catch SOQL injection or insecure CRUD operations before they reach production.
Implementation Example: Always use proper sharing enforcement in Apex:
// ❌ Bypasses sharing rules
public without sharing class UnsafeAccountQuery {
// ✅ Enforces sharing rules
public with sharing class SafeAccountQuery {
public List<Account> getAccounts(String accountType) {
return [SELECT Id, Name FROM Account WHERE Type = :accountType];
}
}
Integration Security
Connected apps should request only necessary OAuth scopes and rely on short-lived JWT bearer flows when possible. Store client secrets in encrypted vaults, enable IP restrictions, and apply API rate limits to prevent bulk-extraction attacks. Monitor event logs for anomalous call patterns.
Governance & Monitoring
Governance and monitoring transforms theoretical controls into day-to-day protection, but its importance extends far beyond monitoring—it's about maintaining security posture over time as your org evolves. Without continuous oversight, even the most carefully configured security controls degrade through normal business operations: users request additional access for projects, developers push emergency fixes that bypass normal review, and integrations accumulate permissions over time. The challenge is that security incidents rarely announce themselves clearly—they often appear as subtle anomalies in login patterns, unusual API usage, or unexpected configuration changes that only become obvious in retrospect. Organizations that lack robust governance practices typically discover breaches weeks or months after they occur, when the damage is already extensive and regulatory consequences are unavoidable.
This layer encompasses continuous monitoring, disciplined change management, and incident response capabilities. It watches for suspicious activity through event logs and login patterns, ensures that changes follow proper approval workflows, and provides the processes to respond quickly when security incidents occur.
Continuous Monitoring
Native Event Monitoring streams every login, API call, and data export, while Setup Audit Trail captures configuration changes. Combine these with Login History reports to spot impossible access patterns. Run Security Health Check periodically to quantify configuration risk and identify quick improvements.
Implementation Example: Set up automated alerts for suspicious activity:
-- Query Event Monitoring for impossible travel
SELECT UserId, LoginTime, SourceIp, LoginGeoId
FROM LoginEvent
WHERE LoginTime = LAST_N_DAYS:1
AND UserId IN (SELECT Id FROM User WHERE Profile.Name LIKE '%Admin%')
ORDER BY UserId, LoginTime
Alert when the same admin user logs in from different countries within 4 hours.
Change Management
Every release should move through approval workflows that separate who builds from who deploys. Track metadata modifications with version control and reconcile against Setup Audit Trail to surface undocumented changes. When emergency fixes are unavoidable, document the rationale and schedule retrospective reviews.
Incident Response
Draft escalation playbooks that define detection thresholds, communication channels, and decision ownership. Include rapid log preservation, impact analysis across environments, and tested rollback plans that restore both data and metadata. Include Salesforce Support in the contact matrix and rehearse the full cycle regularly.
By pairing real-time visibility with controlled change and rehearsed recovery, governance and monitoring keeps daily administration predictable and audit-ready. This same rigor must now follow every automated deployment, where modern DevOps practices can either strengthen or undermine these carefully constructed defenses.
Compliance and Risk Management
Salesforce's platform certifications (SOC 2, ISO 27001, FedRAMP) provide the foundation, but specific regulatory requirements demand additional controls:
- SOX: Field Audit Trail and granular permission reviews support traceable change control
- GDPR: Individual objects, automated deletion flows, and field-level security enable data minimization and consent tracking
- HIPAA/PCI-DSS: Shield encryption, strict access controls, and verifiable audit logs meet healthcare and payment requirements
- Data Residency: Shield Platform Encryption with Bring-Your-Own-Key keeps regulated data within approved jurisdictions
Comprehensive documentation drives successful audits. Setup Audit Trail, event logs, and Field Audit Trail create tamper-proof records. DevOps pipelines that automatically export these artifacts and archive backups provide auditors with a single source of truth.
Security as Strategic Advantage
When security controls integrate properly into development workflows, they foster customer trust, ensure regulatory compliance, and build operational resilience without sacrificing development velocity.
The most effective approaches combine automated security validations embedded within deployment pipelines, comprehensive audit trails that simplify compliance reporting, secure backup and recovery protocols that guard against data loss, and change management processes that uphold security while enabling agility.
Modern DevOps platforms play a crucial role in maintaining this balance. By embedding security controls directly into the development lifecycle, organizations can achieve both airtight protection and the rapid innovation cycles modern business demands.
Ready to implement a security strategy that accelerates rather than constrains your Salesforce development? Learn how Flosum's DevOps platform helps organizations maintain the highest security standards while delivering reliable, rapid innovations.
