Security Operations Explained: SOC vs. SIEM vs. MDR, and How to Build Detection and Response

Security operations is the ongoing function that monitors an organization's systems for threats, investigates suspicious activity, and responds to incidents. It is usually delivered by a security operations center (SOC), a team of analysts using tools such as SIEM (security information and event management) and EDR (endpoint detection and response), either in-house or through a managed detection and response (MDR) provider.

SOC, SIEM, EDR, XDR, and MDR compared

What good detection covers

• Identity: unusual sign-ins, impossible travel, MFA fatigue attempts, and privilege changes.
• Endpoints: malware, suspicious processes, and ransomware behavior.
• Cloud: risky configuration changes, unusual API calls, and exposed storage.
• Email: phishing and business email compromise.
• Applications: authentication abuse and anomalous API usage.
• Network: connections to known malicious infrastructure and lateral movement.

Map detections to the MITRE ATT&CK knowledge base of attacker techniques to find coverage gaps.

Build in-house or use MDR?

• In-house SOC: maximum control and context, but a 24/7 operation requires multiple shifts of analysts, tooling, and ongoing training.
• MDR: faster, often more affordable 24/7 coverage, using the provider's analysts and threat intelligence. You still need an internal owner and clear escalation paths.
• Hybrid: internal team during business hours plus MDR for out-of-hours monitoring and specialist response.

Incident response planning

NIST updated its incident response guidance in SP 800-61 Revision 3 to align with the NIST Cybersecurity Framework 2.0. A practical plan defines:

1. Roles and contacts: technical leads, management, legal, communications, and external partners.
2. Severity levels and escalation criteria.
3. Playbooks for likely scenarios: ransomware, compromised accounts, data exposure, and business email compromise.
4. Evidence preservation and logging requirements.
5. Regulatory and customer notification obligations and timelines.
6. Recovery steps and post-incident reviews.

Run tabletop exercises at least once a year to test the plan with the people who will use it.

Metrics that show detection is working

• Mean time to detect (MTTD) and mean time to respond (MTTR)
• Coverage of critical log sources
• Detection coverage mapped to MITRE ATT&CK techniques
• False positive rate and alert volume per analyst
• Results of tabletop exercises and purple-team tests

Which log sources matter most

A SIEM or MDR service is only as effective as the data it receives. Prioritize log sources by how often they reveal real attacks:

1. Identity provider and authentication logs: sign-ins, MFA events, password resets, and privilege changes reveal account takeover, the most common starting point for attacks.
2. Endpoint detection and response (EDR) telemetry: process, file, and network activity on laptops and servers shows malware, ransomware, and attacker tools.
3. Email security logs: phishing attempts, malicious attachments, and suspicious mailbox rules.
4. Cloud control plane logs: such as AWS CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs, which record changes to infrastructure and permissions.
5. SaaS application audit logs: file sharing, admin actions, and data exports in tools such as Microsoft 365, Google Workspace, and CRM systems.
6. Network and firewall logs: unusual outbound connections, VPN access, and traffic between segments.
7. Application logs: authentication, authorization failures, and administrative actions in your own software.

Start with identity, endpoint, email, and cloud logs, then expand. Collecting everything without prioritization drives up SIEM costs without improving detection.

Writing and tuning detection rules

Detection rules translate attacker behavior into alerts. Good rules are based on known techniques, often mapped to the MITRE ATT&CK framework, and tuned to your environment. Examples include impossible travel between sign-ins, MFA fatigue patterns with many push requests in a short time, creation of new inbox forwarding rules to external addresses, disabling of security tools, mass file encryption or deletion, and new administrator accounts created outside change windows. After deploying a rule, review its alerts for a few weeks, tune out benign activity, and document what analysts should do when it fires. Rules that generate constant false positives train analysts to ignore alerts, which is more dangerous than having fewer rules.

Alert triage workflow

A consistent triage process keeps response quick and thorough. When an alert fires, the analyst first validates it, checking whether the activity is expected, then scopes it by identifying affected users, devices, and data, then contains the threat, for example by disabling an account, isolating a device, or blocking an indicator, then eradicates the cause and recovers systems, and finally documents what happened and what can be improved. Automation through SOAR playbooks can handle repetitive steps, such as enriching alerts with user and device context or isolating a device when ransomware behavior is confirmed, so analysts focus on judgment.

Threat hunting

Detection rules catch known patterns; threat hunting looks for attackers who have slipped past them. Hunters form a hypothesis, for example "an attacker may be using a legitimate remote management tool for persistence", and search logs and endpoint data for evidence. Even when hunts find nothing malicious, they often reveal visibility gaps and lead to new detection rules. Mature SOCs and MDR providers run hunts regularly, often informed by current threat intelligence.

Evaluating an MDR provider

• Coverage: which log sources and technologies do they monitor, and do they support your identity provider, endpoints, cloud platforms, and key SaaS tools?
• Response authority: can they take containment actions, such as isolating devices or disabling accounts, or do they only notify you?
• Response times: what are their committed times to acknowledge and escalate critical alerts, around the clock?
• Analyst depth: who investigates alerts, and how experienced are they?
• Transparency: can you see the alerts, investigations, and actions taken in a portal?
• Threat hunting and reporting: do they hunt proactively, and how do they report on coverage and trends?
• Incident response: is full incident response included or a separate retainer?
• Onboarding: how long until monitoring is live, and how do they tune detections to your environment?

Running a tabletop exercise

A tabletop exercise tests your incident response plan without touching real systems. Gather the people who would be involved in a real incident, including IT, security, leadership, legal, communications, and key suppliers, and walk through a realistic scenario, such as ransomware encrypting file servers on a Friday evening or a cloud administrator account being compromised. At each stage, ask who does what, how they communicate, what information they need, and what decisions must be made. Exercises regularly reveal gaps such as outdated contact lists, unclear authority to shut down systems, missing backups, or unknown notification obligations. Run at least one exercise a year and update the plan afterwards.

Example: an MDR rollout for a professional services firm

A 300-person professional services firm has endpoint protection but no one monitoring alerts out of hours. It engages an MDR provider, connecting its endpoint protection, Microsoft 365 sign-in and audit logs, and cloud logs within the first month. During onboarding, the provider tunes detections and agrees on an escalation process: it may isolate devices and disable accounts immediately for confirmed threats, and it calls the firm's IT lead for other critical alerts. Two months later, the provider detects a sign-in from an unusual country followed by a new inbox forwarding rule on a partner's mailbox. It disables the account, removes the rule, and alerts the firm within minutes, preventing a likely invoice fraud attempt. The firm then runs a tabletop exercise based on the incident and tightens MFA policies. For the identity controls that prevent many such attacks, see our zero trust guide.

Controlling SIEM costs

SIEM pricing is often based on the volume of data ingested or stored, so costs can grow quickly as you add sources. Keep them under control by prioritizing high-value security logs, filtering out noisy events that are never used in detections or investigations, using tiered storage that keeps recent data hot for searching and older data in cheaper archive storage for compliance, and reviewing ingestion volumes monthly to catch unexpected spikes, for example from a misconfigured application logging at debug level. Some organizations route all logs to inexpensive storage and send only security-relevant events to the SIEM, querying the archive only when an investigation requires it.

Building a SOC team

An in-house SOC that provides 24/7 coverage typically needs several analysts per shift position to cover nights, weekends, holidays, sickness, and training, plus engineers who maintain tools and detections and a manager who coordinates incidents. Analyst roles usually range from triage of incoming alerts to deeper investigation and threat hunting. Retention can be difficult, because the work is demanding and skilled analysts are in high demand. Many organizations therefore use a hybrid model: an MDR provider handles round-the-clock monitoring and first response, while a small internal team owns detection engineering for business-specific systems, incident coordination, and continuous improvement.

Common security operations mistakes

• Collecting logs without anyone reviewing the alerts.
• Monitoring only during business hours, when many attacks happen at night and on weekends.
• Leaving detection rules untuned until analysts ignore most alerts.
• Having no authority to contain threats quickly, so response waits for approvals.
• Never testing the incident response plan.
• Measuring alert volume instead of detection coverage and response speed.

Avoiding these mistakes matters more than which tools you buy. For the preventive controls that reduce alert volume in the first place, see our guides to application security and cloud security.

Where to start

If you have no security monitoring today, the fastest path to meaningful coverage is usually an MDR service connected to your identity provider, endpoints, email, and cloud logs, combined with a written incident response plan and a tested contact list. If you already have a SIEM but alerts go unreviewed, focus on reducing noise by tuning rules, assigning clear ownership of alert response, and adding out-of-hours coverage. If you have a functioning SOC, invest in detection engineering, threat hunting, automation, and regular exercises. In every case, measure mean time to detect and respond, and track how many of the attack techniques most relevant to your organization you can actually detect. Our enterprise cybersecurity strategy guide shows how security operations fit into the wider program.

Summary

Effective security operations combine the right data, well-tuned detections, clear response authority, and practiced processes. Whether you build an in-house SOC, use an MDR provider, or combine both, prioritize identity, endpoint, email, and cloud visibility, make sure someone responds to alerts around the clock, and test your response regularly. Measure detection coverage and response speed, not alert counts, and keep improving based on every incident and exercise.

Security operations are never finished: attackers adapt constantly, so detections, playbooks, and coverage must be reviewed and improved continuously, ideally after every significant incident, exercise, or change to your environment.

Start by making sure someone is always watching, and build from there.

Strengthen your security operations

Vertex Cyber Tech provides threat detection, incident response, and SIEM support, and helps teams build log pipelines and response playbooks. Start with a cybersecurity services overview or book a consultation.

Related guides: for practical next steps, read our managed cybersecurity services guide.

Sources and further reading

• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• MITRE ATT&CK
• NIST Cybersecurity Framework 2.0