In most enterprises we walk into, Salesforce and cybersecurity belong to different leaders, different vendors and different budget lines. That separation made sense when CRM was a sales tool and security was a perimeter firewall. Neither is true anymore.

Why the wall exists in the first place

The historical reasoning is straightforward. CRM lived under Sales or Customer Success. Security lived under IT or, increasingly, a dedicated CISO. Each grew its own vendor ecosystem, its own consultants, its own KPIs. CRM optimized for revenue velocity; security optimized for risk reduction. The two rarely needed to coordinate because the data flowing through CRM was, frankly, less interesting to attackers than financial systems or core banking.

That changed when CRMs became the system of record for everything — customer identity, financial relationships, sensitive product data, employee performance reviews, partner contracts. Today, a fully populated Salesforce org is among the highest-value targets in any enterprise. Yet the security model around it is often inherited from the era when CRM was sales notes.

Where the bleed shows up

Three patterns repeat across our engagements:

Permissions sprawl. Without security review, profiles, permission sets and sharing rules accumulate. We have audited orgs with 400+ permission sets, most created during one-off project requests. Each is a potential lateral-movement vector. Each also slows down legitimate admins.

Integration blind spots. Custom integrations to ERP, data warehouses or third-party SaaS are typically built by Salesforce delivery teams without security review. We routinely find hardcoded credentials, over-privileged service accounts and unmonitored data egress.

Conversely, security teams that do not understand Salesforce assume the worst, blocking legitimate integrations and adding latency to revenue-critical flows. Both teams build workarounds for the other team. Nobody wins.

What an integrated model looks like

The first move is structural, not technical: a joint architecture review board where the Salesforce architect and the security architect sign off on every integration, permission model change and major release. This board does not need to slow delivery; the right operating cadence is 90 minutes weekly.

The second move is observability. Salesforce Shield event monitoring (or its equivalent in your edition) feeds the SOC SIEM, alongside infrastructure and endpoint logs. SOC playbooks gain Salesforce-specific scenarios: privileged user impersonation, mass exports, API anomaly detection.

The third move is shared incident response. The runbook for a credential compromise involves both teams from minute zero — not as a handoff but as a joint operation. The Salesforce admin knows what data was exposed; the security analyst knows how the breach happened. Together, they contain it.

What it costs to ignore

In one engagement, a regional bank had three Salesforce orgs. Their security team did not know one of them existed — it had been spun up by a marketing team using a corporate credit card. That org contained 80,000 customer records and was integrated with an unmaintained scraper that ran nightly. Detection happened during our discovery phase, not through the SOC.

The cleanup cost more than a year of joint architecture reviews would have cost. The bank now runs a joint review board. They have not found another rogue org since.