Wazuh Compliance Reporting: PCI, HIPAA, ISO 27001

How Wazuh Compliance Mapping Works

Wazuh does not run a separate compliance engine. Instead, every rule in the ruleset carries compliance tags in its XML definition. When a rule fires, the resulting alert inherits those tags, so the same event is automatically attributed to every framework control it satisfies. This is the core idea: detection and compliance evidence are the same data, viewed through different filters.

Open any rule in the Wazuh ruleset and you will see groups such as pci_dss, hipaa, gdpr, nist_800_53, tsc and gpg13, each listing the specific control identifiers. For example, a rule detecting a sudo command failure might list pci_dss with 10.2.5, hipaa with 164.312.b, nist_800_53 with AU.6 and AC.7, and gdpr with IV_35.7.d. ISO 27001 controls map through the same tagging structure, referencing Annex A clauses.

Because the mapping lives in the rule rather than in a post-processing layer, custom rules you write must include their own compliance tags if you want them to appear in compliance dashboards. This is a common gap: teams write excellent custom detections, then wonder why the events never show in the PCI view. The fix is to add the relevant compliance groups to the custom rule definition.

PCI DSS Reporting With Wazuh

PCI DSS leans heavily on Requirement 10 (log and monitor all access to system components and cardholder data) and Requirement 11.5 (file integrity monitoring and change detection). Wazuh addresses both natively. The default ruleset tags events against PCI DSS sub-requirements, and the Wazuh dashboard ships a dedicated PCI DSS compliance view that breaks alerts down by requirement.

For Requirement 10, configure agents on every in-scope system in the cardholder data environment to forward authentication events, privileged actions, access to audit logs and changes to system-level objects. Wazuh normalises these into a consistent format with user, source, timestamp and outcome, which is exactly what an assessor samples. Set log retention to at least 12 months, with the most recent 3 months immediately searchable in the hot indexer and older data in cold snapshots to object storage.

For Requirement 11.5, enable the Wazuh File Integrity Monitoring module on critical files and directories. FIM events carry the pci_dss group tagged to 11.5, giving you a clean report of who changed what and when across the CDE. Combine this with the configuration assessment module to evidence secure configuration baselines for Requirement 2.

HIPAA Reporting With Wazuh

HIPAA Security Rule technical safeguards under 164.312 require audit controls, access controls, integrity controls and authentication. Wazuh maps directly to these. The hipaa rule group references 164.312 sub-paragraphs, and the dashboard provides a HIPAA compliance view organised by safeguard.

The most important HIPAA requirement Wazuh evidences is 164.312(b), audit controls: the ability to record and examine activity in systems that contain electronic protected health information (ePHI). Deploy agents on systems holding ePHI, monitor access to those systems and the data within them, and retain the resulting audit trail. HIPAA does not set a single universal retention number for audit logs, but related documentation requirements run to six years, so design retention conservatively and to your compliance counsel's guidance.

Pair audit controls with FIM (integrity, 164.312(c)) on ePHI repositories and with authentication monitoring (164.312(d)) to evidence that only authorised users access protected systems. The combination produces a defensible audit-controls narrative for a HIPAA assessment or a Business Associate due diligence questionnaire.

ISO 27001 and GDPR Reporting

For ISO/IEC 27001:2022, the relevant Annex A controls are A.8.15 (logging) and A.8.16 (monitoring activities). Wazuh provides the operating evidence an ISO auditor expects: that logging is implemented, monitored and reviewed, not merely documented in a policy. Use Wazuh to evidence that security events are collected centrally, retained per policy, alerted on and triaged. The internal audit and management review processes then reference Wazuh dashboards and reports as proof the monitoring control is operating.

For GDPR, Article 32 (security of processing) and Article 33 (breach notification) are the touchpoints. Wazuh tags relevant rules with gdpr control references. The practical value is twofold: continuous monitoring evidences the appropriate technical measures Article 32 requires, and rapid detection shortens the time to identify a personal data breach, which directly supports the Article 33 notification clock.

A single well-designed Wazuh deployment therefore feeds PCI DSS, HIPAA, ISO 27001 and GDPR evidence at once. This overlap is why we recommend designing detections against a unified control library rather than building separate monitoring for each framework.

Building Scheduled Compliance Reports

Dashboards are useful for live investigation, but auditors and boards want periodic, dated, exportable reports. Wazuh dashboard supports report generation from saved searches and visualisations, exportable as PDF, and you can schedule these to generate and email automatically. The pattern we use is a daily security summary, a weekly compliance status per framework and a monthly executive roll-up.

Each compliance report should answer three questions an assessor asks: what was monitored, what was detected, and how was it handled. So a strong PCI DSS monthly report includes coverage (which in-scope systems reported), the volume and breakdown of Requirement 10 events, FIM changes for Requirement 11.5 with disposition, and any gaps where expected log sources went silent. Silent-source detection matters: an agent that stops reporting is itself a finding.

Codesecure typically delivers 11 report templates as part of a managed SOC engagement, covering PCI DSS, HIPAA, ISO 27001, SOC 2 Common Criteria and GDPR, plus operational reports for daily and weekly SOC review. Templates are tuned to the client's scope so the evidence aligns to their actual certification boundary.

Common Compliance Reporting Pitfalls

• Treating the dashboard as the audit: Wazuh produces evidence, not a certificate. You still need the control, the policy and the assessor.
• Custom rules without compliance tags: detections that are not tagged never appear in framework views. Add the relevant groups to every custom rule.
• Retention shorter than the framework requires: PCI DSS 12 months, HIPAA documentation up to 6 years, ISO 27001 per policy. Size cold storage accordingly.
• Unmonitored in-scope systems: a missing agent on a CDE or ePHI host is a coverage gap an assessor will find. Reconcile the agent inventory against the asset inventory.
• No silent-source alerting: a log source that stops sending data looks like quiet, but it is a blind spot. Alert when expected sources go dark.
• Reports nobody reviews: scheduled reports are evidence of monitoring only if there is documented review. Record who looked and what they did.