Open source endpoint protection for PCI DSS requirement 5

What PCI DSS requirement 5 asks of open-source endpoint tooling

Open-source tooling such as Wazuh can cover much of PCI DSS requirement 5, but not every sub-requirement by itself. If you are a merchant, processor or service provider with systems in your cardholder data environment, the question is which parts of requirement 5 your own endpoint stack can evidence and which parts still need a dedicated anti-malware product or a documented decision. Requirement 5.2 requires anti-malware on all system components except those evaluated as not at risk, and requires that anti-malware to detect and remove, block or contain all known malware types. Requirement 5.2.3 requires periodic evaluation of the components you classify as not at risk, and requirement 5.2.3.1 requires that evaluation frequency to be set in a targeted risk analysis under requirement 12.3.1. Requirement 5.3 covers keeping the anti-malware updated, scanning on a schedule with real-time or continuous behavioral analysis, scanning removable media, retaining audit logs, and stopping users from disabling or altering the protection.

The standard in force is PCI DSS v4.0.1, the only active version after v4.0 was retired on 31 December 2024. The PCI Security Standards Council (PCI SSC) maintains the standard but does not enforce it or set penalties. The individual payment brands decide which entities must validate and run any enforcement, so confirm your obligations with your acquirer or the relevant brand before scoping. Validation is documented either in a Report on Compliance completed by a Qualified Security Assessor or in a Self-Assessment Questionnaire, and each is closed with an Attestation of Compliance. Your evidence for requirement 5 will therefore be read by an assessor or reviewed against the questionnaire, so the first task is to confirm which template applies to your environment.

Before you select tools, build an inventory of every system component in scope and a documented list of any components classified as not at risk, with the reasoning and the review frequency. Confirm with your assessor how they expect that list to be tested, since the expected testing for requirement 5.2.3 compares the documented list against the components that have no anti-malware deployed. Wazuh's agent inventory and file integrity features can help show coverage, but you must verify whether its malware detection and YARA or ClamAV integrations meet the detection and removal expectations for your platforms. Where they do not, plan for a dedicated product and record that decision.

How each requirement 5 sub-requirement maps to the function

This table takes each part of PCI DSS requirement 5 and sets out what the anti-malware function must do, what evidence an assessor will look for, and how Wazuh, YARA, ClamAV or a complementary product can be configured to meet it. Read it row by row against your own in-scope system inventory, and treat open-source tools as candidates to test rather than settled compliance answers.

Requirement	What the function must do	How to configure Wazuh, YARA, ClamAV or a complementary product
5.2.1 Anti-malware coverage	Deploy anti-malware on every in-scope system component, except components formally assessed as not at risk. Confirm the deployment on each host.	Install Wazuh agents on all in-scope Linux, Windows and macOS hosts, and deploy ClamAV on Linux servers where on-access or scheduled scanning is needed. Export agent inventory and ClamAV status as evidence. Confirm whether Wazuh alone meets the detection expectation for each platform, since its malware detection is largely indicator and rule driven.
5.2.2 Detect, remove, block or contain known malware	Detect all known malware types on covered systems and act on them by removing, blocking or containing the threat.	Use ClamAV signatures with automatic database updates for file scanning, and YARA rules run through Wazuh integration or scheduled scans for known families. Configure Wazuh active response to isolate or block where supported. Confirm that signature and rule coverage matches the malware types in your risk profile, and that you can show detections and actions in logs.
5.2.3 Periodic evaluation of systems not at risk	Maintain a documented list of components assessed as not at risk for malware, and re-evaluate them periodically.	Build the not-at-risk list from a Wazuh agent inventory or asset export, so each component with no anti-malware is traceable to a written justification. Schedule reviews and keep the dated results. An assessor will compare this list with the components that have no anti-malware deployed, so the two must reconcile.
5.2.3.1 Review frequency set by targeted risk analysis	Define the review frequency for not-at-risk systems in a targeted risk analysis under requirement 12.3.1.	Record the review interval and its risk rationale in your risk analysis document, not in the tool. Use Wazuh inventory reports or scheduled queries to produce the evidence at that interval. Confirm with your QSA how the risk analysis must be formatted and approved.
5.3 Anti-malware maintenance and control	Keep anti-malware current and running, with scanning, logging and tamper protection in place on every covered system.	Set Wazuh agent and ClamAV signature update schedules and monitor their status centrally. Configure scheduled ClamAV scans and Wazuh syscheck or rootcheck jobs at the frequency your targeted risk analysis sets. Restrict agent configuration changes to administrators through Wazuh server access control, and alert on agent stop or tampering events.
5.3.2.1 Scan frequency set by targeted risk analysis	Define the scan frequency for periodic malware scans in a targeted risk analysis, and perform scans at that frequency.	Schedule ClamAV full scans and YARA sweeps through cron or systemd timers at the interval in your risk analysis. Keep scan reports with timestamps and host identifiers. Confirm whether your analysis supports continuous behavioral monitoring from Wazuh in place of periodic scans for specific systems.
5.3.3 Removable media scanning	Scan removable electronic media automatically, or analyze behavior continuously, when media is inserted, connected or mounted.	On Linux, use ClamAV on-access scanning or a udev-triggered scan for mounted media. On Windows, use a complementary product that performs on-insert scanning, because confirm Wazuh coverage for USB insertion events before relying on it. Log each insertion and scan result so the record can be produced at assessment.
5.3.4 Audit logs for anti-malware	Enable anti-malware audit logs and retain them in line with requirement 10.5.1.	Forward ClamAV scan logs and Wazuh agent alerts to the Wazuh indexer or central log store. Set retention to match requirement 10.5.1 in your logging policy. Confirm that log integrity and access controls on the store meet the same standard, and test that logs can be retrieved for a sample period.

How Wazuh malware detection, YARA and ClamAV fit together

Wazuh gives PCI DSS requirement 5 one evidence trail, but ClamAV and YARA are inputs to that trail, not separate products. Wazuh has four components: the Wazuh indexer, which stores and searches alerts; the Wazuh server, which decodes and analyzes agent data with rules; the Wazuh dashboard, which hosts the views you will show an assessor; and the Wazuh agents installed on endpoints. Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX. For devices that cannot take an agent, such as firewalls or certain appliances, Wazuh collects syslog and probes APIs on a schedule. Each component that cannot take an agent needs a documented reason in your evaluation of systems not at risk, so the agent inventory and the agentless list should be kept together.

File integrity monitoring, rule-based malware detection, ClamAV scanning and YARA rules all write alerts to the same indexer, tagged by agent and time. File integrity monitoring flags changes to binaries and configuration. Rules map suspicious events to alert levels. ClamAV checks files against signatures, and YARA matches files against pattern rules you write or import. Your evidence for requirements 5.3.4 and 10.5.1 depends on those alerts being retained, so confirm how each input is enabled and logged in the Wazuh release you deploy.

Before you rely on this design, confirm three things in the release you choose. The current line is 4.14, with 4.14.9 as the latest patch published on October 14, 2026. First, signature freshness: how ClamAV databases and any YARA rule sets are updated on air-gapped or restricted hosts. Second, scan scheduling: whether periodic scans and real-time or behavioral checks for removable media can be set per host group and logged. Third, tuning: how rules and exclusions are reviewed and who approves them, since an unreviewed exclusion becomes a gap an assessor will find. Test these in a staging environment and record the results before the assessment period starts.

Which open-source platforms fit requirement 5 and why

Requirement 5 needs anti-malware on in-scope systems, evidence that it detects and removes known malware, and documented reasoning for any system treated as not at risk. No single open-source tool covers all of that, so the platforms below each supply a different part of the evidence. Confirm each licence and version against your own deployment before you rely on it in an assessment.

Wazuh for agent-based detection

Wazuh agents on Linux, Windows and macOS send events to the Wazuh server, which applies rules and stores alerts in the Wazuh indexer. The dashboard includes a prebuilt PCI DSS view, which helps you show alert history for in-scope hosts. Wazuh is distributed under GPL-2.0, so confirm that its license terms suit your deployment. Check that malware alerts reach a monitored queue with a named owner, because an alert nobody reviews does not support requirement 5.3.4 or its audit log expectations.

ClamAV and YARA as scanning engines

ClamAV is a signature-based scanner, and YARA matches files and memory against rules that you write or import. Together they can cover the scanning side of requirement 5.2.2, which asks for detection and removal of all known malware types. The evidence gap is signature and rule coverage, so document which signature sets and rule packs are in use, how often they update, and what action the scanner takes on a hit. Confirm the licence and supported operating systems for each engine before you select it.

Security Onion or Suricata for network evidence

Host agents do not see every malicious download or command-and-control connection, so network sensors add a second evidence source. Suricata is a network intrusion detection engine under GPL-2.0, and Security Onion packages it with Zeek, osquery and the Elastic stack under the Elastic License 2.0. Confirm sensor placement covers the cardholder data environment and its connections, and have counsel review the Elastic License 2.0 terms before you adopt the bundle.

osquery and Falco as supplementary telemetry

osquery answers questions about installed software, running processes and file hashes on demand, which helps you check the inventory behind a not-at-risk decision under requirement 5.2.3. Falco watches system calls on hosts and Kubernetes nodes, which can show malware-like behavior where a signature scanner is weak. Neither replaces a scanner. Confirm the license for each tool, the operating systems it supports in your estate, and who maintains its rule set.

Dedicated anti-malware for remaining gaps

Some systems need protection that open-source scanners do not provide, such as vendor-supported signatures for specific operating systems or tamper protection that stops users from disabling the agent. Requirement 5.3.5 expects anti-malware that users cannot disable or alter, so test that control directly on each platform. Record each gap with a targeted risk analysis and a compensating or customized control decision, and state where a commercial product is still the right answer.

Running the periodic review of systems not at risk

Requirement 5.2.3 only works if the organization can name every component it has decided does not need anti-malware, and explain why. That list is the starting point for the periodic review and the document an assessor compares against actual deployment. Build it from the cardholder data environment inventory rather than from memory, so that every in-scope system appears either with an anti-malware agent or on the register.

Scope of the list: Record each component by hostname or asset ID, operating system, owner and network zone, so the entry can be matched to a scan or inventory export.
Justification: Write a short, specific reason per entry, such as a system that runs a fixed function with no user logins and no file exchange. Generic wording like "low risk" will not hold up.
Ownership and approval: Name the person who signs off each entry and the date of their approval.
Change control: Route any new system into the register or the agent rollout through the same change process that updates the CDE inventory.

Before relying on the register, confirm with your QSA how they expect the justification to read in your ROC or SAQ.

Evidence auditors ask for and which component produces it

This table maps the evidence a QSA is likely to request for requirement 5 to the component that produces it in a self-hosted Wazuh deployment, with a retention note for each item. Use it to plan log routing and storage before the assessment, and confirm every retention period with your QSA and internal policy.

Evidence item	Source component	Retention note
Agent inventory and deployment status	Wazuh server agent list and Wazuh dashboard, cross-checked against the asset register	Export a dated snapshot each review cycle. Confirm the retention period with your QSA and internal policy.
Malware alert records	Wazuh server alerts stored in the Wazuh indexer, with rule IDs for malware detections	Keep alerts and their disposition notes for the period your policy sets. Confirm how long alerts must remain searchable.
Removable media scan or behavior logs	Anti-malware scanner logs on endpoints forwarded to the Wazuh server, such as ClamAV or a commercial product where used	Confirm with your QSA which log source satisfies the removable media requirement for your environment, and how long it must be kept.
Anti-malware audit logs under requirement 10.5.1	Wazuh agent and server logs, plus the scanner's own audit log, collected centrally	Retention must align with requirement 10.5.1. Confirm the exact period with your QSA and internal policy.
Update and signature currency	Scanner update logs, YARA rule repository history and Wazuh rule and CTI update records	Keep version and update timestamps for the assessment period. Confirm the required history length with your QSA.
Tamper protection settings	Agent configuration pushed from the Wazuh server, plus endpoint configuration exports showing user disablement is blocked	Keep configuration baselines and change records. Confirm how long configuration history must be retained.
Not-at-risk register and targeted risk analysis	Documented register maintained outside the tools, cross-checked against agents with no anti-malware deployed	Keep each version of the register and the risk analysis that sets the review frequency. Confirm the retention period with your QSA.
Scan and review schedule	Wazuh scheduled scans and the review calendar tied to the targeted risk analysis	Keep schedule definitions and completion records. Confirm the retention period and sampling approach with your QSA.

Where open-source tooling alone does not satisfy requirement 5

Requirement 5 is judged on what the anti-malware capability does and what evidence it produces, not on whether the software is open source. The cards below mark the points where an open-source stack needs confirmation with your QSA or a commercial component to close the gap.

Engine coverage against every 5.2 capability

Wazuh malware detection, YARA rules and ClamAV scanning each cover part of what Requirement 5.2.2 asks for, which is detecting and removing, blocking or containing all known malware types. Map each capability to a specific engine and signature source, then ask your QSA whether the combination shows coverage of all known malware types for your environment. Do not assume that running several tools adds up to full coverage without that mapping.

Behavior-based removal and containment

Requirement 5.3.1 and 5.3.2 expect real-time scanning or continuous behavioral analysis, and an active response has to remove or contain malicious activity, not only raise an alert. Open-source agents can trigger scripts for containment, but you need to test whether automated actions stop a live process, quarantine a file and isolate a host without breaking production. Confirm the behavioral coverage with your QSA before relying on it.

Removable media enforcement

Requirement 5.3.3 requires removable electronic media to be scanned automatically or analyzed continuously when inserted, connected or mounted, and this requirement has been mandatory since 31 March 2025. Monitoring USB events and running a manual scan script may not meet the automatic requirement on its own. Test insertion on each endpoint class, including kiosks and workstations that cannot run a full agent, and record the results.

Signature feeds and support obligations

Requirement 5.3.1 expects anti-malware mechanisms to update automatically, and a signature or rule feed that lags behind new threats weakens every other control. Community-maintained rule sets and open feeds may have no service commitment, so you need to confirm update frequency, who fixes a broken feed and what your own team must maintain. Document the owner, the update cadence and the escalation path for each feed.

Tamper protection and audit logs

Requirement 5.3.2.1 covers preventing users from disabling or altering anti-malware, and Requirement 5.3.4 requires audit logs to be enabled and retained in line with Requirement 10.5.1. An open-source agent that a local administrator can stop or reconfigure may not meet the tamper requirement without additional controls such as restricted service accounts, configuration management and alerts on agent disconnection. Confirm this design with your QSA.

Systems where a commercial product remains necessary

Some platforms may not be supported by open-source agents, or your QSA may expect a product with a formal certification or vendor warranty for specific systems, such as legacy hosts or certain mainframe or OT devices. Mark these systems early in your asset inventory and decide whether a commercial product, a compensating control or a customized approach applies. Put each decision in your written justification before the assessment starts.

Questions buyers ask about PCI DSS requirement 5 open-source anti-malware

Does open-source anti-malware alone satisfy PCI DSS requirement 5?

Open source can cover much of requirement 5, but no supplied fact says a single open-source tool satisfies it on its own. Requirement 5.2.1 asks for anti-malware on every system component that is not evaluated as not at risk, and 5.2.2 asks that it detect and remove, block or contain all known malware types. Wazuh malware detection, YARA rules and ClamAV can contribute evidence for these, but you must confirm with your assessor that the combined tooling detects the malware types in your environment. Where a dedicated anti-malware product is still needed, the gap usually shows up in signature coverage, real-time or behavioral scanning, or tamper protection. Check each sub-requirement against your own environment before deciding.

What does a PCI DSS requirement 5 open-source rollout cost?

No supplied fact gives a price or budget, so treat any figure as something to request from each provider. Costs fall into three groups: the software, which is free to download under the licenses for Wazuh and ClamAV but still needs servers and storage; implementation and integration work, which a partner quotes from a written scope; and recurring operations, including alert triage, rule tuning, patching and the periodic risk evaluation under 5.2.3. Costs rise with the number of endpoints, the number of operating systems, how many systems must be documented as not at risk, and how much evidence your assessor expects. Ask any quote to separate one-time setup from monthly or annual operating effort.

How long does it take to roll out endpoint anti-malware for PCI DSS?

No supplied fact gives a duration, so confirm timelines in a written scope rather than assuming one. The length depends on the number of endpoints and servers in the cardholder data environment, the operating systems involved, whether hosts can take agents, and how much change control your environment requires. Two dates matter for planning: requirements 5.2.3.1 and 5.3.3 became mandatory on 31 March 2025, so a rollout that starts now must already meet them. Wazuh's documentation also lists an offline installation guide, which can extend the schedule where networks are isolated. Ask the partner to break the timeline into discovery, pilot, fleet rollout and evidence collection.

What must our team provide for an open-source anti-malware project?

Your team must provide the facts that define scope: an inventory of system components in the cardholder data environment, a documented list of any components evaluated as not at risk, and the targeted risk analysis that sets the review frequency under requirement 5.2.3.1, performed under 12.3.1. You also need access to target networks and cloud accounts, change approval, named owners for alert handling, and a place where logs are retained in line with requirement 10.5.1 for the audit logs described in 5.3.4. Without these, a partner cannot test the rules or show the evidence an assessor will request.

Can our internal team run PCI DSS anti-malware on open-source tools?

Yes, if your team has the skills and capacity, but the work is more than installing software. Operating Wazuh means maintaining the indexer, the server cluster and the dashboard, applying the 4.14 patch releases as they ship, and triaging alerts around the clock where your scope requires it. Wazuh's dashboard offers prebuilt views for PCI DSS, which helps evidence gathering but does not replace review. Decide before you start whether your staff will own the platform, whether a partner will implement and hand over, or whether an ongoing retainer will cover upgrades and testing. Many teams split the work this way.

Will a QSA accept open-source anti-malware evidence for requirement 5?

A QSA decides whether evidence meets the requirement, so confirm acceptance early rather than after deployment. PCI DSS assessments are documented in a Report on Compliance by a Qualified Security Assessor, or in a Self-Assessment Questionnaire with an Attestation of Compliance, and certificates are not recognized as validation. The open-source tool itself is not the question; the assessor will look for coverage across the component list, alert and log records, scan and update history, and proof that users cannot disable the protection. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or attestations. Independent assessors and the payment brands determine acceptance.

Who enforces PCI DSS requirement 5 for our organization?

The PCI Security Standards Council owns the standard, but it does not enforce compliance or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Your acquirer or card brand rules set what you must submit, so ask them which validation level and form applies to you before you choose a tool or a partner. Also confirm whether requirement 5.2.3 review records or 5.3 audit logs are part of your submission. This question determines how much evidence you need to prepare.

How a requirement 5 deployment is sequenced

The sequence starts with scoping the cardholder data environment and ends with an evidence package an assessor can test against Requirement 5. Each step produces a record that the next one depends on, so gaps surface early rather than at assessment time.

Scope the cardholder data environment
The assessed organization and its QSA or internal assessor define which systems store, process or transmit cardholder data or could affect that environment. The DeployOpen team works from that boundary, not from the whole network, so Requirement 5 applies to the right system components. Done means a signed scope statement and network diagram that the assessor accepts as the basis for every later step.
Build the component inventory
Collect a complete list of system components in scope, including Windows, Linux and macOS hosts, servers, virtual machines and any removable media workflows. Cross-check the inventory against configuration management records and the Wazuh agent registry to find hosts that have no agent. Done means a reconciled inventory where every component is either covered by anti-malware or listed for the periodic evaluation described later.
Deploy agents and confirm coverage
Install Wazuh agents through your standard deployment tooling and enroll them with the Wazuh server, which can run as a cluster for scale. Confirm each agent reports to the indexer and dashboard, and record any device that cannot take an agent. Done means a coverage report that matches the inventory, with exceptions routed to the not-at-risk review rather than silently left out.
Configure scanning and alerting
Set malware detection and file integrity rules, add YARA rules or ClamAV scanning where your design calls for them, and enable removable media scanning or behavioral monitoring when media is connected. Define which alerts go to a named responder and how a blocked or contained event is recorded. Done means a test event that produces an alert, a ticket and a documented response, and a settings baseline that users cannot change without an alert.
Document the not-at-risk list and targeted risk analysis
For each component that the organization deems not at risk for malware, record the reason and the evaluation frequency in a targeted risk analysis under Requirement 12.3.1. Compare the documented list with the components that have no anti-malware deployed, since that comparison is the expected test for Requirement 5.2.3. Done means a list where every item without an agent has a justification and a set evaluation cadence that the risk owner has approved.
Set up log retention
Enable anti-malware audit logging on every covered component and forward those logs to the Wazuh indexer. Set retention to meet Requirement 10.5.1, and confirm that administrators cannot disable or edit the anti-malware configuration without generating a record. Done means a retention setting you can show the assessor, and a sample log search that returns events from several hosts over the same period.
Test and collect evidence for the assessor
Run controlled tests such as a harmless test file or EICAR-style signature, a blocked removable media event and an attempt to disable the agent, then record the results. Collect the inventory, coverage report, risk analysis, configuration baseline, alerts and log samples into one evidence folder mapped to each sub-requirement. Done means every Requirement 5 sub-requirement has a named artifact and a test result the QSA can review, and you have confirmed with the assessor which items they need in their preferred format.

How DeployOpen scopes and delivers requirement 5 evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source endpoint platforms inside your own infrastructure. For requirement 5, we turn the anti-malware scope, the not-at-risk list and the evidence trail into a written deliverable set that your assessor can review, and we prepare the controls for assessment without issuing any attestation.

How we scope

Confirm which system components sit in the cardholder data environment and which fall under anti-malware or the not-at-risk list.
Agree in writing which Wazuh, YARA and ClamAV capabilities are in scope and which gaps need a separate product.
Define the targeted risk analysis inputs that set the frequency for periodic evaluation of components deemed not at risk.

How we build

Deploy Wazuh agents, server and indexer in your cloud accounts, data centers or air-gapped networks according to the agreed architecture.
Configure malware detection rules, YARA scanning and ClamAV integration, then test detection against known sample categories in a controlled setting.
Set agent configuration so anti-malware settings and audit logs cannot be disabled or altered by ordinary users, and document the configuration.

How we hand over

Deliver the not-at-risk component list, the periodic evaluation records and the anti-malware configuration baseline as versioned documents.
Provide test records, log retention settings and dashboard views mapped to the PCI DSS v4.0.1 requirement numbers in scope.
Walk your internal team and assessor through the evidence set so they know where each artifact comes from and how it is produced.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, based on the written scope.
Plan Wazuh patch upgrades and rule updates in your change process, with test results recorded before production changes.
Confirm with your QSA or internal assessor which evidence they require, since DeployOpen does not issue reports or attestations.