PCI DSS 8.1.2: Roles and responsibilities for performing activities in Requirement 8 are documented, assigned
PCI DSS v4.0.1 control 8.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 8.1.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.1
Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 8 activity, they know it, and the assessor will ask them.
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.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 8 are documented and assigned. |
| 8.1.2.b | Interview personnel with responsibility for performing activities in Requirement 8 to verify that roles and responsibilities are assigned as documented and are understood. |
The split between 8.1.2.a and 8.1.2.b is the point, as it is for every control of this shape: the first examines the documentation, the second interviews the people named in it. What is specific to Requirement 8 is how far its activities scatter. Identity provisioning usually sits with a service desk, multi-factor authentication with security, service-account credentials with engineering, and the user stores inside individual applications with their owners. Two activities cross out of IT entirely: the termination trigger behind 8.2.5 starts in HR, and the identity verification in 8.3.3 is performed by whoever answers the phone. A matrix that assigns Requirement 8 to "Identity and Access Management" is documented and assigned, and it will not survive 8.1.2.b when the assessor asks the HR business partner who owns the leaver feed.
What to prepare
- A responsibility matrix by role for each Requirement 8 activity, not by requirement number.
- Evidence each assignment reached its holder: an acceptance, a job description, a team charter.
- The people to interview, including the ones outside IT.
- Named cover for each responsibility.
How to implement it
1. Decompose to activities, not to the requirement. Provisioning, approval, reset, verification, MFA enrolment, service-account rotation, inactivity sweeps and termination revocation are separate jobs that frequently land with separate teams.
2. Assign the cross-boundary ones explicitly. The HR-to-IT handoff for leavers and the desk-side identity verification are the two that belong to people who do not think of themselves as having a PCI DSS responsibility, which is exactly why 8.1.2.b finds them.
3. Assign by role and keep a current role-to-person mapping. A rota survives a resignation; a name does not.
4. Tell the holder. A responsibility recorded in a compliance folder and never communicated is documented, assigned, and not understood, which fails one of the three words in the control.
Where this commonly fails
- Everything assigned to the identity team, including the parts they cannot perform.
- The HR side of termination unassigned, so the immediate revocation in 8.2.5 depends on a manager remembering.
- Application owners with their own user stores never named, so account management there belongs to nobody.
- A matrix naming a team that a reorganisation has since dissolved.
Related controls
Others in section 8.1:
| Control | What it requires |
|---|---|
| 8.1.1 | All security policies and operational procedures that are identified in Requirement 8… |
← 8.1.1 · All controls · 8.2.1 →
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.