The question behind most security-operations budgets
Almost every organisation past a certain size ends up at the same fork: keep building security monitoring in-house, or hand some or all of it to a provider who runs a security operations centre for a living. The threats are real and the tooling is expensive either way, so the decision usually gets made under pressure, often after an incident or a failed audit, and often without a clear-eyed look at what a SOC actually has to do day to day.
We have sat on both sides of this. We have built and hardened monitoring for a 50-plus server banking estate under Qatar Central Bank oversight, run global alerting for a telecom SaaS platform scaled across AWS, GCP and Azure, and stood up SOC-oriented monitoring for a smaller operator migrating fully into Azure. The right answer is rarely "always build" or "always buy". It depends on what you are defending, how fast you need to respond, and whether you can realistically keep skilled analysts on staff. This article lays out the three delivery models, what separates a useful managed service from an expensive log forwarder, and the questions we ask before committing a client to either path.
What a security operations centre actually does
Strip away the marketing and a SOC has one job: turn a flood of raw telemetry into a small number of decisions someone acts on. That work breaks into stages, and every one of them is a place where in-house programmes quietly fall down.
Telemetry has to be collected from everywhere that matters, which today means endpoints, servers, network devices, identity providers, and every cloud control plane you run. It has to be normalised so a Windows event, a Linux auth log, and an Azure sign-in log can be reasoned about together. Detections have to fire on the patterns that matter, mapped to something like MITRE ATT&CK rather than a vendor's default rule pack. Alerts have to be triaged so that the two that matter are not buried under the four hundred that do not. The real ones have to be investigated with enough context to decide what happened. And then someone has to respond, which at 3 a.m. on a public holiday is the part that separates a monitoring tool from a security operation.
The two numbers that tell you whether any of this is working are mean time to detect and mean time to respond. Every model below should be judged on whether it moves those two numbers, not on how many dashboards it produces.
Three ways to run it
There are really three delivery models, and most of the confusion in vendor conversations comes from people comparing across them as if they were the same product.
In-house SOC
You own the SIEM, you write the detections, and you staff the analyst rota. Full control, full visibility, and full cost. A genuine 24/7 in-house SOC needs somewhere between eight and twelve analysts to cover the shifts sustainably once you account for holidays, sickness, and attrition. For most mid-market organisations that headcount is simply not justifiable, which is why so many "in-house SOCs" are really a SIEM that nobody watches overnight.
Co-managed SIEM
You keep the SIEM and the data, the provider supplies detection engineering and after-hours eyes on glass. This is the model most established security teams underrate. You retain your data, your compliance evidence, and your institutional knowledge, and you buy the one thing that is hardest to hire for: experienced analysts covering the hours your own people cannot. The split has to be written down clearly, or both sides assume the other is watching.
Managed detection and response
The provider brings the platform, the detections, and the analysts, and delivers outcomes rather than tooling. Good MDR is fast to stand up and gives a small team enterprise-grade coverage overnight. The trade-off is portability. Your detection logic and much of your telemetry live in the provider's stack, so leaving later is real work. That is a manageable risk if you go in with eyes open and negotiate data export up front.
Model comparison
| Dimension | In-house SOC | Co-managed SIEM | Full MDR |
|---|---|---|---|
| Who owns the SIEM/data | You | You | Provider |
| Time to meaningful coverage | 6–18 months | 1–3 months | Days to weeks |
| 24/7 analyst coverage | Hard to sustain | Provider fills the gaps | Included |
| Detection engineering | Your team | Shared | Provider |
| Compliance evidence control | Full | Full | Depends on contract |
| Exit / portability | N/A | Straightforward | Requires planning |
| Best fit | Large, regulated, well-funded teams | Teams with a SIEM but no night shift | Small teams needing coverage now |
Why so many in-house programmes stall
The failure modes are consistent across the engagements we have seen, and they are rarely about buying the wrong tool.
Alert fatigue is the first killer. A SIEM shipped with default rules will generate hundreds of low-value alerts a day, analysts learn to close them without reading, and the one that mattered gets closed with the rest. Tuning detections is skilled, ongoing work, and it is the first thing that gets dropped when the team is busy.
Coverage gaps are the second. Attackers do not keep office hours. An in-house team that watches alerts from nine to five has left the sixteen most convenient hours of the day unmonitored, plus weekends. Most serious intrusions we have reviewed after the fact had their initial foothold established well outside business hours.
Staffing is the third, and it is structural rather than temporary. Skilled SOC analysts are scarce and expensive, the work burns people out, and turnover means the detection knowledge in someone's head walks out the door with them. Sustaining a round-the-clock rota year after year is a structurally harder thing than filling any single seat, and it is where most internal programmes eventually run out of road.
The market is not making this easier
The economics have tightened rather than loosened. IDC's tracking of one large regional security-services market showed the total shrinking 6.4% year on year to about USD 2.69 billion for 2024, with the managed security services segment contracting for the first time since IDC began measuring it. Their analysts tied the pullback to budget pressure and to buyers prioritising business projects over security when money is tight, while noting that demand is shifting from on-site services toward remotely delivered, cloud-based managed security. The same report flagged AI as a double-edged sword: it is genuinely improving automation in detection, analysis and response, and it is simultaneously lowering the bar for attackers, which widens the capability gap that most internal teams cannot close by hiring alone.
That framing matches what we see. Cyber Magazine, in its own review of the managed-security market, described the pressure the same way, pointing to agentic AI and geopolitical instability driving threats while hybrid-cloud complexity and data-sovereignty rules raise the bar for defenders. Both signals point at the same conclusion: the volume and sophistication of what has to be watched is rising while budgets and available talent are not, and that gap is exactly what a well-run managed service is meant to fill.
How to tell a real MDR from a log forwarder
The market is crowded, and a fair number of "MDR" offerings are a SIEM with a support ticket queue attached. These are the questions we put to a provider before recommending them to a client.
- Do they respond, or only notify? Ask exactly what happens when a real detection fires at 3 a.m. If the answer is "we email you", that is monitoring, not response. Real MDR contains threats, isolates hosts, disables accounts, and does it inside an agreed window.
- What are their contractual MTTD and MTTR? A serious provider commits to numbers, in writing, with penalties. Vague "rapid response" language is a flag.
- Who writes the detections, and are they mapped to MITRE ATT&CK? You want named coverage of techniques relevant to your environment, updated as threats evolve, not a static vendor rule pack.
- How do they cover your cloud control planes? If you run AWS, Azure or GCP, ask specifically how they ingest and detect against each. Many providers are strong on endpoints and thin on cloud, which is where a growing share of incidents now begin.
- Can you get your data out? Especially for full MDR, negotiate telemetry and detection export before you sign. This is the single biggest determinant of whether you are a customer or a hostage.
- Do they produce audit-ready evidence? If you carry PCI-DSS, ISO 27001, SOC 2 or NIST CSF obligations, the service has to generate the logging and reporting your assessor will ask for, in a form you can hand over.
The compliance angle is not optional
For regulated organisations the build-versus-buy question is partly decided for you. PCI-DSS requires daily log review and file integrity monitoring. ISO 27001 expects logging, monitoring and a working incident-response capability under Annex A. NIST CSF puts Detect and Respond alongside Protect as first-class functions. CIS Controls call out continuous monitoring and audit-log management explicitly. None of these frameworks care whether the capability is in-house or outsourced, but all of them require that it demonstrably exists and produces evidence. In the banking work we did under Qatar Central Bank, PCI-DSS, ISO 27001, CIS and STIG expectations at once, what carried the audits was our ability to prove, on demand, that monitoring and response were operating and effective; ownership of the tooling was beside the point. A managed service that cannot produce that proof is a liability regardless of how good its detections are.
So which model fits
The pattern we recommend to clients is straightforward. A large, well-funded, heavily regulated organisation with the budget for a real analyst rota can justify an in-house SOC and gets the most control from it. A team that already runs a capable SIEM but cannot staff nights and weekends should look hard at co-managed SIEM before spending a year and a fortune trying to build a 24/7 rota that keeps collapsing. A small team that needs real coverage now, and cannot wait twelve to eighteen months for an internal capability to mature, is usually best served by full MDR with a carefully negotiated data-exit clause. The wrong move is the accidental fourth option: a SIEM you bought, half-configured, that nobody is watching after 6 p.m. That is the most expensive way to fail an audit and the most common state we are called in to fix.
How Aydahwa Enterprise Can Help
Aydahwa Enterprise designs and runs security operations for organisations that cannot afford to get detection and response wrong, from banking and telecom to critical national infrastructure. Our team holds Microsoft Cybersecurity Architect Expert certification and works fluently across ISO 27001, PCI-DSS, SOC 2, NIST CSF and CIS Benchmarks, and we have delivered monitoring and response in environments under central-bank and regulatory oversight where the evidence has to stand up to a real assessor.
If you are weighing whether to build, co-manage or outsource, we start by mapping your current coverage honestly, including the gaps, before recommending a model. You can begin with our free cybersecurity self-assessment or work through the cybersecurity readiness checklist to see where you stand today. For SOC design, SIEM tuning, detection engineering and managed detection and response, see our cybersecurity services; for securing the cloud control planes those detections depend on, our cloud services; and for the day-to-day operational backbone around it, our IT support and managed services. When you want a direct conversation about which model fits your risk, budget and compliance obligations, get in touch and we will give you a straight answer rather than a sales pitch.
