Wazuh or osquery: when each one is the right choice
Choose Wazuh when the team needs alerting, a central dashboard and compliance views from the start. Wazuh is a full SIEM with four components: the Wazuh indexer stores alerts, the Wazuh server decodes agent data and applies rules, the Wazuh dashboard provides the web interface, and Wazuh agents run on the endpoints. Its ruleset ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK, and the dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. If your auditors or on-call staff expect alerts to arrive in one console, Wazuh is the closer fit. Confirm that the compliance views match your framework's control mapping before you rely on them as evidence.
Choose a fleet manager plus osquery when the main need is answering host questions on demand or on a schedule. osquery exposes the operating system as a relational database, so an analyst can query running processes, open network connections or loaded kernel modules, and osqueryd can run the same queries on a schedule across many hosts. osquery itself has no central server. The README lists third-party fleet managers such as Fleet, Kolide, OSCTRL and Zentral, which the project does not endorse or test, so you would need to select, host and maintain one. That work is lighter than a SIEM only if you do not also need correlation, alert pipelines and a retention store.
The two can also work together. The Wazuh osquery module lets Wazuh agents manage the osquery configuration and collect results, which then reach the Wazuh manager and can generate alerts. This lets a team keep Wazuh for alerting and dashboards while using osquery for deeper host inventory. Before you commit, decide three things: whether alerting and a central dashboard are required, who will write and tune the detection rules, and how many hours a week your team can spend on operating the stack. Ask any vendor or integrator to show, in your environment, how query results become alerts and where they are stored.
Which platform fits which scenario
This table maps common situations to the platform that fits better and the condition that makes that true. Read each row as a starting point: the condition column tells you what would reverse the recommendation. Most teams with a central alerting need will land on Wazuh, while teams that need only ad hoc endpoint queries often start with osquery alone.
| Scenario | Better fit | Condition that makes it hold |
|---|---|---|
| Central alerting on endpoints | Wazuh | You need agents, rules, alert triage and a dashboard in one place, and you have staff to tune alerts and run the indexer, server and dashboard. |
| Ad hoc investigation across hosts | osquery with a fleet manager | Analysts write SQL against live host state and do not need stored alerts, correlation or a SIEM case workflow. |
| Compliance dashboards | Wazuh | You need prebuilt views for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53 in the dashboard, and you accept that the views support evidence gathering rather than certification. |
| Air-gapped sites | Wazuh with offline installation | You can install from the offline guide and use an offline vulnerability repository, and you confirm each component's update path with the vendor before go-live. |
| Small team with no SIEM staff | osquery with a fleet manager, or a managed Wazuh service | You cannot staff alert tuning and platform upkeep; confirm what a managed offering covers before assuming it matches a self-hosted deployment. |
| Existing Wazuh estate | Wazuh, adding the osquery module | Agents already report to a Wazuh server, so enabling the osquery module adds SQL-based collection without a second agent or central server. |
| Mixed Linux, macOS and Windows fleet needing live queries | osquery with a fleet manager | Your main need is querying operating system state on these three platforms, and you can run a separate fleet manager such as Fleet, Kolide, OSCTRL or Zentral. |
How Wazuh and osquery are built and what that means for operations
Wazuh is a multi-component platform with its own storage, analysis and interface, while osquery is an endpoint query engine that holds no fleet state of its own. The cards below separate what each one runs centrally from what your team must build, host and maintain around it.
Wazuh indexer stores the alerts
The Wazuh indexer is the full-text search and analytics engine that stores alerts, and it is an open source fork of OpenSearch. Every alert history, dashboard query and retention decision depends on this node or cluster, so storage sizing is an operating task from day one. Ask your team who owns index lifecycle, snapshots and capacity growth before you commit to a single-host layout.
Wazuh server analyzes agent data
The Wazuh server runs decoders and rules against events sent by agents, then generates alerts and manages agent configuration and upgrades remotely. It can run as a cluster for horizontal scaling, so a growing estate adds server capacity without replacing the design. Confirm which cluster topology your endpoint count needs before you size the hosts.
Wazuh dashboard and compliance views
The Wazuh dashboard is the web interface where analysts review alerts, and it includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. Those views still need your own review of which controls apply to your environment. Treat them as a starting point for evidence collection, not as a compliance determination.
osquery has no central server
osquery is an agent-only query engine: the osqueryi shell runs ad hoc SQL on one host, and the osqueryd daemon runs scheduled queries on each host. Nothing in the project stores results, schedules queries across the fleet or raises alerts. Plan on a separate destination for results and a separate way to push configuration.
Fleet manager adds central control
When you pair osquery with a third-party fleet manager such as Fleet, Kolide, OSCTRL or Zentral, the manager handles enrollment, query packs, results collection and a web interface. The osquery project does not endorse or test these tools, so you own the choice, the upgrades and the hosting of that manager. Confirm its support, licensing and data retention before you rely on it.
Wazuh osquery module bridges both
The Wazuh osquery module lets Wazuh agents manage the osquery configuration and send results to the Wazuh manager, where they can generate alerts. This keeps the full SIEM stack in one place, but it also means osquery operations depend on the Wazuh agent version you run. Test your query packs against your agent release before a fleet-wide change.
How the Wazuh osquery module changes the picture
The Wazuh osquery module changes the question from whether you can run osquery to whether you want its results handled by a full SIEM. Through the module, Wazuh agents manage the osquery configuration and collect osquery results, then send them to the Wazuh manager, which generates alerts from them. Standalone osquery answers queries you ask or schedule on each host, but it does not evaluate those results against detection logic on its own. With the module, the same osquery output can feed the Wazuh ruleset, alert workflows and the Wazuh dashboard, so the endpoint data you already collect becomes something your SOC can triage in one place. The decision is whether that alerting and central view are worth running the platform that provides them.
The trade-off is operational. You gain alerting and a dashboard on osquery data, but you inherit the Wazuh server and the Wazuh indexer, which store alerts and must be sized, patched, backed up and upgraded. Each Wazuh 4.14 patch release is a change window you must plan for. Before committing, confirm which osquery tables and osquery versions the Wazuh osquery module supports in your environment, since table coverage differs between platforms and between osquery releases, and a query you rely on for detection must exist on every endpoint OS you run. Check the Wazuh osquery module documentation against the exact Wazuh and osquery versions in your pilot, and test each detection query on a representative host of each operating system before you rely on its alerts.
Capability comparison: Wazuh against osquery
This table compares what each platform does out of the box, what it needs from you, and where the two overlap. Read it as a scope check: if you need alerting, a central server and compliance views with little assembly, the Wazuh column matters most; if you need ad hoc endpoint queries and have a fleet manager already, the osquery column matters most.
| Capability | Wazuh | osquery |
|---|---|---|
| Core purpose | Full SIEM and XDR: agents, server, indexer and dashboard in one platform | SQL endpoint query framework that exposes OS state as relational tables |
| Rules and alerting | Ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK | No built-in alerting rules; results must be read or forwarded to another system to alert |
| Central server | Wazuh server (clusterable) and indexer store and analyze agent data | No central management server; a third-party fleet manager is needed (confirm your choice) |
| Dashboard | Included Wazuh dashboard with prebuilt views | No dashboard of its own; visualization depends on the fleet manager or your own stack |
| Ad hoc SQL querying | Not the primary interface; investigation happens through alerts and the dashboard | Core feature via the osqueryi interactive shell on each host |
| Scheduled queries | Agents collect and analyze data continuously; configuration is managed remotely | Scheduled through the osqueryd daemon across many hosts |
| File integrity and vulnerability detection | Included, with vulnerability detection from Wazuh CTI or an offline repository | File hashing is queryable; integrity alerting and vulnerability correlation must be built or confirmed in your fleet manager |
| Compliance views | Prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53 | None built in; confirm what your fleet manager or SIEM provides |
| Platform support | Linux, Windows, macOS, Solaris, AIX and HP-UX agents | Linux, macOS and Windows |
| Agentless devices | Supported through syslog collection and periodic API probing (firewalls and similar) | Not a focus; confirm coverage for network devices with your team |
| License | GPL-2.0 with OpenSSL exception for server and agent; Apache-2.0 for indexer and dashboard | Apache-2.0 OR GPL-2.0-only, at your choice |
Licensing and editions for Wazuh and osquery
Wazuh splits its license by component. The Wazuh server and agent are distributed under GPL-2.0 with an OpenSSL linking exception, while the Wazuh indexer and dashboard are Apache-2.0. The core platform does not require a paid edition, so the software cost of the open stack is zero. What you pay for is the infrastructure, the staff who run it, and any managed service you choose to buy. Wazuh Cloud is the vendor's managed option, and its tier prices and terms are published by the vendor, so ask for current figures directly.
- Server and agent under GPL-2.0: Modifying and redistributing these components triggers source-availability duties under the GPL, so legal review matters if you ship a changed agent to third parties.
- Indexer and dashboard under Apache-2.0: These permissive terms are generally simpler to embed in internal portals, but confirm with counsel for your own use case.
- No paid edition for the core: The open components cover the platform, so budget for hosting, storage and operating effort rather than a license line item.
- Wazuh Cloud as a managed option: It moves operations to the vendor, which changes who holds the data and who you contract with, so review the service terms and regions.
- Internal tooling: Calling the Wazuh API from your own scripts or dashboards is usually separate from redistributing Wazuh code, but confirm this interpretation with your legal team.
Before committing, confirm with your counsel how the GPL applies to any Wazuh modifications you plan to distribute, and get the current Wazuh Cloud terms in writing.
osquery is licensed as Apache-2.0 OR GPL-2.0-only, and you may choose whichever license fits your use. This dual choice gives teams flexibility when embedding the agent or its tables into internal tooling. osquery itself has no central management server, so the fleet layer is a separate product with its own license. The README names Fleet (open core), Kolide (commercial), OSCTRL and Zentral (open source) as third-party options that the project does not endorse or test.
- Dual license for osquery: Selecting Apache-2.0 can simplify embedding in proprietary tooling, while GPL-2.0-only applies if you prefer copyleft terms.
- Fleet as open core: Fleet's free tier and its paid features are governed by its own license, so check which capabilities you need before you assume they are free.
- Kolide as commercial: Kolide terms and pricing are set by the vendor and must come from a written quote.
- OSCTRL and Zentral as open source: Confirm each project's license file and maintenance status before you select one for a regulated environment.
- Separate licenses per layer: Your stack will carry at least two licenses, osquery and the fleet manager, so the legal review covers both.
Before you choose a fleet manager, read each project's license file and ask the vendor for its current edition and support terms.
The licensing question for osquery is not only about the agent. A fleet manager, a log pipeline and any internal dashboard each add their own license and their own obligations. This tab covers the combined stack, so you can see how the layers interact when you build a lighter setup or extend an existing one. Licenses for each layer must be reviewed on their own terms, because the osquery dual license does not extend to the fleet product or to the data platform that stores results.
- Layer-by-layer review: List every component that receives, stores or displays osquery results, and record each license separately.
- Open core boundaries: Fleet's open core model means some management features may sit behind a paid tier, so map required features to editions.
- Data platform licensing: The system that stores query results may have its own copyleft or source-available terms, which affect how you can share or modify it.
- Internal tools and APIs: Scripts that consume fleet APIs are usually easier to maintain under permissive licenses, but confirm terms for each product.
- Third-party endorsement: osquery does not endorse or test these fleet managers, so your own testing is part of the selection work.
Before finalizing the stack, ask each vendor for its license text and edition matrix, and have counsel map the obligations across all layers.
The Wazuh osquery module changes the licensing picture because it lets Wazuh agents manage osquery configuration and send results to the Wazuh manager. In this model, osquery sits inside the Wazuh platform rather than beside it, so the Wazuh license terms cover the server and agent that run the module. You still need to confirm how the osquery license applies to the bundled binary and to any custom queries you write. Choosing this path means one vendor for the management layer but also one set of terms to read.
- Bundled behavior under Wazuh: The module is part of the Wazuh agent workflow, so the GPL-2.0 terms of the Wazuh server and agent apply to that integration.
- Osquery binary terms: The osquery component keeps its own Apache-2.0 OR GPL-2.0-only license, which you should note in your compliance inventory.
- Custom query packs: Queries you write are your own work, but confirm ownership and sharing rules with your legal team.
- Fewer contracts: One platform reduces the number of license reviews, although the open stack still needs documented ownership.
- Single-node versus managed: Wazuh Cloud changes who operates the server, so confirm which license and service terms apply to your deployment model.
Before you deploy the module, confirm with the Wazuh documentation which osquery version is bundled and review both license files.
What drives the running cost of each
This table lists the cost components behind a Wazuh deployment and an osquery deployment managed through a fleet manager, showing who is paid, what recurs and what changes the bill. Read it as a checklist for building a like-for-like quote, since the two stacks shift effort between infrastructure, rule tuning and upgrades in different ways.
| Cost component | Wazuh (full SIEM) | osquery with a fleet manager |
|---|---|---|
| Infrastructure | Hosts or VMs for the Wazuh indexer, server and dashboard, sized to endpoint count, alert volume and retention. Confirm sizing with Wazuh's quickstart guidance for your environment. | A fleet manager host and its database, plus any log pipeline you add. osquery itself runs on the endpoints and has no central server of its own. |
| One-time versus recurring | One-time: installation, agent rollout, initial ruleset and dashboard setup. Recurring: indexer storage growth, host capacity and backups. | One-time: fleet manager deployment, query pack design, agent enrollment. Recurring: database and host capacity, log retention and backups. |
| Rule tuning and alert triage | Recurring staff time to suppress noisy built-in rules, tune decoders and triage alerts mapped to MITRE ATT&CK. Usually the largest ongoing effort, so ask the vendor or partner to estimate it against your alert volume. | Recurring staff time to write, schedule and review queries and to build any detection logic outside the platform. Effort depends on how much alerting you build yourself. |
| Upgrades and patch cadence | Wazuh 4.14 shipped patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly every one to two months (Wazuh release notes). Plan a recurring test and rollout cycle for the server, indexer, dashboard and agents. | osquery plans minor releases roughly every two months and marks them stable after about two weeks of testing (osquery README). Fleet manager upgrades and agent updates are a separate track to plan. |
| Managed or support options | Wazuh Cloud is a managed service with dashboard-only access, and support subscriptions are available. Ask Wazuh for current tier pricing and what is included. | Fleet and other third-party managers may offer commercial or support tiers. Confirm the license and support terms with the manager's vendor before you commit. |
| What to request in a quote | Endpoint count by OS, expected alert volume, retention period, number of indexer and server nodes, and a breakdown of upgrade, tuning and triage effort. | Endpoint count by OS, query pack scope, fleet manager hosting model, database sizing, and a breakdown of query authoring, upgrade and triage effort. |
Moving from osquery to Wazuh, or from Wazuh to a fleet manager and osquery
This sequence shows how an existing osquery estate moves into Wazuh's alerting and dashboards, or how a Wazuh estate narrows to osquery under a third-party fleet manager, with each stage ending in a check you can verify before the old collector is retired.
Inventory existing osquery packs and queries
The security or platform engineer who owns the current osquery deployment lists every pack, scheduled query, interval and destination, along with the alert or report each result feeds. Export the configuration from the osquery fleet manager or from the
osquery.conffiles on hosts, and record which queries are ad hoc through osqueryi and which run on a schedule through osqueryd. The step is complete when every query has an owner, a purpose and a consumer, and any query nobody can explain is marked for removal rather than migration.Decide what moves to Wazuh rules or the osquery module
The team sorts the inventory into three groups: queries that should keep running as osquery results through the Wazuh osquery module, detections that already map to Wazuh's built-in rules and decoders, and detections that need new custom rules. The Wazuh osquery module lets Wazuh agents manage the osquery configuration and send results to the Wazuh manager to generate alerts, so queries that feed alerting are the ones to carry across. The step closes with a written mapping from each old query to its new home, reviewed by the detection owner.
Deploy the Wazuh server and indexer
The platform team installs the Wazuh indexer, server and dashboard using one of the documented deployment options, sized for the endpoint count and retention the security team has agreed. Confirm the topology against the Wazuh components documentation before installing, and confirm the current 4.14 patch level from the release notes. The step is done when the dashboard loads, the server reports healthy, and a test agent can register and appear in the agent list.
Migrate agent configuration to Wazuh
Engineers enroll a pilot group of endpoints as Wazuh agents and push the osquery configuration through the Wazuh agent settings so that the query schedule matches the mapping from the earlier step. Keep the existing osquery collector running on the same hosts while the pilot runs, and compare results from both paths on a sample of machines. Check that agent upgrades and configuration changes are managed from the Wazuh server before extending the rollout. The step is complete when the pilot hosts report the same operating system state through both collectors.
Rebuild alert logic and dashboards
Alert thresholds, correlation logic, dashboard panels and ticketing hooks do not transfer automatically from a fleet manager, so detection engineers recreate them as Wazuh rules, decoders and dashboard views. Map each rule to its MITRE ATT&CK technique where the Wazuh ruleset already provides one, and document any custom rule separately with its test case. The step is done when each retired alert has an equivalent Wazuh alert that fired on a known test event.
Run both collectors in parallel
The team keeps the old osquery path and the Wazuh path active on the same endpoint set for a period agreed in the change plan, and the security operations lead reviews the two outputs for gaps and false positives. Differences in query results, missed events or noisy alerts are logged against the mapping, and each one is either fixed or accepted by the owner. The parallel run ends when the reviewer signs off that the Wazuh alerts cover every detection on the inventory.
Retire the old collector
Once the parallel run is signed off, the team removes the old osquery daemon, its configuration and any fleet manager agent from the endpoints, and archives the final configuration and results for audit purposes. Confirm that no host still sends data to the retired fleet manager and that its credentials and certificates are revoked. The step is complete when a host inventory check shows Wazuh as the only collector and the retirement record is filed with the change ticket.
Where implementation projects usually run long
The Wazuh side of this comparison usually slips on sizing and tuning rather than installation. The Wazuh indexer stores alerts and runs on OpenSearch-derived search, so storage and node count need to be settled against your expected endpoint count and retention before the first agent is enrolled, not after the dashboards fill up. Rule tuning is the other long tail: the Wazuh ruleset ships over 3,000 built-in rules and decoders, and most teams spend weeks deciding which alert levels page someone, which rules to suppress per agent group, and which custom decoders are needed for in-house application logs. Confirm with DeployOpen's scope document who owns the written rule baseline, and whether single sign-on through the Wazuh single sign-on documentation needs to be wired to your identity provider during the same window, since identity changes often wait on a separate approval queue.
The osquery side slips in different places. Because osquery has no central server of its own, you must choose and host a fleet manager such as Fleet, OSCTRL or Zentral, and that choice drives authentication, TLS, backup and upgrade work that is easy to underestimate. The fleet manager is not endorsed or tested by the osquery project, so confirm its support model and release cadence before you commit. A second slip is the query library: scheduled queries for process, socket and kernel module state need owners, false-positive review and a change process, or the library drifts from what the security team can actually act on. Config distribution at scale is the third risk. An illustrative case would be a fleet of several thousand hosts where a single pack change reaches only part of the estate because enrollment secrets, platform differences between Linux, macOS and Windows, and agent restarts were not tested together. Ask for a staged rollout plan and a rollback step in any quote.
Questions buyers ask before choosing Wazuh or osquery
Can osquery alone send alerts when a host changes?
No. osquery runs SQL queries against a host, and osqueryd can run them on a schedule, but the project has no central management server and no alerting engine of its own. Results go to a destination you configure, so something else must evaluate them and notify someone. Teams usually add a third-party fleet manager such as Fleet, Kolide, OSCTRL or Zentral to distribute queries and collect results, then a SIEM or log pipeline to match those results against detection logic. The osquery README names these managers, but the project does not endorse or test them, so confirm each one's license, alerting features and support terms. Ask any implementer which component owns the detection logic and where alert history is stored.
What does a Wazuh deployment need to run?
A Wazuh deployment has four components: the Wazuh indexer, which stores and searches alerts; the Wazuh server, which decodes and analyzes agent data with rules; the Wazuh dashboard; and agents on endpoints. The indexer is an open source fork of OpenSearch. Wazuh documents several install paths, including all-in-one and step-by-step installs, an OVA, Docker, Kubernetes, an offline guide, Ansible and Puppet. Host count, CPU, memory and disk depend on endpoint count, event volume and retention, so confirm sizing against the current Wazuh documentation and a pilot in your own environment. Plan for indexer disk growth, certificate handling between components, and a patch routine, since the 4.14 line shipped six patch releases between March and October 2026.
Does the Wazuh osquery module replace a separate fleet manager?
For a team already running Wazuh, it covers much of the configuration and collection work. The Wazuh osquery module lets Wazuh agents manage the osquery configuration and collect its results, then sends them to the Wazuh manager, which generates alerts. That gives you one central point for osquery policy without adding Fleet, Kolide, OSCTRL or Zentral. It does not turn Wazuh into an interactive live-query console. Confirm which osquery versions the module supports, how query packs are versioned and deployed, how ad hoc questions are issued across a fleet, and how results are retained in the indexer. If you need fleet-wide interactive investigation with a dedicated query interface, evaluate a fleet manager alongside Wazuh before assuming the module meets that need.
How do cost and effort compare for Wazuh and osquery?
Both projects are open source, so the license itself carries no fee, and the total cost sits in infrastructure and people. A Wazuh deployment pays for indexer and server hosts, storage that grows with retention, and staff who tune rules and decoders, run upgrades and manage certificates. An osquery deployment pays for a fleet manager host and its database, a destination for results, and a SIEM or pipeline if you need alerting, plus staff who write queries and maintain packs. Commercial fleet managers and Wazuh Cloud each carry vendor-set fees. Ask every quote to list the hosts, storage for each retention period, support tiers, and who performs upgrades. DeployOpen quotes follow from a written scope.
Can our team run Wazuh or osquery without outside help?
It depends on the skills and hours you can commit, more than on the software itself. Wazuh asks for Linux administration, indexer operations, certificate and upgrade work, and rule tuning to control alert noise. osquery asks for SQL fluency, query design, a fleet manager and an alert path. Both move on regular cadences: osquery plans minor releases roughly every two months, and Wazuh's 4.14 patches arrived about every one to two months in 2026. Someone must own that cycle. Many teams run the platform internally and buy specific help for design, hardening, upgrades or testing. DeployOpen plans, implements, hardens, upgrades and documents self-hosted platforms inside your infrastructure, typically under fixed-scope agreements, with retainers for ongoing support.
How hard is it to switch between Wazuh and osquery later?
The direction matters. Moving from osquery to Wazuh is generally the simpler path, because the Wazuh osquery module brings osquery results into the Wazuh manager and existing query definitions can be reviewed and reused. Moving off Wazuh removes a full stack: agents, server, indexer data, dashboards and alert history. Detection content written as Wazuh rules and decoders is specific to Wazuh, and the built-in set of more than 3,000 rules and decoders, with its MITRE ATT&CK mappings, is only portable through re-expression. Plan a parallel run, an export path for historical alerts, and a rebuild of custom detections in the new tool. Ask any vendor or implementer which artifacts export in open formats and which must be rebuilt.
Which operating systems can Wazuh and osquery monitor?
osquery runs on Linux, macOS and Windows. Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so Wazuh reaches older Unix estates that osquery does not list in its README. Wazuh also monitors agentless devices such as firewalls through syslog collection and periodic API probing. Supported platforms are not the same as full feature parity, so confirm which osquery tables and Wazuh modules work on your exact OS versions. If your estate is mostly Linux, Windows and macOS, both options cover the operating systems, and the decision shifts to alerting, operations and staffing.
Do the Wazuh and osquery licenses allow our use?
Both use open source licenses that generally permit self-hosted internal use, but their terms differ. Wazuh server and agent are GPL-2.0 with an OpenSSL linking exception, and the Wazuh indexer and dashboard are Apache-2.0. osquery is licensed Apache-2.0 OR GPL-2.0-only, so you may choose either license. Under GPL-2.0, distributing modified binaries carries source obligations, so get legal review if you ship or embed either component in a product. Internal use and distribution are treated differently, so confirm with counsel. Check the fleet manager and any commercial add-ons separately, because their licenses are independent of both projects.
How DeployOpen helps you choose and implement
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so the Wazuh vs osquery decision can be tested against your endpoints, network and existing tooling before anything is built. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which endpoints, operating systems and network segments need coverage and which need only ad hoc queries
- Define whether alerting, rules and a dashboard are required, or whether scheduled queries feeding an existing tool are enough
- Record the written scope, deliverables and timeline before any installation begins, with a quote that follows from that scope
How we build
- Deploy the Wazuh components or a fleet manager with osquery in your own cloud accounts, data centers or air-gapped networks
- Enable the Wazuh osquery module or configure osquery packs, then validate that results reach the intended alerts or dashboards
- Test agent coverage, query load and alert quality on representative hosts, and document the results for your review
How we hand over
- Document configuration, agent enrollment steps, query definitions and the ownership of each alert or result stream
- Walk your operations and security teams through daily triage, agent upgrades and how to add or retire endpoints
- Deliver a runbook that states which components you operate, which licenses apply and what each component stores and where
How we support
- Offer ongoing support, upgrades and continuous review as a retainer, scoped in writing alongside the initial work
- Plan version upgrades against the Wazuh and osquery release cadence and test them before they reach production hosts
- Revisit the platform choice if your endpoint count, compliance evidence needs or query workload change over time
