BigQuery access control has layers. IAM sets who can do what on projects, datasets and tables. For finer control there are authorized views, row-level policies and column-level policy tags.
IAM
Roles such as BigQuery Data Viewer, Data Editor and Job User are granted to users, groups or service accounts at the project, dataset or table level. A common split is that people get Job User on a project (to run queries, which is where cost is billed) and Data Viewer only on the datasets they should read. Granting at the dataset level is the usual compromise between control and effort.
Authorized views and datasets
An authorized view lets users query a view without having any access to the tables underneath. You authorize the view on the source dataset, and then give users access to the dataset holding the view.
raw dataset (no user access) <-- authorized view --> reporting dataset (users read here)
A view can hide columns and filter rows, for instance exposing only non-sensitive columns. An authorized dataset does the same for all views in a dataset at once.
Column-level security: policy tags
You build a taxonomy of policy tags (for example PII.email, PII.phone) in Data Catalog (now part of Dataplex), attach tags to columns, and grant the Fine-Grained Reader role on a tag only to those allowed. Others who select that column get an access denied error, or if you set up data masking rules on the tag, see a masked value (hash, null or a default) instead.
Row-level access policies
CREATE ROW ACCESS POLICY eu_only ON analytics.orders
GRANT TO ('group:eu-analysts@company.com')
FILTER USING (region = 'EU');Members of the group see only EU rows.
Choosing
Share a safe slice of data to other teams: authorized view. Hide specific sensitive columns across many tables: policy tags. Split rows by team: row-level policies. Keep IAM simple with groups, never individual users, and review it regularly.