RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes three distinct requirements across its sub-clauses: need-based access for all users under Clause 19(a), close supervision of privileged users with logged system activities under Clause 19(b), and multi-factor authentication for privileged users accessing critical information systems under Clause 19(c). Each sub-clause has a specific technical implementation requirement that goes beyond policy documentation.
Most RBI-regulated entities have access control policies stating that need-based access is required. Fewer have implemented the technical controls that make need-based access enforceable and auditable. A policy stating that users should only have access to systems required for their role does not prevent a user from accumulating access across role changes. An RBAC implementation with structured provisioning workflows, periodic access reviews, and automated deprovisioning does.
The distinction matters because RBI IS auditors examine technical controls, not policy documents. An auditor examining Clause 19(a) compliance will ask to see the provisioning process, the access review records, and the deprovisioning audit trail for a sample of users. An auditor examining Clause 19(b) compliance will ask to see privileged session recordings, not a policy stating that privileged access is monitored. An auditor examining Clause 19(c) compliance will test whether MFA is enforced at the infrastructure layer, not only at the application login screen.
This blog covers what each sub-clause of Clause 19 requires technically, the evidence an RBI IS audit expects, and how IAM controls address each requirement. All clause references are drawn directly from the RBI 2023 Master Direction and Akku’s RBI compliance mapping documentation.
Clause 19(a) requires that access to information systems be granted on a need-to-know and need-to-do basis. Access rights must be commensurate with the user’s current role and responsibilities. Access that is no longer required must be revoked promptly.
Need-based access requires three technical controls operating together. Role definitions that map each organisational role to the specific systems and functions that role requires. Provisioning workflows that grant access based on role assignment, with additional access requiring a structured request and approval process. Deprovisioning workflows that revoke access automatically when roles change or employment ends.
Without role definitions, access is granted ad hoc and accumulates over time. Without structured provisioning workflows, access grants have no documented authorisation trail. Without automated deprovisioning, access persists beyond the point where the need ends. All three gaps are what Clause 19(a) is designed to close.
The periodic access review requirement implied by Clause 23(a) is the mechanism for detecting entitlement drift: the accumulation of access across role changes that structured provisioning alone cannot prevent. An employee who has changed roles three times over five years may hold access entitlements from each previous role that were never revoked. Access reviews surface these entitlements for certification or revocation.
An RBI IS auditor examining Clause 19(a) compliance typically requests evidence of the access provisioning process including a sample of provisioning records showing requester, approver, justification, and timestamp. They examine deprovisioning records for a sample of departed employees, verifying that access was revoked across all connected systems and that the revocation was timely. They review access review records showing periodic certification or revocation decisions with documented outcomes.
They also examine the current access state of a sample of users, verifying that each user’s entitlements are consistent with their current role. Users holding access to systems unrelated to their current function, particularly former system administrators who have moved to business roles but retain infrastructure access, are a common finding.
RBAC defines access entitlements by organisational role. Every application and system access right is tied to a role definition. Access beyond birthright entitlements requires a structured request and approval workflow, with requester identity, approver identity, justification, and timestamp recorded automatically.
Automated User Lifecycle Management handles role changes and departures. Role changes trigger re-provisioning: access from the previous role is reviewed and where no longer required, removed. Departure triggers automated deprovisioning across all connected applications in a single action, with a timestamped audit record of every account removed.
SCIM-based provisioning synchronises access changes to connected applications automatically. Access review and re-certification campaigns run on a defined cadence, sending certification requests to managers and resource owners with timestamped, logged decisions. Akku’s RBI mapping shows Access Manager addresses Clauses 10(d), 19(a), 20(a), 23(c), and 25(c) across five clause mappings.
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 a session-level logging requirement, not an authentication logging requirement.
Close supervision requires two distinct technical capabilities. Real-time monitoring of active privileged sessions, allowing administrators to observe what privileged users are doing during active sessions and terminate sessions exhibiting suspicious behaviour. Session-level recording of completed sessions, producing a complete record of every action taken during a privileged session that can be reviewed retrospectively for audit and investigation purposes.
Authentication logs satisfy neither requirement. An authentication log confirms that a privileged session occurred, from which IP, at what time, and whether MFA was used. It records nothing about what happened inside the session. For Clause 19(b)’s supervision and logging requirements, session-level recordings including keystroke logs for SSH sessions and SQL query capture for database sessions are the required technical controls.
The approval workflow requirement is the third component. Clause 19(b)’s supervision requirement implies that privileged access is authorised before it is granted. A privileged session that opens without a formal approval record is not supervised in the sense the clause requires. Every privileged session must have a request, an approval decision, a scope definition, and a time limit.
An RBI IS auditor examining Clause 19(b) compliance will request session recordings for a sample of privileged sessions to critical systems. They will verify that the recordings capture session activity at the command or query level, not only screen activity. They will examine the session approval workflow records, verifying that every session in the sample was approved before it opened and that the approval record includes scope and duration.
They will also test real-time monitoring capability by asking administrators to demonstrate live visibility into active privileged sessions and the ability to terminate a session from the monitoring console. An organisation that can produce historical session recordings but cannot demonstrate real-time monitoring capability has a partial Clause 19(b) implementation.
SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka. SSH sessions produce full screen recordings and complete keystroke logs per command. Database sessions produce full screen recordings and structured SQL query capture. RDP sessions produce full screen video recordings at configurable frame rates. All recordings are stored encrypted, indexed for forensic search by timestamp, command string, or SQL query, and accessible for in-browser playback from the Akku admin console.
Real-time session monitoring allows administrators to view all active privileged sessions from the Akku admin console. Any live session can be terminated instantly. Termination is recorded in the audit log with actor, timestamp, and reason.
The session approval workflow produces the authorisation record Clause 19(b) requires. Every privileged session request includes target system, requested access level, duration, and justification. Approval and denial decisions are logged with approver identity and timestamp. No session opens without approval when the workflow is enabled.
AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer, and permanently revoked on session close. The user never sees or types the target credential. This eliminates the shared, persistent credential risk that makes privileged account compromise the highest-impact attack vector in regulated entity environments. Akku’s RBI mapping shows Privileged Access Manager addresses Clauses 19(b), 19(c), and 23(c).
Clause 19(c) requires multi-factor authentication for privileged users accessing critical information systems. This requirement extends beyond customer-facing authentication to administrator and privileged user access to servers, databases, network devices, and core banking systems.
MFA for privileged users must be enforced at the infrastructure layer, not only at the application login screen. An administrator who authenticates to a web-based management console with MFA but can then SSH directly to the underlying server without MFA has partial coverage. The SSH session is the higher-risk access path, and it is the one most commonly left without MFA enforcement.
The critical information systems scope includes core banking platforms, payment processing systems, database servers, network infrastructure management interfaces, and any system classified as critical under the regulated entity’s IT risk framework. MFA enforcement must cover all of these, not only the systems with web-based authentication interfaces.
Step-up authentication for high-sensitivity access reflects the proportionate authentication model that Clause 19(c) implies. A privileged user accessing a development environment carries different risk from one accessing a production core banking system. Step-up authentication escalates the challenge for higher-sensitivity access, applying a more demanding second factor or requiring re-authentication within the session.
An RBI IS auditor examining Clause 19(c) compliance will test MFA enforcement across the full scope of critical systems, not only the systems with visible MFA prompts. They will attempt to identify access paths that bypass MFA, including direct SSH access to servers, database client connections, and network device management interfaces.
They will examine MFA event logs to verify that MFA challenges are consistently enforced and that no privileged sessions to critical systems opened without a successful MFA event preceding them. They will also examine the MFA method used, assessing whether it is phishing-resistant for the highest-privilege accounts.
Akku’s Adaptive MFA enforces authentication assurance at the IAM layer for all connected applications. For privileged infrastructure access, MFA is enforced through PAM before any session proxy connection opens. A privileged user must authenticate to Akku IAM with MFA before AkkuReka opens a session to the target system. This enforcement applies to SSH servers, RDP hosts, MySQL and PostgreSQL databases, Kubernetes clusters, and web applications, covering the infrastructure layer that application-level MFA does not reach.
AI-powered anomaly detection evaluates each authentication event against the user’s behavioural baseline. Access from a new location, a new device, or outside normal hours triggers step-up authentication. This is the proportionate, risk-based enforcement model that Clause 19(c)’s critical systems scope implies.
The authentication event log captures every MFA challenge and outcome with actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and result. This event stream provides the continuous MFA enforcement evidence that an RBI IS audit examines. Akku’s RBI mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b).
Clauses 19(a), 19(b), and 19(c) address different layers of the same privileged access risk. Clause 19(a) controls who gets access and ensures it is appropriate to their role. Clause 19(b) controls what privileged users do once access is granted and ensures it is supervised and recorded. Clause 19(c) controls how privileged users authenticate and ensures identity assurance is strong enough for critical system access.
A regulated entity that satisfies only one or two of these sub-clauses has partial controls. An entity with strong MFA under Clause 19(c) but no session recording under Clause 19(b) can prove who authenticated but not what they did. An entity with session recording under Clause 19(b) but weak access controls under Clause 19(a) has detailed logs of privileged sessions that should not have occurred. All three sub-clauses are required together to constitute a defensible privileged access control posture.
The JIT access model addresses all three sub-clauses simultaneously. JIT access enforces need-based, time-bound access at the session level, satisfying Clause 19(a). The session approval workflow and SMARTAudit Trails enforce supervision and logging, satisfying Clause 19(b). MFA at the IAM layer before any session opens enforces authentication assurance, satisfying Clause 19(c). Per-session ephemeral credentials generated by AkkuArka ensure that no standing credential exists that could be used to bypass the JIT and MFA controls.
For a sample of ten users at your organisation with access to critical information systems, can you produce the provisioning record showing who approved each access grant, the justification, and the timestamp, without manual reconstruction from email history?
When a privileged user accesses a core banking system or production database, is there a session recording capturing every command executed and every query run, not only an authentication log confirming the session occurred?
Does your MFA enforcement cover direct SSH access to servers and database client connections, or only web-based application authentication interfaces?
When a system administrator’s employment ends, does their access to all critical systems, including SSH keys, database credentials, and network device management interfaces, cease within the same business day?
Has your organisation conducted a formal review of privileged access entitlements in the last 12 months, and can you produce evidence of every certification or revocation decision made during that review?
What does need-based access mean technically under RBI Clause 19(a), and how is it different from role-based access control?
Need-based access is the principle that users access only what their current role requires, and that access is revoked when the need ends. Role-based access control is the primary technical implementation mechanism: access entitlements are defined at the role level and assigned to users based on their role. Need-based access goes beyond RBAC by requiring that the role definitions themselves reflect actual operational requirements, that additional access beyond role defaults requires documented justification and approval, and that access accumulated across role changes is reviewed and revoked where no longer needed. RBAC without periodic access reviews and automated deprovisioning does not fully satisfy need-based access.
What is the difference between Clause 19(b)’s supervision requirement and standard privileged access logging?
Clause 19(b) requires close supervision with logged system activities sufficient to reconstruct what actions were taken. Standard privileged access logging typically captures authentication events: who connected, when, from where. Clause 19(b)’s supervision requirement requires session-level recording: what commands were executed in an SSH session, what queries were run in a database session, what actions were taken in an RDP session. Authentication logs satisfy the logging of access events. They do not satisfy the logging of system activities that Clause 19(b) requires.
Does RBI Clause 19(c) require MFA for all users or only for privileged users?
Clause 19(c) specifically requires MFA for privileged users accessing critical information systems. The clause targets the highest-risk access scenario: administrators with elevated permissions accessing the systems most critical to the regulated entity’s operations. Customer-facing MFA for internet banking is governed by separate RBI guidelines. Clause 19(c) is specifically about internal privileged user authentication to backend critical systems, which is where most regulated entities have an MFA coverage gap relative to their application-layer MFA deployment.
What does AkkuArka’s per-session ephemeral credential model mean for RBI Clause 19(b) compliance?
Per-session ephemeral credentials mean that every privileged session uses a unique credential generated at session approval and permanently revoked on session close. No privileged user holds standing credentials to target systems between sessions. For Clause 19(b) compliance, this model eliminates the scenario where a privileged user retains credentials that allow them to access critical systems outside the supervised, logged session proxy. Every privileged access event must occur through AkkuReka, ensuring that session recording and real-time monitoring coverage is complete, with no access paths that bypass the supervision controls.
How often should access reviews be conducted to satisfy RBI Clause 23(a)’s periodic review requirement?
The RBI framework does not specify a defined review frequency for Clause 23(a). The standard interpretation in IS audit practice is that reviews should occur at least annually for all users with access to critical systems, and more frequently for privileged users. Quarterly reviews for privileged access entitlements are common practice at banks and NBFCs seeking to demonstrate robust compliance. The key evidence requirement is that reviews are conducted on a consistent cadence throughout the year, producing documented outcomes at each cycle, rather than a single annual review conducted in the pre-audit window.
Can Clause 19 compliance be satisfied by an on-premises PAM solution, or does it require a cloud-based deployment?
Clause 19’s technical requirements, need-based access, session-level supervision and logging, and MFA for privileged users, can be implemented through either on-premises or cloud-based PAM solutions. The RBI framework is technology-neutral in its requirements. Akku PAM supports both cloud-native SaaS deployment and full on-premises deployment for regulated entities with data sovereignty requirements or private network environments. The deployment model does not affect the compliance coverage. What matters is whether the technical controls satisfy the clause requirements and produce the evidence an IS audit expects.
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…
Introduction Most IT teams at regulated organisations experience compliance audits as events. A notice arrives. A scramble begins. Access records…
Introduction IRDAI ICS Annexure III Item 14 requires that all access to organisational systems be authenticated through a centralised authentication…
Indian companies with EU customers, EU operations, or EU-based employees are subject to the General Data Protection Regulation regardless of…
SOC 2 Type II has become a commercial prerequisite for Indian ITeS and BPO companies serving enterprise clients in North…