Indian companies with EU customers, EU operations, or EU-based employees are subject to the General Data Protection Regulation regardless of where the company is incorporated. Article 3 of GDPR establishes extraterritorial scope: any organisation that offers goods or services to EU residents, or that monitors their behaviour, falls within the regulation. For Indian ITeS companies processing EU client data, Indian enterprises with EU subsidiaries, and Indian technology companies with EU users, GDPR is not a foreign regulation. It is an operational requirement.

The technical obligations under GDPR are substantial and specific. Article 25 requires data protection by design and by default, meaning privacy controls must be built into systems architecture, not added as an afterthought. Article 32 requires appropriate technical and organisational measures to ensure security of processing. Articles 15 through 22 create Data Subject rights that require technical fulfilment infrastructure. Article 17’s right to erasure requires automated deletion workflows across connected systems, not manual database cleanup.

Most Indian organisations approaching GDPR compliance focus on the policy and legal layer: privacy notices, consent forms, data processing agreements, and DPO appointment. The technical implementation layer is a separate and more demanding exercise. A privacy notice does not constitute a consent management system. A data processing agreement does not constitute an access control implementation.

This blog covers what GDPR specifically requires at the technical layer, article by article, across lawful basis and consent, access controls and security measures, Data Subject rights, and audit accountability. All article references are drawn directly from the GDPR and Akku’s GDPR compliance mapping documentation, which addresses 36 of the 53 actionable GDPR compliance items with 57 mapping points across 12 modules.

Lawful Basis and Consent Requirements Under Articles 5 to 9

Articles 5 through 9 establish the lawful bases for processing personal data and define the consent requirements where consent is the chosen basis. For organisations relying on consent as a lawful basis, the technical infrastructure requirements are specific and demanding.

What the articles require

Article 5(1)(a) requires that personal data be processed lawfully, fairly, and transparently. Article 5(1)(b) requires purpose limitation: data collected for specified purposes must not be processed in a manner incompatible with those purposes. Article 5(1)(c) requires data minimisation: only data adequate, relevant, and limited to what is necessary may be processed. Article 5(1)(e) requires storage limitation: data must not be kept longer than necessary for the purposes for which it was collected.

Article 5(2) requires that the controller be able to demonstrate compliance with Article 5(1), the accountability principle. This is a technical as much as a governance requirement: the controller must be able to produce evidence of compliance, not merely assert it.

Article 6(1) establishes the lawful bases for processing, of which consent is one. Article 7 sets the conditions for consent: it must be freely given, specific, informed, and unambiguous. Consent must be as easy to withdraw as to give. Article 7(1) requires that the controller be able to demonstrate that consent was given.

Article 9(2)(a) permits processing of special category data where the data subject has given explicit consent for one or more specified purposes.

How Akku addresses it

Akku’s CIAM Consent Manager is the primary technical control for lawful basis and consent management. It addresses Articles 5(1)(a), 5(1)(b), 5(1)(c), 5(1)(d), 5(2), 6(1), 7(1), 7(2), 7(3), 7(4), 8(1), 8(2), and 9(2)(a) across 28 mapping points, the largest single-module count in Akku’s GDPR mapping.

Centralised consent record storage maintains versioned, timestamped consent records tied to specific Data Subject identities and specific processing purposes. Each consent record captures the notice version under which consent was given, the purpose, the timestamp, and the channel. This is the evidence that Article 7(1) requires the controller to be able to demonstrate.

Withdrawal workflows allow Data Subjects to withdraw consent as easily as they gave it, triggering downstream processing cessation notifications. This satisfies Article 7(3)’s withdrawal requirement. Purpose-specific consent management enforces Article 5(1)(b)’s purpose limitation at the data collection layer.

Access Control and Security Measures Under Articles 25 and 32

Articles 25 and 32 impose direct technical obligations on data controllers and processors. Article 25 requires privacy by design and by default. Article 32 requires appropriate technical and organisational security measures. Both are technical engineering obligations, not policy statements.

What the articles require

Article 25(1) requires that the controller implement appropriate technical and organisational measures designed to implement data protection principles effectively and integrate the necessary safeguards into the processing. Data protection must be built into the system architecture by design, not added after deployment.

Article 25(2) requires that the controller implement appropriate technical and organisational measures to ensure that, by default, only personal data necessary for each specific purpose is processed. This is the data minimisation by default requirement. Access to personal data must be restricted by default, with explicit authorisation required to expand access scope.

Article 32(1)(b) requires implementation of appropriate technical measures to ensure a level of security appropriate to the risk, including pseudonymisation and encryption of personal data where appropriate.

Article 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures.

Article 29 requires that processors and persons acting under the authority of the controller process data only on instructions from the controller. This creates an access governance requirement: access to personal data must be role-scoped and limited to authorised processing activities.

How Akku addresses it

Article 25(2)’s data minimisation by default requirement is addressed through RBAC and contextual access controls. Access to personal data systems is restricted by default. Expansion of access scope requires formal authorisation through structured request and approval workflows. Access Manager addresses Articles 5(1)(f), 24(1), 25(2), 29, and 32(1)(b) across five mapping points.

Article 32(1)(b) is addressed across multiple modules. Adaptive MFA reduces the risk of unauthorised access through credential compromise. Contextual access controls restrict processing to authorised environments. GPO Manager prevents personal data exfiltration from endpoints through USB restrictions, file sharing limitations, and upload controls. Password Manager encrypts credentials in AkkuVault using AES-256-GCM. Each of these contributes to the appropriate technical security measures Article 32(1)(b) requires.

Article 32(1)(d)’s testing and evaluation requirement maps to access review and re-certification campaigns. Periodic access reviews assess whether current access scope remains appropriate, producing documented evidence of ongoing control effectiveness evaluation. Identity and Access Governance addresses Articles 24(1), 25(2), and 32(1)(d) across three mapping points.

Article 29’s access governance requirement is addressed through RBAC role definitions scoped to authorised processing activities, provisioning workflows that limit access to what the role requires, and the SoD rules engine that prevents conflicting role combinations. Privileged Access Manager addresses Articles 5(1)(f), 29, and 32(1)(d) across three mapping points.

Data Subject Rights and Technical Fulfilment Infrastructure

Articles 15 through 22 establish eight Data Subject rights. Each right creates a corresponding technical obligation for the controller. Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice, which constitutes a compliance failure regardless of policy statements.

What the articles require

Article 15(1) gives Data Subjects the right to obtain confirmation of whether their personal data is processed, and if so, access to that data and information about the processing. This requires a self-service access portal or structured request fulfilment workflow.

Article 16 gives the right to rectification of inaccurate personal data. Article 17(1) gives the right to erasure, the right to be forgotten, under defined conditions including withdrawal of consent and completion of the purpose for which data was collected.

Article 18(1) gives the right to restriction of processing under defined conditions. Article 20(1) gives the right to data portability: receipt of personal data in a structured, commonly used, machine-readable format. Article 21(1) gives the right to object to processing.

Article 19 requires that the controller communicate rectification, erasure, or restriction to each recipient to whom personal data has been disclosed, unless this proves impossible or involves disproportionate effort.

How Akku addresses it

The CIAM Consent Manager addresses Articles 15(1), (3), 16, 17(1), 18(1), 20(1), 21(1), 21(2), and 25(1) through self-service Data Subject rights management workflows. Data Subjects can request access to their data, initiate correction and erasure requests, manage consent preferences, and exercise objection rights through the consent management portal.

User Lifecycle Manager addresses Articles 5(1)(e), 7(3), 17(1), and 19 across four mapping points. Automated deprovisioning workflows triggered by consent withdrawal or purpose completion ensure that erasure requests propagate across connected systems, not only in the primary data store. Notification workflows inform connected processors of erasure actions, satisfying Article 19’s communication requirement.

Article 30(1) and (2) require controllers and processors to maintain records of processing activities. Akku’s centralised audit log and provisioning records provide the access governance layer of the processing records requirement. CIAM Consent Manager and Audit Logs together address Article 30(1) and (2) across multiple mapping points.

Accountability and Audit Evidence Under Article 24

Article 24 requires that controllers implement appropriate technical and organisational measures and be able to demonstrate that processing is performed in accordance with GDPR. This is the accountability principle operationalised as a technical evidence requirement.

What the article requires

Article 24(1) requires that the controller implement appropriate technical and organisational measures to ensure and be able to demonstrate that processing is performed in accordance with the Regulation. The ability to demonstrate compliance is as much a requirement as compliance itself.

Article 5(2) reinforces this: the controller shall be responsible for, and be able to demonstrate compliance with, Article 5(1).

How Akku addresses it

Akku’s append-only, tamper-evident audit log is the technical infrastructure that makes Article 24(1) demonstrability possible. Every access grant, access review decision, provisioning action, deprovisioning action, consent record, consent withdrawal, and privileged session event produces a structured, timestamped, unmodifiable audit record.

This audit trail is the evidence base that a GDPR supervisory authority examination would draw on. Access controls that operate correctly but produce no structured evidence cannot satisfy Article 24(1)’s demonstration requirement. Audit Logs addresses Articles 5(2), 24(1), and 30(1) and (2) across three mapping points.

Identity and Access Governance addresses Article 24(1) through access certification records that demonstrate ongoing review of access appropriateness. Privileged Access Manager addresses Article 32(1)(d) through session-level evidence of control operating effectiveness.

How IAM Addresses GDPR Technical Obligations

Akku’s GDPR compliance mapping addresses 36 of the 53 actionable GDPR compliance items with 57 mapping points across 12 modules. The CIAM Consent Manager carries 28 of the 57 mapping points, reflecting how central consent infrastructure and Data Subject rights fulfilment are to GDPR’s technical requirements for organisations relying on consent as a lawful basis.

The remaining 17 items outside Akku’s scope relate to organisational obligations including DPO appointment, data protection impact assessments, breach notification procedures, international transfer mechanisms, and contractual obligations with processors. Full GDPR compliance requires these technical controls combined with the legal and governance measures those items require.

An important scoping note for Indian companies: GDPR compliance requires both the technical controls IAM provides and the legal framework compliance requires. Appointment of a Data Protection Officer where required, maintenance of records of processing activities, execution of data processing agreements with processors, and assessment of international transfer mechanisms are legal obligations that sit alongside the technical controls this blog covers.

Questions Indian Companies Ask About GDPR Technical Obligations

Does GDPR apply to Indian companies with no EU office or EU employees?

Yes. Article 3 of GDPR establishes extraterritorial scope based on the location of Data Subjects, not the location of the controller or processor. An Indian company that offers goods or services to EU residents, processes EU resident data on behalf of EU clients, or monitors the behaviour of EU residents is subject to GDPR regardless of where it is incorporated or operates. For Indian ITeS companies processing EU client data, Indian technology companies with EU users, and Indian enterprises with EU operations, GDPR compliance is a direct obligation.

What is the difference between Article 25 data protection by design and Article 32 security measures?

Article 25 requires that privacy controls be built into system architecture by design and that data minimisation be the default configuration, meaning only necessary data is accessible by default without explicit authorisation to expand scope. Article 32 requires appropriate technical security measures to protect personal data against risks including unauthorised access, destruction, and disclosure. Article 25 is about architecture and design choices. Article 32 is about operational security controls. Both impose technical obligations, and satisfying one does not satisfy the other.

What does GDPR’s right to erasure under Article 17 require technically?

Article 17 gives Data Subjects the right to erasure of their personal data under defined conditions including withdrawal of consent and completion of the purpose for which data was collected. Technically, this requires erasure workflows that propagate deletion requests across all connected systems where the Data Subject’s data is held, not only in the primary data store. Article 19 additionally requires that the controller inform each recipient to whom data was disclosed of the erasure. At scale, manual fulfilment of erasure requests across multiple connected systems is not operationally viable within any reasonable timeframe.

What records does Article 30 require controllers to maintain, and how does IAM contribute to this?

Article 30 requires controllers to maintain records of processing activities covering the name and contact details of the controller, purposes of processing, categories of Data Subjects and personal data, categories of recipients, transfers to third countries, retention periods, and a general description of technical and organisational security measures. IAM contributes to this through access governance records showing who is authorised to process which categories of personal data, provisioning audit trails showing when access was granted and on what basis, and access review records demonstrating ongoing governance of processing authorisations.

How does GDPR’s accountability principle under Article 24 differ from simply implementing controls?

Article 24 requires not only that appropriate technical measures are implemented, but that the controller is able to demonstrate that processing is performed in accordance with GDPR. The demonstration requirement means that controls must produce structured, reviewable evidence of their operation, not merely function correctly. A technically effective access control that produces no audit record cannot satisfy Article 24(1) because its effectiveness cannot be demonstrated to a supervisory authority. The audit trail infrastructure that generates continuous, tamper-evident evidence of control operation is what makes the accountability principle technically satisfiable.

Can a single IAM deployment address both GDPR and DPDPA requirements simultaneously?

Yes. The overlapping technical controls are substantial. GDPR Article 7 and DPDPA Clause 6 both require that consent be freely given, specific, informed, and withdrawable with equivalent ease. GDPR Article 17 and DPDPA Clause 8(7) both require erasure when the processing purpose is no longer served. GDPR Article 25(2) and DPDPA Clause 8(4) both require data minimisation by default and access controls limited to authorised purposes. A single Akku deployment implementing consent management, access controls, lifecycle management, and audit trail generation produces compliance evidence for both frameworks from the same technical infrastructure.

SOC 2 Type II has become a commercial prerequisite for Indian ITeS and BPO companies serving enterprise clients in North America and Europe. Enterprise procurement teams increasingly require a current SOC 2 Type II report before awarding contracts involving access to their systems, data, or infrastructure. For ITeS companies handling healthcare data, financial records, or personally identifiable information, the requirement is near-universal.

The distinction between Type I and Type II is not administrative. Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively over a defined period, typically six to twelve months. The operating effectiveness standard requires that controls produce consistent, structured evidence throughout the audit period, not only at the moment of assessment. An access review conducted once before the audit window opens does not satisfy Type II. An access review process that runs continuously and produces documented outcomes every cycle does.

Most Indian ITeS companies approaching SOC 2 for the first time underestimate the evidence infrastructure required for the Logical Access Controls criteria under CC6. CC6.1 through CC6.8 together require that logical access to systems is controlled, monitored, and reviewed throughout the audit period, with structured evidence of every control operating as designed. This blog covers the Trust Services Criteria most relevant to ITeS operations, what each criterion requires technically, and how IAM controls produce the continuous operating evidence SOC 2 Type II demands.

All criteria references are drawn from the AICPA Trust Services Criteria and Akku’s SOC 2 compliance mapping documentation, which addresses 14 of the 61 top-level Trust Services Criteria with 31 overlapping mapping points across 11 modules.

SOC 2 Framework Structure and ITeS Applicability

SOC 2 is structured around five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for all SOC 2 engagements. The other four categories are included based on the services provided and client requirements.

Trust Services Categories relevant to ITeS

Security is the mandatory category and contains the Common Criteria (CC) that apply to all SOC 2 engagements. The CC criteria run from CC1 through CC9 covering the COSO internal control framework, logical access, system operations, change management, and risk mitigation.

Privacy is increasingly included in SOC 2 engagements for ITeS companies handling personal data on behalf of clients. The Privacy criteria (P1 through P8) cover notice and communication, choice and consent, collection, use and retention, access, disclosure, quality, and monitoring and enforcement.

For most Indian ITeS companies, the Security category with CC5, CC6, and CC7 and the Privacy category covering P1 through P6 represent the primary compliance scope. This blog covers these criteria specifically.

Type I versus Type II evidence requirements

Type I requires evidence that controls are suitably designed at a point in time. An auditor reviews control documentation, policy descriptions, and a sample of control outputs to assess design suitability.

Type II requires evidence that controls operated effectively throughout the audit period. An auditor reviews control outputs across the entire period, typically testing samples from multiple points across six to twelve months. A control that worked correctly once but had gaps during the period does not satisfy Type II. Continuous, structured evidence generation is the operational requirement.

Logical Access Controls Under CC6

CC6 is the Logical and Physical Access Controls criterion cluster and is where most IAM-relevant requirements sit. CC6.1 through CC6.8 cover logical access security, user registration, access modification and removal, boundary protection, transmission controls, and malicious software prevention.

What the criteria require

CC6.1 requires that logical access security software, infrastructure, and architectures are implemented to protect against threats from sources outside the system boundary. This covers centralised identity management, MFA enforcement, and access control infrastructure.

CC6.2 requires that prior to issuing system credentials and granting system access, the entity registers and authorises new internal and external users. This is the user registration and provisioning control. Every user must be registered through a formal process before access is granted.

CC6.3 requires that the entity authorises, modifies, or removes access to data, software, functions, and other protected information assets based on approved and documented access requests and the system of record for user entitlements. This is the access modification and removal control, covering role changes, access reviews, and deprovisioning.

CC6.6 requires that logical access security measures are implemented to protect against threats from persons acting outside the entity’s system boundaries. This covers boundary protection controls including MFA for external access and contextual access restrictions.

CC6.7 requires that the transmission, movement, and removal of information is restricted to authorised internal and external users and processes. This covers data transfer controls and endpoint restrictions on data movement.

CC6.8 requires that the entity implements controls to prevent or detect and act upon the introduction of unauthorised or malicious software. This covers endpoint application controls and software installation restrictions.

How Akku addresses it

CC6.1 is addressed through Akku’s unified cloud identity store, SSO infrastructure, and Adaptive MFA. Centralised identity management, consistent MFA enforcement, and contextual access controls together constitute the logical access security architecture CC6.1 requires. Akku’s SOC 2 mapping shows Cloud Directory addresses CC6.1 and CC6.2, SSO and IDP addresses CC6.1, and Adaptive MFA addresses CC6.1 and CC6.6.

CC6.2 is addressed through structured access request and provisioning workflows. Every user is registered through a formal process. Birthright access is assigned based on role. Additional access requires a documented request and approval. SCIM-based provisioning synchronises approved access to connected applications. The provisioning audit trail covers requester, approver, justification, timestamp, and downstream sync confirmation.

CC6.3 is addressed through automated User Lifecycle Management and access review campaigns. Role changes trigger re-provisioning. Departure triggers automated deprovisioning. Periodic re-certification campaigns send certification requests to managers and resource owners with timestamped, logged decisions. The Identity and Access Governance module addresses CC5.1, CC6.2, and CC6.3 across three mapping points. User Lifecycle Manager addresses CC6.2 and CC6.3.

CC6.6 is addressed through contextual access controls applying IP, device, geo-location, and time-of-day restrictions, combined with Adaptive MFA for external and remote access scenarios.

CC6.7 and CC6.8 are addressed through GPO Manager and MDM endpoint controls. USB restrictions, file sharing limitations, application launch controls, and software installation blocking address the data movement and malicious software prevention requirements. GPO Manager addresses CC6.1, CC6.7, CC6.8, and CC7.1 across four mapping points. Mobile Device Manager addresses the same four criteria.

Control Activities and Segregation of Duties Under CC5

CC5 covers the COSO principle of control activities and includes requirements for general controls over technology and segregation of duties. CC5.1 and CC5.2 are the criteria most directly addressed by IAM controls.

What the criteria require

CC5.1 requires that the entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. For IAM, this includes SoD enforcement, access reviews, and access governance processes that mitigate the risk of unauthorised access or fraud.

CC5.2 requires that the entity selects and develops general control activities over technology to support the achievement of objectives. This covers technology controls including logical access controls, change management controls, and system operations controls.

How Akku addresses it

CC5.1 is addressed through the IGA SoD rules engine. The engine defines conflicting role combinations, detects violations continuously, and triggers automated remediation. Access certification campaigns provide the periodic control activity that mitigates entitlement drift risk. Identity and Access Governance addresses CC5.1 alongside CC6.2 and CC6.3.

CC5.2 is addressed through Privileged Access Manager, which provides general control activities over technology systems. The session approval workflow, per-session ephemeral credentials, and SMARTAudit Trails together constitute the general technology controls CC5.2 requires for privileged system access. Privileged Access Manager addresses CC5.2, CC6.1, CC6.3, CC6.8, and CC7.2 across five mapping points, the highest single-module count in Akku’s SOC 2 mapping.

Anomaly Detection and Monitoring Requirements Under CC7

CC7 covers system operations and monitoring. CC7.1 and CC7.2 are the criteria relevant to IAM monitoring capabilities.

What the criteria require

CC7.1 requires that the entity uses detection and monitoring procedures to identify changes to configurations or new vulnerabilities, and conducts ongoing monitoring of the environment. For IAM, this covers endpoint configuration monitoring and authentication anomaly detection.

CC7.2 requires that the entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, or errors affecting the entity’s ability to meet its objectives. Authentication anomaly detection, MFA failure monitoring, and privileged session monitoring are the IAM-layer controls that address CC7.2.

How Akku addresses it

CC7.1 is addressed through GPO Manager and MDM, which enforce and monitor endpoint configurations. Policy violations, non-compliant device states, and configuration changes are surfaced through centralised dashboards. GPO Manager and Mobile Device Manager each address CC7.1 alongside CC6.1, CC6.7, and CC6.8.

CC7.2 is addressed through Akku’s identity and access security monitoring layer. AI-powered anomaly detection in Adaptive MFA evaluates each authentication event against the user’s behavioural baseline. MFA failure spikes, geographic anomalies, and access outside defined time windows generate alerts for administrator review. Real-time privileged session monitoring through AkkuReka allows instant detection and termination of suspicious sessions. Privileged Access Manager addresses CC7.2 alongside CC5.2, CC6.1, CC6.3, and CC6.8.

Privacy Criteria Requirements Under P1 to P6

The Privacy criteria are increasingly included in SOC 2 engagements for ITeS companies handling personal data. P1 through P6 cover notice, consent, collection, use, access, and disclosure of personal information. The CIAM Consent Manager module is the primary technical control addressing these criteria.

What the criteria require

P1.1 requires that the entity provides notice about its privacy practices to individuals whose personal information it collects. Notice must be clear, accessible, and cover the purposes of collection, use, and disclosure.

P2.1 requires that the entity communicates choices available regarding the collection, use, and disclosure of personal information and obtains implicit or explicit consent. Consent must be recorded.

P3.1 requires that personal information is collected only for the purposes identified in the notice. Collection must be limited to what is necessary.

P3.2 requires that the entity collects personal information only with the explicit or implicit consent of the individual.

How Akku addresses it

The CIAM Consent Manager addresses P1.1, P2.1, P3.1, and P3.2 directly, alongside CC6.1 across five mapping points, the joint highest single-module count with Privileged Access Manager in Akku’s SOC 2 mapping.

Centralised consent record storage maintains versioned, timestamped consent records tied to specific individual identities and specific processing purposes. Preference management across channels ensures consent preferences are consistent. Full consent audit trails for every update provide the evidence record P1.1 and P2.1 require. Collection limitation controls enforce P3.1’s data minimisation requirement at the identity layer.

How IAM Addresses SOC 2 Type II Operating Effectiveness Requirements

Akku’s SOC 2 mapping addresses 14 of the 61 top-level Trust Services Criteria with 31 overlapping mapping points across 11 modules. The operating effectiveness requirement of Type II means that evidence must be continuous, not point-in-time.

Every provisioning action, access review decision, privileged session record, authentication event, and deprovisioning action produces a timestamped, structured audit record as a byproduct of normal operations. This continuous evidence generation is what SOC 2 Type II auditors sample across the audit period. Controls that operate correctly but produce no structured evidence fail the operating effectiveness standard regardless of how well they are designed.

The practical implication for ITeS companies is that manual access management processes, email-based approvals, spreadsheet-tracked access reviews, and informally managed deprovisioning cannot produce the continuous, structured evidence SOC 2 Type II requires. The evidence infrastructure must be built into the operational processes, not assembled before each audit cycle.

Questions Indian ITeS and BPO Companies Ask About SOC 2 Type II Trust Services Criteria

What is the difference between SOC 2 Type I and Type II, and why does it matter for ITeS companies?

SOC 2 Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively throughout a defined audit period, typically six to twelve months. Enterprise clients in North America and Europe typically require Type II because it provides assurance of consistent control operation over time, not a snapshot. For ITeS companies, this means the evidence infrastructure must generate continuous, structured outputs throughout the audit period. Controls that work correctly but produce no structured evidence fail the Type II operating effectiveness standard.

Which SOC 2 Trust Services Categories should an Indian ITeS company include in its engagement?

Security is mandatory for all SOC 2 engagements. ITeS companies handling personal data on behalf of clients should consider including Privacy, as enterprise clients increasingly require it for data processing engagements. Availability may be required for ITeS companies providing infrastructure or platform services with uptime commitments. Processing Integrity applies to companies providing transaction processing services. The specific categories included should be determined based on client requirements and the nature of services provided.

What does CC6.3 require for access removal, and how quickly must access be revoked when roles change?

CC6.3 requires that access be modified or removed based on approved and documented access requests and the system of record for user entitlements. SOC 2 does not specify a defined revocation timeframe, but auditors assess whether the process operates consistently and produces documented evidence of timely action. In practice, automated deprovisioning triggered by HR system events, completing within the same business day, with a timestamped audit record of every account removed, is the standard that satisfies the operating effectiveness examination.

What evidence does a SOC 2 Type II auditor expect for CC6.2 user registration controls?

CC6.2 auditors typically look for evidence of a formal user registration process covering the full audit period. This includes access request records showing who requested access, what was requested, and who approved it; provisioning records showing that access was granted in accordance with approvals; evidence that access was granted only after formal authorisation; and a consistent process applied throughout the audit period. Auditors sample provisioning events across the period rather than examining only recent records, so the process must have operated consistently from the start of the audit window.

How do the SOC 2 Privacy criteria apply to Indian ITeS companies processing client data?

SOC 2 Privacy criteria apply when an organisation handles personal information on behalf of clients. For Indian ITeS companies, this covers BPO processing of customer records, KYC data handling, healthcare data processing for US clients, and any service involving personal data of individuals. P1 through P6 require that individuals receive notice of data practices, that consent is obtained and recorded where required, that collection is limited to identified purposes, and that individuals have access to their data. CIAM Consent Manager addresses these criteria for customer-facing consent and preference management.

Can a single IAM deployment support both SOC 2 Type II and ISO 27001:2022 certification simultaneously?

Yes. The overlapping technical controls are substantial. SOC 2 CC6.1 and ISO 27001 A.8.5 both require logical access security. SOC 2 CC6.3 and ISO 27001 A.5.18 both require periodic access rights review. SOC 2 CC5.2 and ISO 27001 A.8.2 both require controlled privileged access. SOC 2 CC7.2 and ISO 27001 A.8.16 both require anomaly detection and monitoring. A single IAM deployment implementing these controls produces compliance evidence for both certifications from the same audit trail and governance infrastructure, reducing the duplication of effort that separate compliance programmes create.

ISO 27001:2022 reorganised the Annex A control set from 114 controls across 14 domains to 93 controls across four themes. The identity and access management controls that were previously spread across multiple domains are now consolidated primarily within Theme 5 (Organisational Controls) and Theme 8 (Technological Controls). The reorganisation did not reduce the technical requirements. If anything, the 2022 revision made several controls more specific, adding A.8.15 on logging, A.8.16 on monitoring activities, and A.8.18 on use of privileged utility programs where the 2013 version had less granular requirements.

Organisations pursuing ISO 27001 certification frequently underestimate the evidence burden of the access control and identity management controls. A.5.18 requires periodic review of access rights with documented outcomes. A.8.2 requires that privileged access rights be restricted, controlled, and reviewed. A.8.15 requires logging of user activities, exceptions, faults, and security events, not login timestamps alone. Each of these controls requires a technical implementation that produces structured, auditor-reviewable evidence as a byproduct of normal operations.

This blog covers the ISO 27001:2022 Annex A controls most relevant to identity and access management, what each control requires at the implementation level, and how IAM controls address them. All control references are drawn from the ISO 27001:2022 standard and Akku’s ISO 27001 compliance mapping documentation, which supports 41 unique clauses with 60 total mappings across 11 platform modules.

Annex A Structure and IAM-Relevant Controls

ISO 27001:2022 organises Annex A controls into four themes: Organisational (A.5), People (A.6), Physical (A.7), and Technological (A.8). The IAM-relevant controls are distributed primarily across A.5 and A.8, with some people-related controls in A.6 covering remote working and clear desk policies.

Key IAM-relevant controls by theme

Theme 5 Organisational Controls contains the core access management controls: A.5.15 (access control), A.5.16 (identity management), A.5.17 (authentication information), A.5.18 (access rights), and A.5.19 through A.5.22 covering supplier relationships and information security in supplier agreements.

Theme 8 Technological Controls contains the operational security controls: A.8.2 (privileged access rights), A.8.3 (information access restriction), A.8.4 (access to source code), A.8.5 (secure authentication), A.8.15 (logging), A.8.16 (monitoring activities), A.8.18 (use of privileged utility programs), and A.8.19 (installation of software on operational systems).

The main clause requirements in Clauses 4 through 10 also contain IAM-relevant obligations. Clause 8.1 requires planning and control of processes needed to meet information security requirements. Clause 9.1 requires monitoring, measurement, analysis, and evaluation of the ISMS. These main clause requirements interact directly with the Annex A controls and are part of what certification auditors assess.

Identity Management Requirements Under A.5.15 to A.5.18

A.5.15 through A.5.18 form the core identity and access governance control cluster in ISO 27001:2022. Together they define the access control policy, identity management process, credential management, and access rights lifecycle that the standard requires.

What the controls require

A.5.15 requires that rules for access control to information and associated assets be established, documented, and reviewed based on business and information security requirements. Access control policy must cover physical and logical access, differentiate between different types of users, and be reviewed at defined intervals.

A.5.16 requires that the full lifecycle of identities be managed: creation, maintenance, and deletion of identities for users, services, and systems. The identity management process must ensure that access rights are assigned and maintained based on defined roles and that identities are removed promptly when no longer required.

A.5.17 requires that management of authentication information follow a formal process covering allocation, storage, and change of authentication credentials. Passwords must meet defined complexity requirements, and credential management must prevent unauthorised disclosure.

A.5.18 requires that provisioning and revoking of access rights follow a formal process. Access rights must be reviewed at defined intervals, and rights that are no longer required must be revoked. The review must produce documented evidence of decisions made.

How Akku addresses it

A.5.15 is addressed through Akku’s access control infrastructure. RBAC defines access entitlements by role. Contextual access controls apply IP, device, time-of-day, and geo-location restrictions. The IGA module’s SoD rules engine enforces segregation of duties. Access policies are centrally defined and technically enforced, not policy-stated.

A.5.16 is addressed through automated User Lifecycle Management. Identity creation, modification, and deletion follow structured workflows. Birthright access is provisioned on joining. Role changes trigger re-provisioning. Departure triggers automated deprovisioning across all connected applications. SCIM-based provisioning synchronises lifecycle events to connected applications with full audit trail coverage. Akku’s ISO 27001 mapping shows User Lifecycle Manager addresses A.8.2 and A.11.5.

A.5.17 is addressed through Akku’s password management capabilities. Password policies enforce complexity, length, expiry, history, and lockout rules at the organisation, group, or role level. Self-service password reset reduces helpdesk burden while maintaining identity-verified reset flows. Password sync maintains consistent credentials across connected systems.

A.5.18 is addressed through access review and re-certification campaigns. Periodic certification requests go to managers and resource owners. Every decision is timestamped and logged. The output is an auditor-ready evidence record of who reviewed which entitlements, on which date, and what action resulted. Identity and Access Governance addresses A.5.18 across the largest single-module mapping count in Akku’s ISO 27001 documentation at 16 clause references.

Privileged Access Requirements Under A.8.2

A.8.2 is one of the most audit-intensive controls in ISO 27001:2022. It requires that the allocation and use of privileged access rights be restricted, controlled, and reviewed. Certification auditors examine A.8.2 with particular scrutiny because privileged access failures are disproportionately represented in security incidents at certified organisations.

What the control requires

A.8.2 requires that privileged access rights be allocated to users on a need-to-use basis and event-by-event basis in line with the access control policy. Users should not be given privileged access rights beyond what is required for their current function.

A.8.2 requires that a process exist for managing privileged access rights, including formal authorisation, defined scope, time limits where appropriate, and periodic review. Standing, unlimited privileged access with no defined scope or time limit is inconsistent with A.8.2’s requirements.

A.8.2 requires that the use of privileged access rights be logged and that logs be reviewed. Authentication records confirming that a privileged session occurred do not satisfy this requirement. The log must capture what happened during the privileged session.

How Akku addresses it

JIT access removes standing privilege entirely. No user holds persistent access to servers, databases, or Kubernetes clusters. Access is granted for the duration of an approved, time-bound session and revoked automatically on expiry. This is the event-by-event, need-to-use access model A.8.2 requires.

AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. The user never sees or types the target credential. This eliminates the shared, persistent credential problem that A.8.2’s allocation controls are designed to prevent.

SMARTAudit Trails satisfy A.8.2’s logging requirement. SSH sessions produce full screen recordings and complete keystroke logs. Database sessions produce structured SQL query capture. RDP sessions produce full screen video recordings. All recordings are indexed for forensic search and accessible from the Akku admin console. This is the session-level evidence that A.8.2 requires and that authentication logs cannot provide.

Periodic privileged access reviews ensure that privileged entitlements are certified regularly and that access no longer required is revoked. Akku’s ISO 27001 mapping shows Privileged Access Manager addresses A.8.3, A.16.2, A.16.6, A.16.7, and A.16.8.

User Activity Logging Requirements Under A.8.15

A.8.15 is one of the controls that the 2022 revision made more specific. The control requires logging and monitoring of user activities, exceptions, faults, and security events. The distinction between user activity logs and authentication logs is central to what A.8.15 requires, and it is a distinction that ISO 27001 certification auditors examine carefully.

What the control requires

A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and regularly reviewed. Logs must be protected against tampering and unauthorised access.

A.8.15 requires that the logging system be capable of capturing: user activities including commands executed and data accessed, exceptions and error events, security events including authentication failures and policy violations, and system events relevant to information security.

A.8.15 requires that log retention periods be defined and that logs be available for investigation when security incidents occur.

How Akku addresses it

For privileged users, SMARTAudit Trails produce the session-level activity logs A.8.15 requires. Every command executed in an SSH session is logged with a timestamp. Every SQL query executed in a database session is captured as structured data. Every screen action in an RDP session is recorded as video. These are user activity logs, not login event records.

For all users, Akku’s identity and access security monitoring captures login and session tracking across all connected applications with time, location, authentication factor, and outcome per event. Failed authentication attempts, MFA failures, and policy-triggered access blocks are captured as security events.

The audit log is append-only and tamper-evident. Existing records cannot be modified or deleted. Logs are exportable in JSON and CSV format and accessible via API for SIEM integration. This satisfies A.8.15’s tamper protection and availability requirements.

Akku’s ISO 27001 mapping shows SSO and IDP addresses A.8.5, A.11.7, A.16.1, A.16.4, and A.18.8, covering the authentication and access event logging layer that complements SMARTAudit Trails’ session activity logging.

Monitoring and Anomaly Detection Requirements Under A.8.16

A.8.16 is a new control in ISO 27001:2022 with no direct equivalent in the 2013 version. It requires that networks, systems, and applications be monitored for anomalous behaviour and that appropriate actions be taken when anomalies are detected. This moves the standard from reactive log review to proactive anomaly detection.

What the control requires

A.8.16 requires that monitoring procedures be established and implemented to detect anomalous behaviour in networks, systems, and applications. Monitoring must be capable of detecting potential information security incidents.

A.8.16 requires that monitoring results be evaluated regularly and that anomalies trigger defined response actions. Passive log storage that is reviewed only after an incident is reported does not satisfy the proactive monitoring requirement.

A.8.16 requires that monitoring cover the full environment including privileged access activity, authentication events, and network traffic where relevant.

How Akku addresses it

Akku’s Adaptive MFA provides the first layer of anomaly detection at the authentication layer. AI-powered anomaly detection evaluates each authentication event against the user’s behavioural baseline. Deviations in location, device, time-of-day, or access pattern trigger step-up authentication challenges and generate security events for review.

Risk and audit dashboards surface MFA failure spikes, geographic anomalies, access outside defined time windows, and behavioural deviations as actionable alerts. This is the proactive monitoring capability A.8.16 requires, not passive log storage.

For privileged access specifically, real-time session monitoring through AkkuReka allows administrators to view all active privileged sessions and terminate suspicious sessions instantly. Session termination events are logged with actor, timestamp, and reason.

Akku’s ISO 27001 mapping shows Adaptive MFA addresses Clauses 8.1, 8.3.a, A.8.1, A.8.4, A.11.7, A.16.3, A.16.4, A.18.1, and A.18.4 across nine clause references, the highest single-module count in the ISO 27001 mapping.

How IAM Addresses ISO 27001:2022 Annex A Obligations

Akku’s ISO 27001:2022 compliance mapping supports 41 unique clauses with 60 total mappings across 11 platform modules, covering Main Clauses 4 through 10 and Annex A controls.

The Identity and Access Governance module carries the highest clause count at 16, addressing Clauses 8.1, 8.1.a, 8.1.c, 8.1.d, 9.1, 9.1.c, A.8.1, A.8.2, A.8.4, A.9.4, A.9.6, A.11.5, A.15.3, A.16.3, A.16.6, and A.19.4. This reflects how central access governance, SoD enforcement, access reviews, and re-certification are to ISO 27001 certification. Adaptive MFA carries nine clause references. Mobile Device Manager carries seven. SSO and IDP carries five.

One important note on scope: Akku supports ISO 27001 by implementing technical security controls, access governance, monitoring, and audit evidence generation. It is not a compliance management system and does not by itself ensure ISO 27001 certification. Final certification depends on the organisation’s overall policies, processes, and risk management practices. The Annex A controls Akku addresses are the technical layer. The ISMS documentation, risk assessment, management review, and internal audit requirements in Clauses 4 through 10 require governance measures beyond what any technology platform provides.

Questions IT and Security Teams Ask About ISO 27001:2022 Annex A Access Controls

What changed in ISO 27001:2022 for access control and identity management compared to the 2013 version?

The 2022 revision consolidated the control set from 114 controls across 14 domains to 93 controls across four themes. Several new controls relevant to IAM were added: A.8.15 (logging) made activity logging requirements more explicit, A.8.16 (monitoring activities) added a proactive anomaly detection requirement with no direct 2013 equivalent, and A.8.18 (use of privileged utility programs) addressed privileged tool governance more specifically. Organisations certified under ISO 27001:2013 transitioning to the 2022 standard need to assess these additions against their current technical controls.

What evidence does a certification auditor expect for A.5.18 access rights review?

A certification auditor examining A.5.18 expects evidence of a structured, periodic access review process with documented outcomes. This typically includes the access review schedule and scope, evidence that reviews were conducted at the defined intervals, records showing which entitlements were reviewed and by whom, timestamped certification or revocation decisions for each entitlement reviewed, and evidence that revocations were actioned. An auditor who finds that access reviews are conducted informally, with outcomes recorded in email or spreadsheets, will likely raise a nonconformity.

Why does A.8.2 require session-level logging for privileged access rather than authentication records alone?

A.8.2 requires that the use of privileged access rights be logged and reviewed. Authentication records confirm that a privileged session occurred. They do not record what happened during the session: which commands were executed, which files were accessed, which configuration changes were made. For the purposes of security incident investigation, compliance audit evidence, and the accountability requirements A.8.2 imposes, session-level logs capturing actual activity are required. Authentication timestamps are a prerequisite for this logging, not a substitute for it.

What is the relationship between A.8.15 and A.8.16, and do they require separate technical controls?

A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced and kept. A.8.16 requires that networks, systems, and applications be monitored for anomalous behaviour and that anomalies trigger response actions. A.8.15 is about log generation and retention. A.8.16 is about active monitoring and anomaly detection. They require complementary but distinct technical controls. A.8.15 is satisfied by a structured logging infrastructure with tamper protection and defined retention. A.8.16 is satisfied by an active monitoring layer that evaluates events against baselines and generates alerts. Both are needed, and satisfying one does not satisfy the other.

How many ISO 27001:2022 Annex A controls does Akku address, and which areas are outside its scope?

Akku’s mapping supports 41 unique ISO 27001:2022 clauses with 60 total mappings, covering the identity management, access control, privileged access, authentication, logging, and monitoring controls. Controls outside Akku’s scope include physical security controls (A.7 theme), cryptographic key management beyond credential vault encryption, network security controls, vulnerability management, software development security controls, and business continuity management. Full ISO 27001 certification requires these technical controls combined with the ISMS governance, risk assessment, and documentation requirements in Clauses 4 through 10.

Can a single IAM deployment address both ISO 27001:2022 and SOC 2 Type II requirements simultaneously?

Yes. The overlapping technical controls are substantial. ISO 27001 A.8.5 and SOC 2 CC6.1 both require logical access security. ISO 27001 A.5.18 and SOC 2 CC6.3 both require periodic access rights review and modification. ISO 27001 A.8.2 and SOC 2 CC6.3 both require least-privilege access management for privileged users. ISO 27001 A.8.15 and SOC 2 CC7.2 both require activity logging and anomaly monitoring. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.

The Insurance Regulatory and Development Authority of India’s Information and Cyber Security Guidelines, 2023 apply to all insurers, re-insurers, and IRDAI-regulated intermediaries operating in India. The guidelines contain 348 checklist items in Annexure III covering identity and access management, endpoint security, privileged access, audit trails, user behaviour monitoring, and remote access controls. They are not advisory. Compliance is mandatory and subject to IS audit examination.

Most insurance IT teams are familiar with the guidelines at a summary level. The detailed technical implementation requirements within the 348-item checklist are less commonly mapped. Item 14 requires centralised authentication, not just SSO deployment but a specific architectural requirement with audit evidence implications. Item 52 requires MFA for network device management, an infrastructure-level requirement that many insurers have not extended beyond application-layer MFA. Items 144 and 145 require session-level audit trails for privileged access, not authentication logs alone.

This blog covers the IRDAI ICS Guidelines’ key technical requirements by category, what each requirement means at the implementation level, and how IAM controls address them. All item references are drawn directly from the IRDAI ICS Annexure III checklist and Akku’s IRDAI compliance mapping documentation, which covers 79 unique compliance requirements with 97 overlapping control mappings across the platform.

The IRDAI ICS Guidelines contain requirements for physical security, governance, disaster recovery, VAPT, and network controls that are outside the scope of IAM platforms. What follows covers the IAM-addressable technical controls layer specifically.

Scope and Applicability of IRDAI ICS Guidelines

The IRDAI ICS Guidelines apply broadly across the insurance sector. Understanding the full scope of applicability is important before mapping technical requirements, as the guidelines cover not only insurers but intermediaries and service providers operating within the sector.

Who the guidelines apply to

The guidelines apply to all insurers registered with IRDAI, including life insurers, general insurers, health insurers, and re-insurers. They also apply to insurance intermediaries including insurance brokers, corporate agents, web aggregators, and insurance marketing firms. Third-party administrators and other entities in the IRDAI-regulated ecosystem are expected to maintain equivalent security standards under their contractual and regulatory obligations.

Framework structure

The guidelines are structured around domains including identity and access management, endpoint security, network security, application security, data security, incident management, business continuity, and governance. Annexure III contains the 348-item compliance checklist that IS auditors use to assess compliance. Items are grouped by domain, and each item specifies a control requirement that must be technically implemented and evidenced.

Akku’s IRDAI compliance mapping covers 79 of the 348 checklist items, representing the IAM and endpoint security addressable subset of the framework. The remaining items cover network infrastructure, VAPT, physical security, governance, and disaster recovery requirements outside IAM scope.

Authentication and Access Control Requirements

Authentication and access control requirements appear across multiple checklist items in the IRDAI ICS Guidelines. The requirements extend from centralised authentication infrastructure through to MFA for specific access scenarios and need-based access governance.

What the guidelines require

Item 14 requires that all access to organisational systems be authenticated through a centralised authentication mechanism. Fragmented authentication, separate credentials per application, inconsistent MFA coverage, and siloed identity stores, does not satisfy this requirement. Centralised authentication implies a single identity source and a unified authentication layer across all systems.

Item 50 requires that access to systems processing sensitive data be restricted to authorised personnel on a need-to-know basis. Access must be role-based and reviewed periodically.

Item 52 requires MFA for managing network devices and for privileged access to critical systems. This is an infrastructure-level MFA requirement that extends beyond application-layer authentication.

Item 64 and Item 65 require MFA for remote access to organisational systems and for access to critical applications from outside the corporate network.

Item 135 requires that password policies enforce complexity, length, expiry, and history requirements. Password policies must be technically enforced, not policy-stated.

Item 148 requires step-up authentication for access to high-sensitivity systems, reflecting the same proportionate authentication model that SEBI CSCRF PR.AA.S7 requires.

How Akku addresses it

Akku’s unified cloud identity store and SSO infrastructure provide the centralised authentication mechanism Item 14 requires. All connected applications authenticate through the Akku identity layer. A single identity source eliminates fragmented credential infrastructure. Akku’s IRDAI mapping shows Cloud Directory and SSO together address Items 14, 50, 135, 176, 204, 298, and 300.

Adaptive MFA satisfies Items 52, 64, 65, 135, 148, 182, and 270. For infrastructure-level MFA required by Item 52, Akku extends authentication assurance to privileged sessions through PAM, enforcing MFA at the IAM layer before any session proxy connection opens to network devices, servers, or databases.

RBAC and ABAC enforce need-based access at the role level. Contextual access controls restrict access by device, IP, time-of-day, and location. Access Manager addresses Items 5, 87, 102, 111, 155, 157, 171, 175, 202, 204, 266, 298, and 299 across 13 total mappings.

Endpoint and Device Security Requirements Under Items 11 to 31

The IRDAI ICS Guidelines contain detailed endpoint security requirements that map to GPO and MDM controls. These items address session lockout, removable media, peripheral device governance, and URL filtering, reflecting the guidelines’ recognition that endpoint controls are a critical layer of data protection for insurance environments.

What the guidelines require

Item 11 requires automatic session lockout after a defined period of inactivity. This must be technically enforced at the endpoint, not policy-stated.

Item 15 requires controls on removable media including USB storage devices. Unauthorised USB usage is a data exfiltration vector that the guidelines specifically address.

Item 18 requires controls on the use of personal devices for accessing organisational systems. For BYOD environments, this maps to work profile isolation and device compliance enforcement.

Item 27 and Item 28 require that Bluetooth and wireless peripheral usage be controlled on managed endpoints, limiting data transfer and pairing risks.

Item 31 requires URL filtering to restrict access to high-risk or non-business web categories. This is a network-level control at the endpoint layer.

Item 36 and Item 37 require that screen capture and printing be restricted in environments processing sensitive data.

How Akku addresses it

Akku’s GPO Manager and MDM together address 31 of the 97 total IRDAI control mappings, the highest combined module count in the IRDAI mapping. This reflects how heavily the guidelines weight endpoint and device security controls.

GPO Manager enforces session lockout policies (Item 11), USB storage restrictions (Item 15), Bluetooth limitations (Item 28), screenshot and screen capture controls (Item 36 and 37), and URL filtering via DNS-based filtering (Item 31). Policies are defined centrally and enforced across Windows, macOS, and Linux endpoints from a single dashboard without dependence on Active Directory.

MDM addresses BYOD and corporate mobile device requirements including device enrollment and approval workflows, work profile isolation on Android devices preventing cross-profile data movement, app whitelisting, remote work-profile wipe, and device compliance enforcement. MDM and GPO together address 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.

Privileged Access and Session Monitoring Requirements

The IRDAI ICS Guidelines contain specific requirements for privileged access governance and session monitoring. Items 32, 52, 144, 147, and 151 together define a privileged access management standard that goes beyond credential storage to require session-level controls and audit evidence.

What the guidelines require

Item 32 requires that privileged access be granted only to authorised personnel and that privileged accounts be separately identified and managed.

Item 52 requires MFA for privileged access to critical systems and network devices, as noted above.

Item 144 requires that all privileged sessions be logged with sufficient detail to enable reconstruction of activities performed. Authentication records alone do not satisfy this requirement.

Item 147 requires that privileged access be reviewed periodically and that access no longer required be revoked promptly.

Item 151 requires that privileged credentials not be shared and that each privileged user have individual, accountable credentials.

Item 190 requires that privileged session activity be monitored in real time, not only retrospectively reviewed.

Item 206 requires that privileged access to production systems follow a formal request and approval process.

How Akku addresses it

AkkuArka generates per-session ephemeral credentials for every privileged session. No privileged user holds standing credentials to target systems. Each session uses a unique credential generated at approval and permanently revoked on close. This directly satisfies Item 151’s individual, non-shared credential requirement and Item 32’s separately managed privileged account requirement.

The session approval workflow satisfies Item 206. Every privileged session request includes target system, access level, duration, and justification. Approval decisions are logged with approver identity and timestamp. No session opens without approval when the workflow is enabled.

SMARTAudit Trails satisfy Item 144’s session-level logging requirement. SSH sessions produce full screen recordings and complete keystroke logs. Database sessions produce full screen recordings and structured SQL query capture. RDP sessions produce full screen video recordings. All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console.

Real-time session monitoring satisfies Item 190. Administrators view all active privileged sessions from the Akku admin console and can terminate any session instantly. Termination is recorded in the audit log.

Periodic access review and re-certification campaigns satisfy Item 147. Akku’s IRDAI mapping shows Privileged Access Manager addresses Items 32, 52, 144, 147, 151, 190, 202, 206, 266, and 274 across 10 total mappings.

Audit Trail and User Behaviour Monitoring Requirements

The IRDAI ICS Guidelines contain specific requirements for audit trail maintenance and user behaviour monitoring that go beyond standard authentication logging. Items 2, 5, 35, 54, and 55 together define an audit and monitoring standard that requires both structured log infrastructure and anomaly detection capability.

What the guidelines require

Item 2 requires that audit trails be maintained for all access to systems processing sensitive data, with sufficient detail for forensic investigation.

Item 5 requires that user behaviour monitoring be implemented to detect anomalies in login time, login location, session duration, and access patterns. Alerts must be generated when behaviour deviates from established baselines.

Item 35 requires that audit logs be protected against tampering and unauthorised modification. Logs must be retained for a defined period and available for regulatory examination.

Item 54 and Item 55 require that security events including failed authentication attempts, privilege escalation events, and policy violations be logged and reviewed.

Item 274 requires that audit trail evidence be producible for regulatory examination on demand.

Item 302 requires that access to audit log infrastructure itself be restricted and logged, preventing privileged users from modifying or deleting audit records.

How Akku addresses it

Akku’s centralised audit log architecture is append-only and tamper-evident. Existing records cannot be modified or deleted. This is the log integrity standard Items 35 and 302 require. Logs are exportable in JSON and CSV format for regulatory submission, satisfying Item 274’s on-demand evidence requirement.

SMARTAudit Trails provide the session-level logging that Item 2 requires for privileged access to sensitive data systems. Every privileged command and database query is captured, indexed, and searchable by timestamp, command string, or SQL query.

Akku’s identity and access security monitoring layer captures authentication anomalies for Item 5’s user behaviour monitoring requirement. Login time anomalies, geographic location changes, access outside configured time windows, and MFA failure spikes are surfaced through risk and audit dashboards. Configurable alerts notify administrators of behavioural deviations without waiting for manual log review.

Authentication event logging captures failed authentication attempts and MFA failures with actor identity, timestamp, source IP, and outcome, satisfying Items 54 and 55. Akku’s IRDAI mapping shows Audit Logs addresses Items 2, 5, 35, 54, 55, 144, 145, 274, and 302 across nine total mappings.

How IAM Addresses IRDAI ICS Technical Obligations

Akku’s IRDAI ICS compliance mapping covers 79 unique compliance requirements from the 348-item Annexure III checklist, with 97 overlapping control mappings across nine platform modules. The coverage reflects defence-in-depth across the identity, access, endpoint, privileged access, and audit trail layers of the guidelines.

The GPO Manager and MDM combination carries the highest combined mapping count at 31, reflecting the guidelines’ detailed endpoint security requirements. Access Manager carries 13 mappings across authentication, access control, and session management items. Privileged Access Manager carries 10 mappings across the privileged access governance and session monitoring items. Audit Logs carries nine mappings across the audit trail and user behaviour monitoring items.

An important scoping note: Akku covers IRDAI’s core identity and access security requirements. Exclusions are limited to non-IAM areas including physical security, governance, disaster recovery, VAPT, and network infrastructure controls. Akku does not guarantee full regulatory compliance on its own but provides a strong technical security baseline aligned with IRDAI expectations. Broader regulatory needs including governance, physical security, and network controls require additional measures addressed during implementation planning.

Questions Insurance IT Teams Ask About IAM Technical Controls Under IRDAI ICS Guidelines 2023

Which IRDAI-regulated entities are subject to the ICS Guidelines 2023?

The guidelines apply to all insurers registered with IRDAI including life, general, health, and re-insurers, as well as insurance intermediaries including brokers, corporate agents, web aggregators, and insurance marketing firms. Third-party administrators and other entities in the IRDAI-regulated ecosystem are expected to maintain equivalent standards under contractual and regulatory obligations. The 348-item Annexure III checklist is the assessment instrument IS auditors use to evaluate compliance across all in-scope entities.

What does Item 14 require for centralised authentication, and how is this different from simply deploying SSO?

Item 14 requires that all access to organisational systems be authenticated through a centralised authentication mechanism. SSO deployment satisfies part of this requirement by providing single sign-on across connected applications. Full satisfaction requires a single identity source, a unified authentication layer that all applications route through, consistent MFA enforcement across all systems, and a centralised audit trail of all authentication events. An SSO deployment that coexists with separate application-level credentials, or that covers only some systems, does not satisfy the centralisation requirement Item 14 imposes.

Why does Item 52 require MFA for network device management specifically, and what does this mean technically?

Network devices including routers, switches, and firewalls are high-value targets for attackers because compromising them enables broad lateral movement and traffic interception. Item 52 requires MFA for managing these devices because a stolen administrator password without a second factor provides unrestricted network access. Technically, this requires MFA enforcement at the infrastructure management layer, not only at application login screens. Akku extends MFA to infrastructure sessions through PAM, enforcing authentication at the IAM layer before any privileged session to network management interfaces opens.

What does Item 5 require for user behaviour monitoring, and how is this different from standard authentication logging?

Item 5 requires detection of anomalies in login time, login location, session duration, and access patterns, with alerts generated when behaviour deviates from established baselines. Standard authentication logging records that a login occurred. User behaviour monitoring requires a baseline of normal behaviour per user or user group and continuous comparison of new events against that baseline. Deviations, logging in from a new country, accessing systems at unusual hours, or session durations significantly longer than normal, must trigger alerts rather than being discovered during manual log review.

How does Akku’s SMARTAudit Trails capability satisfy IRDAI Item 144’s session logging requirement?

Item 144 requires that all privileged sessions be logged with sufficient detail to enable reconstruction of activities performed. SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka: full screen recordings for SSH and RDP sessions, complete keystroke logs per command for SSH, and structured SQL query capture for database sessions. Recordings are stored encrypted, indexed for forensic search by timestamp, command string, or SQL query, and accessible for in-browser playback. This session-level evidence satisfies the reconstruction requirement that authentication logs cannot provide.

Can a single IAM deployment address both IRDAI ICS and DPDPA requirements simultaneously?

Yes. The overlapping technical controls are substantial. IRDAI ICS Item 14 and DPDPA Clause 8(5) both require appropriate technical security measures including centralised authentication. IRDAI ICS Item 144 and DPDPA Clause 8(5) both require audit trail infrastructure for privileged access to sensitive data systems. IRDAI ICS Item 50 and DPDPA Clause 8(4) both require need-based access controls for sensitive data. A single Akku deployment implementing these controls produces compliance evidence for both frameworks from the same technical infrastructure.

The Securities and Exchange Board of India’s Cybersecurity and Cyber Resilience Framework applies to all SEBI-regulated entities: stock brokers, depository participants, asset management companies, portfolio managers, investment advisers, registrars and transfer agents, and market infrastructure institutions. It is one of the most technically detailed cybersecurity frameworks issued by any Indian regulator, with 232 guidelines in Part II covering identity management, access controls, privileged access, audit logging, monitoring, and incident response.

SEBI CSCRF is structured around six functions drawn from the NIST Cybersecurity Framework: Govern, Identify, Protect, Detect, Respond, and Evolve. The Protect function, specifically the Access Authentication sub-category PR.AA, carries the largest concentration of IAM-relevant requirements. The Detect function under DE.CM and the Govern function under GV.OC add audit logging, monitoring, and on-demand log access requirements that many entities are not currently meeting.

The framework differentiates between entity tiers. Market Infrastructure Institutions, Qualified REs, and Mid-size REs face progressively higher requirements. This blog covers the requirements that apply across entity types, with specific clause references drawn from the SEBI CSCRF Part II guidelines and Akku’s SEBI compliance mapping documentation, which covers 88 unique compliance items with 145 total clause mappings across the platform.

CSCRF Framework Structure and Applicability

Understanding how SEBI CSCRF is structured is necessary before mapping individual requirements to technical controls. The framework’s six-function structure determines where each requirement sits and how audit evidence is organised.

Framework structure

The six functions are Govern (GV), Identify (ID), Protect (PR), Detect (DE), Respond (RS), and Evolve (EV). Each function contains sub-categories, and each sub-category contains specific guidelines at multiple tiers.

The Protect function contains the Access Authentication sub-category (PR.AA), which runs from PR.AA.S1 through PR.AA.S17 and covers identity management, credential management, access provisioning, MFA, privileged access, remote access, and external user access. This single sub-category accounts for a large proportion of the IAM-relevant requirements in the framework.

The Govern function contains the Organisational Context sub-category (GV.OC) and the Policy sub-category (GV.PO), which include requirements for on-demand log access and domain-specific security policy enforcement. The Detect function contains the Continuous Monitoring sub-category (DE.CM), which requires continuous monitoring of authentication events and access patterns.

Tiered applicability

Market Infrastructure Institutions face the highest tier requirements across all six functions. Qualified REs, defined by trading volume, assets under management, or number of clients above defined thresholds, face enhanced requirements in several sub-categories. Mid-size and Small REs face the baseline requirements. The specific tier an entity falls into determines which guideline levels within each sub-category apply.

Identity and Access Management Requirements Under PR.AA

PR.AA is the access authentication sub-category and contains the most detailed IAM requirements in the framework. It covers identity management, access provisioning, credential management, MFA, and access control policy enforcement.

What the framework requires

PR.AA.S1 requires that all users be uniquely identified and that identity be managed through a centralised system. Shared accounts and generic credentials are explicitly inconsistent with this requirement. Akku’s SEBI mapping shows Cloud Directory addresses PR.AA.S1 and several related guidelines.

PR.AA.S6 requires strong credential management including password policies, credential storage security, and credential lifecycle management. Akku’s mapping shows Password Manager addresses PR.AA.S6 across eight guideline mappings.

PR.AA.S4 and PR.AA.S5 require access control based on the principle of least privilege, with access provisioned only to the extent required for the user’s current role and function. Access Manager addresses PR.AA.S4 and PR.AA.S5 across 13 guideline mappings, the highest single-module count after GPO Manager and Audit Logs.

PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource being accessed. This is the proportionate, risk-based authentication requirement that Adaptive MFA is specifically designed to satisfy. Akku’s mapping shows Adaptive MFA addresses PR.AA.S7 and 10 additional guideline references across the PR.AA sub-category.

PR.AA.S15 requires endpoint security controls to ensure that only compliant, authorised devices access organisational systems. This maps to MDM and GPO controls for device compliance enforcement. Akku’s mapping shows GPO Manager addresses PR.AA.S15 across multiple guideline references, and Mobile Device Manager addresses it across 21 total guideline mappings, the highest single-module count in the entire SEBI mapping.

PR.AA.S16 and PR.AA.S17 cover external user and customer access controls, including authentication requirements for non-employee users accessing organisational systems or customer-facing platforms.

How Akku addresses it

Akku’s unified cloud identity store provides the centralised identity management infrastructure that PR.AA.S1 requires. Every user has a unique identity in the Akku directory. SSO with a centralised IdP consolidates authentication across applications, eliminating the fragmented credential landscape that PR.AA.S1 is designed to prevent.

RBAC and ABAC enforce least privilege at the access layer. The IGA SoD rules engine enforces segregation of duties, detecting conflicting role combinations and triggering remediation. Contextual access controls apply IP, device, time-of-day, and geo-location restrictions, satisfying PR.AA.S4’s risk-based access control requirement.

Adaptive MFA evaluates risk signals at each authentication event and escalates the challenge proportionately. This is the authentication model PR.AA.S7 requires. For privileged infrastructure access, MFA is enforced at the IAM layer through PAM before any session proxy connection opens.

Privileged Access Requirements Under PR.AA.S10 to S12

PR.AA.S10 through S12 address privileged access management specifically. These guidelines require that privileged accounts be separately managed, that privileged sessions be monitored and logged, and that privileged access be granted on a just-in-time basis where possible.

What the framework requires

PR.AA.S10 requires that privileged accounts be separately identified, managed, and monitored. Privileged users must not use privileged credentials for routine, non-administrative tasks.

PR.AA.S11 requires that privileged access be granted based on formal approval, with access scope defined and time-limited where possible. Standing privilege with no defined scope or time limit is inconsistent with this requirement.

PR.AA.S12 requires that all privileged sessions be logged with sufficient detail to reconstruct the actions taken. Authentication records alone do not satisfy this requirement.

GV.RM.S1 and GV.RM.S2 require that risk management controls include governance of high-privilege access as a specific risk category.

How Akku addresses it

AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. No privileged user holds standing credentials to target systems. This directly satisfies PR.AA.S11’s time-limited, scope-defined access requirement.

The session approval workflow produces the formal authorisation record PR.AA.S11 requires. Every privileged session request includes target system, requested access level, duration, and justification. Approval decisions are logged with approver identity and timestamp.

SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka. SSH sessions produce full screen recordings and complete keystroke logs. Database sessions produce full screen recordings and structured SQL query capture. This is the session-level evidence that PR.AA.S12 requires and that authentication logs cannot provide.

Real-time session monitoring allows administrators to view all active privileged sessions and terminate any session instantly. Session termination is recorded in the audit log with actor, timestamp, and reason. Akku’s SEBI mapping shows Privileged Access Manager addresses PR.AA.S11, PR.AA.S10 to S12 guidelines, and GV.RM.S1 to S2 references across 12 total guideline mappings.

Audit Log and Monitoring Requirements Under DE.CM and GV.OC

The Detect function’s continuous monitoring requirements and the Govern function’s on-demand log access requirements are where many SEBI-regulated entities have significant compliance gaps. The requirements go beyond storing logs to requiring structured, searchable, exportable audit trails accessible to SEBI on demand.

What the framework requires

GV.OC.S2(G2) requires that logs, user details, and application data be accessible to SEBI on demand. This is not a notification requirement. It is an on-demand data access obligation. The infrastructure must be capable of producing structured log exports at any time, covering any requested period.

GV.OC.S2(G3) requires that privileged user responsibilities be formally defined and that audit records reflect the scope of each privileged user’s authorised activities.

DE.CM.S1 through S3 require continuous monitoring of system components, including authentication events, access patterns, and privileged activity. Monitoring must be capable of detecting anomalies and generating alerts.

PR.AA.S8 requires that all authentication events be logged with actor identity, timestamp, source, and outcome. PR.AA.S12 requires that privileged session activity be logged at the command and query level.

RS.AN.S1 through S5 require that incident response activities be supported by structured log evidence enabling rapid scoping and attribution of security incidents.

How Akku addresses it

Akku’s audit log architecture is append-only and tamper-evident. Every authentication event, access event, privileged session lifecycle event, administrative action, and policy change produces a structured log record. Logs are exportable in JSON and CSV format and accessible via API for programmatic integration with SIEM and log aggregation platforms.

The GV.OC.S2(G3) on-demand access requirement is satisfied through Akku’s exportable audit trail infrastructure. Log exports can be produced for any time period, filtered by user, system, event type, or outcome, and submitted to SEBI in structured format.

SMARTAudit Trails provide the session-level logging that DE.CM and PR.AA.S12 require for privileged access. Every privileged command and database query is captured, indexed, and searchable. This is the evidence layer that supports the incident response scoping requirements in RS.AN.

Akku’s identity and access security monitoring layer captures authentication anomalies including MFA failure spikes, logins from new geographic locations, access outside defined time windows, and behavioural deviations. Risk and audit dashboards surface these patterns for investigation. Akku’s SEBI mapping shows the Audit Logs module addresses 20 guideline references, the second highest after Mobile Device Manager’s 21.

Dormant Account and Lifecycle Management Requirements

SEBI CSCRF contains specific requirements for dormant account management and user lifecycle controls that are frequently underimplemented at regulated entities. Dormant accounts with active credentials represent a persistent access risk that several PR.AA guidelines specifically address.

What the framework requires

PR.AA.S1(G1g) and PR.AA.S1(G1h) require that user accounts inactive beyond a defined threshold be automatically disabled. Manual processes for dormant account identification and disabling are insufficient at the scale most regulated entities operate.

PR.AA.S6(G2) requires that credentials associated with dormant or terminated accounts be revoked or invalidated. An account that is disabled at the application layer but retains valid credentials in a connected system is not fully deprovisioned.

GV.SC.S4 requires that third-party and supply chain access be governed through the same lifecycle controls as internal users, including time-bound access and prompt revocation on engagement end.

PR.DS.S6(G3) requires that data access entitlements be reviewed when users change roles or functions, not only at termination.

How Akku addresses it

Automated User Lifecycle Management covers the full joiner-mover-leaver workflow with automated dormant account detection. Accounts inactive beyond a configured threshold are automatically flagged and disabled. The detection run and disabling action produce a timestamped audit record of the dormant account management process.

The IGA orphan account management capability detects accounts without a linked, active identity across all connected applications, including accounts created during migrations, temporary access grants, and incomplete deprovisioning from prior role changes. These are surfaced for resolution through deletion or reassignment.

SCIM-based automated provisioning ensures that deprovisioning actions in Akku propagate to connected applications. Access revoked in the IAM layer is removed from downstream systems without manual intervention. Connector health monitoring detects silent sync failures before they result in access gaps.

Access review and re-certification campaigns address PR.DS.S6(G3)’s role-change access review requirement. When a user changes roles, a targeted recertification of their existing entitlements can be triggered, ensuring that access accumulated in the previous role is reviewed and revoked where no longer appropriate. Akku’s SEBI mapping shows User Lifecycle Manager addresses seven guideline references across PR.AA.S1, GV.SC.S4, and PR.DS.S6.

How IAM Addresses SEBI CSCRF’s Technical Obligations

Akku’s SEBI CSCRF compliance mapping covers 88 unique compliance items from the 232 Part II guidelines, with 145 total clause mappings across 12 platform modules. This is the highest compliance coverage number across all frameworks in Akku’s mapping documentation, reflecting the CSCRF’s detailed and technically specific requirements in the areas that IAM directly addresses.

The module coverage breakdown reflects the framework’s emphasis on endpoint governance and audit trail depth. Mobile Device Manager carries 21 guideline mappings, the highest single-module count, reflecting SEBI CSCRF’s detailed device and endpoint security requirements across PR.AA.S15, PR.AA.S16 to S17, and PR.DS.S1 to S3. GPO Manager carries 17 mappings across device access, data protection, and network controls. Audit Logs carries 20 mappings covering GV.OC, PR.AA.S8, PR.AA.S12, DE.CM, RS.AN, and EV.ST sub-categories.

An important scoping note: the 88 compliance items Akku covers represent the IAM and endpoint security addressable layer of SEBI CSCRF. The remaining guidelines cover network security, vulnerability management, business continuity, incident management, and governance requirements that are outside the scope of IAM platforms. Full CSCRF compliance requires these technical controls combined with the operational and governance measures the framework’s remaining requirements specify.

Questions SEBI-Regulated Entities Ask About IAM Technical Controls Under CSCRF

Which SEBI-regulated entities are subject to CSCRF and what determines their tier?

SEBI CSCRF applies to all SEBI-regulated entities including stock brokers, depository participants, asset management companies, portfolio managers, investment advisers, registrars and transfer agents, and market infrastructure institutions. Entity tier is determined by factors including trading volume, assets under management, number of clients, and systemic importance. Market Infrastructure Institutions face the highest tier requirements. Qualified REs face enhanced requirements above the baseline. Mid-size and Small REs face baseline requirements. Entities should assess their tier classification carefully as it determines which guideline levels within each sub-category apply.

What does SEBI CSCRF PR.AA.S7 require for authentication, and how does adaptive MFA satisfy it?

PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource being accessed. This proportionality requirement means that high-sensitivity systems require stronger authentication than low-sensitivity ones, and that the authentication model must be capable of adjusting based on risk context. Adaptive MFA satisfies this by evaluating risk signals at each authentication event including device posture, location, IP reputation, and behavioural baseline, and escalating the challenge for high-sensitivity access or anomalous contexts. Static MFA applied uniformly does not satisfy the proportionality requirement.

What does GV.OC.S2(G3) require for on-demand log access, and what does this mean technically?

GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. Technically, this means the audit infrastructure must be capable of producing structured log exports covering any requested time period, filtered by user, system, or event type, in a format SEBI can examine. This requires an append-only, tamper-evident audit log with structured export capability, not a collection of application-specific logs that require manual compilation. The integrity of the log must also be demonstrable, meaning records cannot have been modified after the fact.

How does SEBI CSCRF address dormant account management, and what does automated disabling require technically?

PR.AA.S1(G1g) and G1h require that accounts inactive beyond a defined threshold be automatically disabled. Technically, this requires an identity governance platform that monitors last-activity timestamps across connected applications, compares them against a configured inactivity threshold, and triggers automatic account disabling without manual intervention. The disabling action must produce a timestamped audit record. Manual dormant account reviews conducted periodically do not satisfy the automation requirement at the scale most SEBI-regulated entities operate.

What is the difference between PR.AA.S11 and PR.AA.S12, and why do both require separate technical controls?

PR.AA.S11 covers the authorisation and governance of privileged access: how access is requested, approved, scoped, and time-limited. PR.AA.S12 covers the logging of privileged session activity: what the privileged user did once access was granted. Both are required but they address different layers. PR.AA.S11 is satisfied by a structured session request and approval workflow with per-session ephemeral credentials and JIT access. PR.AA.S12 is satisfied by protocol-level session recording through SMARTAudit Trails capturing keystrokes and SQL queries. Satisfying one does not satisfy the other.

Can a single IAM deployment address both SEBI CSCRF and ISO 27001 requirements simultaneously?

Yes. The overlapping technical controls are substantial. SEBI CSCRF PR.AA.S7 and ISO 27001 A.8.5 both require secure, proportionate authentication. SEBI CSCRF PR.AA.S12 and ISO 27001 A.8.15 both require user activity logging beyond authentication records. SEBI CSCRF PR.AA.S11 and ISO 27001 A.8.2 both require least-privilege, time-bound privileged access. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.

The Reserve Bank of India’s 2023 Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices applies to all RBI-regulated entities: scheduled commercial banks, urban cooperative banks, NBFCs, and payment system operators. It is not a guidance document. It is a mandatory framework with 103 compliance items spanning governance, access controls, audit trails, privileged access management, and teleworking security.

Most IT teams at regulated entities are familiar with the framework at the policy level. Fewer have mapped the specific technical controls each clause requires and assessed whether their current infrastructure produces the evidence an RBI IS audit would expect. An access control policy that states need-based access is required does not satisfy Clause 19(a). A technical implementation of RBAC with structured provisioning records and periodic review evidence does.

This blog covers the RBI framework’s key technical requirements clause by clause, what each clause requires at the implementation level, and how IAM controls address them. All clause references are drawn directly from the RBI 2023 Master Direction and Akku’s RBI compliance mapping documentation, which covers 20 actionable technical clauses across Chapters III, IV, and VI, resulting in 30 total clause mappings across the platform.

The RBI framework contains a significant number of governance, physical security, and IT operations requirements that sit outside the scope of IAM platforms. Board-level IT governance structures, IT risk management frameworks, business continuity planning, and vendor management obligations are not addressed here. What follows covers the IAM-addressable technical controls layer specifically.

Governance and IT Risk Management Requirements

The RBI framework establishes governance requirements that create the organisational context within which technical controls operate. Several of these have direct technical implications for identity and access management infrastructure.

What the framework requires

Clause 8(c) requires regulated entities to implement controls that ensure only authorised users have access to information systems, and that access rights are commensurate with the user’s role and responsibilities. This is a direct access governance requirement with audit evidence implications.

Clause 9(b) requires effective segregation of duties in IT operations and application development environments. This is not satisfied by a policy stating that SoD is required. It requires a technical enforcement mechanism that prevents conflicting role combinations and detects violations.

Clause 15(a), 15(b), and 15(c) require audit trails that capture system access, data modifications, and security events in a format suitable for forensic investigation and dispute resolution. Clause 15 is one of the most technically demanding requirements in the framework.

How IAM addresses it

Clause 8(c) is addressed through RBAC with structured provisioning workflows. Every access grant must be tied to a role definition, authorised through a documented approval process, and reviewable on demand. Akku’s access governance module produces the provisioning audit trail that Clause 8(c) requires: requester, approver, justification, timestamp, and downstream provisioning confirmation for every access grant.

Clause 9(b) is addressed through the IGA SoD rules engine. The engine defines conflicting role combinations, detects violations continuously across connected applications, and triggers automated remediation workflows. The violation detection log and remediation record constitute the technical evidence of SoD enforcement that Clause 9(b) requires.

Clause 15 is addressed through Akku’s centralised audit log architecture. The audit log captures authentication events, access events, privileged session activity, administrative actions, and policy changes in a structured, append-only, tamper-evident format. Akku’s RBI compliance mapping shows the Audit Logs module addresses seven RBI clauses: 8(c), 15(a), 15(b), 15(c), 25(c), 27(b), and 30(f).

Access Control Requirements Under Clause 19

Clause 19 is the most detailed access control provision in the RBI framework. It establishes requirements for need-based access, privileged user supervision, and MFA for critical system access. Each sub-clause has specific technical implementation requirements.

What the framework requires

Clause 19(a) requires that access to information systems be granted on a need-to-know and need-to-do basis. Access rights must be commensurate with the user’s current role and responsibilities. Access must be revoked promptly when the need ends or the user’s role changes.

Clause 19(c) requires multi-factor authentication for privileged users accessing critical information systems. This extends beyond customer-facing authentication to administrator and privileged user access to servers, databases, network devices, and core banking systems.

Clause 20(a) requires that access to information systems be granted through a centralised identity management system. Fragmented identity infrastructure, separate directories and authentication systems per application, does not satisfy this requirement.

Clause 23(a) requires that user access rights be reviewed periodically to ensure they remain appropriate to the user’s current role.

Clause 25(c) requires that all access to critical systems be logged and that logs be retained for a defined period sufficient for forensic investigation.

How IAM addresses it

Clause 19(a) is addressed through RBAC, JIT access for privileged users, and automated lifecycle management. Role definitions determine access scope. JIT access eliminates standing privilege for infrastructure access. Automated deprovisioning ensures access is revoked when roles change or employment ends. The provisioning and deprovisioning audit trail provides the evidence of need-based access management.

Clause 19(c) is addressed through Akku’s Adaptive MFA, which extends authentication assurance to infrastructure sessions through PAM. Every privileged session to SSH servers, RDP hosts, databases, and Kubernetes clusters requires MFA at the IAM layer before the session proxy connection opens. Akku’s RBI mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b).

Clause 20(a) is addressed through Akku’s unified cloud identity store, which serves as the centralised identity source for all connected applications. SSO with a centralised IdP consolidates authentication across cloud SaaS, legacy systems, and custom internal applications into a single identity infrastructure. Akku’s RBI mapping shows SSO and IDP addresses Clause 20(a) and Cloud Directory addresses Clause 23(a).

Clause 23(a) is addressed through access review and re-certification campaigns. Periodic certification requests go to managers and resource owners. Every decision is timestamped and logged. The output is the auditor-ready evidence of periodic access review that Clause 23(a) requires.

Audit Trail Requirements Under Clause 15

Clause 15 sets the evidentiary standard for audit trails at RBI-regulated entities. It is one of the requirements most organisations satisfy at the surface level but fail at the depth level. Logging that authentication events occurred is not the same as logging what happened inside authenticated sessions.

What the framework requires

Clause 15(a) requires audit trails that record all access to information systems, including successful and failed authentication attempts, with sufficient detail to enable forensic investigation.

Clause 15(b) requires audit trails that capture data modifications, system configuration changes, and administrative actions with actor identity, timestamp, and before-and-after state where applicable.

Clause 15(c) requires that audit trails be protected against modification, deletion, or tampering. Trails must be retained for a period defined in the regulated entity’s IT policy, and must be available on demand for regulatory examination.

How IAM addresses it

Clause 15(a) is addressed through Akku’s centralised authentication event logging. Every authentication event, successful or failed, produces a structured log record containing actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. This event stream is the foundation of the forensic audit trail Clause 15(a) requires.

For privileged sessions specifically, Clause 15(a) requires more than authentication records. SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka: full screen recordings for SSH and RDP sessions, complete keystroke logs for SSH, and structured SQL query capture for database sessions. This session-level evidence is what makes the audit trail suitable for forensic investigation and dispute resolution as Clause 15 requires.

Clause 15(b) is addressed through Akku’s administrative event logging, which captures role assignments and removals, policy changes, target system additions and removals, user provisioning and deprovisioning events, and approval decisions with approver identity and timestamp.

Clause 15(c) is addressed through the append-only, tamper-evident audit log architecture. Existing records cannot be modified or deleted. Logs are exportable in structured JSON and CSV formats for regulatory submission. API access enables programmatic integration with SIEM and log aggregation platforms.

Privileged Access Requirements Under Clause 19(b)

Clause 19(b) specifically addresses the supervision and monitoring of privileged users. It is the clause that most directly maps to PAM capabilities, and it is frequently the area where regulated entities have the largest compliance gap.

What the framework requires

Clause 19(b) requires close supervision of privileged users, with logged system activities sufficient to reconstruct what actions were taken during privileged sessions. The supervision requirement implies real-time visibility into active privileged sessions, not just historical log review.

Clause 19(c) requires MFA for privileged users accessing critical information systems, as noted above.

Clause 23(c) requires that privileged access be restricted to authorised personnel and that privileged sessions be monitored and logged.

How IAM addresses it

Clause 19(b) is addressed through AkkuReka’s session proxy architecture and SMARTAudit Trails. Every privileged session is brokered through AkkuReka. No direct connection between a privileged user and a target system exists outside the proxy. This architectural control ensures that every privileged action is visible to the platform regardless of what the user attempts to do.

Real-time session monitoring allows administrators to view all active privileged sessions from the Akku admin console. Any live session can be terminated instantly. Session termination is recorded in the audit log with actor, timestamp, and reason. This is the “close supervision” capability that Clause 19(b) requires.

AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer by AkkuReka, and permanently revoked on session close. The user never sees or types the actual target credential. This eliminates the standing credential risk that makes privileged account compromise the highest-impact attack vector in regulated entity environments.

The session approval workflow provides the authorisation record Clause 19(b) requires. Every privileged session request includes the target system, requested access level, duration, and justification. Approval and denial decisions are logged with approver identity and timestamp. No session opens without approval when the workflow is enabled.

Akku’s RBI mapping shows the Privileged Access Manager addresses Clauses 19(b), 19(c), and 23(c).

Teleworking and Remote Access Requirements Under Clause 20

Clause 20 addresses the security controls required for remote workforce access to information systems. As distributed work has become standard operating practice, the gap between policy-stated remote access controls and technically-enforced ones has become a primary audit focus.

What the framework requires

Clause 20(a) requires that remote access to information systems be provided through a secure, centralised authentication mechanism. Fragmented remote access, separate VPN credentials, application-specific passwords, and inconsistent MFA coverage, does not satisfy this requirement.

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

Clause 20(c) requires that remote access sessions be logged with sufficient detail to enable identification of the user, the systems accessed, and the actions taken.

Clause 20(d) requires that remote access be restricted to authorised devices and that device compliance be verified before access is granted.

How IAM addresses it

Clause 20(a) is addressed through Akku’s centralised SSO and identity provider infrastructure. All remote access routes through the Akku identity layer, providing a single point of authentication and a single point of audit trail generation regardless of which application or system the user is accessing.

Clause 20(b) is addressed through Adaptive MFA applied to all authentication events, with step-up challenges triggered for access to critical systems. Remote access from unrecognised locations, new devices, or outside normal hours automatically escalates the authentication challenge. Akku’s RBI mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b).

Clause 20(c) is addressed through the centralised authentication event log and session activity logging. Every remote session produces a structured audit record. For privileged remote sessions, SMARTAudit Trails provide protocol-level session recording.

Clause 20(d) is addressed through device-based contextual access controls. Access can be restricted to registered, compliant, or company-owned devices. Unregistered personal devices can be blocked at the access policy layer. Akku’s RBI mapping shows the Mobile Device Manager and GPO Manager address Clauses 20(c), 20(d), 23(d), and 25(b).

How IAM Addresses RBI’s Technical Obligations

Akku’s RBI compliance mapping covers 20 actionable technical clauses from the 2023 Master Direction, resulting in 30 total clause mappings across 12 platform modules. The coverage spans the access control, audit trail, privileged access, and remote access requirements that constitute the IAM-addressable layer of the framework.

The module with the highest clause coverage is Audit Logs, addressing seven clauses: 8(c), 15(a), 15(b), 15(c), 25(c), 27(b), and 30(f). This reflects the central role that structured, tamper-evident audit trail generation plays in RBI compliance. Access Manager addresses five clauses: 10(d), 19(a), 20(a), 23(c), and 25(c). Privileged Access Manager addresses three: 19(b), 19(c), and 23(c). Mobile Device Manager addresses four: 20(c), 20(d), 23(d), and 25(b).

An important note on scope: Akku does not cover all 103 RBI 2023 Master Direction requirements. Many relate to governance, physical security, business continuity, vendor management, and IT operations that are outside the scope of IAM software. Akku implements the critical identity, access, and monitoring controls that support RBI’s baseline cybersecurity expectations. Full compliance requires these technical controls combined with the governance and operational measures that the framework’s remaining clauses require.

Questions RBI-Regulated Entities Ask About IAM Technical Controls Under the 2023 Master Direction

Which chapters of the RBI 2023 Master Direction contain the primary IAM-relevant requirements?

Chapters III, IV, and VI contain the primary IAM-addressable requirements. Chapter III covers IT governance and risk management, including access control governance under Clause 8(c) and SoD under Clause 9(b). Chapter IV covers IT operations and covers audit trail requirements under Clause 15 and access controls under Clause 19. Chapter VI covers information and cybersecurity, covering privileged access supervision under Clause 19(b) and remote access controls under Clause 20. Akku’s compliance mapping covers 20 actionable technical clauses across these three chapters.

Does RBI Clause 19(c) require MFA only for customer-facing systems or for internal systems as well?

Clause 19(c) requires MFA for privileged users accessing critical information systems. This applies to internal systems including core banking platforms, database servers, network infrastructure, and any system classified as critical under the regulated entity’s IT risk framework. Customer-facing MFA for internet banking is a separate requirement. Clause 19(c) specifically addresses privileged user authentication to critical backend systems, which is where most regulated entities have an MFA coverage gap.

What is the difference between an audit log and an audit trail under RBI Clause 15?

The RBI framework uses audit trail to describe a record suitable for forensic investigation and dispute resolution. An audit log is a record that an event occurred. An audit trail is a record sufficient to reconstruct what happened: who accessed what system, when, from where, what actions they took, and what the state of the system was before and after. For privileged sessions, this requires session-level recording including keystroke logs and query capture, not authentication timestamps alone. Clause 15’s forensic investigation standard requires the latter.

How does RBI Clause 20 apply to NBFCs and fintechs with fully distributed workforces?

Clause 20 applies to all RBI-regulated entities and is technology-neutral in its requirements. A fully distributed workforce does not exempt an entity from the centralised authentication, MFA, session logging, and device compliance requirements. For entities with no physical office presence, the practical implication is that all access must route through a centralised identity layer with consistent MFA enforcement and unified audit trail generation, regardless of where employees are located or what devices they use.

What evidence does an RBI IS audit expect for Clause 19(b) privileged access supervision?

RBI IS auditors examining Clause 19(b) compliance typically look for evidence of a structured privileged access request and approval process with logged decisions, session recordings or keystroke logs demonstrating that privileged session activity was captured, evidence that privileged credentials are not shared or persistent, real-time monitoring capability for active privileged sessions, and periodic review records showing that privileged access entitlements are certified regularly. Per-session ephemeral credentials, session recordings through SMARTAudit Trails, and a structured JIT access workflow collectively produce this evidence set.

Can a single IAM deployment address both RBI and ISO 27001 requirements simultaneously?

Yes. The overlapping technical controls are substantial. RBI Clause 19(c) and ISO 27001 A.8.5 both require secure authentication for privileged users. RBI Clause 15 and ISO 27001 A.8.15 both require user activity logging beyond authentication records. RBI Clause 19(a) and ISO 27001 A.8.2 both require least-privilege, need-based access for privileged users. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.

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.

The Digital Personal Data Protection Act, 2023 is not a policy compliance exercise. The obligations it creates land directly on your IT infrastructure. Consent must be captured, stored, and made withdrawable through a technical system. Access to personal data must be controlled and auditable. Data Principal rights including access, correction, and erasure require automated workflows to fulfil within the timeframes the Act implies. Breach notification requires the ability to identify what data was affected, who had access to it, and when.

Most IT teams approaching DPDPA are doing so through a legal and compliance lens: reading the Act, mapping obligations, writing policies. The technical implementation is a separate and more demanding exercise. A policy stating that consent will be obtained is not a consent management system. A policy stating that access will be controlled is not an access control implementation.

This blog covers what DPDPA specifically requires at the technical layer, clause by clause, across consent management, access controls, data principal rights, and audit readiness. All control references are drawn directly from the Act and from Akku’s DPDPA compliance mapping documentation.

DPDPA compliance covers both technical and organisational obligations. Board-level governance, data protection policies, vendor contracts, and the appointment of a Data Protection Officer are outside the scope of what any technology platform addresses. What follows covers the technical and system-driven layer specifically.

Consent Management Requirements Under DPDPA

Consent is the primary lawful basis for processing personal data under DPDPA for most organisations. The Act sets specific technical requirements for how consent must be obtained, recorded, managed, and withdrawn. These requirements cannot be satisfied by a checkbox on a web form backed by no structured data infrastructure.

What the Act requires

DPDPA Clause 5(1) requires that a notice be given to the Data Principal before consent is sought. That notice must be in clear and plain language, specifying the personal data to be collected and the purpose of processing. Clause 5(2) requires that existing consents obtained without a compliant notice be refreshed.

Clause 6(1) requires that consent be free, specific, informed, unconditional, and unambiguous. Clause 6(3) requires that consent be as easy to withdraw as it is to give. Clause 6(4) requires that processing cease and data be erased when consent is withdrawn, subject to legal retention obligations. Clause 6(7) requires that consent records be maintained.

Clause 9(1) requires additional protections for processing personal data of children, including verifiable parental consent.

What this requires technically

A technically compliant consent system must version notices so that each version is tied to the consent records obtained under it. When the notice changes, affected Data Principals must be re-consented under the new version. This is not achievable with a static terms-and-conditions page.

Consent records must be timestamped, tied to a specific Data Principal identity, linked to a specific notice version, and scoped to a specific processing purpose. A single consent record covering all processing purposes does not satisfy Clause 6(1)’s specificity requirement.

Withdrawal must be operationalised as a self-service workflow that the Data Principal can initiate without contacting support. When withdrawal is received, the downstream systems must be notified to cease processing. For workforce systems, this maps to deprovisioning access to personal data systems. For customer-facing systems, this maps to CIAM consent withdrawal workflows.

Akku’s CIAM Consent Manager addresses Clauses 4(1), 5(1), 5(2), 5(3), 6(1), 6(3), 6(4), 6(7), 8(3), and 9(1) directly. It provides centralised consent record storage, versioned notice management, preference management across channels, full consent audit trails for every update, and withdrawal workflows that trigger downstream processing cessation. Akku’s DPDPA compliance mapping shows 19 of the 33 total clause mappings are carried by the CIAM Consent Manager module, reflecting how central consent infrastructure is to the Act’s technical requirements.

Access Control Requirements Under Clause 8

Clause 8 of DPDPA imposes a direct obligation on Data Fiduciaries to implement technical and organisational measures to ensure that personal data is processed only for the purposes for which it was collected, and that access is limited to authorised personnel. This is an IT engineering obligation, not a policy statement.

What the Act requires

Clause 8(4) requires Data Fiduciaries to implement appropriate technical and organisational measures to ensure effective observance of the provisions of the Act. This includes ensuring that processing is limited to authorised purposes and that access to personal data is restricted to personnel who require it.

Clause 8(5) requires Data Fiduciaries to protect personal data under their possession or control by implementing reasonable security safeguards to prevent personal data breaches.

Clause 8(7)(a) requires erasure of personal data as soon as it is reasonable to assume that the purpose for which it was collected is no longer being served. Clause 8(7)(b) requires erasure upon withdrawal of consent.

What this requires technically

Clause 8(4) maps directly to RBAC and access governance controls. Access to systems that process personal data must be role-based, limited to personnel with a current, documented need, and reviewed periodically to ensure it remains appropriate. An employee who has moved to a different function but retains access to a customer data system is a direct Clause 8(4) deficiency.

Clause 8(5) maps to the broader IAM security controls layer: Adaptive MFA to prevent unauthorised authentication, contextual access controls to restrict access by device, IP, and location, and privileged access management to govern administrator access to systems holding personal data. AkkuReka brokers all privileged sessions to personal data systems, ensuring no direct access without a governed, recorded session.

Clause 8(7) maps to automated deprovisioning. When employment ends, access to personal data systems must be revoked promptly and completely. When consent is withdrawn, the processing entitlements tied to that consent must cease. Both require automated lifecycle management with a timestamped, auditable deprovisioning record. A manual offboarding checklist does not produce the structured proof that a regulatory inquiry would require.

Akku’s access control modules, covering RBAC, ABAC, contextual access, adaptive MFA, and automated lifecycle management, collectively address Clause 8(4), 8(5), 8(7)(a), and 8(7)(b). The IGA module’s access reviews and re-certification campaigns provide the periodic review mechanism that Clause 8(4)’s ongoing observance requirement implies.

Data Principal Rights and the Technical Infrastructure They Require

Chapters III of DPDPA establishes six rights for Data Principals. Each right creates a corresponding technical obligation for the Data Fiduciary. The right exists on paper only if the technical infrastructure to fulfil it exists in practice.

What the Act requires

Clause 11(1)(a) gives Data Principals the right to obtain a summary of personal data being processed and the processing activities. Clause 11(1)(b) gives the right to know the identities of other Data Fiduciaries and Data Processors with whom data has been shared. Clause 11(1)(c) gives the right to any other information related to personal data and its processing as prescribed.

Clause 12(2) gives Data Principals the right to correction, completion, updating, and erasure of personal data. Clause 12(3) requires that where a Data Principal has previously shared personal data with another entity, that entity must be informed of corrections or erasures.

Clause 13(1) gives Data Principals the right to grieve: to register a complaint with the Data Fiduciary before approaching the Data Protection Board.

Clause 14(1) gives Data Principals the right to nominate another individual to exercise their rights in case of death or incapacity.

What this requires technically

The right to access under Clause 11 requires a self-service portal through which Data Principals can request and receive a structured summary of their personal data and processing activities. This cannot be a manual process at scale. For organisations with large customer bases, manual fulfilment of data access requests within any reasonable timeframe is operationally unviable.

The right to correction and erasure under Clause 12 requires workflows that can update or delete personal data across connected systems, not just in one database. An erasure request fulfilled in the CRM but not in the marketing automation platform, the support ticketing system, or the billing system is an incomplete erasure.

Akku’s CIAM Consent Manager addresses Clauses 11(1)(a), 11(1)(b), 11(1)(c), 12(2)(a), 12(2)(b), 12(2)(c), 12(3), 13(1), and 14(1). The User Lifecycle Manager addresses Clauses 6(6), 8(7)(a), 8(7)(b), and 12(3) through automated deprovisioning and data lifecycle workflows triggered by consent withdrawal or role change events.

Audit Trails and Breach Notification Requirements

DPDPA’s breach notification obligation under Clause 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals in the event of a personal data breach. The technical prerequisite for this is a structured audit trail that can identify what data was affected, which systems were involved, and who had access at the time. Without that infrastructure, breach notification is guesswork.

What the Act requires

Clause 8(5) requires implementation of reasonable security safeguards to prevent personal data breaches. Clause 8(6) requires intimation of personal data breaches to the Data Protection Board of India and to each affected Data Principal in such a manner as may be prescribed.

Clause 8(4) requires ongoing observance of the provisions of the Act, which includes maintaining evidence that technical measures are operating effectively, not merely that they are implemented.

What this requires technically

Breach notification under Clause 8(6) requires the ability to determine, at the time of discovery, which Data Principals were affected, what categories of personal data were involved, which systems held the data, and which users or processes had access to those systems during the relevant window. This determination requires structured, searchable audit logs with sufficient granularity.

Authentication logs alone do not provide this. Session activity logs for privileged access to personal data systems, capturing commands executed and queries run, are the audit trail that makes breach scoping operationally viable. Without them, the scope of a breach can only be estimated, not determined.

Akku’s SMARTAudit Trails capture every privileged session to connected systems at the protocol layer, producing a searchable record of every command and query executed. The append-only, tamper-evident audit log architecture ensures that records cannot be modified after the fact, which is the integrity standard a regulatory inquiry would require.

The access governance layer, covering provisioning records, approval trails, access review outcomes, and deprovisioning records, provides the complementary evidence of who had access to personal data systems, on what basis, and for what period. Together, these constitute the audit infrastructure that makes Clause 8(5) and 8(6) compliance demonstrable rather than asserted.

How IAM Addresses DPDPA’s Technical Obligations

Akku’s DPDPA compliance mapping covers 24 of the 38 technical compliance items in the Act, with 33 total clause mappings across 11 platform modules. The remaining items relate to organisational obligations, governance requirements, and areas outside the scope of IAM platforms.

The coverage is distributed across the platform as follows. The CIAM Consent Manager carries 19 of the 33 mappings, covering the consent lifecycle, notice management, Data Principal rights, and preference management. The User Lifecycle Manager covers Clauses 6(6), 8(7)(a), 8(7)(b), and 12(3) through automated lifecycle workflows. The access control modules, covering RBAC, adaptive MFA, contextual access, and PAM, collectively address Clause 8(4) and 8(5). The IGA module addresses Clause 8(4) through access governance and SoD enforcement.

The practical implication is that a single Akku deployment, configured correctly across its modules, addresses the technical layer of DPDPA without requiring separate point solutions for consent management, access control, and audit trail generation. The consent audit trail, the access governance records, and the session activity logs all exist within one platform, accessible through one interface, and exportable in structured format for regulatory submission.

Questions IT and Compliance Teams Ask About DPDPA’s Technical Requirements

Which clauses of DPDPA create direct technical obligations for IT teams?

The primary technical obligations fall under Clauses 5 and 6 (consent notice and management), Clause 8(4) (appropriate technical measures for authorised processing), Clause 8(5) (security safeguards to prevent breaches), Clause 8(7) (erasure on purpose completion or consent withdrawal), and Clauses 11 through 14 (Data Principal rights fulfilment). Each of these requires a technical system to implement, not a policy document to state.

What is the difference between a consent record and a consent management system?

A consent record is a single captured data point: a user clicked agree on a particular date. A consent management system maintains versioned notices, ties each consent to a specific notice version and processing purpose, records every update and withdrawal with a timestamp, supports self-service withdrawal, and notifies downstream systems when consent is withdrawn. DPDPA Clause 6 requires the latter. A database row recording a checkbox state does not satisfy the Act’s specificity, withdrawability, or audit trail requirements.

Does DPDPA require erasure of personal data when an employee leaves?

Clause 8(7)(a) requires erasure of personal data as soon as it is reasonable to assume that the purpose for which it was collected is no longer being served. For employee data, departure is the event that triggers this determination. In practice, this means automated deprovisioning of access to personal data systems, combined with data retention policies that define how long employee personal data is held and on what legal basis. The access revocation component is an IAM obligation. The data retention and deletion component requires a broader data governance framework.

What does DPDPA require for Data Principal rights fulfilment?

Clauses 11 through 14 give Data Principals rights to access, correction, erasure, grievance redress, and nomination. Each right requires a technical fulfilment mechanism. Access requests require a self-service portal producing structured summaries. Correction and erasure requests require workflows that propagate changes across connected systems. Grievance redress requires a documented complaint and response process. At scale, manual fulfilment of these rights is not operationally viable within any reasonable timeframe.

How does DPDPA’s breach notification requirement differ from GDPR’s?

GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a breach. DPDPA Clause 8(6) requires intimation to the Data Protection Board of India and to each affected Data Principal in a manner to be prescribed. The prescribed timelines and format are subject to the Rules, which are yet to be finalised. However, the technical prerequisite is the same under both frameworks: structured audit logs that enable rapid identification of affected Data Principals, data categories, and access history at the time of the breach.

Can a single IAM platform address DPDPA’s full technical compliance requirement?

Akku addresses 24 of the 38 technical compliance items in DPDPA, covering consent management, access controls, Data Principal rights workflows, audit trail generation, and lifecycle management. The remaining items relate to organisational obligations and governance requirements that sit outside the scope of any IAM platform. Full DPDPA compliance requires both the technical controls that IAM provides and the organisational measures that governance frameworks, legal counsel, and data protection officers address.