PCI DSS 5.1.2: Roles and responsibilities for performing activities in Requirement 5 are documented, assigned
PCI DSS v4.0.1 control 5.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 5.1.
Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.1
Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood.
Summary
Someone is named for each Requirement 5 activity, including the judgement calls the product cannot make.
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 | |
|---|---|
| 5.1.2.a | Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 5 are documented and assigned. |
| 5.1.2.b | Interview personnel with responsibility for performing activities in Requirement 5 to verify that roles and responsibilities are assigned as documented and are understood. |
The split between 5.1.2.a and 5.1.2.b is documentation then interview, as everywhere. What is specific to Requirement 5 is that its activities divide into two very different kinds, and one of them routinely has no owner. Operating the tooling is obvious and usually assigned. The judgements are not: deciding a system component is not at risk under 5.2.3, re-examining that decision on the frequency set by 5.2.3.1, and authorising a user to disable protection under 5.3.5, which the standard says must be authorised by management. That last one names a role by implication, and it is frequently held by nobody, so exclusions accumulate without anyone having approved them.
What to prepare
- A responsibility matrix by role for each Requirement 5 activity.
- The named owner of the not-at-risk determination and its periodic re-evaluation.
- The management role authorised to approve disabling protection.
- Whoever operates the tooling on each platform, including any managed service.
How to implement it
1. Assign the judgements explicitly. They are the activities with no console to prompt them, so an unassigned judgement simply does not happen.
2. Name the management approver for 5.3.5. The control requires management authorisation case by case, which cannot be evidenced if no role holds it.
3. Cover the managed service if you use one. Someone internal still owns coverage, exceptions and the evaluation, and "the provider handles anti-malware" is not an answer to who is responsible.
4. Assign by role with a current role-to-person mapping. Interviews under 5.1.2.b go badly when the named person left.
Where this commonly fails
- Tooling operation assigned and the judgements unowned.
- No named management approver, so exclusions exist that nobody authorised.
- Endpoint and server anti-malware owned by different teams with the boundary unstated.
- A managed service treated as owning the responsibility rather than performing the activity.
Related controls
Others in section 5.1:
| Control | What it requires |
|---|---|
| 5.1.1 | All security policies and operational procedures that are identified in Requirement 5… |
← 5.1.1 · All controls · 5.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.