Help with servicenow sign-in and audit-logs collection for IDTR use cases (detection and response)

[febasis360]

Hello ServiceNow Community,

Context – Security and Identity Threat Detection

I’m building a comprehensive Identity Threat Detection and Response (ITDR) process using ServiceNow’s core logs: sys_audit, sysevent, and syslog_transaction. The goal is to detect identity-related threats (privilege escalation, dormant account use, etc.) by correlating log data outside ServiceNow, using a SIEM or log analytics platform.

I have enabled auditing on key tables, especially sys_user_has_role, to track all changes in roles assigned to users.
Auditing enabled on sys_user_has_role (and related tables) as per documentation and via sys_audit_list.

API Calls (using /api/now/table/sys_audit, /api/now/table/sys_user_has_role, etc.) and export filtering, already set up for programmatic access.

Sample log collection and queries are working for most tables.

Problem – sys_audit Old/New Value = "{deleted}" in sys_user_has_role
When reviewing sys_audit entries for changes in sys_user_has_role, I see events where the oldvalue or newvalue (and sometimes both) are {deleted}. This makes it impossible to reconstruct who was assigned what role at the time of the change—especially when historical or deleted references are involved.

Example:
json
{
"tablename": "sys_user_has_role",
"fieldname": "role",
"oldvalue": "{deleted}",
"newvalue": "287ebd7da9fe198100f92cc8d1d2152d",
...
}
Or, both values can be {deleted} if the related record is gone.

Is this expected behavior even with table auditing enabled?

Is there a workaround or best practice for reliably reconstructing role assignment history—especially for deleted roles or users?

How are others handling this for regulatory/audit or SIEM/threat detection purposes?

Looking for Guidance On...
Best practices for full-fidelity role audit: Especially for reconstructing changes (including deletions) to user roles for audit, or threat detection/correlation.

LES or API configuration: If there are special options for LES source setup (or MID server probes/scripts) to preserve old/new values, or get richer links instead of {deleted} stubs.

Alternate designs: If anyone is successfully correlating these events at scale for SOX/ITDR/zero trust, what’s your architecture—especially handling {deleted} records, role re-creations, and similar edge cases?

Any helpful tricks for reconstructing full change history for role assignments, that aren’t in standard docs.

What I’ve Tried
Confirmed auditing is on for the table/field (audit and role settings)

Checked sys_audit and sys_audit_delete

Exported logs via API, LES, and tested MID server path

Used queries like
/api/now/table/sys_audit?sysparm_query=tablename=sys_user_has_role

Reviewed ServiceNow and community articles (e.g., KB0786168, audit-user-roles)