A.8.15 requires event logs that record who did what, when, where and from where: user ID, system activities, date and time, device or system identity and location, and network addresses and protocols. The control specifies ten event types to log. At Stage 2, the auditor samples real logs and checks that those five components are present.
Annex A 8.15 is one of the 34 Technological controls in ISO 27001:2022. It requires event logging and specifies the content. An event log must carry five components, each checkable by an auditor against a sample log line.
| Required log content | The question it answers | Where it commonly goes missing |
|---|---|---|
| User ID | Who did it? | Shared accounts, service accounts, applications that record the action but not the actor |
| System activities | What happened? | Systems that log errors but not normal operations |
| Date and time | When? | Clocks that drift, timestamps in three different formats across systems |
| Device or system identity and location | On what, and where? | Aggregation pipelines that strip the originating host |
| Network addresses and protocols | From where, over what? | Application logs with no source address; proxies and load balancers masking the true origin |
The control also specifies ten event types to log. The list itself is licensed text and is not reproduced here; it covers access to systems and data, actions taken by users and administrators, failures and faults, and changes to configuration and privileges — actions by a person or system that would need reconstructing later.
Two design decisions follow. The first is coverage. ISO 27001 is risk-based, so applicability is recorded in the Statement of Applicability, and the same logic governs which systems log. What the audit examines is a deliberate decision: which systems log, which do not, and who decided. The second is content. Most default log formats fail at least one of the five components, typically user ID or source network address. Enabling logging is the smaller task; producing a log line that records the actor and the origin is the substantive one.
Certification runs in two stages: Stage 1 reviews documentation, Stage 2 covers interviews and evidence. A.8.15 is tested at Stage 2. The auditor selects systems from your Statement of Applicability, requests live logs, and reads them against the five components, followed by retention period, who can alter the logs, and whether a specific user’s activity from a specific week can be retrieved.
Central collection answers the retrieval question and makes the control easier to evidence. It does not answer the content question: a tool storing log lines that lack a user ID stores an organised gap. The content test applies at the source system, and downstream tooling cannot supply a field that was never written.
Retention is the other recurring finding. The standard sets no number; your risk assessment and your legal and contractual obligations do. The failure is usually a mismatch between the documented period and a disk-space setting on one server. The oldest log retrievable in practice, per system, is the figure to check against the policy.
A.8.15 is rarely assessed alone. Its companion control, A.8.16 Monitoring Activities, covers what is done with the recorded history. A.8.15 records history; A.8.16 analyses the present. Auditors assess them as a pair.
ISO/IEC 27001:2022, Annex A 8.15 requires that event logs be produced, and states their required content: the user ID; system activities; the date and time; the identity and location of the device or system; and network addresses and protocols. It further specifies ten types of event that should be logged. This is a paraphrase rather than the control text, because ISO standards are copyrighted. The text itself is available from ISO or your national standards body.
| Framework | Control | How it compares |
|---|---|---|
| PCI DSS v4.0.1 | Requirement 10 — logging you can prove, every day | The same discipline, more prescriptive: log and monitor all access, plus a mandatory automated daily log review since 31 March 2025 |
| ISO 27001:2022 | Annex A 8.16 — Monitoring Activities | The companion control in the same standard: A.8.15 records history, A.8.16 analyses the present |
A cloud provider’s audit trail records the control plane: who changed infrastructure, when, and from which key. It records nothing about activity inside your applications, which is where the auditor samples — a business system, a real log line, five components. A line reading “record updated” with a timestamp fails three of the five.
Testing this before Stage 2 is inexpensive. Take your three most important systems, pull one real log line from each, and score it against the five components. A missing user ID field is a configuration change during implementation and a nonconformity during the audit.
Secure60 operates the control and keeps its evidence current. For A.8.15 our log management platform ingests events from your systems and cloud services, retains them for the period your policy commits to, and keeps the five required components queryable rather than embedded in free text. A request for a named user’s activity on a named system from months back is answered by a search. Secure60 holds ISO 27001:2022 certification, and the logging we run for you is the logging we pass our own audits with.
What must an event log contain under A.8.15?
Five components: user ID, system activities, date and time, the identity and location of the device or system, and network addresses and protocols. A sampled log line missing one of them will be queried by the auditor.
Which events does A.8.15 say we should log?
The control specifies ten event types, covering access to systems and data, actions taken by users and administrators, failures and faults, and changes to configuration and privileges. The full list is in the control text itself; ISO’s wording is licensed, so it is not reproduced here.
Do we have to log every system we own?
No. ISO 27001 is risk-based: you assess all 93 Annex A controls and document how you apply them in your Statement of Applicability. What an auditor examines is the reasoning — which systems log, which do not, and on what basis.
How long do we have to keep logs?
ISO 27001 prescribes no retention period. Set one from your risk assessment and your legal and contractual obligations, document it, and be ready to demonstrate that logs survive that long in practice.
Is our cloud provider's audit trail enough on its own?
Usually not. It records who changed your infrastructure rather than what happens inside your applications. A.8.15 applies to the systems identified in your risk assessment, and most of those write their own logs.
What's the PCI DSS equivalent of A.8.15?
Requirement 10 — log and monitor all access to system components and cardholder data. It covers the same ground and adds a mandatory automated daily log review.
