PCI DSS 8.2.5: Access for terminated users is immediately revoked
PCI DSS v4.0.1 control 8.2.5: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 8.2.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.2
Access for terminated users is immediately revoked.
Summary
When someone leaves, their access goes immediately, including the physical tokens and cards.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 8.2.5.a | Examine information sources for terminated users and review current user access lists—for both local and remote access—to verify that terminated user IDs have been deactivated or removed from the access lists. |
| 8.2.5.b | Interview responsible personnel to verify that all physical authentication factors—such as, smart cards, tokens, etc.—have been returned or deactivated for terminated users. |
The word is immediately, which is a different standard from the six-monthly review in 7.2.4 and from the 90 days in 8.2.6. Neither of those is the mechanism for this control. Two parts of the procedure are routinely missed. 8.2.5.a says access lists for both local and remote access, so accounts held locally on individual systems, on network devices, and in applications with their own user store all count, and those are where terminated access survives longest. And 8.2.5.b is a separate interview about physical authentication factors: smart cards, tokens, hardware keys returned or deactivated. An entity can disable the directory account on the day and still fail this on an unreturned token.
What to prepare
- The leaver process, showing what is revoked and by whom.
- A list of terminations since the last assessment, from HR rather than from IT.
- Current access lists for directory, remote access, applications and local accounts, to check the terminated names against.
- The register of physical factors issued and returned.
How to implement it
1. Drive it from HR, not from a manager remembering. The procedure compares HR's terminated-user list against live access, so the two need to be connected by a process rather than by goodwill.
2. Enumerate the systems with their own user stores. Directory-integrated systems are handled by disabling one account. Everything with a local user list needs its own step, and that list should exist before you need it.
3. Track physical factors as issued items. You can only confirm return against a record of issue, and 8.2.5.b is an interview that goes badly without one.
4. Cover the contractors. They terminate without an HR event, so their end date has to come from somewhere else, usually the contract or the sponsor.
Where this commonly fails
- The directory account disabled and application-local accounts left active.
- Hardware tokens never returned and never deactivated, failing 8.2.5.b on its own.
- Revocation batched weekly, which is not immediately.
- Contractors and temporary staff outside the HR-driven process entirely.
Related controls
Others in section 8.2:
| Control | What it requires |
|---|---|
| 8.2.1 | All users are assigned a unique ID before access to system components or cardholder data… |
| 8.2.2 | Group, shared, or generic IDs, or other shared authentication credentials are only used… |
| 8.2.3 | Service providers with remote access to customer premises use unique authentication factors… |
| 8.2.4 | Addition, deletion, and modification of user IDs, authentication factors… |
| 8.2.6 | Inactive user accounts are removed or disabled within 90 days of inactivity |
| 8.2.7 | Accounts used by third parties to access, support… |
| 8.2.8 | If a user session has been idle for more than 15 minutes… |
← 8.2.4 · All controls · 8.2.6 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.