What to log
Logins and failed attempts, especially for email, VPN, cloud consoles and administrator accounts. Changes to accounts, permissions and security settings. Activity on critical systems and data. Alerts from EDR, firewalls and email security. The goal is not to collect everything, but the events that answer who did what, when and from where.
Keeping logs useful
Logs should be sent to a central place, such as a SIEM, so they survive if a system is compromised and can be correlated. Clocks on all systems must be synchronised, or the sequence of events cannot be reconstructed. Logs must be protected against modification and kept long enough to investigate incidents discovered late, which often means months rather than days.
Logs are only useful if someone looks
Collecting logs without reviewing them gives a false sense of security. Alerts on key events, a SOC that investigates them and periodic reviews turn logs into detection. They also feed MTTD and MTTR metrics and provide the evidence needed after a data breach.
Where it shows up in compliance
ISO 27001 covers logging, monitoring activities and clock synchronisation (Annex A 8.15 to 8.17). The ENS has an activity logging measure, and NIS2, DORA and SOC 2 expect logs to support detection and incident investigation.
