.webp)
A security operations centre is not a product that gets installed. It is people, tools that feed them information, and a written procedure for what happens when something looks wrong. The tools watch. The people decide. That division is what disappears when monitoring is sold as software alone.
Most of what a shift handles is quiet. Signals arrive from servers, laptops, firewalls, cloud identity platforms and mail systems, and nearly all are ordinary: someone signing in from a hotel, an overnight job that ran long. The first task is to sort that traffic so the signals that matter are not buried underneath it.
The second task is correlation. A failed sign-in is uninteresting on its own. A failed sign-in, then a successful one from an unfamiliar location, then a new mailbox forwarding rule, is a story — and only if somebody looks at all of it together. Tools raise events. A person joins them up.
The third is the decision. Every alert ends benign and closed, suspicious and watched, or confirmed and acted on. Nothing is parked in an inbox for tomorrow, because ransomware does not wait for tomorrow. A shift therefore involves:
Every shift hands over to the next in writing. An alert raised at midnight and picked up when the office opens was never really being monitored.
These terms get used interchangeably in sales conversations, and the confusion is not accidental: it lets a tool be sold as though it were a service.
EDR, endpoint detection and response, is software that runs on a device. It records what processes did, recognizes behaviour that looks like an attack rather than matching a list of known bad files, and can act automatically. Left alone, it produces alerts nobody reads.
MDR, managed detection and response, is that software plus somebody whose job is to respond to what it finds. When a detection fires an analyst reviews it and acts under agreed rules, rather than an email landing with your office manager.
A SOC is the wider function. It takes in more than endpoints — identity, mail, network, cloud and servers — runs on a shift pattern so somebody is always on duty, and holds the procedures and records that turn detections into a handled incident.
| EDR | MDR | SOC | |
|---|---|---|---|
| What it is | Software on a device | A service built around that software | A staffed function covering the whole environment |
| What it watches | Endpoint behaviour | Endpoint behaviour, with analyst review | Endpoints, identity, mail, network, cloud, servers |
| Who acts | Automated rules, then whoever notices | An analyst, under rules agreed with you | The analyst on shift, escalating under procedure |
| What you get | Alerts | Alerts that have been triaged | A decision, an action, and a record of both |
We run all three together: the endpoint agent is the sensor, MDR is how detections get handled, and the SOC is the staffed function above both. More on how the pieces fit on our unified security management page.
Automation is good at the unambiguous and bad at judgment. The rule we work to is that automation contains, and a person decides anything carrying a consequence.
Escalation contacts are agreed during onboarding: who to call out of hours, who can authorize disruptive action such as taking a server off the network, and who to fall back to.
This is the question worth putting to any provider, because it is where the difference between a staffed operation and a monitoring dashboard shows. At two in the morning on a Sunday an alert fires, and nothing about the response changes. The analyst on shift is at a desk, already signed in, with the same tooling and procedures as at two on a Tuesday afternoon. No call-out tree, no engineer reaching for a laptop from a bedside table, no waiting for the office to open.
The alert is triaged. Benign, it is closed and noted. Suspicious, it is investigated rather than dismissed because the hour is inconvenient. Confirmed, containment happens immediately under rules already agreed with you: the device comes off the network, the account is disabled.
Only then does the phone call happen, because the first minutes are better spent stopping the spread than describing it. You get a plain account of what was seen, what has been done and what we need from you.
Weekends and statutory holidays are ordinary shifts here. Attackers pick long weekends deliberately, because most organizations are not watching.
If you are reading this during an active incident, do not wait for a form. Call 647-476-5259.
The phrase is used loosely enough to be almost meaningless in a proposal, so it is worth being specific about what it describes here and what it is often used to cover elsewhere.
None of the arrangements on the right is dishonest, and some are reasonable purchases at their price. Ask any provider what a named person does at two on a Sunday morning, and whether that person is at a desk or at home.
Many of the organizations we monitor already have internal IT. The SOC is not a replacement for them and has no interest in taking their job.
The practical split is that your team owns the environment and we own the watch. Your people know which server matters at month end and which contractor is legitimately working at odd hours. We know what the telemetry is showing and what to do about it. Neither half is much use without the other.
In a co-managed arrangement we agree, before go-live, what we may act on unilaterally and what we must consult on. Most internal teams give us standing authority to isolate an endpoint and disable an account, while keeping authority over servers and network kit. Some want a call before any action at all. Both work, provided the boundary is written down rather than assumed.
Your team also gets the output. Detections, investigations and closed incidents are visible to them rather than held in a black box. Where a detection points at a configuration problem, it goes to them as a recommendation, not a criticism.
If you would rather we carried more of the day-to-day load, that is what our co-managed IT arrangement covers, with our helpdesk sitting behind it.
Being straight about the boundary is more useful than implying monitoring covers everything. A SOC is a strong control, not a complete security programme.
Related reading: backup and disaster recovery, IT compliance in Ontario and emergency ransomware recovery.
It is staffed. There is an analyst on shift at all times, including nights, weekends and statutory holidays, using the same tooling and written procedures as during the day. Shifts hand over in writing, so an alert raised overnight is investigated overnight.
EDR is software that runs on a device, records behaviour and can act automatically. MDR is that software plus people whose job is to review and respond to what it finds. EDR with nobody reading its output produces alerts nobody acts on. Our SOC sits above both and adds identity, mail, network and server telemetry.
The analyst on shift triages it immediately. If it is confirmed malicious, containment happens first under the rules agreed with you: isolating the device, disabling the account or revoking the session. A named contact at your organization is then telephoned. For critical incidents we work to a 15-minute response target.
Yes. Before go-live we agree what we may act on without asking and what needs a call first. Your team sees the same detections and incident records we do.
No. Monitoring tells you that something happened. Backups are how you recover, and patching is how you reduce what can be exploited in the first place. A SOC does not remove the need for either.
Our head office is at 141 Main Street N, Markham, Ontario, and you can reach us on 647-476-5259. We are SOC 2 Type 2 attested, meaning an independent auditor has examined how we handle your data and access rather than taking our description at face value.
If your question is not here, a short call is faster than a form. Book a discovery call or read our client case studies.
Scoped to your device count, what needs covering, and whether evidence has to be retained for an auditor. There is no charge for scoping it.
%20(1).avif){kind=logo}
%201.avif)
