Hiring a SOC: How to Do It and What to Consider

When you enter the market to hire a SOC, you're faced with a sea of proposals promising 24/7 monitoring, immediate response, and total security—but few clearly explain what they actually do when an incident occurs.

Choosing poorly doesn't just impact your budget; it creates a false sense of security. You think someone is watching over your infrastructure, but in practice, you only receive generic alerts, automated emails, or dashboards that no one checks when it matters most.

At TecnetOne, we've prepared this guide to help you choose the right SOC for your company: understand what you're actually buying, how to filter proposals, the differences between SOC, SIEM, and MDR, and what to demand to ensure the service truly reduces risk.

Table of Contents

• SOC vs. SIEM vs. MDR: What are you really buying?

• Hiring a SOC: 7 Technical criteria to filter proposals

• The “Uncomfortable Questions” (Red Flags)

• What type of SOC do you need?

• How much does a SOC cost?

SOC vs. SIEM vs. MDR: What are you really buying?

This is where most companies get confused—and where the most money is lost. Many providers sell one thing at the price of another.

1. SIEM (tool): A technology for centralizing logs, correlating events, and generating alerts. A SIEM doesn’t protect you on its own—it requires engineering, detection content, maintenance, and operation.

2. SOC (operations + process + people): The team (and discipline) that monitors, detects, investigates, contains, and coordinates response. It may use SIEM, EDR/XDR, SOAR, and other tools, but the true value lies in the operation.

3. MDR (focused service, commonly endpoint): Typically focused on detection and response, primarily through EDR/XDR. It can be excellent, but it doesn’t always cover your full environment (cloud, identity, networks, SaaS, etc.) or offer complete governance.

Practical rule: If you're promised a "SOC in 48 hours" without onboarding, source integration, or runbooks, you're probably buying alerts—not response capabilities.

Hiring a SOC as a Service: 7 Technical criteria to filter proposals

Don’t rely solely on price or the provider’s logo. Demand that the technical proposal covers these key points:

1) Real Coverage of Sources (Not Just “Endpoint”)

Request an explicit list of telemetry sources and their priorities:

1. Identity (Microsoft Entra ID / AD)

2. Endpoints (EDR/XDR)

3. Network (FW, IDS/IPS, VPN)

4. Cloud (Azure/AWS/GCP)

5. Email (M365 / Google Workspace)

6. Critical SaaS (CRM, ERP, etc.)

If the provider doesn’t clarify what is integrated and what’s excluded, you can’t properly estimate residual risk.

2) Use Cases (Detections) and Their Maintenance

A SOC doesn’t run on “generic signatures.” It must include:

1. Use cases based on MITRE ATT&CK (or equivalent)

2. Tuning to reduce false positives

3. Regular reviews and continuous improvement (new techniques, changes in your environment)

Ask for examples of detections and how they’re updated.

3) SLA for Detection, Triage, and Response

“24/7” isn’t enough. Ask for specific response times:

1. MTTD (Mean Time to Detect)

2. MTTA (Mean Time to Acknowledge/Triage)

3. MTTR (Mean Time to Contain / Coordinate Resolution)

And most importantly: What is the SLA for High Severity incidents?

Read more: Incident Response KPIs: MTTA, MTTD, and MTTR

4) Containment Capability (Actions), Not Just Notifications

Can the SOC take action, or does it just “let you know”?

1. Isolate endpoint

2. Block IOC on firewall

3. Disable compromised user

4. Revoke sessions/tokens

5. Contain lateral movement

If everything depends on “your team doing it,” you’re essentially paying for an alert call center.

5) Runbooks and Incident Response (Mature Operations)

Demand runbooks for common scenarios:

1. Business Email Compromise (BEC)

2. Ransomware

3. Leaked credentials / account takeover

4. Data exfiltration

5. Lateral movement

Also define: Who makes decisions, and what approvals are required to act?

6) Reporting That’s Actually Useful (Business + Technical)

A good SOC must speak two languages:

1. Leadership/Board: trends, risk, exposure, impact, and decisions (what was reduced, what remains).

2. IT/SecOps: evidence, timeline, IOCs, actionable recommendations, and a prioritized backlog.

Avoid “pretty” reports that don’t drive action.

7) Onboarding, Continuous Improvement, and Service “Health”

Ask what Month 1 and Month 3 look like:

1. Onboarding (inventory, critical assets, crown jewels)

2. Baseline (what’s normal in your environment)

3. Severity and threshold adjustments

4. Service meetings, QBRs/MBRs, detection roadmap

A SOC without continuous improvement quickly becomes obsolete.

The “Uncomfortable Questions”

Before signing, ask these questions. Their answers will reveal the provider’s operational maturity:

1. “Who actually operates my account?”
   Is it their internal team or a subcontractor? Who has access to your data and under what controls?
   
   
2. “What happens if there’s an incident at 3 a.m.?”
   Is there a real on-call team? Escalation process? Direct channels (phone/war room) or just a ticket?
   
   
3. “How do you handle false positives and alert fatigue?”
   A good SOC has a tuning process. If they say “that’s normal,” it’s a red flag.
   
   
4. “What does the service NOT cover?”
   If they avoid answering, the actual scope is probably smaller than it seems.
   
   
5. “What evidence do you provide and how is it preserved?”
   Crucial for forensics, compliance, and insurance.

What type of SOC do you need?

You don’t always need the “biggest SOC.” It depends on your context:

1. Internal SOC (in-house): Maximum control, but high cost and complexity (24/7 coverage, staffing rotation, tooling, engineering).

2. Outsourced SOC (MSSP / SOC as a Service): Accelerates coverage and operations—ideal for SMBs/scaleups or small teams.

3. Hybrid SOC: The provider operates 24/7, while your team manages governance, priorities, and extended response.

Practical rule: If your team is currently “putting out fires” and doesn’t have the capacity to run 24/7 security operations, an outsourced or hybrid model usually offers better cost-benefit.

Read more: What is SOC (Security Operation Center)?

How much does a SOC cost?

It’s frustrating not to see fixed prices, but in cybersecurity, “it depends” is often the honest answer. Costs usually vary based on:

1. Scope (assets and sources): endpoints, identities, cloud platforms, firewalls, etc.

2. Log/telemetry volume: ingestion and retention (affects tooling).

3. Service model: monitoring only vs. active response vs. including Incident Response.

4. Schedule and SLA: 8x5 vs. 24/7, response times.

5. Environment complexity: multi-cloud, multiple locations, OT/IoT, etc.

Why do companies choose TecnetOne’s SOC?

At TecnetOne, we don’t believe in a SOC that simply sends alerts or automated emails once something has already gone wrong. Our SOC operates as a true extension of your team, with analysts who understand both technology and business impact.

We don’t just detect incidents—we investigate, contextualize, and help contain them. Every alert has a reason, a clear priority, and an actionable recommendation. Our goal isn’t to flood you with noise, but to truly reduce risk.

A SOC shouldn’t be seen as just another operational expense. The cost of a breach, ransomware, or compromised account often far exceeds the investment in a well-operated 24/7 SOC—especially when detection is delayed or response is unclear.

That’s why we focus on transparency, defined processes, and direct communication. You’ll know what we monitor, how we respond, and who’s on the other end when a critical incident occurs.