When a security incident surfaces in a Salesforce environment, the first question is always the same: who changed what, and when? Without proactive log export processes, compliance managers may spend significant time reconstructing activity timelines from fragmented logs, only to discover that critical event data has already expired from native Salesforce retention windows. That gap between what happened and what teams can prove happened creates exposure, particularly for organizations that have not implemented regular log exports to external storage such as a SIEM or cloud data lake.

This article provides a practical guide to configuring Salesforce Event Monitoring for proactive threat detection. You will learn setup procedures, key event types for identifying threats, regulatory retention requirements, and the specific gaps that require additional controls. The goal is to move from reactive forensics to continuous, automated threat awareness.

The operational stakes reinforce the urgency. In Salesforce, a single compromised identity or over-permissioned integration can trigger rapid data exposure, difficult incident scoping, and audit findings that hinge on whether your team can produce complete, time-stamped evidence. Salesforce Event Monitoring provides the foundation for internal detection capability. While Salesforce Shield's Transaction Security policies enable real-time detection within Salesforce environments, organizations with cross-platform visibility requirements or long-term retention mandates may need supplementary controls to address scope and retention limitations.

What Salesforce Event Monitoring Provides

Event Monitoring captures granular user activity across your Salesforce environment. Understanding its two tiers helps compliance managers and DevOps engineers determine which capabilities their organizations need and where gaps remain.

Standard Event Monitoring

Standard Event Monitoring tracks user interactions through event log files stored in the EventLogFile object. These CSV-formatted files capture logins, logouts, report exports, API calls, URI access, and over 50 event types. Log files are generated hourly for Event Monitoring customers and, by default, have about 1-day data retention (with optional extended retention via the Event Log File retention add-on or Shield Extended Retention, supporting up to 1 year depending on edition and subscription).

The feature requires a Salesforce Shield or Event Monitoring add-on license for full functionality and is available in Enterprise, Performance, Unlimited, and Developer editions.

Shield Event Monitoring

Salesforce Shield adds real-time event monitoring and Transaction Security policies. Transaction Security allows administrators to create rules that block transactions, require multi-factor authentication, or send notifications based on real-time events. Shield stores event data in Event Log Objects, including for events like logins, allowing faster access without the typical delay of log file generation.

Note: Event Monitoring captures runtime user activity (logins, API calls, report exports), while the Setup Audit Trail separately tracks configuration changes (permission modifications, field-level security updates, metadata deployments). These are complementary but distinct features, and teams should leverage both for comprehensive coverage.

Setting Up Event Monitoring Step by Step

Configuration involves licensing activation, permission assignment, and log access configuration. Each step builds on the previous one, so completing them in order prevents access issues during setup.

Assign User Permissions

Event Monitoring must be manually enabled in Setup after the licenses are provisioned. Navigate to Setup, then Users, then Permission Sets. Create or modify a permission set to enable these system permissions:

• API Enabled: For programmatic access to Salesforce Event Monitoring logs via API, specific permissions are required as per Salesforce documentation.
• View Event Log Files: Grants access to event log data (requires "API Enabled")
• Access to the Event Log File Browser requires specific permissions such as "View Event Log Files" and "API Enabled" according to available sources.

Assign the permission set to security analysts and compliance team members who need monitoring access.

Access Event Log Files

Teams can retrieve logs through two methods. The Event Log File Browser provides a UI-based approach: navigate to Setup, select the date range and event types, and download CSV files. For automated retrieval, query the EventLogFile object through the REST or SOAP API using SOQL.

Configure Transaction Security (Shield Only)

Navigate to Setup, then Transaction Security Policies. Create a new policy by selecting an event type such as LoginEvent, although support for ApiEvent as a trigger is not explicitly confirmed in available documentation. Define conditions using Apex code, specify actions (block, MFA challenge, or notification), and activate the policy. This enables real-time enforcement against suspicious activity patterns.

Detecting Threats Through Event Log Analysis

Event logs become a threat detection tool only when teams know which patterns signal compromise. Three categories of events provide the highest detection value for security teams monitoring Salesforce environments.

Authentication Anomalies

Login events reveal brute-force attacks through clusters of failed authentication attempts. Concurrent logins from geographically distant locations indicate credential sharing or session hijacking. LoginAs events track administrator impersonation, a high-risk action that requires close audit scrutiny.

Data Exfiltration Indicators

Report Export and Document Attachment Download events identify potential data theft. A user who suddenly exports large report datasets outside their normal pattern warrants investigation. Bulk API events track mass data operations that could indicate systematic extraction.

API and Integration Abuse

In 2025, two high-profile campaigns demonstrated the severity of SaaS integration threats against Salesforce environments:

• UNC6040 (ShinyHunters) vishing campaign: The threat group UNC6040 breached multiple organizations' Salesforce instances, including a Google corporate Salesforce instance used for managing SMB contact data. Attackers used voice phishing (vishing) to trick employees into authorizing a malicious connected app mimicking Salesforce's Data Loader, generating OAuth tokens that enabled bulk data exfiltration.
• UNC6395 Salesloft Drift supply chain attack: In a separate campaign, the threat actor UNC6395 compromised the Salesloft Drift chatbot integration, stealing OAuth tokens used by Drift to connect to customers' Salesforce instances. Over 700 organizations were potentially impacted, with attackers systematically exporting data from corporate Salesforce environments over a ten-day window.

API event monitoring detects unusual call volumes, unauthorized client applications, and access from unexpected locations. These incidents show why third-party integrations need continuous monitoring, not periodic reviews.

Regulatory Requirements for Security Event Logging

Multiple regulatory frameworks mandate specific event logging, access monitoring, and retention capabilities. Understanding these requirements in one consolidated view helps compliance managers identify where Salesforce retention periods may fall short.

Framework-Specific Mandates

The following frameworks each impose distinct requirements for event logging, access monitoring, and data retention. Not all mandates apply uniformly — applicability depends on your industry, the types of data Salesforce stores, and whether Salesforce serves as a system of record for regulated information. Use this summary to identify which requirements are relevant to your organization and where native Salesforce retention may fall short.

HIPAA

45 CFR § 164.312(b) requires mechanisms that record and examine activity in systems containing electronic protected health information. The six-year retention requirement under 45 CFR § 164.316(b)(2) explicitly applies to HIPAA-related policies, procedures, and documentation. While HHS does not prescribe a specific retention period for system audit logs, many compliance authorities recommend retaining audit logs for six years because log data may constitute "documentation of activities" under §164.316(b)(1). Organizations should consult their risk analysis and legal counsel to determine appropriate audit log retention.

SOX/SEC

Broker-dealers registered with the SEC must maintain complete time-stamped audit trails — including modifications, deletions, timestamps, and user identity — under 17 CFR § 240.17a-4. The required retention period is 6 years. Note that this applies to broker-dealer records systems; whether Salesforce serves as a system of record for these regulated data types depends on the organization's specific usage.

GDPR

Article 32 requires appropriate technical and organisational measures to ensure the security of processing, but it does not explicitly require audit capabilities. Retention periods are organization-defined based on storage limitation and data minimization principles.

NIST SP 800-53

Control AU-11 requires organizations to retain audit records for organization-defined periods to support administrative, legal, audit, or operational needs. Controls AU-2 and AU-12 require comprehensive event logging and generation capabilities.

The Retention Gap

Salesforce provides multiple retention mechanisms that serve different purposes, and understanding the distinctions between them is critical for compliance planning. Incidents may take 12–18 months to surface, while Salesforce logs often expire much earlier, making it essential to understand exactly what each mechanism retains, for how long, and what falls outside its scope.

The key challenge is that each mechanism covers a different dimension of activity — runtime events, configuration changes, and field-level data modifications — and no single mechanism provides comprehensive, long-term coverage across all three. Here is how these mechanisms break down:

• Setup Audit Trail retains configuration change data for 180 days and tracks metadata deployments, permission changes, and security settings.
• Field History Tracking enables tracking of standard and custom objects, with archived history data retained for up to 10 years via the Salesforce Metadata API when using the Field Audit Trail add-on. This add-on increases the tracked field limit per object from 20 to 60. Without add-ons or extended configurations, retention is subject to shorter limits.
• Standard Event Monitoring captures runtime activity (logins, API calls, exports). A paid Event Monitoring license extends Event Log File retention up to one year, but this data is not a permanent system of record and can have gaps. Organizations without Shield or extended retention add-ons face much shorter windows — Enterprise, Unlimited, and Performance Edition organizations have free access to select event log files (such as Login, Logout, and API Total Usage) with only 1-day data retention.
• Real-Time Event Monitoring (Shield) provides a minimum of six months of data retention, meeting most security policies that require event information be stored for at least 3–6 months to facilitate forensics efforts.

For organizations subject to SOX broker-dealer requirements or that interpret HIPAA documentation retention as encompassing audit logs, these native retention periods fall short of the six-year minimums. The maximum one-year extension available through the Event Log File retention add-on or Shield Extended Retention does not close this gap for those use cases. However, whether Salesforce itself must serve as the six-year retention platform depends on the organization's architecture — many enterprises address this by exporting logs to external SIEM or data lake solutions with appropriate retention policies.

Why Native Event Monitoring Falls Short for Enterprise Security

Native Event Monitoring establishes essential visibility into user activity, but it was designed primarily for Salesforce-scoped monitoring rather than as a complete cross-platform enterprise security monitoring solution. Understanding this scope boundary helps teams plan what additional capabilities they need.

Event Monitoring can integrate with a SIEM platform to enhance advanced security use cases. Native log expiration limits cannot support after-the-fact investigations that regulatory frameworks may require without proactive log export. While Event Monitoring does not directly log metadata deployments, the Setup Audit Trail captures these configuration changes separately. However, neither feature connects changes to the deployment pipelines or CI/CD processes that introduced them, creating a traceability gap for organizations that need end-to-end change provenance.

What Comprehensive Threat Detection Requires

Extending Salesforce event data into workflows that meet enterprise security requirements may necessitate additional controls and integrations. The following requirements map directly to the regulatory and operational needs established above.

Effective solutions must provide:

1. Extended audit retention that aligns with compliance mandates, though these typically do not explicitly require methods without manual export processes. This removes dependence on short Salesforce retention windows and reduces audit preparation work when regulators ask for historical evidence.
2. Deployment-aware monitoring that connects configuration changes to the users and pipelines that introduced them. This makes it possible to trace risky permissions, integration changes, or security setting updates back to the exact release that introduced them.
3. Automated policy enforcement through codified security rules embedded in CI/CD pipelines. This shifts governance from after-the-fact review to consistent, repeatable gates that prevent policy violations from being deployed.
4. Continuous audit trail generation spanning version control, security validation, and deployment decisions. This provides end-to-end evidence for change control, including who approved changes, what was tested, and what reached production.

The DoD Enterprise DevSecOps Fundamentals framework establishes that security must be integrated throughout the software lifecycle, from development through deployment and beyond. Enterprise DevSecOps platforms provide this integration layer by embedding security validation directly into the pipeline stages where configuration changes originate.

From Monitoring to Automated Threat Prevention

Event Monitoring gives security teams the data they need, but governance still breaks down when changes move through deployments faster than teams can review them. Organizations must ensure they have robust processes in place to manage configuration changes effectively to avoid potential compliance issues and operational risks.

Flosum provides automated deployment pipelines for Salesforce metadata with policy-based deployment controls that enforce governance at each pipeline stage. These controls prevent unauthorized changes from reaching production, addressing the deployment-awareness gap that Event Monitoring cannot cover.

Without long-term audit documentation, compliance teams face recurring exposure during regulatory reviews.

Flosum generates audit trails for compliance reporting, creating the long-term documentation that satisfies regulatory retention requirements. Teams that combine Event Monitoring visibility with automated deployment governance close the gap between detecting threats and preventing them.

Request a demo with Flosum to explore how automated audit trails and deployment controls support your compliance and threat detection requirements.