PCI DSS 5.4.1: Have both process and automated mechanisms working against phishing, not just training.

PCI DSS v4.0.1 control 5.4.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 5.4.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.4

Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.

Summary

Have both process and automated mechanisms working against phishing, not just training.

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.4.1 Observe implemented processes and examine mechanisms to verify controls are in place to detect and protect personnel against phishing attacks.

Future-dated in v4.0 and assessed since 31 March 2025, and easy to misread as more awareness training. The wording is processes and automated mechanisms, and the automated half is the point: 12.6.3.1 already requires training about phishing, and the applicability notes to both say neither one meets the other. The standard names no product. Its guidance suggests a combination: anti-spoofing controls (SPF, DKIM and DMARC) that help stop phishers spoofing your own domain, technologies such as link scrubbers and server-side anti-malware that block phishing before it reaches people, and training people to recognise and report what gets through. The requirement is to detect and protect, so a mechanism that detects and does not block, or blocks and reports nothing, meets half of it. The applicability notes set the focus on personnel with access to system components in scope for PCI DSS; the guidance recommends, but does not require, applying the controls across the whole organisation.

What to prepare

  • The automated mechanisms in place, named, with their configuration.
  • Where you use them, the SPF, DKIM and DMARC records for the domains you send from, and the DMARC aggregate reports you receive.
  • The process side: how a reported phish is triaged and what happens next.
  • Evidence the mechanisms operate, such as blocked-message reporting.

How to implement it

1. Deploy DMARC in the order RFC 9989 sets out. RFC 9989, which replaced RFC 7489 in May 2026, has the domain owner align SPF and DKIM with the From domain (preferably both), set up a mailbox for aggregate reports and parse them by machine, then publish p=none. Every legitimate mail stream the reports show failing has to be fixed before moving to enforcement, which can take months. Email authentication with SPF, DKIM and DMARC goes through it.

2. Choose the enforcement level deliberately. At p=none DMARC asks receivers to take no action, so it reports spoofing without stopping it; p=quarantine is the usual end point. RFC 9989 says domains whose users post to mailing lists should not publish p=reject, and a domain that still wants it should run p=none for at least a month and p=quarantine for as long again first, and sign everything with DKIM rather than rely on SPF. A domain that sends no mail can publish v=spf1 -all with p=reject. The pct tag is gone; t=y replaces it for testing a stricter policy.

3. Check what arrives, not only what you send. DMARC on your own domains stops your domain being forged, to your staff and to everyone else. A look-alike domain passes DMARC for itself, so phishing from one has to be caught by inbound filtering and link inspection.

4. Give people somewhere to report to. The process half of this control is a reporting route that reaches someone, connected to the incident plan at 12.10.1. A button that files into an unread mailbox is not a process.

5. Cover the channels that are not email. Phishing arrives by SMS, chat and phone; the requirement says phishing attacks, not phishing emails.

6. Feed results back into training. Simulation and real-report data show which phishing threats are getting through, and 12.6.2 requires the awareness programme to be reviewed at least once every 12 months and updated as needed to address new threats.

Where this commonly fails

  • Training presented as the whole control, when automated mechanisms are named separately.
  • DMARC left at p=none with nobody reading the aggregate reports.
  • p=reject published on a domain whose staff post to mailing lists, or with SPF as the only authentication, both of which RFC 9989 warns against.
  • Only one side covered: inbound filtering with no SPF, DKIM or DMARC on your own domains, or DMARC on your own domains with nothing inspecting what arrives from others.
  • A reporting button with no triage behind it.

Terms

Glossary entries that name this control, each with its own example, limits and sources:

← 5.3.5 · All controls · 6.1.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.