The First 24 Hours After a Salesforce Breach: An Admin’s Response Plan

If you administer Salesforce, you are probably the person who gets the call when something looks wrong in your org, even though nobody ever printed security lead on your badge. You know your permission sets and your connected apps better than anyone in the building, but nobody handed you a breach playbook written for the platform. This is that playbook. What follows is an hour-by-hour response plan written for admins, plus a quick readiness checklist you can run against your own org today.

You will not do all of it alone, because a real incident pulls in security, legal, and leadership, but you are the one who knows where everything lives, so you are the one who needs the map. I have spent nineteen years in the Salesforce ecosystem, and these are the moves I want you to have ready before you need them, drawn from the questions admins bring to Salesforce Security Office Hours.

The threat landscape

The ShinyHunters campaign against the Salesforce ecosystem is still running, and researchers now count more than 1,000 organizations compromised across its waves. Allianz Life is one of them, where attackers used social engineering against a trusted CRM connection in July 2025 to reach the data of roughly 1.4 million people. Almost none of these breaches involved a Salesforce vulnerability. They came through trusted integrations, forgotten OAuth tokens, and settings nobody revisited after go-live, so the same gaps likely exist in your org right now. The damage also outlasts the incident, since 70 percent of consumers say they would stop buying from a brand after a breach.

What you control is speed. IBM’s 2025 Cost of a Data Breach report put the average breach lifecycle at 241 days and found a tested incident response plan to be the single biggest cost reducer, saving an average of $2.66 million. Detection is rarely the problem. The response is. Here is that response hour by hour, and there is a video version your team can watch and share.

The first 24 hours at a glance

• In the first hour, you will want to confirm the breach in Login History and the Setup Audit Trail, then map the blast radius across users, scopes, records, and metadata.
• From hours two to six, you will want to expire all sessions and revoke OAuth tokens separately, because a password reset does not revoke a token, then tighten logins, freeze compromised users, and start the escalation tree.
• From hours six to twenty-four, you will want to remove malicious metadata, restore from a verified backup, reconcile integration IDs, and document the root cause so the same breach cannot happen twice.
• A readiness checklist further down lets you gut-check your org, and if you cannot answer yes to every question, you are not ready for the first twenty-four hours.
• Most of the 241-day breach lifecycle is lost after detection, when nobody owns the follow-through, and that accountability gap is the one Argus by EzProtect closes.

Hour 1: Detection and assessment

The first hour has two jobs, and you will want to run them together. The first is confirming the breach. Start in the tools your org actually has, because Setup Audit Trail records configuration changes and Login History keeps six months of logins with IP addresses and geolocation, and both are standard in every org. If you license Salesforce Shield or the Event Monitoring add-on, you also get real-time event monitoring and Transaction Security, which can alert on API anomalies and unusual record volumes. If you do not, you work the standard signals you have, and you recognize that their shorter retention makes speed matter even more. You will also want to open OAuth usage in Setup, which shows every app connecting to your org whether it is installed or not, and confirm who actually published each one, because a rogue app posing as a trusted vendor is a common way in.

The second job is assessing the blast radius. You will want to map every user who authorized the suspect app and the scopes they granted, identify which objects, business units, and customer records were exposed, determine whether any metadata was altered, including Apex classes, flows, permission sets, and remote site settings, and document which integrations touched the affected data. The difference between what was exposed and what could have been exposed separates a measured response from a panic. Before you change anything, capture the current state, because the records you preserve now become the evidence you will need later.

Hours 2 to 6: Containment

Containment is where most teams lose the thread, so you will want to move in a deliberate order. Expire all passwords and active sessions org-wide through Session Settings first, because that is the broadest single lever you hold. Then treat OAuth tokens as separate work, because resetting a password is not the same as revoking a token. The fastest way to cut off an abused integration at scale is to set its refresh token policy to expire immediately, and you use the user’s detail page or the OAuth Connected Apps Usage page for targeted revocation. One note for 2026: as of the Spring ’26 release Salesforce no longer creates new connected apps by default and points you toward External Client Apps, so your inventory now spans both.

Next you will want to tighten where logins can come from. By default Salesforce checks a user’s IP address only at login, yet many attacks happen after the session is established. Under Session Settings you can enable Enforce login IP ranges on every request so the check runs on each request rather than once at sign-in. This adds overhead and can produce unexpected results with some integrations, so test it in a sandbox before you roll it out. You will also want to freeze or deactivate the compromised users, and to remember that deactivation stops new sessions while an already issued access token can keep working until it expires, so you revoke tokens and expire sessions as well. Then disable suspect apps and check for rogue scheduled Apex jobs and unfamiliar integrations.

One token in one org is never the whole job. Investigators saw unauthorized API activity continue even after the original Drift tokens were revoked, because the attackers had already harvested additional tokens and were reusing them across environments with no failed logins and no anomalies. Your containment has to cover every org and every sandbox. While the technical work runs, you will want to activate your escalation tree, because leadership, legal, your insurer, and the authorities each need a defined contact path before the 2 a.m. call. The regulatory clock is already running, since GDPR gives you seventy-two hours from the moment you confirm the breach and NIS2 gives essential entities twenty-four.

Hours 6 to 24: Eradicate, recover, and learn

With the bleeding stopped, eradication removes what the attacker left behind. You will want to scan for malicious Apex, rogue batch jobs, and unauthorized metadata deployments, audit remote site settings and named credentials for redirected endpoints, review permission sets and profiles for privileges that were silently escalated, and check your logs for unusual data exports. Metadata is the quiet trap, because changes to Apex, flows, or permission sets outlast any data restore. The risk climbs when you remember that an attacker with administrative access can misuse functionality every org already has, including the Apex Crypto class, without any premium license.

Recovery restores the data and reconnects the business. You will want to restore from your most recent verified backup, reconcile the restored record IDs with every external integration, verify that no bank routing numbers, PII fields, or financial data were silently altered, and re-sync the integration data deltas for the gap between your backup point and the restore. Plan that reconciliation in advance, because hard-deleted records restored from backup receive new Salesforce IDs, which breaks every external system that referenced the originals.

Learning is the work stream teams abandon once the pressure lifts, and skipping it is how the same breach happens twice. You will want to document the root cause, the attack vector, the timeline, and the response, then validate the fix by testing users and simulating the original vector to confirm the door is closed. This is also when you harden how integrations connect. API access control on your apps restricts which ones can reach your org, though it needs testing because it is not viable for every integration, and a dedicated integration user for each connection limits the damage if one is compromised. Finish by setting token rotation policies, assigning an owner to your app inventory, and scheduling breach drills so the team practices quarterly.

Your 24-hour readiness checklist

Run this gut-check with your team this week, and answer honestly.

• Do you have a named Salesforce breach response owner and a working escalation tree?
• Can you revoke all OAuth tokens and expire all sessions within one hour?
• Do you have a verified, tested backup you could restore from today?
• Is every connected app and external client app inventoried with an assigned owner?
• Does your cyber insurance policy cover a third-party connected app compromise?
• Have you tested your breach response plan in the last ninety days?
• Are you actively monitoring Login History and the Setup Audit Trail?

If you cannot answer yes to every one of these, your org is not ready for the first twenty-four hours.

What most orgs miss

Every step above depends on one thing no tool guarantees, which is a person doing each task properly, in order, and proving they did it. That is exactly where real incidents fall apart, and not because anyone is careless. The admin gets pulled into a release. The security lead sits in back-to-back meetings. The compliance officer means to make the regulatory determination and gets buried. The incident quietly stops being worked, someone closes it weeks later with no evidence, and everyone moves on until an auditor asks for proof or the same threat returns. This is why the 241-day figure is dominated by the response gap rather than detection latency. The detection happened, but the follow-through did not.

Argus by EzProtect closes the gap

Argus by EzProtect is the accountability layer for exactly this gap, and it protects your Salesforce environment by driving every incident through the full NIST incident response lifecycle, from identification and containment through eradication, recovery, and lessons learned. At least two named people sign off on every milestone, the approver can never be the author, evidence is required rather than optional, phases run in order, and every action lands on an immutable, timestamped record that cannot be edited or deleted. The human stays in charge throughout, because Argus surfaces gaps and suggestions against each milestone’s instructions while the named owner validates the evidence and signs off the work. Argus also checks every connected environment for the same threat before an incident can close, so one contained org does not leave the rest exposed. It consumes detections from EzProtect, which scans files and URLs across your Salesforce fields and objects, so EzProtect catches what enters your org and Argus owns what happens once a threat is in front of you.

If you want to know where your org stands before an incident forces the question, you can book a free Salesforce security assessment and find the gaps in a planning session rather than during the first twenty-four hours of a live breach.

---

Frequently asked questions

Does resetting a Salesforce user’s password revoke their OAuth tokens? No, and treating it as if it does is the most common containment mistake I see. A refresh token stays valid until it is explicitly revoked, so you revoke from the user’s detail page, from the OAuth Connected Apps Usage page, or by setting the connected app’s refresh token policy to expire immediately. Password changes and token revocation are separate actions, and the breach exploits the gap whenever a team assumes one covers the other.

We already have a SIEM. Why would we need Argus by EzProtect? A SIEM detects, correlates, and alerts, and once it opens a ticket its job is done. Argus by EzProtect picks up where that ticket stops, driving the response through the NIST lifecycle with named owners, required evidence, and an immutable record, so it complements your SIEM rather than replacing it. Detection tells you something is wrong, and Argus makes sure the right person fixes it and can prove they did.

My team runs Salesforce but is not a security team. Can we still respond to a breach? Yes, and you are the rule rather than the exception, because most Salesforce teams were never trained on incident response frameworks. That gap is what Argus by EzProtect is built to fill, since it assigns role-specific tasks and named accountability at each step so your admins do not have to become NIST experts overnight. EzProtect handles the detection side by scanning files and URLs, so the two together cover what enters your org and what happens next.

What can we monitor if we do not have Salesforce Shield? You still have real visibility. Setup Audit Trail tracks configuration changes and Login History keeps six months of logins with IP addresses and geolocation, and both are standard in every org. Shield and the Event Monitoring add-on extend that with real-time events and Transaction Security, and EzProtect’s file and URL scanning adds a detection layer across your fields and objects that works whether or not you license Shield.

How do we prove to an auditor that we handled an incident correctly? You prove it with evidence created during the work rather than reconstructed afterward. Argus by EzProtect locks every milestone and its evidence into a timestamped record at the moment of approval, one that cannot be edited or deleted, so you hand an auditor or regulator a single report showing what was done, when, by whom, and with what proof. If you want to see where your own org stands before an incident forces that question, you can book a free Salesforce security assessment.