Microsoft Sentinel for small teams: getting real value without a SOC

Sentinel has a reputation as "enterprise SIEM" heavy, expensive, requires a SOC team. Some of that's true. Some of it isn't. A small team can extract real, defensible value from Sentinel without a 24/7 operations center, if they're disciplined about scope.

Here's how I deploy Sentinel for organizations of 20–200 people.

What you're trying to achieve

Three concrete outcomes:

Detect known attacker patterns: credential stuffing, impossible travel, mass file deletion, anomalous role assignment.
Have an audit trail: when something happens, you can reconstruct what happened.
Comply with frameworks that require SIEM: Cyber Essentials Plus, SOC 2, ISO 27001 increasingly expect this.

Anything more ambitious (live threat hunting, custom detections at scale) needs more team than this post assumes.

The data sources to connect (and which to skip)

Connect:

Microsoft Entra ID sign-in logs — table stakes, free.
Microsoft Entra ID audit logs — directory changes, role grants.
Azure Activity Log — control plane operations across Azure.
Microsoft 365 Defender — endpoint, identity, email, cloud app signals.
Office 365 audit logs — file shares, Teams events, mailbox activity.

Skip (initially):

Network flow logs unless you have a specific need — large volume, low signal.
VM-level OS logs unless those VMs are critical — operational overhead.
Custom application logs unless you're building dashboards from them.

The first set is enough to detect 80% of common attack scenarios. Adding the rest later is easy.

Use the analytics templates — don't write your own rules yet

Sentinel ships with hundreds of analytics rule templates. Enable the high-quality, high-impact ones first. My starter pack:

Sign-ins from blocked countries.
Impossible travel detected.
Multiple failed sign-ins followed by success.
New admin account created.
Role assigned to user outside privileged role group.
Suspicious sign-in followed by mass file download.
MFA disabled for user.
Service principal added with high-privilege roles.

Don't enable every rule. Enable maybe 20 to start. Tune false positives for two weeks. Then add more.

Workbooks before custom queries

Before you write KQL queries, use the built-in workbooks:

Microsoft Entra ID Audit logs workbook.
Azure Activity workbook.
Identity & Access workbook.

A small team can get 90% of operational value just by reviewing these workbooks weekly. Bookmark them, set time aside, treat it like a chore that pays back.

Incidents — focus on a tight workflow

Sentinel groups alerts into incidents. The discipline is:

Assign every incident to one person.
Track status: New → Active → Closed.
Always close with a reason: True Positive, Benign Positive, False Positive.
Spend 5 minutes per incident on average. If it takes longer, escalate or write a tuning rule.

This is how a small team avoids being buried.

Cost control — this is the part everyone underestimates

Sentinel charges for data ingested + retained. Without controls, costs spiral.

What I do:

Tier the data. High-value tables (sign-ins, audit, security alerts) → analytics tier (full SIEM features). Lower-value tables → basic logs tier (cheaper, query-only).
Cap retention. 30 days at the analytics tier is fine for many small teams; 90 if your compliance requires it. Archive beyond that to cheaper storage.
Filter at the source. For chatty sources (Activity Log), filter out noise before ingestion using diagnostic settings or DCRs.
Set a daily cap. A daily ingestion cap prevents a misconfigured connector from generating a $5000 bill overnight.

A small team can run Sentinel for $200–500/month with this discipline. Without it, easily 5–10x more.

The on-call question

Sentinel without an on-call rotation isn't useless — it just means alerts pile up overnight and get reviewed in the morning. For most small teams, that's fine.

What I add for night-time coverage:

A small handful of severity: high analytics rules with automated playbook responses (e.g., disable user account on impossible travel + multiple failed sign-ins).
Alerts on those rules to email + SMS via Logic Apps.
A documented "what to do at 2 AM if you get one" runbook.

Nothing fancy. Just enough that the highest-impact scenarios get a fast response without staffing a SOC.

What you should not do

Don't hire a "Sentinel expert" before you've used it for 3 months. You won't know what you actually need.
Don't enable every analytics template at once. You'll drown.
Don't connect every conceivable data source. Sentinel data costs are real.
Don't write custom KQL queries for things the built-in templates already detect.

What you graduate into

Once your team is using Sentinel comfortably — incidents are reviewed, false positives are tuned, costs are controlled — that's when you start thinking about:

Custom detections specific to your business.
Threat hunting practices.
Integration with Defender XDR for unified incident management.
Maybe a managed SOC partner.

Until then: keep it small, keep it disciplined, and you'll get more security value per hour than half the enterprise deployments I've seen.