PCI DSS 4.0 privileged access checklist: Req. 7, 8 and 10

PCI DSS 4.0 privileged access requirements come down to three questions an assessor will test: is access to the cardholder data environment (CDE) limited to what each role needs (Requirement 7), is every administrator uniquely identified and authenticated with MFA (Requirement 8), and is every privileged action logged, protected and reviewed (Requirement 10)? This checklist maps each relevant requirement to a concrete control and the evidence to keep. It is written for security, identity and compliance teams preparing for a PCI DSS v4.0.1 assessment. Requirement numbers and wording below are checked against the PCI DSS v4.0.1 Requirements and Testing Procedures.

PCI DSS privileged access is administrative or elevated access to system components in, or connected to, the cardholder data environment, including human administrators, application and system accounts used interactively, and third-party vendor accounts.

Which PCI DSS version applies in 2026?

The PCI Security Standards Council published PCI DSS v4.0.1 on 11 June 2024 as a limited revision. The Council states that “there are no additional or deleted requirements in this revision”, and that PCI DSS v4.0 “will be retired on 31 December 2024.” Assessments today are against v4.0.1.

The same post confirms the revision did not change the effective date of the new requirements: 31 March 2025. Several requirements in this checklist carried the note “best practice until 31 March 2025, after which it will be required.” That date has passed, so 7.2.5, 7.2.5.1, 8.4.2, 8.6.1 to 8.6.3 and 10.4.1.1 are now fully in scope.

How do Requirements 7, 8 and 10 map to PCI DSS 4.0 privileged access controls?

The table lists the requirements an assessor is most likely to test against privileged access, with the control that addresses each and the evidence that shows it working. Requirement text is paraphrased closely from the v4.0.1 standard, which the Council lists on its PCI DSS page alongside its v4.x resources.

Req.	What v4.0.1 asks for	Privileged access control	Evidence to keep
7.2.1	An access control model granting access by business need, job function and least privilege	Role-based policies per target: who, which systems, what level, how long	Policy definitions; role-to-target map
7.2.2	Access for users, including privileged users, based on job function and least privilege	Narrow admin roles; read-only by default; elevation per task	Role assignments; grant scopes
7.2.3	Required privileges approved by authorised personnel	Approval workflow with named approvers; no self-approval	Request and approval records
7.2.4	All user and vendor accounts and privileges reviewed at least every six months, acknowledged by management	Scheduled access review of admin and vendor accounts	Signed-off review; remediation tickets
7.2.5 / 7.2.5.1	Application and system accounts on least privilege, reviewed at the frequency in your targeted risk analysis	Service account inventory with owner and scope	Inventory; review records
8.2.1	A unique ID for every user before access	SSO sign-in per person; no shared logins at the front door	IdP user list; session-to-user records
8.2.2	Shared or generic IDs only by exception: time-limited, justified, approved, identity confirmed, every action attributable	Vaulted shared credentials checked out per person, injected into recorded sessions	Checkout log; approvals; recordings
8.2.6	Inactive accounts removed or disabled within 90 days	Dormant privileged account sweep	Last-logon report; disablement records
8.4.1 / 8.4.2	MFA for all non-console administrative access into the CDE (8.4.1), and for all non-console access into the CDE (8.4.2)	MFA enforced at the access proxy for every protocol, not only the web portal	MFA configuration; sign-in logs
8.6.1	Interactive use of system or application accounts prevented except by exception, approved and attributable to an individual	Interactive use only through brokered, approved sessions	Approval and session records
8.6.2	Passwords for interactive application and system accounts not hard-coded in scripts, config files or source code	Secrets held in a vault and fetched or injected at run time	Code scan results; vault entries
8.6.3	Those passwords changed periodically and on suspected compromise	Scheduled rotation, plus rotation after check-in	Rotation history
10.2.1.2	Logs capture all actions by anyone with administrative access, including interactive use of application or system accounts	Session recording and command or query logging at the proxy	Recordings; command logs
10.2.1.5	Logs capture changes to identification and authentication credentials, including new accounts and elevation of privileges	Alerts on grants, role changes and new privileged accounts	Grant and policy-change events
10.3.2 to 10.3.4	Logs protected from modification, backed up centrally, and monitored so changes raise alerts	Tamper-evident audit trail; write-once storage; change detection	Integrity checks; storage configuration
10.5.1	Audit log history kept at least 12 months, the latest three months immediately available	Retention policy on recordings and audit data	Retention settings; retrieval test

Requirement 7 checklist: restrict privileged access by need to know

Requirement 7 asks whether each person’s access matches their job. “Administrator” is not a job function an assessor will accept on its own: requirement 7.2.2 expects access based on “least privileges necessary to perform job responsibilities.” The quickest way to get there for administrators is to remove standing rights and grant access per task, as described in our guide to zero standing privileges.

• Document the access control model for CDE systems: roles, targets, privilege levels and maximum grant lengths (7.2.1).
• Replace broad admin group membership with task-scoped, time-limited grants where the platform allows it (7.2.2).
• Require approval by a named, authorised person for every privileged grant, and block self-approval (7.2.3).
• Run the six-monthly review of all user and vendor accounts and get management sign-off (7.2.4).
• List every application and system account with an owner, purpose and the systems it may reach (7.2.5).
• Set the review frequency for those accounts in your targeted risk analysis and keep the results (7.2.5.1).
• Reconcile directory groups, local admins, sudo rules, database grants and cloud roles against the approved list.

Requirement 8 checklist: identify and authenticate every administrator

Requirement 8 is about accountability: every action in the CDE should trace to one person. Shared root, sa or oracle logins break that trace unless they are managed under requirement 8.2.2, which lists six conditions, ending with “every action taken is attributable to an individual user.” A vault that checks the shared credential out to a named person and injects it into a recorded session is the usual way to meet that condition.

• Give every person, including vendors, a unique ID before they reach any CDE component (8.2.1).
• Inventory shared, generic and default accounts; disable those not needed and vault the rest (8.2.2).
• Confirm the individual’s identity before each shared-account checkout and record who used it (8.2.2).
• Revoke access for leavers immediately (8.2.5) and disable accounts inactive for 90 days (8.2.6).
• Enforce MFA on every non-console path into the CDE, including SSH, RDP and database clients, not only the web console (8.4.1, 8.4.2).
• Prevent interactive use of service accounts except through an approved, attributed session (8.6.1).
• Scan scripts, configuration files and code for hard-coded passwords and move them into a vault (8.6.2).
• Rotate application and system account passwords on the schedule your risk analysis sets, and after any suspected compromise (8.6.3).

Requirement 10 checklist: log, protect and review privileged activity

Requirement 10.2.1.2 asks for logs of “all actions taken by any individual with administrative access, including any interactive use of application or system accounts.” A record of the grant alone is not enough; the assessor will want to see what was done during the session, tied to the person, with the details 10.2.2 lists: user, event type, date and time, success or failure, origin, and the affected component or resource.

• Log every privileged session, command and query on in-scope components (10.2.1, 10.2.1.2).
• Log account creation, privilege elevation and changes to administrator accounts (10.2.1.5).
• Check that each event carries the fields in 10.2.2.
• Limit read access to audit logs to people with a job-related need (10.3.1).
• Protect logs from modification, back them up to a central server or hard-to-modify media, and alert on any change (10.3.2 to 10.3.4).
• Review security events and logs from critical components at least daily, using automated mechanisms (10.4.1, 10.4.1.1).
• Synchronise clocks across PAM, operating systems, databases and the SIEM (10.6.1).
• Retain 12 months of history with three months immediately available, and test a retrieval (10.5.1).

How do SWOT PAM and SWOT DAM help produce evidence?

SWOT PAM and SWOT DAM help produce evidence for several of the requirements above. Whether a requirement is met depends on your configuration, scope and your QSA’s assessment; no product makes an environment compliant.

• Requirements 7.2.1 to 7.2.3: SWOT PAM access policies define who can reach which targets, for how long and with which approvals. Engineers request just-in-time access, approvers answer in Slack, Microsoft Teams or email, and the grant ends on its own.
• Requirements 8.2.1, 8.2.2 and 8.4.2: each person signs in through SSO (SAML 2.0 or OIDC) with TOTP multi-factor authentication. Shared credentials sit in the Central Vault and the proxy injects them, so the session stays tied to a named user. Database sessions can use a temporary account revoked at disconnect.
• Requirement 8.6.3: the vault rotates credentials on a schedule, such as every 30 days, or as soon as a credential is checked back in.
• Requirements 10.2.1.2 and 10.3: SSH, RDP and database sessions are recorded at the proxy. Every audit event is sealed in a SHA-256 hash chain, audit tables are insert-only, and recordings can be stored in S3 or MinIO with Object Lock.
• Requirement 10.2.1.5 on databases: SWOT DAM reads native database audit trails with read-only collectors and flags privilege escalation such as GRANT DBA, SUPERUSER or a security policy change.

For cloud administration of AWS, Azure or GCP accounts in scope, SWOT Cloud PAM brokers short-lived credentials behind approval and records sessions on a hash chain. The PCI DSS solution page shows the requirement-by-requirement evidence map.

How should you test the checklist before the assessment?

Walk a sample of identities through the full path: a full-time administrator, a vendor, a service account used interactively, a cloud role and the break-glass account. For each, show the approval, the MFA event, the session record and the removal of access. Then reconcile three views that should agree: the approved access list, the actual permissions on targets, and the logs of use.

Test the failure cases too: an expired grant, a leaver, a failed MFA attempt and a log retrieval from nine months ago. Record the date, tester, result and any corrective action, because that record is evidence in its own right.

Next steps

PCI DSS 4.0 privileged access comes down to need-to-know grants under Requirement 7, unique MFA-protected identities under Requirement 8, and complete, protected logs under Requirement 10, now including the controls that became mandatory on 31 March 2025. Use the table and checklists above to find gaps before your QSA does. See the PCI DSS evidence map or book a demo of SWOT PAM on your own CDE systems.