Understanding Immuta Audit Logs

Immuta provides robust audit logging to capture a complete history of key activity within the platform and governed data sources. This includes policy creation and updates, access approvals, user and group attribute changes, tag applications, and query activity in technologies like Snowflake, Databricks, and Unity Catalog.

This visibility is essential for any organization managing sensitive data, regardless of size, industry, or data governance maturity. Audit logs offer:

• Technical transparency to understand how access is granted and enforced

• Operational accountability to trace decisions and user behavior

• Regulatory evidence required to meet compliance obligations under frameworks like HIPAA, GDPR, and CCPA.

This guide is intended for data platform, security, and governance teams who are getting started with Immuta audit logs. It explains what Immuta captures, how those events are structured, and how to begin analyzing them effectively.

Types of audit logs

Immuta audit logs provide visibility into both how the Immuta application is used and how governed data is accessed in connected technologies. Together, these logs allow teams to trace how access is managed and enforced across the entire data ecosystem. These logs fall into two primary categories: application events and query events.

1. Application events

Application audit logs are focused on capturing how the Immuta application is used—specifically, who took what action, when, and why. These logs are especially useful for tracking

• Policy creation, updates, and deletions

• Changes to data source metadata, including applied tags

• User or group attribute updates that affect entitlements

• Access requests and approvals

• Permission grants and denials for governed data sources

These records help governance and compliance teams trace decision points over time and verify how the Immuta application is enforcing access. For example, if a user gains access to a dataset tagged as sensitive, audit logs can help show whether that access resulted from a new policy, a group change, an updated user attribute, or a tag applied to the dataset.

2. Query events

Query audit logs capture governed data access in connected platforms. These logs show

• Which user queried which table or data source

• The timestamp and context of the query

• The columns accessed or policies enforced (in supported platforms)

This information is critical for detecting anomalies and demonstrating that sensitive data is only accessed under the right conditions.

What’s captured in audit logs

All audit events—whether from Immuta application activity or query execution—follow a consistent structure, making them easy to analyze at scale. Each event typically includes the following fields:

Field	Description
action	Describes what occurred, like CREATE, UPDATE, DELETE, or APPLY.
targetType	Indicates the object affected by the action, like USER, POLICY, DATASOURCE, TAG, or ATTRIBUTE.
actor	Identifies the user or system that performed the action, including their Immuta username, identity provider, and IP address.
timestamp	Shows when the action occurred.
sessionId and requestId	Useful for correlating related events performed in a single session or transaction.
relatedResources	Shows metadata involved in the event, like as applied tags or attributes.
auditPayload	Provides object-specific details, such as which attribute value was applied or what tag was added.

These fields can be used to filter or join logs across different audit event types, helping you reconstruct access behavior, policy changes, or system activity over time.

Learn more about what's captured in the UAM schema reference guide.

What is not captured in Immuta audit logs?

Immuta’s audit logs are focused on access control and governance behavior within the Immuta application and queries in the platforms it governs. Immuta does not audit

• Activity outside governed platforms (e.g., access to unmanaged data stores)

• Failed login attempts done via SSO (these should be captured in your SSO provider audit logs)

Auditing metadata-driven access

One of the most important aspects of Immuta’s access control model is that policies are dynamic and metadata-driven. That means a user’s access can change even if no one edits the policy directly.

For example:

• A policy allows access to tables tagged business.marketing for users with the attribute department=marketing.

• If a user is granted the marketing attribute, or if a new business.marketing tag is added to a table, that user will now have access, even though the policy itself was not changed.

Immuta audit logs will reflect these events, showing when

• A user’s attribute was updated (AttributeApplied)

• A tag was added to a data source (TagApplied)

These indirect events often explain changes in access and are essential to review during audits and investigations.

Next steps

If you haven’t yet configured audit log export, your first step is to set up export to secure storage, such as Amazon S3 or Azure Data Lake Gen2. This ensures that logs are retained beyond Immuta’s 90-day default and remain available for long-term analysis. Setup instructions are available in the Audit how-to guides.

If your exports are already in place, you're ready to begin analyzing the data. To learn how to filter for key events and monitor access patterns, see Extracting Insights from Immuta Audit Logs.