PCI DSS 7.2.6: All user access to query repositories of stored cardholder data is restricted
PCI DSS v4.0.1 control 7.2.6: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 7.2.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know › Section 7.2
All user access to query repositories of stored cardholder data is restricted as follows:
- Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.
- Only the responsible administrator(s) can directly access or query repositories of stored CHD.
Summary
People reach stored cardholder data through an application that enforces their role, not through a database client, and only the administrators responsible for the repository can query it directly.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 7.2.6.a | Examine policies and procedures and interview personnel to verify processes are defined for granting user access to query repositories of stored cardholder data, in accordance with all elements specified in this requirement. |
| 7.2.6.b | Examine configuration settings for querying repositories of stored cardholder data to verify they are in accordance with all elements specified in this requirement. |
This is the control that says ad hoc database access to cardholder data is not a thing. The first bullet routes users through applications or other programmatic methods with role-based least privilege; the second limits direct query access to the responsible administrator or administrators. Procedure 7.2.6.b examines configuration settings, so an interview describing good practice does not satisfy it: the restriction has to be enforced where the queries arrive. It pairs closely with 7.2.5, which covers application and system accounts, since the application in bullet one runs under exactly such an account.
What to prepare
- The list of repositories holding stored cardholder data.
- Database user and role configuration for each, showing who can query directly.
- The applications or reporting layers that users go through instead, and how each enforces role and least privilege.
- The named responsible administrators for each repository.
How to implement it
1. Name the responsible administrators, and keep the list short. The requirement says only they may query directly, which means every other human account with query rights needs removing or a documented reason.
2. Give the analysts a reporting layer. Most direct database access exists because there was no other way to answer a question. A view, an API or a reporting tool with its own roles removes the reason rather than the symptom.
3. Enforce it in the database, not in policy. Revoke the grants. The procedure examines configuration, and a database that still permits the query is not restricted by a document that says it should not happen.
4. Cover the business intelligence tools. A BI platform connected straight to the repository with a shared service account gives its whole user base direct query access, which is the first bullet failing quietly at scale.
Where this commonly fails
- A shared read-only database account handed to the analytics team, which is direct query access held by everyone who has the password.
- Break-glass accounts that were created for an incident and left enabled.
- Production data copied to a reporting replica, and the restriction applied only to production.
- Developers with direct query access to production because that is how support questions get answered.
Related controls
Others in section 7.2:
| Control | What it requires |
|---|---|
| 7.2.1 | An access control model is defined and includes granting access… |
| 7.2.2 | Access is assigned to users, including privileged users, based… |
| 7.2.3 | Required privileges are approved by authorized personnel |
| 7.2.4 | All user accounts and related access privileges, including third-party/vendor accounts… |
| 7.2.5 | All application and system accounts and related access privileges are assigned and managed… |
| 7.2.5.1 | All access by application and system accounts and related access privileges are reviewed… |
← 7.2.5.1 · All controls · 7.3.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.