Three ways to run security operations
A Security Operations Center (SOC) is a function, not a room: the people, processes and tools that watch your systems, decide which alerts are real attacks and coordinate the response. The real question is who runs it.
Providers use the labels loosely, so compare what is included rather than the name on the proposal. As a rule of thumb, the models differ like this:
| Model | Who runs it | What it usually watches | Who acts on a confirmed attack |
|---|---|---|---|
| In-house SOC | Your own analysts, on tools you buy and maintain | Whatever you choose to connect | Your team |
| MDR | A provider, often around its own endpoint or XDR platform | Mostly endpoints, increasingly cloud and identity too | The provider, within limits you agree |
| Managed SOC | A provider, working with your existing tools and logs | Logs and telemetry from endpoints, servers, cloud, network and identity | The provider, within limits you agree |
| Co-managed SOC | Your team and a provider together | An agreed split, often with the provider covering nights and weekends | Shared, following an agreed playbook |
What 24/7 coverage takes in-house
A week has 168 hours. A full-time analyst works about 40 of them, so one seat staffed around the clock needs 4.2 people before anyone takes annual leave, a public holiday, a sick day or a training course. Once those are counted, the realistic figure is closer to five people per seat.
One seat is rarely enough. A working SOC also needs someone senior to escalate to at 3 a.m., someone who writes and tunes detection rules, and someone who keeps the log platform running. Add tooling, threat-intelligence feeds and the time it takes to hire and train analysts, and an in-house SOC becomes a long-term program rather than a purchase.
That is why an in-house SOC tends to suit large organizations with a mature security team, a steady flow of alerts and a reason to keep everything internal. For many mid-sized organizations a provider is the faster route to 24/7 coverage, and their own people stay on the work that needs knowledge of the business.
Where MDR and a managed SOC differ
Both are outsourced, both run around the clock and both promise detection and response. The differences show up in the details:
- Scope of data. MDR often centers on the provider’s endpoint agent. A managed SOC typically also collects logs from servers, firewalls, cloud platforms and identity systems, which matters when an attack starts with a stolen password rather than malware. Some MDR services now take in the same range of logs, so compare the lists of data sources, not the labels.
- Your existing tools. Some MDR services require you to move to the provider’s platform, while others work with the tools you have. A managed SOC usually works with what you already run and tells you where the gaps are.
- Response authority. Ask exactly what the provider may do on its own, such as isolating a laptop or disabling an account, and what needs your approval. Fast automatic action limits damage, but an unapproved block can also stop a production system.
- Evidence. For regulated organizations the case record matters as much as the detection: a timeline of what was seen, decided and done is what regulators and auditors ask for.
What NIS2 and DORA expect when you outsource
Outsourcing the SOC does not outsource accountability. Under the NIS2 Directive, the management body of an essential or important entity approves the cybersecurity risk-management measures, oversees their implementation and can be held liable for the entity’s infringements of those obligations (Article 20). Incident handling and supply-chain security are both among the required measures (Article 21), so your SOC provider is part of the supply chain you have to assess.
DORA goes further for financial entities. They remain fully responsible for compliance when they use an ICT third-party provider (Article 28), and the contract must spell out, among other things, where data is processed, the service levels, the help you get during ICT incidents and what happens to your data when the contract ends (Article 30).
Reporting deadlines are short in both regimes. A NIS2 early warning is due within 24 hours of becoming aware of a significant incident, and a DORA initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it (or within four hours of a later classification). Whoever runs your SOC must be able to hand you the facts well inside those windows.
Questions to ask any SOC provider
- Which data sources will you monitor, and what will you not see?
- Where are our logs and case data stored and processed, and who can access them?
- Which actions can your analysts take without asking us, and how is each one logged and reversed?
- How, and in which language, do you escalate, and how fast at night and at weekends?
- How long does onboarding take, and when are detections tuned to our environment?
- What do your case records contain, and do they match our NIS2, DORA or GDPR reporting duties?
- If we leave, what happens to our data, and do we keep the detection rules built for us?
How our managed SOC approaches them
Our SOC in Skopje is available to organizations in North Macedonia and across Europe, the Middle East and Africa. It works with your existing log sources and tools, uses AI to draft the first analysis of each alert, and leaves every containment action to an analyst’s approval, with a documented rollback wherever the action allows one. Each client has an isolated environment, escalation is in English or Macedonian, and onboarding typically takes two to four weeks. Ask us about data location, response times at night and exit terms during scoping, so they are written into the contract.
How we help
Managed SOC 24/7: Round-the-clock monitoring, detection and response across EMEA, with AI-assisted triage and analysts who make the final call.