PCI DSS 7.1.2: Roles and responsibilities for performing activities in Requirement 7 are documented, assigned
PCI DSS v4.0.1 control 7.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 7.1.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know › Section 7.1
Roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 7 activity, and most of them do not work in IT.
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 | |
|---|---|
| 7.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 7 are documented and assigned. |
| 7.1.2.b | Interview personnel with responsibility for performing activities in Requirement 7 to verify that roles and responsibilities are assigned as and are understood. |
The population split is what makes this specific. Requirement 7 divides cleanly into decisions and enforcement, and they sit in different places. Approving privileges, reviewing access twice a year, and acknowledging that application account access remains appropriate are business judgements held by managers and system owners. Configuring the access control system to enforce them under 7.3.2 and 7.3.3 is technical work. A responsibility matrix that names only the identity or platform team is accurate about enforcement and silent about every approval the requirement depends on, and 7.1.2.b interviews the people named. It is worth noticing that 7.2.5.1 explicitly requires management acknowledgement, which names a role by implication and is the one most often unassigned.
What to prepare
- A responsibility matrix separating decision activities from enforcement activities.
- The named approvers per system or business function.
- Who owns the six-monthly review and who owns the application-account review.
- Evidence the assignment reached the business-side holders.
How to implement it
1. Name approvers per system, not per organisation. "The business owner approves" cannot be interviewed; a named role per system can.
2. Assign the application and system account review separately. 7.2.5.1 covers a different population from the user access review, and it is the one that goes unowned.
3. Record the management role for acknowledgement. The control requires it, so it needs a holder.
4. Keep the mapping current through reorganisations, which is when approver roles vanish and access approvals quietly stop happening.
Where this commonly fails
- Only the identity team named, leaving every approval activity unassigned.
- Application and system account review unowned, so it never happens.
- Approvers listed by name rather than by role, so a departure removes the assignment.
- A matrix that survives 7.1.2.a and collapses at the first interview with a business manager.
Related controls
Others in section 7.1:
| Control | What it requires |
|---|---|
| 7.1.1 | All security policies and operational procedures that are identified in Requirement 7… |
← 7.1.1 · All controls · 7.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.