Introduction

Zero trust is not a product category. It is an access architecture built on three principles: verify every identity before granting access, enforce least privilege for every access decision, and monitor continuously for anomalies. What makes zero trust relevant to compliance is that every major regulatory framework reviewed in this series, DPDPA, RBI, SEBI CSCRF, IRDAI ICS, ISO 27001:2022, SOC 2 Type II, and GDPR, has arrived at requirements that collectively describe zero trust architecture without using the term.

RBI Clause 19(a) requires need-based access. That is least privilege. RBI Clause 19(c) requires MFA for privileged users. That is verify every identity. RBI Clause 15 requires audit trails for every session. That is monitor continuously. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with resource sensitivity. That is risk-based verification. ISO 27001:2022 A.8.2 requires that privileged access be event-by-event and time-limited. That is JIT access with no standing privilege. DPDPA Clause 8(4) requires that access be limited to authorised purposes. That is least privilege at the data processing layer.

The convergence is not accidental. Regulators across industries and jurisdictions have independently arrived at the same access architecture requirements because the threat model they are responding to is the same: credential compromise, insider access abuse, and entitlement drift are the dominant vectors in the breaches and incidents that drive regulatory action. Zero trust architecture addresses all three.

This blog maps the zero trust principles to the specific regulatory requirements that implement them, explains why compliance frameworks are converging on this architecture, and covers what implementing zero trust means technically for regulated organisations.

Verify Every Identity: How Regulations Implement This Principle

Zero trust’s verify every identity principle requires that every access request be authenticated with assurance proportionate to the sensitivity of the resource, regardless of where the request originates. The implicit trust of the corporate network, where users inside the perimeter were trusted by default, is replaced by explicit verification for every request.

How the frameworks state it

RBI 2023 Master Direction Clause 19(c) requires MFA for privileged users accessing critical information systems. Clause 20(b) requires MFA for all remote access to critical systems. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource. IRDAI ICS Items 52 and 64 require MFA for network device management and critical system access. ISO 27001:2022 A.8.5 requires secure authentication procedures. SOC 2 CC6.1 and CC6.6 require logical access security software and boundary protection. GDPR Article 32(1)(b) and DPDPA Clause 8(5) require appropriate security measures for processing.

What this requires technically

Verify every identity requires adaptive, risk-based authentication that evaluates context at each access event. Device posture, geographic location, IP reputation, time of day, and behavioural baseline are the signals that determine authentication assurance at the point of access. A user accessing from a recognised, compliant device at a normal time from a known location faces a standard authentication challenge. The same user accessing from an unrecognised device, a new country, or at an unusual hour faces an escalated challenge.

This proportionate model is what SEBI CSCRF PR.AA.S7 requires. A uniform MFA enforcement applied identically to all sessions regardless of risk context does not satisfy the proportionality requirement. Adaptive MFA that escalates based on risk signals does.

For infrastructure access specifically, MFA must extend to the protocol layer. SSH sessions to servers, database management connections, and network device management interfaces must be authenticated with the same assurance as application-layer access. The infrastructure layer is where most regulated entities have an MFA coverage gap.

Akku’s Adaptive MFA implements risk-based authentication across all connected applications, with infrastructure-level MFA enforcement through PAM for privileged access scenarios.

Enforce Least Privilege: How Regulations Implement This Principle

Zero trust’s enforce least privilege principle requires that every user, service, and system has access only to what they need for their current, specific task, and that access is removed when the task is complete.

How the frameworks state it

RBI Clause 19(a) requires need-based access: users access only what their role requires. SEBI CSCRF PR.AA.S1 through S9 cover identity management, access provisioning, and least privilege enforcement. IRDAI ICS Item 50 requires access restricted to authorised personnel on a need-to-know basis. ISO 27001:2022 A.5.15 covers access control and A.8.2 requires privileged access to be event-by-event and time-limited. SOC 2 CC6.2 and CC6.3 require formal user registration and access modification based on the system of record for entitlements. DPDPA Clause 8(4) requires that processing be limited to authorised purposes. GDPR Article 25(2) requires data minimisation by default.

What this requires technically

Least privilege at the identity layer requires three controls operating together. Role-based access control that scopes access entitlements to what each role legitimately requires. SoD enforcement that prevents conflicting role combinations from accumulating in a single user. Periodic access reviews that detect and revoke entitlements that are no longer appropriate.

Least privilege for privileged access requires JIT access. No administrator holds standing credentials to servers, databases, or network devices. Access is granted for the duration of an approved, time-bound session and automatically revoked on expiry. This is what ISO 27001 A.8.2’s event-by-event, need-to-use requirement describes. It is also what RBI Clause 19(a)’s need-to-do access framing requires for infrastructure access.

AkkuArka’s per-session ephemeral credentials implement least privilege at the credential layer. Each session uses a unique credential scoped to the access level required for that session’s approved purpose. The credential cannot be reused after the session closes. This is not credential rotation. It is per-session credential lifecycle management that makes standing privilege architecturally impossible.

Contextual access controls add a further least-privilege layer by restricting access based on device compliance, IP range, geographic location, and time of day. An entitlement that is valid for a user’s role may still be blocked if the access context does not satisfy the contextual policy. This is the granular access control that frameworks like SEBI CSCRF PR.AA.S4 and RBI Clause 20 require for remote and distributed workforce access.

Monitor Continuously: How Regulations Implement This Principle

Zero trust’s monitor continuously principle requires that all access activity be logged, that anomalies be detected as they occur rather than discovered in retrospective log review, and that the audit trail be available for investigation at any time.

How the frameworks state it

RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. SEBI CSCRF DE.CM.S1 through S3 require continuous monitoring of system components with automated anomaly detection. IRDAI ICS Item 5 requires user behaviour monitoring to detect anomalies in login time, location, and session duration. ISO 27001:2022 A.8.15 requires logging of user activities and A.8.16 requires monitoring for anomalous behaviour. SOC 2 CC7.2 requires monitoring of system components for anomalies. GDPR Article 32(1)(d) requires regular testing and evaluation of technical security measures.

What this requires technically

Continuous monitoring requires three layers. Authentication event monitoring that detects anomalies at the login layer: MFA failure spikes, geographic anomalies, access outside defined time windows, and new device registrations. Session activity monitoring for privileged access through SMARTAudit Trails: every command, every query, every screen action captured at the protocol layer. Access governance monitoring through the IGA layer: entitlement drift detection through access reviews, SoD violation detection through the rules engine, and dormant account identification through activity monitoring.

The monitoring infrastructure must be active, not passive. Logs that are stored and reviewed periodically do not satisfy DE.CM’s continuous monitoring requirement or A.8.16’s anomaly detection requirement. The monitoring layer must evaluate events against baselines as they occur and generate alerts without waiting for a review cycle.

The audit trail must be tamper-evident and available on demand. SEBI CSCRF GV.OC.S2(G3) requires on-demand log access for SEBI examination. RBI Clause 15(c) requires tamper-protected logs. IRDAI Item 274 requires on-demand evidence production for regulatory examination. An append-only audit log with structured export capability satisfies all three simultaneously.

Why Compliance Frameworks Converge on Zero Trust Architecture

The convergence of compliance frameworks on zero trust architecture reflects the shared threat model that has driven regulatory action across industries and jurisdictions over the last decade.

The shared threat model

The incidents that drive regulatory action have consistent characteristics. Credential compromise through phishing or credential stuffing gives an attacker authenticated access with no visible breach of the perimeter. Insider access abuse exploits legitimate entitlements to access data or systems beyond what the role requires. Entitlement drift creates attack surface as users accumulate access across role changes without systematic revocation. Standing privileged credentials provide persistent access that, once compromised, cannot be revoked without disabling the account entirely.

Zero trust architecture addresses all four vectors: adaptive MFA raises the bar for credential compromise. Least privilege limits the blast radius of insider access abuse. Access reviews detect and remediate entitlement drift. JIT access and per-session ephemeral credentials eliminate standing privilege.

When regulators across different sectors, the RBI, SEBI, IRDAI, ISO, AICPA, and EU data protection authorities, independently arrive at requirements for MFA, least privilege, session monitoring, and access reviews, they are each responding to the same incident patterns in their respective regulated sectors. The technical architecture that addresses those incident patterns is zero trust.

What convergence means for regulated organisations

For organisations subject to multiple compliance frameworks, the convergence on zero trust architecture is a practical efficiency. Implementing zero trust principles satisfies the access control requirements of multiple frameworks simultaneously because the frameworks are describing the same technical architecture in different regulatory language.

An adaptive MFA deployment that satisfies RBI Clause 19(c) simultaneously satisfies SEBI CSCRF PR.AA.S7, IRDAI ICS Items 52 and 64, and ISO 27001 A.8.5. A JIT access implementation that satisfies ISO 27001 A.8.2 simultaneously satisfies RBI Clause 19(a) and SOC 2 CC6.3. A continuous monitoring infrastructure that satisfies SEBI CSCRF DE.CM simultaneously satisfies ISO 27001 A.8.16 and SOC 2 CC7.2.

The efficiency is real and measurable. Akku’s compliance mapping shows 15 DORA articles fully addressed, 41 ISO 27001 clauses mapped, 88 SEBI CSCRF compliance items covered, 79 IRDAI requirements addressed, and 36 GDPR compliance items supported, from a single platform implementing the same zero trust architecture across all frameworks.

The Zero Trust Implementation Stack for Regulated Organisations

Implementing zero trust architecture for a regulated organisation requires five technical capabilities operating together.

Centralised identity and authentication infrastructure with adaptive MFA covering all applications and infrastructure access paths. This is the verify every identity layer. Akku’s unified cloud identity store, SSO, and Adaptive MFA constitute this layer.

Role-based and attribute-based access control with SoD enforcement and contextual access restrictions. This is the enforce least privilege layer for standard access. Akku’s RBAC, ABAC, contextual access controls, and IGA SoD rules engine constitute this layer.

JIT access with per-session ephemeral credentials for privileged infrastructure access. This is the enforce least privilege layer for privileged access. AkkuArka and AkkuReka’s PAM architecture constitute this layer.

Continuous monitoring with anomaly detection at the authentication layer and session activity logging at the privileged access layer. This is the monitor continuously layer. Akku’s Adaptive MFA anomaly detection, SMARTAudit Trails, and identity and access security monitoring constitute this layer.

Automated lifecycle management with access reviews and dormant account controls. This is the continuous access governance layer. Akku’s User Lifecycle Manager, IGA access review campaigns, and automated deprovisioning constitute this layer.

Diagnostic Questions

Does your authentication infrastructure apply risk-based verification for every access request, escalating the challenge based on device posture, location, and behavioural signals, or does it apply uniform MFA regardless of access context?

Do privileged users hold standing credentials to servers and databases that are valid between sessions, or does your architecture ensure that access to critical infrastructure requires a new approval and uses a session-specific credential for every connection?

Does your monitoring infrastructure detect authentication anomalies in real time and generate alerts, or are anomalies discovered during periodic log review after the fact?

Can you produce evidence that access entitlements across all connected systems are periodically reviewed and that entitlements no longer appropriate are revoked, with a structured evidence record for every review cycle?

If a privileged user’s credentials were compromised today, how many systems would the attacker be able to access, and for how long, before the access was detected and revoked?

CTAs

See how Akku implements zero trust access architecture across identity assurance, least privilege enforcement, and continuous monitoring for regulated organisations.

Book a conversation with the Akku team to assess your current access architecture against zero trust principles and the compliance frameworks that require them.

FAQs

What is zero trust architecture, and how does it differ from perimeter-based security?

Perimeter-based security assumes that users inside the corporate network are trusted and that the security boundary is the network edge. Zero trust replaces implicit trust with explicit verification: every access request is authenticated with appropriate assurance, every access decision enforces least privilege, and every session is monitored continuously, regardless of where the request originates. The shift from perimeter to zero trust is driven by the dissolution of the network perimeter through remote work, cloud adoption, and mobile access, combined with the demonstrated failure of perimeter-based models to prevent credential compromise and insider access abuse.

Why are compliance frameworks converging on zero trust architecture if they were written independently?

The convergence reflects the shared incident patterns that drove regulatory action across sectors. Credential compromise, insider access abuse, entitlement drift, and standing privileged credentials are the dominant vectors in the breaches and incidents that regulators in financial services, insurance, data protection, and IT assurance have all observed in their respective regulated populations. The technical architecture that addresses these vectors, verify every identity, enforce least privilege, and monitor continuously, is zero trust. When regulators independently arrive at requirements for MFA, need-based access, session recording, and access reviews, they are each describing the same architecture in their own regulatory language.

Does implementing zero trust architecture require replacing existing IAM infrastructure?

Not necessarily. Zero trust is an architecture achieved through the combination of controls, not a single product replacement. An organisation can extend its existing infrastructure toward zero trust principles by adding adaptive MFA where standard MFA exists, implementing JIT access for privileged users without replacing existing identity infrastructure, adding session activity logging for privileged sessions through a PAM-layer proxy, and implementing automated access reviews through an IGA platform. The transition to zero trust architecture is typically incremental, prioritising the highest-risk access scenarios first.

How does JIT access implement zero trust’s least privilege principle for privileged users?

JIT access means that privileged users hold no standing credentials to target systems. Every privileged session requires a formal approval, uses a session-specific credential generated at approval and revoked at close, and operates within a defined time window. This implements least privilege at three levels simultaneously: the user has no access between sessions, the credential for each session is scoped to the approved purpose, and the session window limits the duration of elevated access. Standing privilege with persistent credentials is the antithesis of zero trust’s least privilege principle. JIT access operationalises the principle for every privileged session.

How does continuous monitoring satisfy the zero trust principle of assume breach?

The assume breach principle in zero trust holds that the network should be monitored as if a breach has already occurred or is imminent. This requires that all activity, not only suspicious activity, be logged and that anomalies be detected and acted upon in real time. Continuous monitoring through authentication event logging, session activity recording, and anomaly detection implements this principle technically. When an anomaly is detected, such as a privileged user accessing an unusual system or executing commands outside their normal pattern, the monitoring infrastructure surfaces it for investigation rather than waiting for an incident report. The audit trail produced by continuous monitoring also satisfies the forensic investigation requirements that RBI Clause 15, SEBI CSCRF PR.AA.S12, and ISO 27001 A.8.15 impose.

Can a single IAM deployment implement zero trust architecture across multiple compliance frameworks simultaneously?

Yes. Zero trust architecture is implemented through the combination of adaptive MFA, RBAC with least privilege enforcement, JIT access with per-session ephemeral credentials, continuous monitoring with anomaly detection, and automated lifecycle management with access reviews. These controls, implemented in a single IAM platform, satisfy the verify every identity, enforce least privilege, and monitor continuously principles simultaneously. Because compliance frameworks have converged on requirements that collectively describe this architecture, a single deployment implementing zero trust principles produces compliance evidence for DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, and GDPR from the same technical foundation.

Introduction

RBI 2023 Master Direction Clause 20 addresses teleworking and remote access security. It is one of the most operationally relevant clauses for regulated entities whose workforce operates in hybrid or distributed modes. The clause establishes four requirements: centralised authentication for remote access under Clause 20(a), MFA for remote access to critical systems under Clause 20(b), session logging for remote access under Clause 20(c), and device compliance verification before remote access is granted under Clause 20(d).

Most regulated entities deployed remote access infrastructure rapidly during the pandemic period and have not fully assessed whether that infrastructure satisfies Clause 20’s technical requirements. VPN connectivity was extended to more staff. Laptop issuance increased. MFA was deployed for internet banking and email access. What many entities did not address systematically is the Clause 20 requirement for centralised authentication covering all remote access paths, device compliance verification before access is granted, and session logging that covers remote access events at the activity level rather than only the connection level.

The distinction between remote access that is operationally functional and remote access that satisfies Clause 20 is the same distinction that runs through the rest of the Master Direction: policy compliance versus technical enforcement. An organisation with a teleworking policy, a VPN deployment, and endpoint security software has the operational infrastructure for remote work. Whether that infrastructure satisfies Clause 20’s centralised authentication, device verification, MFA, and session logging requirements is a separate question.

This blog covers each Clause 20 sub-clause in detail, what it requires technically, the most common implementation gaps, and how IAM controls address each requirement.

Centralised Authentication for Remote Access Under Clause 20(a)

Clause 20(a) requires that remote access to information systems be provided through a secure, centralised authentication mechanism. All remote sessions must authenticate through a single identity layer that applies consistent security controls regardless of which system the user is accessing.

What the clause requires technically

Centralised authentication means that every remote access event, whether the user is accessing a business application, an infrastructure management console, or a cloud-hosted service, routes through the same identity provider with the same authentication policy applied. Fragmented remote access infrastructure where different systems have different authentication mechanisms and different MFA enforcement does not satisfy the centralised requirement.

The centralised mechanism must be secure: it must enforce authentication controls appropriate to the sensitivity of the systems being accessed. A centralised VPN that provides network-level access without application-level authentication controls does not constitute a centralised authentication mechanism for Clause 20(a) purposes. The centralised mechanism must sit at the application and session layer, not only at the network layer.

The most common gap

The most common Clause 20(a) gap is the coexistence of centralised authentication for some systems and direct authentication for others. Cloud SaaS applications route through the centralised IdP. Legacy on-premises systems authenticate directly with Active Directory credentials. Infrastructure management interfaces accept direct SSH key authentication without routing through the centralised identity layer. The result is partial centralisation that does not satisfy the complete coverage Clause 20(a) requires.

How Akku addresses it

Akku’s unified cloud identity store and SSO infrastructure provide the centralised authentication mechanism Clause 20(a) requires. All connected applications, cloud SaaS, legacy on-premises systems through directory integration, and custom internal applications through credential replay, authenticate through Akku’s centralised IdP. Infrastructure access routes through AkkuReka’s session proxy, extending centralised authentication to SSH, RDP, database, and Kubernetes access.

The single identity layer means that every remote access event, regardless of the destination system, generates a record in the same centralised authentication event log. This unified logging is both the centralisation evidence and the session logging evidence Clause 20(c) requires.

MFA for Remote Access Under Clause 20(b)

Clause 20(b) requires MFA for all remote access to critical information systems. The scope covers both end users and privileged users accessing critical systems from outside the corporate network.

What the clause requires technically

MFA must be enforced for every remote access session to a critical information system, not only for sessions flagged as high-risk. The consistent enforcement requirement means that MFA cannot be optional or context-dependent for critical system access from remote locations: every remote session to a critical system must complete MFA before access is granted.

The critical information systems scope under Clause 20(b) follows the same definition as Clause 19(c): systems whose compromise would have a material impact on operations, including core banking platforms, payment processing infrastructure, production databases, and network management interfaces.

For privileged users accessing critical infrastructure remotely, Clause 20(b) and Clause 19(c) overlap: both require MFA for the same access scenarios. The combined requirement means that privileged remote access to critical systems must satisfy both the privileged user MFA standard of Clause 19(c) and the remote access MFA standard of Clause 20(b) simultaneously.

The most common gap

The most common Clause 20(b) gap is inconsistent coverage: MFA is enforced for corporate email and productivity applications but not for remote access to production servers, databases, and network management interfaces. The corporate applications are the ones with web-based logins that were covered when MFA was first deployed. The infrastructure access paths were added to the remote access perimeter without MFA integration.

How Akku addresses it

Akku’s Adaptive MFA enforces authentication for all applications connected to the centralised identity layer. For remote access scenarios, contextual access controls detect that the session originates from outside the corporate network and apply the appropriate challenge. For infrastructure access, PAM-layer MFA enforcement through AkkuReka ensures that every remote SSH, RDP, and database session requires MFA at the IAM layer before the session proxy connection opens.

The consistent coverage across all application and infrastructure access paths is what satisfies Clause 20(b)’s all remote access to critical systems standard.

Session Logging for Remote Access Under Clause 20(c)

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. This is a session activity logging requirement, not only a connection logging requirement.

What the clause requires technically

Connection logging records that a remote session was established: user identity, source IP, target system, connection timestamp, and session duration. Action logging records what happened during the session: commands executed for SSH, queries run for database access, screen activity for RDP.

Clause 20(c)’s identify the user, the systems accessed, and the actions taken standard requires all three dimensions. Identifying the user requires the actor identity in the session record. Identifying the systems accessed requires the target system in the session record. Identifying the actions taken requires session activity logging at the command or query level for privileged access.

For standard end users accessing business applications remotely, application-level activity logs within those applications provide the actions taken dimension. For privileged users accessing infrastructure remotely, there is typically no application-level activity log for direct system connections. SMARTAudit Trails are the control that satisfies the actions taken requirement for remote privileged sessions.

The most common gap

The most common Clause 20(c) gap is the distinction between connection logs and activity logs. VPN logs record that a user connected remotely. Authentication logs record that a user authenticated to a specific application. Neither records what the user did after authentication. For remote privileged sessions to infrastructure systems, the actions taken dimension requires session-level recording.

How Akku addresses it

Akku’s centralised authentication event log satisfies the user identity and systems accessed dimensions for all remote access events. SMARTAudit Trails satisfy the actions taken dimension for remote privileged sessions: SSH keystroke logs, SQL query capture for database sessions, and RDP screen recordings are captured at the protocol layer by AkkuReka regardless of whether the session originated locally or remotely.

The remote access origin is captured in the authentication event record through the source IP and geographic location fields. A remote session produces the same structured, complete session record as a local session, with the remote origin visible in the session metadata.

Device Compliance Verification Under Clause 20(d)

Clause 20(d) requires that remote access be restricted to authorised devices and that device compliance be verified before access is granted. The device verification must be technical, not policy-based: the access control must verify the device’s compliance state and block access from non-compliant or unregistered devices.

What the clause requires technically

Device compliance verification requires integration between the identity layer and the device management layer. When a user attempts remote access, the authentication system must query the device management platform to verify the device’s current compliance state: Is it enrolled in MDM? Is it running an approved operating system version? Is it encrypted? Has it checked in with the MDM platform recently? Only after compliance verification should access proceed.

For corporate-owned devices, enrollment in MDM and compliance with the device policy are the baseline requirements. For BYOD environments, device compliance verification must assess whether the personal device meets the minimum security requirements for remote access to corporate systems.

The verification must occur at each access attempt, not only at enrollment. A device that was compliant at enrollment may have fallen out of compliance through OS updates that break policy, antivirus deactivation, or MDM check-in failures. The at-access verification catches compliance drift that enrollment-time verification misses.

The most common gap

The most common Clause 20(d) gap is certificate-based device verification that checks enrollment but not current compliance state. A device is issued a client certificate at enrollment. The certificate is presented at remote access to confirm the device is enrolled. But the certificate does not reflect the device’s current compliance state: an enrolled device that has not checked in with MDM for 60 days and is running outdated software still presents a valid certificate.

Real compliance verification queries the MDM platform in real time to assess the device’s current state, not only its enrollment status.

How Akku addresses it

Akku’s contextual access controls integrate device compliance verification at the authentication layer. Device-based access restrictions query MDM enrollment and compliance status before access is granted. A device that is not enrolled in Akku MDM or that has failed compliance checks is blocked from accessing in-scope applications regardless of whether the user’s credentials are valid.

MDM device compliance policies cover OS version, encryption status, passcode requirements, MDM check-in recency, and app compliance. A device that fails any configured compliance criterion is flagged non-compliant and blocked from remote access until compliance is restored.

The device compliance check result is logged alongside the authentication event, creating a record showing that compliance verification occurred and what the result was for each remote access attempt. This log is the Clause 20(d) evidence.

Akku’s RBI compliance mapping shows Mobile Device Manager addresses Clauses 20(c), 20(d), 23(d), and 25(b), and GPO Manager addresses the same clauses across the endpoint security layer.

The Complete Clause 20 Implementation

Satisfying all four Clause 20 sub-clauses requires the four controls to operate as an integrated system, not as separate deployments.

Centralised authentication under Clause 20(a) provides the single identity layer that all remote access routes through. MFA under Clause 20(b) enforces authentication assurance at that identity layer for all remote access to critical systems. Session logging under Clause 20(c) captures the complete remote session record, from authentication through to session activity, in the centralised audit trail. Device compliance verification under Clause 20(d) gates access at the identity layer based on real-time device compliance status from MDM.

When these four controls operate together through a single platform, the remote access session produces a complete, structured record: device compliance verified, MFA completed, session authenticated, session activity recorded. This is the evidence chain that an RBI IS audit of Clause 20 expects to find for every remote session to a critical system.

Diagnostic Questions

Does every remote access session to a critical information system route through a centralised identity provider that applies consistent authentication controls, or do some systems accept direct authentication bypassing the centralised layer?

For remote access sessions by privileged users to production servers and databases, is there a session activity recording capturing commands executed and queries run, not only a VPN or authentication log confirming the connection?

Does your device compliance verification assess the device’s current compliance state in real time at each access attempt, or does it verify only that the device is enrolled based on a certificate issued at enrollment time?

Can you produce for any remote access session to a critical system in the last 90 days: the device compliance verification result, the MFA authentication record, the session activity log, and the source network context, all from a single queryable audit trail?

Have you tested whether remote access to critical infrastructure systems, specifically SSH and direct database connections, requires MFA enforcement, or whether these access paths can be established from remote networks without the centralised MFA challenge?

CTAs

See how Akku addresses RBI Clause 20 teleworking and remote access requirements across centralised authentication, MFA enforcement, session logging, and device compliance verification.

Book a conversation with the Akku team to assess your current remote access infrastructure against RBI Clause 20’s technical obligations.

FAQs

Does RBI Clause 20 apply only to employees working from home, or to all remote access scenarios?

Clause 20 covers all remote access to information systems, not only work-from-home scenarios. Remote access includes any access from outside the corporate network: employees working from home, staff travelling and accessing systems from hotels or airports, third-party vendors accessing systems remotely for support or maintenance, and any other access that originates outside the corporate network perimeter. The clause is technology-neutral: it applies regardless of whether remote access is through VPN, direct internet access to cloud-hosted systems, or any other remote connectivity method.

What is the difference between VPN-based remote access and the centralised authentication Clause 20(a) requires?

VPN provides network-level connectivity: it extends the corporate network to the remote device, allowing the device to reach systems on the corporate network. VPN does not provide application-level authentication controls. A user on VPN can still authenticate to individual applications using direct credentials, bypassing any centralised identity provider. Clause 20(a) requires centralised authentication at the application and session layer, not only network-level connectivity. VPN may be a component of the remote access architecture, but it does not substitute for centralised authentication. The centralised identity provider must sit between the remote user and every application or system they access, regardless of whether VPN connectivity is also used.

Does Clause 20(b) require MFA for video conferencing and productivity tools accessed remotely, or only for critical information systems?

Clause 20(b) requires MFA specifically for remote access to critical information systems. The critical information systems definition covers systems whose compromise would have a material impact on operations: core banking platforms, payment processing systems, production databases, and network management infrastructure. Standard productivity tools including email, video conferencing, and document management are not typically classified as critical information systems for Clause 20(b) purposes unless they hold regulated data or are critical to operational continuity. However, MFA for all corporate applications is a security best practice that most regulated entities implement regardless of the specific Clause 20(b) scope.

How does Clause 20(d)’s device compliance requirement apply to BYOD environments where employees use personal devices for remote work?

For BYOD remote access, Clause 20(d) requires that device compliance be verified before access is granted. For personal devices, the compliance baseline must be appropriate to the device type: OS version currency, passcode enforcement, encryption, and MDM enrollment or at minimum a managed work profile on Android devices. Access from personal devices to systems classified as critical should be treated with heightened scrutiny: either requiring higher assurance device compliance or restricting access to a limited subset of functionality through a secure browser with no data download capability. The compliance verification infrastructure must extend to personal devices: a device compliance policy that applies only to corporate-owned devices does not satisfy Clause 20(d) for BYOD environments.

Can a regulated entity satisfy Clause 20 using a cloud-based identity provider, or does the centralised authentication mechanism need to be on-premises?

Clause 20 does not require on-premises deployment of the centralised authentication mechanism. A cloud-based identity provider that routes all remote access authentication through a centralised platform satisfies Clause 20(a)’s centralised mechanism requirement. The RBI framework is technology-neutral on deployment model. The relevant assessment is whether the cloud-based platform provides the required controls: consistent authentication enforcement, MFA, session logging, and device compliance verification. Akku supports both cloud-native SaaS deployment and on-premises deployment for regulated entities with specific data sovereignty or private network requirements.

How does Clause 20’s teleworking security requirement interact with Clause 19’s privileged access requirements for remote privileged sessions?

Clauses 19 and 20 overlap for remote privileged access scenarios. A system administrator accessing a production server from home must satisfy Clause 19(a)’s need-based access requirement, Clause 19(b)’s supervision and logging requirement, Clause 19(c)’s MFA requirement, and Clause 20(a)’s centralised authentication requirement, Clause 20(b)’s remote MFA requirement, Clause 20(c)’s remote session logging requirement, and Clause 20(d)’s device compliance requirement simultaneously. The PAM architecture addresses both clause sets in a single implementation: JIT access satisfies 19(a), SMARTAudit Trails satisfy 19(b) and 20(c), PAM-layer MFA satisfies 19(c) and 20(b), centralised authentication through Akku IdP satisfies 20(a), and MDM device compliance verification satisfies 20(d)

Introduction

The Digital Personal Data Protection Act, 2023 creates technical obligations that require infrastructure changes, not only policy updates. Consent management systems must be built or upgraded. Access controls for personal data systems must be implemented and evidenced. Data Principal rights fulfilment workflows must be operational. Audit trails must be continuous and tamper-evident. None of these are achievable by updating a privacy policy document.

Most IT teams approaching DPDPA compliance face a common challenge: the obligations are clear in principle but the implementation sequence is not. Attempting to implement everything simultaneously produces incomplete results across all areas. A phased approach that prioritises the highest-risk obligations first, builds the foundational technical infrastructure before the dependent controls, and produces auditable evidence at each phase is more effective than a parallel implementation attempt.

This 90-day action plan is structured around three 30-day phases. Phase one builds the foundational access control and identity infrastructure that every other DPDPA technical obligation depends on. Phase two implements consent management and Data Principal rights workflows. Phase three implements audit trail infrastructure, lifecycle management automation, and evidence packaging. The sequence is deliberate: access controls must be in place before consent management can be layered on top, and both must be operational before the audit trail evidence they generate can be packaged for regulatory examination.

All clause references are drawn directly from the DPDPA and Akku’s DPDPA compliance mapping documentation, which covers 24 of the 38 technical compliance items with 33 total clause mappings.

Phase One: Access Controls and Identity Infrastructure (Days 1 to 30)

Phase one addresses the Clause 8(4) and 8(5) obligations: appropriate technical measures to ensure processing is limited to authorised purposes and reasonable security safeguards to prevent personal data breaches. These are the foundational controls that all other DPDPA technical obligations build on.

Priority 1: Centralised identity store and SSO

If your organisation’s applications authenticate through separate credential systems, centralising authentication is the first infrastructure task. Every application that processes personal data must authenticate through a single identity layer. This is not a convenience feature for DPDPA purposes: it is what makes Clause 8(5)’s security safeguard requirement technically implementable at scale.

Actions for days 1 to 10: Inventory all applications that process personal data of Indian residents. Identify which applications authenticate through a centralised IdP and which maintain separate credentials. Prioritise migration to centralised authentication for applications processing the highest volumes or most sensitive categories of personal data.

Priority 2: Role-based access controls for personal data systems

Clause 8(4) requires that processing be limited to authorised purposes. Technically, this means RBAC must define which users can access which personal data systems for which purposes. Every user’s access to personal data systems must be tied to a role definition that reflects their authorised processing activities.

Actions for days 10 to 20: Map each role in your organisation to the personal data systems that role legitimately requires access to. Define RBAC role configurations in your IAM platform reflecting these mappings. Identify users whose current access exceeds what their role requires and initiate access reduction.

Priority 3: Adaptive MFA for personal data system access

Clause 8(5) requires reasonable security safeguards. MFA is the primary authentication security safeguard. For personal data systems, MFA must cover both end-user access and privileged administrator access.

Actions for days 20 to 30: Deploy Adaptive MFA for all applications processing personal data. Extend MFA to infrastructure-level access for administrators with privileged access to personal data systems through PAM. Verify that MFA enforcement is consistent across all covered systems and that the authentication event log is capturing MFA method and outcome per event.

Phase Two: Consent Management and Data Principal Rights (Days 31 to 60)

Phase two addresses the Clause 5 and 6 obligations for consent management and the Clauses 11 through 14 obligations for Data Principal rights. These require a consent management system, not policy documentation.

Priority 4: Consent management infrastructure

Actions for days 31 to 40: Deploy a consent management system capable of maintaining purpose-specific consent records per Data Principal. Configure versioned notice management for each processing purpose for which consent is the lawful basis. Define the consent record data model covering Data Principal identity, processing purpose, notice version, consent timestamp, channel, and withdrawal status.

For organisations with existing consent capture mechanisms, assess whether current records satisfy the Clause 6(7) record-keeping requirement. A database row recording form submission does not constitute a compliant consent record. If current records are insufficient, design a migration or re-consent strategy.

Priority 5: Consent withdrawal workflows

Clause 6(3) requires that withdrawal be as easy as giving consent. Clause 6(4) requires processing cessation on withdrawal.

Actions for days 40 to 50: Implement self-service withdrawal interfaces in every channel where consent was originally captured. Configure automated downstream processing cessation notifications triggered by withdrawal events. Test the end-to-end withdrawal workflow: Data Principal initiates withdrawal, downstream systems receive cessation notification, processing stops, and the withdrawal event is recorded with a timestamp in the consent audit trail.

Priority 6: Data Principal rights fulfilment workflows

Clauses 11 through 14 require operational rights fulfilment infrastructure for access requests, correction and erasure requests, grievance redress, and nomination.

Actions for days 50 to 60: Implement a Data Principal rights submission portal accessible through the same channels as the consent management system. Configure structured request logging with unique reference numbers and timestamps. Build correction and erasure workflows that propagate changes across all connected systems processing the relevant personal data. Implement the grievance submission and response mechanism with documented response records.

Phase Three: Audit Infrastructure, Lifecycle Management, and Evidence Packaging (Days 61 to 90)

Phase three implements the ongoing operational controls and evidence infrastructure that make DPDPA compliance continuous rather than point-in-time.

Priority 7: Privileged access session recording for personal data systems

Clause 8(5) requires security safeguards for personal data systems. For privileged users with direct access to databases and servers holding personal data, session-level recording is the security safeguard that produces the forensic evidence standard required by a regulatory examination.

Actions for days 61 to 70: Deploy AkkuReka’s session proxy for all privileged access to databases and servers holding personal data. Verify that SMARTAudit Trails are capturing SQL query logs for database sessions and keystroke logs for SSH sessions. Confirm that session recordings are stored encrypted and indexed for forensic search.

Priority 8: Automated lifecycle management for personal data access

Clause 8(7)(a) requires erasure when the processing purpose is no longer served. Clause 8(7)(b) requires cessation and erasure on consent withdrawal. Both require automated deprovisioning workflows, not manual offboarding checklists.

Actions for days 70 to 80: Configure automated deprovisioning workflows triggered by employment termination events from HR systems. Verify that deprovisioning propagates to all connected applications processing personal data, with SCIM sync confirmation records for each. Configure dormant account detection with a defined inactivity threshold for accounts with access to personal data systems. Implement access review campaigns for personal data system access on a defined cadence.

Priority 9: Audit trail verification and evidence packaging

Clause 8(4) requires that technical measures be demonstrable. This requires that the audit trail generated by phases one through three is structured, complete, tamper-evident, and producible on demand.

Actions for days 80 to 90: Verify that the centralised audit log captures authentication events, provisioning and deprovisioning events, consent lifecycle events, Data Principal rights request and response events, and privileged session events in a single queryable trail. Test the evidence package assembly: for a sample of Data Principals, verify that the consent record, access record, and any rights exercise records can be produced in structured format without manual compilation. Run a tabletop exercise simulating a Data Protection Board examination request and assess whether the evidence package produced would satisfy the request within 24 hours.

What the 90-Day Plan Does Not Cover

This plan covers the technical and system-driven layer of DPDPA compliance. Several obligations are outside the scope of what any technology platform addresses and must be progressed in parallel through legal and governance workstreams.

Appointment of a Data Protection Officer or consent manager as required under the Act. Data protection impact assessments for high-risk processing activities. Review and update of data processing agreements with Data Processors. Assessment of cross-border data transfer mechanisms for personal data transferred outside India. Board-level governance of the data protection programme. Staff training on DPDPA obligations and data handling procedures.

These workstreams should run concurrently with the technical implementation phases, not sequentially. The technical controls this plan implements are necessary but not sufficient for full DPDPA compliance.

Key Milestones and Evidence Checkpoints

End of Phase One (Day 30): Every application processing personal data authenticates through a centralised identity layer. RBAC role configurations reflect authorised processing purposes. MFA is enforced for all personal data system access. Authentication event logging is producing continuous, structured records.

End of Phase Two (Day 60): A compliant consent management system is operational with versioned notices, purpose-specific records, and self-service withdrawal. Data Principal rights fulfilment workflows are live and producing structured request and response records.

End of Phase Three (Day 90): Automated deprovisioning is triggered by employment termination and consent withdrawal events. Access reviews are running on a defined cadence. Privileged session recordings exist for all database and server access to personal data systems. A complete audit evidence package can be assembled on demand without manual compilation.

Diagnostic Questions

Has your organisation completed an inventory of all applications processing personal data of Indian residents, and do you know which of those applications currently authenticate through a centralised identity layer?

For each processing activity where consent is the lawful basis, does a purpose-specific consent record exist per Data Principal, or does your current system capture a single agreement covering all processing?

If the Data Protection Board requested evidence of your technical security measures for personal data systems today, could you produce structured authentication event logs, access records, and privileged session recordings within 24 hours?

When an employee who had access to personal data systems leaves your organisation, does their access cease automatically across all connected systems within the same business day, with a timestamped audit record of every account removed?

Has your organisation tested the end-to-end Data Principal rights fulfilment workflow, from submission through to correction or erasure propagation across connected systems, with a documented record of the test and its outcomes?

CTAs

See how Akku addresses DPDPA technical compliance requirements across consent management, access controls, lifecycle management, and audit trails.

Book a conversation with the Akku team to assess your current technical posture and plan your DPDPA implementation sequence.

FAQs

What is the most critical DPDPA technical obligation to implement first?

The foundational obligation is Clause 8(4)’s requirement for appropriate technical measures to ensure processing is limited to authorised purposes. Technically, this means centralised authentication and role-based access controls for personal data systems must be in place before consent management or rights fulfilment workflows can be layered on top. Without knowing who can access which personal data systems and under what authorisation, consent management alone does not constitute appropriate technical measures. Access controls are the foundation on which all other DPDPA technical obligations rest.

Does the 90-day timeline apply to all organisations, or does it vary by organisation size and complexity?

The 90-day timeline is a structured framework, not a universal commitment. Larger organisations with complex application landscapes, multiple data processing systems, and large Data Principal populations will require more time for each phase. The sequence of phases is consistent regardless of organisation size: access controls before consent management before audit infrastructure. What varies is the time required within each phase. Organisations with existing centralised identity infrastructure and mature access controls may compress phase one significantly. Organisations building consent management from scratch may require more time in phase two.

What should organisations do about personal data collected before DPDPA came into force?

Clause 5(2) requires that Data Fiduciaries who collected personal data before the Act came into force, without providing a Clause 5-compliant notice, must provide a compliant notice as soon as reasonably practicable and give Data Principals the opportunity to withdraw consent. Technically, this requires identifying which Data Principals’ records were collected under pre-Act processes, delivering a compliant notice to each, and recording their response in the consent management system. This re-consent exercise should be incorporated into phase two of the implementation plan, following deployment of the consent management infrastructure.

How does DPDPA compliance interact with existing ISO 27001 or SOC 2 programmes?

Organisations with existing ISO 27001 or SOC 2 programmes will find substantial overlap with DPDPA’s technical obligations. Clause 8(5)’s security safeguards requirement maps directly to ISO 27001 A.8.5, A.8.2, and A.8.15. Clause 8(4)’s access limitation requirement maps to ISO 27001 A.5.15 and SOC 2 CC6.2 and CC6.3. Organisations that have implemented these controls for ISO 27001 or SOC 2 purposes have already addressed a significant portion of DPDPA’s technical layer. The primary DPDPA-specific addition is the consent management infrastructure under Clauses 5 and 6, which has no direct ISO 27001 or SOC 2 equivalent.

What evidence should organisations be able to produce for a Data Protection Board examination?

A Data Protection Board examination of DPDPA compliance will typically focus on: consent records demonstrating that processing is based on valid consent, access control records showing that personal data access is limited to authorised personnel, deprovisioning records demonstrating that access ceases when the processing purpose is no longer served, Data Principal rights fulfilment records showing that rights exercises were responded to appropriately, and security safeguard records demonstrating that technical measures are implemented and operating. All of these must be producible from structured, queryable systems in a format suitable for regulatory submission, not assembled through manual compilation before the examination.

What is the consequence of not having a compliant consent management system when DPDPA enforcement begins?

Processing personal data without a valid lawful basis under DPDPA is a violation of the Act. Where consent is the intended lawful basis, processing without a compliant consent record means there is no demonstrable lawful basis for the processing. The Data Protection Board can direct the Data Fiduciary to cease processing, impose financial penalties, and require remediation. The absence of a compliant consent management system is not only a technical gap: it is a fundamental lawful basis gap that affects the legality of all processing activities that rely on consent.

Introduction

Multi-factor authentication appears as a requirement in every major compliance framework that applies to Indian organisations. RBI requires it for privileged users accessing critical systems. SEBI CSCRF requires it proportionate to resource sensitivity. IRDAI requires it for network device management and critical system access. ISO 27001:2022 requires secure authentication procedures. SOC 2 requires boundary protection for external access. DPDPA and GDPR require appropriate technical security measures, which regulators and auditors consistently read as including MFA for personal data system access.

The compliance conversation about MFA has matured beyond whether MFA is deployed to whether the deployment satisfies the specific requirement each framework imposes. Most organisations have deployed MFA. The compliance gaps are almost universally in three areas: coverage, proportionality, and evidence.

Coverage gaps exist when MFA is enforced for some access paths but not others. Web-based application login covered, SSH access to the same servers not covered. Customer-facing authentication covered, internal administrator access to production databases not covered. The coverage gap means the MFA deployment satisfies the convenient access paths but misses the high-risk ones.

Proportionality gaps exist when the same MFA method is applied uniformly to all access scenarios regardless of risk. SEBI CSCRF PR.AA.S7 requires authentication commensurate with resource sensitivity. A uniform TOTP deployment applied identically to a document management system and a core banking platform does not satisfy proportionality. Adaptive MFA that escalates the challenge for high-sensitivity access does.

Evidence gaps exist when MFA enforcement operates but the authentication event log does not capture MFA method and outcome per event, or does not cover all access paths. The evidence gap means MFA is enforced in practice but cannot be demonstrated to a compliance auditor.

This blog maps each framework’s MFA requirement to its specific technical standard, identifies the most common deployment gaps, and covers what a compliant MFA implementation must produce as evidence.

MFA Requirements by Framework

RBI 2023 Master Direction

Clause 19(c) requires MFA for privileged users accessing critical information systems. The scope is infrastructure-level: system administrators, database administrators, network engineers, and any role with elevated access to systems classified as critical.

Clause 20(b) requires MFA for all remote access to critical information systems. This extends beyond privileged users to all users accessing critical systems from outside the corporate network.

The most common RBI MFA gap is infrastructure coverage: MFA enforced at the web management console layer but not for direct SSH, database client, and network device CLI access. Clause 19(c)’s critical systems scope covers these access paths, and auditors test them.

SEBI CSCRF

PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource. This is the proportionality requirement: higher-sensitivity resources require stronger authentication. PR.AA.S9 requires MFA for access to sensitive and critical systems.

The most common SEBI CSCRF MFA gap is uniform deployment: MFA is enforced but the same method and challenge intensity applies to all systems regardless of their classification. PR.AA.S7’s proportionality requirement distinguishes a trading platform from an internal wiki. Adaptive MFA that applies risk-based step-up for higher-sensitivity access satisfies this requirement. Uniform MFA does not.

IRDAI ICS

Item 52 requires MFA for managing network devices and for privileged access to critical systems. Item 64 requires MFA for remote access to organisational systems. Item 65 requires MFA for access to critical applications from outside the corporate network. Item 148 requires step-up authentication for high-sensitivity systems.

The most common IRDAI MFA gap is infrastructure scope: Items 52 and 64 specifically reference network device management and privileged infrastructure access, which are frequently left outside MFA enforcement perimeters.

ISO 27001:2022

A.8.5 requires secure authentication procedures. The control requires that authentication be appropriate to the sensitivity of the information and systems being accessed, and that authentication credentials be protected. The proportionality implication of A.8.5 aligns with SEBI CSCRF PR.AA.S7.

The most common ISO 27001 MFA gap is evidence: MFA is enforced but the authentication event log does not capture MFA method and outcome per event in a structured format that certification auditors can examine.

SOC 2 Type II

CC6.1 requires logical access security software and infrastructure. CC6.6 requires boundary protection against threats from outside the system boundary, which covers MFA for external and remote access. The operating effectiveness requirement means MFA enforcement must be continuous and consistently evidenced throughout the audit period.

The most common SOC 2 MFA gap is operating effectiveness evidence: MFA is deployed but the authentication event log has gaps, coverage inconsistencies, or does not capture events from all access paths throughout the audit period.

DPDPA and GDPR

Clause 8(5) of DPDPA and Article 32 of GDPR both require appropriate security safeguards and appropriate technical measures respectively. Neither explicitly mandates MFA. Both create a general security obligation that regulators and auditors consistently interpret as requiring MFA for systems processing personal data, particularly for privileged access.

The most common gap for DPDPA and GDPR purposes is the absence of MFA for privileged access to databases and servers holding personal data, where a single compromised credential provides unrestricted access to the most sensitive data in the organisation.

The Three Deployment Gaps

Coverage gaps

Coverage gaps are the most prevalent and the most consequential. Every access path to a critical or sensitive system that does not route through MFA enforcement is a coverage gap.

Web-based management console access is typically covered. SSH access to the underlying servers that the consoles manage is typically not. Database client connections using native database protocols are typically not. Network device CLI access via SSH or Telnet is typically not. Kubernetes API access via kubectl is typically not.

These uncovered access paths represent the highest-risk privileged access scenarios in most regulated environments. The web console is a monitored, logged interface. A direct SSH connection to the same server bypasses the console’s audit trail entirely and may not enforce MFA.

Closing coverage gaps requires routing all privileged access to critical systems through a PAM session proxy that enforces MFA at the session layer, before any target system connection opens, regardless of the protocol used. This is the only approach that provides coverage completeness across all privileged access paths.

Proportionality gaps

Proportionality gaps exist when the authentication challenge does not scale with resource sensitivity. A user accessing a document management system and a user accessing a core banking platform face the same TOTP challenge. The platforms have vastly different risk profiles, but the authentication assurance is identical.

Frameworks requiring proportionate authentication, specifically SEBI CSCRF PR.AA.S7 and IRDAI Item 148, require that the authentication model distinguish between sensitivity levels. Adaptive MFA satisfies this by evaluating risk signals at each authentication event and escalating the challenge for higher-risk scenarios: more sensitive systems, unusual access contexts, new devices, or anomalous locations.

The practical implementation is not simply applying different MFA methods to different system tiers. It is deploying an authentication layer that evaluates context at each event and applies a proportionate challenge dynamically, covering both the system sensitivity and the access context simultaneously.

Evidence gaps

Evidence gaps exist when MFA enforcement operates but the audit trail does not capture the required information for every event. Specifically: MFA method not recorded in the authentication event log, MFA outcome not recorded per event, authentication events from some access paths not captured in the centralised log, or log retention insufficient to cover the examination period.

For RBI IS audits, auditors request authentication logs and verify that privileged sessions to critical systems were preceded by successful MFA events. If the log does not capture MFA method and outcome per session, the auditor cannot verify MFA enforcement from the log.

For SOC 2 Type II, auditors sample authentication events from across the audit period. If the log has gaps for some access paths or some time periods, the sample will find events with no corresponding MFA record.

The evidence requirement means the authentication event log must capture: actor identity, timestamp, target system or application, MFA method used, MFA outcome, source IP, device identifier, and geographic location, for every authentication event, across every covered access path, continuously throughout the compliance period.

What a Compliant MFA Implementation Produces

A compliant MFA implementation produces three outputs: enforcement coverage, proportionate challenge behaviour, and structured evidence.

Enforcement coverage

All authentication events to critical and sensitive systems route through the MFA enforcement layer, regardless of the protocol used. SSH access, database connections, RDP sessions, Kubernetes API calls, and web application logins all require MFA at the session proxy layer before the target connection opens. No access path to a covered system bypasses the MFA requirement.

Proportionate challenge behaviour

The authentication challenge scales with the risk profile of the access scenario. High-sensitivity systems require stronger second factors or multi-step challenges. Unusual access contexts, new locations, unrecognised devices, or anomalous timing trigger step-up challenges regardless of the system being accessed. Familiar, low-risk access contexts receive the appropriate challenge without unnecessary friction.

Structured evidence

Every authentication event produces a structured log record with all required fields. The record is generated at the time of the authentication event, stored in append-only format, retained for the compliance period, and exportable in structured format for regulatory examination. The log covers all access paths, all systems, and the complete compliance period with no gaps.

Akku’s Adaptive MFA implements all three outputs. Coverage is achieved through the centralised authentication layer that all connected applications route through and through PAM-layer enforcement for infrastructure access. Proportionality is achieved through AI-powered anomaly detection that evaluates risk signals and escalates challenges accordingly. Evidence is produced by the centralised authentication event log that captures all required fields for every event in append-only, exportable format.

Diagnostic Questions

Does your MFA deployment cover direct SSH access to production servers, direct database client connections, and network device CLI access, or only web-based management console authentication?

For your highest-sensitivity systems, specifically core banking platforms, payment infrastructure, and personal data databases, does MFA apply a stronger challenge than for lower-sensitivity internal applications, or is the same method applied uniformly?

Does your authentication event log capture MFA method and outcome per event for every authentication attempt across every covered access path, or are some access paths not reflected in the centralised log?

For any 30-day window chosen at random from the last 12 months, can you produce a structured export of all authentication events showing MFA method and outcome for every event, without manual compilation from individual application logs?

Has your organisation tested MFA coverage by attempting to connect to critical systems using direct protocol access without routing through the centralised MFA enforcement layer, to verify that no access paths bypass the requirement?

CTAs

See how Akku’s Adaptive MFA addresses compliance requirements across RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, DPDPA, and GDPR with coverage, proportionality, and structured evidence.

Book a conversation with the Akku team to assess your current MFA deployment against the specific requirements of the frameworks that apply to your organisation.

FAQs

Why do compliance frameworks require MFA specifically, and what risk does it address?

MFA addresses credential compromise, the most common initial access vector in security incidents. A single compromised password provides unrestricted access to any system the account is entitled to reach. Adding a second factor means that compromised credentials alone are insufficient for access: the attacker also needs the second factor, which requires either physical possession of the user’s device or a separate attack to obtain. For regulated organisations where a single compromised administrator credential could provide access to core banking systems, customer databases, or payment infrastructure, the risk reduction from MFA enforcement is directly proportionate to the access privilege of the protected accounts.

What is the difference between standard MFA and adaptive MFA for compliance purposes?

Standard MFA applies the same second-factor challenge to every authentication event regardless of context. Adaptive MFA evaluates risk signals at each authentication event and escalates the challenge when signals indicate elevated risk. For compliance frameworks that require proportionate authentication, specifically SEBI CSCRF PR.AA.S7 and IRDAI Item 148, standard MFA does not satisfy the proportionality requirement. Adaptive MFA satisfies it by applying stronger challenges to higher-risk access scenarios. For frameworks with a simpler MFA requirement such as RBI Clause 19(c), both standard and adaptive MFA satisfy the requirement, though adaptive provides stronger security posture.

Does deploying MFA for customer-facing applications satisfy the privileged user MFA requirements in RBI and IRDAI?

No. Customer-facing MFA covers authentication for customers accessing their accounts through internet banking or insurance portals. RBI Clause 19(c) and IRDAI Items 52 and 64 cover internal privileged user authentication to backend critical systems. These are separate populations, separate access scenarios, and separate technical requirements. Satisfying customer-facing MFA requirements does not satisfy internal privileged user MFA requirements. Organisations must address both independently.

What MFA methods are phishing-resistant, and when should they be required?

Phishing-resistant MFA methods are those that cannot be intercepted or replayed by an attacker who tricks the user into authenticating to a fake service. FIDO2 hardware security keys and platform authenticators using WebAuthn are phishing-resistant because the authentication is cryptographically bound to the legitimate domain. Push notification MFA and SMS OTP are not phishing-resistant because they can be defeated by real-time phishing attacks where the user is tricked into approving or entering the factor on a fake site. For the highest-privilege accounts with access to core banking and payment infrastructure, phishing-resistant methods are increasingly recommended by RBI IS auditors and align with global best practice for privileged account protection.

How should organisations handle MFA for service accounts that cannot complete interactive authentication challenges?

Service accounts used for automated processes cannot complete interactive MFA challenges because they are not operated by a human who can respond to a step-up prompt. For service accounts, MFA alternatives include certificate-based authentication where the service authenticates with a client certificate stored in a secure vault, API keys with short rotation cycles that provide a credential security equivalent, and network-level access controls that restrict service account connections to specific IP ranges and ports. The appropriate approach depends on the protocol the service account uses. Service accounts with privileged access to critical systems should be governed through the same PAM infrastructure as human privileged users, with their credentials managed in AkkuVault and their access sessions logged.

What evidence should organisations retain to demonstrate MFA compliance across multiple frameworks simultaneously?

A single structured authentication event log covering all authentication events with MFA method, outcome, actor identity, timestamp, source IP, device, and geographic location satisfies the MFA evidence requirements of RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, DPDPA, and GDPR simultaneously. The log must be: complete, covering every authentication event across every covered system; continuous, with no gaps during the compliance period; structured, in JSON or CSV format with consistent field naming; append-only, with tamper-evident integrity; and exportable, producible for any time period within the retention window without manual compilation. A single log with these properties serves every framework’s evidence requirement from one source.

Introduction

GDPR Articles 15 through 22 establish eight rights for Data Subjects. Each right creates a corresponding technical obligation for the controller. The right to access personal data requires a self-service portal or fulfilment workflow capable of producing a structured summary of personal data and processing activities within one month. The right to erasure requires workflows that propagate deletion across every connected system where the Data Subject’s data is held. The right to data portability requires export in a structured, machine-readable format. The right to restriction requires a technical flag that prevents processing without deleting data.

Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice. An organisation that describes its Data Subject rights commitment in a privacy notice but has no technical mechanism for fulfilling an access request within one month has not implemented the right. The supervisory authority will assess whether rights are technically exercisable, not whether they are described in documentation.

The scale problem makes this critical for organisations with large user populations. An organisation processing data for hundreds of thousands of customers cannot fulfil Data Subject rights requests through manual processes within GDPR’s one-month response window. At scale, manual fulfilment is operationally impossible. Technical fulfilment workflows are the only viable approach.

This blog covers what each of the primary GDPR Data Subject rights requires technically, what the fulfilment infrastructure must be capable of, and how each right interacts with the IAM and consent management infrastructure. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.

Right to Access Under Article 15

Article 15 gives Data Subjects the right to obtain confirmation of whether their personal data is being processed and, if so, access to that data and information about the processing.

What Article 15 requires technically

Article 15(1) requires that the controller provide confirmation of processing and, where processing is occurring, access to the personal data being processed, the purposes of processing, the categories of data, the recipients or categories of recipients with whom data has been shared, the envisaged retention period, the existence of other Data Subject rights, the right to lodge a complaint with a supervisory authority, and the source of the data where it was not collected directly from the Data Subject.

Article 15(3) requires that the controller provide a copy of the personal data undergoing processing. The copy must be in a format that the Data Subject can understand.

The one-month response window under Article 12(3) applies: the controller must respond within one month of receiving the request, with a possible extension to three months for complex or numerous requests.

What this requires technically

A self-service access request portal is required for organisations with large user populations. The portal must allow Data Subjects to submit access requests and receive structured responses without requiring manual processing by staff for each request.

The response must be assembled from all systems processing the Data Subject’s personal data. This requires a data mapping that connects the Data Subject’s identity to all systems holding their data, and a query mechanism for assembling the response from those systems.

The recipient disclosure under Article 15(1)(c) requires that the controller maintain a current record of every entity to whom each Data Subject’s personal data has been disclosed. This is a data governance record that must be queryable at the time of an access request.

Akku’s CIAM Consent Manager addresses Article 15(1) and (3) through Data Subject access request workflows, with the consent record providing the processing purpose and recipient information components of the required response.

Right to Rectification Under Article 16

Article 16 gives Data Subjects the right to obtain rectification of inaccurate personal data and completion of incomplete personal data.

What Article 16 requires technically

Rectification requests must update personal data across every connected system where it is held. A name correction applied in the CRM but not in the billing system, the support system, and the marketing platform is an incomplete rectification. The controller must ensure that the correction propagates across all systems holding the relevant personal data.

Article 19 requires that the controller inform each recipient to whom personal data has been disclosed of the rectification, unless this proves impossible or involves disproportionate effort. For organisations using Data Processors who hold copies of the personal data, the notification workflow must reach every processor holding the data that was corrected.

What this requires technically

A rectification workflow must accept the correction from the Data Subject, update the primary record in the relevant system, propagate the correction to all connected systems holding the data, and notify Data Processors of the correction where required.

At scale, this propagation must be automated. A manual process requiring a staff member to update each system individually cannot operate reliably within the one-month response window for high volumes of rectification requests.

Akku’s CIAM Consent Manager and User Lifecycle Manager together address Article 16 through correction workflow capabilities and downstream propagation mechanisms.

Right to Erasure Under Article 17

Article 17 gives Data Subjects the right to erasure of their personal data, the right to be forgotten, under defined conditions including withdrawal of consent, completion of the purpose for which data was collected, and objection to processing.

What Article 17 requires technically

Article 17(1) specifies the conditions under which erasure must be fulfilled: the data is no longer necessary for the purpose for which it was collected, the Data Subject withdraws consent and no other lawful basis applies, the Data Subject objects to processing under Article 21 and there are no overriding legitimate grounds, the data was unlawfully processed, or erasure is required for compliance with a legal obligation.

Article 17(2) requires that where the controller has made personal data public, they take reasonable steps to inform other controllers processing the data of the erasure request.

Article 19 requires notification to recipients of the erasure, as with rectification.

What this requires technically

Erasure workflows must delete personal data from every system where it is held, not only from the primary database. The erasure must be verifiable: the controller must be able to demonstrate that the data was deleted from each system. Where data is held in backup systems, the erasure timeline must account for backup retention cycles and document when backup copies will be overwritten.

The erasure workflow must respect legal retention obligations that may override the erasure right. Where data must be retained for legal compliance, the controller may restrict processing rather than erase, pending the end of the retention period.

Downstream notification to Data Processors and other recipients must be automated for organisations with multiple processors. The notification must include the Data Subject identity and the scope of the erasure so that processors can take corresponding action.

Akku’s CIAM Consent Manager addresses Articles 17(1) and 19 through erasure workflow capabilities. The User Lifecycle Manager addresses Article 17 through automated deprovisioning workflows triggered by consent withdrawal under Clause 8(7)(b) of DPDPA, with equivalent functionality supporting GDPR Article 17 erasure workflows.

Right to Restriction Under Article 18

Article 18 gives Data Subjects the right to restrict processing of their personal data in defined circumstances: the accuracy of the data is contested, the processing is unlawful but the Data Subject prefers restriction over erasure, the controller no longer needs the data but the Data Subject requires it for legal claims, or the Data Subject has objected to processing pending verification of whether the controller’s legitimate grounds override.

What Article 18 requires technically

Restriction of processing means the personal data is retained but processing activities are suspended. The data must be flagged as restricted in every system where it is held. Processing operations that are not permitted during restriction, typically everything except storage, legal claims, protection of rights of another person, or public interest grounds, must be blocked for flagged records.

Restriction is technically more complex than erasure because it requires a persistent flag that modifies the processing behaviour of every system holding the data, rather than simply deleting it. The flag must persist until the restriction is lifted by the Data Subject or until the conditions for restriction no longer apply.

A restriction flag system must be queryable across all connected systems and must prevent processing of flagged records at the application layer.

Right to Data Portability Under Article 20

Article 20 gives Data Subjects the right to receive their personal data in a structured, commonly used, machine-readable format and to transmit that data to another controller.

What Article 20 requires technically

Article 20(1) requires that the controller provide personal data in a structured, commonly used, machine-readable format where processing is based on consent or contract and is carried out by automated means.

The machine-readable format requirement means JSON, CSV, or XML, not a PDF. The Data Subject must be able to use the exported data in another system without manual reformatting.

The portability right applies to personal data provided by the Data Subject: data derived by the controller from the Data Subject’s data is not covered. A customer’s purchase history is portable. Analytics models derived from that history are not.

A self-service data export function that produces machine-readable output covering all in-scope personal data categories is the technical implementation of Article 20. The export must be generated from the controller’s data processing systems and delivered to the Data Subject securely.

Right to Object Under Article 21

Article 21 gives Data Subjects the right to object to processing of their personal data based on the controller’s legitimate interests or for direct marketing purposes.

What Article 21 requires technically

Article 21(1) requires that processing cease when a Data Subject objects, unless the controller demonstrates compelling legitimate grounds that override the Data Subject’s interests or the processing is for the establishment, exercise, or defence of legal claims.

Article 21(2) provides an absolute right to object to processing for direct marketing purposes, with no balancing test required.

What this requires technically

An objection workflow must receive the objection, assess whether compelling legitimate grounds apply for non-marketing processing, suppress the Data Subject’s records from marketing processing immediately and unconditionally, and propagate the suppression to all systems conducting the relevant processing.

The marketing suppression must be immediate and technically enforced. A marketing suppression flag that relies on staff to manually update mailing lists does not satisfy Article 21(2)’s absolute marketing opt-out right.

Akku’s CIAM Consent Manager addresses Articles 21(1) and 21(2) through objection and marketing suppression workflows, with the consent record data model supporting objection status per processing purpose.

The Common Technical Infrastructure Across All Rights

All six Data Subject rights require a common technical foundation: a Data Subject identity verification mechanism at the point of rights exercise, a structured rights submission portal, automated fulfilment workflows for each right type, cross-system propagation mechanisms for corrections and erasures, and an audit trail covering every rights request and fulfilment action.

Identity verification

Before fulfilling any Data Subject rights request, the controller must verify that the requester is the Data Subject or an authorised representative. Insufficient verification creates a risk of inadvertent disclosure to unauthorised parties. Excessive verification creates barriers that effectively deny the right.

The verification mechanism must be proportionate to the sensitivity of the data involved and the nature of the right being exercised. An access request for contact details requires lighter verification than an erasure request for financial records.

Audit trail for rights fulfilment

Every rights request and every fulfilment action must produce a timestamped audit record. The request receipt, the verification outcome, the fulfilment action taken, the systems updated, and the response sent must all be captured in a structured record.

The rights fulfilment audit trail is the evidence a supervisory authority will examine when a Data Subject complains that their rights were not fulfilled. It must demonstrate that the request was received, acted upon within the required timeframe, and fulfilled completely.

Akku’s CIAM Consent Manager produces a structured audit trail for every Data Subject rights exercise event. The audit trail is append-only and tamper-evident, constituting the demonstrability evidence that Article 5(2)’s accountability principle requires.

Diagnostic Questions

Can your organisation fulfil a Data Subject access request by producing a structured summary of all personal data held and all processing activities within one month, without a manual data compilation exercise across multiple system administrators?

When a Data Subject requests erasure, does the deletion propagate automatically to every connected system holding their personal data, and does the controller receive confirmation of deletion from each system?

Does your organisation maintain a restriction processing flag that can be applied to a Data Subject’s records across all connected systems, blocking non-permitted processing activities for flagged records?

Is your data portability export function capable of producing personal data in machine-readable format, covering all in-scope data categories, without requiring staff to manually compile and format the export?

When a Data Subject objects to direct marketing processing, is the suppression applied immediately and automatically across all marketing processing systems, or does it require manual update of individual mailing lists?

CTAs

See how Akku’s CIAM Consent Manager addresses GDPR Data Subject rights requirements across access, rectification, erasure, restriction, portability, and objection workflows.

Book a conversation with the Akku team to assess your current Data Subject rights fulfilment infrastructure against GDPR’s technical obligations.

FAQs

What is the one-month response window under GDPR Article 12, and when does it start?

Article 12(3) requires that the controller respond to Data Subject rights requests without undue delay and in any event within one month of receiving the request. The one-month period begins when the controller receives the request, not when they begin processing it. Where requests are complex or numerous, the controller may extend the period by a further two months, but must inform the Data Subject of the extension and the reasons for it within the initial one-month period. For high-volume organisations, manual fulfilment processes that require days to initiate will frequently fail to deliver responses within the one-month window, making automated fulfilment workflows necessary.

Does the right to erasure under Article 17 apply to all personal data a controller holds, or only to data in primary systems?

The right to erasure applies to all personal data the controller processes, regardless of where it is stored. This includes primary databases, backup systems, archive storage, third-party processors, and any other location where the controller’s personal data exists. For backup systems, erasure may not be immediately executable because backup media cannot always be selectively overwritten. The recommended approach is to maintain a suppression record that prevents the backup data from being restored and used after the erasure request is received, and to document when the backup copies will be overwritten through normal backup rotation. The controller must inform the Data Subject that complete erasure from backup systems will occur at the next backup rotation.

What does machine-readable format mean for Article 20 data portability, and what formats satisfy the requirement?

Machine-readable format means a structured format that can be processed by software without manual reformatting. JSON, CSV, and XML are the formats that satisfy this requirement. A PDF is not machine-readable for portability purposes because it cannot be processed by another system without format conversion. The format must be commonly used, meaning the Data Subject can use standard software to read and transfer the data to another controller. The portability export must cover personal data provided by the Data Subject and processed on the basis of consent or contract by automated means. Derived data, analytics models, and inferred attributes are not covered by the portability right.

How does the right to restriction under Article 18 differ from the right to erasure under Article 17?

Erasure removes personal data from all systems. Restriction retains the data but suspends most processing activities. The Data Subject may prefer restriction over erasure where they need the data for legal claims, where the accuracy is being contested and they want the data retained pending verification, or where the processing is unlawful but the Data Subject prefers to have it restricted rather than deleted. Technically, restriction requires a persistent flag that modifies processing behaviour across all systems holding the data, while erasure requires deletion. Restriction is more technically demanding because it requires ongoing enforcement across all systems, not a one-time deletion action.

What notification obligations arise when a Data Subject exercises erasure or rectification rights under Article 19?

Article 19 requires that the controller inform each recipient to whom personal data has been disclosed of any rectification, erasure, or restriction, unless this proves impossible or involves disproportionate effort. Recipients include Data Processors who hold copies of the data and other controllers to whom the data was disclosed. The notification must include the Data Subject identity and the scope of the rectification, erasure, or restriction so that recipients can take corresponding action. For organisations with multiple Data Processors, the notification workflow must reach every processor holding the relevant data. Manual coordination across multiple processors is not scalable for high-volume rights exercises. Automated notification workflows that propagate rights exercise events to connected processors are required at scale.

Can a single CIAM deployment address both GDPR and DPDPA Data Subject and Data Principal rights requirements simultaneously?

Yes. GDPR Articles 15 through 21 and DPDPA Clauses 11 through 14 share substantial overlapping requirements. Both require self-service access to personal data summaries. Both require correction and erasure workflows that propagate across connected systems. Both require withdrawable consent with automated processing cessation. Both require a rights submission portal with structured request and response records. Akku’s CIAM Consent Manager implements the rights fulfilment infrastructure that satisfies both frameworks from a single deployment. The consent record data model and audit trail architecture are extended to capture the specific fields each framework requires, and the fulfilment workflows handle both GDPR and DPDPA rights exercise events through the same operational infrastructure.

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.

Introduction

The difference between SOC 2 Type I and Type II is not a matter of audit scope or report length. It is a fundamentally different evidentiary standard. Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively throughout a defined period, typically six to twelve months. The shift from design to operating effectiveness changes what evidence is required, how it must be produced, and what constitutes a finding.

Most organisations that struggle with SOC 2 Type II do so because they approach it with a Type I mindset. They document controls thoroughly, configure systems correctly, and produce polished evidence packages. Then the auditor samples from the third month of the period and finds that the provisioning records from that month do not include approval timestamps. Or samples from the seventh month and finds that no access reviews were conducted in that quarter. Or samples from the fourth month and finds a gap in MFA enforcement logs for a critical system.

These gaps do not indicate that the controls are poorly designed. They indicate that the controls did not operate consistently throughout the period. Type II’s operating effectiveness standard is not satisfied by a well-designed control that operated correctly for part of the period. It is satisfied only by a control that operated correctly throughout the period and produced structured evidence of its operation at every point.

This blog covers what operating effectiveness means specifically, how it differs from control design, what the auditor sampling approach reveals about evidence requirements, and how continuous evidence generation from IAM controls satisfies the Type II standard.

What Operating Effectiveness Means

Operating effectiveness is the standard that distinguishes Type II from Type I. Understanding it precisely is necessary for building the evidence infrastructure that satisfies it.

Design versus operation

A control is suitably designed if its design can reasonably be expected to achieve the control objective. For access provisioning, a suitably designed control has a defined approval workflow, documented role definitions, and a provisioning system that connects the two. Type I attests to this design.

A control operates effectively if it consistently achieves the control objective in practice over time. For access provisioning, effective operation means every provisioning event during the period was processed through the approval workflow, every approval record contains the required fields, and every provisioning action was reflected in connected systems. Type II attests to this operation.

The gap between design and operation is common and predictable. A designed control may have a documented exception process that is used too frequently. A provisioning workflow may be bypassed for urgent requests. An access review may be skipped during a busy period. Each of these is a design-operation gap: the control was designed correctly but did not operate consistently.

The continuous operation requirement

Operating effectiveness requires that the control operated throughout the audit period, not only during the periods when the organisation was paying attention. An auditor sampling from twelve equally spaced points across a 12-month period will find any significant operational gaps. A control that operated for ten months and had a two-month gap will be sampled during that gap.

The continuous operation requirement means that the infrastructure generating evidence must itself be continuous. Evidence generated by automated controls is continuous by design: every provisioning event produces a record, every authentication event produces a log entry, every access review decision is timestamped. Evidence generated by manual processes is discontinuous: it exists when someone performed the manual step and is absent when they did not.

What the auditor sampling approach reveals

SOC 2 Type II auditors sample systematically across the audit period. For a 12-month period, they typically examine evidence from at least three to four points spread across the period. For specific controls, they may examine every instance during the period rather than a sample.

The sampling approach is designed to detect operational gaps. An organisation that prepared evidence only for the weeks immediately before the audit will find that auditors sample from periods when no evidence was prepared. The only sustainable response to systematic sampling is continuous evidence generation throughout the period.

IAM Controls That Must Produce Continuous Evidence

Each IAM control relevant to SOC 2 must produce evidence continuously throughout the audit period. The evidence standard for each control is specific.

Provisioning controls: CC6.2

Every user provisioned during the audit period must have a corresponding provisioning record with the complete required fields: requester, approver, approval timestamp preceding provisioning, justification, access scope, and SCIM sync confirmation. The record must exist at the time of the provisioning event, not be reconstructed before the audit.

Auditors sample provisioning events from across the period. A provisioning event from month four with no approval record is a CC6.2 finding regardless of how robust the provisioning process is for other months. The continuous evidence requirement means every event must produce a complete record.

The most common CC6.2 gap is SCIM connector failures that result in provisioning records in the IAM platform without corresponding access grants in connected applications. Connector health monitoring that detects and alerts on sync failures before they persist is the operational control that prevents this gap.

Deprovisioning controls: CC6.3

Every departure during the audit period must have a corresponding deprovisioning record covering every system from which access was removed, with same-day timestamps for employment terminations and SCIM sync confirmations for each connected application.

Auditors examine departures from across the period. A departure in month six where deprovisioning was delayed three days is a CC6.3 finding regardless of how effective deprovisioning was for other departures. The automated deprovisioning workflow triggered by HR system events is the control that produces same-day, complete deprovisioning records consistently throughout the period.

Access review controls: CC6.3

Access reviews must have been conducted on a defined cadence throughout the period, with structured evidence from every cycle. A quarterly review cycle must produce four evidence records per year. An annual review cycle must produce one. Auditors sample from across the period: if only one review occurred in the pre-audit window, samples from earlier in the period find no evidence.

The access review campaign infrastructure must be running throughout the period, not activated in preparation for the audit. Campaigns run on a configured schedule, produce structured records at each cycle, and generate timestamped decision records for every entitlement reviewed.

MFA enforcement controls: CC6.1 and CC6.6

MFA enforcement must be continuous and consistent throughout the period. The authentication event log must show that every session to in-scope systems during the period was preceded by a successful MFA event. Gaps in MFA enforcement, periods where sessions opened without MFA, are CC6.1 and CC6.6 findings.

The most common MFA gap is inconsistent coverage: MFA enforced for some systems or some access paths but not others. Auditors examining MFA enforcement across a sample of sessions will identify paths that bypass MFA. Ensuring that all session paths to in-scope systems route through the centralised MFA enforcement layer, and that the authentication event log covers all paths, prevents this gap.

Anomaly monitoring controls: CC7.2

The anomaly detection infrastructure must have been operating throughout the period, with detection events and investigation records spanning the full period. A monitoring infrastructure deployed in the month before the audit has evidence for one month. Auditors sampling from earlier in the period find no monitoring evidence.

The paradox of anomaly monitoring is that a healthy, well-monitored environment will produce anomaly detection events regularly throughout the period. An organisation that has no anomaly detection events for ten months has either an extremely clean environment or a monitoring infrastructure that is not sensitive enough to detect the anomalies that occur in any active user population. Either way, the absence of detection events raises questions that auditors will examine.

The Continuous Evidence Architecture

Satisfying SOC 2 Type II operating effectiveness requires an evidence architecture that generates structured, complete, tamper-evident records as a byproduct of daily operations, not as a preparation exercise before the audit.

Automated controls over manual processes

Manual processes generate evidence when a human performs a step. They do not generate evidence when the step is not performed. Automated controls generate evidence for every event they process, regardless of whether anyone is watching.

For provisioning, an automated workflow that captures every approval event in a structured record before provisioning executes generates continuous evidence. A manual process where an administrator emails an approval to a colleague generates evidence only when someone remembers to document it.

The shift from manual to automated controls is not primarily a productivity improvement for SOC 2 purposes. It is an evidence quality improvement: automated controls produce consistent, structured, timestamped evidence for every event, while manual processes produce inconsistent evidence that reflects operational attention rather than operational reality.

Centralised audit trail

A centralised audit trail that captures events from all IAM modules, authentication events, provisioning events, access review decisions, privileged session events, and policy changes, into a single queryable record is the infrastructure that makes continuous evidence accessible.

When an auditor samples from the fourth month of the period and requests provisioning records from that window, the centralised audit trail produces the records without requiring manual compilation from multiple systems. The accessibility of evidence is as important as its existence: evidence that exists but requires days to produce from multiple disparate systems does not satisfy the operating effectiveness examination standard.

Append-only integrity

Continuous evidence must be tamper-evident. Evidence that can be modified after the fact cannot satisfy the operating effectiveness standard because its accuracy at any sampled point in time cannot be verified. The append-only audit log architecture, where new records are added but existing records cannot be modified, is the technical basis for tamper-evident continuous evidence.

Common Operating Effectiveness Failures and How to Prevent Them

Understanding the most common operating effectiveness failures helps organisations design controls that avoid them.

Provisioning outside the formal workflow

When urgent access requests bypass the formal approval workflow, the provisioning event may be captured but the approval record is absent or informal. Auditors sampling CC6.2 will identify these instances. The prevention is configuring the approval workflow to handle urgent requests efficiently: auto-approval for low-risk access, rapid-approval paths for time-sensitive requests, and escalation workflows for emergency access, all within the formal process that produces compliant records.

Deprovisioning delays for contractor and project access

Contractor departures and project access expiry frequently produce deprovisioning delays because the trigger mechanism is less formalised than for permanent employee departures. The prevention is configuring time-bound access for all contractor and project entitlements, with automated expiry that produces deprovisioning records without requiring a manual trigger.

Access review cycle gaps

Access review cycles that skip a quarter due to competing priorities produce gaps in the review evidence that auditors will identify. The prevention is configuring the review campaign to run automatically on the defined schedule, not requiring manual initiation. A campaign that runs without administrator activation and escalates non-responses to ensure completion does not depend on anyone remembering to initiate it.

MFA coverage gaps for new systems

When new systems are added to the in-scope environment during the audit period, their authentication events may not route through the centralised MFA enforcement until the integration is completed. If the integration is delayed, there is a period when the new system’s access events are not covered by MFA. Auditors sampling that period will find the gap. The prevention is establishing a policy that new systems cannot be placed in production for in-scope services until MFA integration is complete.

Diagnostic Questions

For any provisioning event from any month in the last 12 months chosen at random, can you produce the complete approval record with requester, approver, approval timestamp preceding provisioning, justification, and SCIM sync confirmation?

For any departure from any month in the last 12 months chosen at random, can you produce the deprovisioning record covering every connected application, with same-day timestamps and SCIM sync confirmation for each?

How many access review cycles ran during the last 12 months, and is there a structured evidence record from each cycle covering every in-scope entitlement?

Can you identify any period in the last 12 months when MFA enforcement had a gap for any in-scope system, and if so, what was the root cause and how was it closed?

If an auditor sampled anomaly detection evidence from month six of your last audit period, would they find monitoring events and investigation records from that month, or would the monitoring evidence begin only in the months immediately preceding the audit?

CTAs

See how Akku generates continuous SOC 2 Type II operating effectiveness evidence across provisioning, deprovisioning, access reviews, MFA enforcement, and anomaly monitoring.

Book a conversation with the Akku team to assess whether your current IAM infrastructure produces the continuous evidence SOC 2 Type II operating effectiveness requires.

FAQs

What is the specific difference between a SOC 2 Type I and Type II audit outcome, and why do enterprise clients prefer Type II?

A SOC 2 Type I report attests that controls are suitably designed at a specific date. It provides assurance that the control framework is appropriate but says nothing about whether controls have been operating consistently. A SOC 2 Type II report attests that controls operated effectively throughout a defined period, typically six to twelve months. Enterprise clients prefer Type II because it provides assurance of consistent control operation over time, not a snapshot. For clients entrusting sensitive data to an ITeS or technology provider, consistent operation over time is what reduces their risk. A provider that has well-designed controls on the day of the Type I audit but operational gaps during the year provides less assurance than a provider with Type II evidence of consistent operation.

What does an SOC 2 Type II auditor mean by sampling, and how does it affect the evidence requirement?

Sampling means the auditor selects specific instances from across the audit period for examination rather than reviewing every instance. For a 12-month audit period with hundreds of provisioning events, the auditor might examine 25 provisioning events spread across the period. If any sampled event lacks a compliant approval record, that event is an exception. The proportion of exceptions in the sample is used to assess whether the control operated effectively throughout the period. Evidence that exists only for a subset of instances, those immediately before the audit, will be underrepresented in the sample relative to their actual frequency, but the auditor will find them if they sample consistently across the period.

How many access review cycles are needed during a 12-month SOC 2 Type II audit period?

SOC 2 does not specify a minimum review frequency. However, the operating effectiveness standard requires that evidence of review operation be available for auditor sampling from across the period. A quarterly review cycle produces four evidence records per year, allowing auditors to sample from multiple points across the period and find evidence at each. An annual review produces one record that covers only one point in time. Most SOC 2 Type II engagements covering a 12-month period treat quarterly access reviews as the standard that demonstrates robust operating effectiveness. Annual reviews are accepted but produce limited operating evidence that requires the auditor to rely heavily on the single available record.

What happens when a SOC 2 Type II audit finds operating effectiveness gaps?

When auditors find operating effectiveness gaps, they record them as exceptions. The impact on the audit report depends on the frequency and materiality of exceptions. Isolated exceptions with clear root causes and remediation plans may result in a qualified opinion with a note. Systemic exceptions indicating that a control did not operate as designed throughout the period may result in a more significant qualification or an adverse opinion on that criterion. For organisations in their first Type II engagement, some exceptions are common as the transition from design to continuous operation reveals gaps in the evidence infrastructure. The key is to have a remediation plan and to demonstrate that the gaps are being closed.

Why does automated control infrastructure produce better operating effectiveness evidence than manual processes?

Automated controls produce evidence as a structural output of their operation: every event processed generates a record, regardless of whether anyone performed a manual step. Manual processes produce evidence only when a human performs the required action and documents it. Under operating effectiveness sampling, auditors examine evidence from randomly selected points across the period. Automated controls have evidence at every point because they operate continuously. Manual processes have evidence only when the manual step was performed: periods where competing priorities delayed the manual step appear as gaps in the sampling. The operating effectiveness standard is most reliably satisfied by controls that generate evidence automatically, without depending on human performance consistency throughout the period.

Can an organisation begin a SOC 2 Type II audit immediately after completing a Type I, or is there a waiting period?

There is no mandatory waiting period between a Type I and the start of a Type II audit period. However, the Type II audit period can only cover time after the controls were in place and operating. If the Type I audit identified gaps that required remediation, the Type II period should begin after remediation is complete and the controls are operating as designed. Starting the Type II period immediately after a Type I audit works only if the controls were already operating effectively before the Type I, and the Type I simply documented their design. For organisations that made significant changes to their control environment to achieve Type I, a period of at least three to six months of operating evidence before beginning a Type II engagement produces a stronger evidence base.

Introduction

IRDAI ICS Annexure III contains detailed endpoint security requirements that are among the most technically specific in the guidelines. Items 11, 15, 28, and 31 address session lockout, removable media controls, peripheral device restrictions, and URL filtering respectively. Together they define an endpoint security baseline that applies to every managed device across the insurer’s environment.

Most insurance IT teams have policies addressing these requirements. Session lockout is documented in the IT security policy. USB use is described as restricted. Bluetooth connections to corporate devices are stated as controlled. URL filtering is listed as a security measure. The compliance gap is almost always between the policy statement and technical enforcement. A session lockout policy that relies on users configuring their own screen saver settings is not a technically-enforced control. A USB restriction policy that requires users to request exceptions is not the same as a GPO that blocks USB storage devices at the operating system layer.

IRDAI IS auditors examining these items assess technical enforcement, not policy documentation. Item 11’s session lockout requirement is examined by testing whether devices actually lock after the defined inactivity period, not by reading the policy. Item 15’s removable media requirement is examined by attempting to connect a USB storage device and verifying it is blocked, not by reviewing the acceptable use policy.

This blog covers what each of the four items requires technically, how GPO Manager and MDM implement the controls, and what evidence each control produces for IS audit examination.

Item 11: Session Lockout Requirements

Item 11 requires automatic session lockout after a defined period of inactivity on managed endpoints. The lockout must be technically enforced, not user-configured.

What Item 11 requires technically

Automatic session lockout requires a centrally-configured policy that applies a screen lock after a defined inactivity timeout. The policy must be enforced at the operating system layer, not relying on users to configure their own lock screen settings. Users must not be able to disable or extend the lockout timeout without administrative approval.

The inactivity threshold must be defined in the IT security policy and technically configured to match. Common thresholds at insurance organisations are five minutes for devices in shared or public areas and ten to fifteen minutes for individual workstations in secure office environments. The threshold should be shorter for devices with access to sensitive customer or policy data.

The lockout must require re-authentication before the session resumes. A screen that locks but can be dismissed without entering credentials does not satisfy the security objective of Item 11. The re-authentication requirement connects Item 11 to the centralised authentication infrastructure: the lockout screen should require the user to re-authenticate through the same identity layer as the initial login.

How Akku addresses it

GPO Manager enforces session lockout policies centrally across Windows, macOS, and Linux endpoints from a single dashboard. The inactivity timeout is configured at the organisational unit or group level, ensuring consistent enforcement regardless of individual user configuration. Users cannot modify the lockout timeout without administrative access to the GPO configuration.

For mobile devices managed through MDM, equivalent passcode lock policies enforce automatic device lock after a defined inactivity period. MDM-enforced passcode requirements ensure that the lock screen requires credential entry to resume the session.

The GPO configuration record constitutes the technical enforcement evidence Item 11 requires. IS auditors examining Item 11 can verify the configured timeout in the GPO policy and test enforcement on a sample of managed endpoints. Akku’s IRDAI mapping shows GPO Manager and MDM together address Item 11 within the combined 31-mapping endpoint security coverage.

Item 15: Removable Media Controls

Item 15 requires controls on the use of removable media including USB storage devices on managed endpoints. The control must prevent data exfiltration through USB storage without authorised exception management.

What Item 15 requires technically

USB storage device restrictions must block the mounting of USB storage devices at the operating system layer. A policy stating that USB storage is restricted does not prevent a user from connecting a USB drive and copying files to it. A GPO that blocks USB storage device class at the driver level prevents the device from mounting regardless of user intent.

The restriction must apply to USB storage specifically. USB peripherals that are not storage devices, keyboards, mice, headsets, and similar devices, should not be blocked unless specific policy requires it. A well-configured USB restriction blocks the USB Mass Storage device class while permitting other USB device classes.

Exception management requires a formal approval process for temporary USB access where legitimate business need exists. The exception must be time-bound, logged, and revoked automatically at expiry. Standing exceptions that persist indefinitely undermine the control.

How Akku addresses it

GPO Manager enforces USB storage restrictions at the operating system layer across Windows, macOS, and Linux endpoints. The USB Mass Storage device class is blocked by default. USB peripherals of other classes continue to function normally. The restriction applies consistently across all managed endpoints in the organisational unit or group the policy targets.

For mobile devices, MDM enforces equivalent data transfer restrictions, blocking file transfer through USB connections and restricting AirDrop and Bluetooth-based file sharing.

The GPO enforcement record and audit log of USB connection attempts provide the IS audit evidence for Item 15. An auditor testing Item 15 compliance by connecting a USB storage device to a managed endpoint will find the device does not mount. Akku’s IRDAI mapping shows Items 15 and 201 among the 31 endpoint-related mappings covered by the combined GPO Manager and MDM module pair.

Item 28: Bluetooth and Peripheral Device Controls

Item 28 requires controls on Bluetooth usage and peripheral device connections to reduce data transfer and unauthorised pairing risks. Insurance environments where agents and intermediaries carry mobile devices create specific Bluetooth risk scenarios that Item 28 addresses.

What Item 28 requires technically

Bluetooth restrictions on managed endpoints must prevent unauthorised device pairing and data transfer through Bluetooth connections. The restriction can be implemented at two levels: disabling Bluetooth entirely on managed endpoints where business need does not require it, or restricting Bluetooth to approved device categories and pairing to pre-approved devices.

For insurance agent environments where mobile devices may need Bluetooth connectivity for legitimate purposes, selective restriction is more operationally viable than blanket disabling. Restricting Bluetooth file transfer while permitting Bluetooth audio and input device connections addresses the data exfiltration risk without blocking legitimate usage.

For workstations in secure data processing environments, complete Bluetooth disabling is the appropriate control. A customer data processing workstation has no legitimate business requirement for Bluetooth connectivity.

Camera and microphone controls, also addressed within the Item 28 context, require restrictions on camera and microphone usage on managed endpoints in sensitive areas. Covert capture through endpoint cameras and microphones is a data security risk in environments processing confidential insurance data.

How Akku addresses it

GPO Manager enforces Bluetooth limitations on Windows, macOS, and Linux endpoints. Bluetooth can be disabled entirely for specific organisational units or restricted to specific permitted device categories. Camera and microphone access can be blocked through GPO controls restricting application access to these peripherals.

MDM enforces equivalent controls on Android and iOS devices. Camera access can be restricted per device or per organisational group. Bluetooth settings can be controlled to prevent file transfer while permitting other Bluetooth usage categories.

The GPO and MDM configuration records, combined with audit logs of policy enforcement events, constitute the IS audit evidence for Item 28. Akku’s IRDAI mapping covers Items 27, 28, 73, 75, 81, and 86 within the endpoint control section of the combined GPO Manager and MDM mapping.

Item 31: URL Filtering Requirements

Item 31 requires URL filtering to restrict access to high-risk or non-business web categories from managed endpoints. URL filtering is a dual-purpose control: it reduces malware exposure from high-risk web categories and prevents data exfiltration through web-based channels including personal cloud storage, personal email, and file-sharing services.

What Item 31 requires technically

URL filtering must be enforced at the DNS or proxy layer, not relying on browser settings that users can modify. DNS-based filtering blocks resolution of domains in restricted categories before any connection is established. This is more robust than browser-level filtering, which can be bypassed by changing browser settings or using an alternative browser.

The filtering must cover the categories that represent the highest risk in an insurance environment. At minimum, this includes malware and phishing domains, personal cloud storage services such as consumer Dropbox and Google Drive personal accounts, personal email services, file-sharing and upload services, and categories associated with policy data exfiltration.

The filtering should produce access attempt logs that record blocked requests with the user identity, the attempted URL or domain, the blocking category, and the timestamp. These logs are both an operational security signal and an IS audit evidence source.

For remote workers accessing the internet from outside the corporate network, URL filtering through a cloud-based DNS filtering service extends the control to off-network endpoints. Corporate network-only filtering leaves remote endpoints unprotected during the majority of their operational time.

How Akku addresses it

GPO Manager implements DNS-based URL filtering across managed endpoints. Category-based filtering blocks domains in configured restricted categories. The filtering applies regardless of which browser the user is using or what browser settings they have configured. For remote endpoints, DNS filtering through the endpoint’s DNS resolver extends the control to off-network access.

In addition to DNS-based category filtering, GPO Manager enforces specific application-level blocks on personal cloud drives, personal email access through browser interfaces, FTP client usage, and upload services. These targeted controls address the specific data exfiltration channels that Item 31 is designed to prevent.

Access attempt logs from the filtering infrastructure record blocked requests with user identity, domain, category, and timestamp. These logs are queryable from the Akku admin console and constitute the IS audit evidence for Item 31 enforcement. Akku’s IRDAI mapping covers Items 31, 44, 107, 185, 193, 194, 197, 216, 217, 261, 280, and 305 within the network and data control section of the combined GPO Manager and MDM mapping.

Why Endpoint Controls Are the Largest Single Coverage Area in Akku’s IRDAI Mapping

GPO Manager and MDM together carry 31 of the 97 total IRDAI control mappings in Akku’s compliance documentation, the highest combined module count. This reflects the IRDAI ICS Guidelines’ detailed and specific endpoint security requirements across session management, peripheral controls, network access, data protection, and device governance.

The 31 mappings span Items 11, 15, 18, 27, 28, 31, 36, 37, 44, 73, 75, 81, 86, 87, 102, 106, 107, 111, 154, 177, 185, 193, 194, 197, 201, 216, 217, 261, 270, 280, and 305. Together these items define the IRDAI ICS endpoint security baseline across device enrollment, session security, peripheral restrictions, data transfer controls, network access governance, and system configuration requirements.

The concentration of IRDAI requirements in the endpoint layer reflects the guidelines’ recognition that insurance environments, particularly those with field agent networks, BYOD programmes, and distributed branch operations, face significant data security risk at the device layer. Controls at the identity and application layer are necessary but not sufficient. Endpoint-level enforcement is required to address the data exfiltration, device compromise, and configuration drift risks that identity controls alone cannot prevent.

Diagnostic Questions

Do managed endpoints in your organisation lock automatically after a defined inactivity period with a centrally-configured GPO policy, or does the lockout rely on individual user screen saver settings?

When a USB storage device is connected to a managed endpoint in your environment, is it blocked at the OS layer by a GPO restricting the USB Mass Storage device class, or is the restriction enforced through a policy statement that users are expected to follow?

Does your URL filtering apply to remote endpoints accessing the internet from outside the corporate network, or only to devices on the corporate network?

Are access attempt logs from URL filtering available for IS audit examination, showing blocked requests with user identity, domain, category, and timestamp, or does the filtering operate without producing queryable logs?

For mobile devices used by insurance agents and intermediaries, do MDM policies enforce the same data transfer and peripheral controls as GPO policies on corporate workstations, or are mobile endpoints subject to weaker controls?

CTAs

See how Akku’s GPO Manager and MDM address IRDAI ICS endpoint security requirements across session lockout, removable media, peripheral controls, and URL filtering.

Book a conversation with the Akku team to assess your current endpoint security posture against IRDAI ICS Annexure III requirements.

FAQs

What is the difference between a policy-stated USB restriction and a technically-enforced USB restriction for IRDAI Item 15 purposes?

A policy-stated restriction is a document stating that USB storage devices should not be used without authorisation. It relies on user compliance and manual enforcement. A technically-enforced restriction is a GPO that blocks the USB Mass Storage device class at the operating system driver layer, preventing any USB storage device from mounting regardless of user intent. IRDAI IS auditors examining Item 15 test technical enforcement, not policy existence. They connect a USB storage device to a managed endpoint and verify it does not mount. A policy document does not prevent the device from mounting. A GPO does.

Why does Item 31 require DNS-based URL filtering rather than browser-level filtering?

Browser-level filtering can be bypassed by changing browser settings, using an alternative browser, or using a browser extension that overrides filter settings. DNS-based filtering operates below the browser layer: it blocks the DNS resolution of restricted domains before any TCP connection is established, regardless of which browser or application initiates the request. This makes DNS-based filtering significantly more robust against user circumvention. For insurance environments where data exfiltration risk through web channels is a compliance concern, DNS-based filtering is the technically appropriate implementation of Item 31’s URL filtering requirement.

How should insurance organisations handle legitimate business exceptions to USB storage restrictions under Item 15?

Legitimate business exceptions to USB storage restrictions require a formal approval process documented in IT security policy. The exception must specify the user, the device, the business justification, and the time period. The exception should be implemented as a time-bound GPO exception for the specific device or user rather than a blanket policy relaxation. The exception request, approval decision, implementation, and expiry must all be logged. IS auditors examining Item 15 will look for evidence that exceptions are governed through a formal process, not informally granted. Uncontrolled exception proliferation that effectively negates the USB restriction control is a finding.

Does Item 28’s Bluetooth restriction apply to all managed devices or only to devices in specific risk categories?

IRDAI ICS Item 28 applies to managed endpoints without specifying a subset. The practical implementation should be risk-stratified: devices in secure data processing environments handling confidential policyholder data should have Bluetooth disabled entirely. Devices used by field agents and intermediaries may permit Bluetooth for legitimate operational purposes such as connecting to printers or headsets, with file transfer capabilities restricted. MDM and GPO allow organisational-unit-level policy assignment, enabling different Bluetooth restriction levels to be applied to different device populations based on their risk profile and operational requirements.

How does Akku’s GPO Manager differ from Microsoft’s Group Policy for IRDAI compliance purposes?

Microsoft’s Group Policy is designed for Windows Active Directory environments. It provides endpoint policy management for Windows-domain-joined devices but requires Active Directory infrastructure and does not natively extend to macOS, Linux, or mobile devices. Akku’s GPO Manager is platform-agnostic and cloud-delivered. It applies consistent policies across Windows, macOS, and Linux endpoints from a single dashboard without requiring Active Directory infrastructure. For insurance organisations with mixed-OS environments or those that have migrated away from on-premises Active Directory, Akku’s GPO Manager provides the same endpoint policy enforcement capability across the full device estate. For IRDAI compliance purposes, the platform-agnostic coverage is significant because Items 11, 15, 28, and 31 apply to all managed endpoints regardless of operating system.

Can GPO Manager and MDM controls satisfy both IRDAI ICS and SEBI CSCRF endpoint security requirements simultaneously?

Yes. IRDAI ICS Items 11, 15, 28, and 31 and SEBI CSCRF PR.AA.S15, PR.DS.S1 to S3, and PR.DS.S4 address overlapping endpoint security requirements including session lockout, removable media controls, peripheral restrictions, and data transfer controls. The same GPO Manager and MDM configuration that enforces IRDAI Item 15’s USB storage restriction simultaneously satisfies SEBI CSCRF PR.DS.S1 to S3’s data protection requirements. Akku’s GPO Manager and MDM carry 31 IRDAI mappings and 21 SEBI CSCRF mappings respectively, reflecting the substantial overlap between the two frameworks’ endpoint security requirements. A single endpoint policy configuration satisfies both frameworks from the same technical control.

Introduction

IRDAI ICS Annexure III Item 5 requires that user behaviour monitoring be implemented to detect anomalies in login time, login location, session duration, and access patterns, with alerts generated when behaviour deviates from established baselines. This is not a log storage requirement. It is an active detection requirement: the monitoring infrastructure must evaluate behaviour continuously against baselines and surface deviations for investigation without waiting for an administrator to manually review log files.

Most insurance IT environments have authentication logging in place. Every login attempt is recorded. Failed authentication events are captured. The gap Item 5 addresses is the layer between logging and detection: the analysis that converts a stream of login events into an alert when a specific event deviates from the established pattern for that user.

An authentication log containing a login from a new country at 3 AM is indistinguishable from a normal login without the baseline context. The event has the same format as every other successful login. Without anomaly detection that compares the event against the user’s historical access pattern, the anomaly exists in the log but is invisible to the monitoring team until they are specifically looking for it. By then, the attacker who used compromised credentials may have had hours of undetected access.

Item 5’s detection requirement is what turns passive logging into active security monitoring. This blog covers what Item 5 specifically requires, what baselines must cover, how detection thresholds must be configured, and how Akku’s Adaptive MFA implements the requirement.

What Item 5 Requires

Item 5 is within the audit trail and monitoring section of the IRDAI ICS Annexure III checklist. It requires user behaviour monitoring with anomaly detection and alert generation.

Baseline establishment

Anomaly detection requires a baseline against which current behaviour is compared. Item 5’s requirement for detecting anomalies in login time, location, and access patterns implies that baselines must cover at least these dimensions.

Login time baseline: the typical hours during which a user authenticates, derived from historical authentication events. A user who routinely logs in between 9 AM and 6 PM has a login time baseline. A login at 2 AM is a deviation from this baseline.

Login location baseline: the geographic locations from which a user typically authenticates, derived from IP geolocation of historical authentication events. A user who routinely authenticates from Mumbai and occasionally from Delhi has a location baseline. A login from a European IP address is a deviation.

Access pattern baseline: the applications and systems a user typically accesses during sessions, derived from session event logs. A user who routinely accesses the claims processing system and the policy administration system but not the financial reporting system has an access pattern baseline. Accessing the financial reporting system for the first time is a deviation worth examining.

Session duration baseline: the typical length of a user’s sessions for each application, derived from session start and end timestamps. A session significantly longer than the user’s historical average may indicate an automated process using the user’s credentials rather than interactive use.

Alert generation

Item 5 requires that alerts be generated when behaviour deviates from baselines. The alert generation requirement distinguishes anomaly detection from anomaly logging. A system that logs every authentication event with its contextual details but requires an administrator to review logs to identify anomalies is not generating alerts. An alert is a proactive notification that a specific event warrants investigation, generated automatically when the deviation threshold is crossed.

Alerts must be actionable. They must contain sufficient context for an administrator to assess the severity and initiate investigation: the user identity, the anomalous event, the baseline against which it was compared, the deviation magnitude, and a risk assessment.

Alert investigation and response

Item 5’s detection and alert requirement implies a response process. Generated alerts that are not investigated fail to satisfy the monitoring objective. The monitoring infrastructure must support an investigation workflow: alerts are reviewed, assessed as genuine anomalies or false positives, and actioned accordingly. The investigation and response must be documented.

Dimensions of User Behaviour Monitoring

Implementing Item 5 requires monitoring across multiple behavioural dimensions. Each dimension requires its own baseline model and deviation detection logic.

Geographic anomaly detection

Geographic anomaly detection identifies authentication events from locations inconsistent with the user’s established pattern. The most straightforward geographic anomaly is an authentication from a country where the organisation has no operations and the user has no travel history.

Impossible travel is a specific geographic anomaly that requires no baseline comparison: two authentication events for the same user from geographically distant locations within a timeframe that makes physical travel impossible indicate either credential sharing or account compromise. A login from Chennai at 10 AM and a login from London at 11 AM for the same user is an impossible travel event regardless of the user’s baseline.

For insurance environments where field agents and branch staff may access systems from multiple locations, the baseline must accommodate legitimate geographic variation. An agent who regularly accesses systems from Mumbai, Pune, and Nashik has a multi-location baseline. An authentication from London is still anomalous for this agent. Geographic anomaly detection must distinguish between the variability within an established pattern and genuine deviations from it.

Time-of-day anomaly detection

Time-of-day anomaly detection identifies authentication events at hours inconsistent with the user’s established access pattern. For most insurance staff, legitimate access occurs during business hours with occasional after-hours access during peak periods. Authentication at 3 AM for a standard business user is an anomaly worth investigating.

For systems with defined permitted access hours, time-of-day anomaly detection is complemented by policy enforcement: access outside permitted hours is blocked, not merely flagged. The combination of policy enforcement for high-sensitivity systems and anomaly detection for standard systems provides layered coverage.

Device anomaly detection

Device anomaly detection identifies authentication events from devices not previously associated with the user account. For organisations with MDM-enrolled corporate device fleets, authentication from an unrecognised device is a significant signal: it may indicate credential compromise or an employee using personal device access that violates the device policy.

For organisations with BYOD policies, the device baseline must accommodate multiple registered devices per user. Authentication from a device outside the registered set is the anomaly, not authentication from any unrecognised device if BYOD is permitted.

Access pattern anomaly detection

Access pattern anomaly detection identifies when a user accesses systems or performs actions inconsistent with their established pattern. A claims processor who accesses the underwriting system for the first time, a customer service agent who accesses bulk data export functions, or a standard user who begins accessing administrative functions they have never previously used are all access pattern anomalies.

For insurance environments processing sensitive policyholder data, access pattern anomalies at the system and function level are particularly significant. An insider threat scenario where a departing employee accesses and exports customer data before their departure date produces access pattern anomalies, not geographic or time anomalies, because the access occurs from a normal location at a normal time using the employee’s legitimate credentials.

How Akku’s Adaptive MFA Implements Item 5

Akku’s Adaptive MFA implements Item 5’s user behaviour anomaly detection requirement through AI-powered analysis at the authentication layer.

Continuous baseline evaluation

Every authentication event is evaluated against the user’s behavioural baseline covering geographic location, device identity, time of day, and access patterns. The baseline is built from historical authentication events and updated continuously as the user’s legitimate access patterns evolve.

The AI-powered analysis compares each new authentication event against the baseline across all dimensions simultaneously. A single deviation may warrant a step-up challenge. Multiple concurrent deviations warrant a higher-risk assessment and may trigger blocking or immediate administrator alert.

Risk-based step-up authentication

When an authentication event deviates from the baseline, Akku’s Adaptive MFA applies a risk-proportionate response. Low-severity deviations, such as authentication from a previously unseen IP within the same city, trigger a step-up MFA challenge: the user must complete an additional factor before access is granted. High-severity deviations, such as impossible travel or authentication from a high-risk IP reputation, may trigger session blocking pending administrator review.

The step-up authentication response is both a security control and an Item 5 compliance mechanism. It generates an alert in the form of the step-up event, documents the deviation that triggered it, and records the outcome. Every step-up event is logged in the audit trail with the triggering signals, the risk assessment, the factor required, and the resolution.

Alert generation and investigation interface

Risk and audit dashboards in the Akku admin console surface anomaly events as actionable alerts. Geographic anomaly alerts, impossible travel detections, new device access events, MFA failure spikes, and access outside permitted hours are presented as prioritised items requiring investigation.

Each alert contains the user identity, the anomalous event details, the baseline comparison, and the risk assessment. Administrators can access the full authentication event context from the alert, initiate investigation, and record the resolution in the audit trail.

The alert generation and investigation interface satisfies Item 5’s requirement that monitoring produces actionable alerts, not passive log storage.

Audit trail of anomaly detection events

Every anomaly detection event, step-up challenge, block action, and alert resolution is recorded in Akku’s append-only audit log with timestamps. The continuous stream of anomaly detection events throughout the compliance period constitutes the operating evidence that Item 5 requires.

For IS audit examination, the anomaly detection event log demonstrates that the monitoring was active throughout the examination period, that deviations were detected and alerted, and that alerts were investigated and resolved. The absence of any anomaly detection events during a 12-month period would indicate that the detection is either not deployed or not sensitive enough to detect the deviations that occur in any active user population.

Distinguishing Item 5 from Standard Authentication Logging

Item 5 is frequently confused with standard authentication logging because both involve authentication events. The distinction is what happens to the events after they are recorded.

Authentication logging records events in a structured format for future retrieval and review. The logged events are available for manual inspection and forensic investigation but are not evaluated against baselines in real time. An authentication from an unusual location is logged identically to a normal authentication.

Anomaly detection evaluates events against baselines as they occur and generates alerts when deviations exceed configured thresholds. The anomalous authentication from an unusual location generates an alert immediately, before any investigation is required. The detection is automated and continuous, not dependent on manual log review.

Item 5 requires the latter. Standard authentication logging is a prerequisite for anomaly detection but does not satisfy the detection and alert generation requirement by itself.

Diagnostic Questions

Does your authentication infrastructure evaluate each login event against a user-specific behavioural baseline covering location, device, time, and access patterns, or does it log events without baseline comparison?

When a user authenticates from a new country or at an unusual hour, is an alert generated automatically and presented for investigation, or is the deviation only discoverable through manual log review?

Does your monitoring infrastructure detect impossible travel events, where the same user account has authentication events from geographically distant locations within an impossible timeframe, and generate immediate alerts?

For anomaly alerts generated in the last 12 months, is there a documented investigation record for each alert showing that it was reviewed, assessed, and either investigated or cleared with a rationale?

Does your anomaly detection cover access pattern deviations, where a user accesses systems or functions they have not previously accessed, or only geographic and time-of-day deviations?

CTAs

See how Akku’s Adaptive MFA addresses IRDAI Item 5 user behaviour anomaly detection requirements through continuous baseline evaluation, risk-based step-up authentication, and alert generation.

Book a conversation with the Akku team to assess your current monitoring infrastructure against IRDAI ICS Item 5’s detection and alert requirements.

FAQs

What is the difference between user behaviour analytics and the anomaly detection Item 5 requires?

User behaviour analytics is a broad category covering statistical analysis of user activity patterns to detect insider threats, data exfiltration, and account compromise. It typically operates on large datasets across multiple data sources including network traffic, file access logs, and application event logs. Item 5’s anomaly detection requirement is more focused: it requires detection of anomalies in login time, login location, session duration, and access patterns with alert generation. This is achievable through authentication-layer anomaly detection without the full data lake infrastructure that enterprise UBA platforms require. Akku’s Adaptive MFA implements the authentication-layer anomaly detection that Item 5 requires without requiring a separate UBA deployment.

How should organisations set anomaly detection thresholds to balance sensitivity and false positive rates?

Threshold calibration is iterative. Initial thresholds should be conservative, generating alerts only for the most unambiguous anomalies such as impossible travel and authentication from countries where the organisation has no operations. As the monitoring programme matures and administrators build experience distinguishing genuine anomalies from false positives, thresholds can be refined. Thresholds that generate too many false positives create alert fatigue, leading to genuine anomalies being dismissed alongside false positives. Thresholds that are too permissive miss genuine anomalies. The threshold review process should be documented and conducted at least quarterly, with adjustments recorded alongside the rationale.

Does Item 5 require user behaviour monitoring for all users or only for privileged users?

Item 5 applies to user behaviour monitoring broadly, not only for privileged users. The login time, location, and access pattern monitoring requirements cover the full user population. For insurance organisations, this includes field agents, branch staff, and business users, not only IT administrators. In practice, the detection sensitivity and alert prioritisation should be tiered by user risk profile: privileged users with access to critical systems warrant more sensitive detection and faster alert response than standard business users. But the monitoring infrastructure must cover all users to satisfy Item 5’s requirements.

How does Akku handle impossible travel detection for users who legitimately travel frequently?

Frequent travellers present a calibration challenge for impossible travel detection. An executive who travels internationally multiple times per month may have authentication events from different countries within short timeframes that are legitimate. The impossible travel detection must distinguish between physically possible travel, even if unusual, and physically impossible authentication sequences. The threshold for impossible travel should be calibrated to the minimum travel time between the two locations. Authentication events separated by more than the minimum travel time are physically possible and should not trigger impossible travel alerts, even if the route is unusual. Events separated by less than the minimum travel time are impossible regardless of the user’s travel history.

What investigation record is required for anomaly alerts under Item 5, and how should it be structured?

An anomaly alert investigation record must document: the alert details including user identity, anomalous event, and detection timestamp. The investigation action taken: whether the administrator contacted the user, reviewed session logs, or escalated to the security team. The resolution determination: whether the event was confirmed as legitimate, confirmed as malicious, or inconclusive. The response action: whether the session was terminated, the account was suspended, or the alert was cleared as a false positive. The resolution timestamp. This structured investigation record demonstrates that alerts are not only generated but acted upon, satisfying Item 5’s monitoring and response objective. IS auditors examining Item 5 will request investigation records for a sample of alerts from the examination period.

Can the same anomaly detection infrastructure satisfy both IRDAI Item 5 and SOC 2 CC7.2 requirements simultaneously?

Yes. IRDAI Item 5 and SOC 2 CC7.2 both require automated anomaly detection with alert generation. IRDAI Item 5 specifically requires detection of anomalies in login time, location, session duration, and access patterns. SOC 2 CC7.2 requires monitoring for anomalies indicative of malicious acts or errors. Both are satisfied by Akku’s Adaptive MFA continuous baseline evaluation, step-up authentication response, and alert generation infrastructure. The evidence required differs in audit context: IRDAI IS auditors examine the detection capability against the specific dimensions Item 5 names, while SOC 2 auditors sample anomaly alert records and investigation documentation across the Type II audit period. The same underlying detection infrastructure and alert records satisfy both.

Introduction

RBI-regulated entities have deployed MFA for internet banking customers for years. The compliance conversation about MFA has largely been about customer-facing authentication: OTP for net banking, transaction authentication for fund transfers, and step-up challenges for high-value payments. The privileged user MFA requirement in RBI‘s 2023 Master Direction is a different obligation and a different architecture.

RBI Clause 19(c) requires MFA for privileged users accessing critical information systems. Clause 20(b) requires MFA for all remote access to critical information systems. These are internal user requirements, not customer authentication requirements. They apply to system administrators accessing production servers, database administrators connecting to core banking databases, network engineers managing routers and switches, and IT managers accessing infrastructure management consoles.

Most regulated entities that have satisfied customer-facing MFA requirements have a significant gap in privileged user MFA coverage. Application-layer MFA, where a web-based management console presents an MFA challenge before granting access, covers the systems with web-based interfaces. It does not cover direct SSH connections to Linux servers, direct database client connections to production databases, or command-line access to network devices. These are the access paths that carry the highest privilege and produce the lowest MFA coverage rate in most regulated entities.

This blog covers what RBI’s MFA requirements specifically mandate for privileged users, where the infrastructure-layer coverage gap exists, and how PAM-layer MFA enforcement closes it.

The Full Scope of RBI’s MFA Requirements

RBI’s MFA requirements appear across multiple clauses in the 2023 Master Direction. Understanding the full scope prevents organisations from satisfying one clause while leaving others unaddressed.

Clause 19(c): Privileged user MFA

Clause 19(c) requires MFA for privileged users accessing critical information systems. The critical information systems scope includes core banking platforms, payment processing infrastructure, production databases, network infrastructure management interfaces, and any system whose compromise would have a material impact on operations.

The privileged user definition covers system administrators, database administrators, network engineers, application administrators with deployment or configuration access, and any other role with elevated permissions on critical systems. The scope is not limited to named system administrators. Any user whose credentials, if compromised, would provide access to critical system administration functions is a privileged user for Clause 19(c) purposes.

Clause 20(b): Remote access MFA

Clause 20(b) requires MFA for all remote access to critical information systems. Remote access includes any access from outside the corporate network, including VPN connections, direct internet access to management interfaces, and cloud-hosted system access from any network.

The remote access MFA requirement is broader than the privileged user requirement: it applies to all users accessing critical systems remotely, not only privileged users. However, in practice the highest-risk remote access scenario is privileged users administering critical systems from remote locations, making Clause 20(b) and Clause 19(c) closely related in their implementation requirements.

Clause 20(a): Centralised authentication for remote access

Clause 20(a) requires centralised authentication for remote access. All remote sessions to information systems must route through a secure, centralised authentication mechanism. Fragmented remote access through multiple VPN solutions, direct management interface exposure, and inconsistent MFA coverage does not satisfy this requirement.

Akku’s RBI mapping for MFA requirements

Akku’s RBI compliance mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b). The PAM architecture through which MFA is enforced for infrastructure-level access addresses the infrastructure coverage gap that Clauses 19(c) and 20(b) create together.

Where Application-Layer MFA Falls Short

Application-layer MFA covers web-based interfaces where users authenticate through a browser or application login screen. It does not cover direct protocol-level connections to infrastructure systems.

SSH access to Linux servers

SSH access to Linux servers is a direct protocol connection, not a web-based application login. When an administrator opens an SSH terminal to a production server, the connection goes directly to the server’s SSH daemon. There is no web-based MFA challenge in this path. If the regulated entity’s MFA enforcement only covers web-based management consoles, SSH access to the same servers is unprotected by MFA.

SSH access is the highest-volume privileged access path at most regulated entities. Core banking application servers, payment processing platforms, database servers, and API gateway servers are all accessed primarily through SSH for administration, configuration, and maintenance. If SSH access is not covered by MFA enforcement, Clause 19(c)’s privileged user MFA requirement is satisfied only for the fraction of privileged access that uses web interfaces.

Database client connections

Database client connections use database protocols, not HTTP. A DBA connecting to a MySQL or PostgreSQL production database from a database management tool such as DBeaver or MySQL Workbench connects through the database port using database credentials. There is no application-layer MFA challenge in this path.

Production banking databases contain the most sensitive data in a regulated entity’s environment: transaction records, customer account data, and in some cases payment card data. DBA access to these databases is among the highest-risk privileged access scenarios. If MFA is not enforced for direct database connections, the DBA credential is the only authentication factor protecting access to this data.

Network device management interfaces

Network engineers managing routers, switches, and firewalls use CLI connections through SSH or Telnet. Management interfaces for network devices may have web-based consoles, but command-line access through SSH remains common and is not covered by web-based MFA enforcement.

Item 52 of IRDAI ICS and Clause 19(c) of RBI both specifically reference network device management as a privileged access scenario requiring MFA. The regulatory attention to this specific scenario reflects awareness that network device access is commonly left outside MFA coverage.

Infrastructure management consoles

Cloud infrastructure management consoles, hypervisor management interfaces, and storage management platforms may have web-based access that is covered by application-layer MFA. However, these platforms also expose API access and CLI access that may not route through the same MFA enforcement. An organisation that enforces MFA for web console access to its cloud infrastructure management platform may leave API and CLI access to the same infrastructure unprotected.

PAM-Layer MFA Enforcement

Closing the infrastructure MFA coverage gap requires enforcing MFA at the session proxy layer, not at the application login layer. When all privileged connections to critical systems route through a PAM session proxy, MFA can be enforced at the proxy layer before any connection to the target system opens.

How AkkuReka enforces MFA at the session layer

AkkuReka functions as a session proxy between privileged users and target systems. Before AkkuReka opens a connection to a target system, the user must authenticate to Akku IAM with MFA. This authentication happens at the Akku platform layer, not at the target system layer. The target system sees only the session proxy connection, not the user’s direct connection attempt.

This architecture means that MFA enforcement applies to SSH connections, database connections, RDP connections, Kubernetes API connections, and web application sessions alike. The protocol used by the target system is irrelevant: the user must authenticate with MFA at the Akku layer before any connection opens, regardless of whether the target system has a native MFA capability.

Coverage across all critical system types

For SSH servers, the workflow is: user authenticates to Akku IAM with MFA, Akku evaluates access policy, session is approved, AkkuReka opens an SSH proxy connection to the target server, AkkuArka injects an ephemeral credential at the protocol layer. The user’s SSH terminal connects through the proxy, not directly to the server. MFA was enforced at step one. The server’s SSH daemon receives a proxy connection, not a direct user connection.

For database servers, the same workflow applies with MySQL or PostgreSQL as the target protocol. For RDP connections to Windows servers, AkkuReka proxies the RDP connection after MFA authentication at the Akku layer. For Kubernetes clusters, kubectl operations route through AkkuReka after MFA authentication.

Adaptive MFA for proportionate enforcement

Akku’s Adaptive MFA evaluates risk signals at each authentication event. Access from a new location, an unrecognised device, or outside normal hours triggers step-up authentication: a more demanding second factor or re-authentication within the session. Access from a familiar location, a compliant corporate device, during normal hours may require a standard second factor.

This proportionate enforcement is what Clause 19(c) implies: authentication controls commensurate with the sensitivity of the resource. A system administrator accessing a development server from their corporate device during normal hours faces a different risk profile than the same administrator accessing a production core banking server from a new country. Adaptive MFA applies the appropriate challenge for each scenario.

MFA Evidence for RBI IS Audit Examination

RBI IS auditors examining Clause 19(c) and 20(b) compliance test both the coverage and the evidence of MFA enforcement for privileged access.

Coverage testing

Auditors attempt to identify access paths that bypass MFA. They examine whether SSH access to critical servers requires MFA at the session level or only at a web console layer. They test direct database connections to assess whether MFA is enforced for non-web protocol access. They review the architecture documentation to identify any privileged access paths that do not route through the centralised MFA enforcement layer.

An organisation that has deployed web console MFA but left SSH and direct database access unprotected will have these gaps identified during coverage testing.

Evidence of continuous enforcement

Auditors examine authentication event logs to verify that every privileged session to a critical system was preceded by a successful MFA event. They sample sessions from across the examination period, not only recent sessions. For each sampled session, they verify that the session open event is preceded by a corresponding MFA authentication event in the audit log.

Sessions that opened without a corresponding MFA event in the audit log indicate either a coverage gap where the session bypassed MFA enforcement, or a logging gap where MFA occurred but was not recorded. Both are findings.

MFA method assessment

Auditors may assess the MFA methods deployed for highest-privilege accounts. For core banking system administrators and payment infrastructure administrators, phishing-resistant MFA methods such as FIDO2 hardware keys are increasingly expected for the most sensitive access scenarios. SMS and push notification MFA, while acceptable for standard users, may be scrutinised for accounts with the highest access privileges given their susceptibility to SIM swap and push notification fatigue attacks.

Diagnostic Questions

Does your MFA enforcement cover direct SSH connections to production servers and direct database client connections to production databases, or only web-based management console access?

For every privileged session to a critical system in the last 90 days, is there a corresponding MFA authentication event in the audit log preceding the session open event?

When a system administrator connects to a production server using an SSH terminal client, does MFA enforcement occur at the session proxy layer before the connection opens, or can the connection be established with only a private key?

Does your MFA coverage extend to remote privileged access from any network, including home networks, hotel networks, and mobile data connections, or only to access from within the corporate network?

For your highest-privilege accounts, specifically those with access to core banking systems and payment infrastructure, are you using phishing-resistant MFA methods such as FIDO2, or SMS and push notification methods that are susceptible to targeted attacks?

CTAs

See how Akku’s Adaptive MFA and PAM architecture address RBI Clause 19(c) and 20(b) MFA requirements for privileged user infrastructure access.

Book a conversation with the Akku team to assess your current MFA coverage against RBI’s privileged user MFA obligations.

FAQs

What is the difference between customer-facing MFA for internet banking and the privileged user MFA requirement in RBI Clause 19(c)?

Customer-facing MFA for internet banking covers authentication for retail and corporate customers accessing their accounts through the bank’s internet banking platform. It is governed by RBI’s guidelines on internet banking and payment authentication. Clause 19(c) covers MFA for internal privileged users, specifically system administrators, database administrators, network engineers, and other roles with elevated access to the bank’s critical information systems. The two requirements are separate and must be addressed independently. Satisfying one does not satisfy the other. The architecture for customer-facing MFA, typically OTP delivered to a registered mobile number, is not appropriate for privileged user MFA for infrastructure access.

Does Clause 19(c) require MFA for all privileged sessions or only for the initial session authentication?

Clause 19(c) requires MFA for privileged users accessing critical information systems. The access event is the triggering requirement. For JIT access where every privileged session is a new access event requiring a new approval, MFA is enforced at the authentication step before each session opens. For standing access models where a privileged user authenticates once and maintains an open session, the initial authentication with MFA satisfies the letter of the clause but not the spirit of the event-by-event control standard. RBI IS auditors examining Clause 19(c) in conjunction with Clause 19(a)’s need-based access requirement will look for evidence that MFA is enforced for each access event, not as a one-time authentication to an always-on privileged account.

What MFA methods does RBI Clause 19(c) require for privileged user access?

The RBI 2023 Master Direction does not specify which MFA methods are required for Clause 19(c) compliance. It requires MFA without prescribing specific factors. In practice, IS auditors assess whether the MFA method is appropriate for the risk level. For standard privileged users, TOTP applications such as Google Authenticator, push notification MFA, and hardware tokens are all acceptable. For the highest-privilege accounts with access to core banking systems and payment infrastructure, phishing-resistant methods such as FIDO2 hardware keys are increasingly recommended given the targeted attack risk these accounts face. Organisations should assess the MFA methods deployed for their highest-risk privileged accounts against the current threat landscape.

How does PAM-layer MFA enforcement differ from target system native MFA?

Target system native MFA is configured on each individual system. A Linux server can be configured with PAM-based MFA that challenges users at the SSH login layer. A web management console can be configured with an integrated MFA provider. Target system native MFA requires separate configuration and maintenance for each system and produces separate authentication event logs per system. PAM-layer MFA enforcement, through AkkuReka, applies MFA at the session proxy before any target system connection opens. It requires configuration once at the PAM layer, applies consistently to all target systems regardless of their native MFA capability, and produces a centralised authentication event log covering all target systems. PAM-layer enforcement provides better coverage, simpler maintenance, and more consistent evidence for regulatory examination.

Does Clause 20(b)’s remote access MFA requirement apply to VPN-connected access as well as direct internet access?

Clause 20(b) requires MFA for all remote access to critical information systems. VPN connectivity establishes a network tunnel but does not itself constitute a compliant remote access security control for Clause 20(b) purposes. A user who connects via VPN and then SSH to a production server without MFA has satisfied the network connectivity requirement but not the authentication security requirement. MFA must be enforced for the privileged access event itself, whether the user is on VPN, on a direct internet connection, or on any other network. PAM-layer MFA enforcement through AkkuReka satisfies Clause 20(b) for all remote access paths because MFA is enforced at the session proxy layer regardless of how the user’s network connection is established.

How should regulated entities handle MFA for emergency access scenarios under operational continuity requirements?

Emergency access scenarios where normal authentication mechanisms may be unavailable require a documented emergency access procedure that satisfies the security objective of Clause 19(c) while enabling operational continuity. The emergency procedure should include: a defined list of emergency access scenarios, pre-registered backup MFA factors for privileged users that can be used when primary MFA is unavailable, a break-glass account process with tight controls and mandatory post-incident review, and enhanced session recording for all emergency access sessions. Emergency access must not create a persistent bypass of MFA enforcement. Each emergency access event must be logged with justification and subject to post-incident review. The emergency procedure must be tested periodically to verify it works when needed without being so accessible that it undermines normal MFA enforcement.