That should be captured in security, right? I.e. if someone has access to data the assumption is they are able to read it. Security audit can be done without the grain of select statements but rather the grain of changes to provisioning. Fundamentally, you have an issue even if someone did not actually read what they should not but could. Select audit can be useful for performance tuning but I would not classify it as “audit”, rather monitoring.

> if someone has access to data the assumption is they are able to read it.

This is not the case in most production for two major reasons:

1. Row-level security is expensive and hard to manage, so in most cases, users are granted the select privilege on table level. But indeed, it doesn't mean they should have access to all the rows in that table.

2. Power users should not have production accounts all the time. The production accounts should only be activated when power users have to perform the changes during the production change window.

So financial institutes usually generate two kinds of reports for audit/regulation purposes.

1. Report on the privileges and roles, which tells if a user should have those privileges and roles. This is a periodically static report.

2. Report on the actions a user has performed to see if these actions are part of the changes. This is a dynamic report in which we have to capture the select statements.

I can see the point around expensive row level security. Cannot see how it is harder to manage than to monitor though. Designing around risk acceptance of manual detective rather than preventative controls does not make this approach generally applicable or best practice, just a feasible one with conditions.