ISO 27001:2022 Annex A 8.15: The Ultimate Guide to Logging
In the world of information security, there is an old saying: “If you didn’t log it, it didn’t happen.” Well, actually, if you didn’t log it, it did happen, you just have no way of proving how, when, or who was responsible. That is where ISO 27001:2022 Annex A 8.15 comes in.
This control is the backbone of your detective capabilities. It ensures that when (not if) something goes wrong, you have the digital breadcrumbs required to reconstruct the event, understand the impact, and stop it from happening again. Whether you are an IT manager or a CISO, understanding this control is non-negotiable for a robust security posture.
Table of contents
What is ISO 27001 Annex A 8.15?
Annex A 8.15 is titled simply “Logging.” It requires organisations to produce, store, protect, and analyse logs that record activities, exceptions, faults, and other relevant events. It replaces the older controls regarding event logging from the 2013 version of the standard.
The primary purpose here is detection and investigation. Logs are your surveillance cameras for the digital network. They help you identify unauthorized access, troubleshoot system errors, and provide evidence for internal or external investigations. For a broader look at how this fits into the full list of controls, resources like ISO27001.com can be very helpful.
What Should You Actually Log?
One of the biggest mistakes organisations make is turning on “logging for everything” and drowning in data. The standard requires a more targeted approach based on risk. You need to identify what is critical to your specific environment.
However, generally speaking, your logs should capture the “Who, What, When, Where, and How” of an event. Specifically, you should aim to record:
- User IDs: Who performed the action?
- System Activities: What actually happened? (e.g., file deleted, permission changed).
- Timestamps: When did it happen? (Crucial for correlating events across different systems).
- Device Identity: Where did the request originate? (IP addresses, protocols).
Key Events to Monitor
While you shouldn’t log every single mouse click, you must capture security-relevant events, including:
- Successful and rejected system access attempts (failed logins are a classic indicator of a brute-force attack).
- Use of privileged accounts (Admins should be watched more closely than anyone else).
- System start-up and shut-down procedures.
- Changes to system configurations or security settings.
- Activation and de-activation of security systems (like turning off the antivirus).
- Application errors and exceptions.
Protecting Your Logs
Here is the catch: Hackers know about logs. In fact, one of the first things a sophisticated attacker will do after gaining access is try to wipe or alter the logs to cover their tracks. Therefore, protecting your logs is just as important as collecting them.
You need to ensure that logs are protected from tampering and unauthorized access. This often involves:
- Segregation: Storing logs on a separate, secure server that standard admins cannot access.
- Read-Only Access: Ensuring that logs can be written to but not overwritten or deleted by the system generating them.
- Hashing: Using cryptographic hashes to prove that log files haven’t been altered since they were created.
The “So What?” Factor: Log Analysis
Collecting logs and dumping them into a dark hole where nobody looks at them is useless. Annex A 8.15 explicitly requires that logs are analysed.
You need a process for reviewing these logs regularly. For small organisations, this might be a weekly manual review of critical server logs. For larger enterprises, this usually necessitates a Security Information and Event Management (SIEM) tool that automatically correlates events and alerts you to anomalies in real-time.
Common Implementation Challenges
1. The Privacy Paradox
Be careful. Logs often contain Personally Identifiable Information (PII), such as IP addresses or usernames. You must ensure that your logging practices comply with privacy laws like GDPR. You might need to mask or redact certain fields to protect user privacy while maintaining security visibility.
2. Clock Synchronisation
If your firewall thinks it is 10:00 AM and your server thinks it is 10:05 AM, correlating an attack between the two is a nightmare. Ensure all systems are synchronised to a single reliable time source (NTP).
3. Alert Fatigue
If your system sends you an email for every single failed login, you will stop reading them. You need to tune your alerting thresholds so that you only get notified about genuine risks (e.g., 10 failed logins in 1 minute).
Conclusion
ISO 27001 Annex A 8.15 is not just a box-ticking exercise; it is a fundamental component of your security hygiene. By effectively logging events, protecting that data, and actually analyzing it, you transform your organisation from a passive victim into a proactive defender. Remember, in the event of a breach, your logs are your best witness—treat them accordingly.
