SOX access evidence in Snowflake, Databricks and Redshift: approvals, leavers and segregation of duties

What the SEC and the statute say about access

Section 404(a) of the Sarbanes-Oxley Act directs the SEC to require each annual report to contain an internal control report that, under (a)(2), must contain an assessment, as of the end of the most recent fiscal year of the issuer of the effectiveness of the internal control structure and procedures of the issuer for financial reporting, and 404(b) says the outside auditor shall attest to, and report on, the assessment. Section 404(b) does not apply to an emerging growth company, and Section 404(c) removes the attestation for issuers that are neither large accelerated filers nor accelerated filers, so check which you are (15 U.S.C. 7262 (SOX Section 404) (read 2026-10-31), subsections (a)(2), (b) and (c)).

The SEC’s interpretive guidance for management names access in its own words: For purposes of the evaluation of ICFR, management only needs to evaluate those IT general controls that are necessary for the proper and consistent operation of other controls designed to adequately address financial reporting risks. For example, management might consider whether certain aspects of IT general control areas, such as program development, program changes, computer operations, and access to programs and data, apply to its facts and circumstances. (SEC Release 33-8810 (read 2026-10-31), section II.A.1.d, page 20). Footnote 37 adds: However, the reference to these specific IT general control areas as examples within this guidance does not imply that these areas, either partially or in their entirety, are applicable to all facts and circumstances.

We looked for PCAOB AS 2201 and could not read it (the PCAOB site answered us with a bot check), so this page does not say what it requires. What follows is our reading of what “access to programs and data” means for financial tables in a data platform: three questions an auditor can put to the records. Which of them your auditor asks, and what they accept as an answer, is the auditor’s call.

1. Approvals. For each access granted to a financial table, is there an approval, and is it dated on or before the grant, by someone other than the person who got the access?
2. Leavers. For each person HR says left, was access to the financial table removed, how many days after the last day, and did the account use the table after that?
3. Segregation of duties. Did anyone both change a financial table and run or approve access to it?

What you will have at the end

A Python script, sox_access_evidence.py, that reads each platform’s own access records, exported as CSV with the platform’s published column names, plus your approval log, an HR leaver file and a login map. It runs eleven input checks first, then prints the 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, never as clean. 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. This page produces evidence. It does not say a control is satisfied or that anyone will pass an audit.

Step 4. Turn each platform’s records into the same three events

The platforms record access differently, so the script first reduces each to grants, removals and use of the financial tables, at login level, then matches logins to people.

Snowflake. A person gets access by being granted a role. The script joins each GRANTS_TO_USERS row to the privileges that role holds on a financial table in GRANTS_TO_ROLES at that moment. GRANTS_TO_USERS carries DELETED_ON, which Snowflake documents as the time the role was revoked from the user, and which stays empty while the grant is active (Snowflake: GRANTS_TO_USERS (read 2026-10-31)). The person who ran the grant is not in that view: the script assumes GRANTED_BY is the role the grant ran under and looks in QUERY_HISTORY for the GRANT statement run under that role within 60 seconds that names the role and the grantee. If it finds none, the row shows a dash for the person and counts as follow-up. Writes come from ACCESS_HISTORY, whose OBJECTS_MODIFIED is a JSON array of the objects associated with a write (Snowflake: ACCESS_HISTORY (read 2026-10-31)).

        con.execute(f"""CREATE TABLE sf_acc AS
            SELECT u.ts, u.end_ts, u.login, u.role, u.granted_by, r.obj, string_agg(DISTINCT lower(replace(r.privilege, '_', ' ')), ',' ORDER BY lower(replace(r.privilege, '_', ' '))) AS privs
            FROM sf_gu u JOIN sf_gr r ON r.role = u.role AND r.obj IN (SELECT obj FROM scope WHERE platform = 'snowflake')
                 AND lower(replace(r.privilege, '_', ' ')) IN (SELECT p FROM privs) AND r.ts <= u.ts AND (r.end_ts IS NULL OR r.end_ts > u.ts)
            WHERE u.ts IS NOT NULL GROUP BY ALL""")

        con.execute("""CREATE TABLE sf_g AS WITH m AS (
              SELECT a.*, q.login AS grantor, row_number() OVER (PARTITION BY a.ts, a.login, a.role, a.obj
                       ORDER BY abs(epoch(q.ts) - epoch(a.ts))) AS rn
              FROM sf_acc a LEFT JOIN sf_qh q ON q.query_type = 'GRANT' AND q.role = a.granted_by
                   AND abs(epoch(q.ts) - epoch(a.ts)) <= 60 AND contains(q.text, a.role) AND contains(q.text, a.login))
              SELECT * FROM m WHERE rn = 1""")

Databricks. The audit table records the user, service, action, request parameters and response of each event (Databricks: audit log system table (read 2026-10-31)). The script reads updatePermissions events under unityCatalog and takes the table from securable_full_name and the principals and privileges added or removed from changes. Databricks’ audit log reference lists securable_full_name and changes as the request parameters of updatePermissions (Databricks: audit log reference (read 2026-10-31)), and the system-table page shows full_name_arg and a statusCode in its examples. It does not document the layout inside changes, so how the script reads the principals and privileges added or removed is our assumption: open one of your own events and check it. It counts only events whose response status is 200: a permission change with another status is left out and counted on an [info] line, a read with another status is a refused attempt and not use, and an event on a financial table whose status cannot be read fails an input check (events on other tables are not looked at). If your export carries no status on some of those events, that check will fail on clean data: open one of your own events and check. Writes come from the lineage table’s target_table_full_name and created_by (Databricks: lineage system tables (read 2026-10-31)).

Redshift. Grants and revokes are in STL_UTILITYTEXT, where a statement longer than 200 characters is stored in pieces ordered by sequence (Amazon Redshift: STL_UTILITYTEXT (read 2026-10-31)). The script puts them back in order, strips comments, and parses GRANT and REVOKE with one privilege list, one table and one grantee. A GRANT or REVOKE that names a financial table in full but does not fit the one-table, one-grantee pattern fails an input check. The user id becomes a name through SYS_QUERY_HISTORY’s username (Amazon Redshift: SYS_QUERY_HISTORY (read 2026-10-31)); a dropped user is a removal in SYS_USERLOG (Amazon Redshift: SYS_USERLOG (read 2026-10-31)).

        # a statement longer than 200 characters is stored in pieces: put them back in order, as AWS shows
        con.execute(f"""CREATE TABLE rs_dcl AS
            WITH st AS (SELECT uid, xid, pid, st_text, min(ts) AS ts,
                          string_agg(CASE WHEN len(rtrim(text)) = 0 THEN text ELSE rtrim(text) END, '' ORDER BY seq) AS stmt
                        FROM rs_ut GROUP BY uid, xid, pid, st_text),
                 cl AS (SELECT *, trim(regexp_replace(stmt, '/\\*.*?\\*/', '', 'gs')) AS s FROM st)
            SELECT uid, ts, s, lower(regexp_extract(s, '{DCL_RE}', 1)) AS kind, regexp_extract(s, '{DCL_RE}', 2) AS privs,
                   lower(replace(regexp_extract(s, '{DCL_RE}', 3), '"', '')) AS obj,
                   lower(replace(regexp_extract(s, '{DCL_RE}', 4), '"', '')) AS grantee
            FROM cl WHERE regexp_matches(s, '(?i)^\\s*(grant|revoke)\\b')""")

People. A login that is itself an email address is the person; any other login needs a row in login_map.csv. Emails are lower-cased and trimmed, so Ana.Ruiz@Corp.Example in the approval log and ANA.RUIZ@CORP.EXAMPLE in Snowflake are the same person. A login that wrote to a financial table or ran a grant and matches no person is listed, never dropped.

Step 5. List 1: was each access approved, and before it was given?

Every grant the script can see on the tables you name, in the period, is matched to an approval for the same person and table. If more than one approval exists, the closest one dated on or before the grant wins, and only if there is none is the closest later one used. The status is then NO APPROVAL, SELF-APPROVED (the approver is the person who got the access), APPROVED AFTER GRANT, or approved before grant. The script checks the approval’s date, not who the approver should have been: whether that person was entitled to approve is for you and your auditor.

        WITH g AS (SELECT row_number() OVER (ORDER BY ts, platform, login, obj, privs) AS gid, * FROM grants_r
                   WHERE ts::DATE BETWEEN DATE '{p0}' AND DATE '{p1}'),
             cand AS (SELECT g.gid, a.approver, a.approved_on,
                        row_number() OVER (PARTITION BY g.gid ORDER BY CASE WHEN a.approved_on <= g.ts::DATE THEN 0 ELSE 1 END,
                                           abs(date_diff('day', a.approved_on, g.ts::DATE)), a.approver = coalesce(g.email, g.login), a.approver) AS rn
                      FROM g JOIN approvals a ON a.grantee = coalesce(g.email, g.login) AND a.obj = g.obj AND a.approved_on IS NOT NULL
                           AND a.approver <> '')
        SELECT g.platform, g.ts::DATE AS granted_on, coalesce(g.email, g.login) AS grantee, g.obj AS object, g.privs,
               coalesce(g.grantor_email, g.grantor_login, '-') AS granted_by_person, c.approver, c.approved_on,
               CASE WHEN c.gid IS NULL THEN 'NO APPROVAL'
                    WHEN c.approver = coalesce(g.email, g.login) THEN 'SELF-APPROVED'
                    WHEN c.approved_on > g.ts::DATE THEN 'APPROVED AFTER GRANT'
                    ELSE 'approved before grant' END AS status
        FROM g LEFT JOIN cand c ON c.gid = g.gid AND c.rn = 1 ORDER BY g.ts, g.platform, grantee, g.obj, g.privs"""

Step 6. List 2: leavers, each departure on its own

The list starts from the HR file, not from the removal records, so a person who was never removed still appears. A leaver is listed on a platform if your exports show a grant to them there, or if their account used a financial table there after the grace period; anyone else appears only in the [info] count, so read that line. For each leaver and each platform where they held access to a financial table, the script finds the first removal record credited to that departure, counts the days since the last day of work, counts use of a financial table after a grace period of one day (GRACE_DAYS) and before the removal, and counts use after the removal. Use after the removal makes the row ACTIVE AFTER REMOVAL. Each removal is credited to one departure only: the latest HR last day on or before it, or, for a removal before every last day, the earliest last day it precedes by at most 30 days. So someone who left, was removed, came back and left again is two rows, and the first removal never counts for the second departure. For a person who later leaves again, use after the first removal is not counted against the first row, because a rehired person legitimately uses the table in the second stint. A leaver with no grant record on a platform is listed there only if their account used a financial table after the grace period, which is what a grant older than the exports looks like; otherwise the script counts them on an [info] line.

        WITH lv AS (SELECT email, last_day, lag(last_day) OVER (PARTITION BY email ORDER BY last_day) AS prev_last_day,
                           lead(last_day) OVER (PARTITION BY email ORDER BY last_day) AS next_last_day
                    FROM leavers WHERE email <> '' AND last_day IS NOT NULL),
             pairs AS (SELECT l.*, p.platform FROM lv l CROSS JOIN (VALUES {plat_vals}) p(platform)
                       WHERE l.last_day BETWEEN DATE '{p0}' AND DATE '{p1}' AND (EXISTS (
                         SELECT 1 FROM grants_r g WHERE g.email = l.email AND g.platform = p.platform AND g.ts::DATE <= l.last_day
                           AND (l.prev_last_day IS NULL OR g.ts::DATE > l.prev_last_day)) OR EXISTS (
                         SELECT 1 FROM usage_r u WHERE u.email = l.email AND u.platform = p.platform
                           AND u.ts::DATE > l.last_day + INTERVAL {GRACE_DAYS} DAY
                           AND l.next_last_day IS NULL))),   -- a rehire's earlier departure needs a grant record
             credited AS (SELECT e.email, e.platform, e.ts, coalesce(
                            (SELECT max(l.last_day) FROM lv l WHERE l.email = e.email AND l.last_day <= e.ts::DATE),
                            (SELECT min(l.last_day) FROM lv l WHERE l.email = e.email
                              AND l.last_day - INTERVAL {REMOVAL_WINDOW_DAYS} DAY <= e.ts::DATE)) AS last_day
                          FROM ends_r e WHERE e.email IS NOT NULL),
             rem AS (SELECT email, platform, last_day, min(ts) AS removed_at FROM credited WHERE last_day IS NOT NULL GROUP BY ALL),

Step 7. List 3: who both changed the ledger and gave access to it?

The script lists anyone who wrote to a financial table in the period and also ran a grant of access to one, or approved access to one, matching people by email across all platforms. Then it lists every login that matched no person.

        WITH w AS (SELECT email, count(*) AS writes, string_agg(DISTINCT platform, ',' ORDER BY platform) AS wrote_on FROM usage_r
                   WHERE is_write AND email IS NOT NULL AND ts::DATE BETWEEN DATE '{p0}' AND DATE '{p1}' GROUP BY 1),
             g AS (SELECT grantor_email AS email, count(*) AS grants_run FROM grants_r WHERE grantor_email IS NOT NULL
                   AND ts::DATE BETWEEN DATE '{p0}' AND DATE '{p1}' GROUP BY 1),
             a AS (SELECT approver AS email, count(*) AS approvals_given FROM approvals WHERE approver <> ''
                   AND obj IN (SELECT obj FROM scope) AND approved_on BETWEEN DATE '{p0}' AND DATE '{p1}' GROUP BY 1)
        SELECT w.email, w.writes, w.wrote_on, coalesce(g.grants_run, 0) AS grants_run, coalesce(a.approvals_given, 0) AS approvals_given,
               'WROTE AND ' || CASE WHEN g.grants_run > 0 AND a.approvals_given > 0 THEN 'GRANTED AND APPROVED'
                                    WHEN g.grants_run > 0 THEN 'GRANTED' ELSE 'APPROVED' END AS status
        FROM w LEFT JOIN g ON g.email = w.email LEFT JOIN a ON a.email = w.email
        WHERE coalesce(g.grants_run, 0) + coalesce(a.approvals_given, 0) > 0 ORDER BY w.email"""

Each list is fingerprinted with a SHA-256 of its rows, in the order written to its CSV. The fingerprint does not show the rows are right. It lets anyone who re-runs the script on the same files confirm they got the same rows, and shows if a list changed after it was handed over.

Run 2: the clean records, and the script passes

The same script on the same seed with --plant left off. All eleven input checks pass, all six grants were approved before they were given, all six leaver rows read removed in time (the rehired person included), no one both wrote and granted, and no login is unmatched. The script prints RESULT: NOTHING TO FOLLOW UP.

Command: run 2

python3 sox_access_evidence.py --demo

Output from our run 2

input     : GENERATED records (not a company's data), seed 228, plant=False
platforms : checked snowflake, databricks, redshift

== Input checks   (span checked for records: 2026-07-01 to 2026-10-15)
[ok  ] duplicate Snowflake query ids: 0
[ok  ] timestamps not written YYYY-MM-DD HH:MM:SS (UTC): 0
[ok  ] days with no records, per platform, from PERIOD_START to AS_OF: 0
[ok  ] scope names that match no grant, use or removal in the exports: 0
[ok  ] Databricks audit events or Snowflake write lists the script could not read: 0
[ok  ] Redshift GRANT or REVOKE on a financial table the script could not parse: 0
[ok  ] HR leaver rows with no email or no last day: 0
[ok  ] HR leaver rows whose last day is not written as YYYY-MM-DD: 0
[ok  ] approval rows with a blank grantee, table, approver or date: 0
[ok  ] approval rows whose date is not written as YYYY-MM-DD: 0
[ok  ] login map rows with a blank login or email: 0
[info] permission changes that failed (status not 200), left out: 1
[info] grants in the period where no person who ran them was found: 0

== Access approved before it was granted: sox_1_access_grants
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive)
filters   : grants of ['all', 'all privileges', 'delete', 'insert', 'modify', 'ownership', 'select', 'update'] on the tables in FINANCIAL_TABLES, granted in the period; one row per person and table
run at    : 2026-10-31 23:02:55 UTC
rows      : 6
sha256    : c391d1c2901596ca863849f2ba7f7681bf10389a209f75b4733e9662c6dce484
  snowflake | 2026-07-06 | f01@example.test | finance_db.ledger.gl_entries | select | a01@example.test | m01@example.test | 2026-07-03 | approved before grant
  databricks | 2026-07-08 | f01@example.test | finance.ledger.gl_entries | modify | a02@example.test | m01@example.test | 2026-07-07 | approved before grant
  redshift | 2026-07-15 | f02@example.test | ledger.gl_entries | insert | a01@example.test | m02@example.test | 2026-07-14 | approved before grant
  snowflake | 2026-07-22 | f03@example.test | finance_db.ledger.gl_entries | insert,select,update | a02@example.test | m02@example.test | 2026-07-20 | approved before grant
  databricks | 2026-07-28 | f08@example.test | finance.ledger.gl_entries | select | a02@example.test | m02@example.test | 2026-07-27 | approved before grant
  databricks | 2026-08-03 | f04@example.test | finance.ledger.gl_entries | select | a01@example.test | m01@example.test | 2026-08-01 | approved before grant

== Leavers: sox_2_leavers
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive)
filters   : HR leavers with last day in the period who held access to a financial table on the platform, or used one after the grace period; removal records credited to one departure; grace 1 day(s)
run at    : 2026-10-31 23:02:55 UTC
rows      : 6
sha256    : 0ce33859d8fc8b2872d8cbe4f8b341a7d142d6e365ae7d9a10a4757a3fac2345
  f08@example.test | 2026-07-10 | databricks | 2026-07-11 | 1 | 0 | 0 | removed in time
  f05@example.test | 2026-08-07 | databricks | 2026-08-08 | 1 | 0 | 0 | removed in time
  f05@example.test | 2026-08-07 | snowflake | 2026-08-08 | 1 | 0 | 0 | removed in time
  f06@example.test | 2026-08-21 | redshift | 2026-08-22 | 1 | 0 | 0 | removed in time
  f07@example.test | 2026-09-04 | snowflake | 2026-09-05 | 1 | 0 | 0 | removed in time
  f08@example.test | 2026-09-18 | databricks | 2026-09-19 | 1 | 0 | 0 | removed in time
[info] HR leavers in the period with no grant on a financial table and no use after the grace period seen on snowflake, so not listed there: 3
[info] HR leavers in the period with no grant on a financial table and no use after the grace period seen on databricks, so not listed there: 2
[info] HR leavers in the period with no grant on a financial table and no use after the grace period seen on redshift, so not listed there: 4

== Segregation of duties: sox_3_segregation_of_duties
period    : 2026-07-01 to 2026-09-30 (UTC, inclusive)
filters   : people (matched by email across platforms) who wrote to a financial table and also ran a grant of access to one or approved access to one, in the period
run at    : 2026-10-31 23:02:55 UTC
rows      : 0
sha256    : e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
[info] logins that wrote to a financial table or ran a grant and match no person (add them to login_map): 0

== Result
input checks : all passed
not checked  : none
follow-up    : 0 grant row(s), 0 leaver row(s), 0 segregation or login row(s) need an explanation
RESULT: NOTHING TO FOLLOW UP

“Nothing to follow up” says only that the input passed its checks and that no row in the three lists needed an explanation. It does not say a control is satisfied, and it covers only the platforms in PLATFORMS_EXPORTED: a platform left out is printed as NOT CHECKED, and the result line then says so instead of reading as clean.

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 (228). The approval log, the HR file and the login map are generated too.
• Period: 2026-07-01 to 2026-09-30, UTC, inclusive, for grants, approvals and writes. Completeness is checked from the period’s start to AS_OF (2026-10-15), because a removal and later use can fall after the period ends.
• Use of a financial table is a successful query whose text, with double quotes removed, contains the table’s full name (Snowflake EXECUTION_STATUS success, Redshift not failed or canceled), an audit event with status 200 naming it in full_name_arg (Databricks), or a write recorded by ACCESS_HISTORY or the lineage table. A query that copies a financial table into another table counts as use of the financial table. A write on Redshift is an INSERT, UPDATE, DELETE or COPY whose target is the financial table; one that only reads it to fill another table is use, not a write.
• Privileges that count as access are written at the top of the script (ACCESS_PRIVILEGES), so you can disagree with them. Underscores in privilege names are read as spaces, so Databricks’ ALL_PRIVILEGES is all privileges. The grace period and the removal window are set there too.
• Unreadable input is counted, not dropped: a failed input check marks every list INCOMPLETE; a leaver with no grant record is counted, and listed if they used a financial table after the grace period; an unmatched login that wrote or ran a grant is listed. The Limits below list what the script cannot see.

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, and the layout of the changes field in a Databricks permission change is our assumption.
• These three tests are our reading, not a list from the SEC, the PCAOB or an auditor. We did not read PCAOB AS 2201. Your auditor decides what to test and what evidence to accept, and a different scope can need different lists.
• A role that gains a privilege after a person received it is not seen as a new grant on Snowflake, because the script looks at what the role held when the user was granted it.
• Use is matched on the table’s full name in query text, with double quotes removed. A query that names the table by a shorter name after a USE statement is not matched.
• An approval is matched to a person and a table, not to a privilege. An approval for read access also covers a later grant of more privileges on the same table; check the privileges column of List 1 against what was approved.
• Access that reaches a financial table by another route is not seen: a role granted to another role on Snowflake; a grant on a schema or catalog on Databricks; ALL TABLES IN SCHEMA, a schema grant or group membership on Redshift. The script reads a role granted directly to a user, table-level updatePermissions events, and GRANT ... ON a named table.
• Timestamps with no zone suffix are taken as UTC. Snowflake exports follow the session time zone, so set it to UTC before you export.
• Group and role principals on Databricks and Redshift are treated as logins: they appear in list 1 under the group’s name and match no approval unless your log uses the same name.
• After a first removal, use is not counted for someone who later leaves again. That use is taken to be the second stint, so a removal that did not take before the rehire is not flagged.
• The approver’s authority is not checked, only that the approval exists, is dated, and is not the grantee. A grant approved by a person who had no right to approve passes this test.
• A removal record is not proof of logout. The script counts later use of the financial table as a second signal; a person can also read the data through a shared account or an extract.
• Coverage: only what each platform records, for as long as it keeps it. Redshift keeps seven days in the STL views unless you export them.
• The empty-day check can fire on a quiet day, and cannot see a day that has some records but not all.

Tested on

When this is not enough

• You need every quarter, not one run. The script is a point-in-time pull. Keep each pull’s settings and the lists as produced.
• Your platforms are not these three, or your approvals live in a system you cannot export. The approvals test is only as good as the approval log.
• The control is more than a list. The policy, the review and the sign-off sit in your ticket and HR systems, not in the platforms’ records.
• Legal and audit advice are not here. Whether a list is enough is for your auditor.