Imagine a plane crash where the investigators arrive at the scene, only to find the black box is missing—or worse, it was never turned on. That is the exact scenario you face in information security if you don’t have proper logging in place. When a breach happens (and it’s often a case of when, not if), your logs are the only things that will tell you how the attackers got in, what they took, and if they are still there.
This is where ISO 27001:2022 Annex A 8.15 comes in. It is the control dedicated to Logging. It requires you to produce, store, protect, and analyse logs of events, faults, and exceptions. It sounds technical, but it’s actually one of the most fundamental aspects of good security governance.
Table of contents
What is Annex A 8.15?
In the simplest terms, Annex A 8.15 is about evidence. The standard defines it as the need to produce, store, protect, and analyze logs that record activities, exceptions, faults, and other relevant events.
It acts as a detective control. While a firewall might stop an intruder (preventive), logging tells you that the intruder tried to get in 500 times in the last hour (detective). Without this visibility, you are operating in the dark.
What Should You Actually Log?
One of the biggest mistakes organisations make is trying to “log everything.” This creates a tsunami of data that nobody can read, and it costs a fortune to store. Instead, you need to focus on relevant events.
According to the guidance, and to satisfy an auditor, your logs should typically include:
- User IDs: Who did it?
- System Activities: What did they do? (e.g., launched an application, deleted a file).
- Timestamps: When did it happen? (Crucial for forensics).
- Device Identity: Where did it come from? (IP address, MAC address, or hostname).
Specific Events to Capture
You should configure your systems to capture high-value events such as:
- Successful and rejected system access attempts (failed logins are a key indicator of brute-force attacks).
- Use of privileged accounts (admin users should always be under the microscope).
- Changes to system configurations.
- Activation or de-activation of security systems (e.g., stopping the antivirus).
- Access to sensitive data files.
Protection is Paramount
Logs are only useful if they are trusted. A clever attacker knows that the first thing to do after breaching a system is to wipe the logs to cover their tracks. Therefore, Annex A 8.15 places a heavy emphasis on protecting your log information.
You need to ensure that logs are protected against tampering and unauthorized access. Ideally, logs should be:
- Read-only: Administrators should not be able to edit the history.
- Stored Remotely: Send your logs to a separate, secure server or a cloud-based SIEM (Security Information and Event Management) system. If the main server is compromised/wiped, the evidence remains safe elsewhere.
- Hashed: Use cryptographic hashing to prove that the log file hasn’t been changed since it was written.
The “So What?” Factor: Analysis and Monitoring
Producing logs is useless if nobody looks at them. The control explicitly requires that logs are analyzed.
For a small business, this might mean a weekly manual review of the “Critical” and “Warning” events on your main server. For larger organisations, this requires automated tools (like a SIEM) that can correlate events—for example, spotting that a user logged in from London and New York within 5 minutes of each other.
You need to define the attributes of a security event and set up alerts for exceptions. If a user tries to download the entire customer database at 3 AM on a Sunday, your phone should probably buzz.
The Privacy Trap
A word of caution: Logs often contain personal data (PII). Usernames, IP addresses, and browsing history are all protected under regulations like GDPR.
You must ensure that your logging practices comply with privacy laws. Do not log sensitive authentication information like passwords or PINs (even in plain text). Ensure that access to the logs themselves is restricted to authorized personnel only, as the logs effectively become a database of employee activity.
Practical Implementation Steps
If you are looking to get this control running today, here is a simplified roadmap:
1. Identify Your Requirements
Look at your legal, regulatory, and contractual obligations. Do you need to keep logs for 6 months? 12 months? 5 years? Define this clearly.
2. Create a Policy
You need a “Logging and Monitoring Policy” that sets out the rules. It should define what events you log, how long you keep them, and who reviews them. If you don’t want to write this from scratch, Hightable.io offers comprehensive ISO 27001 toolkits and templates that can save you significant time and ensure you meet the auditor’s expectations.
3. Configure the Technology
Enable logging on your operating systems, applications, and network devices. Ensure they are synchronized to a single time source (Clock Synchronization is covered in Annex A 8.17, but it is vital here so your timelines match).
4. Secure the Storage
Ensure that the storage location for your logs has strict access controls. Only the security team or auditors should generally have read access.
5. Test Your Response
Don’t wait for a hack to see if your logging works. Simulate an event (like creating a dummy admin account) and see if it appears in your logs and triggers the expected alert.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls
Collecting too much: If you log every single mouse click, you will run out of storage and you will never find the needle in the haystack. Focus on security-relevant events.
Ignoring version control: Ensure your documentation regarding logging is up to date. If your policy says you review logs daily, but you only do it monthly, that is a non-conformity.
Set and Forget: IT environments change. When you install a new software platform, you must remember to configure the logging for it immediately.
Conclusion
Implementing ISO 27001 Annex A 8.15 is about creating a safety net for your organisation. It provides the visibility you need to detect threats and the evidence you need to investigate them. By focusing on the right events, securing your data, and actually analysing what you record, you turn your logs from a passive storage burden into an active security asset.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
