Data Access Governance: Software and Tools That Show Who Queries Each Column
Knowing who has access to a column is not the same as knowing who reads it. Datatrail shows the difference, from a read-only connection, in the first week.
Read-only connection. Datatrail never moves or mutates your data.
In short
Data access governance is the practice of controlling and evidencing who can see which data, and proving it after the fact. It splits into two halves: enforcement, which decides who is allowed in, and visibility, which shows who actually went in and where that data came from. Datatrail covers the visibility half. It connects to your warehouse read-only, reads Snowflake ACCESS_HISTORY and QUERY_HISTORY, and shows which roles and people genuinely query each sensitive column, joined to column-level lineage so you can also prove where that column originated.
Why it fits
Lean data teams who need defensible access and lineage evidence without a full governance program.
Who actually reads it
Datatrail reads ACCESS_HISTORY to show which roles and people genuinely query a sensitive column, so access reviews start from usage instead of from a grant list.
Lineage as the evidence
Column-level lineage from query logs is the where-did-this-come-from answer auditors want, generated automatically rather than documented by hand.
No multi-quarter program
Read-only connect means an answer the same week, not after a six-month catalog rollout nobody finishes.
Access granted is not access used, and the gap is where risk lives
Every access review starts from the grant list, because that is the artifact the warehouse hands you. Roles, grants, and the people in each role. It is a complete answer to the wrong question. What a reviewer actually needs to know is who has been reading a sensitive column, and the grant list overstates that by an order of magnitude in most organizations.
The gap is predictable. Roles accumulate. Somebody is added to ANALYST for one project in March and is still there in November. A service account gets broad read to unblock a migration and nobody revokes it. By the time an auditor asks who can see customer email addresses, the honest answer from the grant list is a few hundred principals, and the honest answer from the query logs is eleven people and two pipelines.
Warehouses already record the second answer. Snowflake keeps ACCESS_HISTORY, which logs the columns each query actually touched, not just the tables. Datatrail reads it read-only and turns it into the view a reviewer wants: for a given column, the roles and users who queried it, how often, and when they last did. That turns an access review from an inventory exercise into a short list of grants to revoke, which is the only version of the exercise that ever gets finished.
Where visibility stops and enforcement begins
We should be precise about the boundary, because this category contains two genuinely different products and buying the wrong one is a common and expensive mistake.
Enforcement tools decide, at query time, whether someone may see a row or a column, and mask or block it if not. That is policy-as-code, attribute-based access control, and dynamic masking, and it is what Immuta does, pushing enforcement natively into Snowflake, Databricks, BigQuery, and Starburst. Your warehouse also ships a version of it: Snowflake masking and row access policies, and fine-grained access control in Databricks Unity Catalog. If your requirement is that a contractor must never see a Social Security number, you need enforcement, and Datatrail is not it.
Visibility answers the questions that come afterward, and they are the ones that arrive with a deadline: who read this column last quarter, where did the data in it come from, and which downstream reports expose it. That is a lineage and access-history problem, and it is what we built. The two layers compose well, and most mature programs run both. Our data governance tools comparison lays out which vendors do which, including where each one publishes pricing.
The practical case for starting with visibility is that it costs a read-only role and a week, and it usually shrinks the enforcement problem before you buy an enforcement tool. Teams routinely find that half the sensitive columns they were preparing to write masking policies for have not been queried by a human in a year, at which point the cheaper control is revoking the grant. Pair it with column-level lineage and you can answer where the data came from in the same view.
Questions people ask
Data governance, answered
What is data access governance?
Data access governance is the practice of controlling and evidencing who can see which data. It covers defining access policies, enforcing them at query time, reviewing entitlements periodically, and producing evidence for auditors. In practice it splits into enforcement, which stops unauthorized access, and visibility, which shows what access was actually used and where the data came from. Most programs need both, and most tools do only one.
What is the difference between data access governance and data governance?
Data governance is the whole framework: what data exists, what it means, who owns it, how good it is, and who may use it. Data access governance is the security and entitlement slice of that framework. A general governance platform such as Collibra covers glossary, ownership, quality, and policy definition. An access governance tool concentrates on entitlements and enforcement, and is usually bought alongside a catalog rather than instead of one.
How do you audit who accessed a column in Snowflake?
Snowflake records column-level access in the ACCESS_HISTORY view in the ACCOUNT_USAGE schema, which logs the base columns each query actually read rather than just the tables named in the SQL. Querying it directly works but is awkward at scale, because you have to unpack nested access columns and join back to object metadata. Datatrail reads it on a read-only role and presents per-column reader lists with frequency and recency.
Does Datatrail enforce access policies?
No, and that is deliberate. Datatrail connects with a read-only role and never writes to your warehouse, so it cannot mask a column or block a query. It shows who read what, where the data came from, and what depends on it. If you need enforcement, use your warehouse native policies or a dedicated access governance platform, and run visibility alongside it.
More use cases
Related features
Map your lineage, end to end
Connect your warehouse read-only and see your lineage map in minutes. Datatrail never moves or mutates your data.