However, that same level of preparation may not extend to SaaS platforms like Salesforce, where investigation and recovery require different capabilities and expertise. It defines escalation paths, notification timelines, and recovery procedures – which is great.
What it may not address in sufficient detail, is Salesforce.
That omission matters more than you first realize. When something goes wrong in a Salesforce org, such as a significant data loss event, a compromised account, or a destructive integration failure, the general-purpose IR playbook fails to clearly define what happens next. The forensic questions are different, as are the recovery mechanisms and timelines; the organizations that find this out mid-incident may face delays in investigation and recovery.
The IR plan that stops at the perimeter
Enterprise incident response has matured considerably over the past decade. Most large organizations now have defined playbooks for endpoint compromise, network intrusion, and cloud infrastructure incidents. Security teams are also practiced at isolating affected systems, preserving evidence, notifying stakeholders, and working through structured recovery steps.
However, SaaS platforms like Salesforce sit largely outside that muscle memory. They are not directly monitored by endpoint detection tools, and traditional network visibility provides limited insight into activities within the platform. Some traditional forensic techniques, such as disk imaging and memory capture, are not directly applicable to SaaS environments like Salesforce.
However, log collection, correlation, and investigation remain essential. The challenge is ensuring that the necessary Salesforce telemetry is available, retained, and integrated into existing security monitoring and incident response workflows. Plus, the people who know Salesforce best – admins, RevOps teams, and business users – are rarely the ones running incident response.
The result is that when a Salesforce incident occurs, organizations often have to improvise: working out who needs to be involved, where the evidence is, what recovery options exist, and who has the authority to act. This has to be done at the same time, under pressure, across a platform where some of those options have expiry windows measured in days.
“The challenge during a Salesforce incident is often not knowing what needs to be done, but knowing who can do it, what evidence is available, and how to contain the problem without disrupting critical business processes. Those are decisions organizations should not be making for the first time during an incident,” says Karmina Aquino, Head of Threat Intelligence at Cloud Protection by WithSecure.
The audit trail problem revisited
Effective incident response depends on being able to answer a core question: exactly what happened? In Salesforce, that question is harder to answer than it should be.
The platform’s native audit capabilities – event logs, field history tracking, and login history – provide partial coverage, but there are significant gaps:
- Event log availability and retention vary by Salesforce edition, subscription and configuration. Organizations need to verify which events are captured and whether their retention periods are sufficient for investigation.
- Field-level history tracking requires manual configuration per object and doesn’t capture everything
- Setup audit trail covers configuration changes but not data changes
These capabilities provide valuable evidence for security investigations, but their coverage depends on configuration, licensing, and retention settings. They may not capture every action or provide sufficient context to reconstruct a complex incident. Operational events are often captured, but not the complete provenance trail that an investigation requires.
By the time an organization realizes something has gone wrong, the window for native log-based forensics may already be closing. Reconstructing what happened from incomplete native logs is a slow, labor-intensive process that extends every other part of the incident timeline.
What recovery-ready actually looks like
Recovery readiness for Salesforce is not a single capability. It requires three complementary capabilities that organizations should establish and test before an incident occurs.
Together, they help organizations investigate what happened, contain the impact, restore affected data and operations, and verify that recovery has been successful.
Restoring data is only part of recovery, though. After an incident such as an account compromise, restoring data alone does not address the underlying compromise, so recovery must also remove the attacker’s access and confirm it has ended.
The first is reliable backup with granular restore. This goes beyond periodic exports towards maintaining recoverable copies of critical Salesforce data, including records, relationships, metadata, and configuration. It enables organizations to restore affected data following incidents such as accidental deletion, malicious changes or destructive integration failures. Regular testing helps establish what can be restored, how quickly, and whether recovery time objectives can be met.
The second is audit trail coverage that goes beyond what Salesforce provides natively: the sufficient logging of data access, changes, and user activity, retained long enough to support investigation and recovery. This helps organizations reconstruct what happened, identify affected records and accounts, and determine the scope of an incident, including compromised accounts or unexpected integration activity.
The third is a tested, Salesforce-specific response process: a defined set of steps, roles, and decision points that the right people can execute without having to work it out under pressure. This includes knowing who owns recovery decisions, how to contain compromised accounts or integrations, when and how to restore affected data, and how to verify that normal operations can safely resume.
In terms of a compromised account, it also covers:
- The revoking of active sessions
- Resetting credentials
- Removing malicious connected apps
- Investigating what data was accessed
- Verifying that unauthorized access has ended
It also defines how the Salesforce-specific response connects to the broader organizational incident response process.
“Recovery readiness should be demonstrated, not assumed. Organizations need to test realistic scenarios: can they identify affected records, trace suspicious activity, contain a compromised integration and restore data without losing legitimate changes? These exercises reveal gaps that a written recovery plan alone cannot,” Aquino points out.
The takeaway
Recovery readiness is developed before an incident and demonstrated during response and recovery. The organizations that recover from Salesforce incidents quickly are the ones that have:
- The right tooling in place
- A defined list of who owns what
- The ability to test their restore procedures before they need them
The three pillars above – continuous backup, meaningful audit coverage, and a practiced Salesforce-specific process – require deliberate planning, clear ownership, and regular testing, particularly in organizations where Salesforce supports critical business processes and integrations.
That decision is straightforward when everything is running smoothly. It becomes considerably harder as soon as records are missing, logs are expiring, and the pressure is on.
Recovery readiness has one real test: not whether a plan exists in theory, but whether it would hold up under the pressure of an actual incident. Most organizations only get that answer after the fact. The ones who know before made it their business to find out.