A.8.15 Logging: requirements and evidence

What A.8.15 Logging asks for and why it is hard to pass

If you must show an assessor that logging works, the control asks for four things: that logs recording activities, exceptions, faults and other relevant events are produced, protected, stored and analyzed. The control is not satisfied by switching on logging somewhere. It expects logs that cover the events that matter, that the logs themselves cannot be quietly altered, that they are kept for a defined period, and that someone looks at them. It also names administrator and operator activity explicitly, because people with elevated access are the most likely to need their actions traced. A.8.15 merges three controls from the 2013 edition: A.12.4.1 Event logging, A.12.4.2 Protection of log information and A.12.4.3 Administrator and operator logs. If your evidence still follows the old numbering, map each old control to the new one before the assessor does.

The usual difficulty is not the absence of logs. Most organizations have logs on many systems, but they are incomplete (a cloud account, a database or a SaaS admin console is not forwarded anywhere), unprotected (the same administrators who can act can also delete or edit the records) and never reviewed (nobody can show who looked at them, when, or what they did about a finding). Each gap fails a different part of the control, so a short inventory is the most useful first step. List every system that handles sensitive data or privileged access, record where its logs go, who can change them, how long they are kept, and which reviews are performed. Confirm the retention period and review frequency with your own risk owners and any contractual or regulatory duties, since the standard does not fix them.

The decisions that drive effort are where logs are centralized, how their integrity is protected, and who reviews them. Centralizing logs into a store that administrators cannot edit is what makes the protection and review parts credible. Open-source platforms such as Wazuh or OpenSearch can receive and analyze events, and tools like OpenBao keep audit devices that record API requests, but each product's capabilities and defaults must be confirmed in your environment before you claim them as evidence. The evidence an assessor will ask to see is the configuration showing what is logged, access records for the log store, a sample of review records and a documented response to what the reviews find.

Which systems, accounts and third parties fall under logging

A.8.15 Logging only works as far as its scope reaches, so the first decisions are which systems, identities and external services must produce logs. The organization sets this boundary from its own ISMS scope and risk assessment, then checks each component against what an assessor will ask to see.

In-scope systems and cloud accounts

Start from the ISMS scope and list every production, staging and management system that stores or processes in-scope information, then every cloud account, subscription or project that hosts it. Confirm that each one emits events for authentication, configuration changes, data access and errors, and that the events leave the system. A common gap is a cloud account that was provisioned outside the normal process and never had logging enabled.

Identity providers and directories

Sign-in events, failed attempts, MFA changes, group membership edits and account lockouts usually originate in the identity provider or directory, not in the applications that use it. Confirm that these events are retained and reach the central log store, since an investigation of a compromised account often starts there. Ask the identity team which administrative actions in the directory are logged and which are not.

Privileged and service accounts

Administrator and operator activity is a distinct logging requirement, so every privileged account, break-glass account and service account with elevated rights needs its actions recorded with the account name, source and target. Service accounts are often excluded because they are not people, which leaves automated changes unattributed. Confirm that shared or generic administrative accounts are either removed or tied to a named individual in the logs.

SaaS applications holding ISMS data

Each SaaS application that stores customer data, source code, financial records or access credentials belongs in the scope review, even when a vendor operates it. Check which audit logs the vendor provides, how long they are kept, whether they can be exported to the organization's own store, and whether administrator actions in the admin console are included. Where an export is not available, record that gap and the compensating review in the risk treatment documentation.

Third-party and hosted services

Managed databases, payment gateways, hosted message queues and outsourced development environments can produce security-relevant events that the organization never sees by default. The contract or service agreement should state what logs the provider keeps, how long, and how the organization can obtain them after an incident. Treat the absence of a log feed as a documented risk, not as a silent exclusion from scope.

Scope from the ISMS, not from a crosswalk

NIST's crosswalk relates A.8.15 to seven AU family controls in SP 800-53, but NIST cautions that mapped controls are not always equivalent. Use the crosswalk to find related requirements to read, then set the logging scope from the organization's own asset inventory and risk assessment. An assessor will test whether the scope reflects the actual ISMS boundary, so document how each system was included or excluded and why.

How an assessor tests A.8.15 logging

This table compares each step an assessor takes when testing A.8.15, the evidence requested at that step, and the findings that most often appear. Use it to prepare log sources, protection settings and review records before an audit, since each row maps to a question the assessor is likely to ask. The main takeaway is that an assessor checks whether logging works in practice across every relevant system, not only whether a logging tool exists.

Test area	Evidence requested	Common findings
Sampling of systems and log sources	Inventory of in-scope systems and log sources, with the sample the assessor selected and logging configuration for each	Logging disabled or missing on one host, container or cloud account that is in scope
Event types covering activities, exceptions and faults	Logging configuration showing which user activities, errors, faults and security events are captured, mapped to the risk assessment	Authentication events logged but application errors or failed transactions not captured
Administrator and operator activity	Logs of privileged sessions, configuration changes and actions by system operators, with a sample traced back to a change record	Administrator actions performed through shared accounts with no attributable log entries
Log protection and integrity	Access controls on log stores, separation of duties for log administrators, and evidence that logs cannot be edited or deleted by the people they record	Administrators can edit or delete local log files, with no forwarding to a protected store
Retention	Retention settings and the stated retention period in the log policy, with proof that older logs are available when requested	Retention period not defined, or logs rotated out before the period the organization set
Review and analysis	Review records, alert triage tickets or meeting notes showing who reviewed logs, what they found and what was done	Logs collected for months with no record of anyone reviewing them or acting on findings
Time consistency	Evidence that system clocks use an approved time source so events line up across systems	Timestamps in different systems that cannot be correlated because clocks drift

Evidence that passes A.8.15 and how to keep it current

An assessor testing A.8.15 Logging looks for a written logging standard, proof that the right events are captured from the right sources, and proof that the logs themselves are protected and reviewed. The cards below list the artifacts that show this, along with the routine checks that keep each one accurate between certification audits.

Logging standard or procedure

This document states which systems must produce logs, which event types are required, how long logs are kept, who may read or change them, and who reviews them. An assessor compares it against what the systems actually do, so every statement should name a system owner and a check. Review it at least once a year and whenever a new system or log destination is added, and record the approval date and version. Ask the implementation partner to draft it from your existing practice, then have the control owner sign it.

Log source inventory with enabled event types

The inventory lists every source sending logs, such as servers, databases, identity providers, cloud accounts, network devices and self-hosted applications, together with the event categories enabled on each. Gaps between this list and the asset register are the first thing an assessor will question. Export the inventory on a schedule and diff it against the previous export, so new sources and silently disabled event types are caught and recorded as changes.

Configuration exports showing audit settings

Exported configuration proves that audit logging is switched on and set as documented, rather than relying on memory or screenshots. For self-hosted platforms this usually means the audit configuration files or settings output, such as the audit log path in Nextcloud's admin_audit app or the audit devices enabled on OpenBao. Store exports under version control so that every change has an author, a date and a reason. Compare them against the logging standard during each review.

Administrator and operator activity records

Records of privileged actions show who changed what on the systems that run the controls, including logins, role changes, configuration edits and disabled logging itself. Assessors usually ask for a sample of these entries and then trace each one to an approved change or access request. Keep privileged activity in a separate, restricted log stream so that administrators cannot quietly edit their own trail, and retain samples from each review period to show the trail was complete.

Log storage protection and retention settings

This evidence covers who can read, modify or delete logs, whether logs are forwarded to a separate store, whether integrity is checked, and how long each log class is kept. Export the access control list for the log store, the retention policy and any hashing or write-once settings. An assessor will test whether an administrator could erase their own activity. Recheck these settings at each review, since a changed retention job or a new admin group is a common reason findings appear between audits.

Review and alert handling records

Proof that someone looked at the logs matters as much as proof that they exist. Keep dated review records, alert triage tickets, rule tuning decisions and escalations to incident handling. Monitoring evidence under A.8.16 and time evidence under A.8.17, which keeps timestamps comparable across systems, both depend on this trail. Where an event leads to an investigation, collecting and preserving the evidence follows A.5.28 Collection of evidence, so keep chain-of-custody notes with the case.

How to implement logging in a sequence an auditor can follow

Each step below produces a named artifact that an assessor can read, so the chain runs from the logging standard through to tested, recorded evidence that logging works as designed.

Define the logging standard and event types
The organization, usually the security lead with system owners, writes a logging standard that lists which event types must be recorded, such as authentication, privilege use, configuration changes, security exceptions and system faults. It also states the fields each event must carry, including time, identity and source, and who approves the standard. Done means an approved logging standard exists and is linked from the Statement of Applicability entry for A.8.15.
Inventory every log source
Build a register of systems, applications, cloud accounts, network devices and identity services that must produce logs under the standard, with the owner of each source. Compare the register against the asset inventory so that no in-scope system is missing. Done means a log source register exists, each entry names an owner, and gaps have tickets with dates agreed by the owner.
Enable logging on systems and cloud accounts
System owners turn on the event types defined in step one on each source, including the administrator and operator activity that the 2013 control set treated as a separate control. Enable audit features in cloud accounts and admin consoles, and confirm that privileged sessions and changes to logging settings are themselves recorded. Done means each source has a saved configuration showing the enabled event types, and a test event appears in the next step's collector.
Centralize and protect logs
Forward logs from every source to a central store that is separate from the systems being logged, so that an attacker or administrator cannot quietly edit local records. Limit read and write access to the log store to named roles, and apply integrity controls such as write-once storage or hashing of log files. Done means a access list for the log store exists, and an integrity check has been run and recorded on a sample of logs.
Set retention periods
The organization sets how long each log category is kept, based on its legal, contractual and investigation needs, and documents who may extend or shorten retention. The retention rule is applied in the store, and deletion at the end of retention is itself logged. Done means a retention schedule is approved and the store's settings match it, with a screenshot or configuration export as proof.
Connect logs to review and alerting
Route logs into a review process with defined alert rules, a named reviewer or on-call rota, and a route for escalating findings to incident management. Keep a record of each review, including the logs examined, the date and the outcome, so that the review itself is evidence. Done means a review procedure, an alert rule list and a sample of completed review records are on file.
Test the chain and record the evidence
Test that known events, such as a test login failure or a privileged change made in a sandbox, reach the store, cannot be altered by ordinary administrators, and trigger the expected review. Record the test plan, the results and any fixes, then repeat tests on a schedule and after major changes. Done means a signed test report and an evidence folder exist, and an independent auditor can sample from them. Confirm with the certification body which evidence format it accepts.

Self-hosted open-source tools that produce and analyze logs

Each tool below produces a different slice of the records A.8.15 Logging asks for: application audit trails, privileged secret-access records, rule-matched findings and host-level alerts. Together they cover production, protection and analysis, but none of them makes an organization compliant on its own.

Nextcloud admin_audit logging

The admin_audit app records administrative and security-relevant events in Nextcloud and writes them to audit.log in the data directory, or to a path you set with logfile_audit. For A.8.15 this is the application-side event record, so confirm which events it captures in your version, where the file is stored, and who can read or alter it. Ship the file to a location administrators cannot edit, and document the retention period you apply to it. Licensed under AGPL-3.0-only.

OpenBao audit devices

OpenBao audit devices write a detailed JSON record of every API request and response, including errors, which makes them useful evidence for privileged secret and key access. Most sensitive values are hashed with HMAC-SHA256 rather than stored in plain text, so the log shows what happened without exposing the secret. Confirm which audit device types you enable, that at least one device is always active, and how log files are rotated and protected. Licensed under MPL-2.0.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts go to channels such as Slack or email. The correlation engine links findings across log types in a correlation graph, which helps analysts follow an event across systems. Confirm your rule set, alert routing and review cadence, since A.8.15 expects logs to be analyzed, not only stored. Licensed under Apache-2.0.

Wazuh decoding and alerting

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching alerts are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for review in the dashboard, and each alert is mapped to MITRE ATT&CK. For A.8.15, check which log sources are actually collected, whether agents keep reporting, and how decoder gaps are handled. Licensed under GPL-2.0-only.

What meeting A.8.15 costs in money and effort

This table lists the cost components of meeting A.8.15 Logging, who is paid for each, whether it is one-time or recurring, what pushes it up or down, and how to keep it contained. No price or duration is given because none was supplied, so use the right-hand column to build a written scope and quote. The main takeaway is that licence fees are often the smallest line, while engineering, storage and evidence upkeep recur for as long as the ISMS runs.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Tooling and licences	Recurring if commercial, otherwise none	The named open-source tools (Wazuh, OpenSearch, Nextcloud, OpenBao) carry no licence fee, but commercial SIEM or GRC add-ons do	Confirm each tool's licence terms in writing and avoid paid tiers unless a requirement needs them
Hosting and storage for log infrastructure	Recurring	Log volume, number of hosts and cloud services, index replicas and whether logs are stored in multiple regions	Log only events that matter for the scope, filter noisy sources at collection and size indexes from measured volume
Engineering time to enable and centralize logging	One-time, with later changes	Number of systems, mix of OS and applications, and whether agents must be deployed to each host	Standardize collection with templates and configuration as code so each new system follows an existing pattern
Clock synchronization and log integrity setup	One-time, with periodic checks	Number of time sources and whether logs are hashed, signed or written to write-once storage	Use the time and protection settings already defined for the environment and test them once during setup
Retention and capacity management	Recurring	Retention periods set by the organization's policy and legal obligations, plus growth in event volume	Set retention by log category, move older data to cheaper storage and review capacity on a fixed schedule
Evidence upkeep and rule tuning	Recurring	Frequency of log reviews, number of detection rules, false-positive rate and changes to the environment	Assign named owners, keep review records in one place and retire rules that produce no useful findings
External testing or review	Recurring or per engagement	Scope of testing, whether logs are tested for tampering or gaps in coverage, and the depth of the review	Agree the test scope in writing and combine logging checks with planned security testing
Auditor sampling time	Recurring, once per audit cycle	Number of systems in the ISMS scope, sample sizes the auditor chooses and how quickly evidence can be produced	Ask the certification body how it samples logs and prepare a repeatable evidence pack before the audit

Who does what: your team, an implementation partner and the auditor

Your organization owns A.8.15. That means it decides what must be logged, sets the logging policy, approves which systems are log sources, and reviews the output. No outside party can accept these decisions on your behalf, and an assessor will ask who made them and when. The people who own the control should be able to explain why each log source exists and who reads its output.

Logging policy: Set the rules for which events, exceptions, faults and administrator or operator actions are recorded, and for how long logs are kept.
Log source decisions: Approve each system, application, cloud service and network device that feeds logs, and record the reasons for any exclusions.
Review and follow-up: Assign people to review logs or alerts, define what triggers escalation, and keep records of what was found and done.
Sign-off: Approve the logging configuration and any change to retention or access to logs through your normal change process.
Retention and access: Decide who may read, export or delete logs, and confirm that administrators cannot silently alter their own activity records.

Confirm that a named owner and a documented review cadence exist before any vendor work starts, because assessors test the review as much as the collection.

Where logging programs usually fall short

Most logging gaps are not missing tools. They are missing decisions: which sources are in scope, who can change the logs, how long they are kept, and whether anyone reads them. Each card below names one gap an assessor is likely to find under A.8.15 Logging, with the fix that closes it.

Cloud control planes left out

Servers and applications often send logs to a central store while the cloud control plane, identity provider and SaaS administration consoles write nothing that anyone collects. Configuration changes, new access keys and policy edits then leave no trace. Inventory every place an administrator can act, and confirm that each one has its audit trail enabled and forwarded to the same store as host logs. Ask the cloud provider which control-plane events are logged by default and which need to be switched on.

Administrator actions not captured

Privileged activity is the activity an assessor most wants to see, yet it is often performed through shared accounts, sudo sessions or break-glass tooling that records little. Check that each privileged account is individually identifiable, that elevation events are logged, and that commands run by administrators reach the central store. Where a tool such as OpenBao writes an audit device, confirm that the audit log is enabled before production use, not after the first incident.

Logs writable by the people they record

If administrators can edit or delete log files on the system they administer, the record cannot be relied on after an incident. Protection of log information needs separation: forward logs off the host in near real time, restrict delete rights on the stored copy, and record access to the log store itself. Test this by attempting to alter a log entry from an ordinary administrator account and confirming the attempt fails or is itself recorded.

No documented retention period

Many teams keep logs for whatever period the storage happens to allow, with no written rule and no record of what was deleted. An assessor will ask how long each log type is kept, why that period was chosen, and who approved it. Write a retention rule per source that reflects legal and contractual needs, configure the store to enforce it, and keep the rotation or deletion records so the rule can be shown to work.

Logs collected but never reviewed

A logging pipeline that nobody reads produces evidence of collection, not evidence of analysis. A.8.15 expects logs to be analyzed, so define what is reviewed, by whom and how often, and which events raise alerts. Tools such as Wazuh and OpenSearch Security Analytics can match events against rules and record findings, but someone must own the triage queue and close each finding with a documented outcome.

Clocks that disagree across systems

When hosts, firewalls and applications run on different clock settings, events from one incident appear in the wrong order and cannot be correlated. This undermines both investigation and any evidence presented to an assessor. Point every source to the same approved time reference, check for drift on a schedule, and record the time source configured on each system. The companion control, A.8.17 Clock synchronization, covers the details.

Questions buyers ask about A.8.15 logging

What does it cost to get A.8.15 logging in place?

The cost depends on how many systems produce logs, how much analysis you need, and how much of the work your own engineers can absorb. Most of the spend falls into four parts: designing the logging scope, configuring sources and forwarding, building storage and retention, and writing the procedures and evidence that an assessor will read. Software licenses are only one line item, because open-source platforms such as Wazuh or OpenSearch carry no license fee for the core product, though you still pay for infrastructure, storage and staff time. Ask any partner for a fixed-scope quote that lists the log sources, the retention period and the deliverables, since those three items drive the price more than anything else.

How long does it take to implement logging for ISO 27001?

The timeline is set by the number of log sources, whether logging already exists in some form, and how quickly decisions about retention and access are made. A single application with working audit logs can be brought into scope far faster than a hybrid estate with many servers, cloud accounts and network devices. Internal approvals, change windows for production systems and the time needed to test that logs arrive intact also add weeks. Agree a written schedule with your implementation partner before work starts, and confirm which milestones depend on your own teams.

What must our organization provide before logging work starts?

The organization owns the control, so it must supply the decisions and access that no partner can make on its behalf. You need a defined list of systems in scope, a logging policy that states what must be recorded and for how long, named owners for each log source, and administrative access to the systems being configured. You also need a storage location that meets your data residency and protection rules, and someone accountable for reviewing alerts after go-live. Without these inputs, a partner can install software, but cannot show an assessor that the control operates.

Can a small team run A.8.15 logging on its own?

A small team can run it if the scope is narrow and the tooling is simple, but the work is less about the software and more about discipline. Someone must review log exceptions, keep the retention settings correct, protect the log store from tampering and produce evidence on a schedule. Many small organizations start with the systems that hold customer data and administrator actions, then extend coverage as capacity allows. Be honest about the hours this takes each month, because an unreviewed log store fails the control even when every technical setting is correct.

Which parts of A.8.15 logging are worth outsourcing?

Outsourcing usually makes sense for the design, the initial deployment and the hardening of the log pipeline, because these tasks need specialist knowledge and are finished once. Keep ownership of the policy, the risk decisions about what to log, and the routine review of log findings, since those must reflect your own business and remain traceable to your staff. Ongoing support, upgrades and continuous monitoring can also be bought as a retainer if your team lacks capacity. Whatever you outsource, the organization remains responsible for the control and must be able to explain it to an assessor.

Do open-source logging tools satisfy the A.8.15 control?

No tool satisfies the control by itself, because A.8.15 concerns the whole process of producing, protecting and analyzing logs. Open-source platforms can cover much of that process: Nextcloud's admin_audit app writes audit events to a file, OpenBao's audit devices record API requests with sensitive values hashed, and Wazuh decodes events and writes alerts to alerts.log and alerts.json. The evidence still has to come from your configuration, retention settings, access restrictions and review records. Confirm each tool's capabilities for your version and environment, since features and log formats change between releases.

How do we check that a partner's logging work will hold up in an audit?

Ask the partner to show evidence that matches each claim, not just a description of the tools. Look for a written logging scope, a list of sources with their owners, retention settings with the reasons behind them, samples of protected and tamper-evident log storage, and records of reviews and alert handling. Confirm that the partner prepares evidence but does not issue reports or certificates, since only an independent auditor or certification body does that. Your own internal audit should test the same evidence before the certification body arrives.

How DeployOpen scopes, implements and prepares logging evidence

DeployOpen plans and implements self-hosted open-source logging and audit components inside your own infrastructure, then documents the configuration and evidence an assessor will ask for. Your organization owns the logging policy and the control, and an independent auditor or certification body decides whether the control meets the standard.

How we scope

Engagements are fixed-scope, with systems in scope, log sources and deliverables agreed in writing before work starts.
We list which activity, exception, fault and administrator logs must be produced for each system covered by the ISMS.
We agree retention periods, storage locations and who may read logs, and record these decisions as scope items for your review.
Ongoing support, upgrades and continuous testing of the logging stack are available as a retainer after handover.

How we build

We configure audit and event logging on the platforms in scope, such as Nextcloud admin_audit and OpenBao audit devices, within your environment.
We route logs to a self-hosted store and set access controls so that log content and retention settings are protected from routine change.
We configure detection content such as OpenSearch Security Analytics detectors or Wazuh rules where your scope calls for log analysis.
We test that expected events are produced, stored and reviewed, and we record the results against the agreed scope.

How we hand over

We document the log sources, formats, storage paths, retention settings and access roles so your team can explain them to an assessor.
We provide a mapping from each configured log source to the A.8.15 requirement it supports, with the configuration files and test records behind it.
We deliver runbooks for reviewing logs, handling alerts and restoring logs from backup, owned by your staff.
We do not issue audit reports or certificates. Your independent auditor or certification body assesses the evidence we prepare.

How we support

Before an assessment, we can walk your team through the evidence set and identify gaps in the agreed scope.
Under a retainer, we maintain logging components, apply upgrades and review configuration changes against the documented baseline.
We can repeat log integrity and access tests after changes, so evidence stays current between audit cycles.
Confirm with us during scoping which parts of log review and retention remain with your own security operations team.