Wazuh for SMBs: How a Free SIEM Helps You Meet PCI DSS Requirement 10.2.1 (Audit Log Review)

Why This Matters: The SMB Logging Gap That Auditors (and Attackers) Love

Most small and mid-sized businesses that touch cardholder data — payment gateways, point-of-sale resellers, e-commerce shops, booking platforms — fall into PCI DSS Self-Assessment Questionnaire (SAQ) categories that still require logging controls. The problem is that commercial SIEM platforms (Splunk, QRadar, Microsoft Sentinel) are priced for enterprises, so SMBs frequently run with no centralized logging at all — which is exactly why so many are now looking for a free SIEM for SMB PCI DSS compliance instead. Logs sit scattered across routers, servers, and payment applications, get overwritten after a few days, and nobody reviews them.

That gap is exactly how breaches go unnoticed for months. In nearly every retail and hospitality breach post-mortem that PCI Forensic Investigators publish, the root cause analysis repeats the same line: logs existed on the compromised system, but no one was collecting or reviewing them centrally, so the intrusion ran for weeks before a third party (a bank, a card brand, a customer) flagged the fraud.

PCI DSS addresses this directly in Requirement 10 — "Log and monitor all access to system components and cardholder data." Two sub-requirements matter most here:

• Requirement 10.2.1 — audit logs must be enabled and active for all system components, and must capture a defined set of events (individual access to cardholder data, actions by administrative/privileged accounts, access to the audit logs themselves, invalid access attempts, changes to authentication mechanisms, and start/stop/pause of logging).
• Requirement 10.4.1 — those audit logs must actually be reviewed at least once daily, with automated mechanisms permitted to support the review.

You cannot satisfy 10.4.1 by hand-reading syslog files across dozens of servers every morning. You need a central log collection and correlation layer. That is what a SIEM does — and Wazuh, a free, open-source SIEM and XDR platform, is built specifically to collect, parse, correlate, and surface exactly the event types 10.2.1 requires, with a dashboard module that maps alerts to PCI DSS requirement numbers out of the box.

This guide walks through deploying Wazuh to cover the in-scope systems in your cardholder data environment (CDE), configuring log sources so the required event types are actually captured, and setting up the daily review workflow an assessor will want to see evidence of. If you haven’t already hardened the underlying operating systems you’re about to monitor, it’s worth pairing this guide with our walkthrough on hardening a Linux server with CIS Benchmarks and Lynis so you’re not building compliance evidence on top of an unhardened host.

Prerequisites

Before you start, make sure you have:

• A Linux host for the Wazuh server (Ubuntu 22.04/24.04 or RHEL/CentOS 8/9), minimum 4 vCPU / 8 GB RAM for small deployments (under ~50 agents); more for larger estates.
• Root/sudo access on the Wazuh server and on every endpoint you plan to monitor.
• A list of systems that store, process, or transmit cardholder data (your CDE scope) — this is the minimum set of systems that must be covered; don’t skip scoping.
• Outbound/inbound network access between agents and the manager on TCP 1514 (agent-manager communication) and TCP 1515 (agent enrollment).
• Admin access to configure OS-level audit subsystems: auditd on Linux, Advanced Audit Policy on Windows.
• A mail relay or SMTP credentials if you want daily review alerts emailed automatically (optional but recommended for 10.4.1 evidence).

Since you’ll be opening SSH access across your CDE to install agents and configure auditd, it’s also worth confirming you’ve completed hardening SSH on Linux servers first — administrative access itself shouldn’t become the weak point you’re trying to log and monitor.

Step-by-Step: Deploying Wazuh and Mapping It to Requirement 10

1. Install the Wazuh Server (Manager, Indexer, Dashboard)

Wazuh publishes a single-node "all-in-one" install script for small deployments.

curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

This installs the Wazuh indexer, manager, and dashboard on one host and prints the generated admin password at the end.

Verify: run sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard — all three should show active (running).

2. Log In and Rotate the Default Credentials

Browse to https://<server-ip> and log in with the admin credentials printed during install.

sudo tar -xf wazuh-install-files.tar

Extracting this archive gives you the generated passwords file if you lost the console output.

Verify: you can log into the dashboard; then immediately change the admin password under Server management → Users.

3. Deploy the Wazuh Agent on Every In-Scope System

On each Linux server in your CDE (do this for every CDE system, not just a sample — 10.2.1 applies to "all system components"):

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update
sudo WAZUH_MANAGER="<manager-ip>" apt-get install wazuh-agent -y
sudo systemctl enable --now wazuh-agent

This registers the agent with your manager and starts forwarding logs.

Verify: on the manager, run sudo /var/ossec/bin/agent_control -l — the new agent should appear with status Active.

For Windows CDE hosts, use the Wazuh MSI installer and set the manager IP during install, then confirm the agent service Wazuh is running in Services.msc.

4. Turn On OS-Level Auditing So the Required Event Types Exist to Collect

Wazuh can only report what the OS actually logs. On Linux, install and configure auditd to capture privileged actions and authentication changes:

sudo apt-get install auditd audispd-plugins -y
sudo auditctl -w /etc/passwd -p wa -k identity_changes
sudo auditctl -w /etc/shadow -p wa -k identity_changes
sudo auditctl -w /var/log/ -p wa -k audit_log_access

These rules watch for write/attribute changes to credential files (supports 10.2.1.5) and for access to log directories (supports 10.2.1.3).

Verify: trigger a test change (sudo touch /etc/passwd) and confirm an event appears via sudo ausearch -k identity_changes.

5. Point Wazuh at the Audit Log and Authentication Logs

Edit /var/ossec/etc/ossec.conf on the agent to ensure these sources are forwarded (most are enabled by default, but confirm):

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

This streams Linux audit and authentication events to the manager for correlation.

Verify: restart the agent (sudo systemctl restart wazuh-agent) and check Dashboard → Threat intelligence → Events for new entries from that host.

6. Confirm the Built-In PCI DSS Rule Mapping Is Active

Wazuh’s default ruleset already tags thousands of rules with PCI DSS requirement numbers. Check that the compliance decoders are loaded:

sudo /var/ossec/bin/wazuh-logtest

Run a sample log line (e.g., an SSH failed login) through this interactive tool and confirm the output includes a pci_dss: field referencing a 10.2.x control.

Verify: in the dashboard, go to Modules → Security events → PCI DSS — you should see a breakdown of alerts grouped by requirement number, including 10.2.1-tagged events.

7. Add a Custom Rule for an Event Type Not Covered by Defaults

If you need to explicitly flag, say, new local admin account creation (supports 10.2.1.2 — actions by privileged accounts):

<group name="local,pci_dss_10.2.1.2,">
  <rule id="100100" level="10">
    <if_sid>5902</if_sid>
    <match>useradd</match>
    <description>New local user created - review for authorization</description>
    <group>pci_dss_10.2.1.2</group>
  </rule>
</group>

Save this in /var/ossec/etc/rules/local_rules.xml on the manager and restart the manager.

Verify: create a test user (sudo useradd testuser) and confirm an alert with rule ID 100100 appears in the dashboard within a minute.

8. Set Up the Daily Review Workflow Required by 10.4.1

Enable email alerting for high-severity events so a human reviews them daily without manually opening the dashboard:

<global>
  <email_notification>yes</email_notification>
  <email_to>security-team@yourcompany.com</email_to>
  <smtp_server>smtp.yourcompany.com</smtp_server>
  <email_from>wazuh-alerts@yourcompany.com</email_from>
</global>
<alerts>
  <email_alert_level>10</email_alert_level>
</alerts>

This emails the security team whenever an alert hits severity level 10 or higher, giving you a documented daily touchpoint.

Verify: trigger a level-10+ test alert (e.g., repeated failed logins) and confirm the email arrives; keep these emails as evidence for your QSA or SAQ self-assessment.

9. Configure Log Retention to Support 10.5.1

PCI DSS also requires audit log history to be retained for at least 12 months, with at least the most recent 3 months immediately available for analysis. Set an index lifecycle policy on the Wazuh indexer:

curl -X PUT "https://localhost:9200/_plugins/_ism/policies/wazuh-retention" \
  -H "Content-Type: application/json" -u admin:<password> -d '{
  "policy": {
    "description": "12-month retention for PCI DSS 10.5.1",
    "default_state": "hot",
    "states": [
      {"name": "hot", "transitions": [{"state_name": "warm", "conditions": {"min_index_age": "90d"}}]},
      {"name": "warm", "transitions": [{"state_name": "delete", "conditions": {"min_index_age": "365d"}}]}
    ]
  }
}' -k

This keeps 90 days of logs "hot" (fast access, matching the 3-months-immediately-available rule) and deletes indices after 365 days.

Verify: check applied policy status with GET _plugins/_ism/explain/<index-name>.

Common Pitfalls and Mistakes

• Scoping only "important" servers. Requirement 10.2.1 says "all system components" in the CDE. Leaving out a jump box or a backup server because it "doesn’t touch cards directly" is a common assessor finding — if it’s in the CDE network segment, it’s in scope.
• Installing agents but never enabling OS auditing. Wazuh cannot invent events the OS never logged. Skipping auditd/Advanced Audit Policy configuration means 10.2.1.2, 10.2.1.4, and 10.2.1.5 event types simply never arrive.
• Alert fatigue from default rules. Out of the box, Wazuh is noisy. Without tuning (step 7’s approach, applied broadly), teams start ignoring alerts entirely — which defeats the purpose of 10.4.1’s daily review requirement.
• Treating "SIEM installed" as "compliant." Assessors want evidence of the review process, not just the tool: documented procedures, named responsible staff, and retained alert/email evidence. The tool is necessary but not sufficient.
• No time synchronization. If agent and manager clocks drift, correlated events get misordered timestamps, which undermines the forensic value auditors specifically look for in Requirement 10. Run NTP/chrony on every in-scope host.
• Ignoring the indexer’s disk growth. Audit and auth logs from dozens of servers add up fast. Without the retention policy in step 9, disks fill and the manager silently stops indexing new events — a serious gap if it happens during an incident.
• Relying on host logs alone. Wazuh gives you strong host-based visibility, but it doesn’t replace network-layer detection. Teams that stop at endpoint logging miss attack traffic that never touches a monitored host directly — deploying Suricata IDS/IPS on a Linux server alongside Wazuh closes that gap between endpoint logs and live network traffic analysis.

Troubleshooting

Agent shows "Never connected" in agent_control -l.

Check that TCP 1514/1515 are open between agent and manager: sudo nc -zv <manager-ip> 1514. If closed, fix firewall/security group rules, then restart the agent.

wazuh-logtest shows no pci_dss field for an event you expect to be tagged.

The event is likely matching a generic rule, not the specific PCI-tagged rule. Compare the rule ID returned against the ruleset in /var/ossec/ruleset/rules/ — you may need a custom rule (as in step 7) if your log format doesn’t match the default decoder.

Dashboard shows "Wazuh API not reachable."

Usually caused by a certificate mismatch after changing the server’s hostname/IP. Regenerate certificates with the Wazuh certs tool and rerun wazuh-install.sh --start-wazuh-agent-service or the equivalent restart sequence from the official deployment guide.

Indexer health shows yellow or red status.

Run curl -k -u admin:<password> https://localhost:9200/_cluster/health?pretty. A single-node deployment often shows yellow because replica shards can’t be allocated — this is expected for single-node setups and not itself an error, but red indicates unassigned primary shards and usually a disk space or node-down issue.

Email alerts never arrive.

Confirm SMTP settings with sudo /var/ossec/bin/ossec-control status and test manually: echo "test" | mail -s "test" security-team@yourcompany.com. If the relay requires authentication, Wazuh’s built-in mailer needs an authenticated relay or a local MTA (e.g., Postfix) configured to relay on its behalf.

Conclusion

PCI DSS Requirement 10.2.1 demands that audit logs capture specific, security-relevant events across every system in your cardholder data environment, and Requirement 10.4.1 demands someone actually reviews them daily. For an SMB without a six-figure SIEM budget, Wazuh closes both gaps for the cost of the infrastructure it runs on: deploy the manager, roll out agents to every in-scope system, turn on OS-level auditing so the right events exist, confirm the built-in PCI DSS rule tagging, and wire up a daily alert/email workflow you can show an assessor as evidence.

The tool gets you the logging and correlation. Compliance still depends on scoping correctly, tuning the ruleset so alerts get reviewed instead of ignored, and documenting the review process itself.

This guide pairs naturally with other pieces of the free SMB compliance stack we’ve covered, including Bitwarden for SMBs for Requirement 8.3.1 multi-factor authentication, and our walkthrough on locking down SMB network access with pfSense for Requirement 1.2.1 network segmentation. If you need a formal gap assessment beyond Requirement 10, InfoSec4TC’s PCI DSS Compliance services can validate your full control set against an assessor’s expectations.

Next step: inventory every system in your CDE this week, confirm each one has a Wazuh agent reporting, and check the PCI DSS module in the dashboard to see which requirement-10 sub-controls currently have zero matching events — that list is your remediation priority.

Free Resources

• Wazuh Documentation — official installation, configuration, and ruleset reference.
• Wazuh PCI DSS Compliance Overview — how Wazuh’s modules map to PCI DSS requirements.
• PCI Security Standards Council – PCI DSS v4.0 Document Library — official PCI DSS standard and supporting guidance, including Requirement 10 text.
• NIST SP 800-92, Guide to Computer Security Log Management — foundational federal guidance on log management practices referenced by many compliance frameworks.
• Wazuh GitHub Repository — source code, issue tracker, and community-contributed rules/decoders.