Open source SIEM for SOC 2 monitoring

Open source SIEM for SOC 2 monitoring: what the auditor will sample

A self-hosted SIEM supplies the detection and event records behind CC7.2 and CC7.3, but it does not satisfy either criterion on its own. CC7.2 asks you to monitor system components for anomalies and decide which ones are security events. CC7.3 asks you to evaluate those events and act when they could cause or have caused a failure to meet your objectives. Both criteria also depend on written detection procedures, tuning records, and an incident response process that the SIEM output feeds into. A SaaS or service company with thin monitoring evidence usually has the tool but not the paper trail around it. A SOC 2 Type 2 report adds an opinion on operating effectiveness over a period, so the auditor samples evidence from throughout that window, not from a single date. The 2017 Trust Services Criteria include 33 common criteria that apply to every SOC 2, and CC6 to CC9 cover the system operations that the SIEM monitors. Confirm with your auditor which trust services categories are in scope, because confidentiality or privacy add CC7.3 points of focus about assessing the impact on personal or confidential information. Decide early whether the SIEM's detection content, alert thresholds and review cadence will stay fixed for the whole period, since any change during the window will need its own record.

Before the observation period starts, have the SIEM team, the security owner and your auditor agree on the evidence set: which log sources are onboarded, which alert rules are active, who reviews alerts and how often, and where reviews and incident tickets are recorded. DeployOpen prepares systems, controls and evidence for a SOC 2 assessment, including configuration exports, rule inventories and review records, but it does not issue audit reports, attestations or opinions. The independent CPA firm performing the examination makes that determination. Ask the auditor for a sample request list early, and test that the SIEM can produce those records on demand before the period begins.

Mapping CC7.2 and CC7.3 to SIEM functions and configuration

This table maps each CC7.2 and CC7.3 monitoring function to what the SIEM must do and how to configure it in Wazuh or Graylog Open. Read it row by row against your in-scope systems, then confirm rule content and evidence format with your SOC 2 auditor before the observation period starts.

Requirement and focus	What the function must do	How to configure it in Wazuh or Graylog Open
Log source coverage on in-scope systems (CC7.2)	Collect security-relevant logs from every system in the SOC 2 boundary, including production hosts, cloud control planes, identity providers and the SIEM itself, so anomalies are visible.	Deploy Wazuh agents on Linux, Windows and macOS hosts and use syslog collection for firewalls and cloud sources. In Graylog Open, define inputs for syslog, GELF and Beats and document each source in an inventory.
Detection rules and filters (CC7.2)	Define detection policies and filters that separate anomalies from routine activity, and record who approved them and when they changed.	Use Wazuh decoders and rules, with custom rules kept in version control. In Graylog Open, build streams and processing pipelines, and keep event definitions and their change history as audit evidence.
Monitoring the detection tools (CC7.2)	Confirm that agents, collectors and rules are running as designed and raise an alert when a source goes silent or a component fails.	Enable agent status and disconnection alerts in Wazuh and monitor indexer and server health. In Graylog Open, alert on stalled inputs and on index or journal problems, and review the results on a set schedule.
Event triage and escalation (CC7.2 and CC7.3)	Route alerts to a named analyst, record the triage decision, and escalate events that may be security incidents under a written procedure.	Send Wazuh alerts to a ticketing or chat channel with severity mapping. In Graylog Open, route event notifications to email, Slack or PagerDuty, and require a disposition field for each alert.
Incident determination and response (CC7.3)	Evaluate whether each event could have caused or did cause a failure of objectives, act to contain or fix it, and document the outcome.	Keep an incident record linked to the alerts and log queries that support the decision. Confirm with the auditor which fields must be retained and whether confidential or personal information impact is assessed.
Communication and review of detected events (CC7.3)	Communicate events to the people who need them and review detected events on a recurring basis, with the reviewer's sign-off retained.	Schedule dashboard or report reviews in Wazuh or Graylog Open and export signed review records. Ask your auditor how often reviews must occur and what sample evidence they will request for the period.

Which self-hosted SIEM fits a SOC 2 scope

A SOC 2 monitoring scope is usually a set of hosts, cloud workloads, applications and identity systems, plus the network segments that connect them. The platforms below cover different parts of that scope, and most teams pick one primary SIEM and add a second tool only where the first one has a gap.

Wazuh as the host-based core

Wazuh combines endpoint agents, a server that decodes and applies rules, an indexer that stores alerts, and a dashboard. Its agents run on Linux, Windows and macOS, and agentless syslog covers firewalls and other devices. The dashboard includes prebuilt compliance views, but treat them as a starting point: map each view to the CC7.2 and CC7.3 points of focus yourself and confirm with your auditor which alerts and records they will sample. The core repository is licensed under GPL-2.0.

Graylog Open for log search and alerting

Graylog Open ingests logs through inputs such as syslog, GELF and Beats, routes them through streams and processing pipelines, and raises alerts from event definitions. It is a good fit when application and cloud logs are the main evidence source. Its license is SSPL-1.0, which is not OSI-approved, so have legal review it before you build internal services on it. Confirm which features you need are in Graylog Open rather than the paid editions.

OpenSearch-backed storage and sizing

Graylog and Wazuh both store events in a search backend, so storage and retention decisions drive your cost and your ability to produce records for a Type 2 period. Graylog recommends Data Node as its search backend, and OpenSearch 1.x use is deprecated from Graylog 7.0 and removed in Graylog 8.0. Check the Graylog compatibility matrix against the versions you plan to run, and size storage from your own ingest and retention targets.

Security Onion for network visibility

Security Onion bundles Suricata, Zeek, osquery and the Elastic stack, so it covers network traffic that host agents cannot see, such as east-west traffic between services and unmanaged devices. It is licensed under the Elastic License 2.0, which has its own terms for hosted services, so review those terms with counsel. For a SOC 2 scope, decide whether network alerts are part of your monitoring population and document how they reach your incident process.

Compliance views are not the auditor's mapping

Dashboards for PCI DSS, GDPR, HIPAA and NIST 800-53 show which rules matched, but they do not show that your alert thresholds, review cadence and escalation records meet the TSC points of focus for your system. Build a written mapping from each CC7.2 and CC7.3 point of focus to a rule, a review task and a ticket type. Ask your auditor to review that mapping before the observation period starts.

How scope and environment change the SIEM design

When the production system runs entirely in a public cloud account, the SIEM's job is to collect what the provider and your workloads emit, normalize it and keep it searchable for the period the auditor samples. Most of the monitoring evidence for CC7.2 comes from application logs, identity and administrative activity, and host or container telemetry that you control. Agents fit well on the virtual machines and images you build, while managed services often need their logs pulled through a provider-side export rather than an installed agent. Confirm with each provider which audit and management logs can be exported, in what format and with what retention, because log formats differ and this page does not assume any particular one.

Application and identity logs: Authentication events, administrative changes and application errors are usually the most sampled evidence, so collect them first.
Agent coverage on owned hosts: Install Wazuh agents on the virtual machines and base images you manage, and record which instances are excluded.
Managed service exports: Plan a collection path for each managed service, and treat any gap as a monitoring gap to document.
Ingest and retention cost: Cloud log volume grows with traffic and verbosity, so decide early which sources are full-fidelity and which are summarized.

Before committing, confirm which provider logs you can export and verify that the export path is covered by your monitoring description.

Evidence auditors sample from the SIEM over the period

This table lists the SIEM records a SOC 2 service auditor typically samples under CC7.2 and CC7.3, what they check in each, and which component usually produces it. Read it as a checklist for the full review period, since an auditor testing operating effectiveness will ask for records from the start to the end of the window, not only a screenshot taken on audit day.

Evidence item	What the auditor looks for	Component that produces it
Alert rule definitions and change history	Documented detection rules, who approved each change, dates of changes, and proof that rule edits were reviewed and not made silently	Wazuh server rule files under version control, or Graylog event definitions with audit history
Sampled alerts with triage notes	A sample of alerts across the period, each showing timestamp, source, severity, the analyst's disposition and the reasoning recorded	Wazuh dashboard or Graylog alert views, exported with analyst notes
Tickets linked to security events	Each escalated event links to a ticket with owner, open and close dates and the action taken	Ticketing system integrated through alert routing; confirm the link is stored, not only in chat
Incident records with determinations	For each event evaluated as a possible security incident, a written determination of whether objectives were affected and the response taken	Incident records kept in the team's case or ticketing tool, with SIEM events attached
Review sign-offs	Evidence that someone reviewed alert queues and detection performance on the defined cadence, with reviewer identity and date	Ticket or review log in the SOC workflow; SIEM supplies the underlying queues
Log source inventory	A current list of systems sending logs, the expected sources for in-scope systems, and any source that stopped reporting	Wazuh agent list and syslog inputs, or Graylog inputs and streams; reconcile against the asset inventory
Agent health and coverage reports	Reports showing agent connection status over time, gaps in coverage and how gaps were followed up	Wazuh agent status and inventory data; Graylog input status and message volume trends
Retention settings and SIEM access records	Configured retention for the period, evidence that logs were not altered, and a record of who accessed the SIEM and its administrative settings	Wazuh indexer index policies and audit logs; Graylog index rotation and retention settings, plus authentication logs for SIEM users

Questions buyers ask before a SOC 2 monitoring build

What does a self-hosted SIEM cost to run for SOC 2 monitoring?

The cost is a mix of one-time build work and recurring operation, and no single figure applies to every company. The main components are the infrastructure that hosts the SIEM (cloud or data center compute, storage and backups), the software licenses (Wazuh and OpenSearch are open source, while some Graylog features sit in paid editions), the engineering time to onboard log sources and write detection rules, and the staff time to review alerts and keep records. Storage and compute grow with daily ingest and retention, so those are the largest drivers. If you consider a paid Graylog edition, the Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year and Graylog Security from 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Ask any provider for a quote that separates one-time setup, annual licenses, infrastructure and recurring support.

How long does a SOC 2 SIEM build take, and what sets the timeline?

The timeline depends mostly on how many log sources must be connected, how much of your environment is already in code, and how quickly your team can approve access and review alerts. A single-cloud SaaS with standard Linux servers and a cloud account will move faster than a company with many SaaS tools, legacy hosts and manual approvals. Other factors include whether the SIEM is deployed in your cloud account or on new hardware, how many detection rules need tuning to your environment, and how long the evidence has to exist before the auditor's period begins. Because a Type 2 report covers a period of operation, the monitoring must run and produce records for that whole window, so start early enough that controls are stable before the period starts. Ask for a written scope and milestone plan before work begins, since most engagements are fixed-scope.

What must our team provide to a SIEM build for SOC 2?

Your team supplies the decisions and access that only your company can give. Name a system owner for the SIEM who approves scope, retention and alert routing. Provide access to each log source, such as cloud audit trails, identity provider logs, production servers, endpoints and key SaaS applications, along with credentials or service accounts that can read them. Assign ticket owners who will receive alerts, record their triage, and close or escalate each case in your ticketing system. Finally, confirm who reviews the alert records on a set cadence and who signs off on changes to detection rules. Auditors sample these records, so the people named must actually perform the work during the period.

Can our team build SOC 2 SIEM monitoring without outside help?

A capable team can build it alone, but the work is broader than installing software. The SIEM itself is only one part of the CC7.2 and CC7.3 evidence, and the remaining parts are the detection content, the alert triage process, the incident records and the periodic review that proves someone acted on what the SIEM produced. Teams usually need someone with Wazuh or OpenSearch administration experience, someone who can write and tune detection rules, and someone who can explain the controls to the auditor. Consider whether those skills and the hours to maintain them are available for the full review period. A partner can implement and document the setup, while your team keeps ownership of alert decisions. Whichever route you choose, agree on who handles upgrades, since Wazuh and Graylog both release updates on a regular schedule.

Can a SOC 2 Type 2 pass on tooling alone?

No. A SOC 2 Type 2 report expresses an opinion on whether controls operated effectively over a period, and a SIEM is evidence for only part of that. The Trust Services Criteria ask the organization to monitor for anomalies, analyze them, evaluate security events and respond to incidents, so the auditor will look at whether people reviewed alerts, documented decisions and escalated real incidents. The criteria also cover logical access, change management and risk mitigation, which a SIEM does not decide on its own. Points of focus are not separate requirements, and they help you design and evaluate controls, but the report depends on the whole control set operating over the period. Treat the SIEM as the detection layer of a broader control environment.

Does DeployOpen issue the SOC 2 report?

No. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms, including SIEM deployments, and prepares systems, controls and evidence for compliance assessments. We do not issue audit reports, attestations or certifications. A SOC 2 report is issued by an independent CPA firm after its examination under the AICPA attestation standards, and only that firm decides whether the controls were suitably designed and operated effectively. Before engaging anyone, confirm with your auditor which records they expect for CC7.2 and CC7.3, what period they will test, and how they want the evidence delivered. We can prepare the monitoring setup and the evidence to match that conversation.

What the SIEM does not satisfy on its own

A SIEM collects and alerts on events, but SOC 2 auditors assess whether your controls are designed well and operate consistently across the period. The cards below cover the parts of CC7.2 and CC7.3 that sit in procedures, people, risk decisions and the system description rather than in the tool.

Written monitoring and incident procedures

CC7.2 and CC7.3 both expect documented procedures: how detection tools are designed, how anomalies are analyzed, and how security events become incidents. Auditors read these documents first and then compare them with what the SIEM actually does. Check that each alert rule, triage step and escalation path in the procedure maps to a configured rule or a named person, and that the document names the version in force during the period.

Human review and sign-off cadence

A SIEM produces alerts, but a person must review them and record the outcome on a schedule. Auditors sample review records across the observation period, so gaps in weeks where nobody signed off are visible findings. Define who reviews alerts, how often, what a closed alert looks like, and who reviews the reviewer. Confirm that the cadence is achievable with your staffing, including coverage for holidays and absences.

Risk assessment inputs defining security events

CC7.3 asks you to decide whether an event could cause a failure to meet your objectives. That decision depends on inputs from your risk assessment: which assets are critical, which data is confidential, and which failures matter most to customers. Without those inputs written down, the SIEM has no basis for severity levels or escalation thresholds. Check that the risk register is current and that alert severities trace back to it.

Alert tuning justified in writing

Detection rules are changed as the environment changes, and each change affects what the SIEM will and will not report. Auditors ask why a rule was disabled, why a threshold was raised, or why a noisy source was excluded. Keep a change log for rules and suppressions that records the reason, the approver and the date. Tuning without a record can look like a control that was quietly weakened during the period.

Vendor and third-party log coverage

Many SOC 2 systems depend on cloud providers, identity providers, payment processors and managed services whose logs never reach your SIEM by default. Your monitoring control covers the system boundary you describe, so unmonitored third-party activity that touches customer data is a gap. List each external service in scope, confirm which of its logs you can obtain, and record how you review the ones you cannot ingest, such as provider reports or contractual notifications.

Completeness of the system description

The system description states what is in scope, including the infrastructure, software, people and data that support the service. If the description omits a log source, a SIEM monitoring that source does not help you, and a monitored source that is missing from the description raises questions about scope. Compare the description against the SIEM's agent inventory and log source list before the period starts, and update both when services change.

Protecting the logs an auditor will rely on

The SIEM is itself in scope for the SOC 2 examination. An auditor testing CC7.2 and CC7.3 will want to see that the alerts and review records were complete and unaltered over the whole period, which means the platform holding them has to be controlled too. Start by restricting who can change detection rules, alert routing, index settings and retention on the SIEM, and separate those administrator roles from the analysts who review alerts. In a Wazuh deployment, that means reviewing who holds administrator access to the Wazuh server, the Wazuh indexer and the Wazuh dashboard, and confirming that access is tied to named individuals and recorded. In a Graylog deployment, review the user roles in the Graylog web interface and confirm how authentication is handled, using the Graylog user authentication documentation as the starting point.

Integrity of stored alerts deserves its own check. Confirm where alerts are written, who can delete or edit them, and whether any change to the index or to the rules is logged and retained outside the platform administrators' reach. Export a sample of alerts and review records at the start of the period so you can show later that they were not altered. Ask your auditor which evidence format they accept for this and whether they expect the SIEM's own audit trail to be part of the sample.

Retention is set by your own policy and by the commitments you make to customers, not by the SIEM's defaults. The sizing rule in Graylog's system architecture guidance, which advises daily ingest times retention days times 120 percent for log storage, is a planning rule for storage capacity and does not tell you how long to keep anything. Decide the retention period for alerts, review records and raw logs that cover the full audit period, then confirm that period with your auditor before the period starts. Storage sized to that period is a cost you carry for every day of retention, so record the decision and the reason for it in your policy.

Rolling out monitoring before the audit period starts

The rollout turns a SIEM installation into monitoring controls that are running, tuned and producing records before the Type 2 observation window opens. Each phase depends on the one before it, so the go-live date is set only when the evidence trail already works.

Define scope and inventory systems
Start by listing the systems inside the SOC 2 system boundary, including production cloud accounts, Kubernetes clusters, identity providers, administrator workstations and any service that stores or processes customer data. Name an owner for each system and record which log types it can produce, such as authentication events, administrative changes, network flows and application errors. The step is done when the scope is written down, signed off by management and reconciled against the system description you intend to present to the auditor.
Onboard log sources and confirm coverage
Install Wazuh agents or configure syslog and API collection for each in-scope source, and point cloud and Kubernetes audit logs at the SIEM. Check that every source delivers events, that timestamps are consistent across systems, and that the platform's own administrative and audit records are also collected. Confirm the agent and collection status against the inventory, so any gap is visible before it becomes a hole in the audit period. The step closes when a coverage report shows each in-scope source reporting.
Build detection content and alert routing
Write or adopt detection rules for the events your own risk assessment says matter, such as failed and successful logins from unexpected locations, privilege grants, disabled logging, changes to firewall or security group rules and malware detections on endpoints. Route each alert class to a named queue or on-call group, and set severity levels that the team agrees on. Test each rule with replayed or simulated events and record the results. Done means every rule has a documented purpose, an owner and a test result.
Set up the triage and ticketing workflow
Define how an alert becomes a reviewed event, how an event is judged a security incident, and who approves closure. Connect the SIEM to the ticketing system so every alert that is escalated gets a record with a timestamp, the analyst's notes, the decision and any corrective action. Write the procedure in a form the team will follow, since CC7.3 asks the organization to evaluate events and respond to incidents. The step is complete when a test alert has moved through the full path and produced a closed ticket with all fields filled.
Run a dry run of evidence collection
Before the observation window opens, pull the artifacts an auditor is likely to sample: alert histories, review sign-offs, incident tickets, rule change logs, access records for the SIEM itself and retention settings. Ask someone outside the SOC to attempt the collection from the written procedure and note every missing field or manual workaround. Fix gaps in the procedure or the tooling, then repeat the pull once. Done means the evidence can be produced on request without reconstruction from memory.
Confirm the controls operate and record the go-live date
Review the dry-run results with management and confirm that the detection tools, alert routing, review cadence and ticketing workflow all run as described. Record a documented go-live date in the change log and tie it to the period start agreed with the auditor, so the operating period begins with working controls. Ask your auditor which points of focus they expect you to evidence before that date. The step is done when management has signed the go-live record and the baseline evidence set is archived.

How DeployOpen scopes and delivers SOC 2 monitoring evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a SOC 2 monitoring SIEM, we agree in writing which log sources, detection controls and review records the examination will sample, then build and document them so your team and your auditor can trace each one.

How we scope

Agree in writing which log sources in the SOC 2 system boundary feed the SIEM, such as identity, cloud control plane and production hosts
Map each detection and review record to CC7.2 and CC7.3 points of focus, and to the service commitments you will ask the auditor to examine
Confirm the scope with your auditor before build, including whether confidentiality or privacy criteria are in scope for alert triage

How we build

Deploy the chosen Wazuh or Graylog stack in your environment, with agents, syslog inputs and retention settings documented as configuration
Write and tune alert rules and event definitions, then test them against sample events so alert behavior is shown, not assumed
Protect the logs themselves with access controls, time synchronization and retention settings that the written scope defines

How we hand over

Deliver runbooks for alert triage, escalation and review sign-off, with a named owner for each recurring review record
Provide a control evidence pack that shows configuration, rule sets, alert samples and review logs as they exist during the period
Train your operators on the platform and document the boundary between what the SIEM produces and what your process must still record

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts and quoted from that scope
Ongoing upgrades, patching, rule maintenance and continuous testing are available as a retainer, which keeps the monitoring controls stable across the examination period
Ask any partner, including us, to confirm how alert review evidence is retained and who signs off on each review

Open source SIEM for SOC 2 monitoring