Graylog or OpenSearch: when each one fits your SOC
If you run a self-hosted log estate and must choose between a log management layer and a bare search backend with SIEM features, the deciding question is whether your team needs a finished workflow or a set of components it will assemble itself. Graylog fits when centralized log workflows, stream routing, pipelines and a management UI matter more than owning every layer. Streams let you route incoming messages to separate destinations and alert conditions, and pipelines let you parse, enrich and normalize events before they are indexed. Teams with several log sources, shared analysts and limited time to build their own tooling usually get value from this layer. Graylog Open runs on top of OpenSearch or Graylog Data Node, and the search backend versions your install must match are listed in the Graylog compatibility matrix.
OpenSearch with Security Analytics fits when you need Apache-2.0 terms, have in-house engineering capacity, and want Sigma-based detection without adding a separate product. Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types, so your engineers can own the detection content directly. This suits organizations whose policy rules out SSPL, or whose engineers prefer to write and tune rules in version control rather than configure a management layer. The trade-off is that dashboards, routing, retention workflows and alert handling are your responsibility to design, test and document. Confirm which Security Analytics features your OpenSearch version provides before you commit, since the Security Analytics documentation describes the feature set you would be building on.
Three decision drivers should settle the choice. First, license terms: Graylog Open is under SSPL-1.0, which is not OSI approved, so have legal review how your use and any hosting arrangement fall under it before standardizing. Second, which paid Graylog editions you need: index archiving, correlation, reporting and prebuilt Illuminate detection content sit in Graylog Enterprise or Graylog Security, not Graylog Open, so list those requirements and ask for the edition matrix in writing. Third, operating effort: a management layer adds components to patch, back up and upgrade, while an OpenSearch-only design moves that effort into custom content and dashboards. Estimate both against your staff and your sign-off process, and treat any quote from DeployOpen as a function of the written scope for either path.
Which platform fits which scenario
This table maps common team situations to the better fit between Graylog on OpenSearch and OpenSearch with Security Analytics on its own. Read each row for the reason and the condition under which the other option wins. The main takeaway is that Graylog's extra layer pays off when the team needs its log workflow features, while OpenSearch alone suits teams that already operate the engine and want Sigma detection without a second product.
| Scenario | Better fit | Why and when the other option wins |
|---|---|---|
| Centralized log program with many non-security sources | Graylog | Streams, pipelines and index routing suit application, infrastructure and audit logs owned by several teams. OpenSearch alone wins if the team only needs a search backend and will build its own ingest and routing. |
| SOC that needs Sigma detection on OpenSearch | OpenSearch with Security Analytics | Security Analytics matches ingested logs against Sigma rules and records findings without a separate product. Graylog wins if the SOC also needs its alerting and correlation workflow and will accept the paid edition for it. |
| Organization with a strict open-source license policy | OpenSearch | OpenSearch is Apache-2.0, while Graylog Open is SSPL-1.0, which the OSI does not approve. Graylog may still be acceptable if the policy allows source-available licenses, so confirm that with legal. |
| Team that will buy a Graylog edition | Graylog Enterprise or Security | Index archiving, correlation, reporting and prebuilt Illuminate content are paid features that Graylog Open lacks. If the paid features are not needed, OpenSearch with Security Analytics costs less in licensing. |
| Team that already runs OpenSearch clusters | OpenSearch with Security Analytics | Reusing existing clusters, upgrade process and staff skills keeps the stack smaller. Graylog wins only if its workflow features justify another application tier to operate and patch. |
| Team that needs one vendor-supported log workflow | Graylog Enterprise or Security | Graylog bundles its UI, stream rules and alerting with the search backend. Confirm the support terms and upgrade path for your chosen edition in writing before committing. |
| Team that must pin search backend versions tightly | OpenSearch | Graylog 7.2 supports OpenSearch 1.1.x to 3.7.x or Graylog Data Node, so backend choice is constrained by the compatibility matrix. Check that matrix before any version upgrade. |
How Graylog layers on top of a search backend
A Graylog deployment is not a single application. The Graylog server handles ingestion, streams, pipelines and alerting, MongoDB holds its configuration, and a search backend stores and queries the indexed log data. Each layer adds its own upgrade path, sizing curve and backup job, so the operating burden depends as much on the layers as on the features.
Graylog server and its role
The Graylog server receives logs, applies streams and pipeline rules, and runs alerting and the web interface. It is the layer where most day-to-day configuration lives, so changes to streams, rules and inputs are made here rather than in OpenSearch. Check which features your team needs before you commit, because index archiving, correlation, reporting and prebuilt Illuminate detection content sit in the paid Enterprise or Security editions, not Graylog Open. Confirm which edition covers each feature on your list.
MongoDB for configuration
MongoDB stores Graylog configuration such as users, streams, inputs and dashboards, but not the log events themselves. Graylog 7.2 supports MongoDB 7.x through 8.2.x, so the database version is pinned by the Graylog release you choose. Ask your DBA to confirm the replica set layout, backup schedule and restore test, because losing this database loses the platform's configuration even if the search indices survive.
Self-managed OpenSearch as the search backend
Graylog 7.2 can index log data into self-managed OpenSearch from 1.1.x to 3.7.x. Your team then operates a separate OpenSearch cluster with its own node sizing, shard strategy, snapshot repository and security configuration. Version alignment matters: an OpenSearch release outside the supported range blocks a clean Graylog upgrade, so plan OpenSearch upgrades around the compatibility matrix rather than around OpenSearch's own release calendar.
Graylog Data Node as the recommended backend
Graylog Data Node is the search backend Graylog documents as recommended. It removes the need to run and tune a separate OpenSearch cluster, which reduces the number of distinct products your team patches. The trade-off is dependence on Graylog's own packaging and release cadence for the search layer, so confirm with Graylog how Data Node is licensed, supported and sized for your data volume before you choose it over self-managed OpenSearch.
Sizing and backup across layers
Each layer scales differently. The Graylog server grows with event throughput and rule complexity, MongoDB grows slowly with configuration, and the search backend carries nearly all storage and memory demand. Backups must cover MongoDB and the search indices together, and restore tests should confirm that Graylog can reattach to restored indices. Ask any implementation partner for a written backup and restore runbook that names both the MongoDB and search-layer procedures.
OpenSearch with Security Analytics alone
OpenSearch with Security Analytics is a single search-and-detection stack. Ingested logs are matched against prepackaged or custom Sigma rules, findings are recorded, and events are correlated across log types, all with OpenSearch Dashboards as the interface. There is no Graylog server or MongoDB to run, so the operating surface is smaller. The trade-off is that stream routing, pipeline transformations and Graylog's alerting workflow must be rebuilt in OpenSearch tooling or your own code, so confirm the detection coverage and workflow your SOC needs before choosing this path.
Feature comparison from supplied facts
This table sets Graylog on top of OpenSearch against OpenSearch with Security Analytics used on its own, row by row. Read each row with the condition under which it matters, and confirm any capability the supplied sources do not establish with the vendor before you decide.
| Capability | Graylog (with OpenSearch backend) | OpenSearch (Security Analytics on its own) | When it matters |
|---|---|---|---|
| License | Graylog Open is SSPL-1.0 since Graylog 4.0 (2020), not OSI approved. Enterprise and Security are paid editions. | OpenSearch is Apache-2.0, derived from Elasticsearch 7.10.2 and Kibana 7.10.2 for Dashboards. | Matters when legal or procurement must approve the license for an internal or hosted service. Confirm obligations with counsel. |
| Current release lines | Graylog 7.2.0 (released October 12, 2026) is the current line. Graylog 7.2 supports OpenSearch 1.1.x to 3.7.x or Graylog Data Node. | OpenSearch 3.9.0 (released September 29, 2026) is current. The 2.19 line still received 2.19.6 on July 6, 2026. | Matters when you must pin a version for a compliance baseline. Check the compatibility matrix before choosing an OpenSearch version under Graylog. |
| Search backend | Stores configuration in MongoDB 7.x to 8.2.x and indexes logs in OpenSearch or Graylog Data Node, which Graylog documents as recommended. | Indexes and searches data directly. No separate configuration database is listed in the supplied facts. | Matters when you plan to run and back up an extra MongoDB tier. Confirm which backend Graylog support covers for your version. |
| Streams and pipelines | Graylog layers routing (streams) and processing (pipelines) on top of the search index. | Not a native feature of OpenSearch. Routing and transformation are built with ingest tooling or custom code. | Matters when analysts need log routing and parsing rules managed in a UI. Confirm pipeline capabilities for your edition. |
| Alerting and correlation | Alerting is part of the Graylog layer. Correlation is in paid Enterprise or Security editions per Graylog documentation. | Security Analytics matches logs against prepackaged or custom Sigma rules, records findings and correlates them across log types. | Matters when you need Sigma-based detection without a second product. Confirm the correlation scope you need with OpenSearch documentation. |
| Index archiving and reporting | Index archiving and reporting are in paid Graylog Enterprise or Security editions, not Graylog Open. | Not listed as a supplied feature. Confirm archiving and report options in the OpenSearch documentation or with your implementer. | Matters when retention or scheduled reporting is a control requirement. Price these into the Graylog edition decision. |
| Prebuilt detection content | Illuminate prebuilt detection content is in paid Graylog Enterprise or Security editions. | Sigma rule packs are included in Security Analytics. Confirm rule coverage against your log sources. | Matters when a small team needs content on day one. Without Illuminate, expect to write and tune rules yourself. |
| Operating components | Graylog server, MongoDB and the search backend run as separate tiers you install and patch. | OpenSearch cluster and Dashboards run as your own tier. Fewer components if you do not need Graylog's UI layer. | Matters for staffing and upgrade planning. Each extra tier adds patching, backup and monitoring work. |
What SSPL and Apache-2.0 mean for each deployment
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0). Graylog moved to SSPL with Graylog 4.0 in 2020, replacing the GPL v3. SSPL is not approved by the Open Source Initiative, so many procurement policies that accept only OSI-approved licenses will treat it as a special case. For internal use inside your own organization, the license is generally workable, but the SSPL terms on offering the software as a service are the part that needs a lawyer's reading.
- Internal use: Running Graylog Open to collect and search your own logs is the common case, and the SSPL terms are most relevant if you later change how the software is delivered.
- Hosting for customers: If you run a log platform for other companies as a managed service, the SSPL service provisions apply directly and must be reviewed before you launch.
- Procurement policy: Many organizations require OSI-approved licenses for production tooling. Check whether your policy allows exceptions for SSPL and who approves them.
- Feature boundary: Index archiving, correlation, reporting and prebuilt Illuminate detection content sit in paid editions, not in Graylog Open.
- Source access: The license file in the Graylog server repository is the primary text to review, not a summary.
Have counsel review your specific use case against the SSPL text before you commit, especially if the service will be offered to third parties.
Graylog Enterprise and Graylog Security are paid editions. Under Graylog's documentation, index archiving, correlation, reporting and prebuilt Illuminate detection content are in these editions rather than in Graylog Open. Your license and contract govern what you may deploy, so the paid edition terms are a separate question from the SSPL text of the open server code.
- Recurring cost: Subscription fees recur for as long as you use the paid features, so model them as an annual line item.
- Entitlements: Confirm in writing which features each edition includes and how the license counts nodes, data volume or users.
- Change path: Moving from Graylog Open to a paid edition is an upgrade of features, but the terms of the commercial agreement still need review by procurement.
- Support boundary: Vendor support and DeployOpen implementation support are different contracts with different scopes.
- Document the decision: Record which edition you license and why, so auditors can trace the features your controls depend on.
Ask Graylog for the current edition comparison and the commercial terms in writing before you make a purchasing decision.
OpenSearch is licensed under Apache-2.0 and was derived from Elasticsearch 7.10.2, with OpenSearch Dashboards derived from Kibana 7.10.2. Apache-2.0 is an OSI-approved permissive license, so it is usually the easier case for procurement review. Its terms permit use, modification and redistribution, provided you keep the license and notices. OpenSearch Security Analytics is part of the OpenSearch project, so the SIEM capabilities do not require a separate commercial license from the search engine vendor.
- Internal use: Apache-2.0 places few restrictions on running OpenSearch inside your own environment.
- Hosting for customers: Apache-2.0 generally permits commercial hosting, but you must still comply with the notice and attribution terms.
- Procurement policy: Its OSI-approved status typically simplifies the license review, though your own policy still applies.
- Dependencies: Check the licenses of plugins and dashboards you add, because they may carry their own terms.
- Release lines: Confirm which OpenSearch release line your support and patching process covers.
Have counsel confirm the notice and attribution steps for your distribution model, since the license is simple but the obligations still apply.
What drives the running cost of each stack
The running cost of a Graylog stack is spread across more layers than the license line suggests, so start by separating what you pay for once from what recurs. Graylog Open is licensed under SSPL-1.0, so there is no license fee for the Graylog server itself, but you still pay for the infrastructure that hosts the search backend, the MongoDB 7.x to 8.2.x configuration store and the Graylog servers. Search backend capacity (self-managed OpenSearch 1.1.x to 3.7.x or Graylog Data Node) is usually the largest recurring item, and it grows with daily ingest volume, retention period and replica count. Ask the vendor or your own architects to confirm the storage and replica settings in the Graylog index model before you size disks, since those settings drive storage far more than the server count does.
The other recurring costs are people and upgrades. Running two stacks means your team needs skills in OpenSearch index management and cluster operations, plus MongoDB administration and Graylog pipeline and stream work. Upgrades are the cost most often underestimated: the Graylog server, MongoDB and the search backend each follow their own compatibility constraints, so every Graylog release means checking the Graylog compatibility matrix against your current backend version before scheduling work. If you buy Graylog Enterprise or Graylog Security, archiving, correlation, reporting and Illuminate detection content add a recurring subscription cost. Ask the vendor which of these features are included in each edition and whether the price is per node, per volume or per user. A paid Graylog edition is also what makes the extra layer pay for itself, so model that line item against the labor you would otherwise spend building the same capability by hand.
Moving between Graylog and OpenSearch without losing detections
This sequence moves detections from one stack to the other while proving that alerts still fire on the same events before the old system is turned off. The output is a validated cutover with a documented inventory of what moved, what was rebuilt and what was retired.
Inventory sources, streams and index sets
Start by listing every log source, the Graylog streams or index sets that receive it, and the field names each source produces. Record which alerts, dashboards and saved searches depend on each stream. The client's SOC lead and a DeployOpen engineer usually own this step together, with the platform team confirming retention settings. It is done when every source maps to a destination in the target design and no stream is unaccounted for.
Export pipeline rules and alert definitions
Export Graylog pipeline rules, alert conditions, notification targets and dashboards in whatever form the installed version supports, and keep the originals read-only. For the reverse direction, export Security Analytics detectors and custom Sigma rules from OpenSearch. Confirm the export method for your exact version in the Graylog and OpenSearch documentation before relying on it. The output is a versioned inventory with each item tagged as portable, needs translation or must be rebuilt.
Map detections to the target engine
Translate each Graylog alert condition into a Security Analytics detector, or each Security Analytics detector into a Graylog stream rule and alert, and note where the logic cannot be expressed the same way. Sigma content is the most portable format because Security Analytics matches ingested logs against Sigma rules. Field mappings, timestamp handling and correlation windows usually need manual review. The output is a mapping table with one row per detection and a status for each row.
Confirm what transfers and what is rebuilt
Check each category against current documentation: indexed data formats where the target supports them, Sigma content, dashboards, notification channels and user roles. Anything that does not transfer cleanly is rebuilt, and that work is recorded as a line item in the written scope. Historical data is usually reindexed or kept in the old cluster for search rather than copied, so decide this per index set. The output is a signed-off transfer register that the security team and the data owner both accept.
Build the target and run both in parallel
Deploy the target stack in the same environment, forward each source to both platforms through the existing collectors or a fan-out point, and keep the old detections live. Run long enough to cover the normal event mix, including weekend and batch-job traffic, before judging parity. Watch index health, ingest lag and storage growth on both sides. The output is a parallel-run log showing that both stacks receive the same sources without drops.
Validate alert parity against known events
Compare alerts from both stacks for the same time window and reconcile every difference. Replay known test events, such as those from the security testing or cyber range exercises, through each rule to confirm it fires in both places. Record false positives and missed alerts separately, because they have different causes. The output is a parity report signed by the detection owner, with each unmatched alert either fixed or accepted in writing.
Cut over and retire the old stack in stages
Switch notification routing and dashboards to the target one source group at a time, starting with low-impact sources. Keep the old stack read-only for an agreed period so analysts can search historical data. Retire it only after the retention and archive requirements are confirmed by compliance. Confirm the final state in the runbook, including backups and who can restore them. The output is a closed change record and an updated architecture document.
Where Graylog and OpenSearch projects usually run long
Most of the schedule risk in a Graylog or OpenSearch project sits in design decisions made before the first log arrives. The index model and retention design decide how many indices, shards and replicas the search backend carries, how long hot data stays searchable, and what gets moved to cheaper storage. Teams that skip this step usually discover the problem when disk fills or queries slow down. Sizing the search backend follows from those decisions, so ask the implementer to produce the retention table and the sizing worksheet together, and to show the assumptions behind the daily ingest figure. Confirm the supported OpenSearch 1.1.x to 3.7.x range or the Graylog Data Node choice against the Graylog compatibility matrix before buying hardware.
Identity integration and role mapping are the next common source of rework. Graylog roles, OpenSearch security roles and the Security Analytics access model each need a clear mapping from the directory groups your auditors and SOC analysts already use. Plan for least-privilege access to streams and indices, and test that a read-only analyst cannot change alert conditions or pipeline rules. On the Graylog side, parser and pipeline development is usually the longest task. Every new log source needs field extraction, normalization and tests, and the first months after go-live bring a steady flow of new sources and parser tuning. Alert tuning and detection content work for Security Analytics follow the same pattern: Sigma rules must be selected, adapted to your log fields and tested against known-benign activity before alerts reach an on-call rotation.
Plan for three recurring events that lengthen projects: source onboarding, alert tuning and upgrade windows. Graylog and OpenSearch each have their own release cadence, so an upgrade touches the search backend, the configuration store and the rules in use. Validate every upgrade against the controls you must evidence, and keep the evidence (test results, change records and access reviews) as part of the deliverable rather than an afterthought. Ask the implementer to name which controls are being evidenced and who owns each piece of evidence. DeployOpen scopes these items in writing before work starts, including source counts, parser and rule volumes, identity scope and the upgrade approach, so that the quote and the timeline reflect what your environment actually requires.
Questions buyers ask before choosing a log platform
Is Graylog Open enough for a small security team?
Graylog Open can be enough when your main need is central log collection, search and dashboards, and your team can build its own detection workflow on top of the core product. Start with licensing: Graylog Open is licensed under SSPL-1.0, and Graylog documents index archiving, correlation, reporting and prebuilt Illuminate detection content as features of the paid Graylog Enterprise or Graylog Security editions. Ask three questions. How many detections do you need on day one? Must you keep indexed data longer than your current storage supports? Do you have staff who can write, test and tune correlation logic? If the answer to either of the last two is yes, compare the paid editions with the engineering time you would otherwise spend building those capabilities yourself.
What do the paid Graylog editions add over Graylog Open?
Graylog's documentation places index archiving, correlation, reporting and prebuilt Illuminate detection content in the paid Graylog Enterprise or Graylog Security editions. Each edition is a separate commercial decision, so ask Graylog for a written list of what each one includes before you compare them. The license fee is the recurring cost to plan for, and the basis of that fee is something to confirm in writing: ask how it is measured, whether it changes with data volume or node count, and whether support is included. Your own costs also recur, including storage for archived data, the staff time spent tuning detections, and upgrades. Ask for the edition breakdown and the pricing basis together, so you can compare total ownership over the period you plan to run the platform.
Does OpenSearch Security Analytics replace a SIEM?
For some teams it can, because OpenSearch Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types, so OpenSearch can act as a SIEM backend without a separate product. It is still a detection engine and data store. Case handling, triage queues, reporting, and integrations with your ticketing and response tools are work you design and maintain. Test it against your own log sources before you commit. Check which Sigma rules fire on your data, how findings move through triage, and whether your retention meets your audit needs. Teams with a limited set of log sources and in-house detection engineers often find this route workable. Teams that need a packaged analyst workflow should evaluate a full SIEM platform alongside it.
How does SSPL differ from Apache-2.0 for internal use?
For running software inside your own organization, the two licenses often lead to the same practical result, but the terms differ and the difference matters if you offer the platform to others. Apache-2.0 is a permissive license that does not add source disclosure conditions to an internal deployment. SSPL-1.0 is not OSI approved, and it contains a condition aimed at offering the software as a service: a provider that makes the program available to third parties as a service may have to release the source of the surrounding service stack. Internal use is generally outside that condition, but have counsel confirm your position, especially if you run a log service for subsidiaries, customers or partners. Graylog Open is licensed under SSPL-1.0, while OpenSearch is licensed under Apache-2.0.
How much effort does each stack need to run?
Graylog adds a layer, so the effort is in running more parts. Graylog 7.2 stores configuration in MongoDB 7.x to 8.2.x and indexes log data in a search backend, either self-managed OpenSearch or Graylog Data Node, so you patch, back up and size at least two stateful systems plus the Graylog server. An OpenSearch-only build runs one search cluster and its dashboards, but you author the detection content, pipelines and retention policies yourself. The main effort drivers in either design are ingest volume, the number of log sources, retention length, high availability, parsing work for each source, and the number of upgrades you plan each year. Ask for the sizing assumptions in writing, including the volumes and retention periods they are based on, so you can check them against your own traffic.
Can our team run Graylog or OpenSearch without outside help?
Yes, if your team already runs distributed search, MongoDB and log pipelines in production and has time to tune them. The work that tends to need experience is shard and index sizing, index lifecycle management, certificate handling, access control across the stack, and upgrades that touch both the Graylog server and its backend. Build a skills inventory before you choose. Ask who will own sizing, who will write and tune detections, who will handle upgrades and who is on call when ingestion stops. If those roles are thin, you can either hire or contract for specific parts of the work. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and it offers ongoing support and upgrades as retainers.
Does Graylog 7.2 work with the newest OpenSearch release?
Confirm this before you pick versions. The Graylog compatibility range for self-managed OpenSearch in the 7.2 line is 1.1.x to 3.7.x, while OpenSearch 3.9.0 was released on September 29, 2026, and Graylog 7.2.0 was released on October 12, 2026. The newest OpenSearch line may therefore fall outside the documented range. Check the Graylog compatibility matrix before installation, and confirm the MongoDB range as well. Pin the versions you intend to run in your build plan, test every upgrade in a staging environment that mirrors production, and write upgrade windows into the scope so they are owned and budgeted rather than handled ad hoc.
What does a fixed-scope engagement need from our side?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and the quote follows from that written scope, so the scope is where your inputs matter most. Typical client inputs include an inventory of log sources and expected volumes, retention and compliance requirements, identity integration details, network and cloud access inside your environment, named technical and business owners, a decision on which Graylog edition or OpenSearch build to use, a test window, and acceptance criteria for each deliverable. Ask the written scope to state what is excluded as well as what is included. Cost drivers to examine are the number of sources, the number of integrations, the number of environments and the hardening depth you require.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Graylog vs OpenSearch, that means helping you decide whether a Graylog layer on top of OpenSearch earns its place, then building and handing over the option you choose.
How we scope
- We agree scope, deliverables and timelines in writing before any work starts, as most engagements are fixed-scope.
- Scope records which log sources, retention needs, alerting workflows and license terms the Graylog or OpenSearch design must cover.
- We confirm with you which Graylog edition features, such as archiving or Illuminate content, are required before costing the build.
How we build
- We deploy the chosen search backend and log platform in your environment, including configuration of streams, pipelines and alerting where in scope.
- Security Analytics rules or Graylog detections are mapped to your log sources and tested against representative events before go-live.
- Integrations with your identity provider, storage and existing monitoring are built and hardened to the written scope.
How we hand over
- You receive documentation of the architecture, configuration, access model and operating procedures for the delivered platform.
- Compliance-relevant controls and evidence are prepared for your own auditors, who issue any assessment outcome, not DeployOpen.
- Knowledge transfer sessions cover day-to-day operation, index management and how to review and tune alerts.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- Upgrades to new Graylog or OpenSearch releases are planned against the compatibility matrix for your installed versions.
- Security testing of the monitoring stack itself can be scoped separately so detection coverage is checked over time.
