Google Security Operations vs OpenSearch: which SIEM fits your team
Choose Google Security Operations if your team wants Google to run the search, storage and detection service and you have limited platform staff to operate it. Choose self-hosted OpenSearch with Security Analytics if you need the data, indices and retention settings inside your own environment and have engineers who will own the cluster, detectors and upgrades. Neither option is a drop-in copy of the other: SecOps bundles ingestion, normalization, detection and SOAR under one contract, while OpenSearch gives you a search and analytics engine and a security plugin that you assemble into a SIEM.
Google SecOps fits teams where operational load is the constraint. Google hosts the search, you do not size clusters or manage shard layouts, and the vendor's detection content and parsers arrive with the service. The trade-off is that cost follows ingestion volume and the retention you buy, so a renewal or a growth in log sources changes the bill directly. OpenSearch fits when you want fixed infrastructure costs you can plan, retention you set by policy, and data that stays in accounts and data centers you control. It also suits teams that already run OpenSearch or Elasticsearch for other workloads. Security Analytics brings detectors, Sigma-based rules and correlation, but you own the tuning, the parser and field mapping work for each log source, and the on-call rota for the cluster itself.
The decision turns on four questions. First, staffing: who will maintain indices, Data Prepper pipelines, Security Analytics content and OpenSearch upgrades, given that the project releases a new minor version about every eight weeks. Second, retention: which log types need long hot or cold retention and what storage that implies. Third, existing log sources: whether your forwarders, cloud audit logs and endpoint agents can feed OpenSearch cleanly or need custom mapping. Fourth, compliance evidence: which control families need records from the SIEM, and whether your assessor expects specific audit or access-log outputs. Confirm each answer against your own environment and with the assessor before you choose.
Which option fits which scenario
This table matches common situations to the platform that usually fits better, along with the condition that tips the decision. Read each row against your own staffing, data residency rules, retention targets and existing tooling. Most teams find that the deciding factor is who will operate the platform, not the feature list.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small SOC with no platform engineers | Google Security Operations, or a managed OpenSearch service with an implementation partner | Your team cannot staff ongoing cluster upgrades, index lifecycle work and detector tuning, and the budget covers a managed service or retainer |
| Regulated team that must keep logs in its own cloud account or data center | Self-hosted OpenSearch with Security Analytics | Your policy requires log data, indices and access controls to stay inside your own accounts, and you have engineers who can own TLS, backups and role mapping |
| Long retention needs measured in years | Self-hosted OpenSearch with tiered storage you size yourself | Retention is driven by regulation or investigation needs, and you can fund storage growth and confirm restore procedures with your auditors |
| Team already running OpenSearch or Elasticsearch | Self-hosted OpenSearch | You have existing clusters, dashboards and operators who know the stack, so the added work is mainly detectors, Sigma rules and pipeline changes |
| Team that relies on SecOps threat intelligence content | Google Security Operations | Detections and curated intelligence feeds are central to your workflow, and you can accept that equivalent content must be sourced, written or licensed separately for OpenSearch |
| Team migrating from Splunk or Sentinel with Data Prepper or Fluent Bit pipelines | Self-hosted OpenSearch | Your sources already ship through open collectors, and you are willing to rebuild parsers and dashboards rather than carry vendor-specific pipelines forward |
| Team that needs a vendor-run SLA and single support contract | Google Security Operations | Your procurement requires one accountable vendor for uptime and incident response, which OpenSearch does not provide on its own |
How retention and data location change when you self-host
In Google Security Operations, retention is a contract term, set by the package you buy and the data period it includes. Your team does not decide how long events stay searchable; the subscription does. Self-hosted OpenSearch reverses that. Retention becomes a design decision the team owns: how many indices you keep, how they are rolled over, how long hot and warm data stays on fast storage, and when older indices are deleted or moved. Index State Management policies and the storage you provision set those limits. Before you migrate, confirm the retention your compliance obligations require, then size storage for that period plus headroom for replicas and growth. Check the exact lifecycle features in the OpenSearch version you plan to run against the OpenSearch releases page, since maintenance rules and version support change.
Data location also moves from a vendor region to infrastructure you choose. With SecOps, logs are processed and stored in Google's environment under the terms of your agreement. With OpenSearch, the indexed events, snapshots and the Security plugin's audit logs sit on nodes and object storage in your cloud account, data center or air-gapped network. The key question shifts from "where does the vendor store it" to "who can read the disks, the snapshot repository and the TLS certificates." Ask who holds the encryption keys for disks and snapshots, who administers the cluster and who can impersonate users. OpenSearch Security provides role-based access, document and field-level security, field masking, user impersonation controls and audit logs, so define those roles and their approval paths in writing.
A regulated buyer should document four things before cutover: a retention schedule per log source tied to the legal or policy basis for each period, a data location and access map showing every node, snapshot store and backup copy, a key management record covering who controls encryption and rotation, and a deletion procedure that proves old indices and snapshots are gone. DeployOpen prepares these systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work. Ask your assessor early which evidence they expect, and treat the retention schedule as an operational runbook that someone on your team will execute and test.
What OpenSearch leaves to your engineering team
OpenSearch gives you the search engine, the dashboards and the Security Analytics detection features under Apache 2.0, but it does not run the platform for you. The cards below list the recurring work that replaces what a managed SecOps service handles, who usually owns each area, and what to confirm before you commit.
Cluster sizing and tuning
Node count, shard layout, heap and disk sizing decide whether searches and detections keep up with your log volume. Nothing in a self-hosted OpenSearch deployment sizes itself, so someone must measure ingest rate, query load and shard counts against the hardware you actually buy. The platform or SRE team usually owns this, and it should be re-checked whenever a new log source is added. Ask your DeployOpen or internal team for a written sizing method and a load test before production.
Index lifecycle and retention
Retention in SecOps is set by contract, but in OpenSearch it is a storage decision you make. Index lifecycle policies control rollover, age-based deletion and any move to cheaper storage, and each choice changes disk cost and how far back analysts can search. The security engineering lead should set retention per log type, and compliance should sign off on it in writing. Confirm the retention periods your regulators require before writing any policy.
Ingestion pipeline ownership
Something must collect, parse and deliver logs from every source into OpenSearch. Data Prepper or Fluent Bit replace the Bindplane collectors and forwarders you may run today, and each source needs a mapping, a parser and a test. Parser drift after a vendor update is a common cause of silent detection gaps. The data engineering or SOC engineering team should own pipeline configuration, with a monitored dead-letter path for events that fail to parse.
Security hardening and TLS
The OpenSearch Security plugin provides TLS for node and client traffic, role-based access control, field-level security, audit logs and several authentication backends including SAML, OpenID Connect and LDAP. Your team must configure these, rotate certificates, restrict roles and keep the audit trail reviewable. The security engineering team usually owns hardening, and an independent test should verify it. Confirm which authentication backend your identity provider supports before you design access.
Upgrade cadence and version support
New OpenSearch minor versions arrive about every eight weeks, and each line stays under maintenance for a limited time. During maintenance a line gets bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, so a stale cluster is a security exposure. The platform team should schedule upgrades, test them in a non-production copy and plan rolling upgrades, and should confirm the support window for the version they deploy.
Detection content maintenance
Detectors, Sigma rules and dashboards from SecOps do not carry over automatically. Your detection engineers must translate, test and tune each rule against real events, retire noisy ones and document coverage against the threats you care about. Detection content is the part of the platform that changes most often and the part most directly tied to incident outcomes. The SOC lead should own a review cycle with a named owner for each rule family.
What drives cost on each side
On the Google Security Operations side, the main recurring cost is the subscription itself, which is sold in packages priced on ingestion, with Unit overages when volume exceeds what the package includes. Retention beyond the period included in your package, and BigQuery export (which is an Enterprise Plus feature), are separate line items that you should not assume are covered. Ask your Google Cloud account team for the exact package tier, the ingestion volume it is priced against, how overages are metered, what retention period is included, and whether the BigQuery export you need requires a higher tier. Each of these changes the bill as your log volume grows, so model the cost at your projected volume and at your peak.
With OpenSearch, the software carries no license fee under Apache 2.0, so the recurring costs are the infrastructure that runs it, the storage for the retention you choose, and the staff time to operate it. Storage cost is driven directly by the retention periods you set per index and by replica count, which you decide. Compute cost depends on ingestion rate, query load and the number of nodes you need for your Security Analytics detectors. One-time costs include the migration, porting detection content to Security Analytics detectors and Sigma rules, pipeline work with Data Prepper or Fluent Bit, and building dashboards. Recurring work includes version upgrades, which OpenSearch ships about every eight weeks, and security patching during the maintenance window of each version.
When you request a quote from a DeployOpen-style implementation partner or from your internal team, ask for each item as a separate line: one-time migration and detection porting, infrastructure sizing for your daily volume and chosen retention, storage growth per year, staff hours for run operations, and the upgrade cadence you expect to fund. Ask who owns on-call for the cluster and who is accountable for patching. Compare the total over the same retention period on both sides, since Google's cost is tied to what is kept in its service and OpenSearch's cost is tied to what you keep on your own storage. Confirm these figures in writing before you decide, because the subscription side and the self-hosted side scale in different ways.
What a move from Google SecOps to OpenSearch involves
The sequence turns SecOps log search and detections into an OpenSearch stack you size, secure and operate yourself, with history preserved and both platforms overlapping until the cutover is verified. Each phase produces an artifact that the next phase depends on.
Inventory log sources and detection content
Your team lists every log source sending data to SecOps, the parsers and forwarders that normalize it, and every YARA-L rule, dashboard, saved search and response playbook that depends on it. Owners are assigned for each item, and the inventory is reviewed against what analysts actually use. The step is done when each source has a named owner, a log format, a destination decision and a status for every detection, so nothing is lost silently at cutover. Ask Google for the exact export options available under your contract before finalizing the list.
Design the index and retention model
Your architects decide how logs map to indices, how fields are typed and mapped, which data stays hot for search and which moves to cheaper storage, and how long each class of log must be kept for investigations and compliance. Retention is set by your own policy and storage budget rather than by a contract tier, so the design must state the storage needed for each retention period. The step closes with a written index and lifecycle design that has been tested against a sample of real events.
Stand up the OpenSearch cluster
Platform engineers deploy OpenSearch in your environment using one of the documented install methods, such as Docker, Helm, the Kubernetes Operator, packages or the Ansible playbook, and size nodes, shards and snapshot storage to the design from the previous step. They enable the Security plugin, configure TLS, connect the identity provider through SAML, OpenID Connect or LDAP, and set role-based access. The step is done when the cluster passes health checks, a snapshot restores successfully, and access is limited to the roles defined for analysts and administrators.
Rebuild ingestion with Data Prepper or Fluent Bit
Engineers replace the SecOps forwarders and Bindplane collectors with pipelines built on Data Prepper or Fluent Bit, reproducing the parsing and field normalization that the SecOps parsers performed. Each log type is tested with sample events and compared field by field against the data already in SecOps, including timestamps and enrichment. The step is complete when each in-scope source delivers events to the correct index with fields that match what the detections and dashboards expect.
Port detections to Security Analytics and Sigma
Detection engineers translate each YARA-L rule into Sigma rules where the logic fits, then load them into Security Analytics as detectors mapped to the right log types. Rules that depend on SecOps-specific features, such as entity behavior analytics or curated detections, need a documented replacement or an accepted gap. Each rule is tested against replayed events to confirm it fires on known-bad samples and stays quiet on benign activity. The step is done when every rule has a status of ported, replaced or retired, with the reason recorded.
Rebuild dashboards and alert routing
Analysts and engineers recreate the SecOps dashboards and saved searches in OpenSearch Dashboards, then connect alerts to the ticketing, paging and response channels your SOC already uses. Access rules, including document-level and field-level security for sensitive data, are checked against the roles defined earlier. The step closes when each dashboard shows the same figures as its SecOps counterpart on the same test period and each alert reaches the correct queue.
Run both platforms in parallel
Your SOC runs SecOps and OpenSearch side by side, with the same sources feeding both, so analysts can compare alert volumes, false positive rates and investigation results before relying on the new stack. Differences are logged and resolved, and any gap that cannot be closed is accepted in writing by the risk owner. Parallel running ends when the SOC agrees that the OpenSearch detections cover the agreed scope and that operating procedures have been rehearsed.
Export history before the Data Period ends
Before the SecOps subscription or data retention window ends, the team exports the raw logs, normalized events, rules and parsers it is entitled to take, and loads the history it must keep into OpenSearch snapshots or long-term storage. Export format, volume and extraction time depend on the data period and on which export features your package includes, so confirm these with Google in writing well before the deadline. The step is done when exported data has been restored and searched in the target environment and the export record is retained for audit.
Questions buyers ask before switching to OpenSearch
What does switching from Google SecOps to OpenSearch cost?
The software itself has no license fee, because OpenSearch is released under the Apache License, Version 2.0, and its FAQ does not describe a paid edition. The cost sits in the components you pay for: compute and storage for the indexers and dashboards, the storage that holds the retention you choose, the engineering time to build ingestion and detections, and any outside help you buy. Google SecOps costs are set by ingestion-based packages and overages, so your bill will not fall linearly with the switch. Ask any partner for a quote that separates one-time work (design, migration, content translation) from recurring work (hosting, patching, rule tuning) and states the assumptions for daily log volume and retention.
How long does a move from SecOps to OpenSearch take?
The pace is set by the number of log sources, how many YARA-L detections and parsers must be rebuilt, how much history you must keep, and whether you run both platforms in parallel. Each of those drivers adds work in its own way. Log sources with clean structured output are quick to repoint, while custom parsers and detections need testing against real events. Keeping history also depends on your data period in SecOps, so start the export early. A written scope should list these items and the acceptance tests for each, which is more useful than any general duration.
Can our internal team migrate to OpenSearch without outside help?
Many teams can, but the work spans several skill sets. The team needs experience with index design, Data Prepper or Fluent Bit pipelines, role-based access in the OpenSearch Security plugin, and Security Analytics detectors. Without someone who has run Elasticsearch-family clusters, the first months often go to tuning shards and retention rather than detection content. Consider a fixed-scope engagement for the design and cutover while your analysts keep ownership of detections. DeployOpen implements, hardens and documents these platforms in your environment under written scope, so you can compare that option against an internal plan.
How many people does a self-hosted OpenSearch SIEM stack need?
Staffing depends on data volume, the number of clusters, your availability targets and how much content you build yourself. At minimum you need someone who owns cluster operations (upgrades, snapshots, capacity), someone who owns ingestion and parsing, and analysts who write and tune detections. OpenSearch versions move through maintenance on a cycle, with new minor releases about every eight weeks, so patching is recurring work. Ask a provider to show who covers each role, and what happens during on-call and upgrade windows, before accepting a headcount estimate.
Does OpenSearch replace SecOps threat intelligence?
No, OpenSearch is a search and analytics engine, so it does not supply threat intelligence feeds or curated detection content by itself. Security Analytics gives you detectors and Sigma-based rules that you load and tune, and the OpenSearch Security plugin controls who can see the results. Feeds, IOC enrichment and vendor-curated content must come from separate sources you subscribe to or build. Confirm the exact feed integrations and content coverage you need with the vendor or community project, and list them as separate line items in your migration scope.
How do we keep historical logs while the SecOps subscription still runs?
Start exporting before the subscription ends and before any data period in SecOps lapses. Export raw logs where you can, because normalized events may not replay cleanly into a new schema. Load that history into dated indexes in OpenSearch, and use snapshots so the archive can be restored and verified. Run both platforms in parallel for a defined window so analysts can compare alerts. Ask for a written retention plan that names the source, the target index design, the snapshot location and a restore test. Confirm the Google export options and limits with Google before you rely on them.
Does OpenSearch give us the access controls auditors expect?
OpenSearch Security provides role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic. It supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token authentication backends. These controls help you show access separation, but they do not make a deployment compliant by themselves. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any audit report or attestation.
Hosting models and identity implications
Running OpenSearch yourself means choosing how it is deployed, who signs in, what each analyst can see, and where the evidence of those decisions lives. These cards cover the choices that most change how a Google Security Operations replacement behaves in your environment. Confirm regional and sovereignty requirements with your own environment before you pick a hosting model.
Choosing a deployment method
OpenSearch documents installation with Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, an Ansible playbook and Windows. Containers and Kubernetes suit teams that already run those platforms, while packages and Ansible fit hosts managed by configuration tooling. Pick the method your operations team can patch on schedule, because the cluster must follow OpenSearch's minor release cadence and its maintenance windows. Ask your DeployOpen scope to name the method and the upgrade path in writing.
Kubernetes operator and Helm
The OpenSearch Kubernetes Operator and Helm charts manage node pools, scaling and rolling changes as declared resources. This matters for a SIEM because index storage, node count and upgrades are the costs and risks that grow with log volume. Check whether your platform team already owns persistent volume classes, backup tooling and node labels for data tiers. Without those, the operator adds moving parts rather than removing them.
Single sign-on backends
The Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. In a SecOps replacement, analysts usually expect the same identity provider they use today, so the choice of backend decides whether offboarding a person in the directory also removes their search access. Map every analyst group to a backend before cutover, and test a revoked account against the cluster, not only against the identity provider.
Role and field-level access
Role-based access control, document-level security, field-level security and field masking let you limit which events and which fields each analyst sees. Tier-one staff may need authentication logs without personal identifiers, while investigators need full records. Write these roles from a list of log sources and data classes, and review them against your access policy. Confirm with your compliance lead how masking is evidenced, because the cluster settings are only part of the proof.
Audit logs and impersonation
The Security plugin provides audit logs, TLS for node and client traffic, and user impersonation. Audit logs answer who queried what and when, which matters when an investigation depends on search history. Decide where audit records are stored, who can read them, and how long they are kept, since they should not be readable by the analysts they monitor. Confirm the audit categories you need against the plugin documentation before you rely on them as evidence.
Residency and evidence collection
Moving from a SaaS SecOps tenant to your own cluster changes where log data, indices, snapshots and audit records physically sit, and who operates them. Google Security Operations data is held in the service's regions under its terms, while your cluster is under your cloud or data center controls. Confirm regional and sovereignty requirements with your own environment and legal team, then document the storage location, snapshot targets and operator access. DeployOpen prepares these controls and evidence for your assessor, but does not issue the attestation.
How this decision affects audit evidence
When SecOps is the platform, much of your audit evidence for log collection, access and retention comes from the vendor's console, contract terms and retention settings, and your team mostly exports what it is shown. When you run OpenSearch with Security Analytics, you become the producer of that evidence. Assessors will ask you to show that every log source is collected, that the pipeline has not silently dropped events, that access to the indices is restricted to named roles, and that the retention period is enforced in configuration rather than assumed. Each of those answers now lives in your own systems, so you need to design for it before go-live rather than reconstruct it at audit time.
Start with three artifacts. First, the OpenSearch Security plugin provides audit logs and role-based access control, including document-level and field-level security and field masking, so confirm which audit categories you enable, where those logs are shipped, and who can change them. Second, collect the index lifecycle settings and snapshot records that prove retention is what your policy states. Third, keep the Data Prepper or Fluent Bit configuration under version control, so you can show how a log source was onboarded and when it changed. Ask your assessor early which evidence format they accept, for example exported configuration, screenshots or query output, because that choice changes how you store it.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, and they will decide whether your evidence is sufficient for the framework you are assessed against. Confirm with your auditor which control requirements apply to your environment and which of them they expect to test directly. Then agree in writing which evidence artifacts a readiness engagement will produce, who owns each one after handover, and how often each must be refreshed.
How DeployOpen helps you decide and move
DeployOpen plans and implements self-hosted OpenSearch with Security Analytics inside your own cloud accounts, data centers or air-gapped networks. We start with a written scope that matches your retention, detection and compliance needs against what Google Security Operations provides today.
How we scope
- We inventory the log sources, Bindplane collectors and detection content you rely on in Google Security Operations today.
- We define retention periods, index design and the Security Analytics detectors and Sigma rules that must work after cutover.
- Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before any build work starts.
How we build
- We deploy the OpenSearch cluster, Dashboards and Security plugin in your environment using the install method your team already runs.
- We configure Data Prepper or Fluent Bit pipelines, index lifecycle policies and role-based access controls for each log type.
- We test detections against sample events from your own sources and document where results differ from SecOps behavior.
How we hand over
- We document the architecture, pipeline configurations, index and retention settings, and detector inventory for your engineers.
- We deliver runbooks for upgrades, rolling version changes and backup and restore, so your team can operate the stack independently.
- We walk your SOC and platform staff through dashboards, alert triage and the open items that remain after migration.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
- We can prepare systems, controls and evidence for compliance assessments, while independent auditors issue any attestation.
- Ask us to confirm current OpenSearch maintenance status and version plans against the releases page before scheduling an upgrade.
