Wazuh Mapped to ISO 27001, SOC 2 and PCI DSS: What Each Module Actually Evidences
Wazuh ships with rule groups tagged against several compliance frameworks, and those tags are the reason many organisations choose it. They are also the reason many arrive at an audit with a mapping nobody validated. A tag says a rule is related to a requirement. An auditor asks a different question: show me the evidence, show me who reviewed it, show me that the control operated for the whole period.
This is the mapping we actually use on engagements — which Wazuh capability produces which artefact, for which control, and what the tool does not cover.
The five capabilities that do the work
Almost every compliance mapping below resolves to one of these:
- Log collection and archiving — the manager ingests agent and syslog events, writes them to the indexer, and retains raw archives separately from the searchable index.
- File Integrity Monitoring (FIM) — the
syscheckmodule watches specified paths and registry keys for creation, modification and deletion, with who-data attribution where the audit subsystem supports it. - Security Configuration Assessment (SCA) — policy files, largely CIS-benchmark derived, evaluated on each agent on a schedule, producing a pass/fail state per check.
- Vulnerability detection — installed-package inventory correlated against vulnerability feeds, producing a per-host finding list.
- Rules, decoders and active response — the correlation layer that turns events into alerts, and the hook that can act on them.
Everything an auditor accepts comes out of one of those five, plus the process you wrap around them.
ISO/IEC 27001:2022 Annex A
The 2022 revision reorganised Annex A into four themes and, importantly for this discussion, split logging from monitoring. Annex A numbering is unchanged since 2022 — Amendment 1:2024 amends clauses 4.1 and 4.2 on climate action and adds no controls.
| Control | Wazuh capability | Evidence produced |
|---|---|---|
| A.8.15 Logging | Log collection, archiving, agent enrolment | Event archives with retention, a log-source inventory showing coverage, and clock-synchronised timestamps |
| A.8.16 Monitoring activities | Rules and alerting, dashboards | Alert history, triage records, and demonstrable review cadence — this is the control the tool alone never satisfies |
| A.5.25 Assessment and decision on information security events | Alert triage workflow | Per-alert decisions: escalated to incident, or closed with reason. Requires a ticketing trail; Wazuh alone records the alert, not the decision |
| A.8.8 Management of technical vulnerabilities | Vulnerability detection | Per-host finding lists over time, showing detection and remediation |
| A.8.9 Configuration management | SCA | Baseline pass/fail per host per check, and drift over time |
| A.8.7 Protection against malware | Rootcheck, integrations, active response | Detection events and the response taken |
| A.8.32 Change management | FIM | Unauthorised change detection on production configuration and binaries |
The trap. A.8.15 and A.8.16 are separate controls and are tested separately. Organisations deploy Wazuh, evidence A.8.15 comfortably, and then fail A.8.16 because nobody can show that alerts were looked at. Logging is a deployment. Monitoring is a rota.
SOC 2 — Trust Services Criteria
A SOC 2 Type 2 tests operating effectiveness over a period, which changes what matters. For Type 2 the auditor is not asking whether the control exists today; they are sampling dates across the observation window. A SIEM stood up two weeks before fieldwork produces a qualified report.
| Criterion | Wazuh capability | What the auditor samples |
|---|---|---|
| CC7.1 — configuration and vulnerability detection | SCA, vulnerability detection | Baseline definition and evidence of deviation detection across the period |
| CC7.2 — monitoring for anomalies indicative of malicious acts | Rules, alerting, FIM | Alerts raised on sampled dates, and the analysis that determined whether each was a security event |
| CC7.3 — evaluating security events to determine whether they are incidents | Triage workflow | The documented decision path from alert to incident-or-not |
| CC7.4 — incident response | Active response, integrations | Containment actions and their timestamps, tied to the incident record |
| CC6.1 / CC6.8 — logical access, unauthorised software | Authentication log correlation, FIM, package inventory | Failed-authentication and privilege-change alerting; detection of unapproved software |
The trap. CC7.2 and CC7.3 are where Wazuh deployments get qualified findings, and the gap is almost always the same: alerts exist, decisions were made in someone’s head, and nothing was written down. Route alerts into a ticket with a recorded disposition from day one of the observation period, not from the month the auditor arrives.
PCI DSS v4.0.1 — Requirement 10
Cite v4.0.1. Version 4.0 was retired on 31 December 2024 and v4.0.1 is the only active version; the numbering below is unchanged between them.
| Requirement | Wazuh capability | Notes |
|---|---|---|
| 10.2.1.x — audit logs capture specified events | Log collection, decoders | Individual user access to cardholder data, all actions by privileged accounts, access to audit logs, invalid access attempts, authentication changes, and audit log initialisation or stopping. Each is a separate sub-requirement and each needs a log source proving it |
| 10.2.2 — required fields per event | Decoders, field extraction | User, event type, date and time, success or failure, origin, and affected data or resource. Parsing gaps show up here, not at ingest |
| 10.3.1–10.3.4 — audit log protection | Agent-to-manager transport, index permissions, FIM on log paths | Read access limited by need, protection from modification, prompt write to a central store, and integrity monitoring on the logs themselves |
| 10.4.1 — daily review of specified logs | Alerting, dashboards | Security events, and logs from all critical system components and from systems performing security functions, reviewed at least once daily |
| 10.4.1.1 — automated review mechanisms | Rules engine | Mandatory since 31 March 2025. Manual daily review no longer satisfies this. The rules engine performing correlation and surfacing exceptions is the automated mechanism — but you must be able to describe it as such |
| 10.5.1 — retention | Archives and index lifecycle | Twelve months of audit log history, with at least the most recent three months immediately available for analysis. This is the requirement that sizes your storage |
| 10.6.x — time synchronisation | Agent and manager NTP | Frequently overlooked, trivially tested, and a finding when hosts disagree |
| 10.7.x — failure of critical security control systems | Agent health monitoring | Detection and response when the SIEM or an agent itself stops reporting. Alert on agent disconnection — a silent agent is a failed control |
The trap. 10.5.1 and 10.4.1.1 together are what break under-provisioned deployments. Three months immediately searchable plus twelve months retrievable is an index lifecycle policy with a warm and cold tier, sized against real daily volume. Deployments that keep thirty days because that is what fit on the disk fail a requirement that no amount of tuning repairs after the fact.
India: RBI and CERT-In
For Indian regulated entities two additional constraints drive architecture. CERT-In’s 2022 directions require logs to be maintained for 180 days and within Indian jurisdiction — which rules out shipping them to a region outside India and is a common reason to self-host. Incident reporting runs to a six-hour window from detection, which is a detection-and-escalation requirement, not a logging one; the SIEM has to surface the event fast enough for a human to report inside it.
RBI-supervised entities layer their own continuous-monitoring and SOC expectations on top. Both are covered in depth in SIEM for the RBI cyber security framework and CERT-In six-hour reporting and SIEM requirements.
What Wazuh does not give you
Being explicit about this is what makes the rest of the mapping credible.
- The written process. Every framework above tests documented procedures. Wazuh produces events; your logging and monitoring policy, review procedure and escalation path are documents.
- The reviewer. Daily review, alert triage and the decision record are human activities with a rota behind them.
- Scope assurance. The tool reports on agents that are installed. Proving the agent is on every in-scope host is an asset-inventory exercise, and unmanaged hosts are where audits find gaps.
- Validated mappings. Built-in compliance tags are a starting point. Which specific rule evidences which specific control in your environment is an assessment, and it is the part we do.
- The evidence pack. Auditors ask for extracts across sampled dates in a reviewable form. Producing that repeatably is a reporting job, not a dashboard.
How we deliver this
Praxis-Q runs Wazuh, Elastic/OpenSearch and Graylog/Security Onion in production for clients, under either of two models. In build-and-hand-over we architect against your retention and volume requirements, deploy, tune, produce the validated control mapping and the evidence-pack procedure, and train your team — you own the stack and the data outright. In managed, the same build is operated by our analysts under SOC-as-a-Service, who perform the daily review the frameworks require and produce the evidence at audit time. The platform is identical either way, so moving between them is a handover, not a migration.
If endpoint detection and response is the specific gap, see Endpoint Security and XDR. If you are still choosing a platform, start with the open-source SIEM comparison.
Frequently asked questions
Do Wazuh’s built-in PCI DSS rule tags mean we are PCI compliant?
No. The tags indicate which rules relate to which requirements. Compliance is assessed on evidence, documented process and control operation over time, and a QSA validates the scope and the mapping rather than accepting the vendor’s labels.
Does 10.4.1.1 mean manual log review is no longer allowed?
For the daily review under 10.4.1, automated mechanisms are required — the requirement became mandatory on 31 March 2025. Humans still review what the automation surfaces; what is no longer acceptable is a person manually reading raw logs as the whole control.
We have thirty days of logs. Is that a problem for PCI DSS?
Yes. 10.5.1 requires twelve months of audit log history with the most recent three months immediately available. Retention cannot be retrofitted — data you did not keep is gone — so this is worth fixing before an assessment window opens rather than during one.
Can one Wazuh deployment serve ISO 27001, SOC 2 and PCI DSS at once?
Yes, and it should. The log sources overlap almost entirely. What differs is the evidence each auditor asks for and the sampling method, which is a reporting and mapping exercise on a single platform rather than three deployments.
What does an implementation cost?
Scope is driven by daily ingest volume, retention period, agent count, number of distinct log sources, which frameworks are in scope, and whether we build and hand over or operate it for you. Pricing is scoped per engagement — request a proposal.
Free Consultation
Ready to Get Compliant?
ISO 27001, PCI DSS, HIPAA, SOC 2 & more — fast-track in a few weeks.
Tags
Share this article
Sahil Dubey
Compliance & Security Expert
Praxis-Q’s compliance and offensive-security practitioners deliver ISO 27001, SOC 2, PCI DSS, HIPAA, GDPR and DPDP engagements for banks, payment gateways and regulated fintechs.