Open source SIEM for SaaS companies

Why a SaaS company needs an open source SIEM for SOC 2 evidence

A SaaS company preparing a SOC 2 Type 2 or ISO 27001 certification usually needs a self-hosted SIEM that covers its own production cloud, Kubernetes and SaaS log sources, with alerts, review records and retention an auditor can sample. An open source platform can do that without a large SOC team if the scope is defined early. In a typical lean setup, Wazuh handles agent-based collection, file integrity and compliance views, while OpenSearch serves as the search and storage layer behind it. The SOC 2 Trust Services Criteria, not the SIEM, decide what counts as evidence. The security common criteria CC1 to CC9 apply to every SOC 2 report, and the monitoring criteria in CC7 are the ones the SIEM mainly supports. Confirm with your auditor which system components and time period fall in scope before you pick a platform.

SaaS differs from other sectors in three ways. First, the evidence is about your own production environment, not a regulated record system that a regulator defines. Your auditor will ask about the cloud accounts, clusters, identity provider and admin consoles that your service actually runs on. Second, customer contracts and the system description shape scope more than statute does. A large customer may ask for specific logs or retention, and those requests can change what the SIEM must ingest. Third, the main cost lever is ingest volume and retention. Kubernetes audit logs, cloud control plane events and verbose application logs can grow quickly, so the first design decision is which sources feed hot search, which go to cheaper archive storage, and how long each must stay searchable.

Before you commit to a design, write down four things: the in-scope log sources by account and cluster, the daily ingest estimate you can measure from a pilot, the retention period your auditor and contracts require, and the alerts that a named person reviews and records. Ask any implementation partner to show how they would prove to an auditor that logs are complete and cannot be altered, and how the team will be trained on Wazuh and OpenSearch upgrades. The SIEM supplies the records. Whether those records satisfy SOC 2 depends on the control design and on the review process your team runs around them.

What SOC 2 and ISO 27001 require of SaaS monitoring

This table maps the SOC 2 security criteria and the ISO/IEC 27001:2022 logging and monitoring controls to the log sources, alert review and retention evidence each one implies. Read each row as a question an auditor will ask about your SIEM, then confirm the exact criterion wording against the AICPA text before you finalize scope. The main takeaway is that the auditor samples evidence over a period, so the SIEM must run consistently from the start of that period.

Requirement	What it means for the SIEM	Evidence to keep
SOC 2 security common criteria CC1 to CC9	Security applies to every SOC 2 report. Monitoring sits within the system operations and detection criteria, so the SIEM must cover in-scope systems, not just production servers.	Documented scope of in-scope systems and log sources mapped to each common criterion
SOC 2 monitoring criteria (CC7.2 and CC7.3)	Expected to cover monitoring for anomalies and the evaluation of security events. Confirm exact wording and mapping against the AICPA 2017 Trust Services Criteria before relying on these IDs.	Alert rules, alert records, triage tickets and documented event evaluation decisions
SOC 2 Type 1 versus Type 2	Type 1 describes the system and whether controls are designed as of a date. Type 2 adds operating effectiveness over a period, so a SIEM that was switched on late will leave gaps the auditor can see.	Type 1: design documentation as of a date. Type 2: continuous log and review records across the full observation period
Log source coverage for cloud and Kubernetes	Auditors ask whether cloud control plane, identity, and cluster audit logs reach the SIEM. Gaps in source coverage are a common finding.	Source inventory, forwarding configuration, and a sample of events from each source
Review of alerts and security events	Someone must review alerts on a defined cadence and record the outcome. Automated rules alone do not satisfy the review expectation without records.	Review logs, dispositions, escalation records and on-call coverage schedule
ISO/IEC 27001:2022 Annex A control count	Annex A lists 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). Logging and monitoring controls sit in the technological theme.	Statement of Applicability entries that name the logging and monitoring controls and how each is implemented
ISO/IEC 27001:2022 logging and monitoring controls	Covers event logging, protection of log information, monitoring of systems, and clock synchronization. Confirm control IDs and wording against the ISO standard.	Log retention settings, access controls on the SIEM, time source configuration and monitoring procedures
ISO/IEC 27001 certification cycle	Accredited certification bodies certify on a three-year cycle with at least one audit every calendar year. Monitoring evidence must be available at each surveillance audit, not only at certification.	Ongoing evidence pack refreshed for each annual audit, with the SIEM running continuously between audits

Which platform fits a SaaS team: Wazuh, OpenSearch or a combined stack

A small SaaS team with no existing log platform usually gets the fastest path to coverage from Wazuh. Its agents run on Linux, Windows and macOS, collect host telemetry and ship it to a server that decodes and correlates events, while the Wazuh dashboard provides the alert views. Wazuh is distributed under the GNU General Public License version 2, so the core platform has no per-seat or per-feature license fee to plan around. The dashboard includes prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53, but it does not include a SOC 2 view, so the team will need to map its own controls to the alerts and evidence an auditor samples.

Agent coverage: Endpoints and Linux servers are the strongest starting point, with agent configuration and upgrades managed remotely from the server.
Agentless sources: Firewalls and other devices that cannot run agents can send syslog, with periodic API probing for some devices.
Prebuilt views: Use the PCI DSS, GDPR, HIPAA and NIST 800-53 dashboards as a starting structure, not as a SOC 2 mapping.
Deployment options: An all-in-one installation, Docker, Kubernetes or a prebuilt virtual machine image can match the team's existing platform skills.
Upgrade cadence: The 4.14 line has received patch releases roughly every one to two months, so budget engineering time for regular upgrades.

Before committing, confirm with your SOC 2 auditor which Wazuh rules and dashboards they will accept as monitoring evidence for CC7.2 and CC7.3.

Platforms that fit a lean SaaS SIEM

A lean SaaS SIEM usually rests on one log platform, a small set of collection and identity components, and optional sensing or automation added only where a need is confirmed. The cards below separate what carries the monitoring evidence from what supports it, and name the limit to check for each before committing.

Wazuh as the core SIEM and XDR

Wazuh combines agents on Linux, Windows and macOS with a server, an indexer that stores alerts, and a dashboard with prebuilt compliance views. Its server can run as a cluster, and it manages agent configuration and upgrades remotely, which helps a small team keep endpoints consistent. Its vulnerability detection correlates agent software inventory with the Wazuh CTI platform or an offline repository. Confirm how your cloud and Kubernetes log sources reach the server, and who owns indexer sizing as ingest grows.

OpenSearch as the analytics layer

OpenSearch is released under the Apache License, Version 2.0, and its Security plugin provides SAML, OpenID Connect, LDAP and Active Directory authentication, role-based access, field-level security, audit logs and TLS. It can be installed with Helm or the OpenSearch Kubernetes Operator, which suits teams already running clusters. Confirm which features your chosen SIEM front end actually depends on, and plan upgrades around the release cadence of roughly one minor version every eight weeks.

Shuffle for alert triage

Shuffle is an AGPL-3.0 security automation platform that can enrich alerts, open tickets and run first-pass triage steps without adding analysts. For a SaaS company, it is most useful for repeatable tasks such as checking a cloud login against a known location or tagging a Kubernetes audit event. The AGPL-3.0 license has network-use obligations if you modify the code and offer it to users, so have counsel confirm your use. Confirm which playbooks run unattended and which require a human decision.

Keycloak or authentik for dashboard SSO

Wazuh documents single sign-on for its dashboard, so a central identity provider lets you enforce multi-factor authentication and remove local dashboard accounts. Keycloak supports OpenID Connect and SAML 2.0 and is a CNCF incubation project, while authentik is MIT-licensed except for its enterprise directory. Confirm which SSO protocol your Wazuh version supports, how group claims map to dashboard roles, and who administers the identity service that now gates access to logs.

Suricata or Zeek where sensing is needed

Network sensors are worth adding only when you need visibility that cloud provider logs and host agents cannot give, such as east-west traffic in a self-managed cluster or egress from a database subnet. Suricata is GPL-2.0 and Zeek uses a BSD-style license, and both produce logs that can flow into the same analytics layer. Confirm the traffic you must see, the placement points you can reach in your cloud network, and the storage cost of full packet or metadata capture.

OpenBao or Infisical for pipeline secrets

The credentials that let collectors, forwarders and cloud connectors read logs are themselves sensitive, and hard-coding them in configuration files creates an audit finding. OpenBao is MPL-2.0 and hosted under the OpenSSF, while Infisical is MIT-licensed except for its enterprise directories. Both can issue and rotate the secrets that log pipelines use. Confirm which secrets engine your log shippers and Kubernetes workloads support natively, and how rotation events are recorded for the evidence file.

Integration points and deployment pattern for SaaS workloads

A SaaS SIEM is only as useful as the log sources feeding it and the boundary it sits behind. The cards below cover the sources a SOC 2 monitoring program usually needs, the separate account that keeps security logs apart from production, and the cost controls that decide how much data is indexed and for how long.

Cloud control-plane logs

Cloud provider audit trails record who changed IAM policies, security groups, storage access and logging settings. These are the events a SOC 2 reviewer will ask about first when testing change monitoring. Confirm which control-plane trails are enabled in every account and region, and that they are forwarded to the SIEM rather than kept only in the provider console. Check whether the provider's delivery path needs its own collector or whether an agent or syslog bridge is required. Verify that log delivery failures raise an alert.

Kubernetes audit and Falco runtime events

Kubernetes audit logs show API calls against the cluster, including secret reads, role bindings and exec sessions into pods. Falco adds runtime detections such as unexpected shells or outbound connections from containers. Together they cover the cluster layer that host agents miss, since containers are short-lived. Decide which audit policy levels you need, because verbose settings multiply volume quickly. Confirm the Wazuh ingestion path for both sources with your own cluster version before committing to it.

Identity provider sign-in and MFA events

Sign-in, failed authentication, MFA enrollment and MFA reset events from the identity provider are the records that show who accessed production and whether strong authentication was used. For SOC 2 Type 2, these events support the review of privileged and unusual logins over the audit period. Confirm the identity provider can export these events to the SIEM and that administrative changes to MFA settings generate their own alerts. Map the event names to your detection rules during onboarding.

Separate security account or project

Storing SIEM data in a dedicated security account or project keeps log integrity and access apart from the production team that generates the logs. Engineers who administer workloads should not be able to delete or alter the audit trail they are reviewed against. Ask how cross-account log delivery is granted, which roles can read the SIEM, and whether log buckets are protected from deletion. Document this boundary as part of the system description used in the SOC 2 examination.

Ingest filtering before indexing

Every event that reaches the index adds storage and search cost, so filtering before indexing is the main lever for cost control. Drop repetitive health checks and low-value debug output at the collector or decoder stage, but keep every event type that a monitoring control depends on. Record each filter as a documented decision, because an auditor may ask why a source was excluded. Review filter changes at the same cadence as detection rule changes.

Hot and archive retention tiers

Recent logs need to be searchable for daily review and alert investigation, while older logs mainly need to be retrievable for an audit sample. Splitting storage into a hot tier and an archive tier lets the team keep searchable data small without shortening the retention period the framework requires. Confirm with your auditor how far back samples will be requested and how long archived logs take to restore. Test a restore before the audit period begins, not during it.

Rollout phases for a lean SaaS SIEM

This sequence moves a SaaS company from a scoped list of SOC 2 monitoring commitments to a running, lean SIEM that produces the alert review, retention and access evidence an auditor will sample over the audit period. Each phase closes with a named output that the next phase depends on.

Scope log sources against SOC 2 criteria
Start by mapping the system boundary of the in-scope service to the security common criteria, with particular attention to the monitoring criteria CC7.2 and CC7.3, and to any logging commitments made in customer contracts or security questionnaires. The compliance lead and engineering lead own this work, with the auditor's expectations confirmed early. It is done when the team has a written list of the monitoring objectives, each tied to a criterion or a customer commitment and to the systems that must produce evidence for them.
Build the log source inventory and ingest estimate
Inventory every cloud account, Kubernetes cluster, identity provider, code repository, production database and SaaS admin console that falls inside the scoped objectives, and record the log type, owner and expected daily volume for each. Ask your implementation partner to show how they produced the ingest and storage figures, because the storage and compute needs of a self-hosted SIEM scale with ingest and retention. It is done when the inventory is approved and the ingest estimate states which sources are high volume and which can be filtered at the source.
Deploy the SIEM in a separate account
Install the chosen platform, such as Wazuh with its indexer, server and dashboard, or an OpenSearch-based stack, in a dedicated cloud account or project that is separate from production. Restrict administrative access to a small named group, enforce unique user identification and MFA for the dashboard, and configure the security plugin or dashboard roles so that engineers see only what their role requires. Confirm which role-based and field-level controls your chosen platform supports before you rely on them. It is done when the platform runs, the admin paths are documented, and a test user cannot change log storage or retention settings.
Onboard cloud and Kubernetes sources
Connect the cloud provider audit and control-plane logs, the Kubernetes audit logs and the identity provider logs to the SIEM, and deploy agents to the hosts and nodes that the inventory marks as in scope. Where an agent cannot run, use syslog or an API collection path and document it as an exception. Verify parsing and timestamps on every source, and check that log shipping failures generate an alert. It is done when each in-scope source shows recent events in the SIEM, the timestamps are consistent, and a deliberately stopped source triggers a visible alert.
Write and tune a starter detection set
Build a short starter set of detections that maps to the monitoring objectives, such as changes to cloud IAM policies, disabled logging, new administrator sessions, unusual Kubernetes exec activity and repeated failed logins. Route each alert to a named channel with an owner, and record the triage decision for every alert so that the review trail exists from the first day. Tune thresholds over a short observation period to cut noise without suppressing the events that matter. It is done when each detection has a documented purpose, an owner, a routing rule and a tuning history.
Produce evidence for the audit period
Set up recurring evidence exports for the items an auditor samples: alert review records, retention settings with their change history, the access review of SIEM users and the log integrity controls. Ask your auditor which samples and formats they expect, and confirm that the evidence is collected on a schedule that will cover the full audit period. DeployOpen prepares the controls and evidence for assessment, but the independent auditor issues the report. It is done when the evidence set can be produced on request for any date in the period, and a sample review has been walked through with the compliance lead.

Monitoring evidence auditors ask for and which component produces it

This table maps each evidence item an auditor typically samples for SOC 2 monitoring to the component that produces it and to what the company must still run itself. Read it as a split of responsibilities: the SIEM generates and preserves the records, while the company proves that people reviewed alerts, approved changes and controlled access.

Evidence item	Producing component	What the company still owns
Monitored log sources	Wazuh agents and syslog collection, with the Wazuh server recording which agents report and when they go silent	Maintaining the source inventory, adding cloud accounts and Kubernetes clusters as they are created, and explaining gaps
Alert and detection rule definitions	Wazuh server rule and decoder files, plus rules pulled into version control from the server	Change approval for rules, a documented reason for each tuning change, and a named owner for detection content
Alert review and ticket records sampled over the period	Wazuh dashboard alert views and indexed alerts in the Wazuh indexer; SOAR case records if Shuffle or a ticketing tool is used	Daily or defined-cadence review, triage decisions, escalation records and proof that reviewers worked the queue during the audit period
Retention configuration	Wazuh indexer index lifecycle settings and snapshot configuration on OpenSearch-based storage	Setting retention to match the commitments in the company's SOC 2 system description and keeping the configuration under change control
Access list for the SIEM	OpenSearch Security audit logs and role mappings; Wazuh dashboard user and role records	Quarterly access reviews, joiner and leaver approvals, and linking SIEM accounts to the identity provider
Log integrity and protection	Audit logging and TLS in OpenSearch Security; agent-to-server encryption and restricted indexer write paths in Wazuh	Restricting administrator access to the SIEM hosts, backing up the indexer, and documenting who can delete or alter logs
Vulnerability detection output	Wazuh vulnerability detection, correlating agent software inventory with CTI or offline vulnerability data	Triage, remediation tickets, deadlines and closure evidence, since the SIEM reports findings but does not fix them

What drives SIEM cost for a SaaS company and how to control ingest

The main recurring cost of a self-hosted SIEM for a SaaS company is the infrastructure that indexes and stores what you collect, and it grows with two things: daily ingest and how many days stay searchable. On a Wazuh deployment, the Wazuh indexer holds alerts and carries most of the storage and compute load, so every noisy cloud audit stream or Kubernetes event you forward is paid for in disk and memory. Engineering time is the other recurring line: someone must onboard new cloud accounts and clusters, write or tune detection rules, and review what the SIEM produces. One-time costs cover design, initial deployment, parser work for each source and the first round of detection content. Upkeep is recurring: Wazuh 4.14 has shipped patch releases several times a year, and OpenSearch moves to a new minor version about every eight weeks, so budget for upgrade testing on a fixed cadence. If you buy paid support or a managed service, that fee is also recurring and should be priced against the engineering hours it replaces.

Ingest control is the lever you can pull fastest. Filter high-volume, low-value events at the source or at the Wazuh server before indexing, such as health checks, routine load balancer requests and repetitive allow decisions from cloud network logs, while keeping authentication, administrative actions, key and secret access, and changes to security groups and IAM policies at full fidelity. Then separate hot from archive retention. Keep the recent window that your detection and SOC 2 sampling need in searchable indices, and move older data to compressed snapshots or cold storage. Confirm with your auditor how far back they will sample before you shorten anything. Use index lifecycle policies on OpenSearch-based platforms so the tiers are enforced automatically rather than by a manual clean-up.

When you ask for a quote, require the vendor or partner to state the assumed daily ingest in gigabytes per source, the hot and archive retention periods, the storage and compute sizing that follows, the number of detection rules and their owner, the upgrade and patch service and its frequency, and the support hours. Ask which parts are one-time and which recur, and what is excluded. The EU Data Act's switching rules, under which the switching charge ban applies from 12 January 2027, affect what you can be charged when you move between data processing services, but they do not set what your SIEM costs to run, so do not let them drive the sizing or the budget discussion.

Questions SaaS teams ask about open source SIEM

How much does a self-hosted SIEM cost for a SaaS company?

The software license is rarely the main cost. Wazuh is distributed under the GNU General Public License version 2, and OpenSearch is released under the Apache License, Version 2.0, so the recurring spend is infrastructure, storage and staff time. Storage and compute scale with daily ingest and retention, so cloud log volume is the first thing to measure. Detection engineering, alert triage and upgrades add labor that recurs every month. One-time costs include design, source onboarding and dashboard work. When you request a quote, ask for the scope in writing, the assumed daily ingest in gigabytes, the retention tiers, which log sources are included, who maintains detection rules after go-live and what support runs after handover.

How long does a SIEM rollout take, and what does it need from my team?

The timeline depends on the number of log sources, the cloud and Kubernetes layout and how much detection content you want at launch, so ask for a schedule in the written scope rather than relying on a generic figure. Plan for a named technical owner who can grant cloud and cluster access, approve agent deployment, and confirm which accounts and namespaces are in scope. Your engineers will need to review alert routing and decide who receives pages. DeployOpen plans, implements, integrates and documents the platform inside your own cloud accounts, and the written scope sets the milestones.

Can a small team run Wazuh or OpenSearch without a dedicated SOC?

A small team can operate a SIEM, but the work is continuous and should be assigned explicitly. The main recurring tasks are patching the Wazuh release line, which had six 4.14 patch releases between March and October 2026, keeping the OpenSearch cluster within a supported version, reviewing alerts, tuning noisy rules and checking that agents stay connected. OpenSearch versions receive security patches during maintenance but no new features, so upgrade planning is needed. Ask a partner whether they offer a retainer for upgrades and monitoring, and confirm who is on call for a failed indexer or a full disk before you go live.

Does Wazuh satisfy SOC 2 by itself?

No. SOC 2 is an examination of your controls, and the AICPA 2017 Trust Services Criteria require an organization to design and run those controls, not a tool. Wazuh can collect, correlate and alert on events that support the monitoring criteria, including CC7.2 and CC7.3, and its dashboard includes compliance views, but it does not define your policies, incident procedures or review records. Auditors sample evidence over the examination period, so you need documented alert review, tickets, change records and access reviews. A Type 1 report covers control design at a date, while a Type 2 report adds operating effectiveness over a period. Confirm the criteria mapping with your auditor before relying on any tool output.

How do Kubernetes and cloud logs get into the SIEM?

Logs reach the SIEM through agents on hosts, syslog and API collection for cloud and managed services, and forwarding from cluster-level sources. The usual sources are Kubernetes audit logs, runtime events from a tool such as Falco, cloud provider control plane logs and load balancer or identity logs. Wazuh agents run on Linux, Windows and macOS, and agentless collection covers devices that cannot run an agent. Short-lived pods create alert volume, so filter by namespace and workload label before ingest. Confirm with your partner which cloud log types are supported for your provider, how credentials are scoped and where forwarding components run in your clusters.

How long should we keep logs to cover the audit period?

Retention should cover the full SOC 2 examination period plus the time your auditor needs to sample records, and your own contracts or other frameworks may require longer. A SOC 2 Type 2 examination spans a stated period, so keep alerts, audit logs and review evidence for at least that span and confirm the exact window with your auditor. Split retention into hot storage for recent searches and archive for older records, because hot storage drives cost. Ask your partner how index lifecycle policies are set, how log integrity is protected and how restores are tested.

Does an open source SIEM fit ISO 27001 certification?

Yes, a self-hosted SIEM can support the technological controls that ISO/IEC 27001:2022 Annex A describes, including logging and monitoring, but the standard does not require a specific product. Annex A lists 93 controls in four themes, and the technological theme holds 34 of them. Accredited certification bodies certify your organization, not the tool, and certification runs on a three-year cycle with at least one audit every calendar year. Document your logging scope, review routines, access to log data and retention rules, and give the certification body access to that evidence during the audit.

What does DeployOpen do, and what does the auditor do?

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, and it prepares systems, controls and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications. An independent CPA firm performs a SOC 2 examination, and an accredited certification body certifies ISO 27001. DeployOpen's work is defined in a fixed-scope written agreement before it starts, and ongoing support, upgrades and testing are available as retainers. Ask your auditor which evidence they need before implementation begins so the scope reflects it.

How DeployOpen scopes and runs a SaaS SIEM

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts. For a SaaS SIEM, that means agreeing the log sources, ingest and retention limits and evidence requirements in writing first, then building the pipeline and detections your SOC 2 monitoring evidence depends on.

How we scope

Inventory cloud accounts, Kubernetes clusters, SaaS admin logs and identity sources feeding the SIEM.
Agree daily ingest estimates, hot and archive retention and the alert routing your team will use.
Document the written scope, deliverables and timeline before any build work starts, as fixed-scope engagements.

How we build

Deploy Wazuh or OpenSearch in your own cloud account, with agents or log shippers for each agreed source.
Configure parsing, decoders and detection rules mapped to the SOC 2 monitoring criteria in scope.
Test alerting end to end with controlled events and confirm access controls on the logs themselves.

How we hand over

Document architecture, source inventory, retention settings and the alert triage runbook for your team.
Package evidence artifacts such as rule configurations, alert samples and review records for your auditor.
Run a handover session so your engineers can operate, upgrade and tune the platform after go-live.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
Patch Wazuh or OpenSearch releases on a schedule agreed in the retainer, with backups and documented rollback.
Confirm with us during scoping which tuning, new log sources and detection changes sit inside the retainer.