To audit file access in Salesforce external storage, you need to combine Salesforce’s native event logging with the access controls and audit tools provided by your external storage provider. Neither system alone gives you a complete picture. The sections below walk through each part of that process, from understanding what counts as external storage to setting up continuous monitoring.
External storage in Salesforce refers to any file repository that sits outside Salesforce’s native storage environment but connects to it through an integration or API. This includes cloud platforms like Amazon S3, SharePoint, Google Drive, and other third-party repositories that Salesforce accesses through tools like Files Connect or custom integrations.
The key distinction is where the file physically lives. When a document is stored in Salesforce natively, it lives within Salesforce’s own infrastructure. When it is stored externally, Salesforce holds a reference or metadata pointer to the file, while the actual content resides on a separate system. This split is important for auditing because it means access events can be recorded in two separate places or, in some configurations, in neither.
Common examples of external storage setups include organizations that offload large document libraries to Amazon S3 to reduce storage costs, teams using SharePoint for Office 365 collaboration while linking documents back to Salesforce records, and media or real estate companies that store high-volume assets in cloud buckets connected to their CRM.
Salesforce logs file access events primarily through Event Monitoring, a feature available in higher-tier Salesforce editions. Event Monitoring captures a range of user activity, including document views, downloads, and content delivery events, and stores them as log files that can be accessed via the EventLogFile object in the Salesforce API.
Within Event Monitoring, the most relevant log types for file access are:
These logs are retained for a defined period depending on your Salesforce edition and configuration. Administrators can query them directly or route them to a SIEM tool for longer retention and analysis. The limitation is that these logs only capture what happens within Salesforce’s own layer. Once a file is retrieved from or stored in an external system, the activity moves outside this log scope.
To audit access to files stored outside Salesforce, you need to use the audit and logging capabilities of the external storage provider directly. Each platform maintains its own access logs, and you must enable and configure those logs separately from anything Salesforce provides.
For Amazon S3, AWS CloudTrail records every API call made to your S3 buckets, including who accessed a file, from which IP address, and at what time. S3 Server Access Logging provides a more granular record of individual object-level requests. Both need to be explicitly enabled in your AWS account.
For SharePoint and OneDrive, the Microsoft Purview compliance portal provides audit logs that capture file access, sharing events, and permission changes. These logs are accessible to administrators and can be exported for review.
The challenge is that these external logs do not automatically reference the Salesforce record or user that triggered the access. If a Salesforce workflow retrieves a file from S3, the S3 log records the API call but not the Salesforce context. Bridging that gap requires either a custom integration layer that passes identifiers or a document management solution that maintains a unified access trail across both systems.
Tools that pull file access data from both Salesforce and external storage generally fall into three categories: SIEM platforms, dedicated compliance tools, and document management solutions with built-in audit capabilities. The right choice depends on your organization’s existing infrastructure and compliance requirements.
Security Information and Event Management tools like Splunk, Microsoft Sentinel, and IBM QRadar can ingest logs from both Salesforce Event Monitoring and external storage providers. Once connected, they allow you to correlate events across systems, set alerts, and maintain long-term audit archives. These tools are powerful but typically require dedicated IT resources to configure and maintain.
Document management platforms integrated directly into Salesforce can provide a unified audit trail without requiring a separate SIEM deployment. Because they sit between Salesforce and the external storage layer, they can log access events at the point of interaction and associate them with the relevant Salesforce record, user, and timestamp in a single view. This approach is especially practical for operations teams that need compliance visibility without building a complex logging infrastructure.
Audit gaps in Salesforce external storage setups appear because the two systems log activity independently, and there is no automatic mechanism to link those records. When a user opens a file through Salesforce that is physically stored in an external system, the event may be partially recorded in one log, partially in another, or missed entirely depending on how the integration is configured.
Several factors contribute to these gaps. First, many organizations enable external storage integrations without reviewing the default logging settings on the external platform. AWS S3 logging, for example, is not enabled by default. Second, service accounts or integration users often perform file retrieval operations that are attributed to a system identity rather than the individual end user, making it difficult to trace who actually accessed a document. Third, when files are accessed through embedded previews or third-party viewers, those interactions may not register as a formal access event in either system.
Understanding document value management principles helps organizations identify which documents are high-risk and prioritize closing audit gaps where they matter most.
Access to file audit logs in Salesforce should be limited to a defined set of roles with a legitimate need to review access records. Broadly, that includes system administrators, compliance officers, security teams, and, in regulated industries, designated data protection personnel.
Restricting log access is itself a compliance consideration. Audit logs contain sensitive metadata about user behavior, and unrestricted access to those records creates its own governance risk. In practice, most organizations apply a tiered model:
Salesforce permission sets and profiles control who can query EventLogFile objects. For external storage logs, access is managed through the respective platform’s IAM or role-based access controls. Aligning those permissions across both systems is a step that organizations often overlook during initial setup.
Setting up ongoing file access monitoring in Salesforce requires enabling Event Monitoring, configuring log retention, connecting external storage audit logs, and establishing a review process. This is not a one-time task but an ongoing operational practice that needs to be maintained as your storage environment evolves.
Start by confirming that Event Monitoring is active on your Salesforce org and that the relevant event types are enabled. Next, enable server access logging on any external storage buckets or SharePoint sites connected to Salesforce. Route those logs to a centralized location, whether that is a SIEM tool, a cloud storage archive, or a document management platform that aggregates them for you.
From there, define what you are monitoring for. Common triggers include access to sensitive document categories, downloads by users outside expected roles, access at unusual hours, or bulk retrieval events that could indicate data exfiltration. Set up automated alerts for those patterns rather than relying on manual log reviews.
Review your document management features periodically to ensure your monitoring setup keeps pace with changes in your storage architecture, user base, or compliance requirements. Organizations that treat audit monitoring as a living process rather than a one-time configuration are far better positioned when an audit or incident review occurs.
We built Cartularius to close exactly the kind of audit gaps described throughout this article. Because Cartularius operates as a document management layer directly inside Salesforce, it maintains a unified access trail that spans both Salesforce records and connected external storage, including Amazon S3. Every file interaction is logged in context, meaning you can see which user accessed a document, which Salesforce record it was associated with, and when the event occurred, all from a single location.
Here is what that means in practice for teams managing document access compliance:
If your team is managing high volumes of documents across Salesforce and external storage and needs a cleaner audit trail without building a custom logging infrastructure, explore our storage and compliance plans to find the right fit for your organization.
Install Cartularius now and experience the best Salesforce document management solution and enjoy clean and structured data and optimized processes, risk-free for 30 days.