Logging Without Looking: When the SIEM Becomes a Storage Bill

Ask whether security events are logged and the answer is almost always yes. There is a SIEM, a dashboard and a licence invoice to prove it. Logging is one of the easiest controls to evidence, which is why it so often satisfies an audit without protecting anything.

The uncomfortable pattern in many breach investigations is that the evidence was there. The suspicious login, the new administrator account, the unusual data transfer: all recorded, sometimes even alerted, and never acted on. The organisation was logging. It was not looking.

Where it goes wrong

Collecting the wrong things

Logs are often switched on wherever it was easy rather than where it matters. Firewall and web proxy logs flood in, while the systems that hold the most sensitive data, such as the ERP, the core database or the cloud management console, send little or nothing.

Alerts nobody tuned

Out of the box rules generate thousands of alerts. Analysts learn which ones are always false and start ignoring them, and the real alert arrives looking exactly like the noise.

No one on the other end

In smaller teams the SIEM is owned by an engineer who also runs the network, the servers and the help desk queue. Alerts land in a mailbox that is checked when time allows. Outside working hours, nobody checks at all.

Retention that does not match reality

Attackers often stay inside networks for weeks or months before they are discovered. If logs are kept for only thirty days, the investigation cannot see how the attack began.

A log nobody reads is evidence for the investigation, not protection.

What auditors should test

1. Coverage of what matters

Start from the critical systems and data, not the SIEM's source list. For each, confirm that authentication events, privileged activity and configuration changes reach the central platform. Gaps here are the most important finding you can make.

2. Detection use cases

Ask for the list of detection rules and what each is designed to catch. Good programmes map rules to the attacks most likely to affect the organisation, such as compromised accounts, new privileged users, mass data downloads and disabled security tools.

3. A real alert, followed end to end

Pick a sample of alerts from the last quarter and trace each one. When was it raised, when was it looked at, what was decided, and was the decision recorded? Time from alert to first review is one of the most revealing numbers in security.

4. Out of hours

Ask who would see a critical alert raised at 2 AM on a Friday. If the honest answer is "Monday morning", that is a risk leadership needs to accept or fund.

5. Test it

With approval, create a harmless test event such as adding a dummy account to an administrator group, and see whether it is detected and acted on. Nothing proves monitoring like a controlled test.

6. Retention and integrity

Confirm that logs are kept long enough to investigate realistic attacks, protected from alteration and deletion, and that the clocks across systems are synchronised so events can be put in order.

Fixing it sensibly

The answer is rarely more data. It is fewer, better sources tied to real risks, a short list of well tuned detections, a named person or service responsible for every alert, and regular testing. For many organisations, a managed detection and response service is a more realistic way to cover nights and weekends than building an in house team.

Four questions for leadership

Do our most critical systems send their security logs to a place someone monitors?
How long does it take, on average, for a critical alert to be looked at?
Who responds to an alert outside working hours?
When did we last test whether a real attack would be detected?

Logging is necessary, but it is the start of the control, not the control itself. Auditors who stop at "logs are collected" are testing the storage bill. The question that matters is whether anyone would notice an attack while there is still time to stop it.