What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a security framework managed by the PCI Security Standards Council — formed by American Express, Discover, JCB, Mastercard, and Visa. It applies to any organisation that stores, processes, or transmits payment cardholder data, including merchants, payment processors, and service providers. Unlike most security frameworks, PCI DSS compliance is not voluntary: it is contractually required by card brands, and non-compliance can result in fines, increased transaction fees, and ultimately loss of the ability to process card payments.
PCI DSS version 4.0 was released in March 2022 and became mandatory in March 2024. It introduced several significant changes to access control requirements — most notably the requirement for quarterly reviews of all user accounts with access to the cardholder data environment (CDE).
The scope of PCI DSS is the cardholder data environment — the systems that store, process, or transmit card data, plus any systems that can affect their security. Requirement 7 governs who has access to these systems. Requirement 8 governs how those users are identified and authenticated.
Requirements 7 & 8: What They Actually Require
| Requirement | What it requires |
|---|---|
| Req. 7.1 | Processes and mechanisms for restricting access to system components and cardholder data are defined and understood. |
| Req. 7.2 | Access to system components and data is appropriately defined and assigned — access is limited to the minimum necessary (need-to-know / least privilege). |
| Req. 7.2.4 ⚠️ NEW | Review of all user accounts and related access privileges at least once every six months. Reviews must confirm access is still appropriate. Accounts of terminated/changed users must be reviewed promptly. (In practice, many QSAs interpret 'at least every six months' as quarterly for CDE admin accounts.) |
| Req. 7.2.5 | Application and system accounts have the minimum privileges required for their function. Reviewed at least once every six months. |
| Req. 8.2 | All users in the CDE have unique IDs. No shared accounts. Generic accounts prohibited except for documented exceptions. |
| Req. 8.6 | System and application accounts and associated authentication factors are managed strictly — least privilege, no interactive login for system accounts, all non-interactive accounts logged. |
Requirement 7.2.4 is the critical new obligation in v4.0
Previous versions of PCI DSS required periodic reviews but did not specify frequency. v4.0 explicitly requires reviews at least every six months — and for privileged accounts, many QSAs and internal compliance teams implement more frequent reviews to manage risk. At minimum, twice a year you must review every account in your CDE scope, document who performed the review, what was examined, and what actions were taken.
Why this matters for management
PCI DSS non-compliance is not a theoretical risk — it carries concrete financial consequences. Card brands can fine acquiring banks between $5,000 and $100,000 per month for non-compliant merchants, and those costs are passed to the merchant. Following a data breach involving cardholder data, the forensic investigation costs, card re-issuance fees, and fraud liability can reach millions. Cyber insurers are now routinely asking for PCI DSS compliance evidence before underwriting payment-related risk. For any organisation processing card payments — whether as a merchant, processor, or service provider — Requirements 7 and 8 are not compliance paperwork; they are the direct controls standing between your organisation and a breach that becomes a business-ending event.
What QSAs test for Requirements 7 & 8
A Qualified Security Assessor conducting your annual Report on Compliance (RoC) or Self-Assessment Questionnaire (SAQ) validation will specifically test:
- Req 7.2.4 review records: "Provide documentation for each quarterly access review conducted this year — date, reviewer, scope (which accounts/systems), and decisions made for any accounts flagged." They expect four sets of records for a 12-month assessment period.
- Req 8.2 unique IDs: Request the full user list for CDE systems and check for any shared or generic accounts. Each account must map to a unique individual with a documented business justification.
- Terminated user access: Cross-reference the user list against HR termination records from the past 90 days. Any account still active after an employee left is an immediate finding.
- Req 8.6 privileged accounts: List all accounts with elevated privileges in the CDE. For each, verify least-privilege assignment and evidence of separate review.
The Semi-Annual Review Burden — and Why It Fails Without Tooling
The most common approach to Requirement 7.2.4 compliance is a spreadsheet exercise: pull a user list from each CDE system, send to the system owner, wait for sign-off, file the reply. Twice a year, every year. This process fails for the same reasons it fails in SOC 2 and ISO 27001 — no per-account attribution, no link between review decision and remediation action, no evidence that decisions were genuine rather than rubber-stamp approvals.
What makes PCI DSS uniquely demanding is the explicit mandatory frequency. Most teams accept the manual process because they only need to produce evidence annually for their QSA assessment — but the controls must operate continuously, and auditors sample across the full 12-month period. A missing review cycle is a finding, even if the other period is well-documented.
Finding: No evidence of periodic access reviews (Req. 7.2.4)
The organisation cannot produce documentation for each required review cycle during the assessment period. One or more review cycles is missing entirely, or the evidence produced does not demonstrate individual account-level review with attributed decisions.
Finding: Shared or generic accounts in the CDE (Req. 8.2)
A user account not mapped to a unique individual is an automatic finding. This includes service accounts shared between team members, and admin accounts without a specific owner.
Finding: Terminated employee access not removed (Req. 7.2.4)
Cross-referencing active CDE accounts against HR data reveals accounts that should have been revoked. Even brief windows of post-termination access are findings under PCI DSS.
How AllowNow Addresses Requirements 7 & 8
| Requirement | AllowNow evidence |
|---|---|
| Req. 7.2 | Role-based access with service-level access levels (viewer, read, write, admin) — minimum necessary access is defined, assigned, and tracked per user per system. |
| Req. 7.2.4 | 90-day review check ensures CDE access stays current between required six-monthly cycles. 'Review All' button records each account individually with reviewer identity and timestamp. Complete review records exportable on demand for QSA assessment. |
| Req. 7.2.5 | System and application account tracking through the service-role-user model. Access levels documented per account per system. |
| Req. 8.2 | Employee ID field enforces unique user identification. Every assignment is linked to a specific individual — no shared or generic account access is tracked without attribution. |
| PCI DSS PDF | Report filtered to high-risk and critical-risk services (CDE scope). Compliance findings show quarterly review compliance, admin access inventory, accounts missing expiry dates, and unique ID coverage. |
The AllowNow PCI DSS v4.0 report is scoped specifically to high and critical risk services — the systems most likely to be in your CDE. It includes an observations section mapped to Requirements 7 and 8, showing review recency, privileged account count with review evidence, and whether all users have unique employee IDs. It is designed to be the primary evidence artefact for Req. 7.2.4 testing.
Built for small organisations approaching their first PCI DSS assessment
AllowNow is designed for small merchants and service providers — typically 5 to 100 people — that process card payments and need to meet Req. 7 and 8 without a dedicated security compliance team. If your organisation is preparing for its first QSA assessment or SAQ validation and needs a systematic, documented access review process, AllowNow provides it quickly and without enterprise complexity.
With AllowNow, the access review that previously required a week of coordination and spreadsheet wrangling becomes a 15-minute process — and the resulting records are audit-grade evidence, not an email chain.