If you cannot see what is happening in your environment, you cannot protect it. Over my 30 years in governance, risk, and compliance, I have seen far too many organisations treat logging as a passive technical by-product, something that sits quietly in the background accumulating dust until a major incident occurs. When a breach happens, they suddenly discover their logs were incomplete, overwritten, or modified by the attacker. Storing raw data is just record-keeping; genuine logging is about observability, evidence, and control.
ISO 27001:2022 consolidates former standard requirements into Annex A 8.15 to ensure logging is treated as a core defensive capability. This control ensures your business logs, protects, and reviews security-relevant events across your systems so you can detect incidents early, conduct forensic investigations, and maintain complete accountability.
Quick Summary: What ISO 27001 Annex A 8.15 Requires
At a practical level, Annex A 8.15 is about turning system activity into actionable visibility. It replaces old 2013 controls (12.4.1, 12.4.2, and 12.4.3) with a streamlined requirement. It does not expect you to record every single system event; it expects you to log what matters, protect the evidence, and review it properly. Here is what you need to do in plain English:
- Log Security-Relevant Events: Capture logins, privileged actions, access failures, file edits, and system changes.
- Include Meaningful Details: Ensure every log entry records user identity, event description, timestamp, system ID, and IP location.
- Protect Log Integrity: Lock down log files using read-only permissions, central collection, or append-only vaults so users cannot edit or delete their own trails.
- Synchronise System Time: Align all system clocks to a single UTC reference time source (Annex A 8.17).
- Review and Analyse Logs: Set up routines or automated tools to scan logs for suspicious patterns and security threats.
- Incorporate Cloud and Vendor Logs: Ensure cloud providers, SaaS platforms, and third-party vendors supply accessible log feeds.
Why Weak Logging Is a Major Security Risk
Without effective logging, your incident response team is working in the dark. Hackers rely on missing or unmonitored logs to move sideways, extract data, and cover their tracks without leaving a trace.
Failing to establish proper logging controls exposes your organisation to severe hazards:
- Undetected Long-Term Breaches: Attackers operating inside your network for months without triggering alarms or leaving traceable evidence.
- Inability to Conduct Forensics: Having zero proof of what files were stolen, which servers were compromised, or how an intruder entered.
- Tampered Audit Trails: Insiders or external hackers wiping local log files on compromised machines to destroy evidence.
- Legal and Regulatory Fines: Failing compliance audits or violating data protection laws because user actions cannot be audited.
My 11 Step Plan to Implement Annex A 8.15 Fast
You do not need an enterprise-grade SIEM setup on day one to satisfy an ISO 27001 auditor. Here is my pragmatic, 11-step plan to establish an audit-ready logging framework across your organisation.
1. Define What Should Be Logged (Log What Matters)
Do not try to log every single low-level operating system ping. Focus your logging configuration strictly on security-relevant events:
- Successful and failed user login attempts and multi-factor authentication checks (Annex A 8.5).
- Use of elevated or privileged administrative accounts (Annex A 8.2).
- Changes to system configurations, firewall rules, and security policies (Annex A 8.32).
- Access, modification, or deletion of sensitive customer and financial records.
- Identity management changes, such as account creation, privilege updates, or password resets.
2. Ensure Log Entries Contain Meaningful Context
A log entry that simply says “error” or “access granted” is useless during an investigation. Ensure your system log formats capture five essential attributes:
- Who: The specific user account, service account, or system ID initiating the action.
- What: A clear description of the exact event or command executed.
- When: Precise date and timestamp aligned to UTC.
- Where: The target system name, file path, database table, or process ID.
- Source: The originating IP address, terminal ID, or network location.
3. Synchronise Clocks Across All Log Sources
Correlating an incident across multiple servers is impossible if timestamps do not match. Lock down your time alignment (Annex A 8.17):
- Configure all log-generating systems, cloud hosts, and firewalls to sync with an authoritative UTC time source via NTP.
- Verify that log management tools ingest timestamps cleanly without introducing regional timezone offsets.
- Monitor time offsets regularly to catch silent clock drift across virtual hosts or endpoints.
4. Protect Logs Against Deletion and Modification
Logs are primary targets for intruders seeking to cover their tracks. Ensure users cannot edit or delete their own activity records:
- Set log file permissions to append-only or read-only mode across all local hosts.
- Ship logs continuously off local hosts to a central, isolated log storage repository or cloud vault.
- Revoke log deletion privileges from general IT staff and local administrative accounts.
5. Prevent Log Loss and Capacity Overwriting
A system that silently stops logging because a disk filled up creates a massive security blind spot. Build in storage safeguards:
- Allocate dedicated disk space or auto-scaling cloud storage specifically for log collection.
- Configure automatic log rotation and long-term archiving policies to prevent local disk exhaustion.
- Set up automated monitoring alerts to notify IT leads if a host stops sending log feeds unexpectedly.
6. Manage Privacy and Data Protection Rules
System logs can accidentally collect personal data like email addresses or passwords entered into wrong fields. Keep your logs compliant:
- Configure log outputs to mask or hash sensitive personal data and credentials automatically.
- Restrict access to raw log storage strictly to authorized security and audit leads.
- Align log retention periods with local data privacy laws (such as GDPR) and contractual commitments.
7. Implement Centralised Logging Architecture
Checking log files manually server by server is inefficient and insecure. Centralise your logging visibility:
- Use central log aggregators, SIEM platforms, or cloud-native log services (like AWS CloudWatch or Azure Monitor).
- Correlate log feeds across endpoints, firewalls, databases, and cloud platforms in a single dashboard.
- Store archived historical logs in encrypted, immutable storage for long-term audit compliance.
8. Define Explicit Ownership for Review and Triage
Collecting logs without reviewing them offers zero security protection. Assign clear human accountability across your team:
- Designate specific team members responsible for configuring and maintaining log sources.
- Assign named roles responsible for checking central log dashboards and reviewing daily anomaly reports.
- Define explicit escalation paths for handing off suspicious log findings to incident leads.
9. Conduct Routine Log Analysis and Reviews
Build simple, repeatable review routines to catch operational issues and security anomalies before they turn into breaches:
- Review privileged account usage logs and administrative changes daily or weekly.
- Use automated correlation rules to flag brute-force login attempts or unexpected after-hours access.
- Integrate log analysis directly with your active monitoring controls (Annex A 8.16).
10. Include Cloud Platforms and Third-Party Vendors
Migrating to cloud platforms or SaaS tools does not remove your logging obligations under ISO 27001:
- Enable audit logging across all cloud management consoles (like AWS CloudTrail or Google Cloud Audit Logs).
- Pipe SaaS application audit logs into your central log repository using automated APIs.
- Verify that third-party vendors maintain defensible log retention practices under your supplier agreements (Annex A 8.30).
11. Test Log Completeness During Incident Drills
Prove that your logging setup works in practice by testing it during routine security exercises:
- Simulate a minor incident or account lockout during internal testing drills.
- Verify that the event was captured accurately in central logs with full context and correct timestamps.
- Refine logging rules based on gaps identified during post-incident reviews.
Common Implementation Pitfalls and How to Fix Them
When preparing clients for ISO 27001 audits, I frequently spot the same logging mistakes. Here are the main traps and how to solve them:
- Problem: Logging Everything and Drowning in Unmanageable Noise
Ninja Solution: Prune debug-level system logs and focus strictly on security-relevant events like logins, privilege changes, and access failures. - Problem: Logs Stored Locally on the Same Server Being Audited
Ninja Solution: Stream logs continuously to a central, isolated log server or cloud bucket to prevent local tampering. - Problem: Inconsistent Timestamps Preventing Event Correlation
Ninja Solution: Enforce NTP time synchronisation across all devices and standardise log ingestion in UTC format. - Problem: Collecting Millions of Logs but Never Checking Them
Ninja Solution: Set up automated alert thresholds for high-risk events and assign named staff to review daily log summaries.
The ISO 27001 Ninja Bottom Line
ISO 27001 Annex A 8.15 is about turning raw system activity into clear visibility, and turning that visibility into real control. You cannot protect what you cannot see, and you cannot defend what you cannot prove.
By defining key security events, capturing full context, securing log integrity, synchronising time sources, and centralising log reviews, you turn passive records into an active defensive tool that keeps your business secure, resilient, and completely ready for audit success.