PCI DSS 3.1.2: Roles and responsibilities for performing activities in Requirement 3 are documented, assigned
PCI DSS v4.0.1 control 3.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.1.
Requirement 3: Protect Stored Account Data › Section 3.1
Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 3 activity, and one of those roles carries a signature.
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 | |
|---|---|
| 3.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities performing activities in Requirement 3 are documented and assigned. |
| 3.1.2.b | Interview personnel with responsibility for performing activities in Requirement 3 to verify that roles and responsibilities are assigned as documented and are understood. |
Requirement 3 is the only requirement where a role has to formally accept its responsibilities in writing. 3.7.8 requires key custodians to acknowledge, in writing or electronically, that they understand and accept what being a custodian means. So this matrix and that register have to agree, and they are usually maintained by different people through different processes, which is where they diverge. Beyond that the activities split the familiar way and in an unusually wide gap: retention and disposal decisions are business judgements about how long the organisation needs data and why, while encryption and key management are technical. The business half is the one most often unassigned, because deciding a retention period feels like a policy statement rather than a job.
What to prepare
- A responsibility matrix by role for each Requirement 3 activity.
- The key custodian list, reconciled against the acknowledgements in 3.7.8.
- The named owner of retention periods and of disposal.
- Who decides where account data is permitted to exist.
How to implement it
1. Reconcile the matrix with the custodian register. Two lists of the same people maintained separately will disagree, and one of them is signed.
2. Assign retention to whoever can defend the business need. 3.2.1 asks for a written reason, and only the business side has one.
3. Name an owner for the data inventory. Knowing where account data lives underpins retention, disposal and discovery, and it is nobody's job by default.
4. Assign by role with a current mapping, since 3.1.2.b interviews the people named.
Where this commonly fails
- The matrix and the custodian register naming different people.
- Retention periods set by IT because nobody in the business was asked.
- The data inventory unowned, so it ages until a discovery forces the question.
- Cryptographic responsibilities assigned and disposal left to whoever decommissions the system.
Related controls
Others in section 3.1:
| Control | What it requires |
|---|---|
| 3.1.1 | All security policies and operational procedures that are identified in Requirement 3… |
← 3.1.1 · All controls · 3.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.