Does QueryProxy make our database pass PCI DSS?

No. PCI DSS is assessed against your whole cardholder data environment by a qualified assessor or through a self-assessment. QueryProxy helps with evidence for database access, such as who ran which statement and who approved it. It does not change your scope.

Which PCI DSS requirements does QueryProxy relate to?

Requirement 7, restricting access by business need to know; Requirement 8, identifying users and authenticating access; and Requirement 10, logging and monitoring access. Other requirements, such as network segmentation and encryption of stored account data, are outside what QueryProxy does.

Does masking take QueryProxy or the database out of PCI scope?

Do not assume so. The database holding card data stays in scope. Masking rules reduce what lands in stored result files, but only for values the rules match, and QueryProxy itself sits in the path to a system that stores cardholder data. Ask your assessor how they scope it.

Does QueryProxy mask card numbers?

The default rule set includes a content rule for credit card numbers using the partial strategy, narrowed to real issuer ranges, plus column rules for card columns. A value that matches no rule is returned untouched, so test your rules against your own data.

Can developers see raw card data through QueryProxy?

Results are masked by your rules before they are written, so a masked value is not stored unmasked. A column or format your rules miss is returned as it is. The database user QueryProxy connects with can still read what it was granted.

PCI DSS and database access controls

PCI DSS applies to organizations that store, process or transmit payment card data. Whether a database is in scope, and whether you pass, is determined by an assessment of your environment. QueryProxy cannot decide either. It can help with evidence for the controls that govern who reaches a database and what they do there.

This page is not legal or audit advice. Your assessor decides what satisfies a requirement in your environment.

Which PCI DSS requirements relate to database access?

This page refers to version 4.0.1 of the standard, published by the PCI Security Standards Council (titles checked on 2026-10-13). Three requirements bear on database access, under these titles in v4.0.1:

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know.
Requirement 8: Identify Users and Authenticate Access to System Components.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data.

The sub-requirements carry the detail, and they are the part your assessor tests. Read them in the standard itself, in the PCI SSC document library, rather than from this summary.

What evidence can QueryProxy produce?

QueryProxy helps with evidence for these requirements. It does not satisfy any of them alone.

Requirement	What QueryProxy produces	What it does not cover
7: access by need to know	A developer reaches only the connections a DBA granted. Four roles separate who can submit, approve and audit. Large reads are bounded: a `SELECT` without a `LIMIT` gets a default of 1000 rows, and no `LIMIT` above 10000 is honored (SQL guards).	Deciding what each person’s business need is, and what the database user’s own grants allow. Give that user only the privileges the work needs.
8: identify and authenticate	Users sign in individually, the production credential stays encrypted (AES-256) in QueryProxy and is never handed to a developer (approval workflow reference), and TOTP two-factor authentication can be required for administrators, DBAs or all users (configuration).	Your password and multi-factor policy as a whole, and authentication to the systems around QueryProxy.
10: log and monitor access	Every request writes audit entries: submission, decision, execution with duration and affected rows, result downloads, logins and configuration changes. Audit rows cannot be edited or deleted through the application, and an Auditor can read and export them.	Log review, alerting, time synchronization, and retention. The documentation names no retention period for the audit log.

The audit log shows that a person asked for a statement, a different person approved it, and the statement ran. The approval workflow page walks through how a request travels, and the workflow reference lists the roles and audit entries.

How does masking relate to cardholder data?

Masking runs while a result is written, so the unmasked result is never stored. The default rule set includes a rule for card numbers (the partial strategy) and one for card columns. See dynamic data masking and the masking reference.

This reduces how much cardholder data ends up in result files. It does not make the database leave scope, and it only masks what the rules recognize. A card number in an unexpected column or format returns as stored. Test the rules against real column names and formats before you rely on them.

What stays with your organization?

Defining your cardholder data environment and its scope, and any segmentation.
Protecting stored account data and managing keys.
The grants of the database user QueryProxy connects with. A SELECT-only user remains the safest choice for read connections.
Reviewing the logs, retaining them, and acting on what they show.
Hardening the host and the application’s own database. See production hardening.
The assessment: choosing an assessor or questionnaire and gathering the rest of the evidence.

What are the limits?

Only requests made through QueryProxy are logged by it. Other routes to the database leave no entry in its audit log.
The SQL guard is a denylist and is incomplete by nature. A DBA’s approval is the authorization boundary.
Masking is rule-based and does not detect card data on its own.
The database sees one connection user for every QueryProxy request. Its own logs show that account, not the person. Attribution to an individual lives in QueryProxy’s audit log, which matters when an assessor tests Requirements 8 and 10.
Using QueryProxy does not give you a PCI DSS validation.

When do you not need this?

If you do not store, process or transmit card data, PCI DSS does not apply to your databases, and this page does not either. If a payment processor holds all card data and your databases only store tokens, your exposure is different; confirm with your assessor. If a bastion host and database audit logging already satisfy your assessor, QueryProxy may add little. The comparison with a bastion host shows the difference.

Related reading: SOC 2, ISO 27001 and what database access control is.

Frequently asked

Does QueryProxy make our database pass PCI DSS?: No. PCI DSS is assessed against your whole cardholder data environment by a qualified assessor or through a self-assessment. QueryProxy helps with evidence for database access, such as who ran which statement and who approved it. It does not change your scope.
Which PCI DSS requirements does QueryProxy relate to?: Requirement 7, restricting access by business need to know; Requirement 8, identifying users and authenticating access; and Requirement 10, logging and monitoring access. Other requirements, such as network segmentation and encryption of stored account data, are outside what QueryProxy does.
Does masking take QueryProxy or the database out of PCI scope?: Do not assume so. The database holding card data stays in scope. Masking rules reduce what lands in stored result files, but only for values the rules match, and QueryProxy itself sits in the path to a system that stores cardholder data. Ask your assessor how they scope it.
Does QueryProxy mask card numbers?: The default rule set includes a content rule for credit card numbers using the partial strategy, narrowed to real issuer ranges, plus column rules for card columns. A value that matches no rule is returned untouched, so test your rules against your own data.
Can developers see raw card data through QueryProxy?: Results are masked by your rules before they are written, so a masked value is not stored unmasked. A column or format your rules miss is returned as it is. The database user QueryProxy connects with can still read what it was granted.