PCI DSS 5.1.1: All security policies and operational procedures that are identified in Requirement 5
PCI DSS v4.0.1 control 5.1.1: the requirement in full, the 1 testing procedure 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
All security policies and operational procedures that are identified in Requirement 5 are:
- Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
Summary
The policies and procedures behind Requirement 5 are written down, current, followed, and known to the people they apply to.
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.1 | Examine documentation and interview personnel to verify that security policies and operational procedures identified in Requirement 5 are managed in accordance with all elements specified in this requirement. |
Every requirement opens with this control and identical wording, so the question is what Requirement 5 does to it. Requirement 5 is the requirement most often delegated entirely to a product. Anti-malware is bought, an endpoint team deploys it, and the vendor console becomes the process, which means the documented procedures frequently do not exist because nobody felt the absence. The parts a product cannot perform are precisely the parts with nothing written down: the "not at risk" determination in 5.2.3 is a judgement rather than a setting, and the case-by-case authorisation to disable protection in 5.3.5 is an approval workflow with no tool behind it. Those two are where "documented" and "in use" are lost here, not the scanning configuration, which the console evidences on its own.
What to prepare
- The Requirement 5 documents as a set: deployment and coverage, the not-at-risk evaluation, scanning or behavioural analysis, removable media, phishing controls, and the disable-authorisation process.
- An owner and a review date on each.
- Evidence they are in use, particularly for the two activities the product does not perform.
- Who the affected parties are, which includes whoever approves an exception.
How to implement it
1. Write down the judgements, not the settings. The console already evidences configuration. What it cannot evidence is how you decided a system is not at risk, or who may authorise turning protection off.
2. Do not let the vendor documentation stand in for yours. A product manual describes the product; this control asks for your procedures.
3. Cover every platform in one set. Anti-malware usually spans workstations, servers and possibly a managed service under different owners, and the procedures tend to exist for whichever team wrote theirs first.
4. Check "in use" against the exception path. A documented approval process that has never been used while exclusions exist in the console is the divergence an assessor finds.
Where this commonly fails
- No documented procedures at all, because the product was treated as the process.
- The not-at-risk evaluation performed informally with nothing written, which also fails 5.2.3.
- Vendor documentation offered in place of the entity's own procedures.
- Procedures for endpoints with none for servers, or the reverse.
Related controls
Others in section 5.1:
| Control | What it requires |
|---|---|
| 5.1.2 | Roles and responsibilities for performing activities in Requirement 5 are documented, assigned… |
← 4.2.2 · All controls · 5.1.2 →
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.