PCI DSS 2.1.2: Roles and responsibilities for performing activities in Requirement 2 are documented, assigned
PCI DSS v4.0.1 control 2.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 2.1.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.1
Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 2 activity, including whoever now builds the systems.
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 | |
|---|---|
| 2.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 2 are documented and assigned. |
| 2.1.2.b | Interview personnel with responsibility for performing activities in Requirement 2 to verify that roles and responsibilities are assigned as documented and are understood. |
Documentation then interview, as in every requirement. The specific difficulty in Requirement 2 is that the population performing its activities has moved. Writing and maintaining configuration standards is usually assigned. Applying them is performed by whoever provisions a system, which in most environments now includes application teams standing up their own infrastructure, and detecting drift is often assigned to nobody at all. 7.1.2's problem is distributed approvers; this one is distributed builders. A matrix naming a platform or infrastructure team is accurate about who owns the standard and silent about the dozen teams who deviate from it, and 2.1.2.b interviews people with responsibility for performing the activities.
What to prepare
- A responsibility matrix by role for each Requirement 2 activity: authoring, applying, verifying, updating.
- Who provisions systems in practice, which may be more teams than expected.
- The named owner for drift detection.
- Evidence the assignment reached the teams applying the standards.
How to implement it
1. Separate authoring from applying. One team writes the standard and many apply it, and only naming the author leaves the larger population unassigned.
2. Name an owner for drift. Systems that met the standard at build and no longer do are the common finding, and nobody looks unless someone is asked to.
3. Assign cloud configuration explicitly. The team that creates a storage bucket configures its security parameters, whether or not they think of themselves as doing so.
4. Keep a current role-to-person mapping. 2.1.2.b interviews the named people.
Where this commonly fails
- The standards owner named and the appliers not.
- Drift detection unassigned, so a system that has diverged is found only at assessment.
- Application teams provisioning infrastructure with no Requirement 2 responsibility recorded.
- A matrix that describes the organisation as it was before self-service infrastructure.
Related controls
Others in section 2.1:
| Control | What it requires |
|---|---|
| 2.1.1 | All security policies and operational procedures that are identified in Requirement 2… |
← 2.1.1 · All controls · 2.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.