What PCI DSS 4.0 Requires for Infrastructure Identity and Access Evidence

Most conversations about PCI DSS 4.0 start with the requirements, but I’d rather start with a habit.

As a GRC & Cybersecurity Consultant advising organizations preparing for PCI DSS 4.0 assessments, I’ve developed a habit of observing how findings move from identification to ownership, remediation, and documented closure. That’s often where accountability gaps and unresolved findings surface first.

The controls are usually understood, but they don’t secure an environment unless they are acted on. This is the practice I would like to apply to PCI DSS 4.0, since the change from one version to another was not as much about technology as people think.

What changed in PCI DSS 4.0

If you came up with PCI DSS v3.2.1, the logic is to treat PCI DSS 4.0 as a newer version of the same exam. However, this misses the larger shift. With 4.0, the bar for documentation has been raised, requiring more management transparency than 3.2.1.

Take secure coding and the discipline of following a documented development process. Under the older standard, the expectations around building software responsibly were left largely to individual judgment rather than mandated controls. Code review, threat modeling, and dependency scanning were optional. Security testing happened ad hoc, without fixed pipeline gates, and release sign-off relied on a manager’s informal approval instead of a documented checklist.

Under PCI DSS 4.0, development needed to move from an informal practice to a documented, controlled process as a direct call-out. Compared with PCI DSS v3.2.1, 4.0 adds more explicit requirements around documented roles and responsibilities, periodic access reviews, application and system account governance, and automated audit-log review.

The standard now expects you to prove that compliant management practices are operationalized with artifacts your infrastructure and development systems already generate: IAM and RBAC configurations, access-review records, CI/CD logs, and change tickets.

PCI DSS 4.0 infrastructure identity and access evidence: What happened, and who was responsible

As part of assessing the applicable PCI DSS requirements, I follow the evidence across the systems in scope. If required activity is not captured or the supporting evidence cannot be produced, that can become a finding. Where sampling is appropriate, I may test a representative sample rather than every system component or record.

For infrastructure identity and access, I look for evidence that connects access and activity to the person or account involved, the privileges in effect, and the review or action that followed. Depending on the requirement being tested, that may include:

• Identity and access records such as IAM or RBAC configurations, account provisioning records, and privilege changes showing what access was granted and why.
• Infrastructure activity records such as authentication, SSH, Kubernetes, server, session, and database audit logs showing who accessed an in-scope resource and what they did.
• Review and remediation records such as periodic access reviews, tickets, approvals, and sign-offs showing who reviewed the activity or access and what action followed.

Accountability gaps surface when infrastructure activity is logged, but there is no corresponding record showing who reviewed it or what action followed. For example, a user may elevate to an administrative role and access a production database, but there is no documentation showing why the access was needed, who approved it, or whether it was reviewed afterward. This occurs when:

• There is no formal process for triaging infrastructure security events or access anomalies.
• A formal process exists, but there is no owner for the handoff.
• Suspicious or unauthorized access is noticed, but not formally documented.

What strong PCI evidence looks like across access controls, reviews, and logging

Security practices such as least privilege, need-to-know, periodic access reviews, and automated log review are where the PCI evidence trail either holds up under assessment or exposes gaps. Here are defensible forms of evidence:

Automated audit-log review

For in-scope infrastructure, I verify that automated mechanisms are used to review the audit logs subject to PCI DSS 10.4.1.1. Those logs may capture failed authentication, privilege elevation, administrative actions, and individual access to cardholder data.

When an exception or anomaly is identified, I look for evidence that it was addressed. That might be alert history, an incident record, a ticket, or retained team communication showing the review and follow-up.

Least privilege and need-to-know

The most common gap I find is over-privileged RBAC: roles that grant more access than the job requires. A close second is access that persists after role changes.

For access, I look at assigned privileges, job function, and documented approvals to see whether permissions are scoped to what the person actually needs. PCI DSS Requirement 7.2.5 applies the same least-privilege principle to application and system accounts, limiting privileges to what is necessary for operation and to the systems, applications, or processes that require them.

Periodic access review

I look for documentation showing who performed the review, when it occurred, which accounts and privileges were examined, and what was revoked or changed.

Requirement 7.2.4 requires user-account reviews at least every six months, while 7.2.5.1 sets the periodic cadence for application and system accounts. If the review identifies inappropriate access, I look for the resulting revocation, privilege change, or other corrective action.

Other common PCI DSS 4.0 audit findings

These gaps appear frequently in assessments.

1. Findings get produced, but no action follows, increasing the risk of a breach

Follow-through is understandably difficult. Remediation can be disruptive, especially when it affects production systems or competes with planned work. I’ve assessed environments where critical coding issues were well understood, but refactoring kept slipping behind feature work and short-term fixes. If a PCI DSS finding identifies a control deficiency or vulnerability and remains unresolved, it could increase the likelihood of compromise or a breach.

2. Missing management acknowledgment

When an organization cannot show that leadership reviewed access and confirmed it remained appropriately scoped, accountability can become unclear. The technical review may have happened, but the evidence still needs to show who made the decision to retain, modify, or revoke access.

3. Application and system account privileges

A common question in assessments is whether anyone regularly reviews what service and system accounts can access. For non-human accounts, that can be harder to answer because they may sit outside normal user access-review workflows. As workloads, integrations, and dependencies change, those accounts can retain privileges across systems that are no longer required, making it harder to show that each permission is still necessary for the account’s function.

Infrastructure identity and access evidence that supports PCI DSS 4.0 requirements

PCI DSS 4.0 requires organizations to control and account for access to the cardholder data environment (CDE). Infrastructure identity and access evidence shows who and what can reach in-scope infrastructure, and what privileges they hold. It provides visibility into whether that access is granted, reviewed, and revoked as intended. For Requirements 7, 8, and 10, that evidence helps demonstrate least privilege, proper account management, and traceable access activity.

PCI DSS 4.0 audit readiness checklist for infrastructure teams

To prepare for a PCI DSS 4.0 assessment, test these areas in your own environment:

1. Trace one access-related exception or anomaly from detection through follow-up. Start with an event from in-scope cloud IAM, Kubernetes, a database, or a server. Confirm the evidence shows what was flagged, who reviewed it, what action followed, and the outcome.
2. Pull a recent periodic access review and compare it with live permissions. Confirm which accounts and privileges were reviewed and what access was revoked or changed. Then verify those changes took effect in IAM roles, Kubernetes RBAC, database grants, or other in-scope permissions.
3. Trace one known PCI-relevant access-control gap through remediation. Use something concrete, such as stale administrative access, excessive service-account privileges, or access retained after a role change. Confirm the record shows who was responsible for follow-up, what corrective action was required, and whether it was completed.

---

Accelerate PCI DSS compliance with Teleport

Teleport accelerates PCI DSS compliance by establishing a consistent identity and access record across the infrastructure that supports your CDE. Cryptographic identities, per-session MFA, and audit logs tied to human and non-human identities can support PCI DSS 4.0 requirements for access control (Req 7), identification and authentication (Req 8), and logging and monitoring (Req 10).

• Enforce least privilege across servers, databases, Kubernetes, and cloud infrastructure with scoped roles and permissions.
• Authenticate infrastructure access with cryptographic identity, short-lived credentials, and per-session MFA.
• Trace infrastructure activity back to the user, service account, workload, or agent that performed it.
• Produce audit evidence from access and session records that support reviews, investigations, and assessor requests.