Wazuh Security Configuration Assessment

A custom Wazuh SCA policy is a statement of what your organization considers an acceptable endpoint configuration, written in a form the agent can test. Before any YAML is written, the owner of the baseline should decide which controls the policy claims to implement, which systems it applies to, and who signs off when the baseline changes. The file itself is the easy part. The harder decision is whether the checks faithfully express the baseline your security and compliance teams have approved, because a policy that passes on machines that do not meet that baseline gives false assurance.

The YAML structure has three layers that matter to the reader. The policy metadata identifies the policy, its version and the platforms it targets. Requirements define the conditions under which the policy runs, such as the presence of a file or package, so that the policy skips systems where it does not apply. Checks are the individual tests, and each one can inspect a file's contents or permissions, a registry value on Windows, a running process, or the output of a command on the endpoint. Map each internal baseline control to one check with a stable identifier and a title that an auditor can read without opening the policy. Keep each check to one assertion where possible, and add a description that states the intended setting, not only the command. Confirm the exact keys, supported condition types and result semantics against the Wazuh documentation for the client's version, since these details change between releases.

Most failure modes come from assumptions about the endpoint. A check that reads a path or runs a command written for one distribution can report a pass or fail on a system where the path differs, or where the command is absent. Checks that read a missing file can produce no result at all, which looks like compliance if nobody reviews skipped or unevaluated items. Test each check on representative endpoints across the operating systems and versions you run, including one where the target file is intentionally absent, and confirm how the result is reported. Policies also drift: a control is revised in the baseline document, but the YAML is not updated, or a fix is applied to the policy without a matching change to the approved control text. Store the policy in version control next to the baseline mapping and review both together.

Before a wide rollout, deploy the policy to a non-production endpoint group that mirrors the production operating system mix, and compare results against a manual check or a trusted configuration script for the same controls. Look at both the failures and the unexpected passes. Record the test results as part of the change record. Ask your implementation partner, and your own team, to show how a policy change moves from a proposal through review, testing and release, and who can approve a change to a control's intent. Confirm that the agent version and the Wazuh server version in your environment support the policy features you use.

Writing a custom policy is a decision about the organization's baseline, not only a technical task. Choosing which controls to include, how strictly to interpret a setting, which exceptions are acceptable and how long they last are governance choices that security, IT operations and compliance leads should own. The technical team turns those decisions into checks and keeps them accurate over time. When the CIS-based default policies do not match your approved baseline, the gap should be documented and resolved by the baseline owner, not hidden inside a custom file that nobody else can read.

An SCA result is a record of what a check found on one endpoint at one moment. It is not a finding that the organization is compliant, and it is not a decision about what to do next. Auditors look for the chain that connects the two: a named control, the check that tests it, the evidence showing the result, and a documented decision for every failure. Build that chain before the first scan goes into a report, because reconstructing it after an assessment starts is slow and often incomplete. Start by mapping each policy check to a control in the framework or internal standard you are assessed against. The Wazuh SCA policies are based on CIS benchmark recommendations, so the check titles and IDs do not map one to one onto control IDs in PCI DSS, GDPR, HIPAA or NIST 800-53. Keep the mapping in a version-controlled table with the policy file name, the check ID, the control ID and the mapping owner. Where one check supports several controls, record all of them. Where a control needs evidence that no SCA check provides, say so in the table rather than leaving a gap that looks covered. Retain results in a form that carries its own context. Each exported record should include the scan date and time, the endpoint identifier and hostname, the agent ID, the policy name and version, and the result for each check. Confirm with your Wazuh team which fields the dashboard export and the indexer API return in your release, and test one export against a known endpoint before relying on it. Store the exports in a location with its own retention period and access controls, and keep a copy of the policy files used for each scan, since a result is only interpretable against the policy that produced it. A failing check is an input to a decision, not the decision itself. For each failure, the organization chooses one of three paths: remediate the setting, accept the risk with a documented rationale, or exclude the check because it does not apply to that system. Record the chosen path, the approver and the reason. Exceptions need an owner, a compensating control where one exists, and a review date that forces the question to be asked again. Auditors tend to test exceptions closely, so an exception with no review date or an owner who has left the organization is a common finding. The Wazuh dashboard includes prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53, which can speed up the first review of results. Treat those views as a starting point and confirm how each one maps SCA results to the framework requirements in your version. DeployOpen can plan the mapping, prepare the evidence set and document the exception process for your environment. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

After go-live, Security Configuration Assessment stops being a project and becomes a recurring schedule of reviews. The first decision is scan frequency per endpoint group. Set the SCA scan interval through the agent group configuration that the Wazuh server pushes to agents, not host by host. Base each group's frequency on two factors: how often the host's configuration changes and how much damage a drift would cause. Domain controllers, bastion hosts and internet-facing servers usually justify more frequent scans than stable build hosts. Confirm the interval options and their defaults in the documentation for the version you run before you publish the schedule.

Once scans run, the operational load shifts to the results. Review checks that fail on a large share of hosts and sort them into two groups. Some failures point to a baseline that does not fit your environment, such as a service your platform team requires. Others point to real drift. Only the first group should lead to policy changes. Keep every change to a custom YAML policy under version control with a written reason, and retire checks that no longer match the approved baseline in the same way. Renew each documented exception on a fixed review date so that accepted failures do not quietly become permanent.

Operating system releases and Wazuh agent upgrades can change check results without any change to your hosts. A new OS release may alter a file path, a default setting or a service name that a check reads. An agent or server upgrade may change how SCA evaluates a check. Test every agent and server update against your full policy set on a pilot group that matches your production mix before wide rollout. Compare pass and fail results on the same hosts before and after the change, and treat unexplained movement as a defect in the policy until someone proves otherwise.

Wazuh publishes 4.14 patch releases in its release notes, with dated releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026. Each release may change SCA behavior, so do not assume that a patch is neutral. For every release you adopt, read the notes, confirm which SCA behavior changed and record the result of your pilot comparison. Ask your Wazuh contact or support channel to confirm any change that the notes do not describe clearly. Keep this record with your evidence so that an auditor can see why a result moved between two assessment periods.

The one-time work covers policy design, the pilot, baseline sign-off and the scheduling model for each endpoint group. The recurring work covers periodic review of noisy and retired checks, schedule changes as systems change, exception renewal and regression testing for each OS release or agent upgrade. When you request a quote from DeployOpen or any other partner, ask for the one-time and recurring effort separately, and ask which upgrade tests and exception reviews are included in each. A quote that lists only the initial build leaves the ongoing work unpriced.