Your organisation is likely operating under more than one compliance framework. RBI if you are a bank or NBFC. SEBI CSCRF if you are a capital markets entity. IRDAI ICS if you are an insurer. ISO 27001 if you are pursuing certification. SOC 2 if you serve enterprise clients. DPDPA if you process personal data of Indian residents, which at this point means almost every organisation in India.
Each framework has its own clause structure, its own audit process, and its own evidence requirements. But at the technical controls layer, they are all asking for the same things. MFA for privileged users. Need-based access with least privilege enforcement. Structured provisioning and deprovisioning workflows. Session activity logging for privileged sessions. Periodic access reviews with documented outcomes.
Organisations that treat each framework as a separate controls project end up building parallel evidence packages for controls that are technically identical. An AMFA deployment that satisfies RBI Clause 19(c) simultaneously satisfies SEBI CSCRF PR.AA.S7, IRDAI ICS Item 52, and ISO 27001 A.8.5. The control is the same. The evidence it produces is the same log. Only the clause number in the mapping document changes.
This blog covers the five IAM controls that appear across every major framework, what each framework specifically requires, and how a single IAM deployment produces the compliance evidence for all of them.
One important note on scope: IAM controls address the system-driven, cybersecurity-enforceable layer of compliance. Every framework also contains manual and governance-level obligations, board approvals, risk assessments, training programmes, and documented policies, that no technology platform can satisfy. What follows covers the technical controls layer specifically.
Multi-Factor Authentication Requirements Across Frameworks
Most organisations have MFA deployed for end users. The compliance gap is almost always at the infrastructure layer: servers, databases, network devices, and Kubernetes clusters that privileged administrators access directly, outside the application MFA perimeter.
What the frameworks require
RBI 2023 Master Direction Clause 19(c) requires MFA for privileged users accessing critical information systems. SEBI CSCRF PR.AA.S7 requires authentication controls commensurate with the sensitivity of the resource being accessed. 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 requires logical access security software and CC6.6 requires boundary protection controls. DPDPA Clause 8(5) requires appropriate technical and organisational measures to protect personal data. GDPR Article 32(1)(b) and Article 5(1)(f) require appropriate security for processing operations.
How Akku addresses it
Akku’s Adaptive MFA evaluates device posture, geographic location, IP reputation, time of day, and behavioural baseline at each authentication event. The challenge escalates only when risk signals warrant it. This is the proportionate, risk-based authentication model that SEBI CSCRF PR.AA.S7 and IRDAI ICS specifically require.
For privileged infrastructure access, Akku enforces MFA at the IAM layer through PAM before any session proxy connection opens. This extends authentication assurance to SSH servers, Windows RDP hosts, MySQL, PostgreSQL, Kubernetes clusters, and web applications, covering the infrastructure layer that application-level MFA does not reach.
Passwordless authentication via FIDO2 and WebAuthn removes the password as a primary factor, eliminating the credential attack surface that phishing, credential stuffing, and brute force attacks depend on.
Each authentication event produces a structured log record containing MFA method, outcome, source IP, device identifier, and geographic location. This single event stream satisfies RBI Clause 15, ISO 27001 A.8.15, and SOC 2 CC7.2 simultaneously.
Need-Based Access and Least Privilege Controls
Verified identity does not establish authorised access. The access control layer determines what each verified user can reach, under what conditions, and with what scope of privilege. This is where most access-related audit findings originate.
What the frameworks require
RBI Clause 19(a) requires need-based access: users access only what their role requires, and access is revoked when the need ends. RBI Clause 9(b) requires effective segregation of duties. SEBI CSCRF PR.AA.S1 through PR.AA.S9 cover identity management, access provisioning, and least privilege enforcement. ISO 27001:2022 A.5.15 covers access control, A.5.18 covers access rights management, and A.8.2 covers privileged access rights. SOC 2 CC6.2 and CC6.3 cover user authorisation and modification or removal of access as roles change. SOC 2 CC5.1 requires control activities that mitigate risk, including SoD. DPDPA Clause 8(4) requires technical measures to limit processing to authorised purposes. GDPR Article 25(2) requires data minimisation by default.
How Akku addresses it
RBAC and ABAC are the foundational controls. Role definitions determine application and resource access. Attribute-based controls refine this further by factoring in department, location, employment type, and device compliance status.
The IGA SoD rules engine defines conflicting role combinations, detects violations continuously, and triggers automated remediation workflows. RBI Clause 9(b) and SOC 2 CC5.1 require effective SoD. A technically-enforced rules engine that detects and remediates violations is materially different from a policy document that states SoD is required. Auditors examine the technical control, not the policy statement.
Akku’s contextual access controls apply IP, device, time-of-day, and geo-location restrictions on top of role entitlements. This is the access control model that RBI Clause 20 and SEBI CSCRF PR.AA.S4 require for remote and distributed workforce access scenarios.
For privileged infrastructure, Just-in-Time access removes standing privilege entirely. Access is granted for the duration of an approved, time-bound session and revoked automatically on expiry. This is the technical implementation of need-based, least-privilege access that RBI Clause 19(a) and 19(b), ISO 27001 A.8.2, and SOC 2 CC6.3 all require.
Access Provisioning and Approval Workflows
Compliance frameworks do not only require that current access is appropriate. They require that the process by which access was granted is structured, documented, and traceable. Access approved informally, over email, through a verbal request, or via an ad-hoc ticket, does not produce a defensible audit record.
What the frameworks require
RBI Clauses 8(c) and 9(b) require documented access governance processes. SEBI CSCRF GV.PO.S1 through S5 require domain-specific security policies with technical enforcement mechanisms. IRDAI ICS Item 6 requires controlled provisioning of temporary and contractor accounts with documented lifecycle management. ISO 27001:2022 A.5.16 requires a managed identity management process and A.5.18 requires access rights to follow a formal provisioning workflow. SOC 2 CC6.2 requires formal user registration and CC6.3 requires authorised modification and removal of access. GDPR Article 24(1) requires controllers to demonstrate that appropriate technical measures are implemented.
How Akku addresses it
Automated User Lifecycle Management covers the full joiner-mover-leaver workflow. Birthright access is provisioned automatically on joining based on role. Role changes trigger re-provisioning. Departure triggers deprovisioning across all connected applications in a single, auditable action.
Access request and approval workflows produce the documentary evidence the frameworks require. Every access grant carries a requester identity, approver identity, justification, timestamp, and a complete audit record. Multi-step approval paths for sensitive access, requiring both a line manager and a system owner to approve, satisfy the governed authorisation requirements in DPDPA Clause 8(4) and SOC 2 CC6.2.
SCIM-based automated provisioning synchronises access granted in Akku downstream to connected applications without manual intervention. Provisioning events are logged, downstream sync is verifiable, and connector health is monitored. The audit trail covering request, approval, provisioning execution, and sync confirmation satisfies RBI Clause 8(c), ISO 27001 A.5.16, and SOC 2 CC6.2 from one automated workflow.
Session Activity Logging for Privileged Access
Authentication logs confirm a session opened. They record nothing inside it. No commands executed, no queries run, no files accessed, no configuration changes made. For privileged users with access to critical infrastructure, this gap is a direct compliance deficiency under multiple frameworks.
What the frameworks require
RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. Authentication timestamps do not meet that standard. SEBI CSCRF PR.AA.S8 and GV.OC.S2 require on-demand access to logs including user activity detail. IRDAI ICS Items 144 and 145 require audit trail maintenance including session-level activity records. ISO 27001:2022 A.8.15 explicitly requires logging of user activities, not login events alone. SOC 2 CC7.2 requires monitoring of system components for anomalies, which requires activity data beyond authentication records. DPDPA Clause 8(5) and GDPR Article 5(1)(f) require appropriate security for processing, which implies visibility into what processing occurred.
How Akku addresses it
SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka. SSH sessions produce full screen recordings and complete keystroke logs per command. Database sessions produce full screen recordings and a structured capture of every SQL query executed. RDP sessions produce full screen video recordings at configurable frame rates.
All recordings are stored encrypted, indexed for forensic search by timestamp, command string, or SQL query, and accessible for in-browser playback directly from the Akku admin console. No file download or external media player is required.
Structured audit log events are generated for every stage of the privileged session lifecycle: session request, approval decision, session open, active duration, keystroke and query counts, termination reason, and recording sealed. This log architecture satisfies RBI Clause 15’s forensic evidence standard, ISO 27001 A.8.15’s user activity logging requirement, and SEBI CSCRF’s on-demand log access requirement from a single event stream.
The audit log is append-only and tamper-evident. Existing records cannot be modified or deleted. This is the integrity standard that SEBI CSCRF and IRDAI require when they mandate logs accessible to regulators on demand.
Periodic Access Reviews and Entitlement Management
Access accumulates over time. Employees change roles, take on additional responsibilities, and leave. In each transition, some access is added and not all of it is removed. The resulting entitlement drift, the gap between what a user currently holds and what they currently need, is a finding in every major compliance framework.
What the frameworks require
RBI Clause 9(b) requires effective SoD and periodic access reviews. SEBI CSCRF PR.AA.S3 and PR.AA.S5 require periodic access reviews and recertification. IRDAI ICS Item 10 requires automatic disabling of dormant accounts and Item 189 requires access reviews. ISO 27001:2022 A.5.18 explicitly requires periodic review of access rights. SOC 2 CC6.3 requires that access be modified or removed as roles change. DPDPA Clause 8(4) and GDPR Article 5(1)(e) require storage and processing limitations that include ensuring access does not persist beyond its authorised scope. GDPR Article 17 and DPDPA Clause 8(7) require erasure and cessation of processing when the purpose is served.
How Akku addresses it
Access review and re-certification campaigns send periodic certification requests to managers and resource owners. Each decision to certify or revoke is timestamped and logged. The output is an auditor-ready evidence record showing who reviewed which entitlements, on which date, and what action resulted. This is the continuous operating evidence that SOC 2 Type II requires and that periodic audits under RBI and SEBI CSCRF assess.
Orphan account management detects accounts that exist without a linked, active identity: employees whose application accounts were not removed at offboarding, or accounts created during migrations with no current owner. These are surfaced automatically for resolution through deletion or reassignment. The detection run and resolution log are the proactive access hygiene evidence that RBI, SEBI, and IRDAI auditors look for specifically.
The consolidated who-has-access-to-what view provides a real-time picture of every user’s entitlements across all connected applications. This view makes access reviews operable at scale without requiring manual compilation from individual application administrators.
Automated deprovisioning on exit, triggered when an employee record is marked inactive, ensures offboarding does not leave residual access. The deprovisioning audit trail, showing which accounts were removed, from which applications, at what time, and by what trigger, satisfies DPDPA Clause 8(7), IRDAI Item 10, and SEBI CSCRF from a single automated workflow.
How One IAM Deployment Addresses All Five Controls
The five controls above are not answered by five separate systems. A single IAM platform covering identity assurance, access control, lifecycle governance, session activity logging, and access certification produces the compliance evidence for all of them from one shared audit trail.
This is the mechanism behind Akku’s compliance coverage numbers: 15 DORA articles fully addressed, 41 ISO 27001 clauses mapped, 88 SEBI CSCRF compliance items covered, 79 IRDAI requirements addressed. The frameworks differ in scope and language. The controls doing the work are the same controls.
When an AMFA deployment satisfies RBI Clause 19(c), it simultaneously satisfies SEBI CSCRF PR.AA.S7, IRDAI ICS Item 52, and ISO 27001 A.8.5. When JIT access satisfies ISO 27001 A.8.2, it simultaneously satisfies RBI Clause 19(a) and SOC 2 CC6.3. When SCIM-based lifecycle management satisfies DPDPA Clause 8(7), it simultaneously satisfies IRDAI Item 6 and SOC 2 CC6.2.
One deployment. One audit trail. Multiple compliance frameworks addressed from the same technical foundation.
Questions Compliance and IT Teams Ask About IAM Controls Across Regulatory Frameworks
Does one IAM platform genuinely address multiple compliance frameworks, or does each framework require separate controls?
The overlap at the technical controls layer is substantial. Adaptive MFA, RBAC, automated lifecycle management, session activity logging, and access reviews appear in DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, and GDPR under different clause numbers but with materially identical technical requirements. A single platform implementing these controls correctly produces evidence reusable across frameworks. The mapping documents and clause references differ per framework. The underlying controls do not.
What is the difference between standard MFA and adaptive MFA in a compliance context?
Standard MFA applies the same second-factor challenge to every authentication event regardless of context. Adaptive MFA evaluates risk signals at each authentication, including device posture, location, IP reputation, and behavioural baseline, and escalates the challenge only when those signals indicate elevated risk. SEBI CSCRF and IRDAI ICS require authentication controls proportionate to resource sensitivity. Adaptive MFA satisfies that proportionality requirement. Static MFA does not.
Why do RBI and ISO 27001 treat authentication logs and session activity logs as separate requirements?
Authentication logs record login events: who connected, when, from where, and whether they succeeded. They record nothing about what happened inside the session. RBI Clause 15 requires audit trails suitable for forensic investigation. ISO 27001:2022 A.8.15 requires logging of user activities, not login events. For privileged users, session-level recording including keystroke logs for SSH and query capture for databases is the control that satisfies the forensic evidence standard. Authentication logs are a prerequisite, not a substitute.
What is JIT access and why does it satisfy need-based access requirements?
Just-in-Time access means no user holds persistent standing access to privileged systems. Access is granted for the duration of an approved, time-bound session and revoked automatically on expiry. RBI Clause 19(a) requires need-based access. ISO 27001 A.8.2 requires privileged access rights to be controlled. SOC 2 CC6.3 requires access to be modified or removed as circumstances change. JIT access satisfies all three by making standing privilege architecturally impossible rather than policy-dependent.
How does DPDPA’s erasure requirement apply to workforce identity systems?
DPDPA Clause 8(7) requires Data Fiduciaries to erase personal data and cease processing when the purpose is no longer served. For workforce IAM, the direct application is offboarding: when an employee leaves, their access to systems processing personal data must be revoked completely with a documented audit trail. For customer identity, consent withdrawal must trigger cessation of processing entitlements through CIAM. Both require automated lifecycle management with audit evidence, not a manual offboarding checklist.
What makes an audit log tamper-evident, and why do SEBI and IRDAI require this?
A tamper-evident audit log is append-only: new records are added but existing records cannot be modified or deleted. SEBI CSCRF and IRDAI require logs accessible to regulators on demand with confidence in their integrity. A log that can be altered after the fact cannot serve as reliable compliance evidence. The append-only architecture, combined with structured export in JSON or CSV format, satisfies both the availability and integrity requirements these frameworks impose.
