How should security teams use audit logs to investigate unauthorized changes in SaaS and identity operations?

Why This Matters for Security Teams

Audit logs are often the only durable evidence when a SaaS admin setting, identity policy, or app integration changes without approval. They let security teams reconstruct the sequence of actions across consoles, APIs, and automation accounts, then distinguish a legitimate change from an adversary using stolen credentials or an over-privileged NHI. In practice, monitoring gaps are a recurring attack driver: NHI research from The State of Non-Human Identity Security shows inadequate logging is cited alongside over-privilege as a leading cause of incidents. That makes auditability a control, not a reporting feature.

For SaaS and identity platforms, the real challenge is not collecting “more logs” but retaining the right events with enough context to answer who, what, when, where, and by which mechanism. Teams that rely only on login events miss the higher-risk changes that happen after authentication, including role edits, token creation, consent grants, and policy tampering. The broader control expectation is consistent with NIST Cybersecurity Framework 2.0 and the logging discipline reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover the missing chain of custody only after a failed business process or account takeover has already spread across multiple systems.

How It Works in Practice

Effective investigation starts with centralising audit data from the SaaS control plane, the identity provider, the privileged access layer, and any automation or API clients that can change configuration. The key is to preserve high-value fields: actor, target object, action type, timestamp, source IP, user agent, device, app integration, request ID, and outcome. Those fields make it possible to correlate a policy change in one platform with a token issuance, OAuth consent, or admin elevation in another.

Security teams should treat audit logs as evidence of change, not just evidence of access. That means reviewing events such as:

• role assignment, permission grant, and group membership changes
• API key creation, secret rotation, token issuance, and consent approvals
• conditional access, SSO, federation, and MFA policy edits
• new application registrations, webhook changes, and integration scope expansion
• delete, disable, archive, or offboard actions affecting identities and service accounts

For investigative depth, logs should be searchable by entity and by sequence. A change made by an admin from a corporate laptop looks different from the same change made by a service account, browser automation, or a third-party app. Aligning this approach with the lifecycle and visibility guidance in Ultimate Guide to NHIs helps teams connect identity governance to operational evidence. Best practice is to retain enough history to compare “before” and “after” states, because a single event record rarely explains the blast radius on its own. These controls tend to break down in highly federated SaaS environments because audit fields are inconsistent across vendors and some critical change events are never exposed through native exports.

Common Variations and Edge Cases

Tighter logging often increases storage, parsing, and review overhead, so teams must balance investigative depth against retention cost and alert fatigue. The practical tradeoff is that some platforms provide rich admin audit trails while others expose only partial event history, especially for marketplace apps, delegated OAuth access, or identity actions performed through automation. Current guidance suggests treating those gaps as a risk to be compensated for with API-based export, SIEM normalisation, and explicit logging requirements in procurement.

Two edge cases deserve special attention. First, actions taken by NHIs can look legitimate at first glance because the actor is not a human user, yet the underlying credential may be compromised or mis-scoped. Second, delegated administration can obscure accountability when a support engineer, managed service provider, or CI/CD pipeline makes a change on behalf of another tenant or business unit. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the breach patterns reflected in 52 NHI Breaches Analysis both show why post-incident review must include identity provenance, not just change timestamps. When a platform cannot attribute changes to a stable actor or cannot preserve logs long enough for investigation, the audit trail becomes useful for operations but weak for forensics.

Related resources from NHI Mgmt Group

• How should security teams safely use AI agents to audit and apply identity changes across many applications?
• Who should own non-human identity security when engineering teams create and run the workloads that use them?
• How should security teams schedule access changes to reduce operational risk in SaaS workflows?
• How should security teams correlate identity and data context to find the highest-risk exposures in AI and SaaS environments?