Most small MSPs are running security operations whether they admit it or not. If you sell EDR, run pen tests, manage firewalls, and chase down compliance gaps for your clients, that's a security operations function. What you don't have is a 24/7 staffed SOC with a dozen analysts watching a wall of monitors — and for a 5-to-15-person shop, you probably never will. The good news is that you don't need one to do this well. You need the two things a SOC actually gives you: centralized visibility and disciplined triage.

This post is the playbook we've built our own security workflow around. None of it requires hiring an analyst or buying a SIEM you can't staff.

The real problem isn't detection — it's fragmentation

Here's the thing nobody warns you about when you start stacking security tools: each one is excellent in isolation and a liability in aggregate. Your EDR (Huntress, SentinelOne, CrowdStrike, or whatever you run) catches endpoint and identity threats. Your compliance platform — Cork is one — tracks posture and insurance-relevant gaps. Your RMM (NinjaOne, Datto, or whatever you patch with) tells you which servers are missing critical updates. Your firewall and email-security stack — SonicWall, Check Point Harmony, Fortinet, or your equivalent — flags network and email events. Each vendor has its own console, its own severity language, its own notification email, and its own idea of what "critical" means.

So a senior tech ends up with five tabs open, mentally normalizing severity across five different scales, trying to remember whether the compliance-platform finding on Acme Corp relates to the EDR incident from a different tab an hour ago. That's not a tooling gap — every alert is being detected. It's an attention gap. The signal is there; it's just scattered across five places that don't talk to each other, and the one person watching has a full ticket queue of their own.

A SOC solves this with people and a single pane of glass. A small MSP can't buy the people, but it can absolutely build the single pane of glass.

What "security operations without a SOC" actually means

It means collapsing every vendor's findings into one normalized queue, sorted by what a human needs to look at today, so the one or two people running point on security stop context-switching and start working a list. Concretely, that's four moves:

  1. Normalize severity across vendors. Map every vendor's risk language onto one shared Critical / High / Medium / Low model so a "high" from your EDR and a "high" from your compliance platform mean the same thing to the person triaging — whichever tools those happen to be.
  2. Centralize the queue. One list, every vendor, every client. Each row is a single item to investigate — an EDR incident, a compliance gap, a missing patch on a server, a firewall event flagged for review.
  3. Add context on click. When you open a row, surface the customer, the device, related recent events from other vendors, and the escalation contact — without opening four more tabs.
  4. Act in the right place. This is the part people get wrong. Investigation and prioritization happen in your dashboard; remediation happens in the vendor that owns the host — more on that below, because it's where overpromising burns you.

When we built the security layer in Morton Command Center, this was the entire design brief. The normalized severity model and the per-company drill-in are native features — included in the product. The connections to your actual security tools — your EDR, your compliance platform, your pen-test service, your firewalls — are custom-built for your stack as part of your engagement, so the dashboard reads from exactly the vendors you run. And because the platform is API-driven, any security tool that exposes an API gets the same treatment: a SentinelOne, a CrowdStrike, a Fortinet, whatever you run, gets built into your stack. If your tool has an API, we build that integration for you. The tools stay where they are; nothing gets migrated or replaced. The dashboard is the operations view on top of them.

Where the line is: surface and triage vs. remediate

This is the single most important distinction, and it's where a lot of "unified security" marketing quietly lies. A dashboard that reads from your vendors is not the same as one that acts on your behalf across all of them. Most security APIs are read-only — they'll tell you what's wrong, but they won't let an outside tool quarantine a host or push a firewall rule. So an honest unified view does two different things depending on the vendor:

So the honest claim is "surface, triage, and — for Huntress — act," not "auto-remediate everything from one screen." Morton Command Center does not isolate hosts, quarantine machines, or block traffic on its own. That's deliberate: the vendor that owns the endpoint or the firewall is the right place for destructive action, and pretending otherwise is how you end up with a tool that looks great in a demo and lies to you in an incident. The small-MSP security win is in knowing what to do and when — not in pretending a meta-dashboard can pull the trigger everywhere.

How fast does it need to be?

Not as fast as you think — and beware anyone selling you "real-time." Truly real-time, push-driven security correlation across five vendors is a SOC-grade engineering problem, and most small MSPs neither need it nor can staff a response to it at 3 a.m. anyway.

What you actually need is near-real-time: short enough cycles that nothing important sits unseen for hours. In our case the data is cron-warmed on tiered schedules — EDR incidents (Huntress in our build) pull roughly every couple of minutes because the endpoint layer is the time-sensitive one, while compliance, pen-test, and firewall data refresh on slower hourly or multi-hour cycles that match how fast those findings actually change. The tier each source lands on follows the category, not the brand, so a different EDR or firewall slots into the same schedule. There's also a manual refresh when someone wants the freshest pull right now. "Within minutes for the urgent stuff, within hours for the rest" is the right target for a shop your size; chasing instant correlation buys cost and complexity you don't need.

A weekly cadence that works for a two-person security function

Tooling only matters if there's a rhythm around it. Here's the cadence we run, and it scales down to one or two people:

The discipline matters more than the tool. A spreadsheet and five tabs can run this cadence — it's just miserable, and it breaks the first busy week. The unified queue exists so the cadence survives one.

What this is worth to a small shop

The argument for centralizing isn't only "fewer tabs." It's risk reduction you can price. The expensive security failures at small MSPs are almost never "we didn't have a tool that could have caught it." They're "the alert fired, into a console nobody had open, and it sat there." Consolidating the visibility and triage layer is the cheapest meaningful reduction in that specific failure mode you can buy — and it doesn't require ripping out a single one of the vendors doing the detection.

There's a cost argument too, which we made in why MSPs end up paying 4× their headcount in platform fees: the viewing-and-reporting layer is exactly what per-seat vendors love to charge you twice for. A flat-fee operations layer that reads from your existing security stack flattens that. For the numbers, Morton Command Center uses flat-rate pricing with no per-seat or per-client fees — see current pricing on the homepage →.

Where to start

You don't need to centralize everything on day one. Start with your highest-velocity security vendor — for most MSPs that's the EDR — and get its findings into one triaged queue with a daily ten-minute habit around it. Add the slower-moving sources (compliance, pen test, firewall, patch status) once the rhythm is real. The whole point of security operations without a SOC is building the discipline a SOC enforces, using the tools you already own, at a price a small shop can carry.

If you want to see what a unified security operations view looks like over a real stack, we've written it up in detail on the MSP security operations page, and walked through the most common small-MSP combination on NinjaOne + Huntress + Cork.