PCI-DSS 4.0 and Privileged Access: Mapping the Requirements to Controls
DataDike Security Research
PAM Research & Compliance
PCI-DSS 4.0 is the most operationally specific revision of the standard in over a decade, and the requirements around privileged access management are the area where the gap between the old standard and the new is widest. This post walks the clauses that explicitly or implicitly demand PAM controls, and shows what a QSA expects to see when they sit down at a workstation.
Reference: PCI-DSS v4.0 became mandatory in March 2025. All clause numbers below are from the official 4.0 specification.
The headline requirements that touch PAM
| Clause | What it requires (paraphrased) | PAM control |
|---|---|---|
| 7.2.5 | Access rights to system components must be assigned based on least privilege and explicitly approved. | JIT elevation with approval workflow |
| 7.2.5.1 | Application and system accounts must be reviewed at least every six months. | Vault inventory + scheduled access review |
| 7.2.6 | All access to system components must be authorized and approved by authorized personnel. | Approval chains, immutable approval log |
| 8.2.1 | Strong cryptography must protect authentication factors during transmission and storage. | Encrypted vault + TLS to all targets |
| 8.2.2 | Group, shared, generic accounts must not be used unless necessary, and when used must be tied to an individual. | Session attribution + per-session check-out |
| 8.3.1 | Multi-factor authentication for all access into the CDE. | Step-up MFA at the PAM gateway |
| 8.3.6 | Passwords used for service accounts must be changed periodically or when suspected of compromise. | Automated credential rotation |
| 8.6.1 | Application and system accounts must not be used by individuals. | Sessions proxied through PAM with named-user attribution |
| 10.2.1 | Audit logs must capture all individual user accesses to cardholder data. | Session recording + immutable log forwarding |
| 10.2.2 | All actions taken by users with administrative privileges must be logged. | Full command-and-keystroke recording |
| 10.5.2 | Audit log files must be protected against modification. | Hash-chained, append-only audit log |
What auditors actually look for
A QSA will not read your PAM marketing brochure. They will ask you to demonstrate four specific things in front of them at the workstation. If you can produce these four artifacts on demand, you are in good shape; if you cannot, the audit will stall regardless of what the documentation says.
1. The full list of privileged accounts, with named human owners
Service accounts with no human owner are the single most common finding. Every privileged credential needs a person whose performance review references it. PAM platforms make this list trivial — it is a query against the vault inventory.
2. A six-month access review for at least one tier of accounts
Clause 7.2.5.1 demands the review; auditors want evidence it happened. The evidence is the export of the review with sign-offs. Treat the review as a recurring calendar artifact, not a project.
3. A randomly selected session, replayed end-to-end
They will pick a date and a target and ask you to play back the session. Auditors specifically want to see that command history, file transfers, and clipboard operations are captured, not just metadata. Half-implemented session recording — keystrokes but no screen capture, or screen but no commands — fails this test.
4. Proof of credential rotation for service accounts
Show the rotation history for one Windows service account, one SSH key, and one database user. Auditors look for a continuous chain of rotations on a defined schedule, not a single rotation that happened the week before the audit.
Where DataDike maps to the clauses
DataDike was designed around the assumption that the QSA will eventually open the platform and run their own queries, so every control listed in the table above ships native rather than as an add-on:
- Vault with FIPS 140-2 validated encryption at rest, TLS 1.2+ to every target (clauses 8.2.1, 8.2.2)
- Built-in approval workflows with configurable peer-approval thresholds (clauses 7.2.5, 7.2.6)
- Automated credential rotation for Windows local/domain accounts, SSH keys, database users, certificates (clauses 8.3.6, 8.6.1)
- Full session recording with command capture, keystroke logging, video replay, and file-transfer logging (clauses 10.2.1, 10.2.2)
- Hash-chained audit log with optional SIEM forwarding via CEF/Syslog, including the WORM-style retention auditors want (clause 10.5.2)
- Step-up MFA at the gateway in addition to whatever your IDP enforces at the front door (clause 8.3.1)
Pragmatic suggestion
Before the QSA arrives, run a tabletop with your internal security operations team where they play QSA for two hours. The friction surfaced in that two hours is worth every minute.
