SOC 2 user access evidence for Snowflake, Databricks and Redshift: three lists and a check for missing users

What the criteria cover, in our words

The AICPA’s Trust Services Criteria are licensed text, so this page names criteria by id and describes them in our own words; it quotes none of them (AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022) (read 2026-11-01)). CC6.1 is about logical access security, including identifying and authenticating users. Multifactor authentication appears in one of its points of focus, as an example of stronger authentication where an organization’s own risk strategy calls for it, so this page never says SOC 2 requires it: your own policy decides, which is why the sign-in policy in the script is a setting with no default. CC6.2 is about registering and authorizing users before they are given credentials, and removing credentials when access is no longer authorized; its points of focus include reviewing credentials for validity, including system or service accounts that should not be there. CC6.3 is about authorizing, changing and removing access according to people’s roles and duties, or how the system is built, with regard to least privilege and segregation of duties.

Points of focus describe characteristics, not requirements. We do not know what any particular auditor will sample, and this page does not say. What follows is our reading: those three criteria are about who has an account, who can administer, and how people authenticate, so each of those is a list you can build from the platforms’ own records, and the first list is only worth showing if you can also show it is not missing anyone. Ask your auditor for their sample request, then check it against the lists below. Approvals before a grant and the timing of a leaver’s removal are in our SOX access evidence guide; this page does not repeat them.

What you will have at the end

A Python script, soc2_user_access_evidence.py, that reads each platform’s own account and sign-in records, exported as CSV with the platform’s published column names, plus an HR file, a login map, a service-account owner list, an approved-administrator list and your own sign-in policy. It runs twenty-nine input checks first, then prints three lists, each with its period, its filters, the run time, its row count and a SHA-256 of its rows, and writes each as a CSV. A platform you do not export is printed as NOT CHECKED, and the result line names it. The details are also in a PDF: Download the full guide (PDF).

The records we ran it on are generated: a seeded stand-in, not a company’s data and not a measurement of anything. We have not run the script on a real Snowflake, Databricks or Redshift account. The script produces evidence; it does not say a criterion is met or that anyone will accept it.

Step 3. What each list does

The user listing has one row per account that existed at any time in the period. Snowflake rows run from CREATED_ON to DELETED_ON. We treat a blank or PERSON type as a person and any other Snowflake type as a service account (the USERS page names SERVICE and SNOWFLAKE_SERVICE among its types and links the full list; this rule is ours, so check your own TYPE values; Snowflake: USERS (read 2026-11-01)). Any login in your owners file is a service account, on every platform. A person is matched to HR by the login map, then by a login that is itself an email, then by the email the platform holds. The flags: NO PERSON (no HR match), LEFT BUT ENABLED (an HR leaver whose account is still enabled at AS_OF: the timing is the SOX guide’s), SERVICE NO OWNER (no owner, or an owner HR does not know or who has left).

The completeness check is the part to show first. The script takes every login seen in a successful sign-in during the period and looks for it in the listing. One that is not there is LOGIN NOT IN LISTING: on Snowflake, whose USERS view keeps deleted accounts with their DELETED_ON, the likely cause is a filtered export; on Databricks and Redshift it can also be an account removed since, and on Databricks a service principal, which the users export does not hold. On Databricks and Redshift, whose lists show only today’s accounts, a login that HR says has left is printed as LEFT, NO LONGER LISTED, which is not counted as an exception. The check is this code:

    seen_logins = sorted({(p, l) for p, l, _, _ in signins if (p, l) not in by_login})
    for p, l in seen_logins:
        who_ = person_of(p, l, "")
        status = "LEFT, NO LONGER LISTED" if p != "snowflake" and who_ in leaver else "LOGIN NOT IN LISTING"
        rows1.append((p, l, "(not in listing)", who_ or "", "", n_in[(p, l)], status))

The administrators list is who holds an administrator right at the end of AS_OF: a Snowflake role named in ADMIN_ROLES (GRANTS_TO_USERS rows still open), a Redshift superuser, or an active member of the Databricks admins group, compared with your approved list (NOT ON ADMIN LIST). A second list gives the Snowflake administrator grants made in the period with their date and the granting role; GRANTED_BY is a role, not a person (Snowflake: GRANTS_TO_USERS (read 2026-11-01)).

The sign-in list counts every successful sign-in in the period per login and method (Snowflake IS_SUCCESS is yes, a Databricks status of 200, a Redshift authenticated event) and compares the method with the ones your policy allows for that account type: OUTSIDE POLICY. A Databricks token created in the period with no expiry, or one lasting longer than MAX_TOKEN_DAYS, is OUTSIDE POLICY too; the audit log also records tokens the service itself generates under the same action, so check who created each. A sign-in or a token after the person’s HR last day is AFTER LAST DAY, whether or not the account is still listed.

Step 4. Run it on the clean generated records

Run python3 soc2_user_access_evidence.py --demo. It writes the generated exports to a folder called generated and its lists to evidence-out. The output below is the end of the run: all twenty-nine input checks printed [ok], and a list prints only the rows to explain when it has more than twelve rows. The only row printed is a Redshift user HR says has left and the listing no longer shows, which is informational.

== User listing (accounts during the period): soc2_1_user_listing
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive); accounts and administrators as of 2026-10-15
filters   : every account that existed at any time in the period (Snowflake: CREATED_ON to DELETED_ON; Databricks and Redshift export only the accounts that exist at the export, so a removed account is not listed), plus any login seen signing in that the listing lacks; one row per account
run at    : 2026-11-01 12:06:04 UTC
rows      : 18
sha256    : 0ebe371093250d154f626069812b51e034b6b9959fb877cdf0241af3738e99ec
  redshift | eli | (not in listing) | p06@example.test | - | 8 | LEFT, NO LONGER LISTED

== Administrators at AS_OF against the approved list: soc2_2_administrators
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive); accounts and administrators as of 2026-10-15
filters   : Snowflake: users holding a role named in ADMIN_ROLES (GRANTS_TO_USERS rows open at the end of AS_OF); Redshift: superusers; Databricks: active members of admins; one row per account and right
run at    : 2026-11-01 12:06:04 UTC
rows      : 4
sha256    : c8f436efb4bf9bc2c3f2f6cee2c29d0f7c6cedf1ee90ebec3e3316c6a488046b
  databricks | p01@example.test | p01@example.test | group admins | - | approved
  redshift | ana | p01@example.test | superuser | - | approved
  snowflake | p01 | p01@example.test | role ACCOUNTADMIN | 2026-01-05 | approved
  snowflake | p02 | p02@example.test | role SECURITYADMIN | 2026-08-12 | approved

== Administrator role grants made in the period: soc2_2b_admin_grants_in_period
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive); accounts and administrators as of 2026-10-15
filters   : Snowflake GRANTS_TO_USERS rows for ADMIN_ROLES with CREATED_ON in the period; the granter is a role, not a person; Databricks and Redshift: these exports do not record who made a grant
run at    : 2026-11-01 12:06:04 UTC
rows      : 1
sha256    : 63daf5720760ea655da872b577d48ae3a5b24face2bfeeda7dc43bdddb2d34c4
  2026-08-12 | SECURITYADMIN | p02 | ACCOUNTADMIN | yes

== Successful sign-ins by method, and tokens created, against your policy: soc2_3_signins_against_policy
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive); accounts and administrators as of 2026-10-15
filters   : successful sign-ins in the period (Snowflake IS_SUCCESS, Databricks status 200, Redshift event authenticated), one row per login and method; the allowed methods come from POLICY by account type; AFTER LAST DAY counts sign-ins after the person's HR last day; a token is OUTSIDE POLICY with no expiry or a lifetime over 90 days
run at    : 2026-11-01 12:06:04 UTC
rows      : 20
sha256    : 5d6a29f31063c94126c57fe4a8eb4993a9d797c6ba5f5e4bb9b85c8387c86402

== Result
input checks : all passed
not checked  : none
follow-up    : 0 account row(s) to explain, 0 administrator row(s) not on the approved list, 0 sign-in or token row(s) outside policy or after a last day
RESULT: NOTHING TO FOLLOW UP

The same clean run on duckdb 2.0.0 printed the same four SHA-256 values, so the fingerprints do not depend on the DuckDB release (shown: the user listing’s).

== User listing (accounts during the period): soc2_1_user_listing
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive); accounts and administrators as of 2026-10-15
filters   : every account that existed at any time in the period (Snowflake: CREATED_ON to DELETED_ON; Databricks and Redshift export only the accounts that exist at the export, so a removed account is not listed), plus any login seen signing in that the listing lacks; one row per account
run at    : 2026-11-01 12:06:14 UTC
rows      : 18
sha256    : 0ebe371093250d154f626069812b51e034b6b9959fb877cdf0241af3738e99ec
  redshift | eli | (not in listing) | p06@example.test | - | 8 | LEFT, NO LONGER LISTED

How to read the results

• INCOMPLETE on a list means an input check failed: the list may be missing rows. Fix the export, or explain a quiet day in KNOWN_GAPS, before you show it to anyone.
• NO PERSON is an account HR cannot match. It may be a contractor or a missing login-map row; the list cannot tell which.
• LEFT BUT ENABLED is an HR leaver whose account is still enabled. SERVICE NO OWNER is a service account nobody answers for.
• LOGIN NOT IN LISTING is a login that signed in but the listing lacks. On Snowflake the likely cause is a filtered export; on Databricks and Redshift it can also be an account deleted since; find out which before you show the listing as complete.
• LEFT, NO LONGER LISTED is a Databricks or Redshift login that HR says has left and the current user list no longer shows. It is informational and is not counted.
• NOT ON ADMIN LIST is an administrator your approved list does not name. The list may be out of date, so it is a question, not a verdict.
• OUTSIDE POLICY is a sign-in method or a token your own policy does not allow for that account type. The script compares strings with your policy; whether the policy is right is yours to decide.
• AFTER LAST DAY is a sign-in or token after the person’s HR last day. It is counted whether or not the account is still listed.
• Keep each run’s settings, its SHA-256 lines and the CSVs it wrote. Your auditor decides what they show.

Method

• Input: generated records written by the script as CSV in each platform’s published column names (the links in step 1), with a fixed seed (230). The HR file, login map, owner list and approved list are generated too. The people, logins and accounts are invented.
• Period: 2026-07-01 to 2026-09-30, UTC, inclusive, for the sign-ins and the accounts. Administrators and enabled accounts are read as of the end of AS_OF (2026-10-15). Completeness is checked for every day from the period’s start to AS_OF on each platform.
• A successful sign-in is a Snowflake LOGIN_HISTORY row with IS_SUCCESS yes, a Databricks accounts audit row whose action is in DATABRICKS_LOGIN_ACTIONS with a status of 200, or a Redshift SYS_CONNECTION_LOG row with the event authenticated. A refused attempt is not counted.
• Who is a service account: any login in your owner file first, then a Snowflake user whose type is not blank or PERSON. Everything else is a person, in every list.
• The demo policy is an example, not a recommendation of what any account type should use: people sign in by single sign-on, IAM or a password with a second factor; service accounts by key pair, token, IAM or (on Redshift) a password; and tokens last at most ninety days.
• Unreadable input is counted, not dropped: a failed input check marks every list INCOMPLETE. The Limits below list what the script cannot see.
• Input checks in the runs: of the twenty-nine input checks, five failed in the runs shown; the other twenty-four are written to fail on the fault their labels name and were not triggered.

Limits

• This is not a client result. The records are generated. The runs show that the script finds planted faults. They say nothing about any real company or how often such faults occur.
• We have not run it on a real account. Real exports can differ from the documentation. These are our assumptions, so open one of your own rows and check: Snowflake’s LOGIN_HISTORY USER_NAME is the user’s NAME in USERS; the Databricks sign-in event carries the user in request_params under user; tokenExpirationTime is Unix time in milliseconds, with an empty or zero value meaning no expiry (the Databricks page names the parameter but gives neither its format nor a default token lifetime; Databricks: audit log reference (read 2026-11-01)); a successful Databricks sign-in has statusCode 200 in response; a non-superuser’s export of SYS_CONNECTION_LOG comes back empty; the user lists of Databricks and Redshift hold only accounts that still exist; and a blank or PERSON Snowflake type is a person, any other a service account.
• The criteria are not a checklist. We describe CC6.1 to CC6.3 in our own words and do not quote them. Which lists an auditor asks for, and in what form, is theirs to say.
• The listing says who had an account, not whether the access was right. It shows no approvals and no access reviews. We read the Databricks and Redshift lists as of the export day, so a removal is seen only through a login in the sign-in records that HR matches to a leaver. On Redshift, SVV_USER_INFO has no disabled flag, so every listed account counts as enabled. Redshift’s external_user_id is the identity provider’s identifier (Amazon Redshift: SVV_USER_INFO (read 2026-11-01)); we use it as an email only when it is one, so add Redshift logins to the login map.
• Administrators are only those the settings name. A Snowflake role granted to another role, a nested Databricks group, a Databricks account admin (a role, not group membership) and a Redshift role other than superuser are not followed. Databricks service principals are not in the users export at all.
• Admin grants with a date and a granter exist only for Snowflake, and the granter is a role. The Databricks and Redshift exports here do not record who made a grant.
• Tokens: only tokens created in the period are listed. A token created earlier and still valid is not, and a revoked token is not followed.
• Sign-in methods are strings. A Databricks method is the audit log’s action name, and its authenticationMethod parameter is not read. A Snowflake second factor that is empty means none was recorded.
• The empty-day check can fire on a quiet day, and cannot see a day that has some records but not all. On Databricks only accounts rows count for a day, so make sure your audit export includes that service.
• Timestamps with no zone suffix are taken as UTC. Check the time zone of your own export session and set it to UTC before you export.

Tested on

When this is not enough

• You need more than one day’s pull. The script reads exports taken on one day. Keep each pull’s settings and the lists as produced, and take the exports often enough that your platforms’ own retention never leaves a gap.
• Your platforms are not these three, or you cannot export the records named in step 1.
• The criteria are more than three lists. Approvals, reviews and the policy itself sit in your own systems, not in the platforms’ records.
• Audit advice is not here. Whether a list is enough is for your auditor.