ISO 27001 A.8.15: Logging

ISO 27001 A.8.15 requires an organization to produce, store, protect, and review logs that record activities, exceptions, faults, and security events. It is a Technological control (A.8), and the action teams often get flagged on is the last one: logs are produced and stored, but nobody reviews them and there is no record that anyone ever did.

What is ISO 27001 A.8.15?

ISO 27001 A.8.15 Logging governs the creation and management of logs that record what happens across an organization's systems. Paraphrasing the intent attributed to ISO/IEC 27001:2022, Annex A: the organization produces logs that record user activities, exceptions, faults, and information security events, then keeps those logs, protects them, and analyzes them. The control covers the log lifecycle end to end; switching logging on is only the first step.

ISO 27001 A.8.15 Logging is the record-keeping control that the detection controls depend on. It covers deciding what events to capture, getting them into a place where they can be searched, keeping them from being altered or deleted, retaining them long enough to be useful, and looking at them. A.8.15 produces the logs; A.8.16 monitoring activities is the control that watches those logs for anomalies and raises alerts; and A.8.17 clock synchronization is what makes the timestamps across those logs line up so an investigation can reconstruct a sequence of events. A.8.15 is the foundation the other two build on.

How do you implement A.8.15?

Implementing ISO 27001 A.8.15 is a sequence a team can follow regardless of where the infrastructure lives, and each step produces an artifact an auditor can sample:

1. Decide what to log. Define the event categories that matter for security: authentication events (success and failure), administrative and privileged actions, authorization and role changes, configuration changes, and access to sensitive data. Each entry needs four elements to have compliance value: who (the actor), what (the action), which (the target), and when (a UTC timestamp). A log line missing any of the four is weak evidence.
2. Centralize the logs. Ship logs off the systems that generate them into one aggregation point so they can be searched, correlated, and protected in a single place. Logs that live only on the host that produced them are lost when that host is compromised, rebuilt, or scaled down.
3. Protect log integrity. Make logs tamper-resistant and restrict who can read or delete them. Write logs to append-only or immutable storage, and separate the people who administer the systems from the people who can alter the logs of those systems. If an administrator can edit the record of their own actions, the log is not evidence.
4. Set retention. Define how long logs are kept, based on investigation and compliance needs, and enforce it with a documented retention policy. A common baseline is keeping recent logs hot and searchable for 30 to 90 days, with longer-term archival for a year or more where regulation or contracts require it.
5. Review the logs. Look at the logs on a schedule and record that you did. Review is the step that turns stored data into an operating control, and in readiness work it is often the missing one. Automated review through the monitoring control handles volume, but a documented periodic human review of privileged actions and security events is what an A.8.15 assessor looks for.

Steps 2 through 4 implement meaningfully differently in cloud and on-prem environments. Decisions like where logs centralize, which network segment the log store lives on, and how log administration separates from system administration are structural, the kind of choices a security architecture defines. The two subsections below cover each environment.

In cloud environments

Cloud environments implement A.8.15 through the provider's native logging services, configured deliberately and evidenced through configuration exports:

• Provider audit logging such as AWS CloudTrail, Azure Monitor and Activity Log, or Google Cloud Logging captures control-plane and administrative activity across the account.
• Centralization into a log analytics workspace, a logging account, or a managed SIEM (for example Microsoft Sentinel) aggregates logs from every service and account into one searchable place.
• Immutable storage through object-lock or write-once buckets (S3 Object Lock, Azure immutable blob storage) protects log integrity so entries cannot be altered or deleted within the retention window.
• Access restriction through IAM limits who can read, export, or delete logs, and separates log administration from system administration.
• Retention policies on the log store and archival tiers enforce how long logs are kept and move older logs to cheaper storage without losing them.

On-prem / self-hosted

On-prem environments implement A.8.15 with the same outcomes through a self-run logging stack that produces its own evidence. The SOC 2 incident response on-prem guide covers the self-hosted detection and logging stack in depth; the shape is:

• Syslog forwarding into a central collector or a self-hosted SIEM such as Wazuh, Splunk, or an ELK stack, pulling host, application, and network device logs into one console.
• WORM or restricted storage for the log archive, where write-once media or filesystem controls prevent alteration, and the log store is hosted on a segregated management network.
• Access restriction at the SIEM and storage layer, with log review and retention handled by people who do not administer the systems being logged.
• A documented retention schedule enforced on the collector and archive, with older logs rolled to long-term storage rather than rotated away.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.15?

Evidence for ISO 27001 A.8.15 is paired: a configuration artifact showing logging is in place, plus a review or retention record showing it is maintained and looked at. Teams that export platform configuration and review records automatically, rather than assembling screenshots each audit, spend far less time here; that evidence-automation approach is what GRC engineering covers.

How does A.8.15 map to SOC 2?

ISO 27001 A.8.15 is a Full overlap with SOC 2 CC7.2. Organizations with an existing SOC 2 program can reuse the same logging evidence for the ISO 27001 certification audit with no adaptation.

CC7.2 covers monitoring system components and capturing the log data that monitoring runs on, which is the same capability A.8.15 asks for. The SOC 2 to ISO 27001 control mapping covers the full crosswalk, including how much of an existing SOC 2 program transfers.

Related controls

ISO 27001 A.8.15 Logging anchors the logging and monitoring family in the Technological theme. A.8.16 monitoring activities is the detection and alerting control that watches the logs A.8.15 produces, and A.8.17 clock synchronization keeps the timestamps across those logs consistent so an investigation can reconstruct a sequence. A.5.28 collection of evidence covers preserving logs and other records so they hold up when an incident becomes a legal matter, and A.8.5 secure authentication generates the authentication events that logging captures. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you are implementing A.8.15 as part of an effective security program and want a second set of eyes on the design, Truvo offers scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.15?

ISO 27001 A.8.15 Logging is a Technological control in Annex A of ISO/IEC 27001:2022. It requires that logs recording user activities, exceptions, faults, and information security events are produced, stored, protected, and analyzed. It covers deciding what to log, centralizing logs, protecting their integrity, setting retention, and reviewing them, and it is the record-keeping control the monitoring and evidence-collection controls depend on.

What evidence satisfies A.8.15?

A.8.15 evidence is paired: a configuration artifact plus a maintenance record. Auditors expect a logging policy defining what is logged and for how long, sample log entries showing actor, action, target, and UTC timestamp, the centralized log platform configuration, immutable or restricted storage settings, access control records for the log store, scheduled log review records, and retention configuration. The review record is what demonstrates logs are analyzed rather than only collected.

How do you implement A.8.15 in the cloud versus on-prem?

Cloud implementations use provider logging services: CloudTrail, Azure Monitor, or Cloud Logging for capture, a log analytics workspace or managed SIEM for centralization, object-lock or immutable storage for integrity, IAM for access restriction, and log store retention rules with archival tiers. On-prem implementations reach the same outcomes with syslog forwarding into a self-hosted SIEM such as Wazuh, Splunk, or ELK, WORM or append-only storage on a segregated network, and a documented retention schedule. The controls are equivalent; the evidence looks different.

What should you log for ISO 27001 A.8.15?

Log the event categories that matter for security: authentication events including successes and failures, administrative and privileged actions, authorization and role changes, configuration changes, and access to sensitive data. Each entry needs four elements to be useful: who performed the action, what the action was, which system or record it targeted, and when it happened in UTC. Operational debug logs alone do not satisfy the control.

How is A.8.15 different from A.8.16 monitoring?

A.8.15 is the logging control: it produces, stores, protects, and reviews the log records. A.8.16 monitoring activities is the detection control: it watches those logs and other signals for anomalous behavior and raises alerts. A.8.15 creates the record; A.8.16 acts on it. A.8.17 clock synchronization supports both by keeping timestamps consistent across systems so the logs can be correlated.

How does A.8.15 map to SOC 2 CC7.2?

A.8.15 maps to SOC 2 CC7.2 as a Full overlap. Both cover capturing log data from system components and analyzing it for anomalies. Evidence produced for CC7.2, including SIEM alert evidence, infrastructure monitoring dashboards, log retention records, and alerting configuration, is reusable for the ISO 27001 A.8.15 requirement without adaptation.