Build or buy a 24/7 firewall NOC: the arithmetic

Our interest in your answer

Bonsai Security runs white-label firewall operations for MSPs. We are one of the options on this page, and we benefit financially when an MSP decides to buy rather than build.

That interest is worth stating rather than managing. A build-versus-buy page published by a seller of one option has an obvious direction to lean, and a reader is entitled to know it before weighing the arithmetic.

Three things follow, and they shape how this page is written.

• The arithmetic is arithmetic. A week has 168 hours. Every headcount figure below is derived from that and from published salary ranges we cite, so you can reproduce every number without trusting us.
• The cases for building are written properly. They come first among the two recommendation sections, and they are the cases where we would tell a prospective partner not to buy from us.
• The provider questions are ones we can be asked. The six questions at the end are the ones we would want a partner to put to us, and a provider that cannot answer them clearly has told you something.

Where a section rests on our own operating experience rather than on arithmetic or a cited source, it says so.

Coverage is arithmetic

A week contains 168 hours. A full-time schedule covers 40 of them.

One seat staffed continuously therefore requires 4.2 full-time engineers. That figure assumes every one of them is available every week they are employed, which no organization achieves. Applying a standard continuous-coverage absence allowance of 1.2 to 1.3, which accounts for annual leave, sickness and training, puts the practical requirement at five to five and a half people for a single seat.

Two engineers on duty at all times, which is the usual answer where a single person cannot safely handle both an incident and the queue, requires 8.4 before the absence allowance and ten to eleven after it.

The reason this matters is that it is invariant. It does not improve with a better rota, a more motivated team or a good year. It is the number of hours in a week divided by the number of hours in a working week, and every alternative arrangement is a decision to provide something other than continuous coverage.

The 4.2 figure is 168 divided by 40. The 1.2 to 1.3 absence allowance is the standard planning range for continuous shift coverage. Both are arithmetic and planning convention rather than measurements of ours.

Three models, three headcounts

Most disputes about the cost of coverage are disputes about which coverage is being priced.

These are the three models an MSP realistically chooses between. The salary band below is the same one for all three, so the difference between the rows is headcount rather than rate.

Headcount is 168 divided by 40, multiplied by the 1.2 to 1.3 absence allowance, and by the number of seats. The salary band applies the 25th to 75th percentile range that ZipRecruiter publishes for a US network security engineer, $104,500 to $143,000, to that headcount. Published US medians for the same role span a wide band: PayScale $99,573, Indeed $116,534, ZipRecruiter $124,948, Salary.com $150,652 and Glassdoor $165,720. Salary figures checked 4 August 2026 against each provider's public US average. These are base salary only. Apply your own employer burden, which we have not estimated because it varies by jurisdiction and by benefits package and you already know yours.

Three observations follow from the table, and each one changes a conversation.

The lightest model is the one most MSPs are actually running. Business hours with an on-call rota is common because it is affordable, and it is frequently sold to the customer as 24/7 coverage. Those two descriptions are different products, and the difference becomes visible during the first overnight incident.

The step from model one to model two is the expensive one. It roughly doubles the headcount, and it is the step that converts an on-call promise into a staffed service. Most MSPs reach it at a customer count where the revenue does not yet support it.

Our own headline figure describes the lightest model. The $340,000 on our homepage sits inside the first row of this table rather than the second. It describes business hours with an on-call rota, which is the model most MSPs would actually build. Full continuous coverage costs considerably more than that, and we would rather state the conservative number and show the working than quote the largest one.

The costs that are not salary

Salary is the largest line in a build and it is not the whole of it.

These are the costs that appear in the second year of an internal operation and rarely appear in the business case for it. None of them are large individually. Together they change the comparison.

This list is drawn from building and running this function ourselves and is our operating experience rather than a survey finding. We publish no percentages for any of these lines, because they vary by market and by how the MSP already operates. Price them from your own payroll and your own tooling contracts.

When building wins

Five cases favor building, and four of them have nothing to do with cost.

You already staff a 24/7 desk

An MSP running continuous coverage for another service has already paid the expensive part. Adding firewall work to a staffed rota is an increment in training and runbooks rather than a new cost base. The arithmetic in this page applies to the first seat, not the second workload on it.

Your contracts require specific people in specific places

Public sector work, defense-adjacent work and some regulated industries require staff in a named jurisdiction, with clearances, or under direct employment. Where a customer contract says that, it decides the question regardless of the economics.

Operations is what you are selling

Some MSPs differentiate on how they operate rather than on what they resell. If the way you run an estate is the reason customers choose you, outsourcing it removes the thing being bought. That is a strategy decision rather than a cost decision, and cost should not overturn it.

Your volume has passed the crossover

Internal cost per device falls as device count rises, because the rota is a fixed cost. A provider's price per device falls more slowly. There is a volume at which internal operations become cheaper per device than any provider will quote, and an MSP approaching it should model both curves rather than assuming the answer holds at every scale.

The work is genuinely unusual

Where an estate is built on uncommon platforms, unusual architectures or bespoke integrations, a provider's standard runbooks may not apply. The onboarding cost then approaches the cost of building the capability, and the provider's advantage is smaller than it appears.

Outside these five, the arithmetic tends to favor buying at the device counts most MSPs operate at. That is a statement about the fixed cost of a rota rather than about the merits of any provider.

When buying wins

Buying wins where the coverage requirement arrives before the volume that pays for it.

This is the ordinary situation for a growing MSP. A customer asks for overnight response on firewalls that were sold with business-hours support. The revenue attached to that request is a fraction of a rota, and the alternative to buying is declining the requirement or promising something an on-call rota may not deliver.

Three further conditions favor it.

• Multi-vendor estates. Maintaining current competence across several firewall platforms is a training cost that scales with the number of platforms rather than the number of devices. A provider carrying that cost across many customers carries it more efficiently.
• Uneven demand. Firewall incidents arrive unevenly, and an internal rota is sized for the peak while being paid for continuously.
• Engineer time has a better use. Where your engineers could be doing project work at a higher margin than overnight monitoring, the comparison is against that margin rather than against zero.

Buying also carries risks worth pricing rather than dismissing. You hold the customer relationship while a third party holds the operational knowledge. Quality is harder to observe than to specify. Exit is harder than entry. And a provider's bad night becomes your bad night in front of your customer. Each of these can be addressed in the contract, and the questions below are where that starts.

The option most MSPs land on

The common outcome is neither of the two options in the title.

Most MSPs keep the work that is close to the customer and buy the coverage that is expensive to staff. In practice that means retaining the customer relationship, the change approval, the architecture decisions and daytime engineering, and buying overnight and weekend coverage plus the monitoring that runs continuously.

That split works because the two halves have different cost structures. Daytime engineering scales with the amount of work. Continuous coverage costs the same whether anything happens or not, and it is the fixed half that a provider can spread across many customers.

Two design decisions make the split work rather than produce two half-services.

Draw the line at a time boundary rather than at a task boundary. Splitting by hours is unambiguous at 3am. Splitting by task type produces a discussion about ownership during the incident, which is the worst moment to have it.

Agree what the provider may change without asking. A provider that must seek approval for every action delivers monitoring rather than operations, and a provider with unlimited authority is a risk. The list of permitted actions is the single most important schedule in the agreement, and it belongs in writing before the first shift.

Six questions for any provider

Put these to every provider you consider, including us.

They are written to be difficult to answer well without a real operation behind them, and the answers differentiate providers more than any capability list.

1. Who is awake at 3am on a Sunday, and where are they? A specific answer describes a rota. A general answer describes an aspiration.
2. What happens when your engineer and mine disagree about a change? The escalation path for a professional disagreement says more about the operation than the escalation path for an outage.
3. How do I get my configurations back if I leave, and in what format? Exit terms are easiest to negotiate before you are a customer.
4. What is not covered? Ask for it in writing. A provider that supplies a clear exclusion list has thought about scope.
5. Who do I call, by name, and how long before somebody senior is involved? Named people and stated times, rather than tier numbers.
6. How would you tell me you had made a mistake? This is the most informative of the six. A provider with a real answer has had the conversation before.

Send the same six to every provider in writing. Where the answers differ substantially, the difference is usually in how the operation actually runs rather than in how it is described.