Audit Response Actions

Verify remediation steps and troubleshoot failures using Audit Logs.

When you execute a response action in a case, such as disabling a compromised user or blocking a malicious IP, that operation is permanently recorded in the Audit Log. This guide provides practical examples and search queries to help you verify those actions using the Log Management tools.

View action history

To see a global view of all response actions taken across your environment:

1. Navigate to Log Management in the main menu.

2. Locate the view selector button (small list icon) in the top-right corner, immediately to the left of the Run button.

3. Select Audit logs from the dropdown menu.

1. (Optional) Use the Time Range picker to narrow your search to a specific incident window (e.g., Last 4 hours).

2. Click the Run button to generate the report.

Understand audit entries

To get a detailed vision of the key fields within an Audit Log, check out our Introduction to Audit Logs article.

Example log entry

Below is a standard log entry for an Enable User action. Reviewing the raw JSON helps you understand exactly what data is available for filtering.

{
action: "enable_user"
changedFrom: "{"status":"pending"}"
changedTo: "{"status":"inprogress"}"
eventTimestamp: 1769111845
logEntryTimestamp: 1769112601
message: "Radiant Security Platform executed \"Enable user\" on user_principal_name \"[email protected]\"",
rs_connectorType: "rs_audit_logs"
rs_fp: "89Q+qw=="
rs_indexed: 1769112604
rs_received: 1769112602
rs_timestamp: 1769111845
target: "[email protected]"
targetType: "user_principal_name"
userEmail: "Radiant Security Platform"
userID: "Radiant Security Platform"
}

Common audit scenarios

Use the search bar in Log Management to answer specific questions about your response actions history. You can copy the queries below directly into the search field.

Verify Failed Response Actions

If a response action doesn't seem to work, search for error statuses to confirm if the downstream API failed.

• Goal: Find actions that failed to execute.

• Search Query:

  • changedTo:{"status":"error"}

• What to look for: Expand the log entry and check the target field to identify which asset was not remediated. Use the eventTimestamp to determine exactly when the failure occurred relative to other events in the case.

• Use this detail to troubleshoot the connection or permissions with the Action Connector.

Note: You can also see immediate failure feedback directly in the Case view. The Actions taken column in the artifact table will display an error status (e.g., Error: Enable user) next to the specific item.

Investigate Specific Artifacts (IP or User)

If you are analyzing a suspicious artifact, like an IP address, and want to know if anyone has already taken action on it, filter by the target.

• Goal: See the history of actions taken on a specific IP.

• Search Query:

  • target:"192.168.1.50"

Tip: Using the "target:" prefix ensures you see only direct actions on that artifact, filtering out unrelated noise from other logs.

Track Specific Action Types

You may need to generate a report of specific sensitive actions, such as ensuring no compromised user accounts were re-enabled prematurely.

• Goal: List all instances where a user account was re-enabled.

• Search Query:

  • action:"enable_user"

• Refine your search: You can combine queries to find exactly who performed the action on a specific user:

  • action:"enable_user" AND userEmail:"[email protected]"