Managed SOC

Every security tool you own generates alerts.
Somebody has to read them.

Detection is the easy part now. The hard part is the 40,000 log entries a day that arrive behind it, and the judgment call about which twenty of them are worth interrupting your Tuesday for. AllTech runs a security operations center that reads them — around the clock, including the 2 a.m. ones, and including the ones that turn out to be nothing.

24/7, delivered remotely
The problem

Buying the tool is not the same as watching it

Most businesses that get breached had the product that would have caught it. It was installed, it was licensed, and it fired an alert. The alert went to a dashboard nobody had logged into that week, or to a distribution list that everyone had filtered into a folder six months earlier.

This is the actual failure mode. Not a missing product — an unread one. Security tools are built to be sensitive, because a tool that stays quiet is a tool that gets blamed. So they flag the new local account, the sign-in from an unusual country, the remote access tool that just installed itself as a service. All three of those are routine most of the time. All three of them are also exactly what an attacker does. Nothing in the alert tells you which one you're looking at.

Sorting that out takes a person who knows what normal looks like on your network, has the context to check it against the rest of the environment, and is awake at the time it happens. That person is what a security operations center is. Everything else is licensing.

The stack

Seven feeds, one queue, one place they land

A SOC is only as good as what it can see. Ours pulls from every layer of the environment we manage, not just the endpoints:

Endpoint event logs

The Windows security log on every workstation and server — account creation, group membership changes, service installation, logon activity. This is the layer that catches an attacker who already has valid credentials and isn’t running anything a scanner would flag.

EDR and antivirus telemetry

Behavioral detections and malware mitigations from the endpoint agents, escalated into the same queue as everything else rather than sitting in a separate console.

Microsoft 365 sign-in analysis

Where the login came from, whether the location fits the account’s history, and whether the pattern matches credential stuffing or a legitimate trip.

Microsoft 365 risk detections

Microsoft’s own identity risk signals — anonymous IP address use, unfamiliar sign-in properties, anomalous token activity — pulled in and triaged rather than left in a portal.

Microsoft 365 audit logs

Mailbox rule changes, role assignments, permission grants. The quiet post-compromise activity that never generates a failed login.

Firewall and network telemetry

Perimeter activity correlated against what the endpoints and cloud accounts were doing at the same time.

Advanced breach detection

Correlation rules that fire on a sequence of events rather than any single one, catching the patterns that look ordinary in isolation.

Last month that added up to more than 1,200 endpoint agents, 44 firewalls, and more than 800 Microsoft 365 accounts under continuous monitoring, feeding a single queue reviewed 24 hours a day, 365 days a year.

The numbers

1.2 million logs. 63 incidents. Zero left open.

Most security marketing quotes the big number and stops. The big number is the least interesting one. Here is the whole funnel from a single month across the environments we monitor:

1,220,546
logs and events triaged

Roughly 40,000 a day, collected across every monitored environment and reviewed in a single queue.

63
incidents raised

About two a day. Roughly 19,000 log entries behind every incident that reached a human as a real question.

39 / 24
investigated / tuned out

Thirty-nine worked to closure. Twenty-four closed as expected activity and tuned so the same benign pattern wouldn’t raise a second one.

0
still open at month end

Every incident raised in the period was closed within the period.

Incidents landed on 23 of the 31 days in the period, and nine of them arrived on a weekend. The longest completely quiet stretch was three days. There is no version of this that works as a business-hours service.

Figures from AllTech SOC monitoring, June 1 – July 1, 2026, aggregated across all monitored environments.

Triage

24 of 63 incidents were closed without ever reaching the client

Twenty-four of last month's sixty-three incidents were suppressed — reviewed, matched against known activity in that environment, closed, and tuned so the same benign pattern wouldn't raise a second one. Thirty-eight percent of the queue.

Here is the clearest example. One alert type — a new local user account created on a Windows machine — fired eleven times last month, on eleven different computers. Ten were technicians imaging hardware, setting up a kiosk, or standing up a service account, and were closed as expected. One wasn't, and was worked as a real investigation.

If you had bought that detection and pointed it at your own inbox, you would have received eleven identical alerts, ignored the first four, and been trained by the fifth to ignore the eleventh. That is precisely how the alert that mattered gets missed — not through absence, but through volume.

Deciding which of the eleven was different is the entire product. It requires knowing what that environment's technicians were doing that week, and it cannot be done by a rule.

Real incidents

The 39 that were worth someone's morning

Anonymized, from last month:

A remote access tool installed itself as a service

A managed machine logged a new service installation for a commercial remote-support application. Legitimate software, widely used, and also one of the most common tools in active intrusions — attackers install it because it looks like IT. Escalated, traced back to who installed it and why, closed.

Malware mitigated on two machines the same day

Two separate endpoints, two installer files masquerading as PDF utilities, both stopped by the agent before execution. The tool did its job. The SOC’s job was confirming nothing else on those machines had changed first.

A phishing PDF caught on a workstation, with follow-up

The attachment was blocked. The investigation was about the four related events behind it and whether anyone else had received the same message.

Defense evasion via a scripting engine

Two related detections for behavior consistent with an attempt to bypass endpoint monitoring — the category of activity that never has a file to scan, and never appears in an antivirus report.

An account added to a privileged group — and a phone call

A user was added to a security group on a domain controller outside a change window. Across 1,220,546 log entries that month, this is the one that got a phone call rather than a ticket.

Repeated Microsoft 365 sign-ins from outside the country

One account produced successful foreign logins across most of the month, including a single day with over 1,500 associated events. Investigated, escalated, and closed. It is worth being blunt about this one: a tool would have alerted on the first login and then produced 1,500 more. A SOC establishes what it is on day one and then handles the rest quietly.

All identifying detail removed.

The finding

More incidents started in the cloud than on the endpoints

Broken down by origin, last month's 63 incidents split like this:

Cloud identity 32 · 50.8%

Microsoft 365 sign-ins, risk detections, role changes

Endpoint event logs 26 · 41.3%

Account creation, group changes, service installs

Antivirus and EDR detections 5 · 7.9%

The layer most businesses think of as “security”

Incident origin, all monitored environments, June 1 – July 1, 2026. n = 63.

Just five of the 63 came from antivirus or EDR firing on something malicious. That is the layer most businesses think of as “security,” and it accounted for under eight percent of what actually needed looking at.

The majority started with a valid credential being used in a way that didn't fit — a login from the wrong country, an account added to a group it shouldn't be in, a new local user on a machine at midnight. No malware involved. Nothing for antivirus to catch.

This is the argument for monitoring the whole environment rather than buying one product for the part of it that has a good marketing budget.

Honest expectations

Worth saying plainly

A SOC prevents nothing

Every one of those 63 incidents happened. Detection and response is what you do because prevention is never complete — it is the second layer, not a substitute for the first. If your endpoints are unpatched and your accounts don’t have MFA, fix that before you buy monitoring.

Suppression is a judgment call, and judgment calls can be wrong

Twenty-four decisions last month were “this is expected activity in this environment.” We think all twenty-four were right. The honest framing is that a SOC trades a small risk of tuning out something real against the certainty that an untriaged alert stream gets ignored entirely. Every suppression is logged and reviewable.

Zero open incidents requires you to answer the phone

Every incident closed last month, but some of them closed because someone at the client confirmed what a login or an account change was. A SOC with no one to escalate to stalls at the escalation step.

Sixty-three incidents in a month is not a lot

That is the total across everything we monitor, not one company’s month — a typical monitored client saw two or three. If you are expecting a dramatic weekly report, this is the wrong service. Most months are quiet. You are paying for the coverage on the month that isn’t.

Fit

This is worth it if any of these are true

You already own EDR, antivirus, or Microsoft 365 E5, and nobody reviews what they report
Your team is small enough that “security” is one person’s fourth priority
You operate outside business hours — manufacturing, healthcare, hospitality, municipal
You are subject to cyber insurance questions, CMMC, HIPAA, or a client security questionnaire that asks who monitors your environment and how quickly
You’ve had an incident before and the honest answer to “when did it start” was “we don’t know”

Probably not worth it if: you have a staffed internal security team already, or you're small enough that your entire environment is a handful of laptops and a Microsoft 365 tenant with MFA enforced. We'll tell you if that's the case.

Getting started

Four steps, most of it on us

1

Assessment

We inventory what you have, what’s reporting, and what isn’t. Most environments have at least one security product that stopped sending data months ago and nobody noticed.

2

Deployment and baselining

Agents go on endpoints, cloud connectors go into Microsoft 365, firewall logs get pointed at the collector. Then we spend the first few weeks learning what normal looks like in your environment — which is what makes suppression possible later.

3

Monitoring and triage

Alerts land in the queue 24/7. Analysts triage, investigate, and either close them or escalate. You hear from us when something needs you, not when something fires.

4

Escalation and reporting

Real incidents come to you with what happened, what we’ve already done, and what you need to decide. Monthly reporting shows the full picture, including everything we closed without calling.

FAQ

Common questions

Is this your own SOC or someone else’s?

We operate the monitoring, triage, and escalation for your environment, on a platform built for multi-tenant security operations. What matters practically is that the escalation path ends with the people who already manage your network — not with a ticket queue that has to ask you what a domain controller is.

How fast do you respond?

Alerts are triaged around the clock. Escalation speed depends on severity — a privileged group change on a domain controller gets a phone call; a suppressed duplicate gets logged. Last month every incident raised in the period was closed within the period.

Do we have to replace our current security tools?

Usually not. The SOC ingests from what you have where the integration exists. The assessment tells you where there’s a real gap versus where there’s just a console nobody opens.

What happens if you find something at 3 a.m.?

It gets triaged at 3 a.m. Whether you get woken up depends on what it is, and we agree on that threshold with you during onboarding rather than guessing.

Isn’t this what our IT provider already does?

Ask them who reads the alerts, when, and what the escalation path is at midnight on a Saturday. It’s a fair question and it has a specific answer. Nine of last month’s incidents arrived on a weekend.

Will this generate a pile of alerts we have to deal with?

The opposite is the point. Of 1.2 million log entries last month, 63 became incidents and 39 needed any client involvement at all.

Find out whether anyone is actually reading your alerts.

We'll inventory your security tools, check which ones are still reporting and to whom, and show you what a month of your own alert data looks like once someone sorts it. Most businesses find at least one product they're paying for that stopped sending data and never said so. Plain findings, no pressure.

Trusted by dozens of businesses