Your payment processor requires annual PCI DSS validation. Your Qualified Security Assessor arrives and asks:

"Show me quarterly access reviews for everyone with access to the cardholder data environment."

You pull up your access list.

Forty-seven people have production database access where payment card data lives. Thirty-two haven't logged in this year. Eight no longer work at your company—their access was never revoked during offboarding.

Your quarterly reviews?

You did one nine months ago. Missed the last two quarters entirely.

The QSA flags a finding:

"Requirement 7.2.3 non-compliance—user access not reviewed at least quarterly. Requirement 8.1.4 non-compliance—inactive accounts not removed within 90 days."

Payment processing stops immediately. Your merchant account gets flagged for review. Your acquiring bank imposes penalties—$5,000 to $100,000 per month until compliance is restored. You're liable for breaches during the non-compliant period.

You cannot process credit cards. Which means you cannot do business.

Table of Contents

• What Makes PCI DSS Different From Other Frameworks
• The 90-Day Dormant Account Requirement
• The 30-Day Review Window That Never Closes
• The Cardholder Data Environment Scope Challenge
• The Five Patterns That Cause QSA Findings
• Evidence Format QSAs Expect
• How Continuous Discovery Prevents CDE Scope Gaps
• Implementation Timeline: 30 Days to Your First Review
• Getting Started With PCI-Compliant Access Reviews

What Makes PCI DSS Different From Other Frameworks

PCI DSS is the only major compliance framework that's enforced through economic pressure rather than legal mandate. No law requires PCI compliance.

But if you want to accept credit cards—which means doing business at all for most companies—you must comply.

The enforcement mechanism is immediate. Non-compliance means losing the ability to process payments. Not fines you can pay. Not public disclosure you can manage. Actual business shutdown until you fix the problems.

This creates different audit dynamics than frameworks like SOX (where you might negotiate remediation timelines) or ISO 27001 (where you might debate risk-based frequency). With PCI DSS, your QSA has no flexibility—requirements are prescriptive, and you either meet them or you don't.

The technical requirement is semi-annual reviews under PCI DSS v4.0 (every 6 months). The practical reality is that most QSAs and payment processors expect quarterly reviews. If you're handling significant transaction volumes, quarterly becomes the de facto standard.

Your payment processor's compliance team doesn't care about your preferred review frequency. They care about staying in business, which means enforcing PCI to the letter.

The 90-Day Dormant Account Requirement

Requirement 8.1.4 creates specific operational pressure that doesn't exist in other frameworks: Accounts inactive for 90+ days must be disabled or removed. Not 120 days. Not "eventually." Ninety days.

QSAs test this by sampling user accounts and checking last login dates. They find accounts with 127 days of inactivity? That's non-compliance even if everything else is perfect.

Here's what happens during a typical QSA review:

Your QSA pulls your payment database user list. Sixty-three accounts. They sample ten accounts randomly. They check the last login timestamps.

Three accounts haven't logged in for over 90 days:

• Sarah's account: 127 days inactive. She moved to the marketing team eight months ago but her database access was never revoked.
• Marcus's account: 156 days inactive. He's been on parental leave but his account was never suspended.
• An automated reporting script: 203 days inactive. The script broke six months ago but the service account remained active.

Your QSA flags all three. Non-compliance. You need to prove you have controls that identify and remove dormant accounts within 90 days, not just that you eventually found them.

The challenge is most organizations can't identify dormant accounts systematically.

HR knows when someone terminates. But they don't know when someone stops using the payment gateway.

Managers know their team's responsibilities. But don't track actual login behavior.

A hospital (one of our clients) described this exact gap: "We don't know if a user has admin permissions or regular permissions. If someone had admin access for a certain period and we forget to remove it later, it stays indefinitely. We only discover it during annual audits."

Quarterly access reviews catch these situations. But catching them isn't enough—QSAs test whether you actually removed the access within 90 days of last use. Finding dormant accounts in Q2 review that existed since Q1 meets the letter of the requirement but suggests weak continuous monitoring.

The pattern QSAs look for: Are dormant accounts being caught by quarterly reviews before they exceed 90 days? Or are they accumulating for 6-9 months before anyone notices?

The former suggests working controls. The latter suggests reviews are too infrequent or ineffective.

The 30-Day Review Window That Never Closes

A Singapore financial services firm managing 200+ applications described their quarterly review burden: "Some of our environments aren't synchronized to our ecosystem. Those are manually managed. Our team pulls out reports, converts them to spreadsheets, imports into our database, and manipulates the data. It's going to be more than 30 days of window. And that 30 days is every quarter."

Thirty days every quarter means 120 days per year—one-third of your time spent on manual access governance just for PCI. That's before adding SOX reviews for financial systems, SOC 2 reviews for customer data, and ISO reviews for information assets.

The manual process compounds:

Export users from payment gateway. Export users from database. Export users from VPN with CDE access. Export users from cloud infrastructure running payment systems. Consolidate into a master spreadsheet. Email to reviewers. Chase reminders. Compile responses. Create Jira tickets for revocations. Follow up on incomplete tickets. Generate evidence for QSA. Store in the audit repository.

Repeat every quarter. Forever.

A hospital managing 60 applications described the execution challenge: "When we have audits, we have to remove users from software manually. Going to each tool, downloading the Excel file, checking whether they are present, then removing them. Doing it manually takes a lot of work and creates human error."

The Excel-based approach breaks down under three pressures:

Completeness challenges: How do you prove you reviewed everyone? What if the export was missing recently added users? What if someone's access changed between export and review?

Timeliness challenges: Reviews take 30 days to complete. Remediations take another 30 days. You're consuming half the quarter just doing reviews. That leaves no buffer for delays.

Evidence quality issues: QSAs want system-generated logs with timestamps and digital signatures. A compliance consultant described the common evidence failure: "Clients show us spreadsheets where someone checked boxes. We ask: 'Who checked these boxes?' 'When exactly?' 'Can you prove this person actually saw the full user list before approving?' 'What changed in the system after this approval?' They can't answer. That fails QSA scrutiny."

Manually compiled spreadsheets don't satisfy evidence requirements because they lack tamper-evidence. Anyone can modify an Excel file, change timestamps, add names retroactively. System-generated logs with cryptographic hashing prove integrity. When your QSA exports audit trails and verifies those logs match system records, that's acceptable evidence. Spreadsheets aren't.

The Cardholder Data Environment Scope Challenge

PCI DSS applies only to your CDE—the systems that store, process, or transmit payment card data. Proper scoping dramatically reduces compliance burden.

The challenge is most organizations don't actually know their complete CDE scope.

Payment data has a way of spreading beyond the official payment gateway.

Common CDE scope surprises we've seen across hundreds of validations:

Support ticketing systems: Your QSA asks about customer support tools. "We use Zendesk—it doesn't process payments," you explain. They request a sample of tickets. You search for card numbers. You find 847 tickets where customers shared full PANs during support calls. Zendesk just entered your CDE scope. So did every employee with Zendesk access—63 people across support, operations, and management.

Development environments: Your QSA asks to review development and staging environments. "They don't process real payments," you explain. They ask to see the data. You discover developers populated the staging database with production data for testing six months ago. Your staging environment just entered CDE scope. So did everyone with staging access—17 developers, 5 QA engineers, 3 DevOps engineers.

Finance reports: Your QSA asks if anyone exports transaction data. You check with finance. They've been downloading monthly transaction reports to Excel for chargeback analysis—reports containing full card numbers, stored in Google Drive. Google Drive just entered CDE scope. So did every finance team member with access to these folders.

A healthcare organization preparing for PCI validation discovered their CDE scope was far larger than expected. They initially thought their CDE was just the payment gateway. Then they found support tickets in Zendesk containing full card numbers users had shared. Their business intelligence team had transaction exports in Looker with partial card data. Their QSA determined all of these systems were in scope. Their access reviews had been incomplete.

Effective PCI access reviews require knowing the complete CDE scope first. You can't review access to systems you don't know exist.

The Five Patterns That Cause QSA Findings

We've supported PCI validations across payment processors, e-commerce platforms, and healthcare organizations. The same five patterns cause compliance failures. Companies that pass annual assessments without remediation findings have systematically eliminated these gaps:

Pattern 1: Incomplete CDE Visibility

Traditional IGA platforms assume you already know your complete CDE scope. They provision and review access to systems you've explicitly configured. They don't discover what exists.

This creates the classic validation failure: Your QSA asks "How do you know this is your entire CDE?" Your answer can't be "this is what we think we have."

The problem manifests in specific ways:

Marketing implements a new customer feedback tool that inadvertently captures payment details. Engineering stands up a new analytics database that pulls from production. A developer spins up a cloud instance for testing and copies production data. Your support team starts using a new ticketing system that logs full customer interactions.

Your defined CDE scope becomes outdated the moment it's documented. By the time your QSA arrives for annual validation, scope has expanded but your access reviews haven't.

Most organizations focus on payment gateways but miss supporting systems. Database backups, support tickets, analytics exports—all frequently contain cardholder data but don't appear in access reviews. Systematic discovery prevents scope gaps.

Pattern 2: Manual Dormant Account Tracking

Spreadsheet-based reviews can't effectively identify 90-day inactive accounts. You need automated last-login tracking that flags accounts approaching the threshold before they violate requirements.

Here's what actually happens:

You export user lists in January for Q1 review. The export shows last login dates. You review in February. You find accounts inactive since October (120+ days). You mark them for removal. Remediation happens in March.

Your Q1 review found the violations. But those accounts violated the 90-day requirement in January, and you didn't catch them until February. QSAs see this pattern as a control gap.

Automated tracking flags accounts at 75 days: "This account will violate the 90-day requirement in 15 days." Reviewers address it before the violation occurs. That demonstrates working controls.

Pattern 3: Service Account Blindspot

Your QSA asks for your complete CDE user list. You provide 127 employee accounts. They ask about service accounts. "What service accounts?"

You check. Your payment processing infrastructure has 34 service accounts, for example, automation accounts for fraud detection systems. None appeared in your quarterly access reviews.

Your reviewers focused on human accounts and forgot that service accounts also access cardholder data.

Service accounts represent a major blind spot because they lack the attributes reviewers expect:

• No last login timestamps (they authenticate via API keys)
• No manager to review them
• No HR record showing employment status
• Created by engineering teams who don't think of them as "users"

QSAs find them immediately. Human accounts get reviewed. Service accounts get forgotten.

Pattern 4: Remediation Delays

Finding violations is straightforward. Executing revocations across payment systems, databases, and infrastructure within the quarter is hard.

The typical timeline:

Week 1-2: Export user lists Week 3-4: Conduct reviews Week 5-6: Compile results and approvals Week 7-8: Create Jira tickets for revocations Week 9-10: IT team works through ticket backlog Week 11-12: Follow up on incomplete remediations Week 13: QSA arrives, finds remediations still pending

You identified the violations in week 4. Remediations execute in week 11-12. You've consumed the entire quarter just executing one review cycle.

Closed-loop automation is the only way to meet quarterly deadlines consistently. Approved revocations execute immediately via API for supported applications. For systems without API support, automated tickets route to app owners with complete context. Before/after evidence is captured automatically.

Pattern 5: Inadequate Evidence

A Singapore firm managing 200+ applications explained the evidence challenge: "We spend over a week consolidating all these reports. Some platforms don't even have native integrations, so we need plugins or custom scripts. It's manual work every time."

QSAs want evidence in specific formats because they're testing multiple organizations using standardized procedures. System-generated logs with immutable audit trails satisfy QSA requirements in ways that manually compiled spreadsheets never will.

When your QSA requests Q2 evidence and you export complete packages within minutes—showing all required elements with proper timestamps and digital signatures—their testing goes faster and findings decrease.

Evidence Format QSAs Expect

Your QSA arrives with standardized testing procedures. Understanding what they need eliminates back-and-forth.

For each quarterly review period, prepare:

CDE inventory showing all systems in scope with justification for why each system stores, processes, or transmits cardholder data. Include data flow diagrams showing how card data enters each system.

User access lists exported from each CDE system showing every account with access. Timestamp the export—QSAs verify the list was current at time of review. Include both human users and service accounts.

Review results documenting individual decisions for each user-access pair. Must show: reviewer identity, timestamp, decision (approve/revoke), business justification for approval, last login date, account type (employee/contractor/vendor).

Remediation logs showing every revocation with execution timestamp. Include before/after exports proving changes occurred. For service accounts or admin access, document why revocation couldn't happen immediately and compensating controls applied during delay.

Dormant account reports specifically highlighting any accounts with 90+ days inactivity and how they were handled. QSAs will sample from this list.

Service account registry documenting all non-human accounts, their owners, purpose, and review status. 

Store all evidence for at least 12 months. Many organizations retain 3 years for historical reference and investigation purposes.

How Continuous Discovery Prevents CDE Scope Gaps

Your defined CDE scope constantly shifts. Marketing implements a new customer feedback tool. Engineering stands up a new analytics database. A developer spins up a cloud instance for testing. Your support team adopts a new ticketing system.

Traditional compliance approaches rely on annual scoping exercises. By the time your QSA arrives, scope has expanded but your access reviews haven't caught up.

We built Zluri around access visibility: continuous detection of application, users and access, not just annual scoping:

IdP integration tracks SSO application additions. IT provisions a new payment processing tool through Azure AD or Okta? We pull the assignment data automatically.

Finance integration discovers new tools through expense data. When IT approves a new SaaS purchase, we flag it within days based on the expense transaction. Marketing implements a payment-adjacent tool? Discovery identifies it before your next quarterly review.

Browser extensions catch web-based systems. Your support team starts using a new web portal to process refunds? Browser usage detection identifies it immediately.

Desktop agents find locally installed applications. Developers install database query tools with production access? Desktop discovery flags them before they create compliance gaps.

HR system integration identifies access that persists after role changes. Employee moves from finance to marketing? HR data shows the role change even if their payment system access wasn't revoked.

In total, there are 9 discovery methods that give you complete visibility.

This matters for PCI because QSAs test scope completeness. Your answer needs to be: "Systematic discovery identifies all applications, automated classification flags potential CDE systems based on data flow patterns, access reviews cover verified CDE scope with evidence showing no gaps."

When your payment team implements a new invoicing tool mid-year that stores partial card data for recurring billing, Zluri discovery engine flags it within days. Classification workflow determines if it handles cardholder data. If yes, it automatically enters quarterly review scope before your next QSA visit.

Implementation Timeline: 30 Days to Your First Review

Traditional enterprise IGA platforms require months of implementation before conducting first reviews. SailPoint implementations typically run 6-12 months.

For companies facing quarterly PCI deadlines, that's too slow.

A healthcare organization explained their timeline pressure: "We need to be ready for PCI validation in 90 days. If implementation takes six months, we'll miss our payment processor deadline and lose the ability to bill patients for procedures."

We deploy access reviews in 30 days:

Week 1—Discovery: Connect to identity providers, payment systems, cloud platforms, and HR tools. Nine discovery methods run an initial sweep identifying all applications and users, providing complete access visibility across your CDE.

Week 2—CDE Scoping: Identify which applications store, process, or transmit cardholder data through risk classification. Determine review frequency and depth. Test integration APIs for automated remediation.

Week 3—Reviewer Configuration: Configure reviewer assignments. Reporting managers receive their team rosters. Identify application owners for each CDE system. Assign security team for privileged access review. Designate fallback reviewers for coverage.

Week 4—Pilot Review: Execute first pilot review for 2-3 high-priority CDE systems. Generate evidence package. Internal team reviews evidence against QSA requirements. Test remediation workflows for both API-supported and manual applications.

By day 30, you're running production quarterly reviews generating QSA-ready evidence. This compressed timeline matters because PCI validation happens annually but reviews must occur quarterly. Starting fast means you have a complete quarterly evidence trail by your next annual assessment.

Getting Started With PCI-Compliant Access Reviews

Most access governance vendors approach PCI compliance as "implement our enterprise IGA platform, spend months configuring policies and integrations, then start running compliant reviews."

For companies with payment processor deadlines measured in weeks, that approach fails.

We recommend starting with your most pressing compliance need: quarterly CDE access reviews that keep you processing payments. Get compliant now.

What you need for PCI-compliant access reviews:

Complete CDE discovery through nine detection methods ensures you find all systems with CDE access, not just officially sanctioned payment applications. Finance integration identifies shadow payment tools purchased outside IT approval. Browser extensions catch web-based payment portals. Desktop agents find database query tools with production access. No CDE system goes undiscovered.

Quarterly scheduling launches CDE reviews automatically. Q1 January, Q2 April, Q3 July, Q4 October. Reviews launch on time every quarter with automated reminders to reviewers and escalation workflows for overdue items.

Dormant account detection automatically flags accounts with 90+ days inactivity. Reviewers see "No login in 127 days—requires action" immediately. They can't approve the access without either documenting business justification or marking for revocation. Dormant accounts can't hide.

Service account governance provides a separate workflow for reviewing non-human accounts. Each service account requires a documented owner, business purpose, access scope, and last activity review.

Closed-loop remediation executes approved revocations immediately via API for supported applications. For systems without API support, automated tickets route to app owners with complete context (who approved revocation, when, why). Before/after evidence is captured automatically. No manual exports, no Jira tickets sitting incomplete.

Immutable audit trail logs every review decision with timestamp and reviewer identity. System-generated logs can't be modified retroactively. QSAs export complete audit trail showing who reviewed what, when, with what result. Digital signatures prove evidence integrity.

Evidence export for QSAs generates PCI compliance evidence packages on-demand. Select quarter, export complete documentation formatted for QSA consumption. Includes all required elements: CDE inventory, user lists with timestamps, review decisions, remediation logs, before/after proof, dormant account handling, service account registry, management sign-offs.

Your reviews will reveal operational patterns—dormant accounts from incomplete offboarding, contractors with excessive CDE privileges, service accounts with unclear ownership. These point to upstream provisioning and lifecycle management opportunities that reduce ongoing compliance burden.

But first, get the quarterly CDE reviews that keep you processing payments.

See PCI-compliant access reviews → Book Demo

Frequently Asked Questions

What is PCI DSS and why does it matter?

PCI DSS (Payment Card Industry Data Security Standard) is a security framework that applies to any organization that stores, processes, or transmits payment card data. Unlike other compliance frameworks, PCI is enforced economically—non-compliance means losing the ability to process credit card payments, which effectively shuts down most businesses.

How often do I need to conduct PCI access reviews?

PCI DSS v4.0 technically requires semi-annual (every 6 months) access reviews for users with access to the cardholder data environment (CDE). However, most QSAs and payment processors expect quarterly reviews (every 3 months) as the de facto standard, especially for organizations with significant transaction volumes.

What is the cardholder data environment (CDE)?

The CDE includes all systems that store, process, or transmit payment card data. This typically includes your payment gateway, payment processing databases, systems with API access to payment data, backup systems containing payment data, and any tools where payment information might be logged or exported.

What is Requirement 8.1.4 about dormant accounts?

Requirement 8.1.4 mandates that accounts inactive for 90+ days must be disabled or removed. QSAs test this by sampling user accounts and checking last login dates. Accounts with more than 90 days of inactivity are immediate compliance failures.

What evidence do QSAs require for access reviews?

QSAs require: CDE inventory with data flow diagrams, user access lists with timestamps from each system, review results showing reviewer identity and decisions for each user, remediation logs with before/after proof, dormant account reports, and service account registries. All evidence must be system-generated with immutable audit trails, not manually compiled spreadsheets.

Why don't spreadsheet-based reviews satisfy QSA requirements?

Spreadsheets lack tamper-evidence. Anyone can modify an Excel file, change timestamps, or add names retroactively. QSAs require system-generated logs with cryptographic hashing that prove integrity. When QSAs export audit trails and verify logs match system records, that's acceptable evidence. Spreadsheets aren't.

What are service accounts and why do they matter for PCI?

Service accounts are non-human accounts used for system integrations, automation, and batch processing. They include API keys, automation credentials, and batch job accounts. They're a major compliance blind spot because they lack traditional attributes (no last login, no manager, no HR record) but often have extensive CDE access. QSAs specifically test whether service accounts are included in quarterly reviews.

How long does it take to implement PCI-compliant access reviews?

Traditional enterprise IGA platforms require 6-12 months of implementation. We deploy access reviews in 30 days through a phased approach: Week 1 discovery, Week 2 CDE scoping, Week 3 reviewer configuration, Week 4 pilot review. By day 30, you're running production quarterly reviews generating QSA-ready evidence.

What happens if I fail a PCI validation?

Non-compliance findings trigger immediate consequences: payment processing may be suspended until remediation is complete, acquiring banks impose penalties ($5,000-$100,000 per month), payment processors may terminate merchant accounts, and you face potential liability for breaches during the non-compliant period. The severity depends on the findings and your transaction volume.

Can Zluri help with other compliance frameworks beyond PCI?

Yes. While this article focuses on PCI DSS access reviews, Zluri supports comprehensive identity governance including SOX, SOC 2, ISO 27001, GDPR, and HIPAA compliance. The same discovery, review workflows, and evidence generation capabilities extend across all frameworks. Many organizations use Zluri for unified access governance across multiple compliance requirements.