ISO 27001 Annex A 8.15 is a security control that mandates the production, protection, and regular analysis of audit logs to record system activities, exceptions, and security events. By creating a tamper-evident digital forensic trail, organizations can detect unauthorized access, investigate incidents, and ensure accountability for privileged user actions.
In this guide, I will show you exactly how to implement ISO 27001 Annex A 8.15 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 8.15 Logging
ISO 27001 Annex A 8.15 requires organizations to produce, store, and critically, analyse logs that record system activities, exceptions, and security events. Its goal is to create a digital “forensic trail” that allows you to investigate incidents, detect unauthorised access, and ensure that privileged users (like IT Admins) aren’t abusing their power.
Core requirements for compliance include:
- Standard Field Requirements: Your logs aren’t useful if they lack detail. Every security log should ideally record: Who (User ID), What (Event type), When (Timestamp), Where (Device/Location), and How (Network Address).
- Protecting the Trail: Logs must be protected from tampering. You must ensure that even an administrator with high privileges cannot delete or modify logs to hide their own tracks.
- Analysis is Mandatory: It is not enough to just store logs in a “digital bucket.” You must have a process for regularly reviewing them (either manually or via an automated tool like a SIEM) to identify patterns or anomalies.
- Retention Policy: You must define exactly how long you keep each type of log. Keeping logs “forever” is a privacy risk (GDPR), while deleting them too soon can hinder forensic investigations.
Audit Focus: Auditors will look for Integrity and Utility:
- The “Admin” Test: “How do you ensure your IT Manager cannot delete the audit log of their own actions?”
- Forensic Proof: “Show me the logs from a specific day three months ago. Are they still accessible and accurate?”
- Actionable Review: “Show me evidence that someone actually looks at these logs. Where is the monthly log review report?”
Common Log Retention Schedule:
| Log Type | Retention Period | Primary Reason |
|---|---|---|
| Firewall / Network Logs | 12 Months | Forensic history & industry standards (PCI-DSS). |
| User Access / Login Logs | 12 Months | Investigating unauthorized access attempts. |
| Antivirus / Security Alerts | 12 Months | Identifying recurring malware trends. |
| System Error Logs | 3 Months | Technical troubleshooting (lower security risk). |
Table of contents
- Key Takeaways: ISO 27001 Annex A 8.15 Logging
- What is ISO 27001 Annex A 8.15?
- ISO 27001 Annex A 8.15 Free Training Video
- ISO 27001 Annex A 8.15 Explainer Video
- ISO 27001 Annex A 8.15 Podcast
- ISO 27001 Annex A 8.15 Implementation Guidance
- How to implement ISO 27001 Annex A 8.15
- Common Log Retention Schedule
- How to comply
- What will an auditor check?
- Top 3 ISO 27001 Annex A 8.15 mistakes and how to avoid them
- Applicability of ISO 27001 Annex A 8.15 across different business models.
- Fast Track ISO 27001 Annex A 8.15 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 8.15 FAQ
- Relate ISO 27001 Controls
- Further Reading
What is ISO 27001 Annex A 8.15?
ISO 27001 Annex A 8.15 is about logging which means you have to record the actions of users and system events to aid with incident response and investigations.
ISO 27001 Annex A 8.15 Logging is an ISO 27001 control that requires an organisation to produce, store, protect and analyse logs of activity, exceptions, faults and relevant events.
ISO 27001 Annex A 8.15 Purpose
ISO 27001 Annex A 8.15 is a detective control that to record events, generate evidence, ensure the integrity of log information, prevent against unauthorised access, identify information security events that can lead to an information security incident and to support investigations.
ISO 27001 Annex A 8.15 Definition
The ISO 27001 standard defines ISO 27001 Annex A 8.15 as:
Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed.
ISO27001:2022 Annex A 8.15 Logging
ISO 27001 Annex A 8.15 Free Training Video
In the video ISO 27001 Logging Explained – ISO27001:2022 Annex A 8.15 I show you how to implement it and how to pass the audit.
ISO 27001 Annex A 8.15 Explainer Video
In this beginner’s guide to ISO 27001 Annex A 8.15 Logging, ISO 27001 Lead Auditor Stuart Barker and his team talk you through what it is, how to implement in and how to pass the audit. Free ISO 27001 training.
ISO 27001 Annex A 8.15 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001:2022 Annex A 8.15 Logging. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 8.15 Implementation Guidance
Identify Requirements
Identify what requirements you have for logging so that you can understand what you need to implement.
This is going to be based on the risk assessments that you have conduct and the needs of the business and your clients.
We consider that we use logs to work out what has gone wrong, to provide information on what is happening so we can react and sometimes in formal investigations.
ISO 27001 Logging and Monitoring Policy Template
You will have a topic specific policy, the ISO 27001 Logging and Monitoring Policy that sets out what you do for logging and monitoring.
Event Log Requirements
The standard sets out what the logs should consider to be included as fields and these are:
a) user IDs; b) system activities; c) dates, times and details of relevant events (e.g. log-on and log-off); d) device identity, system identifier and location; e) network addresses and protocols. The following events should be considered for logging: a) successful and rejected system access attempts; c) changes to system configuration; d) use of privileges; e) use of utility programs and applications; f) files accessed and the type of access, including deletion of important data files; g) alarms raised by the access control system; h) activation and de-activation of security systems, such as anti-virus systems and intrusion detection systems; i) creation, modification or deletion of identities; j) transactions executed by users in applications. In some cases, the applications are a service or product provided or run by a third party.
Protect Logs
The logs that you have should be protected. We want to ensure that someone could not do something and cover their tracks. This also applies to admins and privilege users. Controls should be implemented to protect them and these can be both technical, administrative or a combination.
Ensure Data Protection Laws
Logs are tricky in that they can contain information and data protected by data protection laws. It is important to ensure that what you have and what you do complies. This is includes all steps of the process and lifecycle including sharing logs with 3rd parties. It is recommended to get the advice of legal and data protection professionals in terms of your particular deployment.
Analyse Logs
We collect logs and then we analyse them. The guidance on the analysis is listed as:
a) the necessary skills for the experts performing the analysis; b) determining the procedure of log analysis; c) the required attributes of each security-related event; d) exceptions identified through the use of predetermined rules [e.g. security information and event management (SIEM) or firewall rules, and intrusion detection systems (IDSs) or malware signatures]; e) known behaviour patterns and standard network traffic compared to anomalous activity and behaviour [user and entity behaviour analytics (UEBA)]; f) results of trend or pattern analysis (e.g. as a result of using data analytics, big data techniques and specialised analysis tools); g) available threat intelligence.
Monitoring
You will implement specific monitoring activities based on need to support the logs.
- Access to protected resources – success and failed
- Outbound network connections – malicious server access
- Service Reports – service provider reports
- Physical Security – access, locations, cctv as appropriate
How to implement ISO 27001 Annex A 8.15
Implementing a robust logging framework is critical for establishing a verifiable audit trail, enabling rapid incident response, and ensuring the technical integrity of your infrastructure. By following these action-oriented steps, your organisation can successfully align with ISO 27001 Annex A 8.15 requirements while enhancing overall situational awareness.
1. Formalise a Logging Strategy and Policy
- Identify and document exactly which events must be logged, focusing on user authentication, privilege elevation, system errors, and access to sensitive data.
- Establish a clear data retention schedule that aligns with both business requirements and legal obligations like the UK GDPR.
- Result: A structured governance framework that prevents “logging blind spots” and ensures compliance with regulatory standards.
2. Provision Centralised Log Management Infrastructure
- Deploy a centralised Security Information and Event Management (SIEM) or log management solution to aggregate data from disparate servers and applications.
- Utilise secure transmission protocols, such as Syslog over TLS or encrypted API ingestors, to prevent interception during transit.
- Result: A unified repository for correlation and analysis that remains accessible even if individual source systems are compromised.
3. Restrict Log Access via Granular IAM Roles
- Enforce the Principle of Least Privilege by assigning specific Identity and Access Management (IAM) roles to users requiring access to log data.
- Mandate Multi-Factor Authentication (MFA) for all administrative access to the log management platform to mitigate the risk of account takeovers.
- Result: Prevention of unauthorised modifications or deletions of audit evidence by malicious insiders or external actors.
4. Protect Log Integrity via Cryptographic Hashing
- Implement cryptographic hashing (e.g. SHA-256) or digital signatures on log files at the point of ingestion to detect any unauthorised tampering.
- Configure write-once-read-many (WORM) storage for critical audit logs to ensure they remain immutable throughout their retention period.
- Result: Forensically sound audit trails that maintain high evidentiary value during legal or regulatory investigations.
5. Execute Continuous Log Monitoring and Alerting
- Define and provision automated alerting rules for high-risk indicators, such as multiple failed logins followed by a successful privilege escalation.
- Integrate log telemetry with an Endpoint Detection and Response (EDR) system to provide context-rich data for security analysts.
- Result: Significant reduction in Mean Time to Detect (MTTD) security incidents through real-time technical notification.
6. Revoke Access and Audit Log Management Health
- Conduct quarterly technical audits to verify that all critical systems are still successfully exporting logs to the central repository.
- Regularly review the list of authorised log administrators and revoke access for any personnel whose roles have changed or who have left the organisation.
- Result: Sustained operational effectiveness of the logging framework and the elimination of orphaned privileged accounts.
Common Log Retention Schedule
| Log Type | Retention Period | Reason |
| Firewall Logs | 12 Months | PCI-DSS / Forensic history. |
| User Access Logs | 12 Months | Investigating past employee access. |
| System Error Logs | 3 Months | Troubleshooting (low security value). |
| Anti-Virus Logs | 12 Months | Identifying trends. |
How to comply
To comply with ISO 27001 Annex A 8.15 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to:
- Understand and record the legal, regulatory and contractual requirements you have for data
- Conduct a risk assessment
- Based on the legal, regulatory, contractual requirements and the risk assessment you will implement a logging solution
- Implement a topic specific policy, the ISO 27001 Logging and Monitoring Policy
- Document and implement your processes and technical implementations for logging
- Check that the controls are working by conducting internal audits
What will an auditor check?
The audit is going to check a number of areas. Lets go through the main ones
1. That you have documentation
What this means is that you need to show that you have documented your legal, regulatory and contractual requirements for information and that you have taken this into account when building your logging solution. Where data protection laws exist that you have documented what those laws are and what those requirements are. That you have an information classification scheme and a topic specific policy for access control and that you have documented your logging taking all of this into account.
2. That you have have implemented logging appropriately
They will look at systems to seek evidence of logging. They want to see evidence of logging and the process in operation that includes the analysis of the logs and what you do as a result of that analysis. In addition the use of cloud services and the cloud providers logging and logging capabilities will be reviewed.
3. That you have conducted internal audits
The audit will want to see that you have tested the controls and evidenced that they are operating. This is usually in the form of the required internal audits. They will check the records and outputs of those internal audits.
Top 3 ISO 27001 Annex A 8.15 mistakes and how to avoid them
In my experience, the top 3 mistakes people make for ISO 27001 Annex A 8.15 logging are
1. You collect too much
Collecting too much data and logging everything is a common mistake we see. That in conjunction with storing all logs for ever. It is easy to be overwhelmed with information so it is important to work out what you are going to log and why. Then to be sure that the information is valuable, can be analysed and that analysis is actionable.
2. You don’t know your legal obligations
This is a massive mistake that we see, where people assume ISO 27001 is just information security and forget that it also checks that appropriate laws are being followed, and in particular data protection laws. Cost saving by not having a data protection expert or ignoring data protection law entirely is a common mistake we see people make when cutting corners and saving costs. Logging and in particular personal information, can get you in a lot of hot water depending how you implement it.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
Applicability of ISO 27001 Annex A 8.15 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Focuses on enabling basic audit trails for core productivity suites and shared devices. The goal is to ensure that if a breach occurs, the business can identify which user account was used and when. |
|
| Tech Startups | Essential for cloud-native product environments. Compliance requires centralizing logs from various microservices and APIs to maintain a consistent forensic trail across distributed systems. |
|
| AI Companies | Critical for protecting the intellectual property of models and massive training datasets. Logging focuses on tracking every access request to core model weights and training data. |
|
Fast Track ISO 27001 Annex A 8.15 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 8.15 (Logging), the requirement is to produce, store, and protect logs of events, exceptions, and security-related activities. Many organizations mistakenly believe they need a compliance SaaS platform to “manage” their logs, but a SaaS platform is not a log management tool, it is simply an expensive place to host your policies.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Data Ownership | Rents your standards back to you. Definitions of logging requirements are locked in a proprietary system. | Permanent Ownership: You receive the “Logging and Monitoring Policy” in Word/Excel to keep forever. | A localized Logging Standard document defining exactly which event types (success/fail) are captured. |
| Implementation | Requires new interfaces and “integrations” that often duplicate existing technical logs. | Zero Friction: Formalizes your existing AWS, Azure, or SaaS logs into an auditor-ready framework. | A completed Log Review Checklist verifying that cloud-native logs were audited by a human reviewer. |
| Cost Structure | Often scales with “data volume” or integrations, creating an expensive recurring “tax” on your growth. | One-Off Fee: A single payment covers your governance regardless of log volume or system count. | Allocating budget to long-term SIEM storage rather than paying a compliance dashboard subscription. |
| Tool Flexibility | Limited by vendor “hooks.” Switching cloud providers or security tools requires reconfiguring the SaaS platform. | 100% Agnostic: Editable procedures that adapt to any tech stack, from on-premise to multi-cloud. | Updated Logging Procedures that reflect a move from one SIEM provider to another without extra compliance fees. |
Summary: For Annex A 8.15, an auditor wants to see that you have a policy for what is logged and proof that those logs are secure. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 Annex A 8.15 FAQ
What is ISO 27001 Annex A 8.15 Logging?
Think of Annex A 8.15 as your organization’s “Digital Black Box” or high-fidelity security camera system. It is a detective control that requires you to produce, store, protect, and analyze electronic records of user and system activities. Its primary purpose is to create an unshakeable forensic trail that allows you to reconstruct events, identify the root cause of security incidents, and prove who did what (and when) during an investigation.
What specific events must be logged to comply with Annex A 8.15?
You must log any event that could significantly impact your information security risks. While the standard allows flexibility, a compliant log set typically includes:
- Access Events: Successful and failed login attempts (including remote access).
- Privileged Actions: Any activity performed by system administrators or super-users.
- Data Manipulation: Access to, modification of, or deletion of sensitive files and data.
- System Changes: Installation of software, changes to configurations, or stopping/starting services.
- Exceptions: System errors, crashes, or security alerts (e.g., antivirus triggers).
Is simply storing logs sufficient for ISO 27001 compliance?
No. Storing logs in a “digital graveyard” without review is a major non-conformity. The standard explicitly requires that logs be analyzed. You must demonstrate a process for regularly reviewing logs—either manually for small setups or using automated tools (like a SIEM) for larger environments—to identify anomalies, unauthorized access, or suspicious patterns actively.
How should we protect logs from tampering, particularly by administrators?
Log protection is critical because an attacker (or rogue insider) often tries to delete evidence of their presence. To secure your audit trail:
- Write-Once Storage: Send logs to a remote server or cloud bucket that is configured as “append-only” or immutable (WORM storage).
- Segregation of Duties: Ensure that the administrators who manage the systems cannot modify or delete the logs those systems generate.
- Hashing: Use cryptographic hashing to verify that log files have not been altered after creation.
What is the difference between Logging (8.15) and Monitoring (8.16)?
Logging is the recording of history; Monitoring is the real-time observation of that history.
- Logging (8.15): Focuses on collecting and preserving the data (the evidence) of what happened.
- Monitoring (8.16): Focuses on alerting and responding to that data in real-time to detect anomalous behavior (e.g., a sudden spike in failed logins).
You cannot have effective monitoring without reliable logging.
How long should we keep audit logs for ISO 27001?
There is no single mandated period, but 12 months is the industry standard “rule of thumb” for retention, with the most recent 3 months being immediately available for analysis. Your retention period must align with your legal obligations (e.g., GDPR, HIPAA) and your specific risk assessment.
What information must be included in each log entry?
To be useful for forensics, every log entry must answer the “Five Ws” of the event. Ensure your system configurations capture:
- Who: The User ID or Account Name responsible.
- What: The specific type of event (e.g., “File Deleted”, “Login Failed”).
- When: A reliable timestamp (synchronized via NTP).
- Where: The device identity, IP address, or physical location.
- Source: The application or system component that generated the log.
Does ISO 27001 Annex A 8.15 require a SIEM tool?
No, a Security Information and Event Management (SIEM) tool is not explicitly mandated, but it is highly recommended for medium-to-large organizations. For smaller businesses, native logging features (like Microsoft 365 Audit Logs or AWS CloudTrail) combined with a scheduled manual review process can be compliant. The key is to match the tool to the volume of your data—if you have too many logs to review manually, you effectively need a tool to assist you.
What evidence will an auditor ask for regarding Annex A 8.15?
An auditor will look for proof of both existence and process. Be prepared to show:
- Configuration Settings: Evidence that logging is actually enabled on critical systems.
- Retention Policy: A document defining how long logs are kept and why.
- Review Evidence: Tickets, reports, or meeting minutes proving that someone actually reviewed the logs and investigated anomalies.
- The “Admin Test”: They may ask, “If your IT manager deleted a file, would the log show it, and could they delete that log?”
Relate ISO 27001 Controls
Further Reading
- ISO 27001 Logging and Monitoring Policy Beginner’s Guide
- Business Continuity Incident Action Log Template
- ISO 27001 Incident and Corrective Action Log Template
