A.8.15 expects event logs that answer 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 those five components are actually there.
Annex A 8.15 is one of the 34 Technological controls in ISO 27001:2022. It requires event logging, and it’s specific about content. As stated required content, an event log must carry five components — each one checkable by an auditor with a sample log open in front of them:
| 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 that should be logged. We won’t reproduce the list — ISO’s text is licensed — but its shape is what you’d expect: access to systems and data, actions taken by users and administrators, failures and faults, and changes to configuration and privileges. The pattern across all ten is the same: anything a person or system does that you’d want to reconstruct later.
Two design decisions follow from that. First, coverage. ISO 27001 is risk-based — you assess all 93 Annex A controls and record applicability in your Statement of Applicability, and the same logic governs which systems log. Nobody expects a debug trace from every workstation. They do expect a deliberate answer to “which systems log, which don’t, and who decided”. Second, content. Most default log formats fail at least one of the five components — typically user ID or source network address. Turning logging on isn’t the work; making the log say who and from where is.
Certification runs in two stages: Stage 1 reviews your documentation, Stage 2 is interviews and evidence. A.8.15 gets tested in Stage 2, and the test is concrete. The auditor picks systems from your Statement of Applicability, asks to see live logs, and reads them against the five components. Then come the follow-ups: how long are these kept, who can alter them, and can you actually retrieve a specific user’s activity from a specific week.
“We already send everything to a log tool.” Good — that answers the retrieval question, and central collection makes the whole control easier to evidence. It doesn’t answer the content question. A tool faithfully storing log lines that lack a user ID gives you a well-organised gap. The content test happens at the source system, and no amount of downstream tooling fixes a field that was never written.
Retention is the other recurring finding. The standard doesn’t set a number; your risk assessment and your legal and contractual obligations do. What trips organisations up isn’t picking the number — it’s the quiet mismatch between the policy and reality, where the policy says one thing and a disk-space setting on one server says another. Check the oldest log you can actually produce, per system, against what your policy promises.
One more thing worth knowing before the audit: A.8.15 rarely gets assessed alone. Its companion control, A.8.16 Monitoring Activities, asks what you do with all this recorded history. A.8.15 records history; A.8.16 analyses the present. Auditors read them as a pair — logging with nobody watching invites the obvious next question.
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, not the control text — ISO standards are copyrighted, so we state the requirements rather than reproduce the wording. For the text itself, buy the standard 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 |
The common failure is pointing at the cloud provider’s audit trail and calling the control done. That trail records the control plane — who changed infrastructure, when, from which key. It says nothing about what happens inside your applications, and that’s where the auditor will sample: a business system, a real log line, five components. The line that reads “record updated” with a timestamp and nothing else fails three of the five.
The fix is cheap and worth doing before Stage 2, not during it. Pick your three most important systems, pull one real log line from each, and score it against the five components. Fixing a missing user ID field is a configuration change in week one and a nonconformity in audit week.
Tools hand you a to-do list. We do the list — and run the security behind it. For A.8.15, that means 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 buried in free text. When the auditor asks for a named user’s activity on a named system from months back, that’s a search, not an archaeology project. Secure60 is ISO 27001:2022 certified ourselves — 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. If a sampled log line is missing one, the auditor will ask why.
Which events does A.8.15 say we should log?
The control specifies ten event types. Broadly, they cover access to systems and data, actions taken by users and administrators, failures and faults, and changes to things like configuration and privileges. Check the control text itself for the full list — ISO’s wording is licensed, so we don’t reproduce it 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 the auditor won’t accept is coverage decided by accident — you need to be able to say which systems log, which don’t, and why.
How long do we have to keep logs?
ISO 27001 doesn’t prescribe a retention period. Set one from your risk assessment and your legal and contractual obligations, write it down, then be ready to show the auditor that logs actually survive that long.
Is our cloud provider's audit trail enough on its own?
Usually not. It records who changed your infrastructure, not what happens inside your applications. A.8.15 applies to the systems that matter to your risk assessment, and most of those write their own logs — or fail to.
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.
