PCI DSS 4.0 raised the evidence bar on access control requirements in ways that catch mid-market companies handling cardholder data off guard, particularly around Requirement 7 (need-to-know access restriction) and Requirement 8 (identification and authentication), including the expanded MFA scope that now covers all access into the cardholder data environment, not just remote or administrative access. Manual evidence gathering that satisfied earlier PCI versions frequently falls short of what 4.0 assessors expect.
What Changed in Practice for Access Control Evidence
Two shifts matter most for the evidence automation conversation:
- MFA scope expansion — PCI DSS 4.0 requires MFA for all access into the cardholder data environment (CDE), not just remote access as under 3.2.1. This means evidence needs to demonstrate MFA enforcement for internal network access to CDE systems too, which is a meaningfully broader evidence surface than prior versions required.
- Targeted risk analysis requirements — several controls that had fixed frequencies in earlier versions now allow risk-based frequencies, but only if the organization has documented a targeted risk analysis justifying the chosen frequency. This shifts part of the evidence burden from "we did the control" to "we did the control at a frequency we can justify with analysis," which is a different evidence artifact entirely.
The Evidence Pipeline for Requirement 7 (Need-to-Know Access)
# CDE access review pipeline — requirement 7.2.4 mapped evidence
class CdeAccessReviewEvidence:
def collect_review_cycle(self, cde_systems, review_period):
evidence = []
for system in cde_systems:
access_list = system.get_current_access()
job_function_map = self.hr_source.get_job_functions(
[u.id for u in access_list]
)
for user in access_list:
justified = self._is_need_to_know_justified(
user, job_function_map.get(user.id)
)
evidence.append({
"system": system.name,
"user": user.id,
"access_level": user.access_level,
"justified": justified,
"review_period": review_period,
})
return evidence
The critical piece here is cross-referencing access against actual job function data, since "need-to-know" is a job-function-relative test, not a blanket list of who has access — evidence needs to show the linkage was actually checked, not just that a list was pulled.
The Evidence Pipeline for Requirement 8 (MFA Coverage)
For the expanded MFA scope, the evidence pipeline needs to demonstrate MFA enforcement across every access path into the CDE — VPN, internal network segments hosting CDE systems, administrative consoles, and any jump/bastion hosts used to reach CDE infrastructure. We build this as a continuous configuration check against your IdP and network access control systems (verifying MFA policy is actually enforced, not just configured as available) rather than a point-in-time manual verification that can drift out of compliance between assessments.
Documenting Targeted Risk Analysis as Evidence
For controls where PCI DSS 4.0 allows a risk-based frequency, the evidence artifact isn't just "we performed the control" — it's the risk analysis itself, documenting why the chosen frequency is appropriate given the organization's specific risk factors. This is a different kind of evidence than most technical controls produce, closer to a structured decision document than a system log, and it needs to be maintained and version-controlled alongside the technical evidence rather than treated as a one-time exercise.
Segmentation Evidence and Its Relationship to Access Control
PCI DSS 4.0 also tightens segmentation testing requirements, which interacts directly with access control evidence — if network segmentation isolating the CDE isn't verified as effective, the scope of what needs Requirement 7/8-level access control evidence expands to cover systems that were assumed to be out of scope. We build segmentation verification (through automated network scanning and configuration review) as a prerequisite check that determines the actual boundary of what the access control evidence pipeline needs to cover.
This access-control evidence work sits alongside our security automation capability and the related pattern in HIPAA §164.312 access control evidence automation.
Ask us what your GRC platform isn't covering: 907-841-8407 or contact@rutagon.com.
Ask us what your GRC platform isn't covering →
Frequently Asked Questions
Does PCI DSS 4.0 require MFA for all internal employees, or just those accessing the CDE?
It requires MFA specifically for access into the cardholder data environment — internal network access to CDE systems now falls under this requirement, expanded from the remote-access-only scope in PCI DSS 3.2.1.
What is a targeted risk analysis and when is it required?
It's a documented risk assessment justifying a chosen control frequency or approach where PCI DSS 4.0 allows flexibility instead of a fixed requirement — it becomes part of your compliance evidence, not just an internal planning document.
Can our existing SOC 2 access review evidence be reused for PCI DSS?
Partially — the underlying access data often overlaps, but PCI DSS's need-to-know test is specific to the cardholder data environment and job function justification, so the evidence needs a CDE-specific lens rather than a direct reuse of general access review evidence.
How does segmentation testing affect what needs access control evidence?
If segmentation isolating the CDE isn't verified as effective, systems assumed to be out of scope can fall back into scope, expanding what needs Requirement 7/8-level evidence — segmentation verification should run before finalizing your access control evidence boundary.
Is this evidence automation a replacement for a Qualified Security Assessor (QSA)?
No — a QSA (for Level 1 merchants) or internal assessor makes the compliance determination; the automation pipeline produces the structured evidence they review, not the assessment itself.