Implementing ISO 27001 Annex A 8.15 Logging
Welcome to your guide on implementing one of the most critical controls in the ISO 27001 standard. As an ISO 27001 certification body, we at ISO27001.com often see organisations struggle with the practical side of logging. It is not just about turning on a switch. It is about gathering the right data to tell a story if something goes wrong.
Annex A 8.15 deals with logging. In the 2022 version of the standard, this control consolidates several requirements from the previous version. It focuses on recording events, generating evidence, and ensuring the integrity of that information. If you are a beginner, this might sound technical. However, the concept is quite simple. You need to record what is happening in your digital environment so you can detect suspicious behaviour and investigate incidents.
Table of contents
Understanding the Requirement
The standard requires you to produce, store, protect, and analyse logs. These logs record activities, exceptions, faults, and other relevant events. Think of this as the CCTV of your computer network. If a burglar breaks into a building, the CCTV provides the evidence. In information security, your logs provide the evidence of a cyber breach or a system failure.
You must record events that are significant to information security. This usually includes successful and failed log-on attempts, access to sensitive files, and changes to system configurations. You also need to protect these logs so that a hacker cannot delete the evidence of their intrusion.
Step 1: Identify What to Log
You cannot log everything. If you try, you will drown in data and miss the important alerts. You need to define which events are relevant to your security goals. Start with the basics that every auditor expects to see.
- User access: Log every time a user logs in or out. Pay special attention to failed attempts, as these often indicate a brute force attack.
- Privileged actions: Record every action taken by an administrator. Admins have the keys to the kingdom, so you must track their usage closely.
- System errors: Log faults and errors. These can be early warning signs of a system becoming unstable or being targeted by an exploit.
- Security events: Ensure your antivirus and firewall logs are captured centrally.
At ISO27001.com, we recommend creating a topic-specific policy on logging. This document should clearly list the events you have decided to record. This shows the auditor that you have made a conscious decision based on risk.
Step 2: Protecting Your Logs
Creating logs is useless if an attacker can simply delete them. Once a hacker gains administrative access, their first move is often to clear the event logs to hide their tracks. You must prevent this.
The best way to protect logs is to send them to a separate, secure server immediately. This is often called a central log server or a SIEM (Security Information and Event Management) system. Even if the original server is compromised, the logs on the secure server remain safe. If you have a smaller setup, you might configure logs to be “write-only” or backup your logs frequently to a location that cannot be overwritten.
Step 3: Review and Analysis
This is the step where most beginners fail. You can have terabytes of logs, but they offer no value if nobody looks at them. The standard specifically asks for the analysis of logs.
You should establish a routine for reviewing these records. For high-risk systems, this might need to be daily. For others, a weekly review might suffice. Many modern tools can alert you automatically when they spot suspicious patterns. If you use automated tools, you must still check that the alerts are working correctly.
What the Auditor Expects
When we visit your organisation for an audit, we are looking for evidence that this process is working. We do not just want to see a policy document. We want to see the reality.
We will ask you to show us your logs. We might ask you to demonstrate what happens when a user enters a wrong password three times. Does it generate a log? Can you find that log entry quickly? We will also look at the timestamps. If your clocks are not synchronised, your logs are legally useless because you cannot prove when an event happened. Ensure you are using a reliable time source.
We also expect to see proof that you review the logs. If you claim to do a weekly review, we will ask for the records or minutes of those reviews. If you say you receive email alerts, we will ask to see a recent example.
Common Pitfalls to Avoid
Implementation can be tricky. Here are some common mistakes we see at ISO27001.com that you should avoid.
- Logging personal data: Be careful not to log sensitive personal information, such as passwords or detailed user inputs. This can create a privacy violation under data protection laws like GDPR.
- Ignoring the cloud: Do not forget your cloud services. AWS, Azure, and Microsoft 365 all generate logs, but you often have to turn them on or configure them to be retained for long enough.
- Retention periods: Decide how long you will keep the logs. Storing them forever is expensive and risky. Storing them for one day is useless. A common standard is to keep active logs for three months and archived logs for a year, but this depends on your specific risks.
Conclusion
Implementing Annex A 8.15 is about building a safety net for your organisation. It provides the visibility you need to spot threats and the evidence you need to recover from them. Start by defining what matters, ensure those events are recorded, and make sure someone is watching the feed.
If you need templates or further guidance on preparing for your certification audit, remember that we are here to help. Good logging practices demonstrate maturity and control, which is exactly what we like to see.