ISO 27001 Control 8.15: Logging Requirements, Implementation, and Audit Guide

When an incident happens and the logs are missing, incomplete, or overwritten, the investigation stops before it starts. You cannot determine scope, identify root cause, or confirm whether data was exfiltrated. Every hour spent reconstructing what happened is an hour the attacker had that you cannot account for.

What 8.15 Requires

ISO 27001 8.15 is a technological control under the ISO/IEC 27001:2022 standard that requires organizations to generate, protect, and analyze event logs recording user activities, exceptions, faults, and security events across their information systems. It establishes the forensic foundation needed to detect unauthorized access, investigate incidents, and demonstrate compliance during audits.

The control has three core obligations. First, you must generate event logs across systems that capture who did what, when, and from where. This includes authentication attempts, privilege escalation, configuration changes, data access events, and system faults. Second, you must protect those logs from tampering, unauthorized access, and deletion. This protection must extend to privileged insiders who might otherwise modify their own audit trails. Third, you must actively analyze logs to detect anomalies, support forensic investigations, and monitor system health.

The scope is broader than many organizations initially assume. 8.15 applies to every system that processes, stores, or transmits information within your ISMS scope, including cloud services, SaaS platforms, network infrastructure, and endpoint devices. It is not limited to servers and firewalls.

Without this control in place, you have no forensic trail when something goes wrong. You cannot detect lateral movement across systems, you cannot prove to auditors that security events were monitored, and you cannot determine whether a compromised account accessed sensitive data. Logging is the control that makes every other detection and response capability possible.

Why 8.15 Matters

Consider this scenario: your security team discovers that an unauthorized user accessed a production database containing customer records. The access occurred three weeks ago. When the team pulls logs to investigate, they find that the database server was only logging authentication failures, not successful logins. The application logs were stored locally and were overwritten after seven days. Network flow logs exist but lack timestamps synchronized to the same time source as the application layer.

The investigation stalls. You know unauthorized access occurred, but you cannot determine which records were accessed, whether data was exfiltrated, or how the attacker gained initial access. Regulators demand evidence of the scope, and your organization cannot provide it. Maintaining ISO 27001 compliance depends on demonstrating that controls like 8.15 are not just documented but operational. Customers must be notified under a worst-case assumption because you lack the data to narrow the impact. What started as a containable incident becomes an unquantifiable breach with full notification obligations, reputational damage, and potential regulatory fines.

This is not a hypothetical edge case. Mandiant’s M-Trends 2026 report reports that global median dwell time rose to 14 days in 2025, meaning attackers typically have nearly two weeks inside a network before detection. When organizations rely on external notifications rather than internal detection, that window stretches to 26 days or more. Without comprehensive logging, detection might never happen at all.

The financial consequences compound quickly. Investigations without usable logs require manual forensic reconstruction, which is both slower and more expensive. Regulatory bodies treat missing logs as evidence of inadequate controls, not just missing documentation. In sectors governed by DORA, NIS2, or similar frameworks, the inability to produce log evidence during an incident can trigger enforcement actions independent of the breach itself.

What attackers exploit

Attackers specifically target logging gaps to extend their access and cover their tracks:

• Disabled or insufficient audit trails on critical systems — production databases, identity providers, and cloud management consoles that generate no log data for successful operations
• Log storage on the same systems being monitored — once an attacker compromises a host, they delete or modify local logs to erase evidence of their activity
• No centralized log collection — logs scattered across individual hosts make correlation impossible and create blind spots when any single system is compromised
• Missing timestamps or unsynchronized clocks — without consistent time sources, correlating events across systems becomes guesswork, and forensic timelines fall apart
• Privileged users with ability to modify their own audit records — administrators who can delete logs create an accountability gap that both insiders and attackers exploit
• No automated alerting — logs exist but sit unreviewed, meaning a breach that generates detectable patterns goes unnoticed for weeks or months
• Retention periods too short to cover attacker dwell time — if your logs only go back seven days but an attacker has been inside for two weeks, you have already lost the evidence that matters most
• Inconsistent log formats across systems — when each application uses its own schema, automated correlation tools cannot connect related events, and analysts spend hours normalizing data instead of investigating threats

How to Implement 8.15

Implementation requires both internal controls and visibility into how your vendors handle logging. The gap between having a logging policy and having effective logging often comes down to operational discipline. Many organizations deploy a SIEM and consider logging “done,” but the real work is in defining what to capture, protecting log integrity, and building the review processes that turn raw data into security intelligence.

The steps below follow the implementation guidance in ISO 27002:2022 for Control 8.15, supplemented with operational practices from NIST SP 800-92 (Guide to Computer Security Log Management).

For your organization (first-party)

Start with a logging policy that defines which systems generate logs, which events are captured, how long logs are retained, and who can access them. This policy should be a living document tied to your risk assessment, not a compliance checkbox. Review it whenever your infrastructure changes, when new systems are deployed, or when a post-incident review reveals gaps in your log coverage. If you are building your broader ISMS, an ISO 27001 implementation checklist can help ensure logging fits into the larger control environment.

1. Define what to log. At minimum, capture authentication events (successes and failures), privilege escalation, configuration changes, data access to sensitive systems, security tool alerts, and system faults. The goal is not to log everything but to log what you would need to reconstruct an incident. Start by mapping your critical assets, then work backward to identify which events on those systems would matter during an investigation.
2. Standardize log fields. Every log entry should include a user ID, timestamp (in UTC), event type, source IP address, and device or system identifier. Inconsistent formats across systems make automated analysis unreliable.
3. Synchronize time sources. Deploy NTP across all systems and verify synchronization regularly. Without consistent timestamps, correlating events across your application layer, network infrastructure, and identity provider is impossible.
4. Centralize log collection. Forward logs to a SIEM or dedicated log management platform. Centralizing logs removes them from the systems being monitored, protecting them from an attacker who compromises an individual host.
5. Protect log integrity. Use append-only storage, cryptographic hashing, and segregation of duties. No single administrator should have the ability to both perform actions on a system and delete the audit records of those actions.
6. Implement monitoring and alerting. Define detection rules for high-risk patterns: multiple failed authentication attempts, privilege escalation outside change windows, access to sensitive data from unusual locations, and disabled security controls.
7. Schedule regular log reviews. Daily review for critical systems, weekly for standard. Log collection without analysis is security theater. Assign specific ownership for log review activities, and document findings even when nothing anomalous is detected. Auditors look for evidence of consistent review, not just evidence of alerts.
8. Enforce retention periods. Align retention with legal, regulatory, and forensic requirements. Given that attacker dwell times can stretch to weeks, retention periods under 90 days often leave you without the evidence you need most. Balance retention against storage costs and privacy obligations. Some jurisdictions require you to delete certain log data within defined windows, so your retention schedule must account for both minimum and maximum holding periods.

Common mistakes to avoid:

• Logging everything without a strategy, so high-volume noise drowns out the signals that matter
• Storing logs on the same system being monitored, giving attackers a single point of deletion
• Setting retention periods without considering attacker dwell time
• Giving system administrators delete access to their own audit trails
• Treating log collection as “done” without building regular analysis into operations

For your vendors (third-party assessment)

Your vendors’ logging practices directly affect your risk posture. Evaluating these controls is a core part of meeting ISO 27001 third-party risk requirements. Verizon’s 2025 DBIR found that third-party involvement in breaches doubled to 30%, making vendor logging controls a critical assessment area.

Questions to ask:

• What events do you log across the systems that process our data?
• How long are logs retained, and what drives your retention policy?
• Who has access to modify or delete logs? Is there segregation of duties?
• Do you use centralized log management?
• How do you monitor logs for security events, and what is your alerting threshold?

Evidence to request:

• Logging and monitoring policy
• Sample log retention schedule
• SIEM dashboard screenshots or log management platform configuration
• SOC 2 Type II report (specifically CC7.2 and CC7.3)

Red flags:

• “We log everything” with no specifics about event types or retention
• No defined retention policy or one that does not reference regulatory requirements
• Administrative users who can delete audit trails for systems they manage
• No evidence of log review or active monitoring

Verification: Structured vendor risk assessments should include logging controls as a dedicated assessment area. Request a sample anonymized log entry to confirm field completeness. Ask for evidence of a past incident investigation that relied on log data. A vendor that has never used their logs for an investigation likely is not reviewing them. During contract negotiations, include logging requirements as contractual obligations with the right to audit log practices during security assessments. UpGuard’s risk assessment tools can streamline this evaluation across your vendor portfolio.

Audit Evidence for 8.15

Auditors verifying 8.15 will request specific artifacts demonstrating that logging is not just configured but operational. The distinction matters: having a SIEM deployed is not the same as demonstrating that logs are reviewed, alerts are investigated, and the system covers your critical assets. Prepare these artifacts before the audit engagement begins, and verify that each one reflects current practice rather than outdated documentation. For a broader view of what to expect, see this guide to ISO 27001 audit preparation.

Cross-Framework Mapping

If your organization maps controls across multiple frameworks, 8.15 aligns closely with audit and monitoring controls in other standards. The NIST 800-53 AU family covers the same ground across seven controls, while SOC 2 and CIS Controls address overlapping requirements through different lenses. This mapping reduces duplicate implementation effort and simplifies multi-framework audits.

Related ISO 27001 Controls

8.15 does not operate in isolation. These controls form the logging and monitoring ecosystem within ISO 27001.

Together, 8.15 and 8.16 form the detect-and-respond capability that underpins your entire ISMS. Without logging, monitoring has nothing to analyze. Without monitoring, logs are an archive that nobody reads. When planning your implementation, address 8.15 and 8.17 (clock synchronization) first, as they are prerequisites for every downstream control that depends on accurate, centralized log data.

Frequently Asked Questions

What is ISO 27001 8.15?

ISO 27001 8.15 is a technological control requiring organizations to generate, protect, and analyze event logs that record user activities, exceptions, faults, and security events. It establishes the forensic trail needed to detect unauthorized access, investigate incidents, and demonstrate compliance during audits.

What happens if 8.15 is not implemented?

Without proper logging, organizations lose the ability to detect breaches, investigate incidents, or determine the scope of a compromise. Auditors will flag the gap as a major nonconformity, and regulators may impose penalties if the organization cannot produce evidence of security event monitoring.

How do you audit 8.15?

Auditors verify that a logging policy exists, that logs are being generated from critical systems with required fields, that logs are protected from tampering, and that there is evidence of regular log review. They typically request sample log entries, retention schedules, and records of past incident investigations that relied on log data.

How UpGuard Helps

Logging gaps in your vendor ecosystem are blind spots you cannot afford. When a vendor lacks proper logging controls, their incident becomes your investigation without evidence. UpGuard’s User Risk product continuously monitors for logging and security control weaknesses across your third-party landscape, surfacing vendors that fall short of the standards 8.15 demands before a breach forces you to find out the hard way. Explore User Risk to close the gap between your logging policy and your vendor reality.