Cybersecurity
In-house or managed SOC? Budget for the work each model leaves behind
Compare internal, managed and hybrid security operations on the same responsibilities, coverage hours and response authority. Include retained work and transition costs.

At a glance
- Cost the operating responsibilities rather than comparing analyst salaries with a service fee.
- Model coverage, incident surge and customer decisions explicitly.
- Prove the handover before removing the previous arrangement.
One continuously staffed analyst position requires 8,760 hours of cover in a 365-day year. That is the starting point for a CISO considering an internal security operations centre, before allowing for a second simultaneous incident, specialist investigation or the engineering needed to keep the service working.
Outsourcing can change who supplies that capacity. It does not remove every responsibility around it. The useful comparison is an internal, managed or hybrid operating model performing the same work, with the same authority and the same access to the business.
Start with the service the organisation needs
Define which business services and security signals need attention, during which hours, and what response must be possible. Separate routine alert handling from a sustained incident. A team that can review the normal queue may not be able to investigate an intrusion for several days while maintaining that queue.
Include detection engineering, telemetry maintenance, platform administration, investigation, containment, recovery coordination and service-owner communication. Some of these activities can sit outside the SOC, but they still need capacity and a clear handover. If an application team owns a log source, someone must notice when that source stops supplying usable events.
NIST’s incident-response guidance, SP 800-61 Revision 3, recognises internal staff, contracted providers and assistance available when needed. It describes outsourcing as a division of responsibilities that should be defined in the contract, including information flows, coordination and authority to act. Use that division to build the comparison, rather than assuming a service name defines the whole arrangement.
Compare the same responsibilities
The following are operating choices to resolve in a proposal, rather than universal descriptions of every provider.
| Responsibility | Internal model | Managed model | Hybrid model |
|---|---|---|---|
| Routine monitoring and investigation | Fund shifts, supervision and absence cover. | Specify covered signals, hours and investigation scope. | Define the point at which a case changes hands. |
| Detection and telemetry engineering | Reserve engineering time outside the alert queue. | Establish which connectors and rules the provider maintains. | Separate shared rules from organisation-specific detection work. |
| Containment decisions | Give responders authority and access for agreed actions. | Set permitted actions and reachable customer escalation. | Remove ambiguity where both teams can act. |
| Business recovery | Coordinate application and infrastructure owners. | Identify customer tasks and specialist services outside the fee. | Give one incident lead oversight of the combined effort. |
An internal model is attractive when close knowledge of unusual systems and direct control over priorities justify the investment. It needs recruitment, retention, management and a sustainable rota, not simply a licence and several analyst vacancies.
A managed model can provide a defined service without building all of that capacity internally. Its value depends on whether the covered environment and permitted actions match the requirement. The customer still needs people who understand business impact, can resolve integration problems and can direct changes that fall outside the provider’s scope.
A hybrid model can retain specialist detection and business knowledge while buying coverage elsewhere. It works best when the split is explicit: for example, the provider handles initial investigation while an internal team owns application-specific detection and major-incident decisions. An undefined middle arrangement can leave each side waiting for the other.
Continuous coverage needs a capacity calculation
Consider a hypothetical staffing calculation. Assume each person supplies 1,500 hours a year to the relevant staffed position after leave, training and other duties. Covering 8,760 hours then requires 8,760 ÷ 1,500 = 5.84 full-time equivalents, or at least six whole posts on that arithmetic.
This is a planning assumption, not an industry staffing benchmark. It covers one position only, before shift constraints, overlapping handovers, supervision and incident surge. Replace the productive-hours assumption with figures agreed by your own workforce planners. If two positions must be continuously staffed, the coverage requirement doubles before those additional needs are considered.
Use the same discipline for the managed proposal. Add customer service management, retained engineers, on-call decision-makers, excluded telemetry or investigation work and the cost of maintaining access. A supplier fee is comparable with the internal model only after both sides include the work needed to deliver the agreed service.
Response authority changes what you are buying
Sophos provides a useful documented example. Its MDR response modes distinguish Collaborate, which requires written authorisation before response actions, from Authorize, which allows proactive containment within the service. Collaborate also offers an optional fallback to Authorize if the defined contacts do not acknowledge phone contact attempts. Notify Only does not permit containment or neutralisation.
Those settings produce different customer staffing requirements. A model that depends on approval needs someone who can be reached and make the decision. Pre-authorised action needs an agreed scope, suitable technical access and a clear understanding of which business consequences have already been accepted.
The documented action capabilities also depend on configuration: Live Response must be enabled for the relevant device access, and Microsoft 365 response actions require the integration to be set up. A commercial entitlement, a selected response mode and a working integration are separate dependencies.
For any candidate provider, reconcile its documentation with the actual service schedule and your environment. Ask who acts if the customer contact is unreachable, who can restore a service after containment and which actions remain outside scope. This is where a superficially cheaper arrangement can leave substantial internal work unfunded.
Pay for the transition as well as the destination
Allow time for onboarding sources, tuning cases, granting access and teaching the new team which systems are critical. Keep the previous arrangement available until the replacement can demonstrate the required handovers. Running both temporarily has a cost; removing the old cover before the new service works has a different one.
Use a controlled exercise that crosses the organisational boundary. Include an ambiguous alert, a failed contact attempt and a containment action that needs a service owner’s input. Observe whether the teams can share evidence, agree severity and identify the person making the decision. A completed onboarding form does not demonstrate those behaviours.
Choose the model whose retained responsibilities the organisation can sustain through ordinary operations and a prolonged incident. The next step is to turn that operating design into specific evidence requirements for an MDR service evaluation.
Keep reading
Related insights
Cybersecurity · Analysis
Supplier questionnaires leave the hardest resilience question unanswered
Use supplier questionnaires to identify where service-specific evidence, recovery arrangements and contractual commitments need a closer look.
Cybersecurity · Explainer
SSO, federation and provisioning: three different parts of the access journey
Understand what SSO, federation and provisioning each deliver, and why successful sign-in does not prove a complete identity integration.
Cybersecurity · Practical guide
A board cyber report should change a business decision
Turn cyber reporting into a clear discussion of service exposure, evidence and choices, with a practical example of a board decision.



