Salesforce Event Monitoring for security investigations: which events matter

When a Salesforce org is suspected of a compromise, the first question is always the same: what did this user, session or integration actually do? The answer lives in Event Monitoring, and how much of it you can reconstruct depends on decisions made months earlier: which licence you hold, which event types you kept, and whether anyone copied the logs out before they expired. This post covers the event types that matter in an investigation, what the base logs give you compared with the add-on, how retention works, and what is worth alerting on before you need it.

#Two tiers of event log files

Event Monitoring data comes mainly from the EventLogFile object: one CSV-style log per event type per period, queryable through the API. According to Salesforce's Event Monitoring basics on Trailhead, there are two very different levels of access.

The included tier tells you that someone logged in. It does not tell you what they did afterwards. For an investigation into data theft you need the add-on, and you need to have had it switched on before the incident: logs are not generated retroactively.

Real-Time Event Monitoring and Threat Detection are separate again. They stream events as they happen and can feed Transaction Security Policies that block an action or demand extra verification. They need additional licensing on top of the base add-on, so confirm what your contract includes before you design alerts around them.

#The event types that matter in an investigation

Most investigations follow the same arc: how did the actor get in, what did they look at, and what did they take. These event types answer those three questions.

#Getting in

• Login and Login As: who authenticated, from which IP address, with which client and login type. Login As shows an administrator impersonating another user, which is easy to overlook.
• Logout: useful for working out session length. A session that never logs out and keeps making API calls is a token, not a person.

Pair these with Login History (kept for six months in Setup) and the Setup Audit Trail (180 days) for the wider picture.

#Looking around

• URI and Lightning Page View: which record and list pages a user opened, in Salesforce Classic and Lightning Experience respectively.
• List View: which list views ran. Bulk browsing of contacts or accounts often shows up here first.
• Report: which reports ran. A user who suddenly runs reports they have never touched is a classic early signal.

#Taking data

• Report Export: a report was exported. This is the single most important event type for insider-risk cases.
• API, REST API, Bulk API and Bulk API 2.0: programmatic access. The large Salesforce data thefts of 2025 went through API clients and connected apps, not through the browser, so these are where volume shows up.
• Content Transfer: files downloaded or previewed.

Many event types carry a session key and a login key. Use them to stitch a login to everything that session did, rather than correlating on user and time alone.

#Getting the logs out

Pull the log list with the Salesforce CLI, then download each file from its LogFile field:

sf data query --target-org prod \
  --query "SELECT Id, EventType, LogDate, Interval, LogFileLength FROM EventLogFile WHERE EventType = 'ReportExport' ORDER BY LogDate DESC"

The file body is served at /services/data/vXX.X/sobjects/EventLogFile/<Id>/LogFile on your instance. Interval tells you whether a row is a daily or an hourly log.

Because history is capped at 30 days even with the add-on, the most important operational control is boring: copy every log file out every day, into storage you control, with retention that matches your investigation and regulatory needs. An incident discovered on day 40 with no copy has no Event Monitoring evidence at all.

#What to alert on

Alerts should target behaviour that is rare for legitimate users and common in real incidents. A practical starting list:

1. Large or unusual exports. A Report Export outside business hours, a Bulk API job that pulled tens of thousands of rows, or a user exporting far more often than their own baseline.
2. Login anomalies. A burst of failed logins for one user, successful logins from two distant IP addresses minutes apart, or one session seen from more than one IP address.
3. API volume spikes. Thousands of API requests from a single user or integration in a short window, especially from an integration that is normally quiet.
4. Guest user activity. A site guest user touching more than a handful of records. Guest users should almost never read data in volume.
5. Grant then export. A permission or role grant in the Setup Audit Trail followed shortly by a large export from the same user. Either event alone is routine; together they are the shape of privilege abuse.

Expect noise from scheduled data loads and integrations. Name them, and suppress them by user, not by event type.

#Scoring the logs offline

Vulkro for Salesforce runs a set of Event Monitoring rules over these logs on your own machine. Against a live org with the Event Monitoring add-on:

vulkro-sf org event-monitoring --target-org prod --since-days 30

Or against an export already on disk, which also works for an org you can no longer log in to:

vulkro-sf logs analyze --input eventlogs.csv \
  --login-input loginhistory.csv --audit-input audittrail.csv

The rules cover the list above: SF-EVENT-MON-003 for exports outside 06:00 to 22:00 UTC, SF-EVENT-MON-011 for logins from two IP addresses minutes apart, SF-EVENT-MON-012 for one session or token seen from more than one IP address or client, and SF-EVENT-MON-CORR-001 for a permission grant followed by a large export. Log data does not leave the machine. These rules only see what the org logged: activity that sits inside a user's normal pattern leaves nothing to score, and a finding is a lead to investigate, not proof of compromise.

#FAQ

#Is Salesforce Event Monitoring included in every org?

A small set of event types (including Login, Logout and Apex Unexpected Exception) is included in Enterprise, Unlimited and Developer Editions, with daily logs kept for one day. The full set of more than 70 event types, hourly logs and up to 30 days of history needs the Event Monitoring add-on, sold on its own or as part of Shield.

#How long does Salesforce keep event log files?

One day for the included event types, and up to 30 days with the Event Monitoring add-on. To keep logs longer, export them daily to your own storage or SIEM.

#Which Salesforce event types show data exfiltration?

Report Export, the API event types (API, REST API, Bulk API and Bulk API 2.0) and Content Transfer show data leaving the org. Report, List View and URI or Lightning Page View events show what a user looked at before taking it.

See how Vulkro for Salesforce reads a live org in Vulkro for Salesforce, or Start a 14-day trial. Related: how Salesforce orgs get breached and connected app hygiene after token theft.