Salesforce security isn't a tooling problem. It's an ownership problem.

The worst Salesforce incidents of the past year walked through doors customers opened on purpose. The fix is a name next to every door.

Last Friday (10/23/26), I joined a panel at Security Dreamin' 2026 with a blunt title: "Do Salesforce Customers Actually Care About Security?" My thanks to Matt Meyers for moderating, and to Pablo Gonzalez and Francis Pindar for a sharp conversation.

My answer is the one I'd give any CIO. Yes, they care. I've sat in a lot of steering committees, and I have never heard an executive say security doesn't matter.

Caring isn't the gap. Ownership is.

The problem nobody owns

Look at how the worst Salesforce incidents of the past year actually worked.

In its September 2025 alert, the FBI described a group that, since October 2024, has phoned employees while posing as IT support. The caller talks the employee into approving a malicious connected app, often a modified version of Salesforce's own Data Loader. The FBI notes that an app approved this way bypasses many traditional defenses, including MFA (FBI, 2025).

The second campaign didn't need a phone call. In August 2025, attackers used OAuth tokens stolen from the Salesloft Drift integration to pull cases, accounts, users, and opportunities out of customer orgs. Then they combed the support cases for passwords and cloud access keys (Google Threat Intelligence Group and Salesloft, 2025).

Read those two again. One person on a bad call opened a door. The other was opened by a project that, by August, nobody was still watching.

This isn't one company getting it wrong. It's structural, and it's everywhere. In most enterprises, Salesforce security falls between three teams. The security team doesn't know Salesforce well. The Salesforce team doesn't own security. And the business owns the data but assumes IT has it covered.

Everyone cares. Nobody owns it.

Where security fits in the framework

In the Master Framework, this lives in the Foundation domain, under the risk management capability. The book defines risk management as identifying and mitigating risks to maintain operational integrity. It has three functions:

• Risk mitigation. Rank what could hurt you most, and fund the top items first.
• Access control. Decide who can see what and do what, then review it on a calendar.
• Business continuity. Know whether sales and service keep working if you have to shut off an app tomorrow.

Why does this belong in the operating model and not just with IT security? Because the failure isn't technical.

Every connected app has a moment of approval. Someone signs off, the integration goes live, the project closes, and the team moves on. The token stays.

The access outlives the decision that granted it. The approval had an owner. The standing access usually doesn't. Attackers don't need to beat your controls. They need to find what nobody has looked at since go-live.

There's a language point here too. Call it security, and executives hear a technical problem for a technical team. Call it risk, and it becomes a business conversation. Boards already know how to talk about risk.

What good looks like

If a company asked me to stand up Salesforce security ownership on Monday, I'd put three things in place. None of them needs a new tool.

• One named owner. A person with the authority to say no and a seat at the security team's table. A committee doesn't count.
• A quarterly access review on the calendar. Who has admin rights. Who holds View All Data or Modify All Data. Who hasn't logged in for 90 days. Book the first review before the meeting ends.
• A connected-app inventory. Every app that holds a token into your org, who approved it, what it can see, and who owns it today. If nobody owns it, it gets reviewed or switched off.

Then change what you measure. Reactive teams count incidents. Proactive teams measure exposure: how many admins, how many unreviewed apps, how long since the last tested restore. Put those numbers in front of executives every month. What gets measured gets owned.

Funding is the step most programs skip. Projects get funded. Platforms don't. In the programs I've seen hold up, a small, fixed share of every approved Salesforce project paid for the foundation work, and they reported the spend back every quarter. Nobody votes on whether to fix the building's elevator. It's part of the maintenance fee.

Finally, plan the first day of an incident before you need it. Executives will want four answers, in this order. Is it contained? What's the scope? Who owns the response? When is the next update? If your logging, app inventory, and runbook don't exist on a normal Tuesday, you won't build them on incident day.

The evidence

The cost of skipping this work is not abstract. IBM's 2025 Cost of a Data Breach Report puts the average US breach at a record $10.22 million (IBM, 2025). Healthcare is again the costliest industry, at $7.42 million per breach, and its breaches took an average of 279 days to identify and contain (IBM, 2025).

I've spent much of my career in healthcare and financial services. In those industries, regulators are watching the clock. Nine months is a long time to not know what's connected to your customer data.

The same report found that 63% of organizations have no AI governance policy (IBM, 2025). That matters for Salesforce, because the next wave of connected apps is AI agents. Every agent is another identity with standing access.

The pattern I've seen across enterprise CRM programs is consistent. When something goes wrong, the first hours go to questions that should already have had answers. What's connected? Who has access? What was exported? Teams that can answer in minutes recover. Teams that can't spend the first week finding out.

Why a universal standard, not your own framework

Every company that takes this seriously writes its own version. Its own access review template. Its own app approval checklist. Its own idea of who owns what.

Multiply that by every Salesforce customer, and you get thousands of private, incompatible answers to the same question. Nobody tallies what that costs. An admin who ran a tight access-review cadence at one company can't prove it at the next. A board can't compare its exposure with a peer's. A partner can't tell a client they're below the bar, because there is no bar.

Attackers, meanwhile, don't care whose template you used. They look for the gaps between them.

A shared standard for access control and risk mitigation doesn't add work. It removes decisions. You stop debating whether a quarterly review is enough, or who should own the app inventory. The standard has settled it, and your auditors, partners, and new hires all read it the same way.

What this means for you

If you lead a CRM organization

Ask one question this week: who owns each connected app in our Salesforce org, by name? If nobody can answer, that's your exposure. Fund closing it the way you fund maintenance.

If you build and run the CoE

You already know where the unreviewed apps are. Turn that knowledge into an inventory with owners and a quarterly review date, and take it to your sponsor. It's the easiest risk conversation you'll ever win.

If you deliver CRM for clients

Every integration you ship creates access that outlives your engagement. Hand over an owner and a review date along with the code. Clients remember the partners who left them safer.

Where to start

If you want to see where your Salesforce program stands on risk management and the other 26 functions of the framework, reach out, and we will work with you to assess your current state. It shows you where you're exposed before someone else finds out.

Customers care. Now make someone own it.

By: Velu Palani