Because they can show activity without proving control. The Setup Audit Trail and Field History Tracking capture who changed what and when, but they do not fully show review, approval, or long-term retention. If teams cannot prove the change was authorised and preserved, auditors may question completeness, accuracy, and control design.
Why Salesforce audit logs feel complete but still leave a control gap
Salesforce logs are strong evidence that something happened, but they are not the same as evidence that the change was governed. Setup Audit Trail shows administrative activity, and Field History Tracking records field-level changes, yet neither one proves the change request was reviewed, the approver was independent, or the record was retained for the full audit window.
That gap matters because auditors usually test both the event and the control around the event. A log can answer “who changed what and when,” but it often cannot answer “was this authorised, was it reviewed, and can we still produce it in six months?”
Why Setup Audit Trail and Field History Tracking are not full audit evidence
audit logs are narrow by design. Setup Audit Trail focuses on configuration and admin changes, while Field History Tracking captures selected data changes on tracked fields. Both are useful for reconstruction, but they do not by themselves provide workflow approval, segregation of duties, evidence of exception handling, or immutable retention.
That means the logs can create a false sense of completeness. Teams may assume that because a change is recorded, it is therefore controlled. In practice, the control question is broader: was the change requested, approved, executed by the right role, and preserved in a form the auditor can rely on?
Retention is also a hidden weakness. If the audit trail is not exported, archived, or otherwise preserved beyond Salesforce’s native limits and operational settings, the organisation may lose the very evidence it expected to rely on during an audit or investigation.
Why auditors often question completeness, accuracy, and control design
Audit risk rises when the organisation cannot demonstrate a clean chain from request to approval to change execution to retention. Logs alone rarely establish completeness because they may not cover every relevant object, every relevant field, or every administrative action that matters to the business process.
Accuracy can also be challenged when logging coverage is partial or when the tracked fields do not reflect the actual control objective. A log that records a data change is not enough if the real concern is whether the change altered revenue recognition, customer eligibility, or access to sensitive data. The control has to align with the business risk being audited.
Design becomes a problem when logging is treated as the control rather than as one component of the control. A mature design usually combines logging with approval evidence, access review, retention policy, and exception handling. Without those layers, the organisation may be able to show activity but not control.
What changes the risk profile in practice
The risk gets worse when audit logs are used as the primary or only control for high-impact changes. That is common in fast-moving Salesforce environments where admins, ops teams, and business users can all influence configuration, automation, and sensitive data.
It also gets worse when ownership is unclear. If no one is explicitly responsible for reviewing, retaining, and reconciling log evidence, the log becomes a passive record instead of a governed control. In audit terms, passive records are much weaker than evidence tied to a defined control owner and a documented review cadence.
This is why many teams discover the problem only during an audit, not during day-to-day operations. The log exists, but the surrounding control story does not.
Risk and Threat Considerations
Audit logs can be abused as proof of control when they only prove activity. That creates exposure to missed unauthorised change, weak segregation of duties, and evidence gaps during an audit or investigation, especially where administrators or integration accounts can make changes without a strong approval trail.
Failure mechanism: The organisation relies on event capture as if it were control evidence, but the underlying process does not preserve approval, review, or retention evidence with the same reliability as the logged action itself.
Impact: Auditors may reject the control as incomplete, investigations may be unable to establish authorisation, and material changes may remain defensible only at the system activity level rather than at the governance level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Salesforce audit evidence depends on logged events and reviewability. |
| Recommendation — Centralise, review, and retain Salesforce audit logs as controlled evidence. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | The question is about what should be captured to support audit evidence. |
| AU-6 — Audit Review, Analysis, and Reporting | The core gap is that logs do not prove review or exception handling. | |
| AU-11 — Audit Record Retention | The answer hinges on whether logs remain available for the audit window. | |
| Recommendation — Define which Salesforce events must be audited and retained for review. Require documented review and escalation of Salesforce audit findings. Set retention periods that preserve Salesforce audit evidence for the full audit cycle. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Salesforce logging must support evidence, completeness, and monitoring. |
| Recommendation — Specify logging coverage and review expectations for Salesforce changes. | ||
Practitioner Guidance
What to verify: Confirm that the audit trail is paired with documented approval evidence, retained long enough for the audit period, and tied to a named control owner who reviews exceptions. If the evidence cannot survive export, archive, and replay outside the live Salesforce tenant, treat it as operational telemetry rather than audit-grade proof.
Common mistake: Teams often equate “logged” with “controlled.” For audit purposes, that is usually too weak unless the log is part of a broader change-management chain that proves authorisation and retention.
Practitioner takeaway: Treat Salesforce logs as supporting evidence, not as the control itself, and design the surrounding approval and retention process so the audit story survives even when the native log does not.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
