The two schemas this route is built on hold different things: one is a working tool, the other is a record of what named people did. Granting them together is the mistake, and it is made in a single statement.
Audit data records who did what, when, and from which IP address. In several European jurisdictions that is employee monitoring data, and in Germany it is the kind of thing a works council has a legitimate interest in. It is not a debugging convenience to be granted broadly because it happens to be read-only.
Why
Granting SELECT on the whole system catalog to the engineering group is a two-minute decision that hands out billing data, every principal's activity history, and — through query history — statement text containing whatever literals people typed into WHERE clauses. Some of those literals are customer email addresses.
The self-referential problem sharpens it: whoever reads the audit log can see who reviewed what and when. If that is the same group that issues grants, the review has no independence, and a regulator who notices will say so.
How
sqlGrant the audit schema deliberately — not the whole system catalog
-- Evidence: governance group only.
GRANT USE CATALOG ON CATALOG system TO `dwh-governance`;
GRANT USE SCHEMA ON SCHEMA system.access TO `dwh-governance`;
GRANT SELECT ON TABLE system.access.audit TO `dwh-governance`;
GRANT SELECT ON TABLE system.access.table_lineage TO `dwh-governance`;
GRANT SELECT ON TABLE system.access.column_lineage TO `dwh-governance`;
-- Working tool: engineers get lineage, and not audit.
GRANT USE CATALOG ON CATALOG system TO `dwh-engineers`;
GRANT USE SCHEMA ON SCHEMA system.access TO `dwh-engineers`;
GRANT SELECT ON TABLE system.access.table_lineage TO `dwh-engineers`;
GRANT SELECT ON TABLE system.access.column_lineage TO `dwh-engineers`;
The split is the point. Lineage is a daily engineering tool and withholding it makes the team slower for no benefit. The audit log is evidence about people, and it belongs to a group accountable for handling it.
Doing it
Grant system.access at table level to a governance groupNever grant SELECT on the system catalog as a whole.
Give engineers lineage and withhold auditThe working tool and the evidence have different audiences.
Check who currently holds access to system.* before writing the permissions conceptIt is usually broader than anyone believes.
If retention beyond a year is a genuine requirement, agree an archive owned by complianceEvidence held by the audited team is not evidence.
Embedding it
Ask the team who should be able to see that a named colleague queried a table at 23:40 on a SundayThe discomfort in the room is the argument; you do not have to make it.
Have them run the check on their own metastore and report the current holders of system access to their leadFinding it themselves turns your policy into their finding.
Raise the works-council question early with the client's own peopleIn DACH engagements it is a schedule risk, not a footnote.
Defaults
Table-level grants on system.access, to groups, never to individuals
Lineage for engineers, audit for governance — two grants, two audiences
Whoever reviews access is not whoever issues grants
Gotchas
GRANT SELECT ON CATALOG system as a convenienceIt includes billing, query history and audit in one statement, and the exposure surfaces later when someone reads a colleague's query text — a trust incident, not a technical one.
The team that issues grants also owning the access reviewNothing technical breaks; the evidence just stops meaning anything, and only an external auditor notices.
Exporting the audit log to a spreadsheet for a review meetingIt leaves Unity Catalog and the copy is ungoverned personal data with no expiry — the same dead end as any CSV export.
Assuming system tables cannot leak because they are read-onlyRead-only is what makes them trustworthy evidence; it says nothing about who should be reading them.