Wazuh for SOC 2 system monitoring

CC7.1 asks the organization to run detection and monitoring procedures that find two things: configuration changes that introduce new vulnerabilities, and exposure to vulnerabilities that were newly discovered after a system was deployed. In a SOC 2 examination, the service auditor will test whether these procedures exist, whether they run, and whether someone acts on what they find. Wazuh can supply much of the technical evidence for this, but the criterion is about your monitoring design, so the first decision is what you will monitor and against which standard.

The points of focus under CC7.1 cover defined configuration standards, monitoring of infrastructure and software, change-detection mechanisms, detection of unknown or unauthorized components, and vulnerability scans. Wazuh addresses the technical side through its agents, which collect the software inventory on each endpoint, and through its configuration assessment and file integrity monitoring capabilities. Confirm the exact modules and their current behavior against the Wazuh vulnerability detection and configuration documentation for your release line before you write them into the control description.

Configuration baselines and change-detection settings are your standards, not Wazuh's. Wazuh can compare a host against a benchmark or a policy file, and it can alert when monitored files or registry keys change. It cannot decide which settings are correct for your environment. Before deployment, your security or platform team should document the baseline for each system class, the paths and settings to watch, who approves a deviation, and how exceptions are recorded. Auditors will look for these standards as written artifacts, and they will check that the Wazuh configuration matches them. A mismatch between the documented standard and the deployed rules is a common finding.

Vulnerability detection correlates the software inventory that agents collect with vulnerability data. That data comes from the Wazuh Cyber Threat Intelligence platform or from an offline vulnerability repository that you host. The choice depends on your network constraints. If your managed hosts and the Wazuh server can reach the online feed, the CTI platform requires less maintenance. If the environment is air-gapped or restricted by egress policy, you must plan the offline repository, its update process, and the evidence that the data is current. Confirm the offline update procedure in the Wazuh offline installation guide before you commit to either path, and record the decision, because the auditor will ask where the vulnerability data came from and how often it was refreshed.

CC7.2 requires you to monitor system components and their operation for anomalies that indicate malicious acts, natural disasters or errors, and to analyze those anomalies to decide whether they are security events. Wazuh does not make that decision on its own. The Wazuh server applies decoders to parse agent and log data and rules to decide which events matter, so the detection quality an auditor sees is the quality of the rules and filters you configure for your environment. Default rules are a starting point. They are not evidence that anomalies in your systems are being caught.

The points of focus under CC7.2 map closely to the Wazuh work. Your detection policy should state which system components are in scope and what counts as an anomaly for each. Your detection measures should then be designed around those anomalies, such as failed administrative logins on servers holding customer data, unexpected changes to service accounts, or agents that stop reporting. Filters decide which events are analyzed and which are suppressed, and suppression rules need the same review as detection rules because an overly broad filter can hide the anomaly you were meant to catch.

Tuning means adapting Wazuh decoders and rules to your log formats, asset roles and normal activity. Start by inventorying the log sources and agents in scope, then confirm that decoders parse each source correctly on sample events. Next, review the rules that fire most often and the rules that never fire, and document why each change was made. Test changes against known benign and known suspicious events before you rely on them. Ask your implementation partner or internal team to show this test record, because it is what lets you explain detection effectiveness later.

The detection tools themselves also fall under CC7.2, through the points of focus on monitoring the tools for effective operation. Decide how you will confirm the pipeline is running: agents reporting to the server, the server processing events, the indexer storing alerts and the dashboard showing recent data. Set alerts for gaps in agent check-ins and for indexer or server failures, and record who receives them. A monitoring gap that goes unnoticed for weeks is a finding in itself, even when the rules are well written.

Document three things for every monitored component: what you monitor, why it matters to your system and commitments, and how you confirm the pipeline is still working. Keep the rule change history, the filter justifications and the periodic health checks together so they can be sampled during a Type 1 or Type 2 examination. Confirm with your SOC 2 auditor which evidence format and sampling period they expect, since those details depend on the engagement.

CC7.3 asks the organization to evaluate security events and decide whether each one could cause, or has caused, a failure to meet its objectives. If it could, the organization must act to prevent or address that failure. Wazuh supplies the input to this step, not the step itself. Its alerts, raised by rules and correlated across agents, show what the platform saw. Deciding whether an alert is a security event, whether it matters to the system's commitments, and what happens next are organizational judgments that the auditor will test separately.

In practice, the Wazuh dashboard and alert queue are where triage begins, but the classification scheme, severity definitions, escalation paths and closure criteria belong to your security operations team and its documented procedures. Those procedures should name who may reclassify an alert, who approves closing an event as not a security event, and when an event moves into incident handling. A rule that fires often is not a finding until someone has decided what it means for the objectives in your system description. Keep the tuning of rules separate from the evaluation decisions, and record any change to rule logic that alters what reaches the queue.

A defensible record of an evaluation shows the event, the evidence reviewed, the classification and the reasoning, the person who made the decision, the date, and the outcome. For an event that was escalated, it links to the incident ticket, the containment or corrective action, and the verification that the action worked. Export the relevant Wazuh alert identifiers, timestamps and affected agents into that record so the decision can be traced back to the source data. Records of events judged to be non-security are just as important, because an auditor may sample them to test whether the process is applied consistently.

Confirm with your auditor which events and records they will examine before you design the workflow. Ask whether they will sample from all alerts, only from escalated events, or from a population defined by your own procedures, and what period the sample covers. Ask how they expect to see the decision record, for example as a ticket, a signed review or an exported report, and whether they need evidence that reviewers were trained. Those answers determine which fields your records must carry and how long they must be kept, which is an organizational decision rather than a default setting in Wazuh.