Introduction

RBI 2023 Master Direction Clause 19(b) requires close supervision of privileged users with logged system activities sufficient to reconstruct what actions were taken during privileged sessions. This is one of the most technically specific requirements in the RBI framework, and it is consistently among the findings in RBI IS audits at banks and NBFCs that have application-layer MFA but no session-level recording for privileged infrastructure access.

The requirement has two components that are often conflated. Supervision means real-time visibility into active privileged sessions and the ability to terminate sessions exhibiting suspicious behaviour. Logged system activities means session-level recordings that capture what privileged users did during completed sessions, at sufficient detail for forensic reconstruction. Both are required. An organisation with session recordings but no real-time monitoring capability has one component. An organisation with monitoring capability but authentication logs instead of session recordings has the other. Clause 19(b) requires both.

The forensic reconstruction standard is the operative evidence requirement. A RBI IS auditor examining a suspected incident involving a privileged user needs to reconstruct the sequence of events: which commands were run, which queries were executed, what data was accessed, what was changed. An authentication log showing the user connected at a given time satisfies none of these requirements. Keystroke logs and SQL query capture satisfy all of them.

This blog covers what Clause 19(b) requires at the implementation level, what an RBI IS audit examination of 19(b) looks for, how the requirement integrates with Clauses 19(a) and 19(c), and what technical controls produce the evidence standard the clause demands.

What Clause 19(b) Requires in Full

Clause 19(b) is part of the broader Clause 19 access control provision. Understanding its place within that structure clarifies what the supervision and logging requirements are designed to achieve.

The full Clause 19 structure

Clause 19(a) requires need-based access: privileged users access only what their current role requires. Clause 19(b) requires close supervision with logged system activities for those privileged users. Clause 19(c) requires MFA for privileged access to critical information systems.

Together, the three sub-clauses address who gets privileged access, how their sessions are supervised and recorded, and how they are authenticated. Clause 19(b) sits between the access governance controls of 19(a) and the authentication controls of 19(c). It is the accountability layer: given that a privileged user has been granted need-based access under 19(a) and authenticated with MFA under 19(c), what evidence exists of what they did during their session?

Close supervision

Close supervision requires real-time visibility. An administrator must be able to see all active privileged sessions from a monitoring console at any time, not only review historical recordings. The monitoring must be live enough to allow intervention: if a privileged user initiates actions that appear suspicious during an active session, an administrator must be able to terminate the session before the actions complete.

This is a materially different capability from historical log review. Log review identifies what happened after the session closed. Real-time supervision enables intervention during the session. Both are required under Clause 19(b)’s close supervision standard.

Logged system activities sufficient for reconstruction

The logged system activities requirement sets the evidence standard: sufficient to reconstruct what actions were taken. Reconstruction requires activity-level records. For SSH sessions: every command executed with timestamp, directory context, and output. For database sessions: every SQL query executed with timestamp and table context. For RDP sessions: screen recordings sufficient to visually reconstruct what the user did.

The reconstruction standard is specifically what distinguishes Clause 19(b)’s logging requirement from standard authentication logging. Authentication logs support verification of identity and session timing. Session activity logs support reconstruction of actions. The clause requires the latter.

What an RBI IS Audit Examination of Clause 19(b) Looks For

RBI IS auditors examining Clause 19(b) compliance follow a consistent examination pattern. Understanding this pattern helps organisations assess whether their current controls will satisfy the examination.

Session recording sampling

Auditors select a sample of privileged sessions to critical systems from the examination period, typically the last 12 months. For each sampled session, they request the session recording and verify that it captures activity at the appropriate level: keystroke logs for SSH, SQL query capture for database sessions, screen recordings for RDP. Sessions where only authentication records exist, with no session activity recording, are findings.

The sampling is typically stratified: sessions to core banking systems, sessions to payment infrastructure, and sessions to production databases are the highest priority. Sessions to development or test environments may be sampled separately at lower priority.

Real-time monitoring capability demonstration

Auditors test real-time monitoring capability by asking administrators to demonstrate live visibility into active privileged sessions from the monitoring console. They verify that the console shows active session details including actor identity, target system, session duration, and activity. They test session termination capability: can an administrator terminate a specific session from the monitoring console, and is the termination event logged?

An organisation that can produce historical session recordings but cannot demonstrate live monitoring capability has an incomplete Clause 19(b) implementation. Both components are examined.

Approval workflow records

Auditors examine whether privileged sessions were opened through a formal approval process. They look for session request records showing target system, access level, duration, and justification, alongside approval records showing approver identity and timestamp. Sessions that opened without a corresponding approval record indicate either that the approval workflow was bypassed or that it was not required, both of which raise concerns under Clause 19(b)’s supervision standard.

Coverage completeness

Auditors assess whether session recording coverage is complete across all critical systems. A regulated entity with session recordings for database access but not for SSH access to Linux servers has partial coverage. The examination includes a coverage assessment: which systems are within the session recording perimeter and which are outside it.

How AkkuReka and SMARTAudit Trails Address Clause 19(b)

AkkuReka’s session proxy architecture and SMARTAudit Trails together constitute the technical implementation of Clause 19(b)’s supervision and logging requirements.

AkkuReka session proxy architecture

AkkuReka uses an outbound worker model. A lightweight worker process deploys in the same network segment as the target systems. The worker initiates an outbound TLS 1.3 connection to the Akku cloud. No inbound firewall ports are required on the target network. Every privileged session routes through AkkuReka. No direct connection between a privileged user and a target system exists outside the proxy.

This architectural control is what makes Clause 19(b)’s coverage completeness achievable. When all privileged connections must route through AkkuReka, session recording coverage is complete by design. There are no access paths to critical systems that bypass the recording infrastructure.

The outbound worker model also addresses a common deployment constraint at RBI-regulated entities: organisations with air-gapped or highly restricted network segments can deploy the AkkuReka worker within the restricted segment without requiring inbound firewall rules that security policy prohibits.

SMARTAudit Trail coverage

SSH sessions produce full screen recordings and complete keystroke logs per command. Every command typed by the privileged user is captured with a timestamp, the directory context at the time of execution, and the command output. This is the keystroke-level activity log that Clause 19(b)’s reconstruction standard requires for Linux server and network device access.

MySQL and PostgreSQL database sessions produce full screen recordings and structured capture of every SQL query executed during the session. Each query record captures query text, timestamp, and session context. This is the query-level activity log that Clause 19(b) requires for database access.

RDP sessions to Windows servers and workstations produce full screen video recordings at configurable frame rates. Session event logs capture session open, active duration, and termination reason. The screen recording provides the visual reconstruction capability Clause 19(b) requires for Windows server access.

Kubernetes sessions produce session event recordings and command logs for kubectl operations. HTTP and HTTPS web application sessions produce session recordings and event logs.

Real-time session monitoring

The Akku admin console displays all active privileged sessions in real time. Each active session shows actor identity, target system, session duration, and current activity. Any live session can be terminated instantly from the console. Termination is recorded in the audit log with the administrator’s identity, the termination timestamp, and the reason.

This is the close supervision capability Clause 19(b) requires. The monitoring console is not a retrospective log viewer: it is a live supervision interface with intervention capability.

Session approval workflow

Every privileged session request submitted through the Akku IAM portal includes target system, requested access level, duration, and justification. Approvers are notified via email or in-platform notification. No session opens without explicit approval when the workflow is enabled. The session is held in a pending state until approved.

Approval and denial decisions are logged with approver identity and timestamp. The complete approval workflow record, from request submission through approval or denial through session open, constitutes the formal authorisation evidence that Clause 19(b)’s supervision requirement implies.

How Clause 19(b) Interacts With Clauses 19(a) and 19(c)

Clauses 19(a), 19(b), and 19(c) address different layers of privileged access risk and must be implemented together for a defensible Clause 19 posture.

The access governance layer: Clause 19(a)

Clause 19(a) requires that privileged access be need-based. JIT access implements this by ensuring no privileged user holds standing access to target systems. Access is granted for the duration of an approved session and revoked automatically on expiry. The session approval workflow under Clause 19(b) is the mechanism through which need-based access is both granted and documented: every session has an approved justification that establishes why the access was needed at that time.

The authentication layer: Clause 19(c)

Clause 19(c) requires MFA for privileged users accessing critical information systems. Akku enforces MFA at the IAM layer before AkkuReka opens the session proxy connection. The privileged user must authenticate to Akku IAM with MFA before any session to a critical system can open. The MFA event is logged and linked to the subsequent session record, providing the complete authentication-to-session evidence chain that a comprehensive Clause 19 examination requires.

The complete Clause 19 evidence chain

A complete Clause 19 evidence chain for a single privileged session includes: the session request with target system, access level, duration, and justification. The approval record with approver identity and timestamp. The MFA authentication event confirming identity assurance before session open. The session activity recording capturing what occurred during the session. The session close event with duration and termination reason. The credential revocation event confirming that the ephemeral credential is permanently invalidated.

This end-to-end evidence chain is what a rigorous RBI IS audit examination of Clause 19 will look for. Each element satisfies a different component of the clause’s requirements, and all elements are required for a complete response to an examination request.

Diagnostic Questions

For a sample of five privileged sessions to critical systems from the last three months, can you produce the session recording capturing what occurred during each session at the keystroke or query level, not only the authentication record?

Does your monitoring infrastructure provide live visibility into active privileged sessions with session termination capability, or does your monitoring capability rely on retrospective log review?

For every privileged session to a critical system in the last 12 months, is there a corresponding session request and approval record showing the justification for access and the approver’s identity?

Does your session recording coverage extend to all critical systems, including Linux servers accessed via SSH, production databases, and network device management interfaces, or only to systems with web-based management consoles?

Can you produce on demand, for any 90-day period an RBI examiner specifies, a structured export of all privileged session records including session metadata, approval records, and recording availability confirmation?

CTAs

See how Akku’s AkkuReka and SMARTAudit Trails address RBI Clause 19(b) requirements for privileged access supervision and session activity logging.

Book a conversation with the Akku team to assess your current privileged access controls against RBI Clause 19(b)’s supervision and logging standard.

FAQs

What is the specific difference between close supervision under Clause 19(b) and periodic log review?

Close supervision under Clause 19(b) requires real-time visibility into active privileged sessions with the ability to intervene and terminate sessions during their execution. Periodic log review examines completed session records after sessions have closed. The distinction matters because close supervision enables prevention: a suspicious action can be stopped before it completes. Periodic log review enables investigation: it establishes what happened after the fact. Clause 19(b) requires both: real-time supervision during sessions and logged system activities for completed sessions. Periodic log review alone does not satisfy the close supervision component.

Does Clause 19(b) apply only to privileged sessions to core banking systems, or to all privileged access?

Clause 19(b) applies to all privileged users with access to information systems classified as critical under the regulated entity’s IT risk framework. This includes core banking systems, payment processing infrastructure, production databases, network infrastructure management interfaces, and any system whose compromise would have a material impact on operations or data security. The regulated entity must define which systems are critical and ensure that privileged access to all of them falls within the Clause 19(b) supervision and logging perimeter.

What does the reconstruction standard in Clause 19(b) mean for database session logging specifically?

The reconstruction standard requires that the session activity log be sufficient to reconstruct what actions were taken during the session. For database sessions, reconstruction requires knowing which queries were executed, against which tables, at what times, and with what results. A screen recording of a database management client provides visual reconstruction capability. Structured SQL query capture provides searchable, analysable reconstruction capability. An auditor or forensic investigator examining a suspected data access incident needs to search the session logs for all queries against a specific table without reviewing screen recordings manually. Structured query capture satisfies this requirement. Screen recordings alone do not.

How does AkkuReka’s outbound worker architecture address deployment constraints at RBI-regulated entities?

Many RBI-regulated entities operate production systems in network segments with strict inbound firewall policies that prohibit adding new inbound port rules. AkkuReka’s outbound worker model addresses this constraint by deploying a lightweight worker process within the restricted network segment. The worker initiates an outbound TLS 1.3 connection to the Akku cloud, requiring only outbound HTTPS on port 443. No inbound firewall rules are required on the target network or target systems. This deployment model allows AkkuReka to cover critical systems in restricted network segments without requiring changes to inbound firewall policy that security governance would not approve.

What is the relationship between per-session ephemeral credentials and Clause 19(b)’s supervision requirement?

Per-session ephemeral credentials support Clause 19(b)’s supervision requirement by ensuring that every privileged access event routes through the approved session workflow. When no standing credentials exist for target systems, a privileged user cannot open a session outside the AkkuReka proxy and approval workflow. Every privileged access event is necessarily supervised through the monitoring console and recorded through SMARTAudit Trails. If standing credentials existed, a privileged user could potentially connect to target systems directly, bypassing the supervision and recording infrastructure entirely. Per-session ephemeral credentials make this architectural bypass impossible, ensuring complete supervision coverage.

How should a regulated entity handle Clause 19(b) compliance for third-party vendors who require privileged access to critical systems?

Third-party vendor privileged access is subject to the same Clause 19(b) requirements as internal administrator access. Vendor sessions must be brokered through AkkuReka, subject to the formal approval workflow with target system, duration, and justification, and recorded through SMARTAudit Trails. The vendor’s representative is assigned a session-specific identity in Akku IAM for the duration of their engagement. All session records and approval records for vendor access are retained in the same audit trail as internal privileged sessions, providing the same forensic evidence quality for vendor sessions as for internal administrator sessions.