# Access Summary Export

{% hint style="info" %}
**Early access program**

The access summary export is currently available to organizations through the early access program. This gives you exclusive access to the feature before it moves to private preview.

To learn more, see the [early access program section](#early-access-program).
{% endhint %}

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 and why. The access summary exports all the Immuta 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.

## Contents

<figure><img src="/files/Uh9qr1Et8D1spNzHOTyo" alt=""><figcaption></figcaption></figure>

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](/saas/govern/detect-your-data/access-summary-export/latest-access-summary-export-schema-reference-guide.md) 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](/saas/govern/detect-your-data/access-summary-export/set-up-access-summary-export.md), 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](#contents).
* `version`: This is the version of the access summary export. In the early access program, the version is `prpr1`. See the [Versioning section](#versioning) 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.

<details>

<summary>Snowflake example</summary>

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:

```sql
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:

```sql
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>;
```

</details>

## Versioning

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

During the early access program, 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](#viewing-the-export).

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.

{% tabs %}
{% tab title="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`
  {% endtab %}

{% tab title="Generally available example" %}
For example, if a new version of the `tag-metadata` file was released 4/12/2026:

**4/11/2026**

* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=1`**`/tag-metadata.parquet`

**4/12/2026**

* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=1`**`/tag-metadata.parquet`
* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=2`**`/tag-metadata.parquet`

**4/13/2026**

* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=1`**`/tag-metadata.parquet`
* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=2`**`/tag-metadata.parquet`

...

**4/29/2026**

* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=1`**`/tag-metadata.parquet`
* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=2`**`/tag-metadata.parquet`

**4/30/2026**

* `s3://<your-bucket>/<your-path>/tag-metadata/`**`v=2`**`/tag-metadata.parquet`
  {% endtab %}
  {% endtabs %}

{% hint style="info" %}
This versioning plan is not set in stone, and Immuta is open feedback on it.
{% endhint %}

## Early access program

You have been selected for this program because of your interest in advanced reporting from Immuta metadata. As an early adopter, you are gaining exclusive access to this feature before it moves into private preview.

#### Why are we doing this?

To truly validate the effectiveness of these exports, we need to move beyond hypothetical models and 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.

{% hint style="info" %}
Immuta employees won’t have access to your actual data stored in your data platform.
{% endhint %}

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 that is 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 early access data is protected by the same rigorous security standards you already expect from the Immuta platform.

## Known limitations

* If your export job stops working, for example due to auth issues, you have no way of knowing other than noticing the new files aren’t appearing. We may add some observability for that. In the meantime, we are monitoring it and can alert you.
* You can only configure the export via API; there is no UI for this. We may add a UI component.
* There is no way to alter the export schedule or increase/decrease its frequency. We may make this more configurable, but we want to test the speed of the export across many customer environments before we make this decision.
* The `policy-outcomes` table only reflects **global** subscription policies. It ignores exceptions to masking policies (essentially column access) and local subscripiton policies (with the exception of manually added members). We need to make some significant backend changes before we can calculate this across the entire state of Immuta, but those are planned.
* 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](/saas/govern/detect-your-data/access-summary-export/set-up-access-summary-export.md)
* [Explore the access summary export schema](/saas/govern/detect-your-data/access-summary-export/latest-access-summary-export-schema-reference-guide.md)
* [See data model changes](/saas/govern/detect-your-data/access-summary-export/early-access-data-model-changes.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.immuta.com/saas/govern/detect-your-data/access-summary-export.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.