In the transition from ISO 27001:2013 to the 2022 update, the way we handle system audit trails has become much more streamlined. If you are reviewing your old Statement of Applicability (SoA) and looking for the specific requirements for logs, you will find they have been unified under Annex A 8.15: Logging.
While the fundamental goal of recording system activity remains the same, the 2022 revision has shifted the focus from merely “having logs” to a sophisticated, integrated process of producing, storing, protecting, and crucially analysing them. Let’s break down exactly what changed and how to stay ahead of the curve.
Table of contents
The Structural Evolution: From Three Controls to One
In the 2013 version of the standard, logging requirements were fragmented across three separate controls within Domain 12 (Operations Security):
- 12.4.1: Event logging
- 12.4.2: Protection of log information
- 12.4.3: Administrator and operator logs
In the ISO 27001:2022 update, the standard moved to a simplified structure of four themes. These three older controls have been merged into a single, comprehensive requirement: Annex A 8.15, which now lives within the Technological Controls theme. According to Hightable.io, this consolidation is a welcome change for security managers, as it allows for a more cohesive “Logging and Monitoring Policy” rather than managing separate silos of documentation.
What is Annex A 8.15 Logging?
The core objective of Annex A 8.15 is to ensure that logs recording activities, exceptions, faults, and other relevant events are produced, stored, protected, and analysed. It acts as the “black box recorder” for your organisation, providing the evidence needed to detect breaches, support forensic investigations, and verify that your technical controls are working.
The 2022 standard is much more explicit about what a log entry should contain to be useful. It highlights five essential fields:
- User IDs: Who performed the action?
- System Activities: What actually happened?
- Dates and Times: When did it occur? (This links to A 8.17 Clock Synchronisation).
- Device Identity: Which asset was involved?
- Network Addresses: Where did the request originate (IP addresses and protocols)?
Key Changes and New Requirements in the 2022 Version
While the merger of the controls is the most visible shift, the 2022 update introduces several technical nuances that reflect modern cybersecurity threats:
- The Analysis Mandate: In the 2013 version, many organisations treated logs as a “write-only” medium, they collected them but never looked at them. The 2022 version explicitly adds “analysed” to the control name and guidance. You must prove you are actually reviewing logs for anomalies.
- Tamper-Evidence and Protection: The 2022 guidance is more specific about how to protect logs. It suggests techniques like Read-Only Recording, Cryptographic Hashing, or Append-Only storage to ensure that even a system administrator cannot delete evidence of their own actions.
- Cloud and Shared Responsibility: The update acknowledges that in a cloud-first world, logging is often a shared responsibility. You are now expected to ensure your cloud providers (AWS, Azure, Google) are generating the logs you need and that you can access them for your own internal reviews.
- PII in Logs: A new layer of guidance focuses on privacy. Because logs often contain IP addresses or User IDs (which are considered PII under GDPR), you must ensure your logging process complies with privacy requirements, potentially using Data Masking (A 8.11) when sharing logs with third parties.
The Role of Attributes in Annex A 8.15
A central feature of the 2022 update is the use of “Attributes.” For Annex A 8.15, these tags help you define the control’s purpose in your risk assessment. According to Hightable.io, these are vital for mapping your ISMS to other frameworks like NIST or SOC2:
| Attribute | Value for Annex A 8.15 |
|---|---|
| Control Type | Detective |
| Information Security Property | Confidentiality, Integrity, Availability |
| Cybersecurity Concept | Detect |
| Operational Capability | IT Operations Security |
Practical Steps for Compliance
Transitioning to the 2022 standard requires moving from “log collection” to “log management.” Here is how to meet the new A 8.15 criteria:
- Identify What to Log: Don’t log everything, that leads to “noise” and high storage costs. Use your risk assessment to identify critical systems (e.g., those handling sensitive data or admin access).
- Centralise Your Logs: Use a SIEM (Security Information and Event Management) tool or a centralised log server. This makes analysis easier and protects logs from being deleted if a single endpoint is compromised.
- Restrict Access: Ensure that the people who manage the systems (Admins) are not the only ones who can access or modify the logs of those systems.
- Evidence Your Reviews: During an audit, you must show that logs are being analysed. Keep a log of your log reviews, including any “false positives” or incidents that were flagged.
Why the Change Matters
The move to Annex A 8.15 reflects the “Detective” era of security. In 2013, the focus was often on preventing an entry. In 2022 and beyond, we assume that a sophisticated attacker might eventually get in. Robust, protected, and analysed logs are the only way to catch them before they exfiltrate data.
As Hightable.io points out, a successful audit of A 8.15 isn’t about having the most data; it’s about having the right data and a functioning process to act on it. It moves your organization from being reactive to being proactively aware of its own network heartbeat.
Final Thoughts on the Transition
The jump from the 2013 version to the 2022 version’s Annex A 8.15 is a positive step toward operational maturity. While it requires more focus on the “Analysis” phase and better protection of the logs themselves, the result is a more resilient organisation that can stand up to forensic scrutiny.