Security Onion cost of ownership: free vs Pro

What does Security Onion cost of ownership include beyond the free download?

The Security Onion software is free to download, but the cost of running it sits in hardware, storage, detection tuning and analyst time. If you are weighing a Security Onion build against a commercial network security monitoring or SIEM product, the comparison has to cover those recurring items over the life of the deployment, not the price of the ISO. Most teams start this analysis when they are launching a new monitoring program, replacing a tool that has stopped meeting their needs, or facing the end of life of an existing 2.4 installation. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024, so any sensor or grid still on those versions needs a migration or rebuild budget in addition to steady-state operations.

The short answer on who models the cost is that many organizations build the first estimate in-house and then bring in a partner for the parts that are hard to size without experience, such as node counts for a distributed grid, storage for the retention period they need, and the tuning effort for a new detection set. Teams that do this well can ask a partner for a fixed-scope quote with the assumptions written out, so the internal model and the external quote can be compared line by line. Either way, the estimate should be built from your own traffic, retention and staffing figures rather than from generic sizing.

The platform's own hardware documentation sets minimum specifications for each role: a standalone node needs at least 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, a manager or search node needs 4 cores and 16 GB RAM, and a sensor needs 4 cores, 12 GB RAM and 2 NICs. These are minimums, and production sizing depends on link speed, packet capture volume, retention and the number of search nodes in a distributed design. Security Onion supports only x86-64 processors, so the hardware line in your model should reflect that constraint. Ask whether any hardware in your estate is already available for reuse, because that changes the one-time cost more than any other single input.

The Security Onion Pro edition is a separately licensed paid product sold on 1 to 5 year terms. The repository itself is licensed under the Elastic License 2.0, which is a source-available license rather than an OSI-approved open-source license, so the terms that govern the free software and the terms that govern Pro are different documents. Pro adds OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. Before you budget for Pro, confirm with Security Onion Solutions which features your environment needs, the term length they offer, and whether the license terms allow your intended use. Your legal and procurement teams should review the ELv2 text directly.

Build your model as a list of one-time and recurring items. One-time items include hardware or cloud instances, the initial build, sensor placement and tap installation, and migration work if you are moving from 2.4 or another tool. Recurring items include storage growth as retention grows, hardware refresh, ongoing detection tuning, the analyst hours needed to triage alerts, upgrade testing on a matching test grid, and any Pro subscription. For each item, record who pays for it, what drives it up or down, and what you would ask a vendor or partner to quote in writing. The clearest signal that the model is complete is that every cost line has an owner and a stated assumption behind it.

What a Security Onion cost of ownership review covers

A cost of ownership review turns an open-source Security Onion grid into a written model that separates what you pay once from what recurs. Each card below is a deliverable or check that feeds that model, so the free edition and Pro can be compared on the same stated assumptions.

Node sizing sheet for each role

We size the manager, search and sensor nodes against the traffic, retention and link speeds you state, using the minimum hardware published for each role as the floor. The sheet lists the CPU, memory, storage and NIC assumptions for every node so you can see which hardware line items drive the total. Sizing should be re-checked after any change in traffic or retention.

Storage and retention model

Storage for indexed events and Suricata full packet capture often grows faster than compute, so we model retention periods separately for logs and packet data. The model shows how each retention choice changes disk capacity on search and sensor nodes. Ask for the retention figures you expect to keep, because they change the hardware quote more than most other inputs.

Feature-by-feature edition comparison

We list the features your organization needs and compare what the free edition provides with what Security Onion Pro adds, such as OIDC single sign-on, LUKS encryption, FIPS mode, OS STIG compliance and professional support. Each Pro feature is tied to a control, audit or access requirement in your environment, so the subscription is justified by need rather than by preference. Confirm current Pro terms directly with Security Onion Solutions.

Tuning and analyst effort estimate

We estimate the ongoing effort for detection tuning in the Detections interface, including Suricata suppressions and thresholds, Sigma filters and alert review. The estimate states the alert volume and team size it assumes, since noisy rules are the most common source of unplanned analyst time. It also notes which tasks you can keep in-house and which you may want to buy as support.

One-time versus recurring cost split

We separate one-time items such as hardware purchase, initial implementation, network tap installation and first-time tuning from recurring items such as subscription terms, hosting, storage growth, rule maintenance and upgrade testing. This split lets finance compare the first year with later years on the same basis. Each recurring line names its driver so changes can be traced.

Quote questions for the vendor

We produce a list of questions to put to Security Onion Solutions, covering Pro licensing terms, support scope, supported distributions, upgrade paths from 2.4 to 3 and any airgap requirements. The list is written so each answer can be entered directly into the cost model. Vendor prices are set by Security Onion Solutions, and this review produces the written scope that a quote is compared against.

What drives Security Onion cost and how to keep each one down

This table lists the cost and effort drivers that change Security Onion total cost of ownership in both the free edition and Pro. Each row explains why a driver moves cost and gives one practical way to keep it down. Published minimums are 4 cores, 24 GB RAM and 200 GB storage for standalone, 4 cores and 16 GB RAM for manager or search, and 4 cores, 12 GB RAM and 2 NICs for sensor, but production sizing will be higher, so size from measured traffic.

Driver	Why it moves cost	How to keep it down
Number of sensors and link speed	Each sensor needs its own hardware and NICs, and faster links need more capture capacity and storage.	Place sensors on the links that matter most first, then size each one to measured traffic.
Number of search nodes and retention period	Indexing load and storage grow with data volume on each search node and with the number of days retained.	Set retention by data class and add search nodes only when measured indexing or query load requires it.
Standalone versus distributed design	Standalone combines roles on one node, while distributed adds separate manager, sensor and search machines to build, patch and monitor.	Use standalone for evaluation or a small scope, and plan a distributed grid for production.
Number of log sources and Elastic agents	Each integration adds ingest volume, parsing work and storage on search nodes, and each needs upkeep.	Enable only sources that feed detections or investigations, and remove integrations nobody queries.
Detection tuning volume	Noisy Suricata, Sigma and YARA rules create alerts that analysts must triage, and tuning takes engineer time.	Use suppressions, thresholds and Sigma custom filters in the Detections interface to cut noise early.
Air-gapped operation	Offline installs depend on ISO media carrying packages and rules, plus internal handling of each update cycle.	Set a fixed media cadence and test each soup update from new ISO media on a matching test grid first.
Compliance needs (FIPS, STIG, LUKS)	FIPS mode, OS STIG compliance and LUKS encryption are Pro features, so these requirements can decide the edition.	Confirm with your assessor which controls apply, and buy Pro only for the features those controls need.
SSO and identity integration	OIDC single sign-on is a Pro feature and adds identity provider configuration, testing and role mapping work.	Use local console accounts while the team is small, and move to OIDC when access reviews require it.
Analyst headcount	Triage, tuning and investigation time is often the largest recurring cost and grows with alert volume and team size.	Reduce alert volume through tuning, and ask for a documented workload estimate tied to your alert counts.

When Pro features are worth paying for and when the free edition is enough

The free edition is enough when none of your controls, contracts or internal policies require a feature that only Security Onion Pro includes. Pro adds nine capabilities on top of the open edition: OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. Each one answers a specific question, so the decision should start from the question rather than from the feature list.

Single sign-on is the first question to answer. If analysts already sign in through an OIDC identity provider and your access reviews depend on that provider, Pro's OIDC integration lets you remove separate Console passwords from the picture. If analysts are few and access is managed through a small set of local accounts that your team can review and disable quickly, the free edition's local accounts may be sufficient. Ask your identity team how joiners, movers and leavers are handled today, because a Console account that outlives its owner is a finding an assessor will notice.

Encryption at rest and FIPS mode are usually driven by written requirements rather than preference. Ask your assessor which control IDs in your framework require encryption of stored sensor and search data, and whether those controls accept your current disk-level or volume-level approach. For FIPS mode, confirm whether a contract, customer requirement or accreditation boundary names it explicitly. Do not assume Pro is required for either: some environments already meet encryption requirements through full-disk encryption at the infrastructure layer, and the assessor's answer decides which path you need.

OS STIG compliance, the API, external notifications, Manager of Managers and the MCP server are integration and scale decisions. Ask whether your hardening baseline is a published STIG that auditors will check against, whether your ticketing or paging tools need alerts pushed from Security Onion, and whether you will operate several grids that need central management. Treat the Onion AI assistant and professional support as operating decisions: weigh them against how many people on your team can own the platform without vendor help. Request the Pro price in writing from Security Onion Solutions, including the term length from one to five years, and compare it against your internal analyst time.

How a cost model moves from assumptions to a signed scope

This sequence turns rough assumptions about traffic, coverage and retention into a written cost model that separates one-time and recurring lines, so the scope can be reviewed and signed with no open cost questions. Each phase produces a named output that feeds the next one.

Confirm traffic, sensor placement and retention goals
Start by documenting the network segments to be monitored, the expected traffic volume on each, and the link speeds at each tap or SPAN point. Record where sensors will sit, including east-west and egress coverage, and how long alerts, logs and full packet capture must be kept. The output is a short discovery record that names every sensor location and retention target. It is done when the client's network and security owners have confirmed it in writing.
Size manager, search and sensor nodes
Map the discovery record onto a Distributed design with one manager node, sensor nodes and search nodes, the topology the Security Onion architecture docs recommend for production. Compare each role against the published minimum hardware for that role, then adjust cores, memory, storage and NIC count for the observed traffic and retention. The output is a node list with roles, specifications and storage estimates, flagged where the sizing depends on figures the client still has to supply. It is done when each node has a documented basis for its size.
Decide the edition with the Pro feature list
Compare the free edition against the Pro feature list: OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, the MCP server, the Onion AI assistant and professional support. For each feature, write down whether a stated requirement in the client's policy or control set needs it, and whether the team can meet that requirement another way. The output is an edition decision per feature, with the reasons recorded. It is done when every Pro item is either justified or explicitly excluded.
Estimate tuning and analyst time
Estimate the detection work the deployment will need: reviewing NIDS rules loaded into Suricata, building suppressions and thresholds, adding Sigma rules and custom filters, and setting up YARA rules for file analysis in the Detections interface. Estimate the analyst hours for alert triage, onboarding of log sources and Elastic agent integrations, and any documentation or playbook work. The output is a labeled effort estimate by role, with the assumptions behind it. It is done when the client has reviewed the assumptions and agreed which of them they can verify.
Request Pro terms from Security Onion Solutions
If the edition decision includes Pro, prepare a quote request for Security Onion Solutions that lists the chosen features, the number of nodes, the term length and the support expectations. Pro is sold on 1 to 5 year terms, so ask for pricing for each term length the client is considering. Ask the vendor to state what is included in professional support and whether any terms apply to airgap or high-availability designs. The output is written vendor terms that can be placed next to the other cost lines. It is done when the vendor's quote is in hand and its terms have been checked against the requirements.
Write the cost model with one-time and recurring lines
Combine the node sizing, edition terms, implementation effort, tuning estimate and ongoing support into a single cost model. Split each line into one-time items, such as hardware, storage, installation and initial tuning, and recurring items, such as Pro subscription renewal, storage growth, analyst time and support retainers. Show which line is paid to whom, whether to Security Onion Solutions, a hardware vendor, a partner or the client's own staff. The output is a written model in which every line states its basis and what would move it up or down. It is done when each line can be traced to a discovery record, a sizing decision or a vendor term.
Review the model before the scope is signed
Walk the cost model with the CISO, platform owner and procurement contact, and check it against the discovery record and the edition decision. Confirm which assumptions remain open, such as traffic growth or retention changes, and agree how they will be resolved and who pays if they shift. Reconcile the model against the written scope, which sets the deliverables and the timeline agreed in writing before work starts. The output is an approved cost model and a fixed scope ready for signature. It is done when the reviewers have signed off every open assumption.

Which parts of the cost model your team can own and which to outsource

This table splits the Security Onion cost model into its component tasks and shows which skills each one needs and whether teams usually keep it in-house or hand it to a partner. Read each row as a question of who has the skill and the time to answer it accurately for your network. Most teams keep the recurring analyst and tuning work in-house and outsource the one-time sizing and feature mapping decisions that are hardest to get right without prior experience.

Cost model task	Skill required	Usually kept in-house or outsourced
Traffic and sensor placement analysis	Network engineering	Often outsourced for the initial design, then kept in-house as network changes
Node sizing and storage math	Linux administration, Elastic and storage sizing	Often outsourced for the first sizing, kept in-house for ongoing capacity reviews
Pro versus free feature mapping	Security operations management, security architecture	Usually decided jointly, with the partner preparing the feature map
Compliance mapping to features	Compliance	Usually outsourced to the partner, with internal owners approving the mapping
Quote negotiation questions	Security operations management, procurement	Usually kept in-house, with partner input on scope
Tuning effort estimation	Security operations management, detection engineering	Often outsourced for the initial estimate, kept in-house for steady-state tuning
Analyst time forecasting	Security operations management	Usually kept in-house, because it depends on your own alert volume and staffing

What commonly skews a Security Onion cost estimate

Most Security Onion estimates go wrong at a few predictable points: sizing inputs, version lifecycle dates, operating assumptions and the timing of the Pro decision. Each card names one pattern and the check that prevents it. Review them before accepting any quote, because several of these errors only surface months after the grid is live.

Sizing from minimum specs

Minimum hardware figures, such as 16 GB RAM for a manager or search node, describe a node that starts. They do not describe sustained packet rates, alert volume or query load. Search node storage grows with daily event volume multiplied by the days of retention you need, so storage is often the largest recurring line. Ask for sizing built from sensor link speed, measured or projected traffic and retention per data type, with storage shown as a recurring cost.

Free edition treated as zero cost

The free edition has no license fee, but the grid still needs hardware or cloud instances, storage, backups, patching time and monitoring. These charges recur for as long as the platform runs. Build a running cost line for each node role and for the staff who operate the grid, then compare Pro terms on the same basis so the decision reflects the full picture.

Version and end of life timing

Version 3 supports only Oracle Linux 9, so an estimate built on another operating system needs a new base image or a rebuild. Security Onion 2.4 reaches end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024. A 2.4 install on Oracle Linux 9 can upgrade to 3 after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install. Confirm the operating system and version before costing any migration.

Manager outage treated as a delay

In a distributed grid, search nodes stop indexing when they cannot reach Redis on the manager. Sensors may keep capturing traffic while new events stop becoming searchable. Include manager downtime in the impact estimate, price any receiver nodes for pipeline redundancy and load balancing, and ask for a failure test that shows what happens to indexing and capture during a manager outage.

Analyst tuning time set to zero

New detections generate noise until they are tuned. Tuning covers modify, suppress and threshold changes for NIDS rules, custom filters for Sigma rules, and triage of the alerts that remain. Estimate analyst hours each week through the first months and at a lower level afterward, and name the role that owns rule changes once the implementer's work ends.

Pro decision deferred until audit

Pro adds features such as OIDC single sign-on, LUKS encryption, FIPS mode and OS STIG compliance. Enabling them after a compliance evidence request means reworking accounts, storage and host configuration while the assessment is already underway. Decide which controls the assessment will need before the build, then confirm with the vendor which edition provides each one and what its term costs.

What recurs after go-live in a Security Onion deployment

The recurring cost of Security Onion is spread across several lines, and most of them are easy to miss in a free-versus-Pro comparison because the software license is only one of them. Hosting is the first. Manager, search and sensor nodes need power, cooling, rack space or cloud compute for as long as they run, and sensors are often placed where capacity is already tight. Storage is the second and usually the largest. Search nodes hold indexed events and sensors hold Suricata full packet capture, so the volume grows with traffic and with each extra day of retention. Your retention targets set that curve, so ask the partner or your own engineers to show the calculation behind the storage line in any quote. Pro subscriptions are the third line. Security Onion Pro is sold on 1 to 5 year terms, so the renewal date and the uplift applied at renewal belong in your budget model from the start. Confirm with the vendor whether a renewal price is fixed for the term or reviewed at renewal, and whether Pro features such as OIDC single sign-on, FIPS mode and OS STIG compliance are priced per node, per deployment or per seat. Those answers determine whether adding a search node later changes your license cost. Maintenance is the fourth group, and it is the one most often underestimated. Routine updates run through the soup tool, and each update needs a check on a matching test grid before it reaches production. Rule and component maintenance covers NIDS, Sigma and YARA content, which changes as detections are added, modified or suppressed in the Detections interface. Analyst time spent triaging alerts, writing suppressions and reviewing thresholds recurs for as long as the grid is in use, and it rises when log sources change or when the alert volume is high.

Separate these from the one-time items. The initial build, hardware purchase, the first deployment and tuning, any migration from another monitoring tool, and Pro onboarding are one-time costs. The full-version upgrade path from 2.4 to 3 on Oracle Linux 9 is also a one-time project, because it includes moving full packet capture from Stenographer to Suricata and validating the result. Once that project is complete, the soup updates that follow are recurring work. Keep the two in separate lines in your model so that a future major version change is not mistaken for routine maintenance. Retainers are the final recurring line when you choose them. Ongoing support, scheduled upgrades and continuous testing can be bought as retainers, and their scope, response expectations and hours should be written into the agreement. Professional support included with Security Onion Pro is a separate item from any partner retainer, so confirm which responsibilities each one covers. If you intend to run the grid with your own staff, budget for their time instead, and record which tasks they own, such as watching end-of-life dates, reviewing release notes and rehearsing rollback.

Before you accept any quote, request written recurring-cost assumptions. Ask for the expected retention period and daily data volume that the storage figure is based on, the node count and sizing for each role, the renewal terms and uplift for Pro, the frequency of upgrade and test cycles, the expected analyst hours for tuning, and the scope and notice period for any retainer. Ask what happens to these figures if traffic grows by a meaningful amount or if the grid moves to a larger deployment type. A quote that cannot state these assumptions is not yet comparable with another quote or with an internal estimate.

How the cost picture changes by starting point and environment

Security Onion is listed in the AWS, Azure and Google Cloud marketplaces alongside an ISO for on-premises installs. In a marketplace build, the cloud provider bills for the compute instances, block storage and network that the nodes use, so the largest recurring line is usually infrastructure you rent by the hour and by the gigabyte rather than hardware you buy once. The software edition you choose does not change those provider charges.

Main cost shifts:

Compute and storage are metered: sensor, search and manager sizing translates directly into instance and disk charges that recur for as long as the grid runs.
Packet capture grows storage costs: full packet capture and indexed data consume disk, so retention settings have a direct monthly effect.
Egress and cross-zone traffic: traffic between nodes, to analysts and to external notification targets may carry provider charges. Confirm how your traffic will flow.
Pro licensing is separate: a Pro term adds a paid license on top of provider charges, and its term length affects annual spend.

Confirm with the platform owner: the current provider pricing for the instance types and storage you plan to use, which marketplace listing terms apply, and whether the Pro license is billed through the marketplace or directly.

What your team needs to provide before a cost model can be finished

A Security Onion cost model is only as reliable as the inputs behind it, and most of those inputs come from your own network and security teams. Start with traffic estimates for each monitored segment, stated as average and peak throughput along with the link speed of each segment. Pair those figures with sensor placement options: which switches can provide SPAN ports, which segments can take a network tap, and whether your team has spare switch ports or tap budget. The minimum hardware figures in the Security Onion hardware documentation set the floor for each role. They do not size a deployment, so treat them as a starting point. Confirm every traffic figure with your network team before anyone relies on a number from this model.

Next, provide the retention targets and the log source inventory. Retention should be set separately for full packet capture, network metadata from Zeek and Suricata, and ingested logs, because each data type consumes storage on a different role. Ask for the number of days each data type must stay searchable and the number that must stay available for investigations or regulatory requests. The log source inventory should list every source you intend to forward, with its approximate daily volume, its collection method (Elastic Fleet agent, syslog, cloud API or other), and a named owner. Sources without an owner tend to be added late, which changes the sizing after hardware has already been bought.

People and identity decide the rest of the model. Give the expected number of analysts, how many shifts they cover, and whether monitoring is staffed around the clock or only during business hours. That determines whether the cost sits mainly in the platform or in analyst time spent on detection tuning and triage. If Pro single sign-on is under consideration, supply the identity provider details: the product in use, whether it supports OpenID Connect, the groups that map to analyst roles, and who administers it. Compliance scope belongs here too. List the frameworks in scope and the control references your assessors will use, and state which of those controls Security Onion would need to evidence. FIPS mode and OS STIG compliance are Pro features, so the scope list determines whether they are a requirement or an option.

Hosting and procurement constraints come next. Record where the platform must run: a cloud marketplace image in AWS, Azure or Google Cloud, or an ISO installed on-premises. State whether the network must be air gapped, since full installs without internet access use the ISO and the soup update tool in airgap mode. Security Onion 3.0.0 supports only Oracle Linux 9 and only x86-64 processors, so confirm that your hardware and image standards meet both requirements. Finally, name one owner each for the edition decision, the hardware decision and the retention decision, and record the date each decision is needed. A model without named owners tends to stall at the first disagreement about storage or licensing terms.

Common questions about Security Onion cost and Pro

Is Security Onion free to download and run?

Yes, you can download and run Security Onion at no license fee, but it is not a zero-cost platform. The repository is licensed under the Elastic License 2.0, a source-available license that is not an OSI-approved open-source license, so have counsel review its terms against your intended use, including any plan to embed or redistribute it. Your ongoing costs remain: server or cloud hardware, storage for logs and full packet capture, network taps, staff time for detection tuning and upgrades, and any support contract you choose. Build these into the cost model from the start, because they recur for as long as the platform runs.

How much does Security Onion Pro cost?

Pricing for Security Onion Pro comes from Security Onion Solutions in writing, and DeployOpen does not set or quote it. Pro is sold on terms of 1 to 5 years, so ask for the price for each term length you are considering and whether it is billed annually or up front. Ask whether the quote depends on node count, deployment type or other sizing inputs, and what happens to pricing at renewal. Ask what the professional support terms include in writing. Compare the quote with the internal effort you would need to build the same capabilities yourself. DeployOpen can scope and quote the implementation separately, based on a written scope.

What does Security Onion Pro add that the free edition lacks?

Pro adds OIDC single sign-on to the Security Onion Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. Check the current feature list on the Security Onion Pro page before you decide, because editions change. Then match each feature to a real control requirement in your environment. For example, if your identity policy requires central sign-on, SSO may justify the cost on its own, while a lab grid may not need FIPS mode or STIG compliance (illustrative). Record which features you need and why, so the decision holds up in a review.

How much hardware does a Security Onion deployment need?

The published minimums are a starting point for planning. A standalone node needs 4 cores, 24 GB RAM, 200 GB storage and 2 NICs. A manager or search node needs 4 cores and 16 GB RAM, and a sensor needs 4 cores, 12 GB RAM and 2 NICs. Only x86-64 processors are supported. Production sizing depends mainly on traffic volume, the links you monitor, how much full packet capture you keep and how long you retain logs. Model those inputs with your network and SOC teams before you buy hardware. The recommended production design is Distributed, with a manager node, one or more sensor nodes and one or more search nodes.

How long does a Security Onion cost model take?

The duration is set in the written scope agreed before work starts, and no fixed timeline applies to every environment. The length depends on how many sensor sites you have, how much traffic and log data needs sizing, how many interviews with network, cloud and SOC teams are required, and whether you can reuse existing hardware. Ask for the proposed timeline, the list of deliverables, the inputs you must supply and the review points where you check draft figures. Most engagements are fixed-scope, so the agreed deliverables and dates become the basis for planning and for comparing proposals.

Can our analysts set up Security Onion themselves?

Yes, for simple cases, such as a small standalone evaluation or a single site with a few sensors. A capable team can install a standalone node, use the Detections interface to modify, suppress and threshold NIDS rules, and manage Sigma and YARA rules. Larger distributed grids with several sensors, search node scaling, airgap updates and SSO integration need experience with Linux administration, network packet capture, Elasticsearch, Suricata, Zeek and change control. Assess those skills honestly against your team's available time, because tuning and upgrades recur throughout the life of the platform.

What does a Security Onion engagement need from our team?

The work needs defined inputs before a credible cost model can be produced. Typical inputs include a network diagram showing the links you want to monitor, link speeds, expected traffic volumes, retention requirements for logs and packet capture, and the hosting model, such as a cloud marketplace image, an on-premises ISO or an airgap install. If you want SSO, provide details of the identity provider. Also provide your existing tools and log sources, and name the people who will approve sizing, access and change decisions. Gaps in these inputs tend to widen the estimate, so confirm them in the written scope.

Does a partner issue audit or compliance certification for Security Onion?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies issue those. For Pro features such as FIPS mode or OS STIG compliance, the evidence you collect shows how the system is configured, and the assessor decides whether that meets the requirement. Confirm with your assessor which evidence they will accept before you configure the system, and record that expectation in the written scope.

How DeployOpen scopes, delivers and hands over a Security Onion cost model

DeployOpen builds the Security Onion cost model around your own environment, not a generic estimate. We separate the free edition's hardware, storage and staff costs from any Pro features you decide to pay for, then document every assumption so your team can challenge it before a decision is made.

How we scope

Written scope lists the deployment type, node roles and sensor locations the cost model assumes.
Scope records which Pro features are costed as options, such as SSO, FIPS, STIG and Manager of Managers.
Engagements are fixed-scope, so the cost model's inputs and deliverables are agreed in writing before work starts.

How we build

We size manager, search and sensor hardware against the published minimums and your traffic and retention targets.
We separate one-time costs, such as implementation and first-year tuning, from recurring costs like storage growth and analyst time.
We test each cost driver with you, including link speed, retention length and the Oracle Linux 9 requirement for version 3.

How we hand over

You receive a documented cost model with assumptions, formulas and the sources behind each hardware and licence figure.
The handover explains which inputs change costs up or down, so your finance and security teams can rerun the model.
We walk through the quote questions to ask any vendor or partner, so the comparison between free and Pro is like-for-like.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, priced separately from the cost model.
Retainer scope covers keeping the cost model current when editions, end-of-life dates or hardware needs change.
Security Onion Pro support is a separate contract from DeployOpen support, so we confirm which party covers which issue.

Security Onion cost of ownership: free versus Pro