RBI 2023 Master Direction Clause 15 requires that regulated entities maintain audit trails suitable for forensic investigation and dispute resolution. This is a higher standard than authentication logging. Authentication logs record that a session occurred. Forensic-grade audit trails record what happened during it, at sufficient detail to reconstruct the sequence of events, identify the actor responsible, and determine the scope of impact.
The distinction matters in two scenarios that RBI-regulated entities face regularly. Post-incident investigation: when a data breach, fraudulent transaction, or unauthorised configuration change occurs, the investigation team needs to know which user accessed which system, which commands were run, which data was queried, and what changed. Authentication timestamps tell the team a session occurred. Keystroke logs and query capture tell them what happened. Dispute resolution: when a customer or counterparty disputes a transaction or alleges unauthorised access, the regulated entity needs to produce evidence of what occurred. An authentication log is not evidence of what happened in a session. A session recording is.
Most RBI-regulated entities have authentication logging in place. The gap is almost always at the session activity layer: what users did after authenticating, particularly privileged users with access to core banking systems, payment infrastructure, and production databases. This blog covers what Clause 15 specifically requires, why the forensic standard cannot be met by authentication logs alone, and what controls produce the evidence standard Clause 15 demands.
Clause 15 is structured across three sub-clauses covering different dimensions of the audit trail requirement.
Clause 15(a) requires audit trails that record all access to information systems, including successful and failed authentication attempts, with sufficient detail to enable forensic investigation. The forensic investigation standard is the operative requirement. A forensic investigator examining a security incident needs more than a record that authentication occurred. They need a record of what the authenticated user did within the system during the session.
For privileged users with administrative access to servers, databases, and network infrastructure, forensic investigation requires session-level recording. A database administrator whose session is under investigation needs a record of every SQL query executed, not only a timestamp showing when they connected. A system administrator needs a record of every command run in the SSH session, not only confirmation that the SSH connection was established.
Clause 15(b) requires audit trails capturing data modifications, system configuration changes, and administrative actions, with actor identity, timestamp, and before-and-after state where applicable. This extends beyond session logging to cover the specific change events that represent the highest risk in a regulated entity’s environment.
Configuration changes to core banking systems, modifications to access control policies, changes to user privileges, and updates to payment processing rules are all administrative actions that Clause 15(b) requires to be logged with the actor’s identity and a record of what changed. This evidence is what an RBI IS auditor needs to assess whether changes were authorised and whether the change management process was followed.
Clause 15(c) requires that audit trails be protected against modification, deletion, or tampering. Logs must be retained for a defined period sufficient for forensic investigation and regulatory examination, and must be available on demand for regulatory review.
The tamper protection requirement is what distinguishes a compliance-grade audit trail from a standard log file. A log file stored in a file system where an administrator with sufficient privileges can modify or delete records cannot serve as forensic evidence. An append-only audit trail where existing records cannot be modified is the technical standard Clause 15(c) requires.
Authentication logs and session activity logs address different layers of the same event. Understanding the gap precisely is necessary for assessing whether current logging infrastructure meets Clause 15’s forensic standard.
An authentication log captures the login event: who attempted to connect, when, from which IP address and device, using which authentication method, and whether the attempt succeeded or failed. For a successful session, the authentication log records the session open event. It records nothing further until the next authentication event.
For a privileged user who authenticates to a production database, runs a series of queries, exports a dataset, modifies a stored procedure, and disconnects, the authentication log contains: connection timestamp, source IP, MFA method used, and disconnection timestamp. The queries run, the data exported, and the stored procedure modified are not in the authentication log.
Clause 15(a)’s forensic investigation standard requires that the audit trail be sufficient to reconstruct what happened during a session. For the database session described above, reconstruction requires the complete list of SQL queries executed, the tables and columns accessed, the data returned, and the modification made to the stored procedure. Without this, a forensic investigator examining a suspected data exfiltration incident cannot determine from the logs whether data was exported or what was accessed.
For a dispute resolution scenario, Clause 15’s evidence standard requires that the regulated entity can produce records showing what a specific user did in a specific session on a specific date. An authentication log showing the user connected is not evidence of what they did. A session recording showing every query they executed is.
The gap between authentication logging and session activity logging is not configurational. Authentication logs and session activity logs are fundamentally different infrastructure layers. Authentication logs are generated by the identity and authentication system. Session activity logs for privileged access require a session proxy layer, such as AkkuReka, that sits between the authenticated user and the target system and records everything passing through it.
An organisation that has authentication logging but no session proxy infrastructure cannot produce session activity logs for privileged access regardless of how the authentication system is configured. The session activity logging capability requires deployment of a PAM-layer session proxy.
Meeting Clause 15’s forensic standard across the full scope of a regulated entity’s critical systems requires session activity logging for every privileged access path to those systems.
SSH sessions to Linux servers, Unix systems, and network devices require keystroke-level logging per command. Every command the administrator types, the arguments provided, the directory context, and the output produced must be captured with a timestamp. Full screen recording provides visual context. Keystroke logging provides structured, searchable data.
The combination of screen recording and keystroke logging is what makes SSH session evidence forensically useful. Screen recordings can be reviewed visually. Keystroke logs can be searched by command string, allowing investigators to find all sessions where a specific command was run without reviewing every recording manually.
Database sessions to MySQL, PostgreSQL, and other database management systems require SQL query capture. Every query executed during the session must be captured as structured data: query text, timestamp, database and table context. Full screen recording of the database client interface provides supplementary visual evidence.
SQL query capture is what makes database session evidence useful for both forensic investigation and dispute resolution. When a data integrity incident occurs, the investigation team can query the session logs for all SELECT statements against a specific table, all DELETE or UPDATE statements, and all data export operations. Without structured query capture, this investigation requires manual review of screen recordings.
RDP sessions to Windows servers and workstations require full screen video recording at sufficient resolution and frame rate to reconstruct what was done during the session. RDP sessions involve graphical interfaces where activity cannot be captured as structured text. Screen recording combined with session metadata, open timestamp, active duration, and close timestamp, constitutes the session activity log for RDP.
Kubernetes sessions require command log capture for kubectl operations. Web application sessions require session event logging covering page navigation, form submissions, and data access events.
SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka, producing the forensic-grade audit trail Clause 15 requires across SSH, RDP, database, Kubernetes, and web application sessions.
SSH sessions produce full screen recordings and complete keystroke logs per command. MySQL and PostgreSQL sessions produce full screen recordings and structured capture of every SQL query executed. RDP sessions produce full screen video recordings at configurable frame rates. Kubernetes sessions produce session event recordings and command logs. HTTP and HTTPS web application sessions produce session recordings and event logs.
All recordings are stored encrypted with AES-256. The audit log is append-only and tamper-evident. Existing records cannot be modified or deleted after creation. This is the log protection standard Clause 15(c) requires. Logs are retained according to configured retention policies, with export capability for regulatory submission.
Recordings are indexed for forensic search by timestamp, command string for SSH sessions, and SQL query text for database sessions. This enables investigators to search across all sessions for specific commands or queries without reviewing every recording manually, satisfying the forensic investigation utility that Clause 15(a)’s standard implies.
Recordings are accessible for in-browser playback directly from the Akku admin console without requiring file downloads or external media players. Structured audit log exports in JSON and CSV format are available via API and manual export for regulatory submission. Session recordings are exportable for forensic investigation and auditor review.
Akku’s RBI compliance mapping shows Audit Logs addresses Clauses 8(c), 15(a), 15(b), 15(c), 25(c), 27(b), and 30(f) across seven clause mappings, the highest single-module count in the RBI mapping.
For a privileged user who accessed a production database last month, can you produce every SQL query they executed during the session, searchable by query text, without reviewing a screen recording manually?
For a system administrator who made a configuration change on a Linux server three months ago, can you produce a keystroke log showing every command they ran during the session, including the specific configuration file they modified?
Are your audit logs stored in an append-only format where administrators with privileged access to the logging infrastructure cannot modify or delete existing records?
Can you produce on demand, for any 90-day window an RBI examiner specifies, a complete structured export of all authentication events and privileged session records across all critical systems without manual compilation?
For a disputed transaction or alleged unauthorised access event, can your organisation produce session-level evidence showing what the implicated user did during the relevant session, sufficient to satisfy the dispute resolution standard Clause 15 requires?
See how Akku’s SMARTAudit Trails address RBI Clause 15 forensic audit trail requirements across SSH, RDP, database, and Kubernetes sessions.
Book a conversation with the Akku team to assess your current audit trail infrastructure against RBI Clause 15’s forensic evidence standard.
What does forensic investigation standard mean in the context of RBI Clause 15, and how does it differ from standard audit logging?
A forensic investigation standard means the audit trail is sufficient to reconstruct a sequence of events, identify the responsible actor, and determine the scope of impact of an incident. Standard audit logging records that events occurred. A forensic-grade audit trail records what happened in sufficient detail to answer investigation questions: which commands were run, which data was accessed, what was modified, and in what sequence. For privileged access to critical systems, this requires session-level recording at the keystroke or query level, not authentication timestamps.
Does RBI Clause 15 apply only to privileged users or to all users?
Clause 15 applies to all access to information systems, not only privileged access. However, the forensic evidence standard is most demanding for privileged access scenarios because privileged users have the ability to make high-impact changes that require detailed reconstruction. For standard end users accessing business applications, application-level audit trails within those applications typically satisfy Clause 15’s requirements. For privileged users accessing servers, databases, and network infrastructure directly, session-level recording through a PAM-layer proxy is required because there is no application-level audit trail for direct system access.
What retention period should regulated entities apply to audit trail records under Clause 15?
RBI’s 2023 Master Direction does not specify a precise retention period in Clause 15 itself. Industry practice at RBI-regulated entities typically maintains authentication event logs for a minimum of two years, system configuration change logs for two years, and privileged session recordings for two years or longer for sessions involving access to critical banking systems. Entities should define retention periods in their IT security policy, ensure the periods are consistently applied, and verify that the retention periods satisfy the framework’s forensic investigation and regulatory examination requirements.
How does Clause 15’s tamper protection requirement apply to cloud-hosted audit logs?
Clause 15(c) requires that audit logs be protected against modification, deletion, or tampering, regardless of where they are stored. For cloud-hosted audit logs, tamper protection requires an append-only storage architecture where new records can be added but existing records cannot be modified or deleted. Access controls must prevent even privileged administrators from modifying log records. The cloud hosting model does not exempt the requirement. Akku’s audit log architecture is append-only regardless of deployment model, satisfying Clause 15(c)’s tamper protection requirement in both cloud-native SaaS and on-premises deployments.
Can the same session recordings that satisfy RBI Clause 15 also satisfy SEBI CSCRF PR.AA.S12 and ISO 27001 A.8.15?
Yes. SMARTAudit Trail recordings satisfy multiple framework requirements simultaneously. RBI Clause 15 requires audit trails suitable for forensic investigation. SEBI CSCRF PR.AA.S12 requires that privileged session activity be logged with sufficient detail to reconstruct actions taken. ISO 27001 A.8.15 requires logging of user activities, not login events. All three requirements 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 searchable for forensic investigation. The same evidence package serves all three frameworks.
What is the difference between Clause 15(a), 15(b), and 15(c), and do they require separate technical controls?
Clause 15(a) covers system access audit trails, requiring records of authentication events and session activity sufficient for forensic investigation. Clause 15(b) covers data modification and administrative action trails, requiring records of specific change events with actor identity and before-and-after state. Clause 15(c) covers log protection and availability, requiring tamper-evident storage and on-demand access. They address different layers and require complementary controls. Clause 15(a) is satisfied by authentication event logs and SMARTAudit Trails session recordings. Clause 15(b) is satisfied by administrative event logs capturing role changes, policy modifications, and user lifecycle events. Clause 15(c) is satisfied by the append-only audit log architecture applied across all log types. All three are required and satisfying one does not satisfy the others.
Introduction DPDPA Chapters II and III establish six rights for Data Principals. Each right creates a corresponding technical obligation for…
Introduction Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated…
Introduction DPDPA Chapters II and III establish six rights for Data Principals. Each right creates a corresponding technical obligation for…
Introduction GDPR Article 25 requires that data protection be built into system architecture by design and that data minimisation be…
Introduction ISO 27001:2022 Annex A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and…
Introduction Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated…