BigQuery Security Review
A BigQuery dataset’s IAM grants, row access policies and authorised views decide who can read which rows and columns. We test what those grants, exports and shared datasets actually allow. CREST-certified testers, fixed price from £3,280 for a 2-day single-project scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
BigQuery decides who can query which rows and columns through IAM roles, row access policies and policy tags, layered from the project down to a single column. We test which of those grants are actually live against what your business intended.
Why BigQuery security comes down to grants and policies
BigQuery grants live at three levels: the project, the dataset and, for finer control, an individual table or view. The predefined roles map to different levels of access, from BigQuery Data Viewer through BigQuery Data Editor to BigQuery Data Owner and BigQuery Admin, and Google’s own access control documentation lists each role’s exact permissions. We test whether a role granted at the project level, which reaches every dataset underneath it, was meant to be scoped to one dataset instead.
Where a table holds data for more than one customer or department, a row access policy filters which rows a query returns based on who is running it, and a policy tag on a column can mask or withhold a field from anyone without the Fine-Grained Reader role. We test whether those policies cover every column and table that needs them, and whether a join or a wildcard table query finds a way around a filter written for a single table.
Data leaves a dataset in more ways than a query returning results to a screen: an extract job can copy it to Cloud Storage, a BigQuery sharing listing can hand a subscriber a linked dataset, and a service account key used by a BI tool or pipeline can carry the same access outside any session a person is watching. We test whether a VPC Service Controls perimeter, Data Access audit logging and the credentials your integrations use are consistent with the access controls on the data itself, and check the same grants against our Snowflake security review where a business runs both.
SCOPE
What we review in a BigQuery project
Project and Dataset-Level IAM Roles
BigQuery Data Viewer, BigQuery Data Editor and BigQuery Data Owner can each be granted at the project or the dataset level, and a role granted on the project reaches every dataset underneath it. We test whether a broad project-level grant was meant to cover the whole warehouse or should have stayed scoped to one dataset.
Table and View-Level Access Grants
IAM permissions that begin with bigquery.tables can be granted directly on a table or view rather than only at the dataset or project level, and views are treated as table resources for this purpose. We check whether table- and view-level grants were set deliberately, not left inherited from a broader dataset or project role.
Public and Domain-Wide Access
Sharing a dataset outside your organisation means granting access to the special principals allUsers or allAuthenticatedUsers, and an organisation using domain restricted sharing needs an explicit policy exception before either principal can be added. We check whether any dataset, table or authorised view has been shared this way, deliberately or by mistake.
Service Accounts and Keys for Pipelines and BI Tools
Pipelines and BI tools typically reach BigQuery through a service account, and a downloaded key for that account grants the same access as any user credential if it leaks. We check which service accounts your integrations use, what roles they hold, and whether long-lived keys could be replaced with a more secure authentication method.
Row-Level Security and Row Access Policies
A row access policy adds a filter_expression to a table that works like a WHERE clause, so different callers of the same query see different rows depending on their identity. We test whether the filter actually covers every column that identifies a row’s owner, and whether a join to an unfiltered table exposes rows the policy was meant to hide.
Column-Level Security and Policy Tags
A policy tag applied to a column restricts who can see that column’s raw values, and reading it without the Fine-Grained Reader role returns masked data instead of an error. We check that every sensitive column has a policy tag attached, and that the accounts your pipelines and analysts use hold the reader role you intended, not the one they were left with.
Authorised Views and Authorised Datasets
An authorised view lets a group query results from a source dataset without being granted access to the underlying tables, and an authorised dataset extends the same idea to every view inside it. We test whether the view’s own query reintroduces access the underlying grants were meant to withhold, such as a select statement that exposes a masked or restricted column.
Data Exports, Extract Jobs and VPC Service Controls
An extract job can copy a table out of BigQuery to Cloud Storage, and BigQuery is one of the Google Cloud APIs a VPC Service Controls perimeter can restrict to stop that copy leaving the perimeter even when IAM alone would allow it. We check whether a perimeter is in place, what it actually covers, and whether an extract job can still move data past it.
Analytics Hub and Data Exchange Sharing
BigQuery sharing, formerly Analytics Hub, lets a publisher list a dataset for other teams or partners to subscribe to, and a subscriber gets a linked dataset without the data being copied. We test who holds the Analytics Hub Publisher and Subscriber roles, and whether a listing shares more than the authorised view Google recommends publishers use to control it.
Data Access Audit Logging
BigQuery is the exception to Google Cloud’s usual rule that Data Access audit logs are switched off by default, so table reads and query jobs are already being logged whether or not anyone has configured anything. We check where those logs are routed, how long they are retained, and whether anyone would actually notice an unusual read.
OUR PROCESS
Google BigQuery Security Review: From Scope to Attestation
Scope and Access
We agree which GCP projects and datasets are in scope, plus a read-only IAM identity or dedicated service account that matches the access level you want tested.
IAM and Policy Mapping
We map project- and dataset-level IAM roles, row access policies, policy tags and any authorised views or BigQuery sharing listings against who is meant to see what.
Manual Testing
A CREST-certified tester queries the environment with the access provided, testing row and column filters, export paths and shared datasets for gaps between intended and actual access.
Attestation and Retest
You get a technical report with findings mapped to the specific IAM roles, policies or grants involved, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST BigQuery pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Google BigQuery Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test BigQuery For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Google BigQuery Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our BigQuery project?
We need a Google Cloud IAM identity, either your own account or a dedicated service account, with the same roles as the access tier you want tested, typically BigQuery Data Viewer at project or dataset level. If row access policies, policy tags or authorised views are in place, tell us during scoping so we can test what each is meant to restrict.
Will testing touch our live data?
We test with whichever project and datasets you give us access to, using read-only IAM roles by default. We do not run destructive operations such as deleting tables or rows, and we agree in writing before running any query against production data outside business hours.
How long does a BigQuery security review take?
A single BigQuery project sits in our 2-day single-project scope, with a report typically landing around 5 working days after kickoff. A warehouse with more datasets, cross-project sharing or a more complex row and column-level security setup moves into a wider scope with more testing days.
Do you need our service account keys or source code?
No. We test using an IAM identity you create for us, not your existing service account keys. A grey-box option, where we also review the Terraform, deployment scripts or IAM policy exports that define your access controls, is available if you want faster or deeper coverage.
What is out of scope for a single-project BigQuery review?
The compute resources, pipelines or BI tools that query BigQuery, such as a Dataflow job or a Looker deployment, are out of scope for this review and quoted separately, as is the security of other GCP services in the same project. Our GCP cloud security review covers the wider project configuration around BigQuery.
Do you check data we’ve shared through BigQuery sharing or Analytics Hub?
Yes, if it is in scope. We review the listings and data exchanges you publish, who holds the Analytics Hub Publisher and Subscriber roles, and whether the authorised views used to share data restrict access the way you intended. We do not test the subscribing organisation’s own environment.
Does Google Cloud have a customer penetration-testing policy we need to follow?
Yes, but it does not require you to notify Google first. Google states that customers are not required to contact them before testing their own Cloud Platform resources, provided testing stays within the Acceptable Use Policy and Terms of Service and only affects your own projects. We confirm the current wording of that policy during scoping and agree with you which projects are in scope before testing starts.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your BigQuery project
A BigQuery dataset’s IAM grants, row access policies and authorised views decide who can read which rows and columns. We test what those grants, exports and shared datasets actually allow. CREST-certified testers, fixed price from £3,280 for a 2-day single-project scope, quoted within 24 hours.
