What evidence do auditors commonly ask for on 5.1.1 Requirement 5 policies and procedures maintained and communicated?

Approved anti-malware and anti-phishing policy with owner, version and review date; Operational procedures for deploying, updating, monitoring and exception-handling of anti-malware tools; Distribution records or acknowledgements from endpoint and security operations staff; Change history showing updates after a tooling change such as moving to an EDR platform.

What is the most common gap auditors find on 5.1.1?

Policy still describes a retired anti-virus product

PCI DSS v4.0.1 · Req 5: Anti-Malware

`5.1.1` Requirement 5 policies and procedures maintained and communicated

The organisation must hold security policies and operational procedures covering every activity named in Requirement 5 (protection against malware and phishing), and each of them must be: written down; reviewed and refreshed so they stay current; actually followed in practice; and communicated to everyone they affect. Documents should be revised soon after a relevant change in processes, technologies or business objectives, not only on a schedule. Applicability: applies to every entity in scope, with no special notes. Customized approach objective: people involved in Requirement 5 work know what is expected and follow it, so supporting activities are repeatable, consistent and in line with management intent.

Source: PCI DSS v4.0.1, 5.1.1. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open PCI DSS v4.0.1 in the compliance library.

Version 4.0.1 is the active version; 4.0 has been retired. Appendix A1 applies only to multi-tenant service providers, A2 only to card-present POS POI terminals that still use SSL or early TLS, and A3 only when a payment brand or acquirer requires it. Which requirements apply to you follows your validation type.

artefacts

held by a system

at each review

moderate

to go live

Endpoint management (MDM / EDR)

where the evidence lives

teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

Change history showing updates after a tooling change such as moving to an EDR platform · Endpoint management (MDM / EDR)

periodic reviewEvidence produced at each review

Distribution records or acknowledgements from endpoint and security operations staff · Endpoint management (MDM / EDR)

governing documentDocuments that govern the control

Approved anti-malware and anti-phishing policy with owner, version and review date · Policy repository / GRC workspace
Operational procedures for deploying, updating, monitoring and exception-handling of anti-malware tools · Policy repository / GRC workspace

First move

Start with the 1 of 4 artefacts that already live in a system (Endpoint management (MDM / EDR)); keep the periodic reviews but log each one as a dated record with a named reviewer.

Common gaps auditors find

Policy still describes a retired anti-virus product
No written procedure for handling requests to disable anti-malware temporarily
Help desk staff unaware of the procedures they are expected to follow

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

4.2.2 PAN secured when sent by end-user messaging · 5.1.2 Requirement 5 roles and responsibilities assigned