The traces are there, but nobody is looking
An attack rarely begins with encrypted files. First come smaller signals: a sign-in to your email from a country where you have neither customers nor branches, an accounts department login that, at two in the morning, opens folders it never touches during the day, a server sending data to an unknown address. Many of these events end up in the firewall, server and Microsoft 365 logs, sometimes days before the damage is done.
But a log does not alert anyone: it is written, kept for a while and overwritten. If the suspicious event happens on Saturday night, the first person to notice is often whoever finds the warehouse management system locked on Monday morning.
Antivirus, EDR, SIEM, SOC: who does what
In supplier quotes the acronyms get mixed together. It helps to separate them.
- Traditional antivirus: blocks files it recognises as known threats.
- EDR (Endpoint Detection and Response): an agent on PCs and servers that records the machine's behaviour (programs launched, connections, file changes), flags suspicious sequences and can isolate the machine from the network.
- SIEM (Security Information and Event Management): collects logs from different systems and correlates them. Three failed VPN logins, then a successful one, then a new administrator: taken one by one they mean nothing, but lined up together they do.
- SOC (Security Operations Centre): the people and procedures that watch the alerts and decide what to do.
- MDR (Managed Detection and Response): the managed service that brings together tools, analysts and response.
| Tool | What it does | What it does not do |
|---|---|---|
| Antivirus | Blocks known malicious software | Does not see someone who gets in with a stolen password and uses the system's own legitimate tools |
| EDR | Records the behaviour of PCs and servers, raises alerts, isolates the machine | Does not see cloud services, firewalls or devices without an agent; if nobody reads the alerts, it is just a recorder |
| SIEM | Collects logs and correlates them | Does not decide or act: it produces alerts that someone has to read |
| SOC and MDR | Assess alerts, decide and respond according to agreed rules | Do not fix weak passwords, unpatched systems or backups that have never been tested |
Detecting is not responding
It is 3 am and the EDR reports that a process on the accounts department's PC is renaming files in rapid succession. The alert has fired correctly. But if it lands in a mailbox that someone will open at 8:30 am, it is as if it had never arrived.
The real question is who, at that hour, has the authority to isolate that PC or block an account without waiting for the morning. And how far they can go on their own: a laptop, yes; the ERP server perhaps only after a phone call to a designated contact. These rules have to be written in advance, with names, phone numbers and thresholds.
An attack generally goes through five phases: reconnaissance, intrusion, lateral movement, exfiltration, impact. Monitoring is there so you can intervene in the early ones. Stopped at intrusion, the attack costs you one account to block; once it reaches impact, it becomes the night described in the guide on the first hours of a ransomware attack.
Questions to ask a provider
- Real 24/7 coverage or on-call? Analysts on shift watching alerts as they come in are not the same as a technician who gets a call when a rule is triggered. Both are fine, as long as the contract says which one you are buying.
- What is in scope? Servers, PCs, the laptops of sales staff on the road, cloud, Microsoft 365, firewalls. Anything that does not send data to the service is not monitored.
- Who is authorised to act, and how far? Which actions are automatic, which need your go-ahead and who gives it at night.
- How are false positives reduced? With an initial period in which the service learns how your systems normally behave, and rules that are reviewed over time. An alarm that is always ringing soon stops being heard.
- How long are logs kept? An intrusion discovered late can only be reconstructed with the logs from that period. Also ask whether they remain yours when the contract ends.
- What reports will you receive? A periodic summary that management can read, and a report after every incident.
When an SME needs it, and what comes first
A monitoring service makes sense when operations depend on systems that cannot go down and nobody in the company can follow alerts out of hours, or when customers and regulations require you to show that you can detect and handle an incident, as is the case for organisations that fall under NIS2.
A SOC watching over a network without MFA, with unpatched systems and backups that have never been tested, will see plenty of alerts and be able to do little about them. That is where to start: multi-factor authentication, patch management and a backup with an isolated copy, verified with a real restore.
The most common mistakes
- Buying the tool without the service. The EDR is installed, but the alerts go to an address nobody checks.
- Monitoring only the PCs. The attacker gets in through a Microsoft 365 account or the VPN, where nobody is looking.
- No rules on who decides. The SOC phones, the contact person does not answer and nobody else is authorised.
- Treating it as insurance against everything. Monitoring shortens reaction times; it does not replace backups or the recovery plan.
In short
Antivirus and EDR work on the devices, the SIEM correlates the logs, the SOC is whoever watches the alerts and decides. The value lies in the response: who steps in at night, on which systems and with what authority. For an SME it comes after MFA, updates and tested backups, not instead of them.