Elena Marsh had eleven minutes before the closing call with her QSA. She was VP of Platform Security at Brightline Merchant Services, a payment facilitator processing roughly $1.4 billion a year in card volume for about 3,000 sub-merchants, and she was staring at a spreadsheet she wished she'd never opened. Her assessor, running the access-control testing for Requirement 7 of their annual Report on Compliance, had pulled the production entitlement export from the identity platform and cross-referenced it against HR's active-employee roster. Forty-seven accounts had standing access to the cardholder database that didn't map to any documented business need. Nineteen belonged to people who had changed roles in the last year and simply never lost their old permissions. Eleven belonged to former employees and contractors — including one offboarded eleven months earlier who still had root-level SSH access to a host storing tokenized PAN data. And one very awkward account belonged to a marketing intern who could run "customer engagement reports" that, it turned out, queried a view exposing unmasked primary account numbers.
None of it looked like a breach. That was almost worse — it meant nobody had noticed. Brightline's sponsor bank had made it clear, in writing, that a clean, on-time ROC was a condition of the $22 million annual processing relationship, and the QSA now had to decide whether these findings were "exceptions to note and remediate" or grounds to suspend the assessment until Brightline could prove the access sprawl hadn't already resulted in unauthorized data exposure. A forensic review, if it came to that, would run Brightline $250,000 to $500,000 before anyone even started talking about card-brand fines or breach notification costs. Elena's real problem wasn't a hacker. It was that Brightline had never built a working answer to a deceptively simple question: who is allowed to see this data, and why?
That question is the entire subject of PCI DSS Requirement 7. It's not the requirement people picture when they imagine "hacking the payment system" — no exotic malware, no zero-day. It's a governance requirement, and it fails quietly, through role creep, forgotten grants, and approvals nobody ever wrote down. This article walks through exactly what Requirement 7 demands under PCI DSS v4.0.1, how to build a defensible business-need-to-know model, and how to keep it from decaying the moment you look away.
Who This Is For, and What You'll Walk Away With
This is written for the people who actually own access decisions inside a cardholder data environment: IT security managers, identity and access management leads, compliance managers preparing for a Report on Compliance or Self-Assessment Questionnaire, and engineering leaders who keep getting asked "why does this person have that access?" and don't have a great answer. You should already have a rough sense of your PCI DSS scope. By the end, you'll have a working model for defining access needs by job function, a default-deny provisioning approach, a documented approval workflow that survives assessor scrutiny, a periodic review cadence that won't collapse under its own weight, and a clear line between what Requirement 7 controls (authorization — what you're allowed to touch) and what Requirement 8 controls (authentication — proving who you are).
What Requirement 7 Actually Says
PCI DSS Requirement 7, titled "Restrict Access to System Components and Cardholder Data by Business Need to Know," sits inside Goal 4 of the standard — Implement Strong Access Control Measures — alongside Requirement 8 (identify users and authenticate access) and Requirement 9 (restrict physical access to cardholder data). Requirement 7 is the logical-access authorization requirement: it governs what a given identity is permitted to do once it's inside the environment, not how that identity proves who it is.
The core principle stated in the requirement is unambiguous: access to system components and cardholder data (CHD) must be limited to only those individuals whose job requires it. PCI DSS frames this as two related but distinct disciplines working together — need to know (you get access to the specific data required for your role, nothing broader) and least privilege (within that data, you get the minimum level of privilege, such as read-only versus modify, required to do the job). Requirement 7 asks organizations to prove both, continuously, with documentation an assessor can independently verify.
PCI DSS Goal | Requirements | Where Requirement 7 Fits |
|---|---|---|
1. Build & Maintain a Secure Network and Systems | Req 1, Req 2 | Not applicable |
2. Protect Account Data | Req 3, Req 4 | Not applicable |
3. Maintain a Vulnerability Management Program | Req 5, Req 6 | Not applicable |
4. Implement Strong Access Control Measures | Req 7, Req 8, Req 9 | Req 7 = authorization (what); Req 8 = authentication (who); Req 9 = physical access |
5. Regularly Monitor & Test Networks | Req 10, Req 11 | Req 10 logs the access Req 7 authorizes |
6. Maintain an Information Security Policy | Req 12 | Req 12 governs the policies that document Req 7's process |
For the full picture of how Requirement 7 fits alongside all twelve requirements, see the PCI DSS complete guide to the Payment Card Industry Data Security Standard.
The Three Sub-Requirements That Make Up Requirement 7
PCI DSS v4.0.1 organizes Requirement 7 into three numbered sub-requirements, each with its own set of testable controls. It's worth internalizing this structure before you build anything, because assessors test against it clause by clause, and gaps tend to cluster around whichever sub-requirement gets treated as an afterthought.
Sub-Requirement | Core Demand | Typical Evidence |
|---|---|---|
7.1 | Processes and mechanisms for restricting access are defined, documented, and understood — includes formal access-control policy and role definitions | Written access-control policy; documented roles; evidence staff understand responsibilities |
7.2 | Access to system components and data is appropriately defined and assigned — least privilege, need to know, default deny-all, documented approval, and periodic review of user access | Access-control system configuration; approval records; access review logs |
7.3 | Access to system components and data is managed via an access-control system(s) | Technical enforcement mechanism (RBAC/ABAC engine, ACLs, directory groups) with default-deny configuration |
7.1 is the governance layer — the policy and the defined roles it rests on. 7.2 is where most of the operational substance lives: this is the sub-requirement that specifies least privilege, need to know, default deny-all, documented approval by authorized parties, and — new emphasis carried through from v3.2.1 into v4.0 — periodic review of user accounts and access privileges to confirm they remain appropriate. 7.3 is the technical enforcement layer: an actual access-control system, not a manual spreadsheet somebody updates when they remember to.
"Requirement 7 findings almost never come from a single dramatic mistake. They come from twenty small ones — a role that was never fully defined, an approval that happened over Slack and was never logged, a review that got pushed from Q2 to Q3 and then quietly dropped. By the time we're testing it, the gap between the access-control policy on paper and the entitlements in production has usually been open for months." — Marcus Webb, QSA and Principal Consultant, Ironclad Assessors LLC
Need to Know vs. Least Privilege: Two Different Questions
These two terms get used almost interchangeably in casual conversation, and PCI DSS deliberately keeps them separate because they answer different questions. Need to know asks: does this person's job require access to this specific dataset or system component at all? Least privilege asks: given that they need some access to it, what is the minimum level of privilege — read, write, execute, delete, export — required to do the job? You can satisfy one and fail the other. A customer support rep who legitimately needs to look up a masked PAN to confirm a transaction (need to know: satisfied) but whose account also has export and delete rights on the cardholder database (least privilege: failed) is exactly the profile assessors are trained to find.
Dimension | Need to Know | Least Privilege |
|---|---|---|
Question answered | Should this identity access this data/system at all? | What is the minimum privilege level required? |
Scope | Which resources, datasets, or systems | Which actions on those resources (read/write/admin) |
Failure mode | Access to data unrelated to the job function | Excessive privilege within data the job does require |
Typical control | Role definition tied to job function | Granular permission levels within a role |
Example violation | Warehouse staff can query the payments database | Support agent has delete/export rights on CHD, needs only view |
PCI DSS reference | Req 7.2.1 (roles, need to know) | Req 7.2.2 (least privilege assignment) |
Brightline's marketing intern was a need-to-know failure — there was no legitimate reason for that role to touch a CHD-adjacent view at all. The former DBA-turned-product-manager whose SSH keys still worked eleven months after a role change was a least-privilege failure layered on top of a review failure. Both get written up under 7.2, but they point to different root causes and different fixes.
Defining Access Needs Per Role and Job Function
Requirement 7.1 and 7.2 both start from the same prerequisite: you cannot restrict access by need to know until you've documented what each role actually needs. This sounds obvious and is routinely skipped, because most organizations grow their access model organically — new hire gets "the same access as the person who used to sit in that seat," which means every historical over-grant gets faithfully copied forward.
The fix is a formal access-needs definition exercise, typically run per job function rather than per individual, covering every role that touches system components in or connected to the cardholder data environment (CDE). For each role, you document: which systems it needs to reach, which data classifications within those systems (full PAN, masked PAN, tokenized data, transaction metadata, none), and which operations (view, create, modify, approve, export, delete, administer). This becomes the reference model that both your provisioning process and your periodic reviews are tested against.
Role / Job Function | Systems Accessed | Data Access Level | Operations Permitted | Access Justification |
|---|---|---|---|---|
Customer Support Agent (Tier 1) | CRM, masked-PAN lookup tool | Masked PAN (last 4 digits) only | View | Verify caller identity on active transactions |
Fraud Analyst | Fraud detection platform, transaction logs | Masked PAN, transaction metadata | View, flag, annotate | Investigate suspicious transaction patterns |
Database Administrator (CDE) | Production CHD database | Full PAN (encrypted at rest) | View (via approved tools), backup, restore | Maintain database availability and integrity |
Application Developer | Non-production/test environments only | Synthetic/tokenized test data | View, modify, deploy (test) | Build and test payment application features |
Finance / Settlement Team | Settlement reporting system | Masked PAN, transaction totals | View, export (aggregated reports only) | Reconcile daily settlement against acquirer statements |
IT Security Analyst | SIEM, access-control system logs | Log data referencing masked PAN | View, investigate | Monitor and investigate security events |
Marketing / Growth | Customer engagement platform | None (CHD-adjacent systems excluded) | View (non-CHD fields only) | Campaign targeting using non-payment attributes |
Executive / Finance Leadership | Business intelligence dashboards | Aggregated, de-identified metrics only | View | Strategic reporting; no transaction-level CHD access |
Notice that "Marketing / Growth" is explicitly modeled with no CHD access — that's the row that would have stopped Brightline's intern issue before it started, because the role definition itself excludes the CHD-adjacent view rather than relying on someone remembering to restrict it later.
"The biggest unlock for us wasn't a tool. It was sitting down with every department head for ninety minutes and forcing them to say out loud, in plain language, what their team actually needs to touch. Half the time the answer was narrower than what people already had. The other half, we found gaps nobody had flagged." — Dana Alvarez, CISO, Northfield Retail Group
The Default Deny-All Principle
Requirement 7.2.1 specifically requires that an access-control system default to "deny all" unless a specific allow rule is configured. This is a meaningful design choice, not a technicality. A default-allow posture means every new system, application, or data store starts wide open and gets restricted reactively, which is exactly the model that produces environments like Brightline's — where nobody set out to give a marketing intern access to unmasked PAN data, it simply wasn't actively blocked.
Default deny-all means the starting state for any user, service account, or system is no access, and every grant is an explicit, positive action that must be justified and approved. This flips the burden of proof: instead of security having to catch and revoke inappropriate access, business owners have to actively request and justify appropriate access. It also makes your access-control system audit-friendly, because the full population of "who can touch this" is defined entirely by explicit allow rules rather than by the absence of a deny rule someone forgot to write.
Default-Deny Element | What It Requires | Common Implementation |
|---|---|---|
New user accounts | Zero standing access at creation | Provisioning workflow starts from an empty entitlement set |
New systems/applications | No access group is "open by default" | Access groups created explicitly per system, never inherited broadly |
New data stores in CDE | Not reachable until explicitly granted | Database/object-store ACLs default closed |
Firewall/network rules feeding into access | Deny-all baseline, allow by exception | Aligns with Requirement 1 network segmentation |
Service accounts and APIs | No implicit trust between systems | Explicit service-to-service allow rules, reviewed like human access |
Orphaned or unassigned resources | Inaccessible until owner is assigned | Ownerless systems flagged and access-locked pending assignment |
Documented Approval of Access by Authorized Parties
Requirement 7.2.4 requires that access assignments be based on individual personnel's job classification and function, and that access grants have documented approval by authorized parties specifying the required privileges. This is where a huge share of real-world gaps live — not because organizations don't review access requests, but because the approval happens in an ephemeral channel (a verbal okay, a Slack thread that later gets deleted, an email that was never archived) and can't be reconstructed six months later when the assessor asks for evidence.
An approval workflow that will hold up needs four things: a documented request specifying exactly what is being requested and why, an approver who is authorized for that specific system or data classification (not just "a manager," but the correct data or system owner), a timestamped record of the approval decision, and a retention period long enough to cover your assessment cycle. Ticketing systems and identity-governance platforms are built for this; email and chat generally are not, because they're not structured for retrieval and they get purged.
Workflow Step | Responsible Party | What Gets Documented | Evidence Format |
|---|---|---|---|
1. Access request initiated | Requesting employee or their manager | Specific system, data classification, business justification | Ticket/IAM request record |
2. Role/access-level mapping | Access-control system or IAM admin | Which predefined role or custom entitlement matches the request | System-generated mapping log |
3. Authorization review | Data/system owner (authorized approver) | Approval or denial decision, against least privilege | Approver signature/digital sign-off, timestamped |
4. Provisioning | IT/identity team | Access actually granted, matching approved scope exactly | Provisioning log, matched to approval ticket ID |
5. Confirmation to requester | IAM system | Notification that access is active | Automated notification log |
6. Retention | Compliance/GRC function | Full request-to-provisioning chain retained | Retained per audit-evidence retention policy |
The critical control most organizations miss is step 4's linkage back to step 3 — proving that what was actually provisioned matches exactly what was approved, no more and no less. Assessors routinely sample this chain: pull a current access grant, then ask you to produce the original approval that authorized it. If you can't produce a 1:1 match, that's a finding regardless of whether the access itself is reasonable.
"I tell every client the same thing before their first ROC: if you can't hand me a document trail from 'this person asked for this access' to 'this person has exactly this access, and here's who signed off,' the access being appropriate doesn't save you. Requirement 7 tests the process as much as the outcome." — Renée Fontaine, Internal Security Assessor (ISA), Vantage Hospitality Group
Access-Control Systems That Enforce the Restriction
Requirement 7.3 requires that access be managed through an actual access-control system, or systems, rather than manual, ad hoc administration. In practice, most organizations use some combination of mechanisms depending on the layer being controlled — directory groups for network and application access, database-native role grants for data-layer access, and cloud IAM policies for infrastructure. The specific mechanism matters less than whether it enforces default deny-all, maps cleanly to your documented roles, and produces an auditable configuration state.
Mechanism | How It Works | Best Fit | Limitation |
|---|---|---|---|
Role-based access control (RBAC) | Access granted via predefined roles tied to job function | Most CDE applications and directory-based access | Role sprawl if roles aren't periodically consolidated |
Attribute-based access control (ABAC) | Access decisions evaluated dynamically against user, resource, and context attributes | Complex environments with contextual rules (time, location, device posture) | Higher implementation complexity; harder to audit manually |
Access control lists (ACLs) | Explicit permission entries per resource | File systems, network devices, specific data objects | Doesn't scale well without centralized management |
Mandatory access control (MAC) | System-enforced policy that users cannot override | High-sensitivity, tightly regulated segments of the CDE | Operationally rigid; limited flexibility for edge cases |
Directory-based groups (e.g., AD/LDAP/Entra ID groups) | Access inherited by group membership | Centralizing human-identity access across many systems | Group membership itself needs the same review discipline as direct grants |
Cloud-native IAM policies | Policy documents attached to identities/resources | Cloud infrastructure, APIs, service accounts | Requires discipline to avoid overly broad wildcard permissions |
Most mature CDEs run RBAC as the primary model — it maps most naturally onto the role-based access-needs table built earlier — with ABAC or contextual controls layered on top for higher-risk scenarios, such as requiring a managed device and a specific network location before granting access to the production CHD database. Whatever combination you choose, Requirement 7.3 expects the system itself, not a human's memory or goodwill, to be what actually blocks unauthorized access.
The underlying discipline isn't unique to payments. Organizations running parallel compliance programs will recognize the same access-governance backbone in SOC 2 access controls and user management privileges and in ISO 27001's access control guidance under controls 5.15–5.18 — role-based provisioning, documented approval, and periodic review show up as core expectations across every major framework, which is good news if you're already building this muscle for one standard and need to extend it to cover cardholder data too.
Periodic Review of Access
PCI DSS v4.0 sharpened the language here: Requirement 7.2.4 requires that user accounts and access privileges be reviewed at least once every six months to ensure that access remains appropriate based on job function, and that any inappropriate access is remediated. This is the control that would have caught Brightline's nineteen role-change stragglers and its eleven-month-dormant former-contractor account, and it's also the control most organizations run once, treat as a compliance exercise, and let atrophy.
A review that actually works has an owner, a defined population (every account with access to the CDE, not just a sample chosen for convenience), a documented method for comparing current access against current job function, and a remediation SLA for anything flagged inappropriate. Reviews should be evidenced with sign-off from the actual data/system owner making the appropriateness call — not just IT confirming the account technically still works.
Review Element | Requirement | Common Practice | Failure Mode to Avoid |
|---|---|---|---|
Frequency | At least every 6 months (v4.0) | Quarterly for privileged/admin accounts, semi-annual for standard users | Annual-only reviews, or reviews that slip past 6-month mark |
Population | All accounts with CDE access | Full export from access-control system, reconciled to HR roster | Reviewing only "known" accounts, missing service/orphaned accounts |
Reviewer | Business/data owner familiar with the role | Manager or designated access owner per system | IT reviewing its own provisioning with no business input |
Method | Compare current access to current job function | Access-certification tool with attest/revoke workflow | Manual spreadsheet review with no attestation trail |
Remediation SLA | Prompt removal of inappropriate access | 5–10 business days from flagged finding to revocation | Findings logged but not tracked to closure |
Evidence retained | Review completion, findings, remediation proof | Signed certification report per cycle, tied to review population | No retained proof review actually occurred |
Tying reviews to HR events — terminations, role changes, department transfers — closes the gap between scheduled reviews and real-time risk, but it doesn't replace the periodic review; PCI DSS expects both an event-driven process and the standing six-month cycle. Brightline's post-incident redesign added a rule that any HR-reported role change automatically opens an access-recertification ticket within 48 hours, on top of the semi-annual full review.
"Six months sounds generous until you realize how much churn happens in a mid-size org in that window. New hires, promotions, contractors rolling off, whole teams reorganizing. If your review process can't keep pace with that churn, you're not really reviewing access — you're doing an autopsy on access decisions that are already six months stale." — Tobias Reyes, Access Governance Lead, Coastline Processing
Requirement 7 vs. Requirement 8: Authorization vs. Authentication
One of the most common sources of confusion — inside client organizations and occasionally in vendor marketing copy — is treating Requirement 7 and Requirement 8 as the same control. They're adjacent, complementary, and frequently implemented through the same platform, but they answer fundamentally different questions and PCI DSS tests them separately.
Dimension | Requirement 7 | Requirement 8 |
|---|---|---|
Core question | What is this identity allowed to do? | Is this identity who it claims to be? |
Domain | ||
Primary mechanisms | RBAC/ABAC, approval workflows, access reviews | Passwords, MFA, credential management, account lockout |
Typical failure | Right person, wrong permissions (too broad) | Wrong person able to authenticate as the right one |
Governs | Data and system access scope | Identity verification and credential hygiene |
Example control | Least-privilege role assignment | Multi-factor authentication for all CDE access |
Relationship | Defines the "allow" rules the access-control system enforces | Confirms the identity presenting credentials matches the account those rules apply to |
Think of it this way: Requirement 8 gets you through the door and confirms you are who your badge says you are. Requirement 7 determines which rooms your badge actually opens once you're inside. A perfectly implemented Requirement 8 — strong MFA, no shared credentials, robust lockout policies — does nothing to stop an authenticated, correctly-identified employee from having far more access than their job requires. Conversely, a perfectly scoped Requirement 7 role structure is worthless if Requirement 8 allows someone to authenticate as that employee using a stolen password with no second factor. Assessors test both because a payment environment is only as strong as the weaker of the two.
Access Authorization Flow
The diagram below maps the end-to-end lifecycle a request should follow to satisfy Requirement 7 in a defensible, auditable way — from the moment a business need is identified through to periodic revalidation.
flowchart TD
A[Business Need Identified] --> B[Manager / Data Owner Documents Justification]
B --> C[Access Request Submitted via IAM / Ticketing System]
C --> D{Predefined Role Matches Request?}
D -->|Yes| E[Map Request to Existing Role]
D -->|No| F[Custom Access Request Escalated to System/Data Owner]
E --> G[Authorized Approver Reviews Against Least Privilege]
F --> G
G --> H{Approved?}
H -->|No| I[Request Denied - Decision Logged]
H -->|Yes| J[Access Provisioned in Default-Deny Access-Control System]
J --> K[Grant Logged and Time-Stamped, Linked to Approval Record]
K --> L[Periodic Access Review - Minimum Every 6 Months]
L --> M{Access Still Appropriate?}
M -->|Yes| N[Access Retained - Review Documented]
M -->|No| O[Access Revoked Within Defined SLA]
N --> L
O --> P[Revocation Logged - Feeds Requirement 10 Audit Trail]Every arrow in this flow should correspond to a record you can produce on request. If an assessor can't trace a live access grant back through this chain to an original documented business need, the grant is presumptively out of compliance regardless of whether it happens to be reasonable.
Common Requirement 7 Failures
Across assessments, the same handful of failure patterns account for the overwhelming majority of Requirement 7 findings. Recognizing them in your own environment before an assessor does is the cheapest remediation you'll ever do.
Failure Pattern | Root Cause | Typical Detection Point | Business Impact if Unaddressed |
|---|---|---|---|
Orphaned accounts (former employees/contractors) | Offboarding not linked to access revocation | Periodic review or HR reconciliation | Standing unauthorized access, potential breach vector |
Role creep after internal transfer | Old access never removed when new access granted | Access review comparing role history to current entitlements | Excessive privilege accumulation over tenure |
Access approved verbally, never documented | No formal request/approval workflow | Assessor sample testing (request evidence not found) | Immediate compliance finding, undermines all other evidence |
Shared or generic accounts with CDE access | Convenience provisioning bypassing individual accountability | Log review, account naming convention audit | Breaks need-to-know and complicates incident attribution |
Default-allow configurations on new systems | New system stood up without access-control review | Vulnerability/configuration scanning, architecture review | Unintended broad exposure of CHD to unauthorized roles |
Reviews performed but findings not remediated | No SLA or ownership for closing flagged access | Comparing review reports across cycles | Recurring findings, demonstrates process is cosmetic only |
Third-party/vendor accounts with standing elevated access | No differentiated review cadence for external parties | Vendor access audit | Expanded attack surface outside direct organizational control |
Excessive privilege for convenience ("just give them admin") | Provisioning shortcuts under time pressure | Least-privilege gap analysis | Unnecessary blast radius if account is compromised |
Case Study: Brightline Merchant Services — From 47 Findings to a Clean ROC
Elena's team had sixty days to close Brightline's findings before the sponsor bank deadline. They didn't try to fix everything at once — they triaged. Every account belonging to a terminated employee or contractor was disabled within 72 hours of the finding, regardless of what it accessed, and the offboarding process was rebuilt so that HR's termination event automatically triggered an access-revocation ticket within one business day rather than relying on a manager to remember. That single fix eliminated eleven of the forty-seven findings immediately.
Next, they rebuilt the role model from scratch using the job-function exercise described earlier, running working sessions with every department that touched the CDE. The marketing intern's CHD-adjacent report access was redesigned entirely — the underlying report was rebuilt to pull from a non-CHD data mart, closing the gap at the data-architecture level rather than relying on a permission that could be re-granted by mistake later. The nineteen role-creep accounts were individually reconciled against current job descriptions, with nine losing access outright and ten having their privilege level reduced from modify to read-only.
Finally, they stood up a formal semi-annual access-certification cycle in their identity-governance tool, with data owners — not IT — required to attest to every account under their system within a fixed two-week window, and a five-business-day SLA to revoke anything not re-certified. When the QSA returned for the follow-up assessment, all forty-seven original findings were closed, the ROC was signed nine days ahead of the sponsor bank's deadline, and Brightline's next assessment cycle — eight months later — produced zero Requirement 7 findings for the first time in the company's history. The total cost of the remediation sprint, including two contractor identity-governance specialists and the report re-architecture, ran just under $95,000 — against a processing relationship worth $22 million a year and a forensic-investigation exposure that could have run five times that figure.
"What changed everything for us wasn't a new tool, although we did buy one. It was making access owners actually accountable — putting a real person's name on 'I attest this access is still appropriate,' instead of IT quietly maintaining a list nobody outside the department ever looked at." — Elena Marsh, VP of Platform Security, Brightline Merchant Services
Case Study: A Level 2 Merchant's Vendor Access Wake-Up Call
A regional restaurant chain — 340 locations, validating as a PCI DSS Merchant Level 2 via SAQ D because of a custom loyalty-and-payments integration — brought in a third-party point-of-sale support vendor years earlier to help with an initial rollout. The vendor's remote-access account, provisioned with broad administrative rights "to make the rollout easier," was never scoped down after go-live. Four years later, during a pre-assessment gap analysis ahead of their first Level 2 QSA-assisted review, the security team discovered the vendor account was still active, had never been reviewed, had no MFA enforced on it (a separate Requirement 8 gap), and had full administrative access across every POS terminal's back-end management console — a level of access no single internal employee held.
The remediation took a different shape than a typical internal-account fix, because the account belonged to an external party the company didn't directly control. The security team first suspended the account entirely, then worked with the vendor to define exactly what ongoing access the current support contract actually required — which turned out to be read-only diagnostic access to a small subset of terminals, provisioned only during active support tickets rather than as a standing grant. They implemented a time-bound access model: vendor access is now automatically provisioned when a support ticket opens and automatically revoked when the ticket closes, with every session logged. The chain also formalized a vendor access inventory as part of its vendor risk management program, requiring every third party with any CDE-adjacent access to be reviewed on the same six-month cycle as internal accounts, with contract renewal explicitly gated on that review being current. The follow-up assessment found zero standing third-party access anywhere in the environment — a result the CISO called "the single biggest scope-and-risk reduction we got from the entire compliance program, and it cost almost nothing to implement."
Third-Party and Vendor Access Under Requirement 7
Vendor and contractor access deserves its own discipline because it sits outside your normal HR-driven lifecycle — there's no automatic termination event when a vendor's staff member rotates off your account, and standing remote-access grants are common precisely because they're convenient for support work.
Vendor Access Consideration | Requirement 7 Expectation | Practical Control |
|---|---|---|
Scope of access | Limited to specific systems/data the contracted work requires | Time-bound, ticket-linked provisioning rather than standing access |
Approval | Same documented-approval standard as internal accounts | Business owner (not just procurement) signs off on scope |
Review cadence | Included in periodic review population | Vendor accounts flagged distinctly in access-certification reports |
Offboarding trigger | Access removed when contract/engagement ends | Contract end-date tied to access-control system expiration |
Individual accountability | No shared vendor logins | Named individual accounts per vendor staff member, even for third parties |
Documentation | Access terms reflected in the vendor contract/SLA | Security requirements addendum specifying access scope and review rights |
Cloud and SaaS Access Governance
Modern CDEs rarely live entirely on-premises, and cloud/SaaS platforms introduce access surfaces that don't always map neatly onto a traditional role model — think cloud console access, API keys, and third-party SaaS tools that touch tokenized or masked cardholder data.
Cloud/SaaS Access Layer | Requirement 7 Challenge | Recommended Control |
|---|---|---|
Cloud provider console (IAM) | Broad built-in roles (e.g., "Owner," "Admin") don't map to need-to-know | Custom least-privilege policies scoped per resource, avoid built-in broad roles |
API keys and service accounts | Often provisioned once and never reviewed | Treat as identities: owner assigned, reviewed on same cycle, rotated regularly |
SaaS application roles | Vendor-defined role granularity may be coarse | Select the most restrictive built-in role that satisfies the job function; document gaps |
Federated/SSO access | Access sprawl across many apps via one identity | Central IAM governance covering every federated application, not just the CDE core |
Multi-cloud/shadow IT | Unsanctioned cloud services processing CHD-adjacent data | CDE scoping exercise to identify and either govern or eliminate unsanctioned services |
Privileged Access and Administrative Accounts
Administrative and privileged accounts — database administrators, cloud infrastructure admins, domain administrators — deserve a materially stricter version of everything described above, because a compromised or misused privileged account can bypass the very controls Requirement 7 is trying to enforce.
Privileged Access Control | Why It Matters for Requirement 7 | Implementation |
|---|---|---|
Separate privileged accounts from daily-use accounts | Prevents standing admin rights from being used for routine, non-admin tasks | Named individuals get a distinct "-admin" account, used only for privileged actions |
Just-in-time elevation | Reduces standing privilege exposure window | PAM platform grants time-boxed elevation on request/approval |
Session recording for privileged access | Provides evidence of what privileged access was actually used for | PAM session logging feeding into Requirement 10 monitoring |
Tighter review cadence | Higher blast radius justifies more frequent recertification | Quarterly review for privileged accounts vs. semi-annual for standard users |
Approval by two parties for highest-risk grants | Reduces single-point-of-failure approval risk | Dual approval (manager + security) for domain admin / production DBA grants |
Segregation of Duties as a Requirement 7 Discipline
Segregation of duties isn't a separate PCI DSS requirement in the way it's a named control elsewhere, but it's an implicit expectation woven through Requirement 7's least-privilege and role-design language: no single role should combine the ability to both request/approve access and provision it, or to both process a transaction and approve a refund on it, without a compensating check. Segregation of duties failures are exactly the kind of finding that turns a "technically approved" access grant into a fraud-risk finding.
Conflicting Function Pair | Risk if Combined in One Role | Segregation Control |
|---|---|---|
Access request approval + access provisioning | Approver can self-authorize and self-provision | Approver and provisioner must be different individuals/roles |
Transaction processing + refund approval | Enables fraudulent refund-to-self schemes | Refund approval routed to a separate role/manager |
Database administration + security log review | Admin could alter data and suppress evidence of it | Log review performed by a role without DBA write access |
Application development + production deployment | Developer could push unreviewed/malicious code with CHD access | Deployment requires a separate release-management approval |
Vendor access provisioning + vendor contract management | Same person controls both the relationship and the access grant | Access approval routed through internal security, not procurement alone |
Evidence Requirements for QSA and Internal Assessment
Whether you're preparing for a QSA-led ROC or completing a SAQ internally, the evidence expectations for Requirement 7 are consistent, and building the evidence trail as you go is dramatically cheaper than reconstructing it under deadline pressure.
Testing Procedure Area | Evidence to Have Ready | Owner |
|---|---|---|
Documented access-control policy (7.1) | Current, approved policy document; version history | Compliance/GRC |
Role definitions (7.2.1) | Role-to-access matrix, mapped to job functions | IAM/Security |
Least-privilege assignment (7.2.2) | Sample of accounts with privilege level justified against role | IAM/Security |
Default deny-all configuration (7.2.1/7.3) | System configuration export showing deny-all baseline | Infrastructure/Security |
Documented approvals (7.2.4) | Request-to-provisioning chain for sampled accounts | IAM/Help Desk |
Periodic review evidence (7.2.4) | Signed certification reports for the last 1–2 review cycles | Data/system owners |
Access-control system configuration (7.3) | Screenshots/exports of RBAC/ABAC engine configuration | Infrastructure/Security |
Remediation tracking | Closed-loop evidence that flagged access was actually revoked | IAM/Security |
Keep this evidence current continuously rather than assembling it in the weeks before an assessment. An audit trail that already exists is credible; one hastily reconstructed the week of the assessment invites exactly the kind of scrutiny that turns a routine testing sample into a broader investigation.
Common Pitfalls, Time to Fix, and Relative Cost
Not every Requirement 7 gap is equally expensive to close, and prioritizing matters when you're working against an assessment deadline or a limited remediation budget.
Pitfall | Typical Time to Remediate | Relative Cost | Priority |
|---|---|---|---|
Orphaned former-employee/contractor accounts | 1–3 days per finding | Low | Immediate |
No documented approval trail (process gap, not access gap) | 2–6 weeks to stand up workflow | Medium | High |
Role model doesn't exist or is outdated | 4–8 weeks for full role-definition exercise | Medium–High | High |
Default-allow system configuration | 1–4 weeks depending on system count | Medium | High |
No periodic review process | 3–6 weeks to design and run first cycle | Medium | High |
Vendor/third-party standing access | 2–8 weeks depending on vendor cooperation | Medium | High |
Privileged access not separately controlled | 6–12 weeks for PAM implementation | High | Medium–High |
Segregation-of-duties conflicts baked into org structure | 8–16 weeks (may require role redesign) | High | Medium |
Tools and Automation for Access Governance
Manual spreadsheet-based access management scales to roughly the size of Brightline's original 47-finding problem — and then breaks. Most organizations serious about sustaining Requirement 7 compliance invest in some combination of the following tool categories.
Tool Category | Function | Requirement 7 Value |
|---|---|---|
Identity governance and administration (IGA) | Centralizes provisioning, approval workflow, and certification campaigns | Automates the request-approval-review lifecycle end to end |
Privileged access management (PAM) | Just-in-time elevation, session recording, credential vaulting | Directly addresses privileged-account risk and evidences use |
Directory services (AD/Entra ID/LDAP) | Central group-based access management | Backbone for RBAC enforcement across systems |
Cloud IAM policy management | Least-privilege policy analysis and drift detection | Flags overly broad cloud permissions automatically |
GRC/compliance platforms | Evidence collection, review scheduling, audit trail retention | Keeps certification and approval evidence audit-ready year-round |
SIEM integration | Correlates access grants/changes with activity logs | Feeds Requirement 10 monitoring, closes the loop on unusual access use |
Implementation Roadmap
Organizations building or rebuilding a Requirement 7 program from a weak baseline generally move through the same phases, whether the trigger is a QSA finding, a self-assessment gap, or a proactive security initiative.
Phase | Timeframe | Key Activities |
|---|---|---|
1. Discovery | Weeks 1–3 | Inventory all CDE-connected systems; export current entitlements; reconcile against HR roster |
2. Role definition | Weeks 3–7 | Working sessions per department; build role-to-access matrix; identify need-to-know/least-privilege gaps |
3. Immediate remediation | Weeks 1–4 (parallel) | Disable orphaned accounts; revoke clearly excessive access; document interim exceptions |
4. Process design | Weeks 5–9 | Build documented approval workflow; define default-deny configuration standard; select/configure IAM tooling |
5. Technical enforcement | Weeks 7–12 | Implement RBAC/ABAC in access-control systems; configure default-deny baselines |
6. First review cycle | Weeks 10–14 | Run initial full access certification; close flagged findings within SLA |
7. Steady state | Ongoing, every 6 months | Recurring reviews, HR-event-triggered recertification, vendor access audits, evidence retention |
Requirement 7 as a Business Opportunity, Not Just a Checkbox
It's tempting to treat Requirement 7 as pure compliance overhead — a documentation exercise that exists to satisfy an assessor once a year. That framing misses what actually happened at Brightline and at the restaurant chain in the case studies above: both organizations came out of their remediation with a smaller attack surface, faster onboarding (because a defined role model means new hires get correctly-scoped access on day one instead of an ad hoc copy of someone else's permissions), and a much shorter incident-response investigation window, because "who could have touched this data" became a query against clean role data instead of a forensic archaeology project.
There's a commercial angle here too. Enterprise customers and payment partners increasingly ask pointed access-governance questions during vendor security reviews — "show me your access review cadence," "who approves access to cardholder data," "how quickly do you revoke access when someone leaves." A mature, evidenced Requirement 7 program answers those questions in minutes instead of triggering a scramble, and it signals operational maturity well beyond the payments function specifically. Treated well, Requirement 7 compliance becomes a sales enablement asset as much as a risk-reduction one.
If you're building or rebuilding this program, don't start from a blank page. Our PCI DSS 12-Requirements Checklist walks through every requirement including the specific testing procedures under Requirement 7, our PCI DSS Gap Analysis Tool benchmarks your current access-control posture against the standard, and our PCI DSS Policy Pack includes a ready-to-adapt access-control policy template that maps directly onto 7.1's documentation requirement. If you're not yet sure where your program stands, start with the "Are You PCI DSS Ready?" quiz for a quick baseline before committing to a full gap analysis.
Access governance done right isn't glamorous. It's role matrices, approval logs, and recurring certification cycles that nobody notices when they're working. But it's also the difference between an assessor finding forty-seven quiet gaps and finding zero — and between a breach investigation that takes an afternoon versus one that takes months and six figures. Build the boring part well, and it stops being the thing that keeps you up before an assessment.