PCI DSS Requirement 5.4.1: Protecting Personnel Against Phishing

Requirement 5.4.1 says "Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks." It was future-dated in v4.0 and has been assessed since 31 March 2025. This article covers what it asks for, whom it protects, how it is tested, where email authentication fits, and how it sits alongside the phishing training in 12.6.3.1 and the standard's treatment of phishing-resistant authentication.

What it asks for

The requirement has two parts: processes, and automated mechanisms. It names no product or protocol. Its customised approach objective states the outcome: mechanisms are in place to protect against and mitigate risk posed by phishing attacks. The testing procedure has the assessor observe the processes and examine the mechanisms to confirm both are in place.

The guidance explains why technical controls come first. They reduce how often a person has to judge whether a message is genuine, and they limit the damage when someone does respond to one.

Whom it protects

The applicability notes put the focus on personnel with access to system components in scope for PCI DSS. The guidance recommends, but does not require, applying the same controls across the whole organisation. In practice most mail services are configured once for everyone, so the narrower scope matters mainly for deciding what an assessor will examine.

What the guidance suggests

The guidance encourages a combination of approaches and gives three examples:

• Anti-spoofing controls. DMARC, SPF and DKIM help stop phishers spoofing the entity's own domain and impersonating its personnel. They check whether mail that claims to come from a domain was authorised by that domain. They do nothing about a look-alike domain registered by the attacker. Email authentication with SPF, DKIM and DMARC covers setting them up.
• Blocking before delivery. Technologies such as link scrubbers and server-side anti-malware stop phishing emails and malware before they reach people.
• Reporting. Training personnel to recognise and report phishing lets similar messages be found and removed before others open them.

The guidance also notes that anti-malware solutions often include mechanisms that detect and prevent phishing. A mail service's own filtering can therefore be part of the answer. The evidence is its configuration and the process around it.

Training is a separate requirement

12.6.3.1 requires security awareness training to include phishing and related attacks, and social engineering. Under 12.6.3, that training happens on hire and at least once every 12 months. 12.6.3.1 was future-dated alongside 5.4.1.

The applicability notes to both requirements say the same thing from each side: technical controls under 5.4.1 do not meet the training requirement, and training does not meet 5.4.1. An entity needs both. The guidance to 12.6.3.1 suggests the training cover how to identify phishing, how to react, and where and how to report it. It also suggests periodic testing of how often personnel report phishing.

Phishing-resistant authentication

Phishing often aims at a password. The standard's glossary defines phishing-resistant authentication as authentication designed so that its secrets cannot be disclosed to, or used by, anyone other than the legitimate system. Passwords, one-time passwords, SMS codes and magic links are not phishing resistant. FIDO2 is given as an example that is.

It matters for access control as well. The applicability notes to 8.4.2, which requires multi-factor authentication for non-console access into the cardholder data environment, exclude user accounts that are only authenticated with phishing-resistant factors. A stolen password is worth less to an attacker when the account never accepts one on its own.

Evidence an assessor can examine

• The configuration of inbound mail filtering, link protection and attachment scanning.
• SPF, DKIM and DMARC records for the domains the entity sends from, and the reports it receives.
• The process for personnel to report a suspected phishing message, and what happens after a report.
• The documented policies and procedures for Requirement 5, which 5.1.1 requires to be current and known.

A successful phishing attack against someone with access to the cardholder data environment is a security incident. It belongs in the incident response plan under 12.10.1.

Further reading

• How to recognise and avoid phishing attacks, for the warning signs to teach under 12.6.3.1.
• QR code phishing and PCI DSS, for phishing that arrives as an image instead of a link.
• Front Office Payment Security, the site's training for staff who take card payments, which covers phishing and social engineering.