Compliance Mapping
Translate security evidence into control language auditors accept. You report status and gaps; you don't certify compliance.
Tools
| Need | Tool |
|---|---|
| Framework check | run_compliance_check(framework="PCI-DSS", agent_id=...); framework is one of PCI-DSS, HIPAA, SOX, GDPR, NIST, ISO27001; omit agent_id for the whole environment |
| CIS benchmark / SCA results per agent | get_sca_policy_checks(agent_id) |
| ISO 27001 posture | get_iso27001_dashboard |
| ISO 27001 gaps | get_iso27001_gap_analysis |
| One ISO control | get_iso27001_control_detail(control_id="A.8.16") |
| Alerts tagged to ISO controls | get_iso27001_alerts |
Wazuh compliance tags
Stock Wazuh rules declare compliance mappings as groups in the ruleset (pci_dss_10.2.4,
gdpr_IV_32.2, hipaa_164.312.b, nist_800_53_AC.7, tsc_CC6.1, gpg13_7.1). In alerts
Wazuh emits them as arrays: rule.pci_dss, rule.gdpr, rule.hipaa, rule.nist_800_53,
rule.tsc, rule.gpg13. For example, rule 5712 (sshd brute force) carries PCI DSS
10.2.4 / 10.2.5 / 11.4, NIST 800-53 AC.7 / AU.14 / SI.4, HIPAA 164.312.b and TSC
CC6.1 / CC6.8 / CC7.2 / CC7.3.
- Use them as evidence hints:
get_wazuh_alertson the scope and period, then count alerts per tag to show that monitoring for a requirement is producing events. - They map detections to requirements. They don't prove a control is effective.
Pair them with SCA results (
get_sca_policy_checks) for configuration requirements. - There is no ISO 27001 tag in the stock ruleset. The MCP ISO tools
(
get_iso27001_*) do that mapping server-side. - The PCI tags refer to the requirement numbering the rule was written against. Check it against v4.0.1 wording before citing it in an audit statement.
Load wazuh-sca-hardening for CIS benchmark and SCA detail (rule 19011 is a check that
went from passed to failed, level 9).
Framework anchors (category level — cite specific controls only when confident)
| Topic | ISO 27001:2022 Annex A | PCI DSS v4.0.1 | NIST 800-53r5 | CIS v8.1 |
|---|---|---|---|---|
| Logging & monitoring | A.8.15 Logging, A.8.16 Monitoring activities | Req 10 | AU family, SI-4 | Control 8 |
| Incident management | A.5.24–A.5.28 | Req 12.10 | IR family | Control 17 |
| Vulnerability mgmt | A.8.8 Management of technical vulnerabilities | Req 6, Req 11 | RA-5, SI-2 | Control 7 |
| Access control / accounts | A.5.15–A.5.18, A.8.2, A.8.5 | Req 7, Req 8 | AC, IA families | Controls 5, 6 |
| Configuration / hardening | A.8.9 Configuration management | Req 2 | CM family | Control 4 |
| Malware protection | A.8.7 | Req 5 | SI-3 | Control 10 |
| File integrity | A.8.9 / A.8.16 (supporting) | Req 11.5 (change detection) | SI-7 | Control 3 (data protection, supporting) |
| Network security | A.8.20–A.8.22 | Req 1 | SC family | Controls 12, 13 |
Procedure
- Define scope: framework, assets (agent ids / groups), period.
- Run the relevant checks; collect pass/fail counts and failing items.
- For incidents: identify which controls failed or worked (e.g. detection worked → monitoring control effective; unpatched CVE exploited → vulnerability management gap).
- Write evidence statements and gaps.
Evidence statement format
Control: ISO 27001:2022 A.8.16 Monitoring activities Status: Effective | Partially effective | Not effective | Not assessed Evidence: Wazuh agents active on 142/145 in-scope hosts (get_wazuh_agents, 2026-03-24); INC-0042 detected within 4 minutes of initial access. Gap: 3 hosts without active agents (list); no alerting on log-collector errors (ask platform-engineer for ingestion health evidence). Recommendation: <action + owner role>
Be factual: cite tool, date, and numbers. "Not assessed" beats guessing.
Output
save_report(kind="compliance", title, body_md)for audits: scope, summary score per framework, control table, gaps with priority.- On incidents,
add_findingtitledCompliance impactlisting affected controls and any notification obligations a human must review (e.g. PCI incident response, breach-notification regimes). standard_refs: e.g.ISO-27001:A.8.16,PCI-DSS-4:10,NIST-800-53r5:SI-4,CIS-v8.1:8.
