The Reserve Bank of India’s 2023 Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices applies to all RBI-regulated entities: scheduled commercial banks, urban cooperative banks, NBFCs, and payment system operators. It is not a guidance document. It is a mandatory framework with 103 compliance items spanning governance, access controls, audit trails, privileged access management, and teleworking security.
Most IT teams at regulated entities are familiar with the framework at the policy level. Fewer have mapped the specific technical controls each clause requires and assessed whether their current infrastructure produces the evidence an RBI IS audit would expect. An access control policy that states need-based access is required does not satisfy Clause 19(a). A technical implementation of RBAC with structured provisioning records and periodic review evidence does.
This blog covers the RBI framework’s key technical requirements clause by clause, what each clause requires at the implementation level, and how IAM controls address them. All clause references are drawn directly from the RBI 2023 Master Direction and Akku’s RBI compliance mapping documentation, which covers 20 actionable technical clauses across Chapters III, IV, and VI, resulting in 30 total clause mappings across the platform.
The RBI framework contains a significant number of governance, physical security, and IT operations requirements that sit outside the scope of IAM platforms. Board-level IT governance structures, IT risk management frameworks, business continuity planning, and vendor management obligations are not addressed here. What follows covers the IAM-addressable technical controls layer specifically.
The RBI framework establishes governance requirements that create the organisational context within which technical controls operate. Several of these have direct technical implications for identity and access management infrastructure.
Clause 8(c) requires regulated entities to implement controls that ensure only authorised users have access to information systems, and that access rights are commensurate with the user’s role and responsibilities. This is a direct access governance requirement with audit evidence implications.
Clause 9(b) requires effective segregation of duties in IT operations and application development environments. This is not satisfied by a policy stating that SoD is required. It requires a technical enforcement mechanism that prevents conflicting role combinations and detects violations.
Clause 15(a), 15(b), and 15(c) require audit trails that capture system access, data modifications, and security events in a format suitable for forensic investigation and dispute resolution. Clause 15 is one of the most technically demanding requirements in the framework.
Clause 8(c) is addressed through RBAC with structured provisioning workflows. Every access grant must be tied to a role definition, authorised through a documented approval process, and reviewable on demand. Akku’s access governance module produces the provisioning audit trail that Clause 8(c) requires: requester, approver, justification, timestamp, and downstream provisioning confirmation for every access grant.
Clause 9(b) is addressed through the IGA SoD rules engine. The engine defines conflicting role combinations, detects violations continuously across connected applications, and triggers automated remediation workflows. The violation detection log and remediation record constitute the technical evidence of SoD enforcement that Clause 9(b) requires.
Clause 15 is addressed through Akku’s centralised audit log architecture. The audit log captures authentication events, access events, privileged session activity, administrative actions, and policy changes in a structured, append-only, tamper-evident format. Akku’s RBI compliance mapping shows the Audit Logs module addresses seven RBI clauses: 8(c), 15(a), 15(b), 15(c), 25(c), 27(b), and 30(f).
Clause 19 is the most detailed access control provision in the RBI framework. It establishes requirements for need-based access, privileged user supervision, and MFA for critical system access. Each sub-clause has specific technical implementation requirements.
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 must be revoked promptly when the need ends or the user’s role changes.
Clause 19(c) requires multi-factor authentication for privileged users accessing critical information systems. This extends beyond customer-facing authentication to administrator and privileged user access to servers, databases, network devices, and core banking systems.
Clause 20(a) requires that access to information systems be granted through a centralised identity management system. Fragmented identity infrastructure, separate directories and authentication systems per application, does not satisfy this requirement.
Clause 23(a) requires that user access rights be reviewed periodically to ensure they remain appropriate to the user’s current role.
Clause 25(c) requires that all access to critical systems be logged and that logs be retained for a defined period sufficient for forensic investigation.
Clause 19(a) is addressed through RBAC, JIT access for privileged users, and automated lifecycle management. Role definitions determine access scope. JIT access eliminates standing privilege for infrastructure access. Automated deprovisioning ensures access is revoked when roles change or employment ends. The provisioning and deprovisioning audit trail provides the evidence of need-based access management.
Clause 19(c) is addressed through Akku’s Adaptive MFA, which extends authentication assurance to infrastructure sessions through PAM. Every privileged session to SSH servers, RDP hosts, databases, and Kubernetes clusters requires MFA at the IAM layer before the session proxy connection opens. Akku’s RBI mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b).
Clause 20(a) is addressed through Akku’s unified cloud identity store, which serves as the centralised identity source for all connected applications. SSO with a centralised IdP consolidates authentication across cloud SaaS, legacy systems, and custom internal applications into a single identity infrastructure. Akku’s RBI mapping shows SSO and IDP addresses Clause 20(a) and Cloud Directory addresses Clause 23(a).
Clause 23(a) is addressed through access review and re-certification campaigns. Periodic certification requests go to managers and resource owners. Every decision is timestamped and logged. The output is the auditor-ready evidence of periodic access review that Clause 23(a) requires.
Clause 15 sets the evidentiary standard for audit trails at RBI-regulated entities. It is one of the requirements most organisations satisfy at the surface level but fail at the depth level. Logging that authentication events occurred is not the same as logging what happened inside authenticated sessions.
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.
Clause 15(b) requires audit trails that capture data modifications, system configuration changes, and administrative actions with actor identity, timestamp, and before-and-after state where applicable.
Clause 15(c) requires that audit trails be protected against modification, deletion, or tampering. Trails must be retained for a period defined in the regulated entity’s IT policy, and must be available on demand for regulatory examination.
Clause 15(a) is addressed through Akku’s centralised authentication event logging. Every authentication event, successful or failed, produces a structured log record containing actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. This event stream is the foundation of the forensic audit trail Clause 15(a) requires.
For privileged sessions specifically, Clause 15(a) requires more than authentication records. SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka: full screen recordings for SSH and RDP sessions, complete keystroke logs for SSH, and structured SQL query capture for database sessions. This session-level evidence is what makes the audit trail suitable for forensic investigation and dispute resolution as Clause 15 requires.
Clause 15(b) is addressed through Akku’s administrative event logging, which captures role assignments and removals, policy changes, target system additions and removals, user provisioning and deprovisioning events, and approval decisions with approver identity and timestamp.
Clause 15(c) is addressed through the append-only, tamper-evident audit log architecture. Existing records cannot be modified or deleted. Logs are exportable in structured JSON and CSV formats for regulatory submission. API access enables programmatic integration with SIEM and log aggregation platforms.
Clause 19(b) specifically addresses the supervision and monitoring of privileged users. It is the clause that most directly maps to PAM capabilities, and it is frequently the area where regulated entities have the largest compliance gap.
Clause 19(b) requires close supervision of privileged users, with logged system activities sufficient to reconstruct what actions were taken during privileged sessions. The supervision requirement implies real-time visibility into active privileged sessions, not just historical log review.
Clause 19(c) requires MFA for privileged users accessing critical information systems, as noted above.
Clause 23(c) requires that privileged access be restricted to authorised personnel and that privileged sessions be monitored and logged.
Clause 19(b) is addressed through AkkuReka’s session proxy architecture and SMARTAudit Trails. Every privileged session is brokered through AkkuReka. No direct connection between a privileged user and a target system exists outside the proxy. This architectural control ensures that every privileged action is visible to the platform regardless of what the user attempts to do.
Real-time session monitoring allows administrators to view all active privileged sessions from the Akku admin console. Any live session can be terminated instantly. Session termination is recorded in the audit log with actor, timestamp, and reason. This is the “close supervision” capability that Clause 19(b) requires.
AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. The user never sees or types the actual target credential. This eliminates the standing credential risk that makes privileged account compromise the highest-impact attack vector in regulated entity environments.
The session approval workflow provides the authorisation record Clause 19(b) requires. Every privileged session request includes the 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.
Akku’s RBI mapping shows the Privileged Access Manager addresses Clauses 19(b), 19(c), and 23(c).
Clause 20 addresses the security controls required for remote workforce access to information systems. As distributed work has become standard operating practice, the gap between policy-stated remote access controls and technically-enforced ones has become a primary audit focus.
Clause 20(a) requires that remote access to information systems be provided through a secure, centralised authentication mechanism. Fragmented remote access, separate VPN credentials, application-specific passwords, and inconsistent MFA coverage, does not satisfy this requirement.
Clause 20(b) requires MFA for all remote access to critical information systems. This applies to both end users and privileged users accessing systems from outside the corporate network.
Clause 20(c) requires that remote access sessions be logged with sufficient detail to enable identification of the user, the systems accessed, and the actions taken.
Clause 20(d) requires that remote access be restricted to authorised devices and that device compliance be verified before access is granted.
Clause 20(a) is addressed through Akku’s centralised SSO and identity provider infrastructure. All remote access routes through the Akku identity layer, providing a single point of authentication and a single point of audit trail generation regardless of which application or system the user is accessing.
Clause 20(b) is addressed through Adaptive MFA applied to all authentication events, with step-up challenges triggered for access to critical systems. Remote access from unrecognised locations, new devices, or outside normal hours automatically escalates the authentication challenge. Akku’s RBI mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b).
Clause 20(c) is addressed through the centralised authentication event log and session activity logging. Every remote session produces a structured audit record. For privileged remote sessions, SMARTAudit Trails provide protocol-level session recording.
Clause 20(d) is addressed through device-based contextual access controls. Access can be restricted to registered, compliant, or company-owned devices. Unregistered personal devices can be blocked at the access policy layer. Akku’s RBI mapping shows the Mobile Device Manager and GPO Manager address Clauses 20(c), 20(d), 23(d), and 25(b).
Akku’s RBI compliance mapping covers 20 actionable technical clauses from the 2023 Master Direction, resulting in 30 total clause mappings across 12 platform modules. The coverage spans the access control, audit trail, privileged access, and remote access requirements that constitute the IAM-addressable layer of the framework.
The module with the highest clause coverage is Audit Logs, addressing seven clauses: 8(c), 15(a), 15(b), 15(c), 25(c), 27(b), and 30(f). This reflects the central role that structured, tamper-evident audit trail generation plays in RBI compliance. Access Manager addresses five clauses: 10(d), 19(a), 20(a), 23(c), and 25(c). Privileged Access Manager addresses three: 19(b), 19(c), and 23(c). Mobile Device Manager addresses four: 20(c), 20(d), 23(d), and 25(b).
An important note on scope: Akku does not cover all 103 RBI 2023 Master Direction requirements. Many relate to governance, physical security, business continuity, vendor management, and IT operations that are outside the scope of IAM software. Akku implements the critical identity, access, and monitoring controls that support RBI’s baseline cybersecurity expectations. Full compliance requires these technical controls combined with the governance and operational measures that the framework’s remaining clauses require.
Which chapters of the RBI 2023 Master Direction contain the primary IAM-relevant requirements?
Chapters III, IV, and VI contain the primary IAM-addressable requirements. Chapter III covers IT governance and risk management, including access control governance under Clause 8(c) and SoD under Clause 9(b). Chapter IV covers IT operations and covers audit trail requirements under Clause 15 and access controls under Clause 19. Chapter VI covers information and cybersecurity, covering privileged access supervision under Clause 19(b) and remote access controls under Clause 20. Akku’s compliance mapping covers 20 actionable technical clauses across these three chapters.
Does RBI Clause 19(c) require MFA only for customer-facing systems or for internal systems as well?
Clause 19(c) requires MFA for privileged users accessing critical information systems. This applies to internal systems including core banking platforms, database servers, network infrastructure, and any system classified as critical under the regulated entity’s IT risk framework. Customer-facing MFA for internet banking is a separate requirement. Clause 19(c) specifically addresses privileged user authentication to critical backend systems, which is where most regulated entities have an MFA coverage gap.
What is the difference between an audit log and an audit trail under RBI Clause 15?
The RBI framework uses audit trail to describe a record suitable for forensic investigation and dispute resolution. An audit log is a record that an event occurred. An audit trail is a record sufficient to reconstruct what happened: who accessed what system, when, from where, what actions they took, and what the state of the system was before and after. For privileged sessions, this requires session-level recording including keystroke logs and query capture, not authentication timestamps alone. Clause 15’s forensic investigation standard requires the latter.
How does RBI Clause 20 apply to NBFCs and fintechs with fully distributed workforces?
Clause 20 applies to all RBI-regulated entities and is technology-neutral in its requirements. A fully distributed workforce does not exempt an entity from the centralised authentication, MFA, session logging, and device compliance requirements. For entities with no physical office presence, the practical implication is that all access must route through a centralised identity layer with consistent MFA enforcement and unified audit trail generation, regardless of where employees are located or what devices they use.
What evidence does an RBI IS audit expect for Clause 19(b) privileged access supervision?
RBI IS auditors examining Clause 19(b) compliance typically look for evidence of a structured privileged access request and approval process with logged decisions, session recordings or keystroke logs demonstrating that privileged session activity was captured, evidence that privileged credentials are not shared or persistent, real-time monitoring capability for active privileged sessions, and periodic review records showing that privileged access entitlements are certified regularly. Per-session ephemeral credentials, session recordings through SMARTAudit Trails, and a structured JIT access workflow collectively produce this evidence set.
Can a single IAM deployment address both RBI and ISO 27001 requirements simultaneously?
Yes. The overlapping technical controls are substantial. RBI Clause 19(c) and ISO 27001 A.8.5 both require secure authentication for privileged users. RBI Clause 15 and ISO 27001 A.8.15 both require user activity logging beyond authentication records. RBI Clause 19(a) and ISO 27001 A.8.2 both require least-privilege, need-based access for privileged users. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.
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…
ISO 27001:2022 reorganised the Annex A control set from 114 controls across 14 domains to 93 controls across four themes.…
The Insurance Regulatory and Development Authority of India's Information and Cyber Security Guidelines, 2023 apply to all insurers, re-insurers, and…
The Securities and Exchange Board of India's Cybersecurity and Cyber Resilience Framework applies to all SEBI-regulated entities: stock brokers, depository…
Your organisation is likely operating under more than one compliance framework. RBI if you are a bank or NBFC. SEBI…