Should You Build or Source a Security Operations Centre in Saudi Arabia?

The difficult question is rarely whether you need a security operations centre. It is whether you should build the capability yourself, source it from an MDR or managed SOC provider, or keep the critical decisions in-house while outsourcing the monitoring workload.

Getting that choice wrong is expensive in both directions. Building too early can leave an organisation paying for tools, shifts and specialist roles it cannot keep fully utilised. Outsourcing too aggressively can produce a dashboard full of alerts while the business still lacks internal authority to investigate, contain and accept cyber risk.

The right decision depends on the operating model you need to sustain: what must be monitored continuously, who has authority during an incident, where telemetry can be processed, and how much detection engineering the organisation can maintain over time.

What a Security Operations Centre Actually Has to Deliver

A SOC is not a room containing a SIEM. It is the operating capability that turns security telemetry into detection, investigation, escalation and response decisions.

For Saudi organisations within the scope of the NCA Essential Cybersecurity Controls, the requirement is outcome-based. ECC 2-2024 requires cybersecurity event logging on critical assets and privileged or remote access, appropriate collection technologies such as SIEM, continuous monitoring and at least 12 months of log retention.

The Minimum Operating Capabilities

• Collect useful telemetry: The SOC must receive the logs, endpoint events, identity activity, network signals, cloud events and application data needed to detect meaningful threats.

• Maintain detection logic: SIEM implementation is only the foundation. Someone must create, tune and retire detection rules as applications, users and attacker techniques change.

• Triage continuously: Alerts need rapid classification so low-value noise does not bury events requiring investigation.

• Investigate context: Analysts need access to identity, endpoint, network and business context to determine whether suspicious activity is an incident.

• Escalate with authority: The process must define who can disable an account, isolate a server, block traffic or activate incident-response procedures.

• Retain evidence: Logs, timelines and investigation records must support later forensic, management and regulatory review.

• Measure effectiveness: A mature SOC tracks detection quality, response performance, false positives, recurring gaps and the coverage of critical assets.

The NCA control set therefore creates a monitoring obligation, but it does not mean every organisation must employ every analyst internally. The related guide to NCA essential cybersecurity controls covers the wider control environment in which SOC monitoring, incident response and log retention sit.

SAMA Raises the Operating Expectation for Financial Institutions

For organisations regulated by the Saudi Central Bank, the operating expectation is more explicit. SAMA’s Cyber Security Framework calls for a designated team responsible for security monitoring, skilled and continuously trained staff, continuous 24x7 monitoring resources, automated and centralised log analysis through SIEM and periodic independent testing of SOC effectiveness.

That changes the build-versus-source decision. A bank cannot evaluate an MDR provider only on whether alerts appear in a portal. The model has to demonstrate that the full monitoring and incident-management obligation can still be met.

The Cost of Building: People, Tooling and Coverage

The largest mistake in an internal-SOC business case is pricing the SIEM licence and treating the rest as implementation. The harder cost is sustaining the operating model after the platform is live.

24x7 Is a Staffing Model, Not One Role

Continuous monitoring requires enough people to cover shifts, weekends, leave, training, sickness and escalation without making the same analyst permanently responsible for every critical event.

An internal model may require several distinct capabilities:

• Tier-one monitoring: Analysts review alerts, enrich context and determine which events require investigation.

• Senior investigation: More experienced analysts analyse complex events, correlate multiple data sources and coordinate containment.

• Detection engineering: Specialists maintain SIEM rules, use cases, parsing, threat logic and tuning.

• Platform engineering: Someone has to operate collectors, integrations, storage, data pipelines and access controls.

• Incident response: Serious incidents require people who can perform containment, forensic collection, recovery coordination and executive escalation.

• SOC leadership: The capability needs ownership of coverage, performance, risk acceptance, staffing and reporting.

Tool Cost Grows With Data and Complexity

SIEM costs can rise with event volume, retention and the number of connected environments. EDR, NDR, threat intelligence, SOAR, case management and forensic tools may add further licences and integration work.

The organisation also needs time to onboard data correctly. Collecting every available log can increase cost without improving detection if the SOC cannot distinguish useful telemetry from low-value noise.

The Hidden Cost Is Maintaining SOC Maturity

A newly built SOC can perform well during implementation and weaken later if detection content, skills and integrations remain static. Systems change, cloud adoption expands and attackers change techniques.

The build model therefore suits organisations that can fund an operating capability continuously, not merely obtain project approval for a SIEM implementation.

Sourcing Models and What They Leave With You

Sourcing can reduce the staffing and platform burden, but it does not transfer all cyber responsibility to the provider. The organisation still owns the business impact of the incident, internal escalation decisions and the risk created by missed or delayed detection.

Managed SIEM

In a managed SIEM model, the provider focuses on operating the platform, onboarding logs, maintaining connectors and sometimes developing detection content. The customer may still retain its own analysts and incident-response team.

This suits organisations that want to reduce engineering effort but still have strong internal monitoring and response capabilities.

Managed SOC

A managed SOC extends further into alert monitoring, triage, investigation and escalation. The provider may operate the detection platform and provide analyst coverage while the customer retains final incident authority.

The quality of the service depends heavily on how well the provider understands the customer’s assets, identities, business applications and escalation thresholds.

Managed Detection and Response

Managed detection and response normally places greater emphasis on active investigation and containment support rather than simply forwarding SIEM alerts. The exact service boundary varies by provider, so security leaders should evaluate the operating procedures rather than rely on the MDR label itself.

An MDR provider can identify suspicious endpoint behaviour, but the organisation still needs to decide whether that provider is authorised to isolate a production device, disable an executive account or interrupt a critical service.

If outsourcing is being considered because the internal team cannot maintain continuous monitoring, a useful next step is an independent operating-model assessment that maps what the provider can own and what the organisation must still be capable of doing itself.

Hybrid Models That Work

For many larger Saudi organisations, the strongest answer is not fully internal or fully outsourced. A hybrid model can preserve internal decision authority while using an external provider where staffing scale and specialist depth matter most.

External Monitoring, Internal Response

The provider handles 24x7 alert monitoring and initial investigation, while the internal team owns incident declaration, containment approval and coordination with technology and business leaders.

This model works well when the organisation has capable security leadership but does not want to build a full shift-based analyst operation.

Internal SOC With Specialist MDR Support

The organisation retains its own analysts and SIEM but uses external specialists for threat hunting, malware analysis, digital forensics or after-hours escalation.

This can increase technical depth without giving the provider ownership of the entire SOC operating model.

Internal Detection Ownership, Outsourced Platform Operations

The internal team defines use cases, risk priorities and escalation logic while a provider operates SIEM infrastructure, connectors and data engineering.

This model can work where the company understands its threats well but does not want security analysts spending substantial time maintaining ingestion pipelines.

Whichever hybrid model is chosen, decision rights must be explicit. IT governance advisory can help define accountability for detection coverage, provider changes, incident authority and acceptance of unresolved monitoring gaps.

Residency and Data Handling Constraints

SOC sourcing changes where security telemetry travels. Logs can contain usernames, IP addresses, customer identifiers, administrator activity, application data and information about the organisation’s internal architecture.

The procurement decision must therefore address the location of the SIEM platform, log storage, backup copies, analyst access and subcontractors before telemetry is sent to the provider.

NCA Requirements Affect Hosting Design

ECC 2-2024 requires organisations in scope to address cybersecurity requirements for cloud and hosting services and includes requirements relating to data classification and hosting or storage within Saudi Arabia. NCA’s Cloud Cybersecurity Controls add requirements for cloud providers and tenants around monitoring, log protection and cloud security operations.

That means a provider saying it has a “Saudi presence” is not enough. Security teams need to identify where event data is physically stored, where it is processed, whether overseas analysts can access it and which cloud or subcontracting providers form part of the service.

The wider residency issue is covered in the dedicated guide to cloud data residency saudi arabia, which should be reviewed before approving a cloud SIEM or offshore monitoring model.

SAMA-Regulated Entities Have Additional Third-Party Obligations

SAMA’s framework requires member organisations to manage third-party cybersecurity requirements before, during and when exiting an outsourcing relationship. Material outsourcing can also trigger specific approval requirements.

The implication is straightforward: outsourcing detection does not outsource accountability. The regulated organisation still needs enough internal capability to oversee the supplier, evaluate performance and take control when the service fails.

Evaluating an MDR Provider

The strongest MDR proposal is not the one with the largest list of technologies. It is the one that proves how quickly the provider can understand your environment, detect the threats that matter and execute the agreed escalation model.

Test the Operating Model Before the Demo

• Coverage scope: Identify exactly which endpoints, identities, cloud environments, network controls and applications the service will monitor.

• Detection ownership: Determine whether the provider builds custom detections for your environment or relies mainly on generic vendor content.

• Analyst availability: Confirm the actual monitoring and investigation coverage, including nights, weekends and escalation periods.

• Response authority: Define actions the provider can execute automatically, actions requiring approval and actions that remain completely internal.

• Data location: Identify where logs, cases, threat data and backup copies are stored and processed.

• Evidence retention: Confirm how long investigation records and security logs remain available and in what format they can be exported.

• Exit process: Determine how data, detections, cases and integration configurations will be returned when the contract ends.

Make the Provider Prove Detection Quality

Ask the provider to explain how it handles a small number of scenarios relevant to the organisation: compromised privileged credentials, ransomware behaviour, suspicious cloud administration, malicious persistence or abnormal data transfer.

The answer should show telemetry requirements, detection logic, investigation steps, escalation time and the party authorised to act.

Provider selection should also be treated as a cybersecurity risk decision, not merely a procurement comparison. A structured third-party technology risk assessment should cover security controls, contractual obligations, concentration risk, audit rights, subcontractors, continuity and exit.

Check Continuity of the SOC Itself

The monitoring provider becomes part of the organisation’s incident-detection chain. Security leaders therefore need to know how the provider operates during its own cloud, communications or staffing disruption.

The organisation’s business continuity plan should include loss of the SOC or MDR provider as a scenario rather than assuming monitoring is always available because it has been outsourced.

Decision Table by Organisation Size

The following is a starting model, not a regulatory classification. Security maturity, sector requirements and system complexity can justify a different answer for organisations of the same headcount.

The table should narrow the option set, not make the decision on its own. A security operations centre should be designed around the organisation’s regulatory scope, threat profile, internal skills and authority model.

Where the remaining question is whether the organisation has enough internal maturity to build or supervise the model, IT security consulting can be used to assess detection coverage, staffing, tooling and governance without assuming that sourcing or building is automatically the answer.

Does This Model Fit You?

• Source or use MDR: This is usually worth evaluating when 24x7 staffing is the main gap, internal incident leadership already exists and the organisation can govern a provider effectively.

• Build internally: This becomes more defensible when the organisation has sufficient scale, highly sensitive environments and enough permanent specialist demand to sustain detection engineering and response capability.

• Use a hybrid model: This is often appropriate when internal leadership and technical depth exist but shift coverage, threat hunting or specialised investigations remain difficult to maintain.

• Do not source blindly: Outsourcing is a weak fit when the organisation lacks an internal security owner capable of evaluating provider decisions and accepting cyber risk.

• Do not build for status: An internal SOC is a weak fit when the budget funds a room and SIEM platform but not the people and operating discipline needed to maintain it.

If those conditions are still unclear, use our five-stage methodology to assess the current operating model, identify the real monitoring gaps and compare build, source and hybrid options before committing to a platform or provider.

For initial budget planning, published consulting cost ranges can also help separate a focused SOC assessment from a wider security-governance or implementation programme before a formal procurement exercise begins.

Choose the SOC Operating Model Before You Choose the Provider

The most important security operations centre decision is not which SIEM or MDR brand to buy. It is which security responsibilities the organisation must be able to perform itself and which can safely be delegated.

Start by defining monitoring coverage, incident authority, data-handling constraints and the level of 24x7 capability required by the business and regulator. Then assess whether internal staffing, managed detection and response or a hybrid model can sustain those requirements over several years.

If you are still comparing build and source options, the useful next step is a short independent SOC scoping exercise that maps required capabilities, regulatory constraints, staffing gaps and provider responsibilities. The output should remain useful even if the final decision is to build internally rather than purchase a managed service.

FAQ about security operations centre 

Should a company build or outsource its security operations centre?

The answer depends on security scale, regulatory obligations, internal skills and the level of 24x7 monitoring required. Building gives greater control but requires sustained staffing, engineering and tooling capability. Outsourcing can provide faster access to continuous coverage, but the organisation still needs internal ownership of incidents, risk decisions and provider governance.

What is the difference between a managed SOC and MDR?

A managed SOC usually provides monitoring, alert triage and escalation across security tools such as SIEM. Managed detection and response typically places more emphasis on active investigation, threat detection and containment support. Service boundaries vary significantly between providers, so buyers should compare response authority, telemetry coverage and analyst responsibilities rather than choosing based on the service label alone.

Does NCA require organisations to have a SOC?

NCA ECC 2-2024 requires organisations in scope to implement cybersecurity event logging, identify appropriate technologies such as SIEM, continuously monitor cybersecurity events and retain logs for at least 12 months. The controls focus on the required monitoring outcome rather than prescribing that every organisation must build and staff its own internal SOC.

Does SAMA require 24x7 security monitoring?

SAMA’s Cyber Security Framework expects member organisations to establish a designated security-monitoring team and provide resources for continuous 24x7 security event monitoring. It also includes SIEM, incident handling, protected logs and periodic testing of SOC effectiveness among its control considerations. Organisations using providers still need to meet the framework’s third-party and outsourcing requirements.

What should I check before choosing an MDR provider in Saudi Arabia?

Check what telemetry is monitored, how detections are developed, actual analyst coverage, escalation times, response authority, log retention, data location, subcontractors and exit arrangements. Saudi organisations should also assess applicable NCA or sector requirements before sending security telemetry to a cloud or external platform, especially where sensitive or regulated information is involved.