ISO 27001 Logging: The Complete 2026 Requirements Guide

ISO 27001 logging is governed by three Annex A controls that most implementation projects treat as a single line item: A.8.15 Logging, A.8.16 Monitoring activities and A.8.17 Clock synchronisation. That shortcut is where the audit findings come from. The three controls ask for different things, one of them has no predecessor in the 2013 edition, and the standard never tells you how long to keep a log.

This guide covers what each ISO 27001 logging control requires, which events your logs have to support, how to answer the retention question defensibly, and the evidence a certification auditor will actually ask to see.

The three ISO 27001 logging controls in Annex A

ISO/IEC 27001:2022 carries 93 Annex A controls grouped into four themes — 37 organizational, 8 people, 14 physical and 34 technological. All three logging controls sit in the technological theme, next to each other, which is why they get merged in people’s heads.

Control	Title	2013 origin	What it asks for
A.8.15	Logging	Replaces A.12.4.1, A.12.4.2 and A.12.4.3	Logs are produced, stored, protected and analysed
A.8.16	Monitoring activities	New in 2022 — no predecessor control	Networks, systems and applications are watched for anomalous behaviour, and something happens when anomalies appear
A.8.17	Clock synchronisation	Replaces A.12.4.4	Clocks across in-scope systems are synchronised to an approved reference time source

A.8.16 is one of the eleven controls introduced in the 2022 edition, alongside threat intelligence (A.5.7), configuration management (A.8.9) and secure coding (A.8.28). That matters practically: organisations that transitioned from the 2013 edition have a 2013 document behind almost every other control, and nothing at all behind A.8.16. It is the Annex A line most likely to be marked applicable in the Statement of Applicability with no procedure, no owner and no evidence underneath it.

ISO 27001 logging under A.8.15: produce, store, protect, analyse

A.8.15 is built on four verbs, and an ISO 27001 logging programme has to satisfy all four of them. Logs recording activities, exceptions, faults and other relevant events must be produced, stored, protected and analysed. Most organisations do the first two well, because that is what their tooling does by default. The third and fourth are where auditors spend their time.

Produce means the log entry contains enough to reconstruct the event — identity, what was done, when, from where, and over which network path. Store means the entry survives long enough to be useful. Protect means nobody, including an administrator, can quietly delete or edit the record of what they did. Analyse means somebody looks.

That last verb is the one that fails, and it is the single biggest gap in most ISO 27001 logging implementations. A SIEM licence is not analysis. If nobody can show the auditor an output — a triaged alert, a weekly review record, a ticket raised from a log event — then the control is implemented at three verbs out of four, and the finding writes itself.

Worth noting: a logging policy is not on the mandatory-documents list in ISO 27001:2022. Nothing in clauses 4 to 10 demands one. But A.8.15 is close to impossible to exclude in the Statement of Applicability for any scope containing a server, so the document gets written anyway. See our guide to the mandatory documents ISO 27001 actually requires for where the line falls.

ISO 27001 logging is not the same as clause 9.1 monitoring

This is the most common confusion in the whole topic, and it costs people time in Stage 2. Clause 9.1 — Monitoring, measurement, analysis and evaluation — is about the management system. It asks whether your ISMS is performing and whether your controls are effective, and it is satisfied with metrics, review minutes and trend data. Our guide to ISO 27001 monitoring and measurement covers that side in full.

A.8.16 is about systems. It asks whether anomalous technical behaviour on your networks, hosts and applications gets detected and acted on. A perfect clause 9.1 metrics pack proves nothing about your ISO 27001 logging controls, and a flawless SIEM proves nothing about clause 9.1. They are assessed separately, by different evidence, and an ISO 27001 logging project that only builds one of them is half finished.

What to log: the activities your logs must support

ISO 27001 does not publish a log source list. It expects you to derive one from your risk assessment and your scope, which is correct but unhelpful when you are staring at a blank policy template. A usable starting point is the US federal logging baseline in OMB Memorandum M-26-14, issued 22 May 2026, which defines logging by the activities the logs must enable rather than by the systems they come from.

It is worth saying plainly: M-26-14 binds US federal agencies, not you. No certification body will fail you against it. But it is free, current, and specific in exactly the way the standard is not, so it makes a defensible basis for your own ISO 27001 logging scope.

Your logs must let you determine…	Typical source
The identity used to perform an operation	Identity provider, directory, application auth logs
Source and destination addresses, protocols, ports and session attributes	Firewalls, boundary routers, proxies, VPN concentrators
Objects, resources and data accessed, modified or destroyed	File and database audit logs, object storage access logs
Actions that change privilege levels	Directory, PAM tooling, cloud IAM
Changes to IT, OT and IoT estate — endpoints added, removed or modified	Asset management, MDM, configuration management
Suspicious activity flagged by security tooling	IDS/IPS, EDR, secure web gateway, email security
Known indicators of compromise	SIEM correlation against threat intelligence feeds
Anomalous system or user activity	SIEM, behavioural analytics
Quantity and types of data affected during an incident	Data access logs, DLP, classification tooling
Attack vectors, including initial access and lateral movement	Endpoint, authentication and network flow logs together
Automated alerts for all of the above	SIEM alerting and on-call routing

Read that list as an ISO 27001 logging coverage test rather than a shopping list. For each row, ask which system in your scope answers it and whether the answer survives a 3am incident. The rows you cannot answer are your gaps, and they are far more useful in a risk treatment plan than “enable logging on all servers”.

How long ISO 27001 logging records must be kept

ISO/IEC 27001:2022 specifies no log retention period. Not in A.8.15, not in clause 7.5, nowhere. Anyone who tells you the standard requires twelve months is quoting a different framework. What the standard expects is that you set a period, justify it against risk and legal obligation, and then honour it.

The useful external benchmark here changed recently, and most ISO 27001 logging guidance online has not caught up. OMB M-26-14 rescinded the 2021 memorandum M-21-31 with immediate effect and replaced its 12-months-hot / 18-months-cold baseline with a shorter, risk-based pair of objectives.

Benchmark	Status	Retention expectation
ISO/IEC 27001:2022, A.8.15	Current	No period stated — you define and justify it
OMB M-21-31 (Aug 2021)	Rescinded 22 May 2026	12 months active storage plus 18 months cold storage
OMB M-26-14 (22 May 2026)	Current federal baseline	Actively searchable for at least 6 months; retrievable for one year

The distinction M-26-14 draws is the one worth borrowing. “Searchable” means detections and analytics can run on the data immediately. “Retrievable” means the data can be used after intermediate steps — rehydrating an archive, thawing cold storage. Writing your retention schedule in those two tiers rather than one flat number tells an auditor you have thought about cost against forensic reach, and it maps cleanly onto how log platforms are actually priced.

One caveat the memo itself flags and your policy should too: meeting a cybersecurity retention minimum does not discharge separate records-management, contractual or sector obligations. Payment, health and telecoms scopes routinely carry longer ones.

Protecting log integrity under A.8.15

The “protect” verb exists because attackers clear logs. Joint guidance published on 21 August 2024 by Australia’s ACSC with CISA, the FBI, the NSA and partner agencies is explicit that threat actors target local event logs for deletion or modification to delay incident response — which is exactly the failure mode A.8.15 is written against.

Four ISO 27001 logging measures satisfy the control and hold up under questioning:

• Forward off the host. A log that only exists on the compromised machine is not protected. Ship it to a separate or segmented environment with its own access controls.
• Make records immutable. Append-only or write-once storage, or cryptographic hashing of log records in transit and at rest.
• Separate duties. Nobody should be able to review, modify or delete the logs of their own activity — which is the whole point of the old administrator-and-operator-logs control that A.8.15 absorbed.
• Harden the collector. The SIEM and its forwarding agents are in scope. A tamper-proof log store reached through an unpatched collector is not a tamper-proof log store.

Access to the log platform is also an access control decision, so it should appear in your access control model rather than living only in the logging policy. Our ISO 27001 access control policy guide covers how to document that cleanly.

A.8.16 monitoring activities: baselines before tools

A.8.16 expects networks, systems and applications to be monitored for anomalous behaviour, with appropriate action taken to evaluate potential incidents. The word doing the work is anomalous, and anomalous is meaningless without a baseline of normal.

That is why buying a SIEM does not close A.8.16, and why tooling is the last decision in an ISO 27001 logging project rather than the first. Until you can describe normal — typical outbound destinations, usual sign-in hours and geographies, expected service accounts, standard resource consumption — your detections are either silent or drowning you. The agencies behind the 2024 joint guidance make the same point about living-off-the-land tradecraft: attackers abusing legitimate built-in tools produce almost no conventional indicators, so the only thing that gives them away is deviation from a known-good baseline.

Two limits on monitoring belong in the policy. The first is legal: monitoring user activity engages employment law and data protection obligations, so the scope and justification of what you monitor needs recording before you switch it on, not after. The second is the handoff — A.8.16 requires that action be taken to evaluate potential incidents, which means the output of monitoring has to arrive somewhere that handles it. If your detections do not feed a defined process, the control stops halfway. Our ISO 27001 incident response plan guide covers the receiving end.

A.8.17 clock synchronisation: the control that makes the others usable

A.8.17 asks you to define a single approved reference time and synchronise in-scope systems to it. It looks like the trivial control in the ISO 27001 logging set. It is the one that decides whether an incident timeline can be assembled at all. Correlating a firewall log, an authentication log and an endpoint log across three sources whose clocks drift by minutes produces a sequence of events that is confidently wrong.

Practically: nominate your time source, use NTP or an equivalent, and prefer a source traceable to a national authority — M-26-14 points US agencies at the US Naval Observatory or NIST. ISO/IEC 27002:2022 suggests considering a second, independent time source for resilience. In hybrid estates, cloud workloads usually inherit a provider-managed clock rather than yours, so record that and check for discrepancies instead of assuming alignment.

ISO 27001 logging evidence your auditor will ask for

An ISO 27001 logging control set is assessed on artefacts, not intent. These are the ones that get requested.

Evidence	Satisfies	Where it comes from
Logging and monitoring policy naming events, sources, retention and review cadence	A.8.15, A.8.16	Written once, approved, version-controlled
Log source inventory mapped to in-scope systems	A.8.15	Asset register cross-referenced with the SIEM
Sample log extracts showing the required fields	A.8.15	Pulled live during the audit
Retention configuration screenshots against the stated period	A.8.15	Log platform settings
Access list for the log platform plus proof of immutability	A.8.15	IAM export, storage policy
Triaged alerts and the tickets they generated	A.8.16	SIEM and service desk, same incident
Review records showing logs were analysed, with outcomes	A.8.15, A.8.16	Meeting notes, shift handovers, review log
NTP configuration and drift check for a sample of systems	A.8.17	Configuration management output
Statement of Applicability entries for 8.15, 8.16 and 8.17	Clause 6.1.3	Your SoA, with justification per control

The pairing in row six is the single most valuable artefact in the list. One alert, traced from detection through triage to a closed ticket, demonstrates A.8.15’s analyse verb and A.8.16’s action requirement in one move. Keep two or three of those ready.

Every applicable control also needs a line in the Statement of Applicability, which is mandatory under clause 6.1.3. If you are not sure how to word the justification, our Statement of Applicability guide walks through it.

Five ISO 27001 logging mistakes that cost findings

1. Logging everything. Volume is not coverage. It raises cost, slows queries and buries the events that matter. Derive sources from the activity list, not from what happens to emit a log.
2. Collecting without analysing. The most common finding in the set. Retained-and-never-read logs implement three of A.8.15’s four verbs.
3. Treating A.8.16 as a duplicate of A.8.15. They are separate SoA lines with separate evidence. Monitoring is an activity; logging is a record.
4. Leaving administrators able to clear their own logs. A direct hit on the control that A.8.15 inherited from the 2013 administrator-logs requirement.
5. Inheriting a retention number with no rationale. “Twelve months” copied from a template is indefensible once you are asked why. A risk-based figure with a searchable and a retrievable tier is not.

ISO 27001 logging FAQ

Does ISO 27001 require a logging policy?

Not as a mandatory document — ISO 27001:2022’s documented-information requirements do not name one. But A.8.15 and A.8.16 are effectively impossible to exclude from the Statement of Applicability for a technology scope, and the simplest way to demonstrate both is a written logging and monitoring policy. In practice, you will write one.

How long does ISO 27001 require you to keep logs?

ISO 27001 logging carries no mandated retention period. You choose one, justify it from your risk assessment and your legal and contractual obligations, and then prove the platform is configured that way. The current US federal baseline — six months actively searchable, one year retrievable — is a reasonable reference point for a commercial scope with no sector-specific rule.

Is a SIEM mandatory for ISO 27001?

No. No Annex A control names a product category, and ISO 27001 logging can be satisfied without one. A SIEM is the usual way to satisfy centralised collection, correlation and alerting at scale, and above a certain size the manual alternative stops being credible. A small, single-cloud scope can satisfy A.8.15 and A.8.16 with native cloud logging plus a documented review process.

What is the difference between A.8.15 and A.8.16?

A.8.15 is about the record: produce it, keep it, protect it, read it. A.8.16 is about the watching: detect behaviour that deviates from normal and act on it. You can hold perfect logs and fail A.8.16 because nothing is watching them in near real time, and you can run excellent detections and fail A.8.15 because an administrator can wipe the evidence.

Do cloud provider logs count?

Yes, within the shared-responsibility split. Provider-native logs are legitimate evidence for the layers the provider controls, but you still need to show they are enabled, retained for your stated period, protected from deletion by your own privileged users, and reviewed. Clock behaviour in cloud workloads is usually provider-managed, which is an A.8.17 item to document rather than ignore.

Documenting it without starting from a blank page

Most of the work in ISO 27001 logging is written, not technical: a logging and monitoring policy, a log source inventory, a retention schedule in two tiers, a review record, and three SoA justifications that match what the platform actually does. If you would rather adapt a drafted set than write them from scratch, the ISO 27001 Toolkit ships 165 editable templates covering the full Annex A control set and the mandatory clause documents, for $99. For the wider control picture, our overview of the 93 ISO 27001:2022 Annex A controls shows where logging sits relative to everything else.

Primary sources worth reading in full: the standard’s own scope and status at iso.org/standard/27001, and the current federal logging baseline in OMB Memorandum M-26-14.