OneTrust Activity Log

What is captured in Activity Logs?

As of the OneTrust Summer 202608.1.0 release, Activity Log includes select global settings activity, such as branding, authentication, session, credential, and user management changes, along with supported product activity surfaced in the platform. Product coverage varies by area and generally includes notable record and configuration updates where supported. Support for additional platform areas will be rolled out in upcoming releases.

Prerequisites

• Access to a developer tool such as Postman

• Client Credentials configured with the AUDIT_LOG scope. For more information, see Managing OAuth 2.0 Client Credentials.

Configuring the public API

1. In Postman, create a new POST request to generate an OAuth access token using your client credential.

   JSONCopy

   POST https://<your-domain>/api/access/v1/oauth/token Headers: accept: application/json Body (form-data): grant_type=client_credentials client_id={{client_id}} client_secret={{client_secret}}

   POST https://<your-domain>/api/access/v1/oauth/token
   
   Headers: 
   accept: application/json
   
   Body (form-data): 
   grant_type=client_credentials
   client_id={{client_id}}
   client_secret={{client_secret}}

2. Send the request and copy the access_token from the response. You can set this as a variable for protection, {{access_token}}

   
   
   

3. Create a second request in Postman to using the Get List of Event Types endpoint with the bearer token from the previous step.

   JSONCopy

   GET https://{hostname}/api/audit/v4/audits/event-types Accept: application/json Authorization: Bearer {{access_token}}

   GET https://{hostname}/api/audit/v4/audits/event-types
   
   Accept: application/json
   Authorization: Bearer {{access_token}}

   
   
   

4. The response returns event records that include the event code, event name (value), object type name, and module name. This payload can be used as a source record for reporting or review. You can keep it as the complete raw export, then pull out the fields you need to validate coverage, compare event names, or support audit discussions.

   JSONCopy

   [ { "code": 1001, "value": "User created", "objectTypeName": "User", "moduleName": "User management" } ]

   [
     {
       "code": 1001,
       "value": "User created",
       "objectTypeName": "User",
       "moduleName": "User management"
     }
   ]

   
   
   

Consent & Preferences - DS GUIDs

Global Activity is designed to provide centralized visibility into platform activity without storing personally identifiable information in the audit layer. Because of that design, consent-related audit records for data subjects are not searchable by familiar personal identifiers such as an email address or values.

This approach helps limit unnecessary exposure of personal data in Global Activity while still preserving the audit trail needed for investigation and review. When a user needs to find audit activity related to a specific data subject, they must search using the data subject GUID (DS GUID) instead of the personal identifier. The DS GUID is the system-level identifier available to Global Audit and is the supported value for locating the relevant audit record.

1. Locate the DS GUID for the data subject in the source data subject record or related workflow.

2. Open Global Activity and go to the search or filter experience.

3. Enter the DS GUID as the search value instead of the email address or other personal identifier.

4. Review the returned audit records to find the relevant activity for that data subject.

Tenant Copy & User IDs

A current limitation of tenant copy with Activity Logs is that some historical audit records may retain source-tenant userIDs instead of mapping cleanly to userIDs in the target tenant, which can cause missing or incomplete user details in audit history after the copy.

For more information, see Submitting a Tenant Copy Request.

Network Details

Integration-initiated events, which are actions performed by the system rather than direct user-driven updates, will not include network details such as IP address or user-agent in the SIEM payload. This is because the original caller context is not captured or preserved as the event moves through the integration flow, so the final record reflects the integration path instead of the originating request source.