Logging and monitoring: collecting logs is not the control

Almost every organisation collects logs. Far fewer can evidence that anyone looked at them. That gap - between collection and review - is one of the most common audit findings, and it is also why breaches sit undetected in environments that had all the necessary telemetry.

What to log

Frameworks converge on a similar core set:

• Authentication - successes and failures, including MFA outcomes.
• Privileged actions - administrative use, privilege escalation, role changes.
• Access to sensitive data - who read what, especially personal, health or cardholder data.
• Account lifecycle - creation, modification, deletion, permission changes.
• Configuration and security control changes - including changes to logging itself.
• System and application errors relevant to security.
• Network boundary events - blocked connections, unusual egress.

Each entry needs the basics: timestamp with a synchronised source, actor identity, action, target, and outcome. Logs without an identifiable actor are of limited use during an investigation.

Retention

Requirements vary, and you must satisfy the strictest that applies:

• PCI DSS is explicit - a minimum retention period with a portion immediately available for analysis.
• ISO 27001 requires retention appropriate to your risk assessment and legal obligations.
• Sector regulators such as SAMA and the NCA set their own expectations.
• Privacy law pulls the other way - logs containing personal data are themselves subject to minimisation and retention limits.

That tension is real: security wants longer retention, privacy wants shorter. Resolve it deliberately, document the reasoning, and apply different periods to different log types rather than one blanket policy.

Tamper resistance

Logs are only evidence if they can be trusted. Expect scrutiny on:

• Centralisation - shipped off the originating host promptly, so compromising a server does not erase its own trail.
• Write-once or immutable storage for critical logs.
• Restricted access - administrators of a system should not be able to alter its logs.
• Logging the logging - any change to log configuration is itself an event worth alerting on.
• Time synchronisation across sources, without which correlation is unreliable and timelines are contestable.

The review requirement

This is the part organisations skip. Frameworks expect evidence that logs are examined - not necessarily by a human reading every line, but that a defined process surfaces and dispositions anomalies. Acceptable evidence includes:

• Alert rules with documented rationale and tuning history.
• A ticketed queue showing alerts triaged, with outcomes recorded.
• Periodic review records for log types not covered by real-time alerting.
• Metrics - alert volume, false positive rate, time to triage.

"We have a SIEM" is not evidence of review. The ticket trail is.

Avoiding the two failure modes

1. Collecting everything and reviewing nothing. Expensive, and provides false assurance. Prioritise the event types tied to your actual risks.
2. Alert fatigue. If analysts routinely close alerts without investigation, the control has failed even though it appears to operate. Track the closure-without-investigation rate honestly - it is a better health indicator than alert volume.

Practical starting order

1. Log authentication and privileged actions everywhere first.
2. Centralise and protect those logs before broadening coverage.
3. Set retention per log type against your strictest obligation.
4. Write a small number of high-quality alerts rather than many noisy ones.
5. Create the review record from day one - retrofitting it is not possible.

Key takeaways

• Collection is assumed; evidenced review is the control.
• Ship logs off-host and restrict who can alter them.
• Set retention per log type, balancing security against privacy minimisation.
• Track closure-without-investigation - it reveals alert fatigue early.