Most SMEs discover they have no logs only after the incident. That's when questions like "who logged in at 3am" and "how did they get in" have no answers. And that means you also don't know whether the hole is actually closed.
"Log management" sounds like something for large corporations with a security team. That's a trap. A 200,000-a-year SIEM really isn't for a 30-person business, but that doesn't mean logs aren't. Between "we record nothing" and "we run a 24/7 SOC" there's a huge grey area that most SMEs ignore, and it's the mistake that always shows up at the worst possible moment.
Why bother with logs at all
Three scenarios we see regularly.
First, a ransomware attack. You pay or you rebuild from backup, but you don't know how they got in. You come back to production with the same hole open, only now the attacker has already mapped your network. At one of our clients — a 22-person printing shop — after the attack it turned out Windows had retained only 48 hours of logs, and the incident had started 11 days earlier. We never learned how they got in. We changed everything we could and hoped for the best.
Second, an ex-employee. You fire someone who had access to the customer folder. Three months later a client calls to say a competitor sent them a quote matching your prices to the cent. Without file access logs — you can prove nothing. At one 12-person accounting firm we switched on basic file-access logging and within a month found that a former external bookkeeper still had an active login and was regularly pulling data on three clients.
Third, a customer dispute that ends up in court. The customer claims they never accepted the order. Without ERP and quoting-system logs, you have no way to show when and from which IP the order was confirmed.
Logs aren't "security paranoia". They're your memory when nobody else remembers.
The minimum worth collecting
Not everything. Collecting "everything" ends with nobody ever finding anything. Set a minimum, make sure it works, then extend later.
- System logins — who logged in, when, from where (IP), success or failure. Windows, ERP, email, VPN, the hosting admin panel. Failed login attempts are your early warning — brute force has looked the same for ten years.
- Permission and account changes — who granted whom access, who changed a role in the ERP, when a new admin account appeared. A new admin account nobody knows about is one of the first moves after a breach.
- Access to sensitive assets — the contracts folder, the customer directory in the ERP, database exports. You don't need to know who opened every file, but a mass download (500 files in 3 minutes) should leave a trace.
- Endpoint events — antivirus/EDR, blocked exes, protection disabled, USB stick plugged in. Windows Defender logs this by default; nobody is collecting it.
- Backup results — what succeeded, what failed, when restore was last tested. Usually the easiest log to add and the one most often ignored.
- Changes in critical apps — who changed a price list, who cancelled an invoice, who marked a new supplier as VAT-verified.
Leave email and browser logs out of scope for now. Too much noise, too little value.
Where to keep it
Rule number one: not on the machine you're monitoring. If an attacker gets into the server, the first thing they do is wipe the logs. Keeping logs only locally on your file server is like recording your break-in camera onto a hard drive sitting on the burglar's desk.
For most SMEs a combination of three things is enough. A simple in-house log collector (Wazuh, Graylog Open, or even Windows Event Forwarding to a dedicated server) pulls events from endpoints and servers into one place. Critical logs (domain controller, ERP, VPN) go additionally to an external location — that can be a simple cloud logging service or even an encrypted archive on external S3. A backup of your logs matters as much as a backup of your data.
Retention: 30 days "hot" (fast to search), 90 days "warm" (available in minutes), 365 days "cold" (compressed, possibly in the cloud, retrievable within an hour). For most SMEs 30/90/365 is enough and cheap. If your sector requires more (healthcare, finance, personal data processing above a certain scale), verify with a lawyer.
What to actually watch
Collecting without watching is theatre. But nobody at a 30-person company will stare at a console 24/7. So set a handful of specific, loud alerts — ones you must not ignore, and not too many of them.
- Failed admin logins > 10 per hour on one account.
- A new account with admin privileges — immediately.
- Antivirus/EDR disabled on an endpoint.
- Backup failed two days in a row.
- VPN login from a country where you don't operate.
- Mass download from the contracts or customer folder.
Everything else goes into the log and waits until it's needed. Don't try to alert on everything — you'll end up with 200 emails a day that nobody reads.
A rollout path for an SME
Don't buy a SIEM. Don't hire a SOC analyst. Start with three steps you can finish in a month.
Week one: turn on detailed logging on the domain controller and file server. Windows logs less than you need by default — you have to tune it in the audit policies. Week two: stand up a simple collector (Wazuh in a container on one server is enough to start) and pipe logs from your 3–5 most critical sources into it. Week three: set up the six alerts from the list above. Week four: run a drill — simulate a failed admin login, check that the alert arrived, that the log is in the collector, that you can find it in under 2 minutes. If yes — it works. If not — fix it now, not after the incident.
That's not a SOC. But it's the difference between "we have no idea what happened" and "we can see who came in, when, and with which account". In most cases that's enough to close the hole and sleep at night.
If you're not sure which of the six alerts to start with in your infrastructure, book an hour-long call. We usually walk out with three things you can do in a week and the name of the person who'll drive it.
Logs are collected before the incident. After the incident, all you can collect is regrets.