Security monitoring for SMEs: where to start

Most of the attacks we analyse were not “undetectable”. The traces were in the logs — failed and successful logins from exotic addresses, strange tools being launched, sudden outbound traffic. The problem is that nobody was looking at those logs, because “security monitoring” brings to mind a three-shift SOC and an enterprise budget. In reality, between “nothing” and a “24/7 SOC” there is a long scale of solutions within reach of a mid-sized company. This article shows how to climb it sensibly.

Why monitor if we already have defences

Prevention (firewalls, MFA, patching) reduces the number of successful attacks, but never to zero. Industry statistics have shown the same problem for years: the time from breach to detection is measured in weeks and months — and the longer an attacker sits in the network, the more it costs. With ransomware, days to weeks usually pass between entry and encryption: that’s the window in which good monitoring turns a catastrophe into a manageable incident.

Monitoring is also a formal requirement: NIS2 mandates detecting and reporting incidents within specific deadlines (24/72 hours), GDPR requires establishing a breach “without undue delay”, and insurers increasingly ask about EDR and logs directly in policy questionnaires.

Step 1: the logs you must have (before you buy anything)

Before anyone says “SIEM”, get your data sources in order. The minimum for a typical company:

• Identity — logins to Microsoft 365 / Google Workspace, VPN and critical systems: from where, when, with MFA or not, failed attempts.
• Endpoints and servers — system events, launched processes (on Windows: advanced auditing or Sysmon), account and permission changes.
• Network — firewall and DNS logs: where your network connects to; often the cheapest way to spot communication with malicious infrastructure.
• Critical applications — access and error logs wherever the money and customer data live.
• Cloud — audit trails (who changed configuration, who granted permissions); we cover cloud misconfigurations here.

Two technical rules: logs must flow off the machine they describe (attackers wipe local logs first), and retention should be at least 90 days, better 6–12 months — because incidents are discovered late.

Step 2: EDR — the best first purchase

If you have budget for one tool, buy EDR (Endpoint Detection and Response) for workstations and servers. Unlike classic antivirus, EDR sees behaviour (processes, connections, system changes), detects techniques known from real attacks and lets you remotely isolate an infected machine with one click. In most incidents we help with, an EDR alert was the first signal — provided someone read it.

And that’s the crux: a tool without a human is not monitoring. An alert at 2 a.m. that nobody sees until 9 a.m. gave the attacker a seven-hour head start.

Step 3: alerts someone will actually handle

Instead of hoarding everything “just in case”, start with a short list of high-value, low-noise alerts:

1. a privileged account login from a new country or at an unusual hour,
2. EDR or antivirus being disabled or uninstalled on a machine,
3. creation of a new admin account (domain, M365, cloud),
4. a mail-forwarding rule to an external address being added (the classic follow-up to phishing),
5. mass file operations / detection of known attacker tooling,
6. a VPN login without MFA or a burst of failed MFA prompts (possible MFA fatigue),
7. a sudden spike in outbound traffic from a server (possible exfiltration).

For each alert define: who receives it, how quickly they must react and what they do first (a one-page playbook is enough). Ten alerts handled within the hour beat a thousand alerts ignored.

Step 4: SIEM, XDR or an external service?

Once the basics work, the choice of path depends on resources:

Your own SIEM/XDR. Sensible log centralisation can be built today on ecosystem tools (e.g. Microsoft Sentinel with M365) or open source (Wazuh, Elastic). Licence costs can be moderate — the real cost is the person: someone has to tune rules, review alerts and maintain the whole thing. Without at least half an FTE for this, a SIEM becomes an expensive archive.

MDR / SOC-as-a-Service. An external team monitors your EDR and logs 24/7, calls you about real incidents and helps respond. For companies without their own security team this is usually the best protection-to-price ratio — you pay for vigilance, not a tool. What to watch when choosing: guaranteed response times (SLA), the scope of response (do they only “inform” or also isolate a machine), language of communication, and whether the reports make sense to anyone outside IT.

A hybrid model. Critical alerts go to the external service; reviews and business context stay with you. We offer this model within our security support packages — monitoring combined with retests and advisory.

Step 5: test that it works

Untested monitoring is hypothetical monitoring. Three ways to verify, starting with the simplest:

• a light “purple team” exercise: run a few techniques in a controlled way (e.g. credential dumping in a lab, an unusual VPN login) and check whether the alerts arrived and who reacted,
• a penetration test with detection scoring: the pentester acts while you measure what your monitoring saw — we run tests this way when the client wants detection assessed too,
• a post-incident review: every real incident (even a minor one) should end with the question “which alerts fired, and which should have”.

Frequently asked questions (FAQ)

What does sensible monitoring cost for a company of 50–200 people? Order of magnitude: EDR typically runs to tens of złoty per seat per month; an MDR service — from a few to a dozen or so thousand złoty monthly depending on device count and SLA; your own SIEM — licences from zero (open source) upwards plus the real cost of engineering time. For comparison: the median cost of a ransomware incident at an SME is in the hundreds of thousands.

Isn’t antivirus with a console enough? An AV console shows detected malicious files, but modern attacks largely use legitimate tools (PowerShell, PsExec, admin accounts) — AV doesn’t flag those. EDR analyses behaviour, not just signatures, and offers response (host isolation), not just information.

What should we log first if the budget is near zero? Three nearly free things: full sign-in logs in M365/Google Workspace (with alerts on forwarding rules), VPN/firewall logs shipped to a separate machine, and free Sysmon plus centralised Windows event collection. That covers a surprisingly large share of real attack scenarios.

Does NIS2 require us to run a 24/7 SOC? Not literally — it requires the ability to detect and handle incidents and to report within the 24/72-hour deadlines. That can be met with an MDR service or a well-organised on-call rota, without building your own SOC. What matters is documenting the process and having evidence it works.

We have logs, but nobody has time for alerts. What now? That’s the most common state, and the honest answer is: outsource the first line. Keep the decisions (what gets isolated, who gets informed) and the business context in-house. Let’s talk — we’ll help match the model to your team size, including as part of ongoing security support.

Summary

Security monitoring at an SME doesn’t start with buying a SIEM but with three decisions: which logs we collect centrally, which signals we alert on, and who reacts to them and how fast. EDR plus a short list of good alerts plus someone who reads them — that’s the level that catches most real attacks before they become disasters. The rest can be added in stages, at the pace of your budget and your team’s maturity.