Wazuh for PCI DSS requirements 10 and 11.5

Requirement 10.2.1 expects audit logs to be enabled and active for all system components and cardholder data, and sub-requirements 10.2.1.1 to 10.2.1.7 list the events that must be captured. Requirement 10.2.2 then sets the content of each entry: event type, date and time, success or failure, origination, and the identity of the affected data, component, resource or service. Wazuh does not add these fields on its own. Its decoders and rules can only report what each source produces, so the first task is to confirm that every log source emits all of these elements. Read the sub-requirement list in the PCI DSS v4.0 SAQ D for Service Providers directly, because the exact wording of 10.2.1.1 to 10.2.1.7 carries detail that summaries tend to drop.

Scope starts with your cardholder data environment inventory, not with the Wazuh deployment. Wazuh agents on Linux and Windows collect operating system audit data and send it to the Wazuh server, which applies decoders and rules and stores resulting alerts in the Wazuh indexer. Agentless monitoring covers devices such as firewalls, which send syslog to the server, and the server can also probe APIs on a schedule. Systems that agents cannot run on, such as some appliances and vendor-managed platforms, depend on syslog or API collection. For each of these, confirm the device can send the fields required by 10.2.2. A syslog message that drops the affected resource or the outcome leaves an audit gap even though the message arrived.

Build a table that maps each in-scope component to its collection method (agent, syslog, API or none) and to the 10.2.1 events it produces. Application and database logging is where many gaps appear. PCI SSC FAQ 1081 addresses database and application logging, and an agent on the host usually sees operating system events but not necessarily the application's own audit records. Check whether each application writes audit entries, where they are stored, and whether Wazuh can read them. PCI SSC FAQ 1034 addresses system-level objects. Use it to confirm which objects in your environment must be logged and that each one appears in your mapping. Read both FAQs before you conclude that the agent deployment alone covers requirement 10.2.

Plan for failures that do not look like failures. An agent that stops forwarding or a firewall whose syslog target changes will produce no alerts, and the absence of events is easy to mistake for a quiet environment. Assign an owner to watch agent connectivity and syslog source health in the Wazuh dashboard, and test each source by generating a known event and confirming it appears with the required fields. Time accuracy also matters: the date and time field in 10.2.2 is only useful if all sources share a synchronized clock. Ask the team that operates each firewall, database and application to confirm its time source before you accept its entries as evidence.

Requirement 11.5.2 asks for a change-detection mechanism, such as file integrity monitoring, that alerts on unauthorized changes to critical files and compares those files at least once a week. In a Wazuh deployment, file integrity monitoring runs on the agents and reports to the Wazuh server, so the work is mostly configuration and governance. The first decision is the critical file list. Build it from your own system inventory: every host in the cardholder data environment, every component that stores, processes or transmits cardholder data, and every security function such as authentication, logging and firewall policy. For each host, record the file or directory, its owner and the approver for changes to it. An assessor will trace monitored paths back to this list, so keep it as a controlled document with a named owner and a review date.

Monitored paths differ by platform. On Linux, the usual starting points are the system configuration directory, the directories holding system binaries, privilege settings such as sudoers, SSH server configuration, and the configuration directories of applications that handle cardholder data. On Windows, cover the system directories, the registry locations that hold security settings, and service configuration. Treat these as a starting point to validate against your hardened build standard. Exclusions need the same discipline as inclusions. High-churn paths such as log and cache directories may need exclusion to keep alert volume manageable, but each exclusion should be written down with a reason and reviewed, because an excluded path that should have been critical is a gap an assessor will test. Confirm in the documentation for your Wazuh version how default monitored directories, custom paths, exclusions and continuous monitoring options are declared.

The schedule must produce a comparison at least once every seven days on every in-scope agent. Set the scheduled scan frequency in the agent configuration that the Wazuh server manages, and confirm in the documentation for your version which setting controls scheduled comparison and how it interacts with continuous monitoring. Continuous monitoring helps with alerting, but do not assume it satisfies the weekly comparison without agreement. Ask your QSA how they will accept continuous monitoring alongside the scheduled comparison and what evidence they expect, such as scan records or agent logs showing completion. Then check operations: review the last scan time per agent in the dashboard and alert when an agent misses a cycle. An agent that goes offline or is misconfigured will otherwise fail the requirement without anyone noticing.

Change alerts must reach a reviewer who can act on them. Define which rules or alert levels represent file changes on critical paths, then route those alerts to a named queue, mailbox or ticketing integration with an accountable owner. Map each alert to the change management record that authorized it. A change made during an approved maintenance window should close with a reference to that record, while any change without one becomes an investigation. Test the routing end to end on a non-production host by altering a monitored file and confirming that the alert arrives, is assigned and is closed with a justification. Keep those test records as evidence. Reviewing these alerts overlaps with the broader log review covered elsewhere on this page, so use the same roles, escalation path and retention.

The definition of critical files is an entity decision, and it is one of the first things an assessor will test. The assessor will select systems, compare your inventory against the monitored paths and ask why any cardholder-related file is missing. Write the scope rationale into your documentation, record who approved it and review it whenever systems change. Confirm the file integrity capabilities and scan settings for your Wazuh version in the official documentation before you rely on them in an assessment, and confirm with your QSA or acquirer how they expect evidence to be presented. The weekly check is only as good as the list behind it, so spend most of the configuration effort on defining that list and proving it stays current.