CyphrQ
Menu

SIEM vs SOC: The Tool, the Team, and Which One You Need

A SIEM is a log platform; a SOC is the team that acts on it. Build, buy or hybrid, which logs to collect first, how long to keep them, and staffing.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

SIEM vs SOC is a tool-versus-team question. A SIEM is software: it collects logs from your systems, stores them and raises alerts. A SOC (security operations centre) is people and process: the team that investigates those alerts and responds to attacks. You can buy a SIEM in a week. A SOC takes trained staff, written procedures and round-the-clock cover. Most organisations need both, and many can't build the second one alone.

The confusion is understandable, because vendors sell "SOC platforms" and service providers sell "SIEM as a service". The practical question is simpler: when an alert fires at 3am on a Sunday, who looks at it, and what are they allowed to do?

How does a SIEM tool differ from a security operations centre?

SIEM SOC
What it is A platform (software or cloud service) A function: people, process and tools
What it does Collects, normalises, stores and correlates logs; raises alerts Triages alerts, investigates, contains, escalates, reports
What it needs Log sources, storage, detection rules, tuning Analysts, shift cover, playbooks, authority to act
What you buy A licence, usually priced by data volume Salaries, or a managed service contract
How it fails Missing logs, expired retention, untuned rules Unread alerts, no one on shift, no authority to isolate

SIEM stands for security information and event management. SOAR (security orchestration, automation and response) is a related tool that runs scripted response steps, such as disabling an account when certain alerts fire. Neither replaces the judgement of the person deciding whether an alert is an attack.

A SOC is also not a SOC 2 report; that's an audit of a service provider, explained in our SOC 1, 2 and 3 guide.

What does a SIEM actually do all day?

A SIEM does four jobs:

  1. Collect logs from identity systems, firewalls, VPNs, servers, cloud consoles, email and security tools.
  2. Normalise them into a common format so a login from one system can be compared with a login from another.
  3. Correlate events across sources: a sign-in from a new country, followed by a mailbox rule change, followed by a large download.
  4. Keep the history, so investigators can reconstruct what happened weeks or months later.

That fourth job is underrated. When an intrusion is found, the first question is "when did it start?", and only stored logs can answer it.

For how a SIEM compares with EDR, NDR, XDR and deception tools, see our breach detection tools guide.

What does a SOC team do that a SIEM can't?

A SIEM can tell you that an admin account logged in from an unusual place. It can't phone the admin to ask if they're travelling, decide whether to lock the account during a board meeting, or brief legal on whether a regulator needs telling.

A working SOC covers:

  • Triage: deciding which alerts matter, in minutes.
  • Investigation: scoping what the attacker touched.
  • Response: isolating devices, disabling accounts, coordinating with IT.
  • Detection engineering: writing and tuning the rules the SIEM runs.
  • Reporting: to management, auditors and, when required, regulators.

Where a SOC sits in the wider incident process is covered by our ISO/IEC 27035 explainer, and how detection fits the stages of an attack by the data breach lifecycle hub.

Can you have a SIEM without a SOC, or a SOC without a SIEM?

Yes to both, and both are common.

A SIEM without a SOC is a log archive with alerts nobody reads. It still helps after the fact, for investigation and audit evidence, but it won't stop an attack in progress.

A SOC without a SIEM usually means analysts working directly from EDR consoles and cloud admin portals. That can work for a small estate. It breaks down when an attack crosses systems, because nobody sees the whole chain in one place.

In practice: in June 2023 a US federal civilian agency spotted an intrusion into its Microsoft 365 email because it had both halves. According to the joint CISA and FBI advisory AA23-193A (12 July 2023), the agency observed "MailItemsAccessed events with an unexpected ClientAppID and AppID in M365 Audit Logs". It caught them using enhanced logging plus an established baseline of normal Outlook activity. The log mattered, and so did the people who knew what normal looked like. The advisory notes that the premium audit tier carrying that logging "requires licensing at the G5/E5 level".

That licensing gap had consequences. On 21 February 2024 CISA announced that "expanded logging will be available to all agencies using Microsoft Purview Audit regardless of license tier", and that Microsoft would "increase the default log retention period from 90 days to 180 days."

Which SOC model fits: in-house, MSSP, MDR or hybrid?

The labels vary by provider, so check what each contract actually includes. In common usage:

  • In-house SOC: your staff, your SIEM, your shifts.
  • MSSP (managed security service provider): typically manages security devices and the SIEM, and forwards alerts to you to act on.
  • MDR (managed detection and response): typically investigates and takes agreed response actions itself, often built around an endpoint agent.
  • Hybrid or co-managed: your team owns detection rules, business context and decisions; a provider covers nights, weekends and surge.

The regulatory side, including who stays accountable when you outsource, is in the US SOC rules guide and, for Saudi Arabia, the UAE and India, the GCC and India SOC requirements guide.

The joint guidance led by CISA and Australia's ASD, Guidance for SIEM and SOAR Implementation (27 May 2025), is written for exactly this decision, with separate documents for executives and practitioners. Whichever model you choose, ask any provider where your logs will be stored and what happens to detection if the provider has an outage.

My reading: for most mid-sized organisations, hybrid is the realistic end state. Keep the decisions in-house; buy the hours.

Which log sources should go into a SIEM first?

Start with the logs that show an attacker getting in and getting control, not the noisiest ones.

The August 2024 joint guidance from ASD, CISA, the FBI, the NSA and international partners, Best Practices for Event Logging and Threat Detection, ranks enterprise log sources by how likely an asset is to be targeted and how bad its compromise would be. Its list starts:

  1. Critical systems and data holdings likely to be targeted
  2. Internet-facing services, including remote access
  3. Identity and domain management servers
  4. Other critical servers
  5. Edge devices, such as boundary routers and firewalls
  6. Administrative workstations

For the SIEM itself, the 2025 CISA-led package adds Priority Logs for SIEM Ingestion, a practitioner document that CISA says "offers insights for prioritizing log ingestion into a SIEM".

A practical first wave for most organisations: identity provider sign-ins and admin changes, VPN and remote access logs, firewall logs, cloud control-plane audit logs, email audit logs, and EDR alerts. Add DNS and proxy logs next. Leave verbose application debug logs until the basics are tuned.

How long should SIEM logs be kept?

Long enough to investigate an intrusion that was found late, and at least as long as your strictest regulator requires.

Regulation sets floors. PCI DSS and NYDFS retention periods are compared in our US SOC requirements guide. For US federal agencies, AA23-193A cited OMB memorandum M-21-31, which required Microsoft audit logs to be kept at least twelve months in active storage plus eighteen months in cold storage.

Attackers set the practical floor. Mandiant's M-Trends 2026 reports dwell times close to 400 days for one malware family, BRICKSTORM, and warns that 90-day retention leaves investigators unable to see how such an intrusion began. The Microsoft Purview Audit default for those federal agencies was 90 days until the 2024 change described above.

A common pattern is tiered: a few months searchable in the SIEM, the rest in cheaper archive storage you can restore when needed. Test the restore; an archive you can't search in a crisis is not retention.

What are the staffing realities of running a SOC?

Covering one analyst seat around the clock takes far more than one person. My arithmetic: 24 hours times 7 days is 168 hours a week. At roughly 40 working hours per person, that's more than four people per seat before holidays, sickness and training. Two seats, so nobody works alone overnight, means around ten.

Getting the platform in place is a staffing job of its own. The CISA-led executive guidance tells leaders that several people will be needed full-time just to implement a SIEM or SOAR. The practitioner guidance puts proper SIEM implementation and effective log analysis ahead of buying SOAR.

This is why MDR and co-managed models exist. They spread the night shift across many customers.

Going deeper: for security and IT teams

Standards to anchor on. NIST SP 800-92, Guide to Computer Security Log Management, dates from September 2006 and is still listed as final. Its revision, SP 800-92 Rev. 1, Cybersecurity Log Management Planning Guide, was released as an initial public draft on 11 October 2023, describing itself as "a playbook intended to help any organization plan improvements to its cybersecurity log management". Comments closed on 29 November 2023, and NIST's page listed no final version as of 26 October 2026. Use Rev. 1 for planning structure, and cite it as a draft.

The four factors. The 2024 joint logging guidance organises a programme around four factors: an enterprise-approved event logging policy, centralised log access and correlation, secure storage and event log integrity, and a detection strategy for relevant threats. Map your SIEM project plan to these four, and you'll find most gaps are in the last two.

Integrity and time. Forward logs off the source quickly, because an attacker with admin rights can clear them locally. The Volt Typhoon hunting steps in our living-off-the-land guide include investigating every event ID 1102, the audit-log-cleared event. Restrict who can delete or modify stored logs, separately from who can read them. Synchronise every source to a common time reference and store timestamps in UTC; correlation across sources fails when clocks disagree by minutes.

Cloud control planes. Collect administrative configuration changes, changes to security principals and permissions, and federated authentication events (SAML and OAuth), along with sign-ins to tenant admin accounts. These are where a cloud intrusion shows up, and many are off or short-retention by default. AA23-193A recommends confirming Microsoft 365 Unified Audit Logging is on rather than assuming it, and either offloading logs or setting a native retention policy.

Ingestion economics. Most SIEM licences charge by volume, so volume control is an engineering task. Filter at the collector, not the source: drop duplicate firewall allow events and verbose debug output, keep every authentication, privilege change and admin action. Track ingestion per source weekly; a sudden drop usually means a broken collector, not a quieter network.

Detect the silence. Alert when a priority source stops sending for longer than its normal gap. Many investigations find the key log source had been down for weeks.

Metrics a SOC should report. Mean and median time to triage, time to contain, percentage of priority sources reporting, false-positive rate per detection rule, and the number of ATT&CK techniques with at least one tested detection. Report them monthly to the same audience every time.

Questions for an MSSP or MDR provider: - Which of our log sources will you ingest, and which will you ignore? - How long do you keep our raw logs searchable, and in archive? - Do we own the detection rules you write for us, and can we take them with us? - What can you do without calling us: isolate a host, disable an account, block an IP? - If a firewall or server goes quiet in your platform, who notices, and how fast?

A SIEM and SOC decision checklist

  1. Write down who answers a critical alert at 3am on a Sunday today. If the answer is "nobody", that is the first gap to close.
  2. List your top six log sources using the joint guidance order above, and confirm each one reaches a central store.
  3. Set retention to at least a year for identity, remote access and cloud admin logs, longer if a regulator requires it.
  4. Turn on an alert for any priority source going silent.
  5. Decide which decisions stay in-house (declaring an incident, notifying regulators) and which hours you can buy.
  6. Budget for training alongside licences.
  7. Hold off on SOAR until your SIEM alerts are tuned and trusted.

Key takeaways

  • A SIEM is a log platform; a SOC is the team and process that acts on what it finds. One without the other leaves a gap.
  • The 2024 joint logging guidance from ASD, CISA, the FBI, the NSA and partners puts critical systems, internet-facing services, identity servers and edge devices near the top of the log priority list.
  • In 2023 a US federal agency caught an email intrusion using enhanced Microsoft 365 audit logs and a baseline of normal activity, per CISA advisory AA23-193A.
  • Retention must outlast attackers: Mandiant reports dwell times close to 400 days for one malware family, while 90 days is a common default.
  • Round-the-clock cover for one analyst seat takes more than four people, which is why many organisations use MDR or a hybrid model.
  • NIST SP 800-92 (2006) is still the final log management guide; its 2023 revision remains a draft.

Sources