Who should own Salesforce forensic readiness in an identity programme?

Why This Matters for Security Teams

Salesforce forensic readiness is not an application-owned task alone because the evidence trail is split across identity, privilege, and platform administration. IAM confirms who authenticated, IGA shows what changed in access over time, and PAM helps explain elevated sessions and privileged actions. NIST guidance on logging and auditability in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that evidence collection must be designed for investigation, not added after an incident. For NHIs, that matters because the environment can look healthy while being impossible to reconstruct later.

NHIMG research shows why this is a governance issue, not a narrow admin concern: only 5.7% of organisations have full visibility into their service accounts, and 79% have experienced secrets leaks, with 77% causing tangible damage, as noted in the Ultimate Guide to NHIs. In a Salesforce context, that means compromised OAuth grants, suspicious profile changes, and admin activity can all disappear into separate logs unless ownership is shared and explicit. In practice, many security teams discover gaps in Salesforce forensic readiness only after an account takeover or token abuse has already occurred, rather than through intentional evidence design.

How It Works in Practice

The practical ownership model is shared, with clear lines for collection, retention, and escalation. IAM typically owns authentication telemetry, federation configuration, conditional access, and identity proofing signals. IGA owns entitlement changes, role assignment history, approval trails, and recertification records. PAM owns privileged session coverage, elevation events, and administrative command trails where those controls exist. Security operations coordinates detection, triage, and evidence preservation so the data can be used in incident response and legal review.

For Salesforce specifically, forensic readiness should include login history, connected app and OAuth grant history, permission set changes, profile edits, API usage, and admin configuration changes. The question is not whether Salesforce logs exist, but whether they are complete enough, retained long enough, and correlated across identity systems. The 52 NHI Breaches Analysis and the Salesloft OAuth token breach both illustrate the same pattern: once a token or privileged integration is abused, investigators need an identity timeline, not just an application snapshot. Current guidance suggests building a joint evidence map that ties each log source to an accountable owner, retention period, and escalation path.

• Map Salesforce login, API, and admin events to IAM, IGA, PAM, and SOC ownership.
• Retain identity and configuration evidence long enough to support breach reconstruction.
• Correlate OAuth grants, permission changes, and privileged sessions with time sync enabled.
• Test whether the team can answer who changed access, when, and from where.

These controls tend to break down in highly delegated Salesforce environments because shadow admin practices, unmanaged integration tokens, and incomplete audit retention fragment the evidence chain.

Common Variations and Edge Cases

Tighter forensic coverage often increases operational overhead, requiring organisations to balance investigation quality against admin friction and storage cost. That tradeoff is most visible when Salesforce is heavily customised, integrated with third-party apps, or administered by multiple business units. In those cases, ownership still sits with IAM, IGA, PAM, and SOC, but application owners may need to provide platform-specific logging and retention support.

There is no universal standard for this yet, but current guidance suggests treating third-party integrations and non-human identities as first-class evidence sources. If a service account, OAuth app, or automation bot can change records, create users, or alter permissions, the identity programme must be able to reconstruct its actions. The Top 10 NHI Issues research is useful here because excessive privilege and weak visibility are recurring root causes, not edge cases. Where Salesforce sits behind a managed service or outsourced admin model, organisations should explicitly define who exports logs, who preserves evidence, and who approves incident access before an event occurs.

In practice, the right answer is shared ownership with one named operational coordinator, because forensic readiness fails when every team assumes another team is keeping the evidence.

Related resources from NHI Mgmt Group

• Who should own identity detection coverage in a mature security programme?
• Who should own identity readiness in an M&A programme?
• Who should own continuous pentesting decisions in a secure delivery programme?
• How should security teams govern non-human identities in Salesforce?