Access Summary Export

Private preview

The access summary export is currently in private preview and is available to select accounts. Contact your Immuta representative for details.

To learn more about how the preview status impacts the feature, see the private preview section.

The access summary export is a feature that exports files to S3 with access information that you can then use to understand what users have access to at this moment in time and why. The access summary exports all the Immuta configuration metadata relevant to analyzing your user's access. Organizations can utilize these exports in a few different ways:

• Expose the access summary export as an external table in your data platform for interactive queries.

• Use the access summary export in BI dashboards to visualize access.

• Support the necessary information for user access reviews or recertifications in tools like SailPoint.

The access summary export is a snapshot of what access in Immuta looks like. For an audit trail of what user actions led to user access, use the Immuta audit logs.

Contents

The access summary export contains 12 files:

1. policy-metadata: This file contains details about Immuta data and subscription policies.

   1. Use this file with policy-outcomes to understand the policy that granted or restricted data access.

   2. Use this file for policy recertification workflows.

2. user-metadata: This file contains details about Immuta users.

   1. Use this file with policy-outcomes to understand the users that have access to data.

3. datasource-metadata: This file describes the data source assets registered in Immuta.

   1. Use this file with tag metadata to understand how data is tagged.

4. column-metadata: This file describes the column assets registered in Immuta.

   1. Use this file with tag metadata to understand how columns are tagged.

5. tag-metadata: This file contains details about how data sources are tagged in Immuta.

   1. Use this file with policy-outcomes to understand which tags are driving Immuta policies.

6. policy-outcomes: This file contains details on the Immuta policies applied to data sources and the resulting access based on those policies.

   1. Use this file to understand current access to data.

7. domain-metadata: This file contains details on Immuta domains.

8. access-requests: This file contains details on access requests in the Request app.

   1. Use this file for user access recertification workflows.

9. request-determinations: This file contains details on the determinations that have been made on access requests in the Request app.

10. request-duas: This files contains details on the data use agreements (DUAs) that requestors signed when making access requests.

11. data-products: This file contains details on data products in the Request app.

12. data-product-assets: This file contains details on the assets within data products in the Request app.

See the Access summary export schema reference guide to see the full file contents.

Using the access summary files for your use case

Join these files together to surface the story of data access in your organization and answer access related questions like these and more:

1. What users have access to data through a specific policy?

   1. Filter policy-metadata for the specific policy.

   2. Join to user-metadata using global_user_id to get the list of names and emails for the recertification report.

   3. Join to policy-outcomes using policy_id.

2. Which domains have the most users with access to tags that signify highly sensitive data?

   1. Filter tag-metadata for high-sensitivity tags and filter by target_type:DATA_SOURCE.

   2. Join to domain-metadata via data_source_id, which is the target_id in the tag-metadata table, to group by domain name.

   3. Join to policy-outcomes via data_source_id to count the unique global_user_ids per domain.

3. If a specific policy is changed, what users' access will be impacted?

   1. Identify the policy in policy-metadata.

   2. Look up all records in policy-outcomes where that policy ID appears in the policy_ids list.

   3. Cross-reference with user-metadata to identify the impacted user base.

4. Who is requesting access to which assets, and what’s the current status?

   1. Filter access-requests by target_id (or target_type) and/or determination.

   2. Join to user-metadata on global_user_id (access recipient) and global_requestor_id (submitter) to get names/emails.

   3. Use request_date, final_determination_date, and expiration_date to drive timeliness and lifecycle reporting.

5. Which users need recertification for a specific data product (or governed data source)?

   1. Filter access-requests to the asset you’re recertifying (e.g., target_type = DATA_PRODUCT and target_id = <product_id>).

   2. Keep only currently-active grants (e.g., determination = APPROVED and expiration_date is null OR expiration_date > <as-of-date>).

   3. Join to user-metadata on global_user_id to get the user’s name/email for the recertification outreach list.

Accessing the export in S3

Once the access summary export is configured, the access summary is exported daily (at 5AM local time) to your configured S3 bucket in your AWS environment. Each access summary export is the current, full state of the metadata in Immuta, not the diff from the previous run. The access summary export always replaces the one from the previous day.

You can find the access summary export at this location in your bucket: s3://<your-bucket>/<your-path>/<export-name>/v=<version>/<export-name>.parquet

• your-bucket: This is the S3 bucket you configure the export to go to.

• your-path: This is the AWS path you configure the export to go to.

• export-name: This is the name of the particular file of the access summary export. See the options in the Contents section.

• version: This is the version of the access summary export. See the Versioning section for additional details.

To find the date of the access summary export data, view the EXPORT_DATE column in each file.

Viewing the export

For the best experience, have any users viewing the access summary export query it through a view on top of an external table pointing to the exports in S3. This future-proofs your process when versions change.

Snowflake example

As an example, if you want to configure an external table in Snowflake for your export.

1. Set up a storage integration, file format, stage, AWS role, and AWS role policies in S3.

2. Run the following:

CREATE OR REPLACE EXTERNAL TABLE EXT_USER_METADATA_<version> (
    "user_id"            VARCHAR AS (VALUE:"user_id"::VARCHAR),
    "global_user_id"     VARCHAR AS (VALUE:"global_user_id"::VARCHAR),
    "email"              VARCHAR AS (VALUE:"email"::VARCHAR),
    "identity_source"    VARCHAR AS (VALUE:"identity_source"::VARCHAR),
    "global_permissions" ARRAY   AS (VALUE:"global_permissions"::ARRAY), -- List<String>
    "group_name"         VARCHAR AS (VALUE:"group_name"::VARCHAR),
    "attribute_key"      VARCHAR AS (VALUE:"attribute_key"::VARCHAR),
    "attribute_value"    VARCHAR AS (VALUE:"attribute_value"::VARCHAR),
    "source"             VARCHAR AS (VALUE:"source"::VARCHAR),
    "association"        VARCHAR AS (VALUE:"association"::VARCHAR),
    "export_date"        TIMESTAMP_NTZ AS (VALUE:"export_date"::TIMESTAMP_NTZ)
)
LOCATION = @<your-stage>/user-metadata/<version>/
FILE_FORMAT = <your-format>
AUTO_REFRESH = TRUE;

Then create a view on top of that external table by running the following:

CREATE OR REPLACE VIEW ACCESS_SUMMARIES.ACCESS_SUMMARIES_PRPR.USER_METADATA AS
SELECT 
    "user_id"            AS USER_ID,
    "global_user_id"     AS GLOBAL_USER_ID,
    "email"              AS USER_EMAIL,
    "identity_source"    AS AUTH_SOURCE,
    "global_permissions" AS GLOBAL_PERMISSIONS,
    "group_name"         AS USER_GROUP,
    "attribute_key"      AS ATTRIBUTE_KEY,
    "attribute_value"    AS ATTRIBUTE_VALUE,
    "source"             AS SOURCE,
    "association"        AS ASSOCIATION,
    "export_date"        AS EXPORT_DATE
FROM ACCESS_SUMMARIES.ACCESS_SUMMARIES_PRPR.EXT_USER_METADATA_<version>;

Versioning

The access summary export is versioned to ensure that any schema changes can be properly communicated and understood.

During the private preview and public preview, if a new version is created, the old version will stop receiving updates immediately. You will need to immediately update the external table to point to the new version's path and update your view.

However, once this feature become generally available, each new version will run in parallel with the prior version for a reasonable amount of time so that you can switch versions without any downtime.

Preview feature example

For example, if a new version of the tag-metadata file was released on 1/12/2026, these would be the exports:

1/11/2026

• s3://<your-bucket>/<your-path>/tag-metadata/v=prpr1/tag-metadata.parquet

1/12/2026

• s3://<your-bucket>/<your-path>/tag-metadata/v=prpr2/tag-metadata.parquet

1/13/2026

• s3://<your-bucket>/<your-path>/tag-metadata/v=prpr2/tag-metadata.parquet

Generally available example

This versioning plan is not set in stone, and Immuta is open feedback on it.

Private preview program

While the access summary is in private preview, additional metrics will be assessed.

Why are we doing this?

To truly validate the effectiveness of these exports, Immuta must test against real-world scenarios. This is a collaborative phase where both Immuta and your team will have access to your export data to refine the data model and ensure the insights generated are accurate and actionable for your organization.

Immuta employees won’t have access to your actual data stored in your data platform.

The only data Immuta employees can access and potentially will access is the access summary which is metadata already stored in Immuta. Only a small subset of Immuta employees who are directly working on this new capability will be able to access it in adherence to our well established control frameworks.

Privacy and data security

We want to be transparent about how your data is handled during this program:

• Metadata only: This feature is strictly limited to metadata already stored in Immuta. Immuta never accesses, processes, or stores your raw business data.

• Subprocessor disclosure: Some specific metadata exported by this feature is categorized as privacy-impacting and requires subprocessor notification. As such, that data will be stored and managed within our existing, vetted infrastructure.

• Established frameworks: We will utilize our current, SOC2-compliant subprocessors for this storage, ensuring that this data is protected by the same rigorous security standards you already expect from the Immuta platform.

Known limitations

• The policy-outcomes table only reflects global subscription policies. It ignores exceptions to masking policies (essentially column access) and local subscription policies (with the exception of manually added members).

• If your export job stops working, for example due to auth issues, there are no errors or notifications. You must notice the new files aren’t appearing. Observability may be added in the future. In the meantime, Immuta is monitoring it and can alert you.

• You can only configure the export via API; there is no UI.

• There is no way to alter the export schedule or increase/decrease its frequency. This may become more configurable, but the speed of the export across many customer environments must be monitored beforehand.

• There are no configuration details about sensitive data discovery (SDD) or identifiers in the export files, with the one exception being that the fact tags were placed by SDD is captured.

• No support for ADLS export currently.

Next steps

• Set up your access summary export

• Explore the access summary export schema

• See data model changes