7.2 Defining and assigning access: requirements and evidence

PCI DSS 7.2 access control model: what the requirement asks for

Requirement 7.2 is where a compliance lead tests whether access to cardholder data is designed on purpose or has simply accumulated. The requirement asks the organization to define an access control model, assign privileges according to least privilege, and then keep checking that the assignments still match the work people and systems actually do. The underlying risk is familiar: staff who changed roles keep old permissions, contractors keep accounts after projects end, and service accounts gain rights nobody remembers granting. Each unneeded privilege is a path to stored cardholder data that the business no longer justifies. The seven sub-requirements (7.2.1 to 7.2.6, plus 7.2.5.1) fall into three themes: the model and its assignments (7.2.1 to 7.2.3), the reviews that catch drift (7.2.4 and 7.2.5.1), and the restriction of direct query access to stored cardholder data (7.2.6). Your sub-requirement list in the standard and the SAQ D for service providers should be the reference you check against, and you should confirm with your assessor which version and which approach (defined or customized) applies to your environment.

Two parts are usually the hard ones. The first is the six-monthly review under 7.2.4, which covers all user accounts and privileges, including third-party and vendor accounts. Most teams can produce a list. The harder work is getting the right reviewer to make a documented decision on each item, removing what is inappropriate, and showing that management acknowledged the results. The second is system and application account coverage under 7.2.5 and 7.2.5.1. Service accounts, batch jobs and integration credentials often have no owner, and the review frequency for them is set by a targeted risk analysis under Requirement 12.3.1, so the analysis itself becomes evidence. Start by asking three questions: who owns the access model document, which system is the source of truth for user and privilege data, and who signs the review. Identity tooling that supports access certification campaigns can produce much of the evidence, but the organization still owns the decisions. Confirm with your QSA how they expect review records, reviewer sign-off and risk analysis outputs to look before you build the process.

Which accounts, systems and third parties fall under 7.2 scope

Requirement 7.2 applies to every account that can reach cardholder data or the systems that protect it, not only employee logins. The cards below set out the account types and scoping decisions that change how much review and documentation you carry.

User accounts, including vendors

Employee, contractor and third-party accounts all sit inside the 7.2.4 review cycle, including remote support and vendor accounts used for maintenance. Build one inventory that lists every human identity with access to the cardholder data environment (CDE), its source, and its business reason. Vendor accounts are the ones most often missed because they are created outside the corporate directory. Check that each one has a named owner and an expiry.

Application and system accounts

Service accounts, batch jobs and integration credentials are not people, but 7.2.5 and 7.2.5.1 still require their privileges to be least privilege and reviewed. Inventory each account, the process that uses it, and the data it touches. The review frequency for these accounts is set by a targeted risk analysis under Requirement 12.3.1, so document that analysis and the frequency it produces. Shared or interactive use of system accounts is a common finding.

Query access to cardholder data stores

7.2.6 addresses direct queries against repositories that hold stored cardholder data. Analysts, developers and database administrators who can run ad hoc queries against those stores fall in scope, even when they never touch the application. Confirm which users can connect to the database directly, which queries run through an application or programmatic method, and that only responsible administrators can query the repository directly.

Shared cloud and administrative accounts

Whether a shared cloud tenant, Kubernetes cluster or administrative console sits inside the CDE is a scoping decision that changes the 7.2 workload. If the same administrator accounts can reach both payment and non-payment systems, those accounts and their privileges are generally in scope. Ask your assessor early how they will treat shared identity providers and directories, and document the reasoning. Changing the boundary later can reopen every review.

Identity sources that feed the CDE

Directories and identity providers that issue credentials for CDE systems become part of the 7.2 evidence chain, even when they run outside the CDE. A federated sign-in service, for example, decides who gets access to payment applications. Map which directories supply accounts to each CDE system and whether account removals propagate. Open-source options such as FreeIPA and authentik can serve these roles, but the scoping question is the same for any product.

Privileged roles that span systems

Accounts granted roles across several systems accumulate access over time, and each role grant is a privilege that 7.2.2 and 7.2.4 require to be approved and reviewed. Identify roles that combine payment administration with other duties, since these often sit outside the CDE boundary on paper but reach it in practice. Use access certification campaigns to record keep, change or revoke decisions for each role assignment.

How an assessor tests requirement 7.2

This table sets out how a QSA or internal assessor typically tests each part of Requirement 7.2, what they ask for, and where organizations most often fall short. Read it as a preparation checklist: for each row, confirm that the evidence exists, covers every account type in scope, and can be produced on request.

Sub-requirement	How the assessor tests it	Evidence requested and common findings
7.2.1 Access control model	Interview the owner of the model, then inspect the documented model against the in-scope systems and the business functions that use them.	Written access control model covering users, system components and privilege levels. Finding: model exists but does not name the systems it governs, or was never updated after a platform change.
7.2.2 Least-privilege assignment	Select a sample of user IDs and compare each assigned privilege with the job function documented for that role.	Role-to-privilege mapping and the sampled account grants. Finding: administrators holding broad rights that exceed the role description, often inherited through group membership.
7.2.3 Approval of privileges	Trace sampled grants back to a documented approval, checking that the approver is authorized and the approval predates the access.	Approval tickets or workflow records with approver identity and date. Finding: access granted by email with no retained record, or approved by the person receiving it.
7.2.4 User account reviews (six-monthly)	Confirm a review occurred within the last six months for all user accounts, including third-party and vendor accounts, then sample findings and follow-up actions.	Review records listing every account, the reviewer, the outcome, the removals or changes, and management acknowledgment. Common finding: vendor and contractor accounts omitted from the review population.
7.2.5 Application and system account privileges	Inspect the list of application and system accounts and the privileges assigned to each, checking for least privilege and documented need.	Account inventory with owner, purpose and privileges per account. Finding: shared or service accounts with interactive login or administrator rights and no named owner.
7.2.5.1 Review of application and system accounts	Locate the targeted risk analysis under Requirement 12.3.1 that sets the review frequency, then check review records against that frequency.	Targeted risk analysis and completed review records. Finding: review frequency asserted in policy but no risk analysis to support it, or system accounts never reviewed at all.
7.2.6 Query access to cardholder data stores	Inspect database and repository access settings, then test whether ordinary users can query stored cardholder data directly or only through approved applications.	Access configuration exports and sample user test results. Finding: analysts with direct database query rights that the application layer was meant to replace.

Implementing 7.2 step by step, with the output of each step

The sequence below moves from a written access control model to recurring reviews and query restrictions, so each step produces an artifact an assessor can sample. Work in this order so that later steps rely on decisions already recorded.

Define the access control model
Start by choosing how access will be granted across the cardholder data environment, such as role-based access tied to job functions, and record the rules in a written model. The security owner drafts it with input from IT operations, application owners and the business units that run payment processes. The step is done when the model states who can request access, who approves it, how privileges map to roles, and how exceptions are handled. The output is an approved access control model document that every later step references.
Document role-based privileges and approvals
Translate the model into a catalog of roles, each listing the privileges it grants and the minimum business need that justifies them. Assign each role an approver who is independent of the person requesting access. Confirm that the catalog covers user accounts, including third-party and vendor accounts, so that no access exists outside a documented role. The output is a role matrix with named approvers and a log of approved privilege requests, which shows that access is assigned by need to know rather than by convenience.
Inventory accounts across user, application and system types
Build a complete list of accounts with access to the cardholder data environment, separated into user accounts, application accounts and system accounts. For each account, record the owner, the role it holds, its privileges and where it is used. Pull the lists from directories, application configuration, database users and cloud identity services, then reconcile them so orphaned or shared accounts are visible. The step is complete when the inventory matches what the systems actually show. The output is an account register that serves as the population for every review in later steps.
Set review frequency for system accounts through the targeted risk analysis
Application and system account reviews do not run on a fixed interval written into 7.2. Their frequency is set in a targeted risk analysis performed under Requirement 12.3.1, so the security owner documents the accounts in scope, the risk factors considered and the resulting review interval. Ask your QSA how the analysis should be structured before finalizing it. The output is a signed targeted risk analysis that states the review frequency for each class of system and application account, which the assessor will compare against your account register.
Run the six-monthly user access reviews
Review every user account and privilege, including third-party and vendor accounts, at least once every six months. A reviewer who does not administer the access compares each entry in the account register against the approved role matrix and marks it as keep, change or revoke. Any inappropriate access is removed or corrected, and management acknowledges the results in writing. Identity governance tools such as midPoint can run this as a certification campaign with designated reviewers and deadlines. The output is a signed review record for each cycle, with evidence of the changes made.
Run the system and application account reviews
Execute the reviews at the frequency set in the targeted risk analysis for application and system accounts. Check that each account still has only the privileges its documented purpose requires, and that ownership is current. Record exceptions and the remediation applied. Because service accounts often lack an obvious human owner, confirm an accountable owner for each one before the review starts. The output is a dated review record for each application and system account class, linked to the risk analysis that set its frequency.
Restrict direct query access to cardholder data stores
Configure the cardholder data repositories so that user queries pass through applications or programmatic methods that enforce role-based, least-privilege rules. Only designated administrators should be able to query the stores directly. Test this by attempting direct queries from ordinary user and application accounts and confirming they are blocked or logged. Record the administrators with direct access and review that list in each access review cycle. The output is a configuration record, a test result showing direct queries are restricted, and an updated administrator list.

Evidence that passes 7.2 and how to keep it current

Requirement 7.2 is tested largely through documents and records that show access was designed, approved, reviewed and acknowledged. The cards below cover each artifact an assessor typically asks for, and the routines that keep those records accurate between assessments without rebuilding them every cycle.

Access control model document

This is the written statement of how access is granted: which model applies (for example role-based or attribute-based), who owns each decision, and how job functions map to privileges. Assessors use it as the baseline against which every other 7.2 record is compared. Check that the document names the systems in scope, matches what the directory and applications actually do, and carries an owner and a review date. A model that describes a process nobody follows will fail even if the paperwork looks complete.

Role and privilege matrices

A role and privilege matrix lists each job function, the roles assigned to it and the specific permissions each role carries in cardholder data systems, applications and databases. It shows least privilege at a glance and gives reviewers something concrete to test against. Keep it generated from the identity source where possible, so changes to a role appear in the matrix automatically. Flag any role that grants administrative or query rights to cardholder data and confirm who approved it.

Privilege approval records

Each grant of access above a baseline needs a dated record showing who requested it, what business need it serves, who approved it and when. Tickets in a service desk or workflow tool usually serve this purpose if they link to the account and the role granted. Check that approvers are independent of the requester and that revoked access also has a record. Missing approvals for privileged accounts are among the most common gaps assessors find under this requirement.

Signed user access review results

Requirement 7.2.4 expects every user account and privilege, including third-party and vendor accounts, to be reviewed at least once every six months. The output should list each account reviewed, the decision (keep, change or remove), the reviewer and the date, and a record that management has acknowledged the results. Inappropriate access must show a follow-up action with a closure date. Store signed results in a location the review team can retrieve without rebuilding the list from scratch.

Certification campaign history

Access certification tools can run recurring review campaigns in which designated reviewers decide whether to keep, change or revoke each access item within a set timeframe. The campaign history, including reviewer decisions and revocations, becomes the review evidence and shows access accumulation is being checked. Confirm with the tool vendor which reports can be exported for an assessor and whether campaign data is retained long enough to cover the assessment period.

System account risk analysis

Requirement 7.2.5.1 ties the review frequency for application and system accounts to a targeted risk analysis under Requirement 12.3.1. The analysis should record each account class, its privileges, the risk of misuse and the review interval chosen with its reasoning. Assessors check that the interval in the analysis matches the review records actually produced. Revisit the analysis when new services or accounts appear, rather than only at the annual policy cycle.

Query access configurations

Requirement 7.2.6 expects user queries of stored cardholder data repositories to pass through applications or programmatic methods based on role, with only responsible administrators querying the repository directly. Evidence includes database role grants, application query interfaces, and access lists showing who can connect directly. Export these configurations on a schedule and compare them to the previous export. Any direct query grant outside the administrator group should be listed as an exception with an approval.

What meeting 7.2 costs in money and effort

This table breaks down the cost components of meeting Requirement 7.2, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to compare quotes, since no price list is published and figures depend on your environment.

Cost component	One-time or recurring	What drives it	What to ask for in a scope or quote
Identity tooling or licenses	Recurring (subscription) or one-time (perpetual)	Number of user accounts, applications and directories connected	Itemized licence terms, the account count basis, and whether self-hosted open-source options are costed separately
Role model design and build	One-time	Number of job functions, applications and privilege levels in scope	A written role catalogue deliverable, the workshop count and who signs off approved privileges
Integration engineering	One-time, with later changes	Number of applications, legacy systems and directories to federate or synchronize	Named integrations, the testing approach and the handover documentation for the client team
Six-monthly user access reviews	Recurring, every six months	Total accounts including third-party and vendor accounts, plus the number of reviewers	Reviewer assignments, the review tooling used, and how inappropriate access is tracked to closure
System and application account reviews	Recurring, at the frequency set by the targeted risk analysis	Count of service and application accounts and the review interval your risk analysis sets	Confirmation of the review frequency basis and the evidence format assessors will receive
Query access restriction setup	One-time, with ongoing checks	Number of cardholder data repositories and the administrators who query them directly	Inventory of stores, the approach for routing queries through applications, and the role logic applied
Evidence upkeep	Recurring	Frequency of access changes, joiners and leavers, and audit log volume	Retention period for review records, the sampling approach and the owner of each evidence set
Independent review or testing	Recurring or per engagement	Scope of the access model under test and how often it changes	Whether testing is independent of the implementation work and the report format delivered
Assessor sampling	Recurring, per assessment cycle	Number of accounts and reviews the assessor samples and the quality of your records	Confirmation with your assessor of the sample size and the evidence they expect before fieldwork

Open-source identity tools that produce 7.2 evidence

midPoint is an identity governance platform whose access certification campaigns can support the six-monthly review of user accounts and privileges expected under Requirement 7.2.4. A campaign assigns designated reviewers who decide within a set timeframe whether each access item stays, changes or is revoked. That decision trail is the kind of record an assessor asks for when checking that inappropriate access was addressed and that management acknowledged the results. Because reviewers see role assignments side by side, campaigns also help surface access accumulation and segregation of duties conflicts.

Campaign scope: Confirm whether campaigns can cover user accounts, role assignments and third-party or vendor accounts, since 7.2.4 includes those.
Decision records: Keep, change and revoke decisions with reviewer identity and dates form the core evidence, so confirm they export in a form your assessor can read.
Segregation of duties: Reviewers can flag combinations of roles that should not sit with one person, which supports the least-privilege intent of 7.2.1 and 7.2.2.
Remediation follow-through: Confirm that revocations are applied to the target systems, not only recorded in midPoint.
Review cadence: Campaign schedules must be set to meet the six-month interval, and the schedule itself becomes evidence.

Confirm with your team which systems feed midPoint and whether revocations flow back to them automatically.

Common gaps that fail 7.2 reviews and how to close them

Most Requirement 7.2 findings come from access that was granted correctly once and then never reviewed, narrowed or documented again. The gaps below cover who is left out of reviews, which accounts hold standing privilege, and where acknowledgment and query paths break down. Each card names one check to run before an assessor does.

Vendor accounts left out of reviews

Reviews often cover employee directory accounts and miss third-party and vendor accounts held in support tools, jump hosts or ticketing integrations. Requirement 7.2.4 applies to these accounts as well. Build a single inventory that lists every account type with its owner, contract end date and sponsoring manager, then include that inventory in each six-monthly review. Ask the assessor's expected evidence early, since a missing vendor row is an easy finding.

Service accounts with standing privilege

Application and system accounts often run with broad rights that were set during installation and never narrowed. Requirement 7.2.5 expects least privilege for these accounts, and 7.2.5.1 expects their access to be reviewed at a frequency set by a targeted risk analysis. Export each service account with its granted rights, remove rights the process does not use, and record the review frequency and the risk analysis that justifies it.

Reviews without management acknowledgment

A review that lists accounts but shows no decision, and no sign that management read the results, fails the evidence test even when the access looks correct. Requirement 7.2.4 expects inappropriate access to be addressed and management to acknowledge the outcome. Record a keep, change or revoke decision for each item, the date of the removal ticket, and a named manager's sign-off on the completed review.

Role sprawl from accumulated access

Staff who change teams often keep the roles from their previous jobs, and the sum of those roles can exceed what any current job needs. Access certification campaigns, such as those in midPoint, have a designated reviewer decide within a set timeframe whether each role assignment stays, changes or is revoked, which counters this accumulation. Run a campaign on job-function roles and confirm that revocations are applied in the directory, not only recorded in the review tool.

Direct query access to cardholder data stores

Analysts and developers who run ad hoc SQL against databases holding stored cardholder data fall outside Requirement 7.2.6. Only responsible administrators may query these repositories directly, and other users must reach the data through applications or programmatic methods based on role. Disable direct client access for non-administrators, route reporting through a controlled application, and keep a list of the administrators who keep direct rights.

Unmanaged accounts outside the directory

Applications that keep local user tables create accounts that the directory review never sees, so leavers can retain access. Where an application can delegate sign-in, connect it to the central identity source so that removing a person from the directory removes their application access too. Test one leaver case end to end and keep the result as review evidence. Confirm with each application vendor which accounts remain local and why.

Questions buyers ask about PCI DSS 7.2

How much effort does Requirement 7.2 add to our PCI DSS program?

Requirement 7.2 adds recurring work more than one-time build work in most environments, and the size of that work depends on how many accounts, roles and applications sit inside the cardholder data environment. The main drivers are the number of user and system accounts, how many privileges are assigned outside a documented role model, whether access is granted through a ticket workflow, and how many third-party accounts need review. An organization with a clean identity directory and role-based groups will spend far less effort than one that manages access by hand on each system. Ask any implementation partner for a written scope that lists the systems, directories and applications in the review, because that list sets the effort. Ask your QSA which evidence they expect to sample before you agree on the scope.

How often must user access reviews run, and what counts as acknowledgment?

Requirement 7.2.4 requires all user accounts and their privileges, including third-party and vendor accounts, to be reviewed at least once every six months. Inappropriate access must be addressed, and management must acknowledge the results. Acknowledgment is evidenced by a dated record showing that a named manager or accountable owner reviewed the list, approved what stays, and confirmed that changes were made. A signed spreadsheet with no follow-up ticket is weak evidence. Keep the review population, the reviewer, the decision for each account, and the closure record together so an assessor can trace them. Confirm the exact evidence format with your QSA, since the standard does not prescribe a tool or template.

Can a small team run Requirement 7.2 in-house?

A small team can meet Requirement 7.2 in-house when the environment is small, the account population is stable and someone owns the process end to end. The work that tends to strain small teams is the periodic review itself, the tracking of revocations and the evidence trail, not the access model. Writing down the access control model, defining who approves privileges, and scheduling six-monthly reviews are tasks that a few people can complete if they have time and clear authority. Outside help is most useful for designing the review workflow, configuring the directory and reporting, and preparing evidence before the assessor arrives. Ask any partner to separate design work from assessment work in the quote, because the assessor role must stay independent.

What does Requirement 7.2 need from our identity and application owners?

Requirement 7.2 depends on identity owners and application owners providing accurate, current data. Identity owners maintain the directory, group membership and the link between a person's job and their roles. Application owners confirm which privileges their software exposes, which roles are required for each job function and which accounts are service or system accounts. Without those inputs, reviewers approve lists they cannot interpret. Ask each owner to name a backup, document the role catalog for their system, and agree the review frequency for application and system accounts in writing. Check whether your directory can produce a complete account and group export, since that export is usually the first artifact an assessor requests.

Can a partner replace our QSA for Requirement 7.2?

No. A partner can prepare systems, access models, review workflows and evidence, but only the QSA can assess the environment and issue the Report on Compliance and Attestation of Compliance. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Keep the consultant and the assessor separate so the assessor can test your controls independently. When you request a quote, ask the partner to list the deliverables it will produce, the evidence it will hand over and the work the QSA will still perform. Confirm with your assessor which parts of the partner's output they will accept as evidence.

What changed when system account reviews became mandatory on 31 March 2025?

Requirement 7.2.5.1 became mandatory on 31 March 2025. It requires application and system account access to be reviewed at a frequency defined in a targeted risk analysis under Requirement 12.3.1, so the frequency is set by your own risk reasoning rather than a fixed interval. Before that date the requirement was a future-dated best practice. Now an assessor will expect a documented risk analysis that justifies the chosen frequency, a list of application and system accounts, and evidence that those reviews happened on schedule. Many teams found that service accounts had no owner, which made the review impossible until ownership was assigned. Check your current evidence against that list before your next assessment.

What should a quote for Requirement 7.2 include?

A useful quote for Requirement 7.2 names the systems and directories in scope, the accounts and applications covered, the deliverables, and the evidence each deliverable produces. It should separate one-time work, such as the access control model, role catalog and review workflow, from recurring work, such as six-monthly reviews and the system account review cycle. Ask who performs the reviews, who approves them and who keeps the records. Request the assumptions behind any effort estimate, and ask what changes if the account population grows. DeployOpen fixed-scope engagements are agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen prepares 7.2 access controls and evidence

DeployOpen plans, implements and documents self-hosted open-source identity and access tooling inside your own infrastructure, so the access model, approvals, reviews and query restrictions for 7.2 Defining and assigning access are in place and provable. We prepare systems and evidence; your organization owns the controls, and an independent QSA issues the Report on Compliance or the Attestation of Compliance.

How we scope

We agree a written scope listing the systems, directories and applications where cardholder data access is granted.
We confirm which user, third-party, vendor and application or system accounts fall under the 7.2 reviews.
We record which cardholder data repositories exist and who currently holds direct query access to them.

How we build

We configure an access control model with roles mapped to job functions and least privilege defaults.
We connect the corporate directory to applications so sign-in and group membership follow one source of truth.
We set up access certification campaigns with named reviewers and a documented timeframe for keep, change or revoke decisions.

How we hand over

We deliver the role catalog, approval records and privilege assignments in a format your assessor can sample.
We document the six-monthly user review and the risk-based review frequency for application and system accounts.
We hand over query access rules for cardholder data stores, with the administrators who may query them directly named.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can rerun access reviews and refresh evidence ahead of your assessor's fieldwork, as agreed in scope.
Your team keeps ownership of approvals, review decisions and the final compliance position at all times.