Secure your Google BigQuery surface
Dataset IAM granting broad read, authorised views bypassing controls, and no retention on sensitive tables. We don’t connect to Google BigQuery to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Google BigQuery goes wrong
BigQuery goes wrong through exports: data leaves through result exports to buckets far more often than through queries.
- Datasets shared with allAuthenticatedUsers or broad group bindings
- Authorised views granting access to underlying data beyond the intended scope
- Tables holding personal data with no expiration or retention policy
- Query results exported to buckets with weaker access control
- Service accounts with project-wide BigQuery data access
[02] What We Secure
What we watch, catch and fix on Google BigQuery
On BigQuery we audit export destinations alongside dataset IAM, because the destination usually has weaker controls than the source.
- Dataset-level IAM reviewed, since broad bindings here expose entire analytical estates
- Authorised view chains resolved to effective access
- Table expiration and retention checked against data policy
- Export destinations audited, because data leaves through exports more often than through queries
- Service account scope reduced
[03] Where It Lands
Where Google BigQuery lands in your registers
Every datastore becomes an asset register entry carrying its data classification, encryption state, and retention position. Access reviews cover database roles and grants alongside application access. The risk register maps each store to the specific exposure it represents — a production replica in a development environment is a named risk against a named asset, with an owner and a date.
[04] How We Engage
On Google BigQuery specifically
On Google BigQuery, we tighten dataset bindings and apply retention. Authorised view restructuring and column-level security rollout we plan with your data team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Google BigQuery FAQs
What BigQuery access does Konfirmity need?
Konfirmity needs the BigQuery Metadata Viewer and Data Viewer roles on the datasets in scope, plus access to audit logs. We read dataset structure, IAM bindings and query metadata rather than table contents.
Why do authorised views need special attention?
Because they grant access to underlying data without granting access to the underlying table, which makes the effective permission harder to see. A chain of authorised views can expose more than any single grant suggests, so we resolve them rather than reading them individually.
PostgreSQL
MySQL
MongoDB
Snowflake
Databricks