5.4 Anti-phishing mechanisms: requirements and evidence

What requirement 5.4 anti-phishing mechanisms asks for

If you have just found requirement 5.4.1 in your SAQ or ROC, the short answer is that it requires processes and automated mechanisms that detect and protect personnel against phishing attacks. It was a best practice under PCI DSS v4.0 until 31 March 2025 and has been a required control since that date, so an assessor will now expect evidence that it operates. The requirement exists because phishing is one of the most direct ways to harvest the credentials of staff who can reach in-scope systems. A single captured password or MFA prompt approved under pressure can open the cardholder data environment without touching any technical control, which is why the standard treats the people layer as part of the technical defense.

The difficulty is that 5.4.1 is not one tool. An assessor will expect to see the whole chain working: mail filtering that quarantines or flags suspicious messages, a way for staff to report suspicious messages quickly, a documented response when a report is made, and evidence that the mechanism actually detects phishing rather than just being switched on. Each link usually sits with a different owner, such as email administration, the security operations team and the help desk, and the evidence lives in different systems. Confirm early with your QSA which mail platform, reporting path and log sources they will accept, and map the owner and the evidence for each link before the assessment window opens. Note that the SAQ D guidance says the email servers providing the mechanism do not themselves come into PCI DSS scope, but the personnel with access to in-scope components do.

Which people, systems and third parties 5.4.1 covers

Requirement 5.4.1 is scoped around people, not around the mail platform itself. The cards below separate the personnel the requirement protects from the tools, services and accounts that surround them, so each scoping call can be documented and confirmed. Confirm every decision with your QSA or acquirer before you finalize scope.

Personnel with in-scope access

This is the core of 5.4.1. The requirement focuses on people who hold access to in-scope system components, and the processes and mechanisms must detect and protect those people against phishing. Start from your access records for the cardholder data environment and list every role with a login, including finance, support and operations staff who can reach in-scope systems. Check whether any of those roles also receive mail or chat that never reaches the CDE, because those people still need coverage if they can reach in-scope systems.

The automated mechanism itself

The processes and automated mechanisms that detect phishing are the controls you must operate and evidence. Document which product or service performs detection, where it runs, who administers it and how its alerts reach a responder. Confirm with your QSA how the mechanism is described in your assessment, because it is the item assessors will sample when they test whether the control operates.

Email and collaboration platforms

Mail, chat and file-sharing platforms are where phishing usually arrives, so they sit at the center of the people-focused control. The SAQ D note states that systems such as email servers are not brought into PCI DSS scope by this requirement. Your scoping work still needs to record which mailboxes and collaboration tenants belong to people with in-scope access, and to confirm that any filtering applied to those users is in place and monitored.

Third-party mail and security services

If a managed email gateway, cloud filtering service or outsourced security operations center detects phishing for your staff, that provider becomes part of how you meet 5.4.1. Request its responsibility matrix, the contract language on alert handling and the evidence it can produce for an assessor. Confirm with your QSA whether the provider's attestation covers the function you rely on, and whether its own PCI DSS status matters for your scope.

Contractors with accounts

Contractors and temporary staff who hold accounts on in-scope systems are personnel for this requirement, even when they are not employees. Confirm that their mailboxes and collaboration accounts are included in phishing detection and that offboarding removes access promptly. Check whether contractors use personal devices or outside mail services, since those paths may fall outside the mechanism you describe.

Shared and service accounts

Shared mailboxes, group addresses and service accounts can receive phishing without a named person behind them. Identify which of these accounts can access in-scope systems or route approvals and payments, then decide how the mechanism covers them. Ask your QSA whether a shared inbox that feeds a person with access counts as in scope, and document the rule you apply so the decision can be repeated at the next assessment.

Why anti-phishing controls and phishing training need separate evidence

Requirement 5.4.1 and the phishing awareness training in Requirement 12.6.3.1 are separate requirements, and meeting one does not meet the other. The first asks for processes and automated mechanisms that detect and protect personnel against phishing. The second asks that staff receive security awareness training that covers phishing. An assessor tests each on its own terms, so a compliance lead who files them together will usually find a gap at assessment time. Training records show who completed a course and when. They do not show that a mail filter, link scanner or phishing-reporting mechanism was running, configured or reviewed during the assessment period. Equally, a filter report showing blocked messages does not prove that any employee understood how to recognize a phishing attempt.

The practical step is to split the evidence before the assessment starts. Assign 5.4.1 to a named owner, usually the person responsible for email and endpoint protection, and give that owner a procedure that describes the automated mechanisms, their configuration baseline, how personnel report suspicious messages and how those reports are handled. Give 12.6.3.1 to whoever runs the awareness program, with its own curriculum, completion records and refresher schedule. Store each set of evidence in its own folder so that neither is cited as proof of the other. Confirm the exact scope of 5.4.1 with your assessor, since the SAQ D note says the mail servers providing the mechanism are not brought into PCI DSS scope by that requirement, while the personnel with access to in-scope components are.

How an assessor tests the anti-phishing mechanism

This table compares what an assessor typically checks for Requirement 5.4, the evidence usually requested for each check, and the gaps that come up most often. Read each row as a question the assessor will ask, then confirm your own evidence answers it. The assessor makes the final determination, and this table does not predict the outcome of any assessment.

Test approach	Evidence requested	Common findings
Confirm the mechanism exists and is described in documented procedures	Written procedure naming the anti-phishing mechanism, its owner and how it is run and reviewed	Procedure describes a tool that is not actually deployed, or names no owner
Confirm the mechanism is automated and covers personnel with access to in-scope components	Configuration export or screenshots showing the automated control is active, plus the scope setting for user groups	Mechanism is manual or periodic only, so it does not meet the automated expectation
Compare the mechanism's scope with the personnel list	Current list of personnel with access to in-scope systems, matched against the users or mailboxes the mechanism protects	Mechanism is configured for some users but not for administrators, contractors or shared mailboxes with access to in-scope components
Sample configuration and alert records to confirm the mechanism runs	Sampled alerts, logs or reports dated across the assessment period, with the configuration version in effect at each date	Documented as active but no operating records for much of the period, so the assessor cannot confirm continuous operation
Check how suspected phishing is detected	Detection rules or filter settings, and examples of detections with their timestamps and disposition	Detection depends only on user reports, with no automated flagging of suspicious messages
Check how suspected phishing is reported and handled	Reporting channel instructions, sample tickets or incident records showing triage, containment and closure	Reports arrive through an informal channel with no record of how they were handled
Separate this requirement from the training requirement	Distinct evidence for Requirement 5.4 (mechanism records) and Requirement 12.6.3.1 (training records)	Training completion reports are offered as proof of the automated mechanism, which they do not show
Confirm the platform hosting the mechanism is handled correctly	Scope notes on whether the email or messaging system is in scope, and how the mechanism's own components are protected	Assessment scope for the email platform is unclear, so the team cannot explain why its servers are or are not included

How to implement anti-phishing mechanisms step by step

This sequence turns Requirement 5.4.1 into a working chain: the organization knows who is covered, detects suspicious messages, routes alerts to someone accountable, proves the chain works, and keeps the configuration current.

Identify in-scope personnel from access lists
Start by listing the people who have access to in-scope system components, using identity provider groups, directory exports and access reviews. Requirement 5.4.1 focuses on personnel with access to in-scope components, so this population defines where the phishing protections must apply. Confirm with the system owners that the list covers contractors and administrators as well as staff. The output is a dated scope roster with the source of each group, reviewed and approved by the security owner.
Choose and configure the automated mechanisms
Select the automated mechanism or mechanisms that will detect and protect these users, such as email filtering, link rewriting, attachment sandboxing or a dedicated phishing detection product. The choice of mail filtering or phishing product is the organization's decision and should be confirmed against its own email platform and environment. Configure the mechanism for the roster, and note that the email servers providing it do not, by the SAQ D note, come into PCI DSS scope by that fact alone. The output is a configuration record listing the product, version, policies and the users or groups it covers.
Define how users report suspected phishing
Set up a simple reporting path that users can follow in seconds, such as a report button in the mail client or a monitored mailbox. Write a short procedure stating what users should do with a suspicious message and what they must not do, such as clicking links or forwarding credentials. Make sure the reporting channel feeds into the response process rather than ending in an unmonitored inbox. The output is a published reporting procedure and a confirmed intake channel.
Route detections to an owner with a response procedure
Connect detections and user reports to a named owner, for example a security operations queue or on-call analyst, through the alerting path the organization already uses. Document the response steps for a confirmed phishing message, including blocking the sender or URL, removing delivered copies, checking whether credentials were entered and escalating to the incident response process. Open-source tools such as Shuffle workflows can automate parts of this routing, such as scanning an attachment or posting to chat, but the procedure must still name a human owner. The output is a routing diagram, an owner assignment and a written response procedure.
Test the chain with a controlled exercise
Run a controlled phishing exercise against a defined sample of in-scope users, agreed in advance with management and the people who run the mail system. Record whether the mechanism flagged or blocked the test message, whether users reported it, and whether the owner received the alert and followed the procedure. Treat any gap as a finding with an assigned fix. The output is an exercise plan, a results record and a list of corrective actions. Exercise results are not a substitute for the phishing awareness training required by Requirement 12.6.3.1, which is a separate requirement.
Record configuration and first-run evidence
Capture evidence that the mechanism was configured and operated as described: configuration exports or screenshots with dates, the scope roster as it stood at activation, the first detection or test log entries, and the alert records that reached the owner. Store these where assessors can retrieve them without reconstruction. Ask the assessor, or the team assessing you, which evidence formats they accept. The output is an evidence folder indexed to Requirement 5.4.1 with dated, attributable records.
Set a review cycle for scope and configuration
Schedule recurring reviews of the scope roster, the mechanism configuration, the reporting procedure and the exercise results, so that joiners, leavers and product changes are picked up. Set the review frequency in your own risk-based process and record it in the policy that governs anti-malware and anti-phishing controls. Confirm the cadence with your assessor, since the standard does not supply a fixed interval in the facts available here. The output is a review calendar, signed review records and updates to the configuration record when changes are approved.

What evidence passes an anti-phishing review

A 5.4 assessment tests two things: that a documented process and automated mechanism exist for detecting and protecting personnel against phishing, and that they run as described. The artifacts below connect the design to day-to-day operation, so an assessor can trace a person in scope to a mechanism, an alert and a handled case.

Written detection and reporting procedure

A dated procedure that describes how phishing is detected, how staff are protected from it, and how suspected messages are reported and triaged. It should name the automated mechanisms in use, such as email filtering, link rewriting or workflow-based scanning of reported messages, and state who owns each step. Keep the version history and approval record current, and review it at least quarterly against the mechanisms actually deployed. Confirm with your assessor whether they expect a standalone document or a section within a broader policy.

Personnel scope list tied to access

A list of the people covered by the phishing controls, reconciled against the access records for in-scope system components. The point is to show that every person with access to the cardholder data environment is protected, not only the people who happen to sit in a monitored mailbox group. Export the list from the identity provider with a date stamp, and reconcile it each quarter against joiners, movers and leavers. Ask the assessor how they want exceptions, such as contractors, documented.

Mechanism configuration exports

Exports or dated screenshots of the automated mechanism's configuration, showing the rules, scanning policies, detection content and enforcement settings in force. For a self-hosted stack this may be a configuration file, a rule set version or a workflow definition. Note that the SAQ D guidance does not bring systems such as email servers into PCI DSS scope just because they provide the mechanism, but the people they protect remain in scope. Capture the export at each audit period and whenever settings change.

Sample alerts and handled cases

A set of real alerts or case tickets showing that detections were received, triaged and closed with a documented outcome. Assessors look for evidence that the mechanism acts on what it finds, so include the alert source, time, disposition and any user notification. Retain tickets in the ticketing system rather than in personal inboxes, and sample across the review period rather than presenting only the most recent items. Confirm with your assessor how many samples they expect and how personal data in the samples should be redacted.

Reporting channel test records

Records showing that the channel staff use to report suspected phishing works and reaches someone who acts on it. Test it on a schedule, for example by sending a controlled test message through the reporting button or mailbox and recording the time to acknowledgment and the handling outcome. Keep the test plan, the results and any fixes. If the channel is automated, export the workflow run history as the record. Ask the assessor whether they accept internally generated test messages or expect an independent test.

Change records for mechanism updates

Change tickets, approvals and release notes for every update to the phishing mechanism, including rule changes, vendor version upgrades and new detection content. Each change should show what changed, who approved it, when it was tested and whether it was rolled back. Assessors use this trail to confirm the mechanism stays current, so link tickets to the configuration exports they produced. Review open changes monthly, and confirm with your assessor which change-control evidence format they accept.

What meeting 5.4.1 costs in money and effort

This table lists the cost components behind Requirement 5.4.1, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a written scope and to ask providers and assessors what their quotes include. No prices or durations are given because none are supplied for this requirement.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Anti-phishing or mail security licensing	Recurring, usually per user or per mailbox	Mailbox count, feature tier, and whether sandboxing or link rewriting is included	Confirm which features 5.4.1 needs, then size licenses to in-scope personnel only
Open-source mechanism licensing	None for the software itself	Hosting, storage and the number of log sources feeding detections	Start with phishing-related Sigma rules and a single mail or identity log source, then expand
Engineering to scope and configure the mechanism	One-time, then periodic tuning	Number of mail platforms, identity providers and in-scope user groups	Write a scope that names in-scope personnel and data flows before configuration begins
Integration with logging and ticketing	One-time build, recurring maintenance	Number of connected systems, custom parsers, and ticketing workflow complexity	Use existing SIEM and ticketing connections; automate report intake with a standard workflow
Staff time to triage user reports and alerts	Recurring	Report volume, false positive rate, and whether triage rules are documented	Tune detections against known benign senders and document triage steps in a runbook
Evidence upkeep	Recurring	Frequency of assessor sampling, retention periods, and how many alerts must be traced to a response	Set retention and export of alert records and ticket closures on a fixed schedule
External review or testing by a provider	Usually one-time per assessment, sometimes recurring	Scope of phishing simulation or configuration review and how many mail domains are covered	Ask for a written deliverable list and limit testing to agreed mailboxes and domains
Assessor time	Recurring, once per assessment cycle	Quality and completeness of evidence, and how quickly the assessor can sample records	Prepare a single evidence folder with configuration exports, sample alerts and tickets before fieldwork

Open-source tools that support anti-phishing evidence

Requirement 5.4.1 asks for processes and automated mechanisms that detect and protect personnel against phishing. The three open-source tools below can collect, match and record the signals that show those mechanisms running, but they do not replace a dedicated mail filter or a user reporting path. Confirm those controls in your own environment before you treat any tool as the anti-phishing mechanism.

Shuffle workflows for response

Shuffle (AGPL-3.0-only) runs event-driven workflows started by a webhook, a schedule or a manual run. App nodes perform actions such as scanning a suspicious attachment with VirusTotal or posting an alert to a chat channel, and the same workflow can open a ticket or query a SIEM. For 5.4.1, the useful evidence is a saved workflow with run history showing that a reported phishing message was triaged. Check who can edit workflows, where credentials for connected apps are stored, and whether run logs are retained long enough for your assessor to sample them.

OpenSearch Security Analytics detectors

OpenSearch Security Analytics (Apache-2.0) runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can go to Slack or email. A correlation engine links findings across log types in a correlation graph, which helps show that a mail gateway event, a credential use and a host alert belong to one incident. Confirm which mail and identity log sources you ingest, since a detector can only match what reaches it.

Wazuh ruleset and alert trail

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK techniques, and forwarded to the Wazuh indexer for review in the dashboard. Its value for 5.4 is the retained alert trail of detections on endpoints and mail-related logs. Confirm the rules you rely on are tuned to your mail platform and that alert files are protected from modification.

Who does what: your team, a partner and the assessor

Your organization owns Requirement 5.4 in full. The obligation to detect and protect personnel against phishing sits with you, as does the decision about which personnel fall within the control's scope. Your assessor will ask who is accountable, and the answer should be a named role, not a vendor. Your team also makes the judgment calls that no partner should make for you: what counts as a phishing incident, who is contacted, and when a user is coached, restricted or escalated.

Control ownership: Name an accountable owner for the anti-phishing mechanisms and document the role in your anti-malware and anti-phishing roles.
Personnel scope: Decide which accounts and people with access to in-scope system components are covered, and keep that list current as staff join, move or leave.
Response procedure: Write and approve the steps for triaging a suspected phishing alert, including who investigates and how users report suspicious messages.
Evidence ownership: Retain alert records, response tickets and review sign-offs in a location your team controls and can produce on request.

Before engaging a partner, confirm that your owner can explain the mechanism, the scope and the response path without referring to a contractor.

Questions buyers ask about anti-phishing under PCI DSS

Does requirement 5.4.1 still apply if we already run phishing awareness training?

Yes. Requirement 5.4.1 and the phishing training requirement in 12.6.3.1 are separate, and meeting one does not meet the other. Requirement 5.4.1 asks for processes and automated mechanisms that detect and protect personnel against phishing, so training addresses how people recognize attacks while 5.4.1 addresses technical detection and protection. Since 31 March 2025, 5.4.1 is a required control rather than a best practice. Assessors will look for training records under 12.6.3.1 and working mechanisms with evidence under 5.4.1. Ask your QSA how they plan to test each one. The cost table on this page lists these as separate lines so you can see what each adds.

Is the email server in PCI DSS scope if it runs phishing filters?

Not automatically. The SAQ D note to requirement 5.4.1 states that the systems providing the automated mechanism, such as email servers, are not brought into PCI DSS scope by that requirement, and that the requirement focuses on personnel with access to in-scope system components. Scope still depends on your environment. If the mail system stores, processes or transmits cardholder data, or connects to the cardholder data environment, it is in scope for other reasons. Document the data flows and mailbox boundaries, then confirm the decision with your QSA. The PCI SSC SAQ D for service providers contains the note in full.

How much effort does phishing protection take under PCI DSS, and what drives it?

Effort depends mainly on how many people and mail channels fall under 5.4.1 and how much automation you already run. The main drivers are the number of mailboxes and messaging channels used by personnel with access to in-scope components, whether you use a managed email security service or self-host, how many detection rules you tune, and how alerts reach a person who acts on them. One-time work covers design, integration and documenting the process. Recurring work covers tuning, alert review and evidence collection. The cost table on this page separates these components. Ask for a quote that shows each one, and confirm any time estimate with your assessor and implementer, since no duration is supplied here.

Can we meet requirement 5.4 with open-source tools ourselves?

Possibly, if your team can operate the tools and produce evidence an assessor can test. Wazuh decodes collected logs and compares events against a ruleset of over 3,000 built-in rules and decoders plus custom rules. OpenSearch Security Analytics runs detectors on ingested logs using Sigma rules and sends alerts to channels such as Slack or email. Shuffle can automate response steps, such as scanning a file with VirusTotal. Confirm whether these tools cover the mail-side detection you need, since log rules alone may not stop a message from reaching a mailbox. Self-hosting also moves uptime, updates and evidence retention to your team.

What does the phishing control need from our internal team?

It needs named owners for the mechanism, the alert queue and the link to training. Your team must identify which personnel and mail systems are in scope, provide log sources, approve rule changes and act on alerts. Security engineers usually handle configuration and integration. Email administrators handle the gateway and the user reporting path. Compliance leads map evidence to 5.4.1 and keep the process documented. Staff who receive suspicious messages need a clear way to report them. Ask the implementer to list these roles, expected review hours and handover items in the written scope. Documented roles for anti-malware and anti-phishing controls relate to Requirement 5.1.

How long does it take to produce evidence for requirement 5.4.1?

No duration is supplied for this, so confirm timing with your assessor before you plan. Evidence timing depends on how long the mechanism has run consistently, how often the assessor samples records, and whether the process was documented and followed throughout the assessment period. Ask which evidence types they expect, such as alert logs, tuning records and records of reviewed phishing reports, and over what period. Start collecting evidence as soon as the mechanism is live rather than waiting for assessment. Your assessor decides what is sufficient. DeployOpen prepares systems and records but does not issue assessment conclusions.

Should we bring in a partner for 5.4.1, and what is their independence limit?

A partner can design, deploy and document the mechanism and help prepare evidence, but it cannot assess its own work. Your organization owns its controls. The implementation partner prepares systems and evidence. Only a Qualified Security Assessor issues the Report on Compliance, and the Attestation of Compliance accompanies it. Keeping consulting and assessment independent means the firm that builds the control should not be the one judging it. Ask your QSA whether a proposed engagement creates a conflict, and use a fixed written scope so deliverables and boundaries are clear. Certificates are not recognized as validation, as PCI SSC FAQ 1220 explains.

What changes with the future-dated requirements timeline for 5.4.1?

For this requirement, the transition is complete: 5.4.1 became required on 31 March 2025. Of the 64 new requirements in v4.0, 51 were future-dated and took effect on that date, while before then they were best practices that could be marked not applicable. PCI DSS v4.0.1 is the only active version, since v4.0 was retired on 31 December 2024. The PCI SSC ran a request for comments from 3 June to 20 July 2026 to begin the next iteration, and no release date for a new version had been announced as of October 2026. Confirm with your assessor which version applies to your validation date.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the phishing detection and protection mechanisms for 5.4 Anti-phishing mechanisms run in your environment under your control. We prepare the systems and evidence an assessor will review, while your organization owns the control and an independent QSA or assessor issues the conclusion.

How we scope

Agree in writing which personnel and in-scope system components the anti-phishing mechanisms must protect.
Confirm which email and collaboration platforms are the automated mechanism, and document that they sit outside the scope the SAQ D note describes.
Record the separation from the phishing awareness training under 12.6.3.1 so the two requirements are evidenced independently.

How we build

Deploy self-hosted open-source detection, such as Wazuh rules or OpenSearch Security Analytics detectors, against email and endpoint log sources you name.
Configure automated response workflows, for example in Shuffle, that scan suspicious attachments and route alerts to your ticketing system.
Test detections with controlled phishing samples to confirm alerts fire and reach the responsible team.

How we hand over

Deliver configuration records, rule and detector exports, and workflow definitions stored in your own repositories.
Document the procedure for reviewing and acting on anti-phishing alerts, including the roles that own each step.
Provide test records and alert samples that show the mechanism operating, ready for the assessor to review.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover tuning of detection rules as your email platform and threat patterns change.
Ask any implementation partner to confirm in writing who maintains the evidence between assessment cycles.

5.4 Anti-phishing mechanisms