SOC 2 logging and monitoring requirements, what auditors test

What SOC 2 requires for logging and monitoring

If a customer or contract now asks for SOC 2, the short answer for logging is this: CC7.2 expects you to monitor system components for anomalies that indicate malicious acts, natural disasters or errors, and CC7.3 expects you to evaluate security events to decide whether they could cause or have caused a failure to meet your objectives. The criteria set no log retention number. Your job is to define what you collect, how anomalies are detected and triaged, and how long you keep the records, then show the auditor that those steps run as designed. The organization owns these controls. A partner such as DeployOpen can prepare the logging pipeline, detection rules and evidence, but only an independent CPA firm examines the controls and issues the report.

The right answer depends on three things. The first is system scope: the auditor will look at the components inside the boundary you describe, so a log source left out of the description is a gap nobody will ask about until it causes an incident. The second is the service commitments you make to customers, which shape how long you must keep records to investigate disputes and how quickly you must detect problems. The third is the auditor's judgment, since CC7.2 and CC7.3 use the words the auditor will test against. Ask your CPA firm early which retention period and alert workflow they expect to see, and write those expectations into your policy so the control matches what you can prove.

For retention, use reference points rather than guesses. NIST SP 800-92 Rev. 1, in its initial public draft from October 2023, offers a planning playbook covering generation, transmission, storage, access and disposal of log data. For US federal agencies, OMB memorandum M-21-31 sets 12 months in active storage and 18 months in cold storage for many log categories, and CISA advisory AA22-131A recommends keeping the most important logs for at least six months and using a segregated logging regime such as a SIEM. These are benchmarks, not SOC 2 requirements, so confirm with your auditor which period fits your commitments. On open-source tooling, Wazuh agents forward endpoint and application logs to a Wazuh server for decoding and rule matching, and OpenSearch Index State Management can roll indices over, make them read-only, snapshot them and delete them after a set number of days, which turns your retention decision into a configured, testable policy.

Evaluating security events under CC7.3

CC7.2 produces alerts, but CC7.3 asks what happened next: whether each security event could cause or has caused a failure to meet the organization's objectives. The cards below follow that path from triage to closure, and show how the records auditors sample connect back to monitoring under CC4.1.

Triage and initial classification

Every alert or anomaly that CC7.2 surfaces needs a documented first decision: is it a security event, a benign operational error, or noise to tune out. Write the triage criteria down, including who may close an alert without review and what must be recorded when they do. Auditors look for a consistent rule applied to real alerts, not a queue that is quietly emptied. In a Wazuh deployment, confirm which rule levels route to a human and which are suppressed, and keep the tuning changes under change control.

Deciding whether an event is a security incident

CC7.3 asks the organization to evaluate whether an event could cause, or has caused, a failure to meet its objectives. That evaluation is a decision, so record the facts considered, the affected systems and data, the objective at risk, and the person who made the call. A closed-as-no-impact ticket with no reasoning is weak evidence. Define the criteria in the incident response procedure before the first event occurs, so the decision is not improvised under pressure.

Escalation and response actions

When an event is judged to be an incident, the record should show who was notified, when, and which containment or remediation steps followed. Escalation paths should name roles rather than individuals, and should include on-call contacts and the customer notification obligations written into contracts. Check that the actions taken are traceable to the incident ticket and to the logs that show the activity, so an auditor can follow one event from detection through response.

Resolution, root cause and lessons learned

Closure should state what was fixed, whether the root cause was addressed, and whether any control needs to change. Feed the findings back into detection rules, access settings or change management so the same gap does not recur. Auditors commonly sample closed incidents to see whether corrective actions were completed and verified, so record the verification step, not only the ticket status.

Linking evaluation to CC4.1 monitoring

CC4.1 asks the organization to run ongoing or separate evaluations confirming that internal control components are present and functioning. Use those evaluations to test the CC7.2 and CC7.3 process itself, for example by sampling alerts to confirm they were triaged, or by reviewing whether incidents were closed on time. Document the review, the reviewer, and any deficiency found and how it was corrected. This is what turns a working alert queue into evidence of monitoring.

Records an auditor samples

Expect the auditor to select a sample of security events across the examination period and ask for the full trail: the original alert or log entry, the triage note, the incident decision, escalation evidence, and closure with corrective actions. Keep these records in a system with access controls and retention that match the policy. Confirm with your auditor how many events they will sample and over which period, since that determines how much the ticketing and log tooling must retain.

How long to keep logs when SOC 2 sets no number

The SOC 2 criteria do not specify how long logs must be kept. An auditor will not compare your retention period against a figure in the Trust Services Criteria. Instead, the organization sets a retention period in its logging or monitoring policy, applies it consistently across systems, and then the auditor tests whether you followed your own rule across the observation period. The practical decision is therefore a policy choice you must be able to defend: which log sources you keep, for how long in searchable storage, how long in archive, and who approves exceptions. Write that decision down before the Type 1 date, because a retention period that exists only in someone's head is a common source of exceptions in a Type 2 report.

Three public references are useful when you set the number, but none of them is a SOC 2 requirement. NIST SP 800-92 Rev. 1, in its initial public draft from October 2023, is a planning guide that covers generating, transmitting, storing, accessing and disposing of log data, including meeting retention requirements. For US federal agencies, OMB memorandum M-21-31 (August 27, 2021) sets retention for many log categories at 12 months in active storage and 18 months in cold storage. CISA advisory AA22-131A recommends keeping the most important logs for at least six months and using a segregated logging regime such as a SIEM. Confirm the current status of the NIST draft with NIST before citing it as final, and treat the federal figures as a benchmark rather than a rule for a commercial service organization.

Customer contracts, regulators and your own incident response needs often ask for more than the policy minimum. Before you finalize the number, ask customers and your legal counsel whether any agreement or regulation sets a longer period, and check whether your cloud or hosting provider keeps its own logs and for how long. In a self-hosted platform, the retention settings live in the tools themselves, for example index lifecycle policies in OpenSearch Index State Management that roll over, freeze and delete indices after a set number of days, or the storage settings on the Wazuh server. Document each setting, test that deletion happens as configured, and keep the configuration under change control so the auditor can see that the period you wrote down is the period the system enforces.

Running monitoring on Wazuh or OpenSearch

Wazuh's agent runs on monitored endpoints and collects system and application logs, then forwards them to the Wazuh server. The server can also receive events over syslog or through third-party API integrations, which matters for network devices, cloud services and SaaS applications that cannot host an agent. Once events arrive, the server analyzes them in three stages: pre-decoding, which tags the event's source and format, decoding, which extracts named fields, and rule matching, which compares those fields against detection rules and raises alerts when a rule fires. For CC7.2, the rule set and its tuning are the detection tools an assessor will ask about, so the organization needs to show which sources feed the server and which rules are active.

Agent coverage: Record which hosts run the agent, who approves new installs, and how removed hosts are detected.
Syslog and API feeds: Document each non-agent source, its transport and the owner who fixes it when it stops sending.
Decoders and rules: Keep the active rule set under version control so a change to a detection can be traced to an approved ticket.
Alert handling: Route rule matches into the incident process so that CC7.3 evaluations have a record of what was reviewed and why.
Licensing and features: Wazuh is licensed under GPL-2.0-only. Confirm current agent, server and integration capabilities in the Wazuh documentation before designing around them.

Check that every log source named in your system description appears in the Wazuh configuration, and that a silent source produces an alert rather than going unnoticed.

How logging moves from design to audit evidence

This sequence turns logging from a set of tools into a documented, tested control that produces records an independent auditor can sample across the examination period. Each step leaves an artifact that shows the control was designed, deployed and operating.

Define log sources and scope
The organization lists every system component in the SOC 2 boundary that generates security-relevant events, including identity providers, cloud control planes, production servers, endpoints, databases and the monitoring tools themselves. Security and platform engineering agree the list with the system description, and the owner of each source is named. The step is complete when the log source inventory is approved and matches the scope the auditor will test.
Set the log retention policy
Compliance and security leads write a retention policy that states how long each log category stays in active and archive storage and when it is deleted. CC7.2 does not set a number, so the policy should rest on the organization's own risk assessment, customer commitments and any regulation it must follow. Reference points from NIST SP 800-92 Rev. 1 (initial public draft) and the OMB and CISA retention figures can inform the decision. The step closes when the approved policy is published and the owner has signed it.
Deploy collection and alerting
Engineers install log collection agents or configure forwarding from each source into a central platform such as a self-hosted Wazuh server or an OpenSearch cluster, and enable the alert rules that the detection design calls for. Configuration is kept in version-controlled files so that changes can be traced. The step is done when a test event from each source appears in the central platform and a test alert reaches the responsible team.
Tune rules and filters
The security team reviews alert volumes and false positives, then adjusts detection rules, decoders and filters so that alerts reflect anomalies that could indicate malicious acts, errors or failures. Each rule change is recorded with the reason, the approver and the date. The step closes when the detection rules have a documented owner, a documented purpose and a change history that an auditor can read.
Test that monitoring tools operate
The team runs scheduled checks that confirm agents are reporting, index policies are running, storage is not full and alerts are firing for known test conditions. Failures are logged as tickets and tracked to closure. This is the evidence for CC4.1 monitoring of the controls themselves. The step is complete when the test results, including any failed checks and their fixes, are stored in the evidence repository.
Review alerts and record event evaluations
Analysts triage alerts on a set cadence, decide whether each one is a security event, and record that decision with the evidence reviewed. Events that could cause or have caused a failure to meet objectives are escalated under the incident response process, which addresses CC7.3. Each review leaves a ticket or log entry showing who reviewed it, what they concluded and what action followed. The step is done when the review queue is current and every escalated event has a documented outcome.
Hand over evidence for the examination period
Before fieldwork, the control owner exports the records the auditor needs for the examination period, such as source inventories, retention settings, configuration history, tool health checks, samples of alerts and event evaluations, and retention deletion logs. The auditor's requests are answered from this set and the sample period is defined by the auditor. Whether this is a point-in-time Type 1 or an operating period for Type 2, the length of the period is set by the engagement and the auditor, not by this guide. The step closes when the auditor accepts the evidence set.

Who owns logging controls, who prepares evidence, who attests

This table compares what the organization, an implementation partner and the CPA firm each do for SOC 2 logging and monitoring. Read each row as a split of responsibility: the organization decides and operates, the partner builds and documents, and the CPA firm tests and reports. The main takeaway is that a partner can make the evidence easy to produce, but cannot make the control operate on the organization's behalf.

Activity	Organization	Implementation partner	CPA firm
Owns the CC7.2 monitoring control	Owns it and is accountable for it operating	Designs and configures the detection pipeline as directed	Tests whether the control is designed and operating
Sets logging and alerting policy	Approves scope, log sources and retention decisions	Drafts configuration documentation for review	Reads policy and checks it matches practice
Deploys and configures Wazuh or OpenSearch	Provides access, hosting and change approval	Installs agents, rules, index policies and backups	Inspects configuration and change records, does not configure
Reviews alerts and anomalies	Staff review alerts and document their analysis	May provide runbooks and training materials	Samples alert reviews to test operating effectiveness
Decides whether an event is a security incident (CC7.3)	Makes the decision and records the rationale	Supports forensic analysis when asked	Samples incidents and tests the evaluation process
Retention and disposal of logs	Sets retention periods and confirms them against commitments	Configures retention policies and snapshots	Checks that retention matches the stated policy
Prepares evidence for the auditor	Owns the evidence and answers auditor requests	Produces exported configs, dashboards and index settings	Requests evidence and evaluates whether it is sufficient
Issues the report or opinion	Signs management's description and representations	Has no role in the opinion	Only the independent CPA firm issues the report, and an implementation partner cannot

What to confirm before the auditor samples your logs

An auditor testing CC7.2 and CC7.3 will not take your word that monitoring works. The cards below cover the records they pull first, and each one says how to check it before fieldwork starts.

Log source coverage

List every system in the SOC 2 boundary and the log source it produces: cloud control plane, identity provider, production hosts, databases, admin consoles and endpoints. Compare that list against what actually reaches the log store. A source that is in scope but silent is the most common gap an auditor finds when tracing a sample event back to its origin. Confirm the Wazuh agent or syslog forwarder is registered on each host, and record the date of the last event received from each source.

Time synchronization

Events from different systems only make sense in order if their clocks agree. Check that every log source syncs to the same time source and that the log server records events in a consistent time zone. Ask for a sample event from two systems involved in one incident and confirm the timestamps line up. Drift can make a sequence of events look like it happened in the wrong order, which weakens any investigation the auditor reviews under CC7.3.

Access to log stores

Logs are only evidence if people cannot change them. Review who can read, delete or modify indexes and log archives, and confirm that administrators of monitored systems cannot silently edit their own audit trail. Check that access to the log store itself is limited, logged and reviewed. Keep the access list and the most recent review as evidence, since the auditor will ask who could have altered the records.

Alert review records

A detection rule that fires and disappears produces no evidence. For each alert type, keep a record showing who reviewed it, when, what was decided, and whether it was escalated to an incident. Auditors sample these records to test whether anomalies were analyzed to decide if they were security events, which is the core of CC7.2. Confirm that the alert queue is owned by a named role and that closed alerts carry a documented outcome, not only a status.

Tuning history

Detection rules change as environments change, and every change should leave a trail. Keep a dated record of rules added, disabled, or adjusted, with the reason and the approver. Auditors look for tuning that quietly suppresses an alert type, because a rule switched off without a record is indistinguishable from a control that stopped working. Confirm that rule changes flow through the same change process as other system changes under CC8.1.

Retention policy versus configuration

A retention policy that says one thing while the index settings do another will fail testing. Compare the period written in the policy with the actual deletion or rollover settings in the log platform. The SOC 2 criteria set no retention number, so the organization must choose and justify one. OpenSearch Index State Management policies can enforce that period automatically, so confirm the policy is attached to the live indexes and that deletions are recorded.

Monitoring of the detection tools

CC4.1 expects the organization to confirm that controls are present and functioning, and that includes the monitoring stack itself. Check whether the SIEM, log forwarders and agents raise an alert when they stop, fall behind or lose disk space. Keep a record of a test where a forwarder was stopped on purpose and the gap was detected. A monitoring system that fails silently leaves the organization blind without anyone noticing.

Logging and monitoring questions buyers ask

Does SOC 2 require a SIEM?

No. SOC 2 does not name a product or require a security information and event management system. CC7.2 asks the organization to monitor its system components for anomalies that indicate malicious acts, natural disasters or errors, and CC7.3 asks it to evaluate security events and act on them. A SIEM is one common way to meet those expectations because it centralizes logs, applies detection rules and keeps a searchable record. The auditor will test whether monitoring works and whether events are reviewed, whichever tool does it. A smaller organization can meet the criteria with a well-configured log platform, documented alert rules and recorded reviews, provided the design fits its risks and the auditor accepts it.

How long must SOC 2 logs be kept?

SOC 2 sets no retention number, so the period comes from your own risk assessment, contracts and any other rules that apply to you. Write the period into a retention policy and make the systems enforce it. NIST SP 800-92 Rev. 1, in its initial public draft from October 2023, frames retention as part of log management planning, including meeting retention requirements. For reference, OMB memorandum M-21-31 sets 12 months in active storage and 18 months in cold storage for many federal log categories, and CISA advisory AA22-131A recommends keeping the most important logs for at least six months. Confirm what your customers and any regulator require before you choose a number, and show the auditor that logs are kept for the period you declared.

Is Wazuh enough for SOC 2 logging and monitoring?

Wazuh can cover a large part of the work, but it does not make an organization compliant on its own. The Wazuh agent collects system and application logs from endpoints and forwards them to the Wazuh server, which can also receive syslog and third-party API data and applies decoding and rule matching. That supports the detection side of CC7.2. What remains is your job: deciding which sources must be monitored, tuning rules to your environment, assigning who reviews alerts, documenting how events are classified under CC7.3, and keeping evidence of reviews. Confirm with the vendor which collection methods and rule sets fit your systems, and make sure the auditor agrees the design addresses your risks.

How much effort does SOC 2 logging take, and what does it need from internal staff?

Effort depends mainly on how many systems you run, how many log sources feed the platform, how many alert rules you need and how much tuning the environment requires. Costs fall into one-time work (architecture, agent deployment, rule design, dashboards and documentation) and recurring work (alert triage, rule maintenance, storage, upgrades and periodic evaluation). Internal staff must own the decisions: which events matter, who responds, what counts as a security event and how reviews are recorded. The engineers who run the platform also need time for upgrades and troubleshooting. When requesting a quote, ask the provider to list the log sources, rules, retention targets, storage assumptions and the staff roles it expects you to fill.

Can we run SOC 2 logging and monitoring ourselves?

Yes, many organizations do, provided they have people who understand the systems being monitored and can keep the platform running. The auditor does not need a particular product or an outside firm to run monitoring. The practical questions are whether you have the skills to deploy and tune the tools, whether someone reviews alerts consistently and whether the work survives staff changes. An implementation partner can prepare the system, deploy and configure the platform in your own infrastructure, write the runbooks and assemble evidence, but the organization keeps ownership of its controls. Only an independent CPA firm issues the SOC 2 report.

How does logging relate to the CC7.3 incident record?

CC7.3 asks you to evaluate security events to decide whether they could cause, or have caused, a failure to meet your objectives, and to act when they do. Logs are the raw input for that decision, so the incident record should link each event back to the log entries, alerts and reviewer notes that support it. Keep a register that shows the event, the triage decision, whether it became a security incident, the response and the follow-up. Auditors commonly sample these records to test whether events are evaluated on time and whether actions are completed. Logs that cannot be traced to a decision make the monitoring look ineffective, even when the tooling works.

How DeployOpen prepares logging evidence for SOC 2

DeployOpen works as an implementation partner for the logging and monitoring side of SOC 2. We scope, deploy and harden self-hosted monitoring inside your own cloud accounts, data centers or air-gapped networks, then prepare the configuration and evidence that your controls rely on. In practice that means agent deployment to endpoints, forwarding rules, detection rules, retention policies and the records that show they are running. The work is agreed in a written scope before anything starts, with deliverables and timelines set out in that document. Your organization still owns its controls, and your team decides what counts as an anomaly, who reviews alerts and how security events are escalated.

DeployOpen does not issue SOC 2 reports, attestations or opinions. That work belongs to an independent CPA firm, which tests your design and, for a Type 2 report, operating effectiveness over a period. Before you engage us, ask the CPA firm which logging artifacts it expects to sample, such as alert records, review sign-offs and retention settings, and confirm that the proposed Wazuh or OpenSearch configuration will produce them in a form the auditor can inspect. Ask your auditor to confirm the evidence it will request, rather than assuming a default set.

At handover, you should receive documentation that a reviewer can follow without us: the architecture, the configuration baseline, the retention settings applied through Index State Management, the alert review procedure and a record of changes made during the period. Ask any implementation partner to name these deliverables in the written scope, along with who maintains them after handover and whether ongoing support is a separate retainer. Confirm with your auditor that the documentation format and the evidence cadence match the examination period you have agreed.

SOC 2 logging and monitoring requirements