PCI DSS Requirement 7 Guide: Need-to-Know Access and Access Reviews

Requirement 7 decides what every identity in the cardholder data environment may do, and v4.0 turned it from a role-design exercise into a recurring evidence obligation with periodic reviews of user, vendor, application and system accounts. This guide works through PCI DSS v4.0.1 Requirement 7: the access control model (7.2.1), least privilege assignment and approval (7.2.2, 7.2.3), access reviews for people and third parties (7.2.4), application and system accounts (7.2.5, 7.2.5.1), access to stored cardholder data (7.2.6) and the access control systems that enforce it all (7.3). It is written for IAM and IGA teams, application owners and PCI programme owners. Requirement wording is summarised, not quoted, because the standard itself is published as a PDF in the PCI SSC Document Library; check every value against the current standard before relying on it.

Key takeaways

• Requirement 7 is authorisation, Requirement 8 is authentication: 7 decides what an identity may do, 8 proves who it is. Both must cover every system component in scope.
• Least privilege has a definition: the PCI SSC glossary defines least privileges as the minimum level of privileges necessary to perform the roles and responsibilities of the job function; 7.2.2 applies it to all users, including privileged users.
• Reviews are mandatory and periodic: 7.2.4 requires all user accounts and their privileges, including third-party and vendor accounts, to be reviewed at the frequency the standard sets; 7.2.5.1 requires reviews of application and system accounts at a frequency defined by a targeted risk analysis.
• Machine accounts are in Requirement 7 too: 7.2.5 requires application and system accounts and their privileges to be assigned and managed on least privilege, not left as broad database owners or domain admins.
• Default deny: 7.3.3 requires access control systems to be set to "deny all" by default, and 7.3.1 requires them to cover all system components.

How Requirement 7 is structured

Requirement 7, "Restrict Access to System Components and Cardholder Data by Business Need to Know", has three sections. The standard as a whole is summarised in the PCI DSS 4.0 Guide; authentication is in the PCI DSS Requirement 8 Guide.

Some v4.0 requirements were future-dated and, according to the PCI SSC, became effective on 31 March 2025; the standard marks which ones, so check which Requirement 7 items carry that note. If your last assessment predates that date, they may not yet have been tested.

7.2.1 to 7.2.3: the access model, least privilege and approval

7.2.1 access control model: the model is expected to cover all system components, how access is assigned by job classification and function, and the least privileges needed. In practice this is a role catalogue: each role lists the systems and permissions it grants, the job functions eligible for it, and the role owner. See the Authorisation Models Guide for choosing between RBAC and attribute-based designs.

7.2.2 least privilege: assign access by job function, and separate everyday accounts from privileged accounts so administrators do not browse or email with admin rights. For techniques such as just-in-time elevation and permission right-sizing, see the Least Privilege Techniques Guide and the JIT Access Guide.

7.2.3 approval: privileges are approved by authorised personnel. Assessors sample accounts and ask for the approval record for each privilege. Approval by the requester, or by a manager who cannot judge the access, is weak evidence; our recommendation is manager approval plus system or data owner approval for privileged and cardholder data access.

Decision guidance: role design by organisation size

7.2.4: reviewing user and vendor access

7.2.4 requires all user accounts and related privileges, including third-party and vendor accounts, to be reviewed periodically, with inappropriate access addressed and management acknowledging that remaining access is appropriate. Points that commonly decide whether a review passes:

• Completeness: the review covers every in-scope system's accounts, not only the directory. Local accounts on databases, network devices and SaaS consoles count.
• Vendors: third-party accounts have a named internal sponsor who reviews them; dormant vendor accounts are disabled. Requirement 8.2.7 separately requires third-party remote access accounts to be enabled only when needed.
• Meaningful decisions: reviewers see what each permission means, not cryptic group names, and can revoke in the same step.
• Closure: revoked access is actually removed, with evidence, and management acknowledges the result.

For running campaigns, see the Access Reviews Guide, the Access Review Checklist and the Access Recertification Campaign Plan Template.

7.2.5 and 7.2.5.1: application and system accounts

Application and system accounts (service accounts, database connection accounts, integration and API accounts, automation identities) must be assigned and managed on least privilege (7.2.5), and their access reviewed at a frequency defined by a targeted risk analysis performed according to 12.3.1 (7.2.5.1). Requirement 8.6 adds authentication controls for the same accounts.

1. Inventory: list every application and system account in scope with its owner, purpose, systems reached and permissions.
2. Right-size: replace database owner, sysadmin or domain admin grants with the specific permissions the application uses. Use access logs to see what is actually exercised.
3. Prevent interactive use: block interactive logon where the platform allows; where it cannot be blocked, broker and monitor it.
4. Set the review frequency: write the targeted risk analysis, considering privilege level, exposure and change rate, and record the chosen interval.
5. Review: the owner confirms purpose and permissions; orphaned accounts with no owner are disabled after a defined grace period.

See the PCI DSS Requirements for Service Accounts and NHIs Guide for the matching 8.6 controls, and the PCI DSS Customised Approach and Targeted Risk Analysis Guide for writing the risk analysis.

7.2.6: access to stored cardholder data

7.2.6 restricts user access to query repositories of stored cardholder data. In summary, access is through applications or other programmatic methods, with access and allowed actions based on user roles and least privilege, and only responsible administrators able to access or query the repositories directly. In practice:

• Business users reach cardholder data only through applications that enforce role checks and masking (see 3.4.1).
• Direct SQL or console access to the cardholder database is limited to named DBAs, ideally through just-in-time elevation and recorded sessions.
• Reporting, analytics and data science users get tokenised or truncated data, not direct access to the PAN store.

See the DBA Privileged Access guide and the Database Privileged Access Review Template.

7.3: access control systems

• 7.3.1 coverage: an access control system restricts access by need to know and covers all system components. Gaps are usually network devices with local accounts, legacy applications with their own user tables, and cloud consoles outside the directory.
• 7.3.2 enforcement: the system enforces the permissions assigned to individuals, applications and systems by job classification and function.
• 7.3.3 deny all: default deny, so access exists only where explicitly granted. Check cloud IAM, database default roles (such as public grants) and file share inheritance.

How to implement Requirement 7

1. Scope the identities: list every system component in scope and every account on it, human and machine, including vendor and local accounts.
2. Define the model: build or refresh the role catalogue (7.2.1) and map job functions to roles (7.2.2).
3. Fix approval: route all privilege requests through one workflow that records approver and date (7.2.3).
4. Right-size in waves: start with privileged and cardholder data access, then machine accounts, then everything else. Remove permissions in a pilot group first and keep a record of removed grants so they can be restored quickly if a business process breaks.
5. Enforce default deny: review default and public grants on each access control system (7.3.3).
6. Run the first reviews: a 7.2.4 campaign for users and vendors and a 7.2.5.1 review for machine accounts, then schedule them.
7. Keep evidence: role catalogue, approvals, review results, remediation tickets, the targeted risk analysis and management acknowledgement.

Detection and measurement

Alert on new members of privileged groups, new grants on cardholder data stores and interactive logons by service accounts; Requirement 10 logs these events. See the Log Management and Retention Guide.

Framework mapping

For the ISO/IEC 27001 view, see the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Common failure patterns

• Directory-only reviews: the campaign covers Active Directory groups but not database logins, network device accounts or SaaS admin consoles.
• Rubber-stamp approvals: reviewers approve everything because they cannot interpret the entitlements shown.
• Vendor accounts without sponsors: third-party accounts linger after the contract or project ends.
• Over-privileged service accounts: application accounts run as database owner or domain admin because it was easier during build (7.2.5).
• No targeted risk analysis: machine account reviews happen at an arbitrary interval with nothing written to justify it (7.2.5.1).
• Analysts with direct PAN access: reporting users query the cardholder database directly instead of through masked or tokenised data (7.2.6).

Practitioner checklist

• Document the access control model and role catalogue for every in-scope system (7.2.1).
• Assign access by job function with least privilege, separating privileged accounts (7.2.2).
• Record an approval for every privilege (7.2.3).
• Review all user and vendor accounts at the interval the standard sets, with management acknowledgement (7.2.4).
• Inventory, right-size and own every application and system account (7.2.5).
• Write the targeted risk analysis for machine account review frequency and follow it (7.2.5.1).
• Limit direct queries of cardholder data stores to named administrators (7.2.6).
• Confirm every access control system covers all components and defaults to deny all (7.3).

Standards and references

• PCI SSC: Document Library (PCI DSS v4.0.1)
• PCI SSC Glossary: Least Privileges
• PCI SSC FAQ 1304: Targeted risk analysis for periodic activities (10.4.2.1 example)
• PCI SSC Blog: Requirements effective after 31 March 2025
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Requirements for Service Accounts and NHIs Guide, Access Reviews Guide, Segregation of Duties Guide, PCI DSS Readiness Checklist. This guide summarises PCI DSS v4.0.1 Requirement 7 and is not legal or assessment advice.