Introduction

RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes three distinct requirements across its sub-clauses: need-based access for all users under Clause 19(a), close supervision of privileged users with logged system activities under Clause 19(b), and multi-factor authentication for privileged users accessing critical information systems under Clause 19(c). Each sub-clause has a specific technical implementation requirement that goes beyond policy documentation.

Most RBI-regulated entities have access control policies stating that need-based access is required. Fewer have implemented the technical controls that make need-based access enforceable and auditable. A policy stating that users should only have access to systems required for their role does not prevent a user from accumulating access across role changes. An RBAC implementation with structured provisioning workflows, periodic access reviews, and automated deprovisioning does.

The distinction matters because RBI IS auditors examine technical controls, not policy documents. An auditor examining Clause 19(a) compliance will ask to see the provisioning process, the access review records, and the deprovisioning audit trail for a sample of users. An auditor examining Clause 19(b) compliance will ask to see privileged session recordings, not a policy stating that privileged access is monitored. An auditor examining Clause 19(c) compliance will test whether MFA is enforced at the infrastructure layer, not only at the application login screen.

This blog covers what each sub-clause of Clause 19 requires technically, the evidence an RBI IS audit expects, and how IAM controls address each requirement. All clause references are drawn directly from the RBI 2023 Master Direction and Akku’s RBI compliance mapping documentation.

Need-Based Access Requirements Under Clause 19(a)

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

What the clause requires technically

Need-based access requires three technical controls operating together. Role definitions that map each organisational role to the specific systems and functions that role requires. Provisioning workflows that grant access based on role assignment, with additional access requiring a structured request and approval process. Deprovisioning workflows that revoke access automatically when roles change or employment ends.

Without role definitions, access is granted ad hoc and accumulates over time. Without structured provisioning workflows, access grants have no documented authorisation trail. Without automated deprovisioning, access persists beyond the point where the need ends. All three gaps are what Clause 19(a) is designed to close.

The periodic access review requirement implied by Clause 23(a) is the mechanism for detecting entitlement drift: the accumulation of access across role changes that structured provisioning alone cannot prevent. An employee who has changed roles three times over five years may hold access entitlements from each previous role that were never revoked. Access reviews surface these entitlements for certification or revocation.

What evidence an RBI IS audit expects

An RBI IS auditor examining Clause 19(a) compliance typically requests evidence of the access provisioning process including a sample of provisioning records showing requester, approver, justification, and timestamp. They examine deprovisioning records for a sample of departed employees, verifying that access was revoked across all connected systems and that the revocation was timely. They review access review records showing periodic certification or revocation decisions with documented outcomes.

They also examine the current access state of a sample of users, verifying that each user’s entitlements are consistent with their current role. Users holding access to systems unrelated to their current function, particularly former system administrators who have moved to business roles but retain infrastructure access, are a common finding.

How Akku addresses it

RBAC defines access entitlements by organisational role. Every application and system access right is tied to a role definition. Access beyond birthright entitlements requires a structured request and approval workflow, with requester identity, approver identity, justification, and timestamp recorded automatically.

Automated User Lifecycle Management handles role changes and departures. Role changes trigger re-provisioning: access from the previous role is reviewed and where no longer required, removed. Departure triggers automated deprovisioning across all connected applications in a single action, with a timestamped audit record of every account removed.

SCIM-based provisioning synchronises access changes to connected applications automatically. Access review and re-certification campaigns run on a defined cadence, sending certification requests to managers and resource owners with timestamped, logged decisions. Akku’s RBI mapping shows Access Manager addresses Clauses 10(d), 19(a), 20(a), 23(c), and 25(c) across five clause mappings.

Privileged Access Supervision Requirements Under Clause 19(b)

Clause 19(b) requires close supervision of privileged users, with logged system activities sufficient to reconstruct what actions were taken during privileged sessions. This is a session-level logging requirement, not an authentication logging requirement.

What the clause requires technically

Close supervision requires two distinct technical capabilities. Real-time monitoring of active privileged sessions, allowing administrators to observe what privileged users are doing during active sessions and terminate sessions exhibiting suspicious behaviour. Session-level recording of completed sessions, producing a complete record of every action taken during a privileged session that can be reviewed retrospectively for audit and investigation purposes.

Authentication logs satisfy neither requirement. An authentication log confirms that a privileged session occurred, from which IP, at what time, and whether MFA was used. It records nothing about what happened inside the session. For Clause 19(b)’s supervision and logging requirements, session-level recordings including keystroke logs for SSH sessions and SQL query capture for database sessions are the required technical controls.

The approval workflow requirement is the third component. Clause 19(b)’s supervision requirement implies that privileged access is authorised before it is granted. A privileged session that opens without a formal approval record is not supervised in the sense the clause requires. Every privileged session must have a request, an approval decision, a scope definition, and a time limit.

What evidence an RBI IS audit expects

An RBI IS auditor examining Clause 19(b) compliance will request session recordings for a sample of privileged sessions to critical systems. They will verify that the recordings capture session activity at the command or query level, not only screen activity. They will examine the session approval workflow records, verifying that every session in the sample was approved before it opened and that the approval record includes scope and duration.

They will also test real-time monitoring capability by asking administrators to demonstrate live visibility into active privileged sessions and the ability to terminate a session from the monitoring console. An organisation that can produce historical session recordings but cannot demonstrate real-time monitoring capability has a partial Clause 19(b) implementation.

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 structured SQL query capture. RDP sessions produce full screen video recordings at configurable frame rates. All recordings are stored encrypted, indexed for forensic search by timestamp, command string, or SQL query, and accessible for in-browser playback from the Akku admin console.

Real-time session monitoring allows administrators to view all active privileged sessions from the Akku admin console. Any live session can be terminated instantly. Termination is recorded in the audit log with actor, timestamp, and reason.

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

AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, injected at the protocol layer, and permanently revoked on session close. The user never sees or types the target credential. This eliminates the shared, persistent credential risk that makes privileged account compromise the highest-impact attack vector in regulated entity environments. Akku’s RBI mapping shows Privileged Access Manager addresses Clauses 19(b), 19(c), and 23(c).

MFA Requirements Under Clause 19(c)

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

What the clause requires technically

MFA for privileged users must be enforced at the infrastructure layer, not only at the application login screen. An administrator who authenticates to a web-based management console with MFA but can then SSH directly to the underlying server without MFA has partial coverage. The SSH session is the higher-risk access path, and it is the one most commonly left without MFA enforcement.

The critical information systems scope includes core banking platforms, payment processing systems, database servers, network infrastructure management interfaces, and any system classified as critical under the regulated entity’s IT risk framework. MFA enforcement must cover all of these, not only the systems with web-based authentication interfaces.

Step-up authentication for high-sensitivity access reflects the proportionate authentication model that Clause 19(c) implies. A privileged user accessing a development environment carries different risk from one accessing a production core banking system. Step-up authentication escalates the challenge for higher-sensitivity access, applying a more demanding second factor or requiring re-authentication within the session.

What evidence an RBI IS audit expects

An RBI IS auditor examining Clause 19(c) compliance will test MFA enforcement across the full scope of critical systems, not only the systems with visible MFA prompts. They will attempt to identify access paths that bypass MFA, including direct SSH access to servers, database client connections, and network device management interfaces.

They will examine MFA event logs to verify that MFA challenges are consistently enforced and that no privileged sessions to critical systems opened without a successful MFA event preceding them. They will also examine the MFA method used, assessing whether it is phishing-resistant for the highest-privilege accounts.

How Akku addresses it

Akku’s Adaptive MFA enforces authentication assurance at the IAM layer for all connected applications. For privileged infrastructure access, MFA is enforced through PAM before any session proxy connection opens. A privileged user must authenticate to Akku IAM with MFA before AkkuReka opens a session to the target system. This enforcement applies to SSH servers, RDP hosts, MySQL and PostgreSQL databases, Kubernetes clusters, and web applications, covering the infrastructure layer that application-level MFA does not reach.

AI-powered anomaly detection evaluates each authentication event against the user’s behavioural baseline. Access from a new location, a new device, or outside normal hours triggers step-up authentication. This is the proportionate, risk-based enforcement model that Clause 19(c)’s critical systems scope implies.

The authentication event log captures every MFA challenge and outcome with actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and result. This event stream provides the continuous MFA enforcement evidence that an RBI IS audit examines. Akku’s RBI mapping shows Adaptive MFA addresses Clauses 19(c) and 20(b).

How Clauses 19(a), 19(b), and 19(c) Interact as a Control Set

Clauses 19(a), 19(b), and 19(c) address different layers of the same privileged access risk. Clause 19(a) controls who gets access and ensures it is appropriate to their role. Clause 19(b) controls what privileged users do once access is granted and ensures it is supervised and recorded. Clause 19(c) controls how privileged users authenticate and ensures identity assurance is strong enough for critical system access.

A regulated entity that satisfies only one or two of these sub-clauses has partial controls. An entity with strong MFA under Clause 19(c) but no session recording under Clause 19(b) can prove who authenticated but not what they did. An entity with session recording under Clause 19(b) but weak access controls under Clause 19(a) has detailed logs of privileged sessions that should not have occurred. All three sub-clauses are required together to constitute a defensible privileged access control posture.

The JIT access model addresses all three sub-clauses simultaneously. JIT access enforces need-based, time-bound access at the session level, satisfying Clause 19(a). The session approval workflow and SMARTAudit Trails enforce supervision and logging, satisfying Clause 19(b). MFA at the IAM layer before any session opens enforces authentication assurance, satisfying Clause 19(c). Per-session ephemeral credentials generated by AkkuArka ensure that no standing credential exists that could be used to bypass the JIT and MFA controls.

Diagnostic Questions

For a sample of ten users at your organisation with access to critical information systems, can you produce the provisioning record showing who approved each access grant, the justification, and the timestamp, without manual reconstruction from email history?

When a privileged user accesses a core banking system or production database, is there a session recording capturing every command executed and every query run, not only an authentication log confirming the session occurred?

Does your MFA enforcement cover direct SSH access to servers and database client connections, or only web-based application authentication interfaces?

When a system administrator’s employment ends, does their access to all critical systems, including SSH keys, database credentials, and network device management interfaces, cease within the same business day?

Has your organisation conducted a formal review of privileged access entitlements in the last 12 months, and can you produce evidence of every certification or revocation decision made during that review?

FAQs

What does need-based access mean technically under RBI Clause 19(a), and how is it different from role-based access control?

Need-based access is the principle that users access only what their current role requires, and that access is revoked when the need ends. Role-based access control is the primary technical implementation mechanism: access entitlements are defined at the role level and assigned to users based on their role. Need-based access goes beyond RBAC by requiring that the role definitions themselves reflect actual operational requirements, that additional access beyond role defaults requires documented justification and approval, and that access accumulated across role changes is reviewed and revoked where no longer needed. RBAC without periodic access reviews and automated deprovisioning does not fully satisfy need-based access.

What is the difference between Clause 19(b)’s supervision requirement and standard privileged access logging?

Clause 19(b) requires close supervision with logged system activities sufficient to reconstruct what actions were taken. Standard privileged access logging typically captures authentication events: who connected, when, from where. Clause 19(b)’s supervision requirement requires session-level recording: what commands were executed in an SSH session, what queries were run in a database session, what actions were taken in an RDP session. Authentication logs satisfy the logging of access events. They do not satisfy the logging of system activities that Clause 19(b) requires.

Does RBI Clause 19(c) require MFA for all users or only for privileged users?

Clause 19(c) specifically requires MFA for privileged users accessing critical information systems. The clause targets the highest-risk access scenario: administrators with elevated permissions accessing the systems most critical to the regulated entity’s operations. Customer-facing MFA for internet banking is governed by separate RBI guidelines. Clause 19(c) is specifically about internal privileged user authentication to backend critical systems, which is where most regulated entities have an MFA coverage gap relative to their application-layer MFA deployment.

What does AkkuArka’s per-session ephemeral credential model mean for RBI Clause 19(b) compliance?

Per-session ephemeral credentials mean that every privileged session uses a unique credential generated at session approval and permanently revoked on session close. No privileged user holds standing credentials to target systems between sessions. For Clause 19(b) compliance, this model eliminates the scenario where a privileged user retains credentials that allow them to access critical systems outside the supervised, logged session proxy. Every privileged access event must occur through AkkuReka, ensuring that session recording and real-time monitoring coverage is complete, with no access paths that bypass the supervision controls.

How often should access reviews be conducted to satisfy RBI Clause 23(a)’s periodic review requirement?

The RBI framework does not specify a defined review frequency for Clause 23(a). The standard interpretation in IS audit practice is that reviews should occur at least annually for all users with access to critical systems, and more frequently for privileged users. Quarterly reviews for privileged access entitlements are common practice at banks and NBFCs seeking to demonstrate robust compliance. The key evidence requirement is that reviews are conducted on a consistent cadence throughout the year, producing documented outcomes at each cycle, rather than a single annual review conducted in the pre-audit window.

Can Clause 19 compliance be satisfied by an on-premises PAM solution, or does it require a cloud-based deployment?

Clause 19’s technical requirements, need-based access, session-level supervision and logging, and MFA for privileged users, can be implemented through either on-premises or cloud-based PAM solutions. The RBI framework is technology-neutral in its requirements. Akku PAM supports both cloud-native SaaS deployment and full on-premises deployment for regulated entities with data sovereignty requirements or private network environments. The deployment model does not affect the compliance coverage. What matters is whether the technical controls satisfy the clause requirements and produce the evidence an IS audit expects.

Introduction

SEBI CSCRF’s Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the most detailed set of identity and access management requirements in any Indian regulatory framework. The Detect function’s continuous monitoring sub-category DE.CM adds a layer of anomaly detection and real-time visibility requirements that most capital markets entities are not currently meeting at the depth the framework requires.

Together, PR.AA and DE.CM define what SEBI expects from a capital markets entity’s identity stack. PR.AA covers how identities are managed, how access is provisioned, how credentials are controlled, how authentication is enforced, and how privileged access is governed. DE.CM covers how authentication events and access patterns are monitored continuously, and how anomalies are detected and acted upon.

Most SEBI-regulated entities have implemented some subset of these controls. SSO is deployed for application access. MFA is enforced at the application login layer. Some form of access review is conducted periodically. What the framework requires goes further: proportionate, risk-based authentication for every access scenario, privileged access governance with session-level recording, continuous monitoring with anomaly detection, and on-demand log access for SEBI examination.

This blog covers what PR.AA and DE.CM specifically require at the technical implementation level, with direct references to guideline codes from the SEBI CSCRF Part II and Akku’s SEBI compliance mapping documentation, which covers 88 unique compliance items with 145 total clause mappings.

Identity Management Requirements Under PR.AA.S1 to PR.AA.S6

PR.AA.S1 through PR.AA.S6 cover the foundational identity management layer: unique identification, centralised identity management, credential governance, and access provisioning based on least privilege.

What the guidelines require

PR.AA.S1 requires that all users, whether employees, contractors, or third parties, be uniquely identified. Shared accounts and generic credentials are inconsistent with this requirement. Each identity must be individually accountable. PR.AA.S1 guideline references G1e, G1g, G1h, and G2 in Akku’s SEBI mapping cover user registration, lifecycle management, and dormant account controls under this sub-section.

PR.AA.S6 requires strong credential management covering password policies, credential storage security, and the full credential lifecycle. Password complexity, length, expiry, and history requirements must be technically enforced. Credentials must be stored in an encrypted vault with access controls preventing direct human access to raw credential data. Akku’s SEBI mapping shows Password Manager addresses PR.AA.S6 across eight guideline references including G1, G1f, G3, G3b, G4h.

PR.AA.S3 and PR.AA.S5 require that access be provisioned based on formally defined roles, with least privilege enforced throughout the access lifecycle. Access beyond role defaults requires documented justification and approval. Identity and Access Governance addresses PR.AA.S3 and PR.AA.S5 across 12 total guideline mappings covering role governance, access certification, and SoD enforcement.

PR.AA.S4 requires that access controls be applied based on risk, with more sensitive resources receiving stricter access controls. This is not a uniform access control requirement. It is a risk-stratified model where the access control applied to a trading system is more restrictive than the one applied to an internal wiki. Access Manager addresses PR.AA.S4 across 13 guideline mappings, the highest single-module count after GPO Manager and Audit Logs in the SEBI mapping.

How Akku addresses it

Akku’s unified cloud identity store provides the centralised identity management infrastructure PR.AA.S1 requires. Every user has a unique identity in the Akku directory. The User Lifecycle Manager automates the joiner-mover-leaver workflow, ensuring identities are created, updated, and removed through structured processes with full audit trails. Akku’s SEBI mapping shows User Lifecycle Manager addresses PR.AA.S1 guideline references G1g and G1h, GV.SC.S4, and PR.DS.S6(G3) across seven total mappings.

RBAC and ABAC enforce least privilege at the access layer. Role definitions determine application and resource access. Attribute-based controls refine this 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.

Password Manager addresses PR.AA.S6’s credential governance requirements. Password policies enforce complexity, length, expiry, history, and lockout rules at the organisation, group, or role level. AkkuVault stores credentials encrypted with AES-256-GCM. Vault contents are accessible only via the AkkuArka API, with no direct human access to raw credential data.

Authentication Requirements Under PR.AA.S7 to PR.AA.S9

PR.AA.S7 through PR.AA.S9 cover authentication controls, MFA enforcement, and the proportionality requirement that distinguishes SEBI CSCRF’s authentication model from a simple MFA deployment.

What the guidelines require

PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource being accessed. A trading system, a core settlement platform, and a network management interface require stronger authentication than an internal documentation system. The proportionality requirement means that authentication strength must scale with resource sensitivity, not be applied uniformly.

PR.AA.S9 requires that MFA be enforced for access to sensitive and critical systems. For capital markets entities, this includes trading platforms, clearing systems, client data repositories, and network infrastructure management interfaces. The scope extends beyond application-layer authentication to infrastructure-level access.

PR.AA.S10 through PR.AA.S12 cover privileged access specifically, which is addressed in the next section.

Guideline references G1i and G1j under PR.AA.S1 to S9 cover authentication logging requirements, specifying that every authentication event must be logged with sufficient detail for audit and investigation purposes. Akku’s SEBI mapping shows Adaptive MFA addresses PR.AA.S7 and 10 additional guideline references across the PR.AA sub-category.

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 when risk signals indicate elevated risk. This is the proportionate, risk-based authentication model PR.AA.S7 requires. A static second factor applied uniformly to all sessions does not satisfy the proportionality requirement.

For infrastructure-level access, Akku extends MFA enforcement to privileged sessions through PAM. A privileged user must authenticate to Akku IAM with MFA before AkkuReka opens a session to the target system. This covers SSH servers, RDP hosts, MySQL and PostgreSQL databases, Kubernetes clusters, and web applications at the infrastructure layer.

Every authentication event produces a structured log record containing actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. This event stream is the continuous authentication evidence that PR.AA.S8’s logging requirement and DE.CM’s monitoring requirement draw on.

Privileged Access Requirements Under PR.AA.S10 to PR.AA.S12

PR.AA.S10 through PR.AA.S12 define SEBI CSCRF’s privileged access management standard. These guidelines go beyond credential storage to require session-level governance, formal approval workflows, and activity-level logging.

What the guidelines require

PR.AA.S10 requires that privileged accounts be separately identified and managed. Privileged users must not use privileged credentials for routine non-administrative tasks. Each privileged account must be individually accountable, with no shared administrative credentials.

PR.AA.S11 requires that privileged access be granted based on formal approval, with access scope defined and time-limited where possible. GV.RM.S1(G1c) reinforces this by requiring that high-privilege access be treated as a specific risk category within the entity’s risk management framework.

PR.AA.S12 requires that all privileged session activity be logged with sufficient detail to reconstruct the actions taken. Authentication records alone do not satisfy this requirement. The log must capture what the privileged user did, not only that they connected. Akku’s SEBI mapping shows Privileged Access Manager addresses PR.AA.S11, guidelines G2a, G2b, G2c under PR.AA.S10 to S12, PR.AA.S15(G4c), PR.DS.S4(G2), PR.MA.S2(G3), and GV.RM.S1 to S2(G1c) across 12 total guideline mappings.

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 session close. This directly satisfies PR.AA.S10’s individual accountability requirement and PR.AA.S11’s time-limited access requirement.

The session approval workflow produces the formal authorisation record PR.AA.S11 requires. Every privileged session request captures 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 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. RDP sessions produce full screen video recordings. This is the activity-level logging 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. Termination is recorded in the audit log with actor, timestamp, and reason.

Continuous Monitoring Requirements Under DE.CM

DE.CM, the continuous monitoring sub-category of the Detect function, adds a proactive detection layer on top of the logging requirements in PR.AA. The distinction between logging and monitoring is central to what DE.CM requires: logs record what happened, monitoring detects anomalies as they occur or shortly after.

What the guidelines require

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 indicative of malicious activity, unauthorised access, or policy violations.

DE.CM requires that monitoring be automated and continuous, not periodic. A weekly review of authentication logs does not satisfy continuous monitoring. The monitoring infrastructure must evaluate events against baselines and generate alerts without waiting for manual review cycles.

RS.AN.S1 through S5 in the Respond function require that incident response activities be supported by structured log evidence enabling rapid scoping and attribution. This reinforces the quality and completeness requirements for the underlying log infrastructure that DE.CM monitors.

Akku’s SEBI mapping shows Audit Logs addresses DE.CM.S1 to S3(G1) alongside RS.AN.S1 to S3(G1 to G4), RS.AN.S4 to S5(G1 to G5), EV.ST.S1 to S3(G5 to G6), and EV.ST.S1 to S3(G7 to G8) across 20 total guideline mappings, the second highest single-module count in the SEBI mapping after Mobile Device Manager.

How Akku addresses it

Akku’s Adaptive MFA provides anomaly detection at the authentication layer. AI-powered analysis 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 administrator review.

Risk and audit dashboards surface MFA failure spikes, geographic anomalies, access outside defined time windows, and behavioural deviations as actionable alerts. These are the real-time signals that DE.CM requires to be detected automatically, not discovered through periodic log review.

For privileged access, real-time session monitoring through AkkuReka provides the continuous visibility DE.CM requires at the infrastructure layer. Administrators view active sessions and can act on anomalous behaviour immediately rather than retrospectively.

The append-only, tamper-evident audit log architecture ensures that the event records DE.CM monitors cannot be modified after the fact. Logs are exportable in JSON and CSV format and accessible via API for integration with SIEM and log aggregation platforms, supporting the RS.AN incident response evidence requirements.

On-Demand Log Access Requirements Under GV.OC

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

What this requires technically

On-demand log access requires a centralised, queryable log infrastructure with structured export capability. Logs distributed across individual application log files that require manual compilation before export do not satisfy the on-demand requirement. The export must be producible in structured format, such as JSON or CSV, within a timeframe consistent with a regulatory request.

The integrity of the exported logs must be demonstrable. An append-only architecture that prevents post-hoc modification is what makes the integrity claim credible. A log that can be edited before export cannot satisfy a regulatory examination where the accuracy of the records is under scrutiny.

How Akku addresses it

Akku’s centralised audit log provides a single queryable source for all authentication events, access events, privileged session records, administrative actions, and policy changes. Exports can be produced for any time period, filtered by user, system, event type, or outcome, in JSON or CSV format. API access enables programmatic integration with SIEM, SOAR, and log aggregation platforms.

The append-only architecture ensures that records cannot be modified after the fact. GV.OC.S2(G2) and GV.OC.S2(G3) are addressed by Audit Logs alongside Cloud Directory in Akku’s SEBI mapping.

Diagnostic Questions

For any 30-day window SEBI requests, can you produce a structured export of all authentication events, privileged session records, and access change events across your environment without manual log compilation?

Does your MFA deployment apply proportionately stronger authentication to your trading systems and settlement platforms than to lower-sensitivity internal applications, or is MFA applied uniformly regardless of resource sensitivity?

When a privileged user accesses a trading platform database or network management interface, is there a session recording capturing every query executed and every command run, not only an authentication log confirming the session occurred?

Are dormant accounts automatically disabled after a defined inactivity threshold, with a timestamped audit record of each disabling action, or does dormant account management rely on periodic manual review?

Does your monitoring infrastructure detect MFA failure spikes and geographic authentication anomalies in real time and generate alerts for administrator review, or are these patterns discovered during periodic log review?

FAQs

What does PR.AA.S7’s proportionality requirement mean in practice for a capital markets entity?

PR.AA.S7 requires that authentication controls be commensurate with the sensitivity of the resource. For a capital markets entity, this means that trading platforms, clearing systems, and client data repositories require stronger authentication than internal administrative tools. In practice, this is implemented through Adaptive MFA that evaluates risk signals at each authentication event and escalates the challenge for higher-sensitivity access scenarios. A static second factor applied uniformly to all sessions, regardless of what is being accessed, does not satisfy the proportionality requirement.

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

PR.AA.S11 covers the authorisation and governance of privileged access: how sessions are requested, approved, scoped, and time-limited. PR.AA.S12 covers the logging of what happened during privileged sessions: commands executed, queries run, actions taken. PR.AA.S11 is satisfied by a structured session approval workflow with per-session ephemeral credentials and JIT access. PR.AA.S12 is satisfied by protocol-level session recording through SMARTAudit Trails. Satisfying one does not satisfy the other.

What does DE.CM require for continuous monitoring, and how is this different from periodic log review?

DE.CM requires continuous monitoring of system components including authentication events, access patterns, and privileged activity, with automated detection of anomalies. Periodic log review involves examining accumulated logs on a defined schedule, typically daily or weekly. Continuous monitoring evaluates events against baselines as they occur and generates alerts without waiting for a review cycle. The distinction matters because a credential stuffing attack that completes within hours leaves the detection window before a daily log review occurs. Continuous monitoring with real-time alerting is the control DE.CM requires.

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

GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. Architecturally, this requires a centralised, queryable log infrastructure capable of producing structured exports for any requested time period without manual compilation. Logs distributed across individual application systems that require aggregation before they can be exported do not satisfy the on-demand requirement. The export must be producible in structured format within a timeframe consistent with a regulatory request, and the integrity of the records must be demonstrable through an append-only architecture.

How does the SoD rules engine address PR.AA.S3’s access control requirements for capital markets entities?

PR.AA.S3 requires that access be provisioned based on formally defined roles with least privilege enforced. For capital markets entities, SoD requirements are particularly stringent because conflicts of interest between front-office trading, back-office settlement, and compliance functions create direct regulatory risk. The SoD rules engine defines conflicting role combinations specific to the entity’s operational structure, detects violations continuously across connected applications, and triggers automated remediation workflows. This technical enforcement is what distinguishes a compliant SoD posture from a policy document stating that SoD is required.

Can a single IAM deployment address both SEBI CSCRF and RBI requirements for entities regulated by both?

Yes. The overlapping technical controls are substantial. SEBI CSCRF PR.AA.S7 and RBI Clause 19(c) both require proportionate, risk-based MFA for privileged access. SEBI CSCRF PR.AA.S12 and RBI Clause 15 both require session-level activity logging for privileged users. SEBI CSCRF GV.OC.S2(G3) and RBI Clause 15 both require on-demand log access with demonstrable integrity. A single Akku deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.

Introduction

DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be free, specific, informed, unconditional, and unambiguous. It must be as easy to withdraw as it is to give. The controller must be able to demonstrate that consent was given. These are not abstract principles. Each condition maps to a specific technical requirement that a consent management system must implement.

Most organisations approaching DPDPA consent compliance are building on top of existing web forms, checkbox flows, and terms-of-service acceptance mechanisms. These capture a consent event but not a consent record. The distinction matters: a consent event is a user action. A consent record is a structured data object containing the Data Principal identity, the notice version under which consent was given, the specific processing purpose, the timestamp, the channel, and the withdrawal status. DPDPA requires the latter.

The technical gap between a checkbox and a compliant consent management system is substantial. Versioned notices that can be updated and re-served without invalidating prior consents. Purpose-specific consent records that cannot be used as blanket authorisation for all processing. Withdrawal workflows that trigger downstream processing cessation automatically. Consent audit trails that demonstrate to the Data Protection Board of India that consent was obtained in compliance with the Act.

This blog covers what each condition in DPDPA Clause 6 requires technically, how a compliant consent management system must be architected, and how Akku’s CIAM Consent Manager addresses each requirement. All clause references are drawn directly from the DPDPA and Akku’s DPDPA compliance mapping documentation.

Notice Requirements Under Clause 5

Consent cannot be valid under DPDPA without a compliant notice. Clause 5 sets the notice requirements that must be satisfied before consent is sought. The notice infrastructure is a technical prerequisite for the consent management system.

What the clause requires

Clause 5(1) requires that a notice be given to the Data Principal before or at the time consent is sought. The notice must be in clear and plain language and must specify the personal data to be collected and the purpose of processing for which consent is sought.

Clause 5(2) requires that where personal data was collected before the Act came into force without a compliant notice, the Data Fiduciary must provide a notice as soon as reasonably practicable and give the Data Principal an opportunity to withdraw consent.

Clause 5(3) requires that notices be made available in English and in any of the languages specified in the Eighth Schedule of the Constitution, giving Data Principals the option to receive notices in a language they understand.

What this requires technically

Notice versioning is the core technical requirement. Every version of every notice must be stored with a version identifier and effective date. Consent records must reference the specific notice version under which consent was given. When a notice is updated, the new version must be served to relevant Data Principals, and their consent under the new version must be separately recorded.

Without versioning, an organisation cannot demonstrate which notice a Data Principal saw when they consented. If the notice is later found non-compliant, there is no way to determine which consents were obtained under the non-compliant version. Versioning makes both notice governance and consent validity demonstrable.

Clause 5(2)’s re-consent requirement for pre-Act data creates a specific workflow requirement: identification of Data Principals whose data was collected without a Clause 5-compliant notice, delivery of a compliant notice to each, and recording of their response, whether consent, withdrawal, or no response, with timestamp.

Akku’s CIAM Consent Manager addresses Clause 5(1), 5(2), and 5(3) through versioned notice management, multi-language notice support, and structured re-consent workflow capabilities.

Consent Validity Requirements Under Clause 6

Clause 6 sets the conditions for valid consent. Each condition has a direct technical implementation requirement. A consent system that captures user agreement without satisfying all five conditions does not produce valid consent under the Act.

What the clause requires

Clause 6(1) requires that consent be free, specific, informed, unconditional, and unambiguous. Free means not bundled with other agreements as a condition of service. Specific means tied to a defined processing purpose, not a generic authorisation for all processing. Informed means given after a compliant notice. Unconditional means not contingent on anything other than the Data Principal’s own choice. Unambiguous means expressed through a clear affirmative action.

Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent is given through a single tap on a mobile interface, withdrawal must be achievable through an equivalent single action. A withdrawal process that requires contacting support, submitting a form, or waiting for a response does not satisfy Clause 6(3).

Clause 6(4) requires that where consent is withdrawn, the Data Fiduciary cease processing the personal data and, upon the request of the Data Principal, erase the data, unless processing is required or authorised under any other law. The cessation and erasure must be actioned, not only acknowledged.

Clause 6(7) requires that the Data Fiduciary maintain a record of consent given by the Data Principal. The record must be available to demonstrate compliance.

What this requires technically

Purpose-specific consent records are the technical requirement for Clause 6(1)’s specificity condition. A single consent record covering all processing purposes is not specific. Each processing purpose requires a separate consent record, allowing Data Principals to consent to some purposes and decline others. A consent management system that captures a single agreement covering all data uses does not satisfy this requirement.

Clause 6(3)’s equal ease of withdrawal requires a self-service withdrawal interface accessible through the same channel as the original consent mechanism. For mobile applications, this means an in-app withdrawal flow. For web applications, a portal-accessible withdrawal action. The withdrawal must not require interaction with a human agent.

Clause 6(4)’s cessation requirement creates an automated downstream notification requirement. When consent is withdrawn, every system processing personal data under that consent must be notified to cease processing. This notification must be automated, not manual, at any scale. Akku’s User Lifecycle Manager addresses Clause 6(6), 8(7)(a), 8(7)(b), and 12(3) through automated deprovisioning workflows triggered by consent withdrawal events.

Clause 6(7)’s record-keeping requirement is satisfied by a consent record data model that stores Data Principal identity, notice version, processing purpose, consent timestamp, consent channel, and withdrawal status and timestamp. Every update to this record must be logged with a timestamp, creating a complete consent history for each Data Principal.

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, carrying 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation.

Children’s Data Requirements Under Clause 9

Clause 9 imposes additional requirements for processing personal data of children, defined as individuals below the age of 18. The technical implementation requirements are specific and add a verification layer that standard consent flows do not include.

What the clause requires

Clause 9(1) requires that before processing personal data of a child, the Data Fiduciary obtain verifiable consent from the parent or lawful guardian of the child. The consent must be verifiable, meaning the system must have a mechanism to confirm that the consenting individual is actually the parent or guardian.

Clause 9(3) prohibits Data Fiduciaries from undertaking processing of personal data of children that is likely to cause detrimental effect on their wellbeing, tracking or behavioural monitoring of children, or targeted advertising directed at children.

What this requires technically

Verifiable parental consent requires an age verification mechanism at the point of data collection and a separate consent flow for Data Principals identified as children. The age verification must be capable of identifying when a Data Principal is below 18 and routing their registration to a parental consent workflow rather than a standard consent flow.

The parental consent record must capture the guardian’s identity, the verification method used, the notice version, the specific processing purpose, and the timestamp. The technical challenge is that verifiable consent requires more than a checkbox labelled “I confirm I am the parent or guardian.” The verification mechanism must provide reasonable assurance of the consenting individual’s relationship to the child.

Akku’s CIAM Consent Manager addresses Clause 9(1) through age-gated consent workflows and parental consent record management as part of its DPDPA compliance mapping.

Consent Audit Trail Requirements

The accountability principle in DPDPA Clause 8(4) and the record-keeping requirement in Clause 6(7) together create a consent audit trail obligation. The Data Fiduciary must be able to demonstrate to the Data Protection Board of India that consent was obtained in compliance with the Act for every Data Principal whose data is being processed on the basis of consent.

What the requirements mean technically

A consent audit trail is not the same as a consent record. A consent record captures the current state of a Data Principal’s consent. A consent audit trail captures the complete history of every consent event, including initial consent, updates, purpose additions, purpose withdrawals, and full withdrawal, with timestamps and the notice version applicable at each event.

This history is what makes consent demonstrable under Clause 8(4). If the Data Protection Board examines a specific Data Principal’s consent record and asks when consent was given, under which notice version, for which purposes, and whether any changes were made, the audit trail must answer all of these questions from structured data, not from manual reconstruction.

The audit trail must also be tamper-evident. A consent history that can be modified after the fact cannot satisfy a regulatory examination. Records must be append-only: new events are added, but existing records cannot be changed.

Akku’s CIAM Consent Manager produces a full consent audit trail for every consent update, covering every change in consent status with timestamp, notice version, and channel. The append-only architecture ensures that the history cannot be modified retroactively. This satisfies both Clause 6(7)’s record-keeping requirement and Clause 8(4)’s demonstrability obligation.

How CIAM Consent Manager Addresses DPDPA Clause 6 Obligations

Akku’s CIAM Consent Manager addresses 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation, covering Clauses 4(1), 5(1), 5(2), 5(3), 6(1), 6(3), 6(4), 6(7), 8(3), 9(1), 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 technical capabilities addressing these clauses include centralised consent record storage with a structured data model per Data Principal per processing purpose, versioned notice management with re-consent workflow support, preference management across web, mobile, and API channels, self-service withdrawal workflows with downstream processing cessation notifications, full consent audit trails for every consent update, and Data Principal rights fulfilment workflows for access, correction, and erasure requests.

The remaining DPDPA clause mappings outside the CIAM Consent Manager are addressed by the User Lifecycle Manager for deprovisioning and erasure workflows, the access control modules for Clause 8(4) and 8(5) obligations, and the IGA module for access governance under Clause 8(4).

Diagnostic Questions

Does your current consent mechanism store a structured consent record per Data Principal per processing purpose, or does it capture a single agreement covering all data uses?

Can you demonstrate to the Data Protection Board of India, for any Data Principal whose data you are processing on the basis of consent, the exact notice version under which consent was given, the specific purpose, and the timestamp?

When a Data Principal withdraws consent, does processing cease automatically across all connected systems within the same session, or does cessation require manual intervention across system administrators?

Does your consent withdrawal mechanism require a Data Principal to contact support or submit a form, or is withdrawal achievable through a self-service action equivalent in ease to the original consent mechanism?

For Data Principals whose personal data was collected before DPDPA came into force without a compliant Clause 5 notice, has your organisation delivered compliant notices and recorded the response of each Data Principal?

CTAs

See how Akku’s CIAM Consent Manager addresses DPDPA Clause 6 requirements across consent capture, record management, and withdrawal workflows.

Book a conversation with the Akku team to assess your current consent management infrastructure against DPDPA’s technical obligations.

FAQs

What is the difference between a consent event and a consent record under DPDPA?

A consent event is a user action, clicking agree, tapping accept, or submitting a form. A consent record is a structured data object that captures the Data Principal identity, the notice version under which consent was given, the specific processing purpose, the timestamp, the channel, and the current withdrawal status. DPDPA Clause 6(7) requires that the Data Fiduciary maintain a record of consent. A database entry recording that a user clicked agree, without capturing which notice version, which purpose, and on which channel, does not constitute a compliant consent record.

Why does DPDPA require purpose-specific consent rather than a single general consent?

Clause 6(1) requires that consent be specific, meaning tied to a defined processing purpose. A single consent covering all processing purposes does not satisfy the specificity requirement because it does not give the Data Principal meaningful choice over individual processing activities. A Data Principal may be willing to consent to processing for service delivery but not for marketing communications. Purpose-specific consent records allow this granularity. They also allow partial withdrawal, where a Data Principal withdraws consent for one purpose without affecting consent for others.

What does Clause 6(3) require for consent withdrawal, and how does a compliant withdrawal mechanism differ from current practice?

Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent is given through a single tap in a mobile application, withdrawal must be achievable through an equivalent single action in the same application. Current practice at many organisations requires Data Principals to email a privacy team, submit a data subject rights request form, or contact customer support to withdraw consent. These mechanisms do not satisfy the equal ease standard. A compliant withdrawal mechanism is a self-service action accessible through the same interface as the original consent, with immediate effect and automated downstream processing cessation.

What downstream actions must a Data Fiduciary take when consent is withdrawn under Clause 6(4)?

Clause 6(4) requires that the Data Fiduciary cease processing the personal data for which consent has been withdrawn. Where the Data Principal requests it, the Data Fiduciary must also erase the data unless processing is required or authorised under another law. Technically, cessation requires automated notification to every system processing personal data under the withdrawn consent. For workforce systems, this maps to deprovisioning access to personal data processing systems. For customer data systems, this maps to suppression flags and processing cessation workflows across the data infrastructure. Manual coordination across system administrators does not scale to this requirement.

What does DPDPA require for processing personal data of children, and how does this differ from standard consent flows?

Clause 9(1) requires verifiable consent from the parent or lawful guardian before processing personal data of a child. Standard consent flows capture the Data Principal’s agreement without verifying their age or, where they are a child, the identity and relationship of the consenting adult. A compliant children’s data flow requires an age verification mechanism at the point of registration, a separate parental consent flow for Data Principals identified as below 18, a parental consent record capturing guardian identity, verification method, notice version, purpose, and timestamp, and a prohibition on processing activities likely to cause detrimental effect on children’s wellbeing under Clause 9(3).

How does the DPDPA consent audit trail requirement differ from standard application logging?

Standard application logs record system events: page views, form submissions, API calls. A consent audit trail records the complete history of every consent event for every Data Principal, including initial consent, purpose additions, purpose withdrawals, notice version changes triggering re-consent, and full withdrawal, with timestamps and applicable notice versions at each event. The consent audit trail is the evidence base for demonstrating Clause 8(4) compliance to the Data Protection Board. It must be append-only and tamper-evident, meaning existing records cannot be modified after the fact. Standard application logs do not typically have these properties and are not structured around the Data Principal identity and processing purpose dimensions that DPDPA requires.

Introduction

Most IT teams at regulated organisations experience compliance audits as events. A notice arrives. A scramble begins. Access records are pulled from multiple systems. Provisioning history is reconstructed from email threads and IT tickets. Privileged session logs are exported and reformatted. Access review evidence is assembled from spreadsheets. The process takes weeks, involves multiple teams, and produces an evidence package that reflects what the organisation can reconstruct rather than what it continuously maintains.

The problem is not that the preparation is rushed. The problem is that the controls producing the evidence were not designed to generate continuous, structured, auditor-ready output as a byproduct of normal operations. An access review conducted three weeks before an audit does not satisfy ISO 27001 A.5.18’s periodic review requirement. A log export compiled the day before submission does not satisfy RBI Clause 15’s forensic evidence standard. A provisioning record reconstructed from email approvals does not satisfy SOC 2 CC6.2’s user registration requirement.

Every major compliance framework reviewed in this series, DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, SOC 2, and GDPR, requires that evidence of control operation be available on demand, covering any period the auditor requests. That requirement is only satisfiable if the evidence is generated continuously by the controls themselves, not assembled retrospectively before each audit cycle.

This blog covers what continuous compliance evidence looks like technically, which controls generate it as a byproduct of normal operations, and why the shift from reactive audit preparation to continuous audit readiness is an infrastructure decision rather than a process improvement.

Why Reactive Audit Preparation Fails the Evidence Standard

Compliance frameworks do not only require that controls exist. They require that controls operated effectively over time and that evidence of that operation is available for examination. This distinction is what separates SOC 2 Type I from Type II, and it is the standard that every Indian regulatory framework applies when examining audit trail completeness.

The evidence gap reactive preparation creates

RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. An audit trail assembled from exported logs, reformatted spreadsheets, and email-based approval records does not meet this standard. The forensic evidence standard requires that records be generated at the time of the event, stored in a tamper-evident format, and available in structured form without requiring manual compilation.

SEBI CSCRF GV.OC.S2(G3) requires that logs, user details, and application data be accessible to SEBI on demand. On-demand access means the infrastructure must be capable of producing structured exports at any time covering any requested period. A manual log compilation process that takes days to produce is not on-demand access.

ISO 27001 A.5.18 requires periodic review of access rights with documented outcomes. A review conducted once before an audit does not satisfy periodic. The standard requires a defined review cadence running continuously throughout the certification period, with documented evidence of every cycle.

SOC 2 Type II requires that controls operated effectively throughout the audit period, typically six to twelve months. Auditors sample control outputs from multiple points across the period. A control that operated correctly for three weeks before the audit but has no evidence of operation for the preceding nine months fails the operating effectiveness examination.

What continuous evidence generation requires technically

Continuous compliance evidence requires that every control action, every access grant, every access review decision, every provisioning and deprovisioning event, every authentication event, and every privileged session, produces a structured, timestamped, unmodifiable record as an automatic byproduct of the control operating.

This is not achievable with manual processes. Email-based access approvals do not produce structured records. Spreadsheet-tracked access reviews do not produce tamper-evident audit trails. Ad-hoc log exports do not produce on-demand accessible evidence. The evidence infrastructure must be built into the operational controls themselves.

Access Governance Controls That Generate Continuous Evidence

Access governance is the control cluster that reactive preparation most consistently fails to evidence continuously. Provisioning records, approval trails, access review outcomes, and deprovisioning records must all exist as structured, queryable data covering the entire compliance period.

Provisioning and deprovisioning evidence

Every access grant must be tied to a structured approval record containing requester identity, approver identity, justification, timestamp, and downstream provisioning confirmation. This record must be generated automatically at the time of provisioning, not reconstructed from email history.

SCIM-based automated provisioning synchronises access granted in the IAM platform to connected applications with a timestamped sync confirmation record. When SCIM connectors fail silently, provisioning gaps accumulate without any visible signal. Connector health monitoring detects sync failures before they create evidence gaps or access discrepancies.

Automated deprovisioning triggered by HR system events produces a timestamped record of every account removed, from every connected application, at the time of the offboarding event. This is the continuous deprovisioning evidence that DPDPA Clause 8(7), IRDAI Item 10, and SEBI CSCRF require. A manual offboarding checklist completed after the fact does not produce this evidence.

Access review evidence

Access review and re-certification campaigns running on a defined cadence produce a continuous stream of review evidence. Every certification or revocation decision is timestamped and logged. The output covers which entitlements were reviewed, by whom, on which date, and what action resulted.

This continuous review record is what ISO 27001 A.5.18 and SOC 2 CC6.3 require. A review conducted once a year in the month before an audit produces a single evidence record. A review process running quarterly or monthly produces evidence across the entire certification or audit period, which is what the operating effectiveness standard actually examines.

The consolidated who-has-access-to-what view makes access reviews operable at scale without manual compilation. Without it, access reviews require system administrators from every connected application to produce entitlement lists, which is why they are deferred and compressed into the pre-audit window.

Authentication and Session Evidence

Authentication event logs and session activity records are the other evidence layer that reactive preparation consistently fails. Pulling authentication logs from multiple systems and reformatting them for auditor submission is not the same as maintaining a continuous, structured, tamper-evident authentication event stream.

Authentication event evidence

Every authentication event across all connected applications must produce a structured log record containing actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. This event stream must be continuous, not generated on demand from individual application logs.

RBI Clause 15 requires audit trails covering system access. SEBI CSCRF PR.AA.S8 requires that all authentication events be logged. ISO 27001 A.8.15 requires logging of user activities and security events. IRDAI Items 54 and 55 require logging of failed authentication attempts and policy violations. All of these requirements are satisfied by a single centralised authentication event stream, not by four separate log exports from four different systems.

The append-only, tamper-evident architecture of the audit log is what makes the evidence usable. A log that can be modified after the fact cannot satisfy RBI Clause 15’s forensic standard or SEBI CSCRF’s on-demand access requirement. The integrity of the evidence is as important as its completeness.

Privileged session evidence

SMARTAudit Trails produce continuous session-level evidence for every privileged session. 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. Every session record is generated automatically at the time of the session, stored encrypted, and indexed for forensic search.

This is the continuous privileged session evidence that RBI Clause 15, ISO 27001 A.8.2, SEBI CSCRF PR.AA.S12, and IRDAI Items 144 and 145 require. It is not generated by log exports compiled before an audit. It is generated by every privileged session as it occurs, throughout the compliance period.

How One Audit Trail Serves Multiple Frameworks

The compliance efficiency argument for continuous audit evidence infrastructure is not only that it eliminates pre-audit scrambling. It is that the same evidence serves multiple frameworks simultaneously.

The authentication event stream that satisfies RBI Clause 15 also satisfies ISO 27001 A.8.15, SEBI CSCRF PR.AA.S8, and SOC 2 CC7.2. The provisioning audit trail that satisfies SOC 2 CC6.2 also satisfies RBI Clause 8(c), ISO 27001 A.5.16, and DPDPA Clause 8(4). The privileged session recordings that satisfy IRDAI Items 144 and 145 also satisfy RBI Clause 15, ISO 27001 A.8.2, and SEBI CSCRF PR.AA.S12.

Organisations maintaining separate evidence packages for each framework are maintaining separate copies of the same underlying evidence. The controls generating that evidence are identical. The difference is architectural: one platform generating a shared, continuous audit trail serves every framework that examines it, while separate systems generating separate logs require separate compilation exercises before every audit.

Akku’s compliance coverage numbers reflect this architecture. 15 DORA articles fully addressed. 41 ISO 27001 clauses mapped. 88 SEBI CSCRF compliance items covered. 79 IRDAI requirements addressed. 36 GDPR compliance items supported. The same platform, the same audit trail, the same governance infrastructure, mapped to every framework’s clause numbering.

Diagnostic Questions

For any 30-day window in the last twelve months, can you produce a structured, tamper-evident export of all authentication events across all connected systems without manual log compilation from individual applications?

Is your access review process running on a defined cadence throughout the year, producing documented evidence at every cycle, or does it run once in the pre-audit window?

When a user is provisioned or deprovisioned, is the event automatically recorded with requester, approver, justification, timestamp, and downstream sync confirmation, or is the record reconstructed from email history?

Can you produce on demand the complete privileged session history for any user across any 90-day window, including session recordings and keystroke logs, without a manual export exercise?

Does your current compliance evidence infrastructure generate continuous, structured outputs as a byproduct of daily operations, or does it require a preparation effort before each audit cycle?

FAQs

What is the difference between audit preparation and continuous compliance evidence?

Audit preparation is the process of assembling evidence before an audit by pulling logs, reconstructing records, and compiling documentation. Continuous compliance evidence is generated automatically by controls as they operate, stored in structured, tamper-evident format, and available on demand without preparation effort. The distinction matters because every major compliance framework requires evidence of control operation throughout the audit period, not only at the point of examination. Evidence assembled before an audit reflects what can be reconstructed. Continuous evidence reflects what actually occurred.

Why does SOC 2 Type II specifically require continuous evidence rather than point-in-time evidence?

SOC 2 Type II attests that controls operated effectively throughout the audit period, typically six to twelve months. Auditors sample control outputs from multiple points across the period to assess operating effectiveness. A control that worked correctly for a few weeks before the audit but has no evidence of operation for the preceding months fails the Type II standard. Type I only requires evidence of suitably designed controls at a point in time. The shift from Type I to Type II is fundamentally a shift from demonstrating control design to demonstrating continuous control operation.

What does RBI Clause 15’s forensic evidence standard require that standard audit logs do not provide?

RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. Standard authentication logs record that a session occurred. Forensic-grade audit trails record what happened during the session, including commands executed, queries run, files accessed, and configuration changes made. For privileged access to critical systems, this requires session-level recording through SMARTAudit Trails, not authentication timestamps. The forensic standard also requires that records be generated at the time of the event and stored in tamper-evident format, so their integrity can be demonstrated during investigation.

How does SCIM connector health monitoring contribute to continuous compliance evidence?

SCIM connectors synchronise access granted in the IAM platform to connected applications. When connectors fail silently, provisioning and deprovisioning events in the IAM platform do not propagate to downstream applications. A user deprovisioned in the IAM platform may retain active access in a connected application if the SCIM sync failed without generating an alert. Connector health monitoring detects these failures before they create access gaps or evidence discrepancies. For compliance evidence purposes, a deprovisioning record in the IAM platform that did not result in actual access removal is an incomplete evidence record.

Which compliance frameworks specifically require on-demand log access rather than periodic log review?

SEBI CSCRF GV.OC.S2(G3) explicitly requires that logs, user details, and application data be accessible to SEBI on demand. IRDAI ICS Item 274 requires that audit trail evidence be producible for regulatory examination on demand. RBI Clause 15 requires audit trails available for forensic investigation, which implies on-demand availability. ISO 27001 A.8.15 requires that logs be kept and regularly reviewed, with availability for investigation when security incidents occur. All of these requirements are satisfied only by a continuous, structured, queryable audit log infrastructure, not by periodic log exports stored in flat files.

Can continuous compliance evidence infrastructure reduce the time IT teams spend on audit preparation?

Yes. Akku’s key metric of 50% time saved by IT teams during compliance preparation reflects this directly. When provisioning records, access review outcomes, authentication event logs, and privileged session recordings are generated continuously and stored in structured, exportable format, audit preparation becomes a log export and mapping exercise rather than a reconstruction effort. The reduction in preparation time is proportional to the completeness of continuous evidence generation. Organisations with partial automation, some structured records and some manual ones, see proportionally smaller reductions.

Introduction

IRDAI ICS Annexure III Item 14 requires that all access to organisational systems be authenticated through a centralised authentication mechanism. This is not a recommendation to deploy SSO for user convenience. It is a compliance obligation with a specific architectural requirement: a single identity source, a unified authentication layer covering all systems, consistent MFA enforcement, and a centralised audit trail of all authentication events.

Most insurance IT teams have deployed SSO for some applications. The compliance gap is almost always in coverage and architecture. SSO deployed for cloud SaaS applications but not for legacy policy administration systems. MFA enforced at the web application layer but not for server management or database access. Authentication events logged per application in separate systems rather than consolidated into a single, queryable audit trail.

Item 14’s centralisation requirement means that every authentication event, regardless of which system the user is accessing, must route through the same identity layer and produce a record in the same audit trail. A user authenticating to a cloud CRM through SSO and the same user authenticating to a legacy claims system through a separate login page are two different authentication architectures. Item 14 requires the former for all systems.

This blog covers what Item 14 requires technically, how a centralised authentication architecture is implemented, and what compliance evidence it produces. All item references are drawn from the IRDAI ICS Annexure III checklist and Akku’s IRDAI compliance mapping documentation.

What Item 14 Requires Technically

Item 14’s centralised authentication requirement has four distinct technical components. Each component has implementation requirements that go beyond simply deploying an SSO solution.

Single identity source

Centralised authentication begins with a single identity store. If users exist in multiple directories, an Active Directory for on-premises systems, a separate cloud directory for SaaS applications, and application-specific user databases for custom systems, authentication cannot be truly centralised because the identity layer is fragmented.

A single identity source means one directory holds all workforce identities and serves as the authoritative source for all authentication decisions. Applications that currently maintain their own user databases must be migrated to authenticate against the centralised directory. Legacy systems that cannot support modern authentication protocols must connect through credential replay or protocol bridging rather than maintaining separate credentials.

Akku’s unified cloud identity store serves as this single source. It is designed to be the only identity store an organisation needs, providing identity credentials to modern SaaS applications, legacy systems, and custom internal applications. Directory synchronisation capabilities maintain consistency for organisations migrating from existing Active Directory or LDAP environments.

Unified authentication layer

A unified authentication layer means every application routes authentication through the same identity provider, regardless of the protocol it supports. Modern SaaS applications authenticating via SAML, OIDC, or OAuth connect directly to the Akku IdP. Legacy applications that do not support modern federation protocols connect through SSO with credential replay, which extends centralised authentication coverage to applications that cannot be federated natively.

This is the coverage gap that most partial SSO deployments carry. The applications that support SAML are covered. The legacy policy administration system, the claims processing platform, and the internal tools that predate modern authentication protocols are not. Item 14’s requirement covers all systems, not only those with modern protocol support.

Akku’s 500-plus pre-built connectors provide plug-and-play integration for common SaaS applications. Credential replay extends coverage to legacy applications without protocol support. Desktop SSO extends the centralised authentication layer to domain-joined workstations, covering the local login layer that application-level SSO does not address.

Consistent MFA enforcement

Centralised authentication enables consistent MFA enforcement because MFA policy is applied at the identity provider layer, not at each individual application. When MFA is configured at the IdP level, every application that routes authentication through the IdP inherits MFA enforcement without requiring separate MFA configuration per application.

Item 14’s centralisation requirement makes Items 52, 64, and 65’s MFA requirements technically achievable at scale. Enforcing MFA for privileged access to network devices, for remote access to critical applications, and for all user access to sensitive systems requires a centralised authentication layer through which MFA policy can be applied consistently.

Akku’s Adaptive MFA is configured at the platform level and applies to all connected applications. Step-up authentication for high-sensitivity access, device-aware authentication for endpoint compliance verification, and geo-location based access restrictions are all applied through the centralised authentication layer.

Centralised audit trail

A centralised authentication layer produces a centralised authentication audit trail as a structural byproduct. Every authentication event across every connected application generates a structured log record in a single audit trail, with actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome.

This is the audit trail that IRDAI Items 2, 35, and 274 require: a complete record of all access to organisational systems, in tamper-evident format, available for regulatory examination on demand. When authentication is fragmented across multiple systems, producing this record requires manual compilation from multiple log sources. When authentication is centralised, the record exists as a continuous, queryable stream.

Implementation Architecture for Item 14 Compliance

Implementing Item 14 in an insurance environment requires addressing the specific system landscape that most insurers operate: a mix of cloud SaaS applications, on-premises legacy systems, custom-built internal tools, and infrastructure management interfaces.

Cloud SaaS applications

Cloud SaaS applications supporting SAML 2.0, OIDC, or OAuth connect to Akku as a centralised IdP through standard federation. The connection is typically configured in minutes using Akku’s pre-built connector catalogue. Authentication events from these applications flow into the centralised audit trail automatically.

Legacy and on-premises systems

Legacy policy administration systems, claims platforms, and on-premises line-of-business applications require one of two approaches depending on their technical capabilities. Systems that support LDAP authentication can authenticate against Akku’s cloud directory directly or through directory synchronisation. Systems with no directory integration capability can be covered through SSO with credential replay, which intercepts the application’s login form and injects credentials managed by the centralised identity layer.

Infrastructure management interfaces

Server management consoles, database management interfaces, and network device management systems require PAM-layer coverage rather than application-layer SSO. AkkuReka’s outbound worker architecture deploys in the same network segment as the target systems and routes privileged sessions through the centralised authentication layer. This extends Item 14’s centralised authentication requirement to the infrastructure layer, covering the access paths that application-level SSO does not reach.

Audit trail consolidation

The centralised audit trail is a structural output of routing all authentication through a single identity layer. No additional log aggregation configuration is required for the authentication event stream. Privileged session recordings from SMARTAudit Trails and endpoint compliance events from MDM and GPO Manager supplement the authentication audit trail with activity-level evidence.

Compliance Evidence Item 14 Produces

A correctly implemented centralised authentication architecture produces four categories of compliance evidence relevant to IRDAI ICS requirements.

Authentication event log covering every login attempt across all connected systems with actor identity, timestamp, source IP, device, location, MFA method, and outcome. This satisfies Items 2, 5, 35, 54, 55, and 274.

MFA enforcement evidence showing that every authentication event to covered systems included a successful MFA challenge. This satisfies Items 52, 64, and 65 for the systems within the centralised authentication perimeter.

Access governance records covering provisioning, de-provisioning, role changes, and access reviews with full approval audit trails. This satisfies Items 6, 10, 26, 33, 150, 152, 155, 157, 189, and 341 through the IGA and User Lifecycle Manager modules.

Privileged session recordings for every infrastructure-level session brokered through AkkuReka. This satisfies Items 144, 145, 190, and 274 through SMARTAudit Trails.

Akku’s IRDAI mapping shows Cloud Directory and SSO together address Items 14, 50, 135, 176, 204, 298, and 300 across seven total mappings.

Diagnostic Questions

Does every system in your organisation, including legacy policy administration platforms and claims processing tools, authenticate users through a single centralised identity layer, or do some systems maintain separate credential stores?

Can you produce on demand a complete authentication event log covering every login attempt across all connected systems for any 30-day period an IRDAI examiner requests, from a single queryable source without manual compilation?

Is MFA enforcement applied at the identity provider layer so that every application inheriting authentication from the centralised IdP automatically enforces MFA, or is MFA configured separately per application with inconsistent coverage?

Do your infrastructure management interfaces, including server management consoles and database management tools, route authentication through the same centralised identity layer as your application-layer SSO, or do they have separate authentication mechanisms?

When an employee’s employment ends, does deprovisioning of their centralised identity result in automatic access revocation across all connected systems simultaneously, or does each system require a separate deprovisioning action?

CTAs

See how Akku addresses IRDAI Item 14 centralised authentication requirements across cloud, legacy, and infrastructure systems.

Book a conversation with the Akku team to assess your current authentication architecture against IRDAI ICS compliance requirements.

FAQs

What is the difference between deploying SSO and implementing centralised authentication as Item 14 requires?

SSO deployment typically covers the applications that support modern federation protocols such as SAML and OIDC. Centralised authentication as Item 14 requires covers all systems, including legacy applications that do not support modern protocols, infrastructure management interfaces, and desktop login. The key architectural distinction is that every authentication event routes through a single identity layer that produces a unified audit trail. A partial SSO deployment where some systems authenticate through the IdP and others maintain separate credentials does not satisfy Item 14’s centralisation requirement.

How does credential replay extend centralised authentication to legacy systems?

Credential replay is a technique where the SSO platform intercepts a legacy application’s login form and injects credentials managed by the centralised identity layer, without requiring the application to support SAML, OIDC, or other modern federation protocols. The user authenticates to the centralised IdP with MFA, and the IdP handles the legacy application’s authentication transparently. From the user’s perspective, the experience is SSO. From the centralised audit trail’s perspective, the authentication event is captured at the IdP layer. This extends Item 14’s centralised authentication requirement to applications that cannot be federated natively.

Does Item 14’s centralised authentication requirement apply to privileged infrastructure access as well as application access?

Yes. Item 14 requires that all access to organisational systems be authenticated through a centralised mechanism. This includes infrastructure management interfaces such as server SSH access, database management consoles, and network device management interfaces. These access paths are not covered by application-layer SSO. PAM-layer coverage through AkkuReka’s session proxy architecture extends the centralised authentication requirement to infrastructure access, routing every privileged session through the Akku IAM layer before the target connection opens.

What does a centralised authentication audit trail contain, and how does it differ from individual application logs?

A centralised authentication audit trail contains a structured log record for every authentication event across all connected systems: actor identity, timestamp, source IP, device identifier, geographic location, MFA method, and outcome. Individual application logs contain authentication events for that application only, in the application’s own log format, requiring manual compilation and format normalisation to produce a consolidated view. A centralised audit trail is queryable across all systems simultaneously, exportable in structured format for regulatory submission, and append-only to prevent post-hoc modification.

How long should authentication event logs be retained to satisfy IRDAI ICS requirements?

The IRDAI ICS Guidelines do not specify a precise retention period in Item 14 itself. Item 35 requires that audit logs be retained for a period defined in the organisation’s IT security policy, sufficient for forensic investigation and regulatory examination. Industry practice at insurance organisations in India typically maintains authentication event logs for a minimum of one year, with privileged session recordings retained for two years or longer depending on the sensitivity of the systems accessed. The retention period should be defined in the IT security policy and consistently applied across all log types.

Can centralised authentication through Akku cover both corporate-owned devices and BYOD devices used by insurance agents and intermediaries?

Yes. Akku’s contextual access controls apply device-based restrictions at the identity layer. Corporate-owned devices enrolled in MDM can be verified as compliant before access is granted. BYOD devices can be permitted for some application access with additional MFA requirements and data transfer restrictions enforced through GPO Manager’s browser-level controls. The centralised authentication layer applies these policies consistently regardless of device type, with every authentication event recorded in the unified audit trail whether the device is corporate-owned or personally owned.

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.