Wazuh for PCI DSS, HIPAA and NIST 800-53 compliance

Wazuh for PCI DSS, HIPAA and NIST 800-53 compliance: what it covers and what it does not

Wazuh supplies monitoring, alert and dashboard output that can support a PCI DSS, HIPAA or NIST 800-53 assessment, but the control mapping, the assessment scope and the evidence pack have to be built by your team. If you already run Wazuh, or plan to, treat the platform as the source of records, not as the compliance deliverable. Auditors will ask which systems are in scope, which log sources feed the platform, how long records are kept, and how you know nothing was dropped or changed. Wazuh answers some of these questions directly and leaves others to you. The Wazuh dashboard includes prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53. Those views group alerts by the requirement or control they are tagged to, which is a useful starting point for a walkthrough. They are not a finished assessment. A view shows what the rules matched; it does not show that every in-scope system reports, that the rule set is appropriate for your environment, or that a missing alert means nothing happened. Confirm with your assessor which requirements they expect you to evidence from Wazuh and which must come from policies, tickets or other tools. Scope is the first place these projects get harder than they look. A cardholder data environment, a set of systems that store or process protected health information, or a NIST 800-53 system boundary has to be defined before you decide which agents, syslog sources and API probes belong in the Wazuh deployment. Agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX hosts, and agentless collection covers devices such as firewalls through syslog. Each in-scope source you leave out is a gap an assessor can find. Write down the boundary, map each source to it, and record which sources are not yet onboarded. Retention and completeness are the other hard parts. Your retention periods come from the framework and your own policy, and you must confirm them with your assessor and legal or privacy staff rather than copy a default. You also need to show that the indexer holds what the server analyzed, that agents did not silently stop reporting, and that stored alerts have not been altered. Plan for indexer capacity, archive handling and access controls on the stored data, and test a restore before an assessor asks for one. GDPR is covered by the same dashboard family, so a team working under both frameworks can reuse much of the setup. That reuse does not make Wazuh a GDPR compliance solution, and the mapping for personal data processing still needs legal review. DeployOpen plans and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

Which Wazuh components produce compliance evidence

Wazuh produces compliance evidence through four components that each capture, classify, store or present different data. Evidence is only as strong as the weakest link, so each card names what a component can prove on its own and where a control still needs another source or a manual check.

Wazuh agents on endpoints

Agents installed on Linux, Windows, macOS and other supported hosts collect host telemetry, including file integrity monitoring results and software inventory. This is the primary source for host-level evidence such as changes to system files and installed packages. An agent cannot prove that a host is complete, so check agent coverage against your asset inventory and confirm which hosts report in the reporting period an auditor will sample.

Wazuh server decoders and rules

The server parses incoming agent and device data with decoders, then classifies events with rules that assign severity levels and compliance tags. These mappings decide which events appear in each framework view, so they are the part of the stack most likely to need tuning. Review the default rule set against each control you claim, and document any custom rules as part of the evidence trail rather than treating the defaults as proof of coverage.

Wazuh indexer alert storage

The indexer stores alerts and makes them searchable, which gives you a queryable record of events over time. Retention settings determine whether a sample period is still available when an assessor asks for it. The indexer stores what the server passes to it, so it cannot show that a log source was missing. Confirm retention periods against the logging requirements that apply to your environment and test that archived data can be restored.

Wazuh dashboard compliance views

The dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, which group alerts by requirement. These views help assessors and operators navigate evidence quickly. They summarize detections against the rules that feed them and do not certify compliance. Treat each view as a starting point, check that the requirements shown match the version of the standard you are assessed against, and export or record the results with dates.

Agentless syslog collection

Firewalls, switches, load balancers and other devices that cannot run an agent can send syslog to the Wazuh server, which decodes and stores their events. This closes gaps in network-layer logging, such as firewall rule changes and administrative logins. Syslog delivery is usually unacknowledged, so events can be lost in transit. Confirm each device's log forwarding settings, time synchronization and whether the device's own logs are retained locally as a fallback.

Decisions to make before mapping Wazuh to a framework

This table compares five decisions that shape a Wazuh compliance mapping, the options each one offers, when each option fits and what it costs to run. Read each row as a pairing: choose the option that matches your audit scope and staffing, then record the choice before you build rules or dashboards. The main takeaway is that a narrow scope and exported evidence lower ongoing effort, while estate-wide coverage and dashboard-only evidence raise it.

Decision	When it fits	Operational cost
Framework views or requirement map	Prebuilt views fit a small scope and a stable assessor. A documented requirement-to-rule map fits teams with custom rules or a tailored control set.	Prebuilt views need little upkeep but reflect only the vendor's mapping. A custom map needs staff time whenever rules or scope change.
Scope of in-scope systems	A narrow scope, such as cardholder data environment hosts, fits PCI DSS work with a clearly bounded environment. Estate-wide scope fits teams that must show monitoring across all systems.	A narrow scope means fewer agents and less review. Estate-wide scope adds agents, rule tuning and alert triage across more systems.
Agents or agentless collection	Agents fit servers and endpoints that store or process regulated data. Agentless syslog fits network devices, such as firewalls, where an agent cannot run.	Agents need enrollment, upgrades and group configuration. Agentless sources need syslog forwarding and checks that events keep arriving.
Evidence source	Dashboard evidence produced on demand fits infrequent reviews with a small reviewer group. Exported, retained records fit assessments that need a stable, repeatable set.	Dashboard reports cost little to produce. Exports need a protected store, access control and a schedule so records stay unaltered.
Alert retention location	Keeping alerts in the indexer fits active investigation and short look-back needs. Archiving fits longer retention, where the indexer would hold data you rarely query.	Indexer storage grows with event volume and retention. An archive adds storage, restore testing and a process for searching archived alerts.

How to build a Wazuh compliance evidence set in order

This sequence takes a Wazuh deployment from an undefined scope to an evidence set an assessor can follow. Each step ends with a check the team can repeat, so gaps surface before the assessment begins.

Scope requirements and group agents by system
The compliance lead, working with the security team, writes the in-scope requirement list for PCI DSS, HIPAA or NIST 800-53 and names the systems each requirement applies to. Platform engineers then create Wazuh agent groups that match those systems, so a host's scope is visible from its group membership in the dashboard. The step is done when every in-scope system sits in a group and every requirement has a named owner. The check is a count: group membership must match the signed-off asset inventory.
Deploy agents and confirm every host reports
Platform engineers install Wazuh agents on in-scope endpoints and configure agentless collection for devices such as firewalls, which send syslog and can be probed through their APIs. Each agent is enrolled into the group defined in the previous step. The check is a reconciliation: compare the asset inventory for each in-scope group against the agent list on the Wazuh server, and investigate any host or device that is missing or silent. The step is complete when the two lists match.
Confirm decoders parse each log source
Engineers select a sample of log sources for each in-scope group, including agent logs, syslog from agentless devices and any application logs, and confirm the Wazuh server decodes them into fields. Where a source is not decoded, they add a custom decoder before moving on. The check is a trace: pick a known event on the source system, such as a logon or a configuration change, and find the same event in the Wazuh indexer and on a dashboard view. Record one trace per source type in the evidence log.
Review prebuilt framework views against requirements
The compliance lead opens the prebuilt PCI DSS, HIPAA or NIST 800-53 views in the Wazuh dashboard and compares each view's requirements with the list written in the first step. Every requirement is recorded as covered, partly covered or not covered, with the rule or alert group that supports it and a note on what is missing. The check is a coverage count: the three totals must add up to the number of requirements on the list, with no line left unclassified. The views are a starting point and do not decide compliance on their own.
Write and test custom rules for gaps
For each requirement recorded as partly or not covered, the security engineer writes a custom rule or adjusts an existing one, using the decoded fields confirmed in the earlier trace. Each rule is tested against sample events, including one that should fire and one that should stay silent. Rules are kept in version control with the requirement identifier in the rule description, so the link is visible to assessors. The check is a test log showing each rule fired on its positive sample and stayed quiet on its negative sample, followed by an updated coverage count.
Set read-only roles for auditors
The platform owner defines dashboard and API roles so auditors can view alerts, dashboards and exported evidence without changing rules, decoders, agent configuration or users. Where the team uses SAML single sign-on, identity provider groups are mapped to these roles so access follows the directory. The check is a negative test: sign in as an auditor account and attempt a rule edit, an agent group change and a user change. Each attempt should be refused, and the results are filed with the evidence set.
Define the evidence pack and export method
The compliance lead defines what an assessor receives for each requirement: the requirement entry, the rule or dashboard that covers it, sample alerts, agent and device coverage for the review period, and change records for rules and decoders. The platform team agrees how each item is exported, whether as a saved dashboard report, an indexer query output or a scheduled file, and where it is stored. The check is a reproduction test: one engineer produces the full pack for a single requirement, and a second engineer rebuilds it from the written method and gets the same output.
Run a dry-run assessment
The compliance lead walks through the evidence pack as an assessor would, selecting requirements at random and asking for the requirement entry, supporting alerts and change history. Engineers answer from the pack and the platform without running live queries, so gaps appear as questions the pack cannot answer. Each gap is logged with an owner and closed before the formal assessment. The check is a clean walkthrough: every sampled requirement is answered from the pack alone, and the gap log is empty or each open item has a named owner and a due date.

How to turn Wazuh alerts into audit evidence an assessor will accept

Assessors accept evidence they can reproduce. Three forms of output are worth separating. A dashboard view is live: it shows the state of the environment at the moment someone opens it, so it cannot show what happened last quarter. A screenshot freezes that view but records no query, no time range and no person who captured it. A reproducible evidence record is a saved query or report that states its search logic, the time window, the Wazuh rules and agent groups it depends on, the run date and the exported output. Decide which control each record supports before building dashboards, because a dashboard is only a convenient way to run the query behind the record.

The evidence auditors usually request maps to Wazuh sources in predictable places. Authentication and access events come from agent log collection, decoded by the server and stored in the indexer, and support logging requirements such as PCI DSS requirement 10 and the audit controls in HIPAA section 164.312(b). File integrity monitoring produces configuration and file change records for PCI DSS requirement 11.5 and NIST 800-53 CM-3. Software inventory and vulnerability findings come from the vulnerability detection module and support NIST 800-53 RA-5 and SI-2. Alert handling records and rule version history sit partly outside Wazuh: alert status is only as complete as your team records it, and custom rules are best kept in version control. Confirm each mapping with your assessor.

Every evidence record needs three properties before it is useful. First, a stated time window, meaning the start and end timestamps of the query, which must match the audit period the assessor agrees to. Second, a way to show the records were not altered after collection. The Wazuh indexer does not, on its own, prove that stored alerts were never changed, so plan a hash of each exported file recorded in a separate system, and restrict write access to the archive location. Confirm how index and archive access is controlled and logged in your environment. Third, a traceability matrix that links each requirement to the saved query or custom rule that produces its evidence, along with the rule identifier and the rule version in force during the period.

The assessor makes the final judgment on whether evidence satisfies a requirement, and that decision depends on the scope and sampling they apply. DeployOpen prepares the evidence: it configures the queries and reports, builds the traceability matrix, documents the collection procedure and tests that exports reproduce. DeployOpen does not attest to compliance and does not issue audit reports or certifications. Before implementation, ask your assessor to review a sample export and the matrix layout, and agree in writing the audit period, the export format and how long raw alert data is kept. Those agreements shape the scope and effort of the work more than any dashboard choice.

What drives effort in a Wazuh PCI DSS, HIPAA or NIST 800-53 project

This table lists the main factors that change the effort and cost of a Wazuh compliance project, who usually carries each piece of work, and whether it is paid once or recurs. Use it to see which drivers apply to your environment and where narrowing scope will pay off before you request a written quote.

Driver	Why it changes effort	Who does the work	One-time or recurring	How to keep it down
In-scope systems and diversity	Each Linux, Windows, macOS, network device or other asset in scope needs an agent or agentless collection, configuration checks and evidence mapping. Mixed fleets add platform-specific rules and testing.	DeployOpen and your infrastructure team, with your asset owners confirming what is in scope	One-time for onboarding, recurring as systems are added	Define the cardholder, protected health or regulated data boundary first, then use agent groups and network segmentation to keep out-of-scope systems off the evidence path
Log sources needing decoders	Firewalls, load balancers, databases, SaaS audit feeds and custom applications each need a decoder and field mapping before their events support a requirement. Vendor log formats vary by version.	DeployOpen builds decoders; your application owners supply sample logs and confirm meaning	One-time per source, plus recurring work when log formats change	Inventory log sources against each requirement and onboard only those that produce required evidence; retire duplicate feeds
Uncovered requirements needing custom rules	Prebuilt framework views do not cover every sub-requirement in full. Each gap needs a custom rule, test event and documented rationale for the assessor.	DeployOpen writes and tests rules; your compliance lead approves the control mapping	One-time build, recurring tuning after upgrades	Map the framework requirements to your controls early, accept existing coverage where it is sufficient, and limit custom rules to documented gaps
Identity integration with your directory	Connecting the dashboard to your directory with SAML, and mapping groups to administrator and read-only roles, needs IdP configuration, role design and access review evidence.	Your identity team owns the IdP side; DeployOpen configures the Wazuh side	One-time setup, recurring access reviews	Reuse existing directory groups and avoid per-user local accounts so access reviews run from one source
Retention and archive requirements	Each framework sets retention periods for audit logs. Longer retention increases indexer storage, backup scope and archive procedures that must be tested for restore.	Your infrastructure team sizes storage; DeployOpen configures retention and archive jobs	Initial sizing one-time, storage cost recurring	Confirm the retention period for each log class with your assessor, then split hot and archived data so only what is needed stays searchable
Number of environments	Test, production and disaster recovery environments each need deployed components, configuration management, and evidence that the non-production copies do not hold live regulated data.	DeployOpen and your platform team; hosting cost is paid to your cloud or data center provider	Build once, recurring for hosting and parity upkeep	Keep test data synthetic, automate environment builds from one configuration source, and size disaster recovery to the recovery targets you have agreed
Evidence the assessor expects in advance	Assessors may ask for sample reports, rule test results, configuration baselines and sign-off records before fieldwork. Preparing these in advance adds documentation and dry-run effort.	Your compliance lead and assessor agree the list; DeployOpen prepares the Wazuh outputs	One-time for the first assessment, recurring for each assessment cycle	Agree the evidence list with the assessor before build starts, and generate recurring reports from the dashboard instead of assembling them by hand

How the compliance approach changes by deployment model

A single all-in-one installation is useful for rehearsing how Wazuh rules and dashboards map to PCI DSS, HIPAA and NIST 800-53 requirements before anything touches production. The evidence it produces is valuable for practice, but it should not be presented to an assessor as the production record.

Mapping practice: Walk through the framework dashboard views with a few test agents and confirm which alerts appear under which requirement.
Sample data only: Test endpoints and synthetic events show the layout of evidence, but they do not reflect the volume or variety of production logs.
Informal retention: Retention and access settings are often relaxed in a test build, so they must be rebuilt and checked before go-live.
Documentation trial: Draft control narratives and screenshot procedures here so the production team can repeat them exactly.

Check that every mapping rehearsed in this environment is re-verified against production data sources, because a test environment cannot show that production agents are reporting.

Access control and integrity controls for compliance evidence

Compliance output is only as credible as the controls around it. Assessors will ask who can read, change or delete the rules, decoders, alerts and exported reports that support your PCI DSS, HIPAA or NIST 800-53 position. The cards below cover the controls specific to compliance evidence. Platform-wide settings such as certificates, API restrictions and SSO are covered in the hardening and SSO topics.

Separate auditor and administrator roles

Give auditors and reviewers a read-only role in the Wazuh dashboard, and keep administrator rights with a small named group that operates the platform. Auditors need to view compliance dashboards, rule matches and alert history without the ability to change agents, rules or retention. Check that the read-only role cannot open configuration pages or run write API calls, and test it by logging in as an auditor account before each assessment. Role mapping from your identity provider is covered in the SSO topic.

Restrict changes to rules, decoders and agent groups

Rules, decoders and agent group membership decide what gets detected and which agents receive which configuration, so changes to them are control changes. Limit write access to these objects to named engineers, and require a second person to approve each change before it reaches production. Record who changed what and when, and confirm that the audit trail for these changes is kept outside the accounts that make them. Assessors often ask for this trail when they test change management.

Version control rule and configuration files

Keep custom rules, decoders, configuration sections, agent group files and integration settings in a version control repository. Each change should go through a reviewed pull request or merge request that links to a ticket explaining the reason. Tag the state deployed at each assessment period so you can show what was in force on a given date. Confirm that the repository has branch protection and restricted push rights, since an unprotected repository weakens the review step.

Protect exported evidence and its hashes

Reports, alert exports and screenshots prepared for an assessment should be stored in a location with restricted write access and recorded hashes. Generate a checksum when each export is created, store the checksum separately from the file, and record who produced it. When an auditor asks whether a report was altered, you can recompute the hash and compare it with the record. Confirm that retention and access rules for evidence folders match the sensitivity of the logs they contain.

Control deletion and change of indexed alerts

Alerts stored in the Wazuh indexer are the primary record for many log review and retention requirements, so deleting or editing them should be rare and visible. Restrict index deletion and index-level write permissions to a small administrative role, and keep dashboard user accounts out of that role. Apply retention through a documented policy, and allow manual cleanup only under a logged change. Test that a deletion attempt by a read-only user fails and that the attempt appears in the logs.

Keep log source credentials out of rule files

Agentless collection and API probing need credentials for firewalls, cloud services and other log sources. Store those secrets in a dedicated secrets mechanism with restricted read access, and keep them out of decoders, rule files and committed configuration. Scan the version control history for embedded passwords and tokens before the first assessment, and rotate any value you find. Check the platform-level handling of credentials against the hardening topic.

How to verify the Wazuh compliance mapping works and fails safely

The fastest way to trust a compliance mapping is to test it with events you created yourself. On a test agent, generate a small set of known events: failed SSH or Windows logons, a change to a file under a path covered by file integrity monitoring, and a connection blocked by a firewall whose logs reach Wazuh through syslog. For each event, write down the expected rule ID and alert level from the ruleset in your exact version, along with the framework controls it should map to in PCI DSS, HIPAA or NIST 800-53. Then trace each event through the pipeline. Confirm the alert exists in the Wazuh indexer, that it matched the expected rule, and that it appears under the correct framework view with the control reference you expected. Store the expected results in a written test script so that a reviewer can repeat the run and compare outcomes.

A mapping that pulls in too much is as unreliable as one that misses events, and assessors will ask whether systems outside the cardholder data environment or the ePHI boundary appear in scoped views. Place a test host outside the defined scope, generate the same events on it, and confirm that its alerts stay out of the in-scope views. Check every filter that defines scope, including agent groups, tags, saved searches and dashboard filters. Then move a test host into scope and confirm it starts appearing, and move it out and confirm it disappears. Record the group membership at the time of each test. Scope evidence is only as strong as the membership record it reflects, so keep the membership history alongside the test results.

The failure that matters most is silence. An agent that stops reporting, a firewall that stops sending syslog, or a decoder that no longer matches after a log format change will produce no alerts, and an empty dashboard looks identical to a clean environment. Test this directly. Stop the agent service on a test host, or block its path to the Wazuh server, and confirm that the agent shows as disconnected in the in-scope view or that a monitoring alert fires. Pause forwarding from a test log source and confirm the same. Decide before testing what a gap must look like in your environment: a generated alert, a visible status on the compliance view, or a ticket raised by your monitoring. Without that decision, the mapping fails without anyone noticing.

Re-run the full test script after each Wazuh patch release on your line and before any move to a new minor version. Patch releases can change decoders, rule logic or dashboard definitions, and custom rules written against an older ruleset may stop matching without any error. Compare each run against the previous baseline and investigate any change in rule ID, alert level or framework mapping. Run the re-test in staging first. A private cyber range is well suited to this work because it can host the full test set, including the negative and silent-source cases, using synthetic hosts and no production data. Confirm with your implementation partner whether the re-run is part of the support scope, who reviews the results, and how the evidence is stored.

What to review each month after the compliance build goes live

Monthly review keeps the Wazuh compliance build aligned with the environment it monitors as agents, rules, patches, accounts and scope change. The routine ends with four documents current: the requirement-to-rule map, the scope statement, the change log and the evidence index. Because these controls recur, the schedule itself should be documented and owned by a named person.

Confirm agent and log source coverage
Compare the agents reporting to the Wazuh server and the log sources arriving at the indexer with the in-scope asset list in your scope statement. The compliance owner or a security engineer chases any source that has gone silent, confirms its cause and records the owner and restoration date. Check that every in-scope system either reports or has a documented exception with an approver. The step closes when the coverage record shows no unexplained gaps.
Check framework views for unmapped alerts
After any rule update, open the PCI DSS, HIPAA and NIST 800-53 views in the Wazuh dashboard and look for alerts that fire without a requirement mapping. Assign each one to an existing requirement, or add it to the requirement-to-rule map as a gap with an owner. Use the release notes for each patch to see which rules changed, so the review targets the right alerts. The step closes when no alert in the views is unmapped and every open gap has a named owner.
Record patches and rerun verification tests
For every 4.14 patch applied, log the release version, the date it was applied, the components changed and the approver in the change log. Then rerun the verification tests for custom rules, decoders and framework mappings to confirm they still fire and still map to the right requirements. Record the test results next to the change entry. The step closes when the change log entry and the test output are both filed for each patch.
Review access roles and remove stale accounts
Compare the dashboard and API user list, along with each user's roles and group memberships, against the current staff and service account register. Remove or disable accounts that no longer have an owner or a business need, and revoke roles that are no longer used. If SAML single sign-on is in place, review the identity provider group mappings to administrator and read-only roles as well. The step closes when the access review record lists each change and its approver.
Verify evidence packs are complete and hashed
Confirm that each evidence pack exported during the period contains the reports listed for it, has a recorded hash, and sits in the storage location named in the evidence index. Recompute the hash for a sample of packs to confirm the stored files have not changed. Note any missing pack and the reason it is missing. The step closes when the evidence index lists every pack with its hash and no pack is unaccounted for.
Update the map when scope changes
When in-scope systems, data flows, business units or hosting locations change, update the scope statement first, then the requirement-to-rule map so each affected requirement reflects the new environment. Record the change, its reason and its approver in the change log. Confirm the evidence index still points to the right sources. The step closes when the map and scope statement match the current environment and the change log has a matching entry.

Questions teams ask before building Wazuh compliance evidence

Can we use Wazuh for PCI DSS, HIPAA or NIST 800-53 without a partner?

Yes. The self-hosted software is open source with no license fee, and the Wazuh dashboard includes prebuilt views for PCI DSS, HIPAA and NIST 800-53, so an internal team can start without a partner.

What you still own: deciding which controls apply to your environment, mapping each control to the Wazuh agents, decoders, rules and configuration that produce its evidence, and collecting records an assessor will accept. The dashboard groups alerts by framework requirement, but it does not decide whether a requirement is met. Teams new to assessments often underestimate the documentation side: scope statements, system owner sign-off, change records and evidence retention. Confirm your assessor's expectations before you start, because they set the bar the evidence must meet.

What drives the cost of building Wazuh compliance evidence?

Most of the cost is people time and infrastructure. Your staff time covers the compliance lead, system owners and identity and network staff. The infrastructure covers the indexer, server, dashboard and the storage needed to retain logs for the required period. If you hire outside help, that is a separate fee paid for the work in the written scope.

One-time work includes scoping, control mapping, rule tuning and writing evidence procedures. Recurring work includes agent maintenance, upgrades, log storage growth, periodic access and configuration reviews, and the assessor's fees, which go to the assessor and not to a platform vendor.

The main drivers are the number of in-scope systems, how many frameworks overlap, how many custom log sources need decoders, and how well logging is already set up. In a quote, ask for an itemized scope, deliverables, assumptions, exclusions and a clear statement of who maintains each component after handover.

How long does a Wazuh compliance evidence project take?

No duration is given here. The written scope sets the timeline, and DeployOpen engagements are normally fixed scope, with scope, deliverables and timelines agreed in writing before work starts.

The main factors are the number of frameworks in play, how many systems and data flows are in scope, whether Wazuh agents are already deployed, how many log sources need custom decoders or rules, and how many control owners must be interviewed and must sign off. Approval cycles and change freezes often add more time than the technical work. If you have an assessment date, confirm whether it fixes the evidence period you must cover.

Ask for milestones with the work each one produces, the internal decisions each one depends on, and the point at which evidence is considered complete for your assessor.

What does our internal team need to provide for this work?

The work needs named people from several teams, and their availability should be confirmed in the written scope.

Compliance lead: owns scope decisions, control interpretation and sign-off on the control matrix. System owners: confirm which hosts, applications and data stores are in scope and provide their change records. Identity staff: supply user and group lists, multi-factor authentication details, administrator roles and, if you use single sign-on, the identity provider configuration. Network staff: provide segmentation details, firewall and syslog sources, and time synchronization settings. Platform and security engineers: grant access to hosts and cloud accounts for agent deployment and configuration.

Without these inputs, rule mapping and evidence collection stall, so plan for each group to review drafts in good time.

Can our own team build Wazuh compliance evidence without outside help?

Yes, if you have engineers who can run Wazuh, a compliance lead who knows the frameworks, and enough capacity for both. Many teams start with one framework and one set of systems as a pilot before expanding.

The usual risks are gaps in control mapping, rules that were never tested against real events, evidence that cannot be reproduced on request, and knowledge that leaves with a single engineer. Check whether your team can answer these questions: which Wazuh rule or configuration proves each control, how you would show that a log source stayed healthy for the whole audit period, how changes to rules are recorded, and who reviews access to the dashboard.

If the answers are unclear, a narrower outside review of the control matrix and evidence procedures may be a better fit than a full build.

Can DeployOpen get our Wazuh platform assessed for PCI DSS, HIPAA or NIST 800-53?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body makes the assessment decision.

What DeployOpen can prepare includes the Wazuh configuration, the mapping from each in-scope requirement to the platform's output, documented evidence collection procedures, and the records an assessor will ask to see. The assessor then tests that evidence against their own method.

Before you start, confirm with your assessor which evidence format they expect, how many samples they will review, and whether the framework you are working toward uses a formal attestation or another route. Those answers should shape the scope agreed in writing.

Does Wazuh Cloud remove the compliance mapping and evidence work?

No. Wazuh Cloud is the vendor's managed, cloud-delivered XDR and SIEM service, so it can reduce the work of hosting and operating the platform. It does not remove the responsibility to map controls, define scope, set retention periods, run access reviews and produce evidence for your assessor.

Before you decide, ask the vendor which components it operates, which configuration remains yours, what log sources you can connect, and how you export evidence and retention records. Wazuh Cloud is sold in Small, Medium, Large and Custom tiers, and every paid plan includes at least Standard support. The vendor offers a 14-day free trial that needs no credit card, which is a practical way to test the console before choosing.

Whether the managed service or a self-hosted deployment fits better depends on your data residency, operating model and staffing.

How DeployOpen scopes, builds and hands over Wazuh compliance evidence

DeployOpen plans, implements and documents self-hosted Wazuh inside your own cloud accounts, data centers or air-gapped networks. For PCI DSS, HIPAA and NIST 800-53 work, we prepare the Wazuh systems, controls and evidence that your assessor will review. We do not issue audit reports or attestations, which remain the role of independent auditors and certification bodies.

How we scope

The written scope names the Wazuh components, agent counts, platforms and the framework requirements in play.
We map which PCI DSS, HIPAA or NIST 800-53 controls Wazuh outputs can support, and which stay with you.
Work is fixed-scope, with deliverables agreed in writing before start; ongoing support runs as a retainer.

How we build

Wazuh is deployed in your infrastructure, using the installation method your environment allows, including offline installs.
Prebuilt PCI DSS, HIPAA and NIST 800-53 dashboard views are configured, then checked against the scoped controls.
Custom rules, decoders and alert settings are documented and tested against sample logs before they reach production.

How we hand over

Handover includes configuration records, rule and decoder inventories, and a control-to-evidence map for the scoped requirements.
Evidence procedures explain how your staff export alerts, agent inventories and configuration state for each assessment period.
Runbooks cover indexer, server, dashboard and agent operations, so your team can run the platform after go-live.

How we support

Retainers can cover upgrades across the Wazuh indexer, server, dashboard and agents, with custom rules retested afterward.
Support can include reviewing evidence exports before each assessment, so gaps surface while there is time to fix them.
Scope for ongoing work is agreed in writing, and the support terms define what is covered.