PCI DSS 6.1.2: Roles and responsibilities for performing activities in Requirement 6 are documented, assigned
PCI DSS v4.0.1 control 6.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.1.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.1
Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 6 activity, and one of those roles is a separation the standard requires.
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 | |
|---|---|
| 6.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 6 are documented and assigned. |
| 6.1.2.b | Interview personnel responsible for performing activities in Requirement 6 to verify that roles and responsibilities are assigned as documented and are understood. |
This control is unusual because the requirement it governs mandates a role split of its own. 6.5.4 requires roles and functions to be separated between production and pre-production so that only reviewed and approved changes are deployed, which means 6.1.2's matrix is not only documentation: it has to show that separation exists. A matrix in which the same role develops, approves and deploys is documented, assigned, and evidence that 6.5.4 is not met. Beyond that, the activities span development and operations, and the unowned ones are at the boundary: who ranks a vulnerability under 6.3.1, who decides a change is significant under 6.5.2, and who authorises a release.
What to prepare
- A responsibility matrix by role for each Requirement 6 activity.
- Evidence the matrix reflects the separation 6.5.4 requires.
- The named owner of vulnerability ranking and of the significant-change decision.
- Who authorises a release, distinct from who wrote the change.
How to implement it
1. Check the matrix against 6.5.4 before anything else. If one role covers development, approval and deployment, the fix is organisational rather than documentary.
2. Name who decides "significant". It is the trigger for 6.5.2, 11.3.1.3 and 11.3.2.1, so an unowned decision leaves three controls untriggered.
3. Assign vulnerability ranking explicitly. It drives remediation timescales in 6.3.3 and the treatment of everything else in 11.3.1.1.
4. Assign by role with a current mapping, since 6.1.2.b interviews the people named.
Where this commonly fails
- One role developing, approving and deploying, which fails 6.5.4 through this matrix.
- Nobody owning the significant-change decision, so scans and confirmations never trigger.
- Vulnerability ranking unassigned, leaving remediation timescales undefined in practice.
- A matrix covering development while change control is treated as somebody else's requirement.
Related controls
Others in section 6.1:
| Control | What it requires |
|---|---|
| 6.1.1 | All security policies and operational procedures that are identified in Requirement 6… |
← 6.1.1 · All controls · 6.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.