· cyber security · 5 min read

SIEM, SOC, and MDR: Sorting Out Security Acronyms for Small Teams

SIEM is software, a SOC is a team, and MDR is a service. This post explains each in plain words, which logs a small organization should collect, and how co-managed IT splits log ownership from log watching.

SIEM is software, a SOC is a team, and MDR is a service. This post explains each in plain words, which logs a small organization should collect, and how co-managed IT splits log ownership from log watching.

Security vendors love acronyms. If you run a small company, a sales call can leave you holding three of them and no idea which one you need to buy.

Picture a defense subcontractor with 80 employees whose prime contractor has started asking about logging. The IT manager is capable and busy, and the questionnaire is full of terms that sound alike. Here is what each one means, which logs to collect, and who should own what when you already have IT staff in-house.

Four acronyms in plain words

A SIEM (security information and event management) is software. It collects logs from many systems into one place and looks for patterns across them, like a sign-in from another country followed by a mailbox forwarding rule.

A SOC (security operations center) is the people and the function. Analysts watch alerts, investigate, and respond. A SOC can be a room full of staff or a small shared team at a provider.

MDR (managed detection and response) is a service that packages detection tools with a SOC. You pay a provider, and their analysts watch your environment and act on what they find.

XDR (extended detection and response) is a product category that stretches endpoint detection to cover email, identity, and the network in one console. Some MDR providers build their service around one.

Put together: the SIEM is the tool that collects, the SOC is the team that reads, and MDR is the SOC sold as a service.

Logs worth collecting

A log is a record of something that happened on a system. You can’t investigate what you didn’t record. For a small organization, these are the sources to start with:

  • Microsoft 365 sign-in logs and the unified audit log, which show logins, mailbox rule changes, file sharing, and admin actions
  • Firewall logs, which show traffic in and out of each office
  • Endpoint alerts from your EDR (endpoint detection and response) tool
  • Access logs from your line-of-business applications, such as the ERP, CRM, or document system that holds customer or project data
  • Entra ID sign-in and audit logs, plus domain controller logs if you still run them

Frameworks tend to ask for this. NIST SP 800-171, which many defense contractors use to protect controlled unclassified information (CUI), includes requirements around audit logging and reviewing those logs. SOC 2 reports and cyber insurance applications often ask similar questions. Check the exact wording for your situation with whoever manages your compliance.

Retention is a decision

Many platforms keep logs for a limited time by default. An investigation can start months after the activity, and short retention can leave you with nothing to read.

Decide how long to keep each source. Ask your compliance advisor or insurer what applies, then write the number down. Check that storage is protected from tampering, because an attacker who gets admin rights will want to erase the trail.

What a small organization buys and what it builds

Building your own SIEM and SOC means licenses, storage, constant tuning, and analysts on shift around the clock. A company with one IT manager can’t staff that, and a larger one rarely wants to.

Most small organizations buy the watching. An MDR service uses the logs and tools you already have, plus some it provides, and puts trained people behind them.

What you still build is the foundation underneath. Someone has to turn auditing on, send logs to the right place, and know what normal looks like in your environment. That is internal work, and no vendor can do it for you from outside.

Co-managed IT: who owns log sources and who watches

The cleanest split is ownership of the sources on one side and the watching on the other.

Your internal IT team typically owns:

  • turning on auditing in Microsoft 365 and confirming it stays on
  • configuring the firewall to send logs
  • asking application vendors how to get access logs, and exporting them
  • telling the provider when a system is added, moved, or retired

The MSP or MDR provider typically owns:

  • receiving and storing the logs
  • writing and tuning the detection rules
  • watching alerts around the clock
  • reporting on what was found and what was done

The gap to watch is silence. A log source that stops sending produces no alerts, and everyone assumes things are quiet. Ask your provider to alert on a source that goes dark, and make sure the IT manager hears about it.

A one-page log inventory

For each source, write down the owner, where the logs go, the retention period, and who reviews them. If a box is empty, that is your first task. The same list helps when a customer’s security questionnaire or your insurer asks what you log.

How Kayak Cyber helps

We collect and correlate logs across Microsoft 365, firewalls, endpoints, and servers, and put analysts behind them around the clock. Related signals from endpoint, email, identity, and cloud show up as one incident. Your IT manager keeps ownership of the log sources and decides what happens to your systems. We do the watching, tuning, and reporting. Start with our cybersecurity services.

Call us at 405-253-5101 or schedule a discovery call to get on the calendar.

Back to Blog