PCI DSS 10.1.2: Roles and responsibilities for performing activities in Requirement 10 are documented
PCI DSS v4.0.1 control 10.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 10.1.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data › Section 10.1
Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 10 activity, including the one that has to happen every day.
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 | |
|---|---|
| 10.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 10 are documented and assigned. |
| 10.1.2.b | Interview personnel with responsibility for performing activities in Requirement 10 to verify that roles and responsibilities are assigned as defined and are understood. |
Requirement 10 divides into three kinds of work that rarely sit together: building the logging, reading it, and responding when it fails. The distinctive one is reading. 10.4.1 is a daily obligation, one of very few in the standard, which means the role needs cover in a way an annual task does not: weekends, holidays and departures all break it, and the gap is visible in the review records afterwards. The failure-response activities in 10.7.2 and 10.7.3 are the other commonly unassigned ones, because a control that has stopped working belongs to whoever owns that control rather than to the logging team, and nobody writes that down. 10.1.2.b interviews the people named.
What to prepare
- A responsibility matrix separating build, review and failure response.
- The daily review rota, including cover.
- The owner of each critical security control system, for failure response.
- The managed provider's responsibilities where any of this is outsourced.
How to implement it
1. Give the daily review a rota, not a person. Daily obligations fail on the first absence, and the record shows it.
2. Assign failure response per control system. When file integrity monitoring stops, the response belongs to whoever runs it, and 10.7.3 needs that named in advance.
3. Separate who builds from who reads. The platform team configures logging; security operations reads it. Naming only one leaves the other unassigned.
4. Write down the split with a provider. "The SIEM vendor reviews the logs" still leaves you owning scope, escalation and retention.
Where this commonly fails
- The daily review assigned to one person with no cover.
- Failure response unassigned, so a stopped control is noticed and nobody owns it.
- A managed provider assumed to hold responsibilities their contract does not mention.
- Build assigned and review not, or the reverse.
Related controls
Others in section 10.1:
| Control | What it requires |
|---|---|
| 10.1.1 | All security policies and operational procedures that are identified in Requirement 10… |
← 10.1.1 · All controls · 10.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.