ISO 27001:2022 Annex A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and regularly reviewed. The control is specific: user activities. Not login events. Not authentication outcomes. The activities a user performs after authentication succeeds.
Most organisations pursuing ISO 27001 certification have authentication logging in place. Every login attempt is recorded. MFA outcomes are captured. Failed authentication attempts generate alerts. This is necessary but it does not satisfy A.8.15. Authentication logs answer the question of who connected. A.8.15 requires evidence of what they did once connected.
The distinction becomes critical during post-incident investigation. When a privileged user accesses a production server and a configuration change is made that causes a system outage, an authentication log confirms the session occurred. It provides no evidence of which commands were run, which files were modified, or which configuration was changed. Reconstructing what happened requires session-level activity logs. Without them, investigation relies on inference rather than evidence.
ISO 27001 certification auditors examine A.8.15 by asking for samples of user activity logs, not authentication logs. An auditor who receives authentication event exports when they asked for user activity logs will raise a finding. This blog covers what A.8.15 requires technically, how user activity logging differs from authentication logging at the implementation level, and what evidence a certification audit expects.
The gap between what A.8.15 requires and what most organisations have implemented is architectural, not configurational. It cannot be closed by adding more fields to an existing authentication log.
A.8.15 requires logs covering four categories. User activities: the actions a user performs within a system session, including commands executed, files accessed, queries run, and configuration changes made. Exceptions: events where normal processing did not complete, including access denied events, application errors triggered by user actions, and policy violations. Faults: system-level events including failed processes, service interruptions, and hardware faults relevant to security. Security events: authentication failures, privilege escalation attempts, policy changes, and account modifications.
The logging infrastructure must protect logs against tampering and unauthorised access. Logs must be retained for defined periods and available for investigation when security incidents occur. The review requirement means logs must be actively monitored, not only stored.
Authentication logs record the login layer. Who attempted to authenticate, when, from which IP and device, using which authentication method, and whether the attempt succeeded. For sessions that succeed, the authentication log records the session start. For sessions that fail, it records the failure reason and any MFA outcome.
Authentication logs do not record anything inside an authenticated session. Once a user passes authentication and the session opens, the authentication log has no further entries for that session until the next authentication event. Everything that happens in between, every command, every query, every file operation, every configuration change, is invisible to the authentication log.
For standard end users accessing SaaS applications, this gap is partially acceptable because application-level activity logging within those applications captures the relevant user actions. For privileged users accessing servers, databases, and network devices directly, there is typically no application-level activity log. The session is a direct connection to a system, and without session-level recording, the activity inside it is unrecorded.
A.8.15’s user activity logging requirement is most demanding for privileged access scenarios. A privileged user with SSH access to a Linux server, database administrator access to a production MySQL instance, or RDP access to a Windows server has the ability to make changes with significant impact. The activity logging requirement exists precisely because these are the sessions where the evidence of what occurred matters most.
For SSH sessions, user activity logging requires keystroke-level capture per command. The log must record every command the user typed, the directory context in which it was executed, and the output produced. A screen recording that captures visual session activity satisfies part of this requirement but does not produce structured, searchable keystroke data. Full compliance requires both screen recording and structured keystroke logging.
The practical implication is that a Linux server administrator who runs a series of commands during a session, modifies a configuration file, restarts a service, and exits can be fully reconstructed from the keystroke log. Every command, every argument, every file path is in the record. An authentication log of the same session contains only the session start and end timestamps.
For database sessions, user activity logging requires capture of every SQL query executed during the session. The log must record the query text, the timestamp, the database and table context, and where possible the number of rows affected. This is the evidence base that satisfies A.8.15’s user activity requirement for database access and that supports forensic investigation when data integrity questions arise.
An authentication log of a database session records that a DBA connected to the database at a given time. It does not record whether they ran a SELECT on a customer table, executed a DELETE, or modified a stored procedure. Without query-level logging, the investigation of a data integrity incident in a database is severely hampered.
For RDP sessions to Windows servers, user activity logging requires screen recording at sufficient resolution and frame rate to reconstruct what was done during the session. RDP sessions involve graphical interfaces where the activity cannot be captured as structured text. Screen recording is the appropriate logging mechanism, supplemented by session event logs capturing session open, active duration, and termination reason.
ISO 27001 certification auditors examining A.8.15 follow a consistent examination pattern. Understanding what they look for helps organisations assess whether their current logging infrastructure satisfies the control.
Auditors typically select a sample of privileged users and request the activity logs for a defined period, often the last 30 days. They examine whether the logs produced are user activity logs capturing session-level actions, or authentication logs capturing login events. An organisation that produces authentication logs in response to this request has demonstrated a gap in A.8.15 implementation.
For the sampled period, auditors verify that every privileged session to critical systems has a corresponding activity log entry. Gaps in coverage, sessions that occurred but have no activity log record, indicate incomplete deployment of the activity logging controls.
Auditors examine whether logs are protected against tampering. An append-only, tamper-evident architecture where existing records cannot be modified is what satisfies this requirement. Logs stored in standard file systems that can be modified by administrators with sufficient access do not satisfy the tamper protection requirement.
A.8.15 requires that logs be regularly reviewed. Auditors look for evidence that the review process operates, not only that logs exist. Risk and audit dashboards that surface anomalous events for administrator attention, combined with records showing that alerts were investigated and actioned, constitute review evidence. Passive log storage with no review mechanism does not satisfy the regular review requirement.
SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka, producing the user activity logs A.8.15 requires across SSH, RDP, database, and web application sessions.
SSH sessions produce two complementary records. A full screen recording capturing the visual session at configurable quality. A complete keystroke log capturing every command typed with timestamp, providing structured, searchable activity data. The keystroke log is the user activity log A.8.15 requires for SSH sessions. The screen recording provides the visual context.
MySQL and PostgreSQL sessions produce full screen recordings and a structured capture of every SQL query executed during the session. Each query record includes the query text and session context. This query capture is the user activity log A.8.15 requires for database sessions.
RDP sessions produce full screen video recordings at configurable frame rates. Session event logs capture session open, active duration, keystroke count, and termination reason.
All SMARTAudit Trail recordings are stored encrypted with AES-256. The audit log is append-only and tamper-evident. Records cannot be modified or deleted after creation. Recordings are indexed for forensic search by timestamp, command string, or SQL query and accessible for in-browser playback from the Akku admin console without requiring file downloads or external media players.
API access to audit logs supports integration with SIEM and log aggregation platforms. Structured export in JSON and CSV format supports auditor submission and forensic investigation workflows.
Akku’s ISO 27001 mapping shows Privileged Access Manager addresses A.8.3, A.16.2, A.16.6, A.16.7, and A.16.8. The Identity and Access Governance module, carrying 16 clause references, covers the broader access governance controls that complement A.8.15’s activity logging requirement.
When a system administrator runs commands on a production Linux server, is there a keystroke log capturing every command executed during the session, or only an authentication log confirming the session occurred?
When a database administrator connects to a production MySQL or PostgreSQL database, is there a record of every SQL query executed during the session, or only a record that the connection was established?
Are your privileged session activity logs stored in an append-only, tamper-evident format where existing records cannot be modified, or are they stored in a file system that administrators with sufficient access could modify?
Can you produce the complete activity log for any privileged session that occurred in the last 90 days, searchable by command string or SQL query, without requiring a manual log compilation exercise?
Is there a defined process for regularly reviewing privileged session activity logs, with evidence that anomalous sessions trigger investigation, or are logs stored passively without a systematic review mechanism?
See how Akku’s SMARTAudit Trails address ISO 27001 A.8.15 requirements for user activity logging across SSH, RDP, and database sessions.
Book a conversation with the Akku team to assess your current logging infrastructure against ISO 27001:2022 A.8.15 certification requirements.
What is the specific difference between an authentication log and a user activity log under ISO 27001 A.8.15?
An authentication log records login events: who connected, when, from which IP and device, using which authentication method, and whether the attempt succeeded. A user activity log records what happened after authentication: which commands were executed, which queries were run, which files were accessed, which configuration changes were made. A.8.15 requires the latter. An organisation that has authentication logging but no session-level activity logging for privileged users has a gap in A.8.15 compliance that a certification auditor will identify when they request user activity log samples.
Does A.8.15 apply equally to all users or primarily to privileged users?
A.8.15 applies to all users, but the practical implementation priority is privileged users. For standard users accessing SaaS applications, activity logging is often handled within the applications themselves, which log user actions at the application layer. For privileged users accessing servers, databases, and network devices directly, there is no application-level activity log. The session is a direct system connection, and without session-level recording through a PAM-layer proxy, the activity inside it is entirely unrecorded. A.8.15’s user activity logging requirement is therefore most demanding to implement, and most commonly unmet, for privileged access scenarios.
What does A.8.15 require for log protection, and how does an append-only architecture satisfy this?
A.8.15 requires that logs be protected against tampering and unauthorised access. An append-only architecture means that once a log record is written, it cannot be modified or deleted. New records can be added, but existing records are immutable. This is the tamper protection mechanism that satisfies A.8.15’s requirement. Logs stored in standard file systems where administrators with sufficient privileges can modify or delete records do not satisfy the tamper protection requirement. The append-only property, combined with access controls preventing direct human access to the raw log data, constitutes the technical implementation of A.8.15’s protection requirement.
How does A.8.15 interact with A.8.16 monitoring activities, and do they require separate controls?
A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced and kept. A.8.16 requires that networks, systems, and applications be monitored for anomalous behaviour and that appropriate actions be taken. A.8.15 is about log generation and retention. A.8.16 is about active monitoring and anomaly detection. They are complementary but distinct controls. A.8.15 is satisfied by a session activity logging infrastructure with tamper protection and defined retention. A.8.16 is satisfied by an active monitoring layer that evaluates events against baselines and generates alerts. Satisfying one does not satisfy the other.
What retention period should organisations apply to user activity logs to satisfy A.8.15?
ISO 27001:2022 does not specify a defined retention period in A.8.15. The control requires that logs be kept for defined periods sufficient for investigation purposes. In practice, most certification bodies and auditors expect a minimum retention period of one year for authentication event logs and user activity logs. For privileged session recordings, a two-year retention period is common in organisations handling sensitive data. The retention period should be defined in the organisation’s information security policy and consistently applied. Organisations subject to additional regulatory requirements, such as RBI or SEBI, should align their retention periods with the longer of the ISO 27001 internal policy requirement and the regulatory requirement.
Can SMARTAudit Trails evidence be used for both ISO 27001 A.8.15 certification and RBI Clause 15 forensic investigation requirements simultaneously?
Yes. SMARTAudit Trails produce session-level activity logs that satisfy both A.8.15’s user activity logging requirement and RBI Clause 15’s forensic audit trail standard from the same recordings. ISO 27001 A.8.15 requires user activity logs for privileged sessions. RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. Both are satisfied by keystroke logs for SSH sessions, SQL query capture for database sessions, and screen recordings for RDP sessions, stored in append-only, tamper-evident format and accessible for forensic search. The same evidence package serves both requirements.
Introduction GDPR Article 25 requires that data protection be built into system architecture by design and that data minimisation be…
Introduction Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated…
Introduction SOC 2 CC6 is the Logical and Physical Access Controls criterion cluster and is where the majority of IAM-relevant…
Introduction RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes…
Introduction SEBI CSCRF's Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the…
Introduction DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be…