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.