Introduction

SOC 2 Trust Services Criteria CC7.2 requires that the entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, or errors affecting the entity’s ability to meet its objectives. For IAM specifically, CC7.2 is the criterion that requires authentication anomaly detection, privileged session monitoring, and the technical infrastructure to surface suspicious access patterns without relying on manual log review.

Most organisations pursuing SOC 2 Type II have some form of monitoring in place. Authentication failures are logged. System events are recorded. Security teams review logs on a defined schedule. CC7.2 requires more than this. The criterion expects that monitoring is proactive and automated: anomalies are detected as they occur or shortly after, not discovered during a weekly log review. The distinction matters because the threat scenarios CC7.2 is designed to surface, credential stuffing, session hijacking, and insider access abuse, often complete within hours. A weekly log review discovers them after the fact. Automated anomaly detection surfaces them during or immediately after the event.

The authentication layer is where CC7.2 is most relevant for IAM-focused organisations. Every access event generates an authentication event. Authentication events contain the signals that distinguish normal access from anomalous access: geographic location, device identity, time of day, MFA outcome, and session duration. An anomaly detection layer that evaluates these signals continuously and generates alerts when they indicate suspicious patterns is what CC7.2 requires at the authentication layer.

This blog covers what CC7.2 requires technically, what SOC 2 Type II auditors examine for the criterion, and how Adaptive MFA anomaly detection and privileged session monitoring satisfy it.

What CC7.2 Requires

CC7.2 is part of the System Operations category and covers monitoring of system components for anomalies. The criterion applies broadly to infrastructure monitoring, application monitoring, and security event monitoring. For IAM, the relevant scope is authentication event monitoring, access pattern monitoring, and privileged session monitoring.

Automated anomaly detection

CC7.2 requires that monitoring be automated and capable of detecting anomalies without requiring manual examination of every log entry. The monitoring infrastructure must evaluate events against a baseline of normal behaviour and generate alerts when events deviate from that baseline.

The baseline comparison is what distinguishes anomaly detection from event logging. Event logging records that events occurred. Anomaly detection evaluates whether events are consistent with expected patterns and surfaces those that are not. A user logging in from their usual location at their usual time using their usual device is an expected event. The same user logging in from a different country two hours after their last domestic login is an anomaly that warrants investigation.

For CC7.2 operating effectiveness in a SOC 2 Type II engagement, the monitoring must have operated continuously throughout the audit period. Anomaly detection deployed in the month before the audit does not satisfy operating effectiveness for a 12-month period. The continuous operation evidence is what Type II auditors sample from across the period.

Response to detected anomalies

CC7.2 requires not only that anomalies be detected but that appropriate actions be taken when they are identified. The response component requires that alerts generate investigation workflows, that suspicious sessions can be terminated, and that the response actions are logged with timestamps.

For authentication anomalies, the response is typically step-up authentication: escalating the authentication challenge when signals indicate elevated risk. For privileged session anomalies, the response may include immediate session termination by an administrator. Both response types must produce logged evidence of the action taken.

Authentication Layer Anomaly Detection for CC7.2

The authentication layer is the primary monitoring surface for CC7.2 in IAM environments. Every access attempt generates an authentication event containing the signals that indicate normal or anomalous access patterns.

Signals that indicate authentication anomalies

Geographic anomalies: a user authenticating from a location significantly different from their historical access pattern, or from a location inconsistent with their role or the organisation’s operations. Impossible travel: two authentication events for the same user from geographically distant locations within a timeframe that makes physical travel impossible.

Device anomalies: authentication from an unrecognised device that has not previously been associated with the user account, particularly when combined with other risk signals. For environments where device compliance is enforced, authentication from a non-compliant device is an anomaly by definition.

Time-of-day anomalies: authentication at unusual hours significantly outside the user’s historical access pattern. For privileged users with defined permitted access hours, any authentication outside those hours is a policy violation as well as a potential anomaly.

MFA failure patterns: multiple consecutive MFA failures for the same account, or MFA failures across multiple accounts from the same source IP, are indicators of credential stuffing or account takeover attempts.

Behavioural baseline deviations: access to systems or resources not previously accessed by the user, session durations significantly longer or shorter than the user’s historical pattern, or access volume significantly higher than baseline.

How Adaptive MFA implements CC7.2 anomaly detection

Akku’s Adaptive MFA evaluates each authentication event against the signals above. AI-powered anomaly detection compares the authentication context with the user’s behavioural baseline and the organisation’s access patterns. When signals indicate elevated risk, the authentication challenge escalates: an additional MFA factor is required, the session is held for administrator review, or access is blocked pending investigation.

Every anomaly detection event is logged with the triggering signals, the risk assessment, the response action, and the outcome. This event stream constitutes the CC7.2 monitoring evidence: a continuous record showing that anomaly detection was operating throughout the audit period, that anomalies were surfaced, and that appropriate responses were triggered.

Risk and audit dashboards surface anomaly patterns for administrator review. MFA failure spike alerts, geographic anomaly notifications, and new device access events are presented in the admin console as actionable items requiring investigation. The dashboard provides the monitoring interface CC7.2 requires: a view into the anomaly detection output that enables timely response.

Privileged Session Monitoring for CC7.2

CC7.2’s system component monitoring requirement extends to privileged access monitoring. Privileged users with access to critical systems represent the highest-impact anomaly scenario: an administrator whose session is compromised or who is abusing their access has significantly more potential impact than a standard user.

What privileged session monitoring requires

Real-time visibility into active privileged sessions is the operational monitoring capability CC7.2 requires for the privileged access layer. Administrators must be able to view all currently active privileged sessions and identify any that appear anomalous: unexpected target systems, unusual session duration, or activity patterns inconsistent with the session’s stated purpose.

Session termination capability is the response component: when a suspicious session is identified, it must be terminable immediately. The termination action must be logged with the administrator’s identity, the termination timestamp, and the reason.

Historical session review, examining completed session recordings for anomalous behaviour, is the retrospective monitoring component. For CC7.2 operating effectiveness, both real-time monitoring and retrospective review capabilities must be demonstrated.

How AkkuReka’s monitoring addresses CC7.2

The Akku admin console provides real-time visibility into all active privileged sessions. Each session displays actor identity, target system, session duration, protocol, and current activity status. Any active session can be terminated instantly from the console. Termination events are logged with administrator identity, timestamp, and reason.

SMARTAudit Trails provide the retrospective monitoring capability. Session recordings indexed by timestamp, command string, and SQL query text allow administrators and security teams to search across historical sessions for specific command patterns or query types without reviewing every recording manually. This searchable recording infrastructure is what makes retrospective anomaly detection operationally viable at scale.

The combination of real-time monitoring with immediate termination capability and retrospective session search satisfies CC7.2’s monitoring and response requirements for the privileged access layer.

What SOC 2 Type II Auditors Examine for CC7.2

Monitoring infrastructure examination

Auditors examine whether automated anomaly detection is in place and operating continuously. They review the monitoring infrastructure configuration, verifying that it evaluates authentication events against baselines rather than only logging them. They look for evidence of anomaly alerts generated during the audit period, verifying that the detection capability was active throughout.

A monitoring infrastructure with no anomaly alerts generated during a 12-month audit period raises a credibility question: either the environment experienced no anomalous events, which is implausible for most organisations, or the monitoring is not sufficiently sensitive to detect the anomalies that occurred.

Alert and response evidence

Auditors examine a sample of anomaly alerts generated during the audit period. For each alert, they verify that it was investigated and that a response was documented. An alert that generated no investigation record indicates that the monitoring produces alerts but the response component is absent.

The response documentation does not need to show that every alert indicated a genuine security incident. Most anomaly alerts will be false positives or low-severity events. What the documentation must show is that alerts were reviewed, assessed, and either investigated or cleared with a documented rationale.

Privileged session monitoring demonstration

Auditors may request a demonstration of real-time privileged session monitoring capability. They ask administrators to show the current active sessions view and demonstrate session termination capability. An organisation that cannot demonstrate this capability during the audit has a gap in CC7.2 implementation for the privileged access layer.

Diagnostic Questions

Does your authentication infrastructure evaluate each login event against a behavioural baseline and generate alerts when anomalies are detected, or does it log authentication events without evaluating them for anomalous patterns?

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

Can administrators view all active privileged sessions in real time from a monitoring console, and can any active session be terminated instantly from that console with the termination event logged?

Does your monitoring infrastructure generate alerts for geographic anomalies, impossible travel events, MFA failure spikes, and new device access events, or are these patterns only discoverable through manual log review?

Has your anomaly detection infrastructure been operating continuously throughout the last audit period, with evidence of detection events from across the full period available for auditor sampling?

CTAs

See how Akku’s Adaptive MFA anomaly detection and privileged session monitoring address SOC 2 CC7.2 requirements across authentication and privileged access layers.

Book a conversation with the Akku team to assess your current monitoring infrastructure against SOC 2 Type II CC7.2 operating effectiveness requirements.

FAQs

What is the difference between CC7.1 and CC7.2 in SOC 2, and do they require separate controls?

CC7.1 requires that the entity uses detection and monitoring procedures to identify changes to configurations or new vulnerabilities, and conducts ongoing monitoring of the environment. It focuses on configuration monitoring and vulnerability detection. CC7.2 requires monitoring of system components for anomalies indicative of malicious acts, errors, or events affecting objectives. It focuses on behavioural anomaly detection and incident precursor identification. Both are required and they address different monitoring layers. CC7.1 is satisfied by configuration monitoring and vulnerability scanning capabilities. CC7.2 is satisfied by authentication anomaly detection, privileged session monitoring, and security event correlation. Satisfying one does not satisfy the other.

What does CC7.2 require for the response to detected anomalies, and how is this evidenced?

CC7.2 requires that appropriate actions be taken when anomalies are detected. The response component requires that alerts generate investigation workflows, that suspicious sessions can be terminated, and that the actions taken are logged. Evidencing the response component requires: alert records showing that anomalies were detected with triggering signals and timestamps, investigation records showing that each alert was reviewed and assessed, response records showing what action was taken for each alert, whether investigation, clearance, or escalation, and for privileged session anomalies, session termination records where termination was the response. The absence of response records for anomaly alerts is a CC7.2 finding regardless of how effective the detection infrastructure is.

How does Adaptive MFA’s step-up authentication function as a CC7.2 anomaly response?

When Adaptive MFA’s anomaly detection identifies elevated risk signals at an authentication event, the response is to escalate the authentication challenge: requiring an additional factor, blocking the authentication pending investigation, or routing the session for administrator review. This step-up response is both a security control and a CC7.2 compliance mechanism. The step-up event is logged with the triggering signals, the risk assessment, the additional factor required, and the outcome. For auditors examining CC7.2, this event stream demonstrates that the monitoring infrastructure detected anomalies, generated a proportionate response, and logged the response with sufficient detail for evidence review.

What constitutes a sufficient baseline for authentication anomaly detection under CC7.2?

A sufficient baseline captures the typical authentication patterns for each user or user category: normal geographic locations, normal device types, normal access hours, normal session frequencies, and normal resource access patterns. The baseline must be established from historical data with sufficient depth to distinguish genuine patterns from noise. For new users with limited historical data, peer group baselines, comparing the user’s behaviour to others in the same role or department, can supplement individual baselines. The baseline must be updated continuously to accommodate legitimate changes in user behaviour, such as travel or role changes, without generating persistent false positive alerts.

Can the same monitoring infrastructure satisfy both SOC 2 CC7.2 and ISO 27001 A.8.16 simultaneously?

Yes. SOC 2 CC7.2 and ISO 27001:2022 A.8.16 both require monitoring of system components for anomalous behaviour with appropriate response actions. The same Adaptive MFA anomaly detection infrastructure, risk and audit dashboards, and privileged session monitoring capability satisfy both criteria from the same technical controls. The evidence required differs in format and audit context: SOC 2 auditors sample anomaly alert records and investigation documentation across the Type II audit period, while ISO 27001 auditors examine monitoring procedures and evidence that the monitoring was operating effectively during the certification period. The underlying monitoring infrastructure that generates this evidence is identical for both frameworks.

How frequently should anomaly alert thresholds be reviewed to maintain CC7.2 operating effectiveness?

Anomaly detection thresholds should be reviewed when the baseline changes significantly, when the false positive rate indicates that thresholds are miscalibrated, and at least annually as part of the ISMS review process for ISO 27001 or the controls review for SOC 2. Thresholds that generate too many false positives create alert fatigue, leading to alerts being dismissed without investigation. Thresholds that are too permissive miss genuine anomalies. The threshold review process itself should be documented and the outcomes recorded, as the review process is evidence that the monitoring infrastructure is actively managed rather than passively operated.

Introduction

DPDPA Clause 8(4) requires Data Fiduciaries to implement appropriate technical and organisational measures to ensure effective observance of the provisions of the Act. This is a technical engineering obligation, not a policy drafting exercise. The appropriate technical measures that Clause 8(4) requires include role-based access controls for personal data systems, segregation of duties enforcement preventing conflicting access to personal data, periodic access reviews ensuring access remains appropriate, and automated deprovisioning when processing purposes are fulfilled.

Most legal and compliance teams reading Clause 8(4) understand it as a governance obligation: document what measures are in place, appoint a Data Protection Officer, maintain records of processing activities. These are real obligations. But Clause 8(4)’s appropriate technical measures requirement goes beyond governance documentation into the IT infrastructure layer. A policy stating that access to personal data is controlled does not constitute a technical measure. An RBAC implementation that restricts access to personal data systems to roles with an authorised processing purpose does.

The IT team’s responsibility under Clause 8(4) is to build and maintain the access control infrastructure that makes the data protection obligations in Clauses 5 through 8 technically enforceable. Consent management, Data Principal rights fulfilment, and breach prevention all depend on having an access control foundation that knows who has access to personal data systems, on what basis, and with what scope.

This blog covers what Clause 8(4) specifically requires from the IT access control layer, how each requirement maps to technical controls, and what evidence the Data Fiduciary must be able to produce to demonstrate compliance.

What Clause 8(4) Requires at the Technical Layer

Clause 8(4) uses the phrase appropriate technical and organisational measures to ensure effective observance. Effective observance means the measures must actually work, not merely exist. A technical measure that is documented but not deployed does not constitute effective observance. A deployed control that produces no evidence of operation does not enable demonstration of effective observance.

Access limitation to authorised purposes

The first technical requirement implied by Clause 8(4) is that processing be limited to the purposes for which personal data was collected. At the access control layer, this means each user’s access to personal data systems must be scoped to the processing activities their role legitimately requires.

A customer service representative whose role is to handle billing queries should have access to billing records but not to medical history, policy claim details, or any other personal data categories their role does not require. This is the data minimisation principle applied at the access control layer. RBAC is the technical mechanism: role definitions determine access scope, and access scope is limited to what the role’s authorised processing purposes require.

The distinction between accessing personal data for an authorised purpose and accessing it for an unauthorised purpose is not something a user can reliably police themselves. A system where every customer service representative can access all customer records including categories unrelated to their function does not implement Clause 8(4)’s processing limitation, regardless of how clearly the usage policy is written.

Segregation of duties for personal data processing

Clause 8(4)’s effective observance requirement extends to preventing conflicting access combinations that could enable unauthorised processing without detection. A user who can both access personal data and modify the audit log that records access events can access data without leaving a traceable record. A user who can both provision access to personal data systems and certify access reviews can grant themselves access and certify it as appropriate.

SoD enforcement at the IAM layer prevents these conflict combinations. The rules engine defines which role combinations are incompatible from a personal data governance perspective and detects violations when they occur.

Periodic access reviews for personal data systems

Clause 8(4)’s ongoing observance requirement implies that access to personal data systems must be reviewed periodically to ensure it remains appropriate. Access that was appropriate when granted may become inappropriate as roles change, processing purposes evolve, or the business relationship with the Data Principal changes.

Periodic access reviews that produce documented certification or revocation decisions for every entitlement to personal data systems are the technical mechanism for maintaining ongoing observance of the access limitation requirement.

Automated deprovisioning on purpose fulfillment

Clause 8(7)(a) requires erasure and cessation of processing when the purpose is no longer served. At the access layer, purpose fulfillment means the user’s role no longer requires access to the personal data system. Employment termination is the clearest trigger: a departed employee has no current processing purpose for any personal data system access. Role changes may also trigger purpose fulfillment for specific systems.

Automated deprovisioning triggered by HR events ensures that access ceases when the purpose is fulfilled without depending on manual IT action. The deprovisioning audit trail demonstrates that cessation occurred promptly and completely.

Access Control Evidence Clause 8(4) Requires

Clause 8(4)’s demonstrability requirement under the broader accountability principle in Clause 8(4) and Article 5(2) of GDPR’s equivalent means the Data Fiduciary must be able to produce evidence that technical measures are operating. The evidence requirements cover four categories.

Access authorisation evidence

For every user with access to a personal data system, the Data Fiduciary must be able to produce the authorisation record showing who approved the access, on what basis, for what processing purpose, and when. This record demonstrates that access to personal data was granted through a formal process tied to an authorised processing purpose.

Access granted informally, where an administrator copied an existing user’s access configuration or responded to a verbal request, does not produce this record. A formal approval workflow that generates structured records at the time of every provisioning event is required.

Access scope evidence

The Data Fiduciary must be able to demonstrate that access scope is appropriate to processing purposes. This requires a current view of every user’s access entitlements across all connected personal data systems, queryable at any time.

The consolidated who-has-access-to-what view in Akku’s IGA module provides this capability. Every user’s current entitlements across all connected applications are visible in a single interface, with the role and approval basis for each entitlement accessible from the same view.

Access review evidence

The Data Fiduciary must be able to produce access review records showing that access to personal data systems was periodically examined and that entitlements no longer appropriate were revoked. The review records must cover a period sufficient to demonstrate ongoing observance, not only the most recent cycle.

Deprovisioning evidence

The Data Fiduciary must be able to demonstrate that access ceased when the processing purpose was no longer served. Deprovisioning records showing same-day access removal for employment terminations, with SCIM sync confirmation from every connected personal data system, constitute this evidence.

Mapping Clause 8(4) to Specific IAM Controls

Each component of Clause 8(4)’s technical requirement maps to a specific IAM control.

Processing limitation maps to RBAC and ABAC

Role definitions in Akku’s IAM platform scope each user’s access to the personal data systems their role’s processing purposes require. Attribute-based controls further refine access within systems, limiting which data categories a user can access based on their current active processing context.

The role matrix that defines which roles have access to which personal data systems for which processing purposes is the governance documentation that underpins the RBAC implementation. Both the documentation and the technical configuration must exist: documentation without implementation is policy, not technical measure.

Conflict prevention maps to SoD enforcement

The IGA SoD rules engine defines incompatible role combinations for personal data processing. Access provisioning and access certification must be separated. Personal data access and audit log administration must be separated. Data export capabilities and data deletion capabilities must be separated where the combination creates a fraud or concealment risk.

The rules engine detects violations continuously and triggers remediation workflows. The violation detection log and remediation records constitute the SoD enforcement evidence for Clause 8(4).

Ongoing observance maps to access review campaigns

Access review campaigns for personal data systems run on a defined cadence. Every user’s entitlements to personal data systems are presented to appropriate reviewers for certification or revocation. Every decision is timestamped and logged. Revocations trigger automated deprovisioning.

The campaign records from every review cycle throughout the compliance period constitute the ongoing observance evidence Clause 8(4) requires.

Purpose fulfillment maps to automated deprovisioning

Automated deprovisioning triggered by HR system events, consent withdrawal, and access review revocations ensures that access ceases when the processing purpose is no longer served. The deprovisioning audit trail, covering every system from which access was removed with timestamps and sync confirmations, constitutes the cessation evidence.

Akku’s DPDPA mapping shows Identity and Access Governance addresses Clause 8(4) directly. Access Manager, Adaptive MFA, Privileged Access Manager, and the broader access control stack collectively address Clause 8(5)’s security safeguard requirement that complements 8(4)’s access limitation requirement.

The Connection Between Clause 8(4) and Breach Notification

Clause 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals in the event of a personal data breach. The technical infrastructure required to fulfil this notification obligation is the same infrastructure Clause 8(4) requires for access controls.

Identifying affected Data Principals requires knowing which users had access to the compromised personal data system and what data they could access. This requires the access control records Clause 8(4) mandates: role-based access scoping, provisioning records showing access basis, and session activity logs for privileged access.

Determining the scope of the breach requires knowing what was accessed. For standard user access, application-level logs provide this information. For privileged users with direct database access, SMARTAudit Trails capturing SQL queries are the evidence source. Without this session-level evidence, breach scoping is guesswork, not determination.

An organisation with weak Clause 8(4) technical measures will struggle with Clause 8(6) breach notification because the evidence infrastructure required for both obligations is the same.

Diagnostic Questions

For every user with access to a personal data system, can you identify the processing purpose that justifies the access and the approval record that authorised it, without manual reconstruction?

Does your RBAC implementation scope each user’s access to personal data systems to only the categories their role’s processing purposes require, or does role-based access provide broader access than the processing purpose strictly requires?

Has your organisation defined and enforced SoD rules preventing the same user from both provisioning access to personal data systems and certifying access reviews for those systems?

If the Data Protection Board requested evidence that access to a specific personal data system was limited to authorised personnel with documented processing purposes over the last 12 months, could you produce that evidence from a structured, queryable source within 48 hours?

When an employee with access to personal data systems departs, does access cease automatically across every connected personal data system within the same business day, with a timestamped completion record for each?

CTAs

See how Akku addresses DPDPA Clause 8(4) access control requirements through RBAC, SoD enforcement, access reviews, and automated deprovisioning for personal data systems.

Book a conversation with the Akku team to assess your current access control posture against DPDPA Clause 8(4)’s technical obligations.

FAQs

What is the difference between Clause 8(4)’s technical measures requirement and Clause 8(5)’s security safeguards requirement?

Clause 8(4) requires appropriate technical and organisational measures to ensure effective observance of the Act’s provisions, including ensuring processing is limited to authorised purposes. It is the access governance and control layer. Clause 8(5) requires reasonable security safeguards to prevent personal data breaches. It is the security layer. Clause 8(4) governs who can access personal data and for what purpose. Clause 8(5) governs how that access is protected against compromise. Both are required simultaneously. RBAC and access reviews satisfy Clause 8(4). Adaptive MFA, encryption, and session recording satisfy Clause 8(5). A gap in either creates a separate compliance deficiency.

Does Clause 8(4) require a formal data classification scheme before access controls can be implemented?

A formal data classification scheme is a governance best practice that makes access control implementation more systematic, but Clause 8(4) does not explicitly require one. What Clause 8(4) requires is that access to personal data systems be limited to authorised processing purposes. This can be implemented through role-based access controls scoped to processing purpose categories without a formal classification scheme, provided the role definitions clearly reflect which personal data categories each role requires access to. A classification scheme that labels data by sensitivity and maps roles to classification levels is a more scalable approach for large organisations with complex data landscapes.

How does Clause 8(4) apply to third-party service providers who access personal data systems?

Third-party service providers who access personal data systems are either Data Processors under Clause 8(8), in which case the Data Fiduciary must ensure they implement equivalent technical measures, or they are separate Data Fiduciaries accessing data under their own lawful basis. For Data Processors with access to the Data Fiduciary’s personal data systems, Clause 8(4)’s technical measures requirement extends to their access: provisioning must be through a formal process tied to their processing scope, deprovisioning must occur promptly when the processing engagement ends, and session-level logging for privileged access is required. The same IAM controls that govern internal user access must be applied to Data Processor access.

What constitutes a processing purpose for RBAC design under Clause 8(4)?

A processing purpose under Clause 8(4) is the specific, defined reason for which personal data was collected as specified in the notice under Clause 5. For RBAC design, processing purposes translate into operational functions: handling customer service requests, processing insurance claims, conducting KYC verification, or producing financial statements. Each operational function requires access to specific personal data categories. The RBAC role definition maps the operational function to the personal data systems and data categories that function requires, scoping access to what the purpose actually needs rather than to the broadest plausible interpretation of the function. Over-scoping role access to personal data systems is a Clause 8(4) issue, not merely a best practice gap.

How should organisations handle the transition period before DPDPA Rules are finalised?

The DPDPA’s core obligations, including Clause 8(4)’s technical measures requirement, are in force even though the Rules specifying certain implementation details are not yet finalised. Organisations should implement the technical measures that the Act’s current text requires: access controls limiting processing to authorised purposes, security safeguards preventing breaches, consent management systems, and Data Principal rights fulfilment infrastructure. When the Rules are finalised, the implementation may require adjustment for specific details such as breach notification timelines and consent form requirements, but the foundational technical infrastructure should be operational before the Rules specify the precise format. Building the infrastructure after the Rules are finalised creates a compliance gap during the interim period.

Can Clause 8(4)’s technical measures requirement be satisfied by cloud-hosted IAM infrastructure, or does DPDPA require on-premises deployment?

DPDPA does not specify on-premises deployment as a requirement for technical measures. Cloud-hosted IAM infrastructure that implements the required access controls, audit trails, and lifecycle management capabilities satisfies Clause 8(4)’s technical measures requirement. The data localisation provisions in DPDPA, to the extent they are specified in the Rules, may affect where personal data is stored and processed, but the IAM infrastructure that governs access to that data is not subject to the same localisation requirements as the personal data itself. Akku supports both cloud-native SaaS deployment and on-premises deployment for organisations with specific sovereignty requirements.

Introduction

Indian ITeS companies processing US healthcare data on behalf of US covered entities are business associates under HIPAA. The Business Associate Agreement they sign with each covered entity creates direct HIPAA obligations, including implementation of the technical safeguards specified in 45 CFR 164.312. These are not contractual aspirations. They are regulatory requirements that the Office for Civil Rights enforces directly against business associates.

The technical safeguards in 45 CFR 164.312 cover four areas: access controls, audit controls, integrity controls, and transmission security. Each area has required implementation specifications, meaning they must be implemented, and addressable implementation specifications, meaning they must be implemented or the covered entity or business associate must document why an alternative is equivalent or why the specification is not reasonable. In practice, most addressable specifications are implemented because the documentation burden of the alternative is comparable to implementation.

Indian ITeS companies frequently underestimate their HIPAA exposure because their contracts are with US healthcare organisations and the regulatory enforcement is in the US. This does not reduce the obligation. A breach of PHI at an Indian business associate’s facility is a reportable breach under HIPAA, and the OCR has pursued enforcement actions against business associates including those operating outside the US.

This blog covers what each technical safeguard in 45 CFR 164.312 requires, which specifications are required versus addressable, and how IAM controls address each safeguard. All section references are drawn from 45 CFR Part 164 Subpart C.

Access Controls Under 164.312(a)(1)

Section 164.312(a)(1) requires covered entities and business associates to implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights.

Required implementation specifications

Unique user identification under 164.312(a)(2)(i) requires assigning a unique name or number to each user for identifying and tracking user identity. Shared accounts and generic credentials are non-compliant. Every individual who accesses PHI must be individually identifiable in the system audit trail.

Emergency access procedure under 164.312(a)(2)(ii) requires establishing procedures for obtaining necessary electronic protected health information during an emergency. This is a required specification because access to PHI may be needed when normal authentication mechanisms are unavailable.

Addressable implementation specifications

Automatic logoff under 164.312(a)(2)(iii) requires implementing electronic procedures that terminate an electronic session after a predetermined time of inactivity. This is addressable but universally implemented in practice.

Encryption and decryption under 164.312(a)(2)(iv) requires implementing a mechanism to encrypt and decrypt electronic protected health information. Addressable but effectively required for any organisation storing PHI on portable devices or transmitting it over untrusted networks.

How Akku addresses 164.312(a)(1)

Akku’s unified cloud identity store provides unique user identification for every individual accessing PHI systems, satisfying 164.312(a)(2)(i). No shared accounts or generic credentials are required when centralised identity management is implemented correctly.

RBAC scopes each user’s access to the PHI systems and functions their role requires. Contextual access controls restrict access by device compliance, IP range, geographic location, and time of day, implementing the technical policies and procedures 164.312(a)(1) requires.

GPO Manager enforces automatic logoff through centrally-configured session lockout policies, satisfying 164.312(a)(2)(iii).

AkkuVault’s AES-256-GCM encryption addresses the 164.312(a)(2)(iv) encryption requirement for credentials and sensitive data within the IAM platform’s scope.

Audit Controls Under 164.312(b)

Section 164.312(b) requires implementation of hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. This is a required specification with no addressable sub-specifications.

What 164.312(b) requires technically

The audit control requirement is straightforward in statement but demanding in implementation: every activity in PHI systems must be recorded and the recordings must be examinable. The examinable standard implies that records are structured and searchable, not stored in unstructured log files that require custom parsing to analyse.

For privileged users with direct access to PHI databases, audit controls require session-level activity recording. A database administrator querying a table containing patient records must have a session log showing the specific queries executed, not only an authentication record showing they connected to the database.

The audit controls must cover all PHI systems, not only the primary clinical application. If PHI is processed in analytics platforms, reporting databases, or custom-developed tools, all of these systems require audit controls. The scope of 164.312(b) follows the PHI, not the system category.

How Akku addresses 164.312(b)

Akku’s centralised authentication event log captures every authentication event across all connected PHI systems with actor identity, timestamp, source IP, device, MFA method, and outcome. This is the foundation of the audit control evidence.

SMARTAudit Trails provide the activity-level audit control 164.312(b) requires for privileged access to PHI databases and systems. SSH sessions to servers holding PHI produce keystroke logs. Database sessions to PHI databases produce SQL query capture. RDP sessions produce screen recordings. These session-level records are what the examinable standard requires for privileged access scenarios.

The append-only audit log architecture ensures that records cannot be modified after generation, satisfying the implicit integrity requirement of audit controls that are intended to be reliable evidence in enforcement proceedings.

Integrity Controls Under 164.312(c)(1)

Section 164.312(c)(1) requires implementation of policies and procedures to protect electronic protected health information from improper alteration or destruction. The addressable implementation specification under 164.312(c)(2) requires implementing electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorised manner.

What 164.312(c) requires technically

Integrity controls at the IAM layer address the access dimension of PHI integrity: ensuring that only authorised users with appropriate entitlements can modify PHI, and that modification events are logged with sufficient detail to detect unauthorised alterations.

The SoD requirement is relevant here: a user who can both modify clinical records and approve modifications has the ability to make and conceal unauthorised alterations. SoD enforcement at the IAM layer prevents conflicting modification and approval capabilities from being held by the same user.

Access logging that captures which users accessed which PHI records and what operations were performed is the monitoring layer that enables detection of unauthorised modifications. Without this layer, integrity violations are undetectable until their effects manifest clinically or operationally.

How Akku addresses 164.312(c)

RBAC enforces that modification access to PHI systems is limited to users whose role requires it. The IGA SoD rules engine prevents conflicting modification and approval role combinations from being held simultaneously.

For privileged users with direct database access, SMARTAudit Trails capture every SQL modification statement executed during privileged sessions. This provides the corroboration mechanism 164.312(c)(2) requires: a record of every modification event attributable to a specific user at a specific time.

Transmission Security Under 164.312(e)(1)

Section 164.312(e)(1) requires implementation of technical security measures to guard against unauthorised access to electronic protected health information that is being transmitted over an electronic communications network. The addressable specifications cover encryption of PHI in transit under 164.312(e)(2)(ii).

What 164.312(e) requires technically

Transmission security requires that PHI transmitted over any network, including internal networks, be protected against interception or unauthorised access. For IAM specifically, this covers the transmission of authentication credentials, session tokens, and any PHI that flows through the IAM platform during access control operations.

TLS 1.3 for all communications between the IAM platform components and connected systems is the current technical standard that satisfies 164.312(e)’s transmission security requirement. Older TLS versions are not considered adequate against current threat models.

The transmission security requirement applies to all network paths through which PHI transits, not only internet-facing connections. Internal network communications between the IAM platform, the session proxy, and target PHI systems must be encrypted.

How Akku addresses 164.312(e)

AkkuReka’s outbound worker architecture uses TLS 1.3 for all communications between the worker and the Akku cloud, and between the worker and target systems. All user sessions are proxied over TLS 1.3. This satisfies 164.312(e)’s transmission security requirement for all access paths brokered through Akku PAM.

AES-256-GCM encryption of credentials in AkkuVault addresses the data-at-rest component that complements transmission security for a complete PHI protection posture.

Business Associate Obligations for Indian ITeS Companies

Indian ITeS companies operating as HIPAA business associates face obligations beyond the technical safeguards. The Business Associate Agreement requires implementation of appropriate safeguards, reporting of breaches to the covered entity, and cooperation with OCR investigations. Understanding the technical safeguard implementation in the context of these broader obligations is important for managing HIPAA exposure.

Breach notification implications

A breach of unsecured PHI by a business associate must be reported to the covered entity without unreasonable delay and no later than 60 days after discovery. For an Indian ITeS company, discovery typically occurs when a security incident is detected. The technical infrastructure that enables rapid breach scoping, structured audit logs, privileged session recordings, and access governance records, is what makes the 60-day notification window operationally achievable.

An organisation without session-level audit controls for PHI systems cannot determine the scope of a PHI breach with confidence. Without knowing which records were accessed, the notification cannot identify the affected individuals, which is a required element of the breach notification.

OCR audit programme

The OCR conducts audits of covered entities and business associates to assess HIPAA compliance. For technical safeguards, auditors examine documentation of safeguard implementation, evidence that safeguards are operating, and audit logs demonstrating access control and audit control effectiveness. Indian ITeS companies subject to OCR audits must be able to produce this evidence for their US operations.

Akku’s HIPAA technical mapping shows access control, audit controls, and integrity controls are addressed across multiple platform modules. The technical safeguard evidence that an OCR audit requires is generated continuously by Akku’s operational controls as a byproduct of daily access governance activities.

Diagnostic Questions

Does every individual accessing PHI systems at your organisation have a unique user identifier in the system audit trail, with no shared accounts or generic credentials used for PHI system access?

For privileged users with direct access to PHI databases, is there a session-level audit record capturing the specific queries they executed, not only an authentication record confirming they connected?

When a workforce member whose role required PHI access changes roles or leaves the organisation, does their PHI system access cease within the same business day with a timestamped deprovisioning record?

Are all communications between your IAM platform components and PHI systems encrypted with current-standard TLS, including internal network communications between the session proxy and target systems?

If the OCR requested audit logs for PHI system access covering a specific 90-day period, could your organisation produce structured, complete records within the 60-day breach notification timeframe without manual compilation?

CTAs

See how Akku addresses HIPAA technical safeguards for Indian ITeS companies processing US healthcare data across access controls, audit controls, and transmission security.

Book a conversation with the Akku team to assess your current technical safeguard implementation against HIPAA 45 CFR 164.312 requirements.

FAQs

Are Indian ITeS companies directly subject to HIPAA, or only through their contracts with US covered entities?

Indian ITeS companies that create, receive, maintain, or transmit protected health information on behalf of a HIPAA covered entity are business associates under HIPAA. Business associates are directly subject to HIPAA’s security rule requirements, including the technical safeguards in 45 CFR 164.312, regardless of where they are incorporated or operate. The OCR has authority to enforce HIPAA directly against business associates, and enforcement actions have been taken against organisations operating outside the US. The Business Associate Agreement formalises these obligations contractually, but the regulatory obligation exists independently of the contract.

What is the difference between required and addressable implementation specifications under HIPAA?

Required implementation specifications must be implemented. There is no alternative. Addressable specifications must be implemented if reasonable and appropriate, or the covered entity or business associate must document why an equivalent alternative has been implemented or why the specification is not reasonable and appropriate given their environment. In practice, the documentation burden of demonstrating that an addressable specification is not reasonable and appropriate is typically comparable to implementing it. Most organisations implement addressable specifications rather than document exceptions. For Indian ITeS companies handling significant volumes of PHI, the risk of documented exceptions being challenged by the OCR during an audit makes implementation the safer approach.

How does HIPAA’s audit control requirement under 164.312(b) differ from the general logging requirement?

Section 164.312(b) requires that activity in PHI systems be recorded and examinable. The examinable standard goes beyond storing log files: records must be structured and searchable so that specific activity can be identified during an investigation or audit. For privileged access to PHI databases, this means session-level recording of database queries rather than authentication records alone. For a breach investigation, the examiner needs to identify which records were accessed, by whom, and when. Authentication logs establish that a connection occurred. Session-level query logs establish what data was accessed. The examinable standard requires the latter.

What constitutes a PHI breach for HIPAA reporting purposes, and how does IAM infrastructure support breach scoping?

A breach under HIPAA is the acquisition, access, use, or disclosure of PHI in a manner not permitted by the Privacy Rule that compromises the security or privacy of the PHI. For breach notification, the covered entity or business associate must identify the nature of the PHI involved, the unauthorised person who accessed or received the PHI, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. IAM infrastructure supports this scoping through structured access logs showing which users accessed which PHI systems and when, privileged session recordings showing what queries were executed and what data was returned, and provisioning records showing the access state of the compromised account at the time of the incident.

How should Indian ITeS companies structure their HIPAA technical safeguard documentation for OCR audit purposes?

OCR audits of technical safeguards typically request policies and procedures describing how each safeguard is implemented, evidence of implementation including system configuration records, access control policies, and audit log architecture documentation, and operating effectiveness evidence including samples of access logs, audit records, and access review records. Indian ITeS companies should maintain: a technical safeguard implementation document mapping each 164.312 specification to the specific technical control that satisfies it, system configuration records showing that the controls are deployed and configured as described, and operating evidence records demonstrating that controls are functioning throughout the audit period. This documentation structure mirrors the evidence requirements for ISO 27001 and SOC 2 and can largely be assembled from the same evidence sources.

Can the same IAM deployment satisfy both HIPAA technical safeguards and SOC 2 Type II requirements for Indian ITeS companies pursuing both?

Yes. The overlapping technical controls are substantial. HIPAA 164.312(a)(1) access controls and SOC 2 CC6.1 and CC6.2 both require unique user identification and formal access provisioning. HIPAA 164.312(b) audit controls and SOC 2 CC7.2 both require activity monitoring and anomaly detection. HIPAA 164.312(c) integrity controls and SOC 2 CC5.1 SoD requirements both address conflict prevention and modification accountability. A single IAM deployment implementing these controls produces compliance evidence for both frameworks from the same technical infrastructure. Indian ITeS companies frequently pursue SOC 2 and HIPAA simultaneously because their US healthcare clients require both, and the shared technical foundation makes joint pursuit efficient.

Introduction

Every major compliance framework that applies to Indian organisations contains a provisioning and deprovisioning requirement. The language differs. RBI Clause 8(c) calls it access governance with documented approval records. SEBI CSCRF PR.AA.S1 calls it identity lifecycle management. IRDAI ICS Items 6 and 26 call it controlled provisioning of user accounts. ISO 27001:2022 A.5.16 calls it identity management. DPDPA Clause 8(7) calls it erasure and cessation of processing when the purpose is served. SOC 2 CC6.2 and CC6.3 call it user registration and authorisation and modification or removal of access.

Different language, identical technical requirement: access must be formally granted through a documented process, and access must be removed completely and promptly when it is no longer required. Both halves of the requirement must be technically enforced and continuously evidenced.

The provisioning half fails when access is granted informally: over email, through a verbal request, via an ad-hoc IT ticket, or by an administrator who copies an existing user’s access configuration without a documented approval. The deprovisioning half fails when access removal is incomplete, delayed, or undocumented: a departed employee whose accounts were removed from Active Directory but persist in three SaaS applications, a contractor whose engagement ended without a formal deprovisioning trigger, or an employee who changed roles but retained access from every previous function.

Both failures produce audit findings across every framework that examines them. This blog covers what the provisioning and deprovisioning requirement looks like in each major framework, what technical controls are required to satisfy it, and what evidence the controls must produce.

Provisioning Requirements Across Frameworks

The provisioning requirement is consistent across frameworks at its core: access must be granted through a formal process that produces a documented authorisation record.

What each framework requires

RBI Clause 8(c) requires that access governance controls ensure only authorised users have access to information systems. Authorisation implies a documented process. An authentication log showing a user has access does not demonstrate that the access was formally authorised. The approval record does.

SEBI CSCRF PR.AA.S1 and GV.PO.S1 to S5 require that access be provisioned based on formally defined roles with technically-enforced policies. Birthright access defined by role and additional access requiring documented approval are the two provisioning mechanisms that satisfy this requirement.

IRDAI ICS Item 6 requires controlled provisioning of temporary and contractor accounts with documented lifecycle management. Item 26 requires that access provisioning follow a defined process. The controlled and defined qualifiers indicate that informal provisioning does not satisfy these items.

ISO 27001:2022 A.5.16 requires that the full lifecycle of identities be managed, including creation through a managed process. A.5.18 requires that access rights be provisioned through a formal process. Both controls must produce structured records for certification audits.

SOC 2 CC6.2 requires that prior to issuing system credentials and granting system access, the entity registers and authorises new users. The authorisation must precede access, not follow it. Access granted before the approval is complete fails CC6.2 regardless of whether approval is eventually obtained.

DPDPA Clause 8(4) requires appropriate technical measures to ensure processing is limited to authorised purposes. Provisioning access to personal data systems without a documented authorisation tied to a specific processing purpose fails this requirement.

What compliant provisioning evidence looks like

A compliant provisioning record must contain: requester identity, approver identity and approval timestamp, justification for the access grant, the specific access being granted including system and permission level, provisioning execution timestamp, and SCIM sync confirmation from each connected application.

The timestamp sequence matters. The approval timestamp must precede the provisioning execution timestamp. An approval record dated after the access was granted is not a compliant provisioning record.

Multi-step approval for sensitive access must be documented with every approver in the chain: line manager approval, system owner approval, and security team approval where required. The complete approval chain, not only the final approval, must be in the record.

How Akku produces compliant provisioning evidence

Akku’s access request and approval workflow captures every provisioning event with the complete required record at the time of the event. Birthright access provisioned automatically on joining is recorded with the role trigger, the access definition, and the provisioning execution timestamp. Additional access requested beyond role defaults is recorded with requester identity, approver identity, approval timestamp preceding provisioning, justification, access scope, and SCIM sync confirmation.

SCIM-based provisioning generates a downstream sync record for every connected application. When a provisioning action in Akku does not propagate successfully to a connected application due to a connector failure, the failure is logged and flagged for administrator attention. The provisioning record in Akku without a corresponding sync confirmation is an incomplete record, and Akku surfaces this discrepancy rather than allowing it to persist silently.

Deprovisioning Requirements Across Frameworks

The deprovisioning requirement is equally consistent across frameworks: access must be removed completely and promptly when it is no longer required, with a documented audit trail of every removal action.

What each framework requires

RBI Clause 19(a) requires that access be revoked promptly when the need ends or the user’s role changes. Promptly is not defined precisely but IS auditors interpret it as same-day for employment terminations and within the current business cycle for role changes.

SEBI CSCRF PR.AA.S1(G1g) and G1h require automatic disabling of dormant accounts and prompt revocation of access when employment or engagement ends. The automatic requirement means deprovisioning cannot depend on a manual trigger from the business unit.

IRDAI ICS Item 10 requires automatic disabling of dormant accounts. Items 26 and 33 require that access be removed when employment ends. The combination means both event-triggered deprovisioning and threshold-based dormant account management are required.

ISO 27001:2022 A.5.16 requires that identity deletion follow a managed process. A.5.18 requires that access rights be revoked when no longer required. Both must produce structured evidence that removal occurred.

SOC 2 CC6.3 requires that access be modified or removed based on the system of record for entitlements. When employment ends, the system of record must reflect the change and trigger access removal. Deprovisioning that relies on a separate IT ticket disconnected from the HR system of record fails this standard.

DPDPA Clause 8(7)(a) requires erasure and cessation of processing when the purpose is no longer served. For workforce systems, employment termination is the event that triggers this determination. Clause 8(7)(b) requires cessation and erasure when consent is withdrawn.

What compliant deprovisioning evidence looks like

A compliant deprovisioning record must contain: the trigger event, whether employment termination, role change, access review revocation, consent withdrawal, or dormant account threshold crossing. The systems from which access was removed. The removal timestamp for each system. SCIM sync confirmation from each connected application. The identity of the administrator or automated process that executed the deprovisioning.

Completeness is critical. A deprovisioning record showing removal from Active Directory and the primary SaaS applications but silent on the legacy policy administration system, the custom internal tool, and the infrastructure access credentials is an incomplete record. The record must cover every system the user had access to.

Timing is equally critical. The removal timestamp must be same-day for employment terminations under most frameworks. Removals completed days after the triggering event are findings under RBI, SEBI, and SOC 2.

How Akku produces compliant deprovisioning evidence

Akku’s automated deprovisioning workflow is triggered by HR system events through SCIM or API integration. When an employee’s record is marked inactive in the HR system, Akku receives the trigger and initiates deprovisioning across all connected applications simultaneously. Each application removal generates a timestamped deprovisioning record with system identity, removal timestamp, and SCIM sync confirmation.

The deprovisioning audit trail covers every connected application, not only those with native directory integration. Legacy applications covered through credential replay receive deprovisioning actions through Akku’s application connector, with the removal event logged alongside direct-integration removals in the same audit trail.

For role changes, Akku’s mover workflow triggers a re-provisioning action: access from the previous role is reviewed, entitlements no longer appropriate for the new role are revoked, and new role-based entitlements are provisioned. The complete workflow record, covering both the revocation of previous access and the provisioning of new access, is generated at the time of the role change event.

The Orphan Account Problem

Orphan accounts are user accounts that exist without a linked, active identity. They are the accumulated product of incomplete deprovisioning over time: employees who left without a formal deprovisioning trigger, contractor accounts created for specific projects and never removed, accounts created during system migrations with no owner, and service accounts whose owning service was decommissioned but whose accounts persisted.

Every framework reviewed above creates an orphan account risk because every framework requires access to cease when the need ends. Orphan accounts are evidence that deprovisioning failed at some point in the past. They represent both a security risk, credentials that may be valid with no active owner to notice suspicious usage, and a compliance finding.

Akku’s IGA orphan account management detects accounts across all connected applications that exist without a linked, active identity in Akku’s directory. The detection run identifies the orphan, its connected application, the last authentication timestamp, and the absence of a linked active identity. Detected orphans are surfaced for resolution through deletion or reassignment. The detection run and resolution record constitute the proactive access hygiene evidence that frameworks including RBI, SEBI, and IRDAI specifically look for.

The SCIM Connector Failure Problem

SCIM-based provisioning and deprovisioning is the technical standard for automating access changes across connected applications. When SCIM connectors fail silently, provisioning and deprovisioning actions recorded in the IAM platform do not propagate to connected applications. The IAM platform record shows the action completed. The connected application retains the previous access state.

For deprovisioning specifically, a silent SCIM failure means a departed employee’s account persists in a connected application after the IAM platform records show it was removed. The deprovisioning evidence is misleading: it shows completion when the access was not actually revoked.

Akku’s connector health monitoring detects SCIM sync failures before they create access gaps. Failed sync events are logged and flagged for administrator attention. The deprovisioning record in Akku includes the SCIM sync status: completed with confirmation, or failed with the failure event logged. An auditor examining deprovisioning records can see which removals completed end-to-end and which require investigation.

Diagnostic Questions

For a sample of ten users provisioned in the last 12 months, can you produce the provisioning record for each showing the approval timestamp preceding the access grant, the approver identity, and the justification, without reconstructing from email history?

For a sample of ten users who departed in the last 12 months, can you produce the deprovisioning record for each showing every system from which access was removed, the removal timestamp for each system, and SCIM sync confirmation, with same-day completion for employment terminations?

Does your deprovisioning workflow trigger automatically from HR system events, or does it require a manual IT ticket submission after the HR event is recorded?

Has your organisation run an orphan account detection pass in the last 90 days, and is there a detection record and resolution record for every orphan identified?

Does your SCIM connector health monitoring detect failed sync events and flag them for administrator attention before they create persistent access gaps or misleading deprovisioning evidence?

CTAs

See how Akku’s User Lifecycle Manager addresses provisioning and deprovisioning requirements across DPDPA, RBI, SEBI CSCRF, IRDAI, ISO 27001, and SOC 2.

Book a conversation with the Akku team to assess your current lifecycle management controls against the provisioning and deprovisioning evidence standards your frameworks require.

FAQs

What is the difference between provisioning and birthright access, and how do they interact with compliance requirements?

Birthright access is the set of applications and systems a user receives automatically on joining based on their role, without requiring a separate access request. Provisioning is the technical process of granting that access. For compliance purposes, birthright access must be defined at the role level in a documented role matrix, provisioned automatically through an automated workflow rather than manually by an administrator, and recorded with the provisioning execution timestamp and the role trigger that initiated it. Additional access beyond birthright requires a separate request and approval process. Both birthright and requested access must produce compliant provisioning evidence, the difference is in the authorisation mechanism: role-based for birthright, request-based for additional access.

Why does same-day deprovisioning matter for compliance frameworks, and what counts as same-day?

Same-day deprovisioning matters because access that persists after employment ends creates both a security risk and a compliance gap simultaneously. A departed employee with valid credentials can access systems they are no longer authorised to use. Every framework that requires access to cease when the need ends treats delayed deprovisioning as a control failure. Same-day means within the same calendar day that the employment termination is recorded in the authoritative HR system. An employee whose termination is recorded at noon and whose access is removed at 11:59 PM the same day satisfies the same-day standard. Access removal completed the following business day does not.

How does SCIM-based deprovisioning differ from manual account deletion, and why does the difference matter for evidence?

SCIM-based deprovisioning sends a structured deprovision request to each connected application’s SCIM endpoint and receives a confirmation response. The confirmation is logged alongside the IAM platform deprovisioning record, creating an end-to-end evidence chain. Manual account deletion requires an administrator to log into each application separately, delete the account, and record the deletion. Manual records are subject to human error, inconsistent format, and documentation gaps. SCIM-based deprovisioning is deterministic and complete: if the SCIM request succeeds, the account is removed and the confirmation is logged. If it fails, the failure is also logged. Manual deprovisioning can succeed silently, fail silently, or be documented inconsistently. The evidence quality of SCIM-based deprovisioning is materially higher.

What should organisations do when they discover orphan accounts during a compliance review?

When orphan accounts are discovered, the organisation must take three actions. First, assess the risk: determine when each orphan account was last used, what systems it has access to, and whether there is any evidence of inappropriate use since the account became orphaned. Second, remediate: disable the account immediately to prevent further access, then delete it after confirming no outstanding dependencies. Third, document: record the detection, the risk assessment, the remediation action, and the resolution timestamp in the audit trail. For compliance evidence purposes, the detection and resolution record demonstrates proactive access hygiene. For the root cause, investigate why the account became orphaned and address the deprovisioning process gap that allowed it.

How do provisioning and deprovisioning requirements interact with third-party and contractor access governance?

Third-party and contractor access is subject to the same provisioning and deprovisioning requirements as permanent employee access under every framework reviewed. IRDAI Item 6 specifically addresses contractor account lifecycle. SEBI CSCRF GV.SC.S4 requires supply chain access governance equivalent to internal user governance. For contractors, provisioning must be time-bound: the access grant must include an expiry date aligned with the engagement end. When the engagement ends, deprovisioning must be automatic and complete, covering all systems the contractor had access to. Contractor accounts that persist after engagement end are orphan accounts and are treated as such in compliance examinations.

Can the same provisioning and deprovisioning evidence satisfy multiple compliance frameworks simultaneously?

Yes. The provisioning record structure, requester, approver, timestamp, justification, access scope, and SCIM confirmation, satisfies RBI Clause 8(c), SEBI CSCRF PR.AA.S1, IRDAI Items 6 and 26, ISO 27001 A.5.16, SOC 2 CC6.2, and DPDPA Clause 8(4) simultaneously. The deprovisioning record structure, trigger event, systems removed, removal timestamps, SCIM confirmation, and completeness across all connected applications, satisfies RBI Clause 19(a), SEBI CSCRF PR.AA.S1, IRDAI Items 10 and 26, ISO 27001 A.5.16, SOC 2 CC6.3, and DPDPA Clause 8(7) simultaneously. A single automated lifecycle management implementation producing these records continuously satisfies the provisioning and deprovisioning requirements of all applicable frameworks from one evidence source.

Introduction

DPDPA Clause 8(7)(a) requires Data Fiduciaries to erase personal data and cease processing as soon as it is reasonable to assume that the specified purpose for which personal data was collected is no longer being served. For workforce data, employment termination is the clearest trigger for this determination. When an employee leaves, the employment relationship that justified processing their personal data ends. The processing purpose, executing the employment contract, is no longer being served.

At the access layer, this translates to a direct technical obligation: when an employee whose role required access to personal data systems leaves the organisation, their access to those systems must cease. Promptly, completely, and with a documented audit trail. The Clause 8(7) obligation is not satisfied by removing the employee from Active Directory while leaving their accounts active in three SaaS applications and their SSH keys on two production servers.

The offboarding gap is pervasive. Exit processes at most organisations are built around payroll, benefits, and asset return. IT offboarding, covering access revocation across all connected systems, is either a secondary step that depends on a separate IT ticket or a manual checklist that individual system administrators work through. Both approaches produce incomplete, delayed, and undocumented deprovisioning. Neither satisfies Clause 8(7)’s technical obligation.

This blog covers what Clause 8(7) specifically requires for employee offboarding, the technical infrastructure required to satisfy it, the evidence the Data Fiduciary must produce, and how automated deprovisioning workflows address both the access cessation and documentation requirements.

What Clause 8(7) Requires for Employee Offboarding

Clause 8(7) has two sub-clauses with different triggers but overlapping technical requirements.

Clause 8(7)(a): Purpose completion trigger

Clause 8(7)(a) requires erasure and cessation as soon as it is reasonable to assume the specified purpose is no longer being served. For workforce personal data, the specified purpose is executing the employment relationship: payroll processing, benefits administration, performance management, and access provisioning for the employee’s role.

When employment ends, the employment relationship purpose is no longer being served. The Clause 8(7)(a) trigger for workforce offboarding is employment termination as recorded in the HR system.

The reasonably assume standard implies a prompt response to the trigger event. An organisation that processes personal data of a departed employee for months after their termination because IT offboarding was delayed cannot reasonably claim that the purpose is still being served. The trigger has occurred. The obligation to cease processing begins from the trigger.

Clause 8(7)(b): Consent withdrawal trigger

Clause 8(7)(b) requires erasure and cessation when the Data Principal withdraws consent and no other lawful basis applies. For workforce data processed on the basis of consent, withdrawal triggers the same access cessation obligation as employment termination under Clause 8(7)(a).

For customer-facing systems, consent withdrawal by a customer is the Clause 8(7)(b) trigger. The access cessation at the customer data layer, removing the customer’s data from active processing systems, is the technical equivalent of the employee access revocation at the workforce layer.

The distinction between access cessation and data erasure

Clause 8(7) requires both cessation of processing and erasure of personal data. These are related but technically distinct obligations.

Cessation of processing means the departed employee’s access to personal data systems is revoked. They can no longer log in to the HR system, the CRM, the document management platform, or any other system they were entitled to use during employment.

Data erasure means the employee’s personal data that was collected and processed during employment is deleted after the retention period required for legal compliance has passed. Payroll records may need to be retained for tax compliance. Employment records may need to be retained for a defined period. The erasure obligation applies after these retention periods expire.

The IT team’s primary Clause 8(7) obligation at the point of offboarding is access cessation. Data erasure following the retention period is a data governance function that requires a separate retention and deletion schedule.

The Technical Infrastructure Required for Compliant Offboarding

Compliant Clause 8(7) offboarding requires an automated deprovisioning workflow that covers all connected systems, completes within the same business day of the employment termination event, and produces a complete audit trail.

HR system integration as the deprovisioning trigger

The deprovisioning workflow must be triggered automatically by the HR system event recording the employment termination. Manual triggers, where an IT ticket is raised after HR records the departure, create a gap between the trigger event and the access cessation. During this gap, the departed employee may retain access to personal data systems.

HR system integration through SCIM or API enables the IAM platform to receive termination events in real time. When the HR system records a termination, Akku’s User Lifecycle Manager receives the event and initiates deprovisioning across all connected applications simultaneously.

The trigger mechanism eliminates the dependency on human memory or process adherence. Deprovisioning occurs because the system received the trigger, not because an IT administrator remembered to raise a ticket.

Comprehensive application coverage

Deprovisioning must cover every application the departed employee had access to. Not just Active Directory. Not just the primary business applications. Every connected application, including legacy systems, custom-built tools, SaaS applications, and infrastructure access.

The coverage requirement is what makes manual deprovisioning at scale problematic. A departing employee at a mid-market organisation may have access to 15 to 30 applications. A manual deprovisioning process requires the IT administrator to access each application separately, locate the user account, and disable or delete it. The process is time-consuming, error-prone, and inconsistently applied.

SCIM-based automated deprovisioning propagates the termination event to every connected application simultaneously. Each application receives a structured deprovision request and returns a confirmation. The deprovisioning is comprehensive and the confirmation is logged.

Privileged access revocation

For employees with privileged access to infrastructure, deprovisioning must extend beyond application accounts to SSH keys, database credentials, API keys, and any other credentials the employee held.

Per-session ephemeral credentials through AkkuArka address this structurally: because privileged users hold no standing credentials to target systems, there are no standing credentials to revoke. Access to infrastructure is governed through the PAM platform, and removing the employee’s PAM platform access simultaneously removes their ability to request privileged sessions to any target system.

For organisations that issued standing SSH keys or database credentials before implementing PAM, the offboarding process must include explicit revocation of these credentials alongside the application account deprovisioning.

Same-day completion requirement

DPDPA’s promptly implied standard means access cessation must complete within the same business day as the employment termination event. A deprovisioning process that takes three days to work through the checklist does not satisfy the prompt cessation requirement.

Automated deprovisioning triggered by HR system events completes in minutes, not days. The trigger fires when HR records the termination. Deprovisioning requests are sent to connected applications immediately. SCIM confirmations are received within minutes for most connected applications. The complete deprovisioning process, from HR trigger to confirmed access removal across all connected systems, can complete within a business hour rather than a business day.

The Audit Evidence Clause 8(7) Requires

Clause 8(4)’s demonstrability requirement means the Data Fiduciary must be able to prove that access ceased when the processing purpose was no longer served. For offboarding, this requires a structured deprovisioning audit trail.

What the deprovisioning audit trail must contain

The trigger event: the HR system termination record with the termination timestamp. The deprovisioning execution: which applications were deprovisioned, the deprovisioning action taken, and the execution timestamp for each. SCIM sync confirmation: the confirmation response from each connected application, with timestamp. The complete record must cover every system the employee had access to, not only the systems where deprovisioning was confirmed successful.

Handling SCIM connector failures

When a SCIM connector fails, the deprovisioning request is sent but the confirmation is not received. The IAM platform records show the deprovisioning was initiated but not confirmed. This is an incomplete deprovisioning record.

Akku’s connector health monitoring detects SCIM failures and flags them for immediate administrator attention. The failed sync is logged alongside the deprovisioning record, creating a complete picture of what occurred: deprovisioning was initiated, the sync failed, the failure was detected and flagged. The administrator can then manually complete the deprovisioning for the affected application and record the manual action.

The critical point is that connector failures must be detected, not allowed to persist silently. An undetected connector failure means a departed employee’s account persists in a connected application for an indefinite period, with no indication in the IAM platform that the deprovisioning was incomplete.

Retention of deprovisioning records

Deprovisioning records must be retained for a period sufficient for regulatory examination. The trigger event record, the deprovisioning execution record, and the confirmation records together constitute the Clause 8(7) compliance evidence. These records should be retained for a minimum of three years, consistent with the general retention practice for compliance evidence.

What Happens to Personal Data After Access Is Revoked

Access revocation under Clause 8(7) at the offboarding point is the immediate compliance obligation. The longer-term data retention and erasure obligations require a separate data governance programme.

Employee personal data retention

Payroll records, employment contracts, performance records, and other employment-related personal data may need to be retained after termination for tax compliance, employment law requirements, or legal dispute resolution. The applicable retention periods depend on the legal requirements in the jurisdictions where the employee worked.

During the retention period, the personal data is retained but processing should be limited to what the retention requirement necessitates. Active use of the data for operational purposes beyond the retention obligation is inconsistent with Clause 8(7)(a)’s purpose completion requirement.

Scheduled deletion after retention period

After the applicable retention periods expire, the employee’s personal data should be scheduled for deletion. The deletion schedule should be defined in the data retention policy, technically enforced through the data management infrastructure, and produce an audit record of the deletion event.

The scheduled deletion at retention period expiry is the completion of the Clause 8(7)(a) obligation that began with access revocation at offboarding. The full compliance evidence chain runs from employment termination through access revocation to scheduled deletion.

Diagnostic Questions

When an employee is terminated today, does their access to all personal data systems cease within the same business day through an automated deprovisioning workflow triggered by the HR system, or does cessation depend on a manual IT ticket?

Does your deprovisioning coverage extend to every application the employee had access to, including legacy systems, custom tools, and infrastructure access, or only to the primary directory and main SaaS applications?

For employees with privileged infrastructure access, does offboarding revoke their SSH keys, database credentials, and any other standing credentials to production systems, or only their application accounts?

Is there a complete deprovisioning audit trail for every employee who left in the last 12 months, covering every system from which access was removed, with timestamps and SCIM sync confirmations, and are connector failures flagged for remediation?

Does your data retention policy define how long each category of employee personal data is retained after termination, and is scheduled deletion after retention period expiry technically enforced with an audit record of each deletion?

CTAs

See how Akku’s User Lifecycle Manager addresses DPDPA Clause 8(7) offboarding requirements through HR-triggered automated deprovisioning, SCIM coverage, and complete audit trail generation.

Book a conversation with the Akku team to assess your current offboarding process against DPDPA Clause 8(7)’s access cessation and documentation obligations.

FAQs

What does DPDPA Clause 8(7)(a) require specifically for employee offboarding, and how quickly must access be revoked?

Clause 8(7)(a) requires erasure and cessation as soon as it is reasonable to assume the specified purpose is no longer being served. For employee offboarding, employment termination is the trigger event. The reasonably assume standard implies a prompt response: access to personal data systems should cease on the day of termination, not days or weeks later. While the Act does not specify an exact timeframe, same-day cessation is the standard that satisfies the prompt obligation. An organisation that typically completes deprovisioning three to five days after termination cannot claim the delay is reasonable when automated deprovisioning infrastructure is available that completes the process in minutes.

Does DPDPA Clause 8(7) apply to all employee data or only to personal data systems?

Clause 8(7)(a) applies to personal data the organisation processes for the employment purpose. This covers all personal data collected and processed as part of the employment relationship: HR records, payroll data, performance records, and access to any system where the employee’s personal data or the personal data of others was processed in the course of their role. At the access layer, the obligation applies to every system the employee had access to, because their role in those systems was connected to the employment purpose. At the data layer, the obligation covers the employee’s own personal data held by the organisation, subject to applicable legal retention requirements.

How does the DPDPA offboarding obligation interact with legal retention requirements for employee records?

Legal retention requirements create an exception to the erasure obligation under Clause 8(7). Where personal data must be retained for tax compliance, employment law requirements, or potential legal disputes, the retention is lawful under the legal obligation basis rather than the employment contract basis. During the retention period, processing must be limited to what the retention requirement necessitates. The access cessation obligation at offboarding applies immediately: the employee’s access to operational systems is revoked. The data retention obligation allows the data itself to be kept for the required period, after which scheduled deletion completes the Clause 8(7)(a) obligation.

What is the risk of incomplete offboarding from a DPDPA compliance perspective?

Incomplete offboarding creates two simultaneous risks. The security risk: a departed employee with persistent access to personal data systems can access, copy, or exfiltrate data they are no longer authorised to process. For high-risk departures such as employees leaving for competitors or employees dismissed for cause, this risk is acute. The compliance risk: persistent access after employment termination is a direct Clause 8(7)(a) violation. If a Data Principal whose data was processed by the departed employee files a complaint with the Data Protection Board alleging unauthorised access to their data, the organisation cannot demonstrate that access ceased promptly. The deprovisioning gap becomes both a security incident and a regulatory finding simultaneously.

Can the same automated deprovisioning workflow satisfy both DPDPA Clause 8(7) and ISO 27001 A.5.16 simultaneously?

Yes. DPDPA Clause 8(7)(a) requires cessation of processing when the purpose is no longer served, which for workforce offboarding means access revocation on employment termination. ISO 27001:2022 A.5.16 requires that identity deletion follow a managed process with documented evidence. Both requirements are satisfied by an automated deprovisioning workflow triggered by HR system events, covering all connected applications, completing within the same business day, and producing a structured audit trail with SCIM sync confirmations. The same workflow, the same trigger, and the same evidence satisfy both frameworks simultaneously.

What should organisations do when they discover that a departed employee still has active accounts in connected applications due to SCIM connector failures?

When a SCIM connector failure is discovered that left a departed employee’s account active in a connected application, the organisation must take three immediate actions. First, manually disable or delete the account in the affected application immediately. Second, investigate whether the account was accessed after the termination date: the application’s access logs should be reviewed for any activity between the termination date and the discovery date. Third, assess whether the activity, if any, constitutes a personal data breach under DPDPA Clause 8(6) requiring notification to the Data Protection Board and affected Data Principals. The discovery, remediation, and breach assessment must all be documented in the audit trail as evidence that the organisation responded promptly when the failure was identified.

Introduction

DPDPA Clause 8(4) requires Data Fiduciaries to implement appropriate technical and organisational measures to ensure effective observance of the provisions of the Act. This is a technical engineering obligation, not a policy drafting exercise. The appropriate technical measures that Clause 8(4) requires include role-based access controls for personal data systems, segregation of duties enforcement preventing conflicting access to personal data, periodic access reviews ensuring access remains appropriate, and automated deprovisioning when processing purposes are fulfilled.

Most legal and compliance teams reading Clause 8(4) understand it as a governance obligation: document what measures are in place, appoint a Data Protection Officer, maintain records of processing activities. These are real obligations. But Clause 8(4)’s appropriate technical measures requirement goes beyond governance documentation into the IT infrastructure layer. A policy stating that access to personal data is controlled does not constitute a technical measure. An RBAC implementation that restricts access to personal data systems to roles with an authorised processing purpose does.

The IT team’s responsibility under Clause 8(4) is to build and maintain the access control infrastructure that makes the data protection obligations in Clauses 5 through 8 technically enforceable. Consent management, Data Principal rights fulfilment, and breach prevention all depend on having an access control foundation that knows who has access to personal data systems, on what basis, and with what scope.

This blog covers what Clause 8(4) specifically requires from the IT access control layer, how each requirement maps to technical controls, and what evidence the Data Fiduciary must be able to produce to demonstrate compliance.

What Clause 8(4) Requires at the Technical Layer

Clause 8(4) uses the phrase appropriate technical and organisational measures to ensure effective observance. Effective observance means the measures must actually work, not merely exist. A technical measure that is documented but not deployed does not constitute effective observance. A deployed control that produces no evidence of operation does not enable demonstration of effective observance.

Access limitation to authorised purposes

The first technical requirement implied by Clause 8(4) is that processing be limited to the purposes for which personal data was collected. At the access control layer, this means each user’s access to personal data systems must be scoped to the processing activities their role legitimately requires.

A customer service representative whose role is to handle billing queries should have access to billing records but not to medical history, policy claim details, or any other personal data categories their role does not require. This is the data minimisation principle applied at the access control layer. RBAC is the technical mechanism: role definitions determine access scope, and access scope is limited to what the role’s authorised processing purposes require.

The distinction between accessing personal data for an authorised purpose and accessing it for an unauthorised purpose is not something a user can reliably police themselves. A system where every customer service representative can access all customer records including categories unrelated to their function does not implement Clause 8(4)’s processing limitation, regardless of how clearly the usage policy is written.

Segregation of duties for personal data processing

Clause 8(4)’s effective observance requirement extends to preventing conflicting access combinations that could enable unauthorised processing without detection. A user who can both access personal data and modify the audit log that records access events can access data without leaving a traceable record. A user who can both provision access to personal data systems and certify access reviews can grant themselves access and certify it as appropriate.

SoD enforcement at the IAM layer prevents these conflict combinations. The rules engine defines which role combinations are incompatible from a personal data governance perspective and detects violations when they occur.

Periodic access reviews for personal data systems

Clause 8(4)’s ongoing observance requirement implies that access to personal data systems must be reviewed periodically to ensure it remains appropriate. Access that was appropriate when granted may become inappropriate as roles change, processing purposes evolve, or the business relationship with the Data Principal changes.

Periodic access reviews that produce documented certification or revocation decisions for every entitlement to personal data systems are the technical mechanism for maintaining ongoing observance of the access limitation requirement.

Automated deprovisioning on purpose fulfillment

Clause 8(7)(a) requires erasure and cessation of processing when the purpose is no longer served. At the access layer, purpose fulfillment means the user’s role no longer requires access to the personal data system. Employment termination is the clearest trigger: a departed employee has no current processing purpose for any personal data system access. Role changes may also trigger purpose fulfillment for specific systems.

Automated deprovisioning triggered by HR events ensures that access ceases when the purpose is fulfilled without depending on manual IT action. The deprovisioning audit trail demonstrates that cessation occurred promptly and completely.

Access Control Evidence Clause 8(4) Requires

Clause 8(4)’s demonstrability requirement under the broader accountability principle in Clause 8(4) and Article 5(2) of GDPR’s equivalent means the Data Fiduciary must be able to produce evidence that technical measures are operating. The evidence requirements cover four categories.

Access authorisation evidence

For every user with access to a personal data system, the Data Fiduciary must be able to produce the authorisation record showing who approved the access, on what basis, for what processing purpose, and when. This record demonstrates that access to personal data was granted through a formal process tied to an authorised processing purpose.

Access granted informally, where an administrator copied an existing user’s access configuration or responded to a verbal request, does not produce this record. A formal approval workflow that generates structured records at the time of every provisioning event is required.

Access scope evidence

The Data Fiduciary must be able to demonstrate that access scope is appropriate to processing purposes. This requires a current view of every user’s access entitlements across all connected personal data systems, queryable at any time.

The consolidated who-has-access-to-what view in Akku’s IGA module provides this capability. Every user’s current entitlements across all connected applications are visible in a single interface, with the role and approval basis for each entitlement accessible from the same view.

Access review evidence

The Data Fiduciary must be able to produce access review records showing that access to personal data systems was periodically examined and that entitlements no longer appropriate were revoked. The review records must cover a period sufficient to demonstrate ongoing observance, not only the most recent cycle.

Deprovisioning evidence

The Data Fiduciary must be able to demonstrate that access ceased when the processing purpose was no longer served. Deprovisioning records showing same-day access removal for employment terminations, with SCIM sync confirmation from every connected personal data system, constitute this evidence.

Mapping Clause 8(4) to Specific IAM Controls

Each component of Clause 8(4)’s technical requirement maps to a specific IAM control.

Processing limitation maps to RBAC and ABAC

Role definitions in Akku’s IAM platform scope each user’s access to the personal data systems their role’s processing purposes require. Attribute-based controls further refine access within systems, limiting which data categories a user can access based on their current active processing context.

The role matrix that defines which roles have access to which personal data systems for which processing purposes is the governance documentation that underpins the RBAC implementation. Both the documentation and the technical configuration must exist: documentation without implementation is policy, not technical measure.

Conflict prevention maps to SoD enforcement

The IGA SoD rules engine defines incompatible role combinations for personal data processing. Access provisioning and access certification must be separated. Personal data access and audit log administration must be separated. Data export capabilities and data deletion capabilities must be separated where the combination creates a fraud or concealment risk.

The rules engine detects violations continuously and triggers remediation workflows. The violation detection log and remediation records constitute the SoD enforcement evidence for Clause 8(4).

Ongoing observance maps to access review campaigns

Access review campaigns for personal data systems run on a defined cadence. Every user’s entitlements to personal data systems are presented to appropriate reviewers for certification or revocation. Every decision is timestamped and logged. Revocations trigger automated deprovisioning.

The campaign records from every review cycle throughout the compliance period constitute the ongoing observance evidence Clause 8(4) requires.

Purpose fulfillment maps to automated deprovisioning

Automated deprovisioning triggered by HR system events, consent withdrawal, and access review revocations ensures that access ceases when the processing purpose is no longer served. The deprovisioning audit trail, covering every system from which access was removed with timestamps and sync confirmations, constitutes the cessation evidence.

Akku’s DPDPA mapping shows Identity and Access Governance addresses Clause 8(4) directly. Access Manager, Adaptive MFA, Privileged Access Manager, and the broader access control stack collectively address Clause 8(5)’s security safeguard requirement that complements 8(4)’s access limitation requirement.

The Connection Between Clause 8(4) and Breach Notification

Clause 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals in the event of a personal data breach. The technical infrastructure required to fulfil this notification obligation is the same infrastructure Clause 8(4) requires for access controls.

Identifying affected Data Principals requires knowing which users had access to the compromised personal data system and what data they could access. This requires the access control records Clause 8(4) mandates: role-based access scoping, provisioning records showing access basis, and session activity logs for privileged access.

Determining the scope of the breach requires knowing what was accessed. For standard user access, application-level logs provide this information. For privileged users with direct database access, SMARTAudit Trails capturing SQL queries are the evidence source. Without this session-level evidence, breach scoping is guesswork, not determination.

An organisation with weak Clause 8(4) technical measures will struggle with Clause 8(6) breach notification because the evidence infrastructure required for both obligations is the same.

Diagnostic Questions

For every user with access to a personal data system, can you identify the processing purpose that justifies the access and the approval record that authorised it, without manual reconstruction?

Does your RBAC implementation scope each user’s access to personal data systems to only the categories their role’s processing purposes require, or does role-based access provide broader access than the processing purpose strictly requires?

Has your organisation defined and enforced SoD rules preventing the same user from both provisioning access to personal data systems and certifying access reviews for those systems?

If the Data Protection Board requested evidence that access to a specific personal data system was limited to authorised personnel with documented processing purposes over the last 12 months, could you produce that evidence from a structured, queryable source within 48 hours?

When an employee with access to personal data systems departs, does access cease automatically across every connected personal data system within the same business day, with a timestamped completion record for each?

CTAs

See how Akku addresses DPDPA Clause 8(4) access control requirements through RBAC, SoD enforcement, access reviews, and automated deprovisioning for personal data systems.

Book a conversation with the Akku team to assess your current access control posture against DPDPA Clause 8(4)’s technical obligations.

FAQs

What is the difference between Clause 8(4)’s technical measures requirement and Clause 8(5)’s security safeguards requirement?

Clause 8(4) requires appropriate technical and organisational measures to ensure effective observance of the Act’s provisions, including ensuring processing is limited to authorised purposes. It is the access governance and control layer. Clause 8(5) requires reasonable security safeguards to prevent personal data breaches. It is the security layer. Clause 8(4) governs who can access personal data and for what purpose. Clause 8(5) governs how that access is protected against compromise. Both are required simultaneously. RBAC and access reviews satisfy Clause 8(4). Adaptive MFA, encryption, and session recording satisfy Clause 8(5). A gap in either creates a separate compliance deficiency.

Does Clause 8(4) require a formal data classification scheme before access controls can be implemented?

A formal data classification scheme is a governance best practice that makes access control implementation more systematic, but Clause 8(4) does not explicitly require one. What Clause 8(4) requires is that access to personal data systems be limited to authorised processing purposes. This can be implemented through role-based access controls scoped to processing purpose categories without a formal classification scheme, provided the role definitions clearly reflect which personal data categories each role requires access to. A classification scheme that labels data by sensitivity and maps roles to classification levels is a more scalable approach for large organisations with complex data landscapes.

How does Clause 8(4) apply to third-party service providers who access personal data systems?

Third-party service providers who access personal data systems are either Data Processors under Clause 8(8), in which case the Data Fiduciary must ensure they implement equivalent technical measures, or they are separate Data Fiduciaries accessing data under their own lawful basis. For Data Processors with access to the Data Fiduciary’s personal data systems, Clause 8(4)’s technical measures requirement extends to their access: provisioning must be through a formal process tied to their processing scope, deprovisioning must occur promptly when the processing engagement ends, and session-level logging for privileged access is required. The same IAM controls that govern internal user access must be applied to Data Processor access.

What constitutes a processing purpose for RBAC design under Clause 8(4)?

A processing purpose under Clause 8(4) is the specific, defined reason for which personal data was collected as specified in the notice under Clause 5. For RBAC design, processing purposes translate into operational functions: handling customer service requests, processing insurance claims, conducting KYC verification, or producing financial statements. Each operational function requires access to specific personal data categories. The RBAC role definition maps the operational function to the personal data systems and data categories that function requires, scoping access to what the purpose actually needs rather than to the broadest plausible interpretation of the function. Over-scoping role access to personal data systems is a Clause 8(4) issue, not merely a best practice gap.

How should organisations handle the transition period before DPDPA Rules are finalised?

The DPDPA’s core obligations, including Clause 8(4)’s technical measures requirement, are in force even though the Rules specifying certain implementation details are not yet finalised. Organisations should implement the technical measures that the Act’s current text requires: access controls limiting processing to authorised purposes, security safeguards preventing breaches, consent management systems, and Data Principal rights fulfilment infrastructure. When the Rules are finalised, the implementation may require adjustment for specific details such as breach notification timelines and consent form requirements, but the foundational technical infrastructure should be operational before the Rules specify the precise format. Building the infrastructure after the Rules are finalised creates a compliance gap during the interim period.

Can Clause 8(4)’s technical measures requirement be satisfied by cloud-hosted IAM infrastructure, or does DPDPA require on-premises deployment?

DPDPA does not specify on-premises deployment as a requirement for technical measures. Cloud-hosted IAM infrastructure that implements the required access controls, audit trails, and lifecycle management capabilities satisfies Clause 8(4)’s technical measures requirement. The data localisation provisions in DPDPA, to the extent they are specified in the Rules, may affect where personal data is stored and processed, but the IAM infrastructure that governs access to that data is not subject to the same localisation requirements as the personal data itself. Akku supports both cloud-native SaaS deployment and on-premises deployment for organisations with specific sovereignty requirements.

Introduction

RBI 2023 Master Direction Clause 15 requires that regulated entities maintain audit trails suitable for forensic investigation and dispute resolution. This is a higher standard than authentication logging. Authentication logs record that a session occurred. Forensic-grade audit trails record what happened during it, at sufficient detail to reconstruct the sequence of events, identify the actor responsible, and determine the scope of impact.

The distinction matters in two scenarios that RBI-regulated entities face regularly. Post-incident investigation: when a data breach, fraudulent transaction, or unauthorised configuration change occurs, the investigation team needs to know which user accessed which system, which commands were run, which data was queried, and what changed. Authentication timestamps tell the team a session occurred. Keystroke logs and query capture tell them what happened. Dispute resolution: when a customer or counterparty disputes a transaction or alleges unauthorised access, the regulated entity needs to produce evidence of what occurred. An authentication log is not evidence of what happened in a session. A session recording is.

Most RBI-regulated entities have authentication logging in place. The gap is almost always at the session activity layer: what users did after authenticating, particularly privileged users with access to core banking systems, payment infrastructure, and production databases. This blog covers what Clause 15 specifically requires, why the forensic standard cannot be met by authentication logs alone, and what controls produce the evidence standard Clause 15 demands.

What Clause 15 Requires

Clause 15 is structured across three sub-clauses covering different dimensions of the audit trail requirement.

Clause 15(a): System access audit trails

Clause 15(a) requires audit trails that record all access to information systems, including successful and failed authentication attempts, with sufficient detail to enable forensic investigation. The forensic investigation standard is the operative requirement. A forensic investigator examining a security incident needs more than a record that authentication occurred. They need a record of what the authenticated user did within the system during the session.

For privileged users with administrative access to servers, databases, and network infrastructure, forensic investigation requires session-level recording. A database administrator whose session is under investigation needs a record of every SQL query executed, not only a timestamp showing when they connected. A system administrator needs a record of every command run in the SSH session, not only confirmation that the SSH connection was established.

Clause 15(b): Data modification and administrative action trails

Clause 15(b) requires audit trails capturing data modifications, system configuration changes, and administrative actions, with actor identity, timestamp, and before-and-after state where applicable. This extends beyond session logging to cover the specific change events that represent the highest risk in a regulated entity’s environment.

Configuration changes to core banking systems, modifications to access control policies, changes to user privileges, and updates to payment processing rules are all administrative actions that Clause 15(b) requires to be logged with the actor’s identity and a record of what changed. This evidence is what an RBI IS auditor needs to assess whether changes were authorised and whether the change management process was followed.

Clause 15(c): Log protection and availability

Clause 15(c) requires that audit trails be protected against modification, deletion, or tampering. Logs must be retained for a defined period sufficient for forensic investigation and regulatory examination, and must be available on demand for regulatory review.

The tamper protection requirement is what distinguishes a compliance-grade audit trail from a standard log file. A log file stored in a file system where an administrator with sufficient privileges can modify or delete records cannot serve as forensic evidence. An append-only audit trail where existing records cannot be modified is the technical standard Clause 15(c) requires.

Why Authentication Logs Do Not Meet the Clause 15 Standard

Authentication logs and session activity logs address different layers of the same event. Understanding the gap precisely is necessary for assessing whether current logging infrastructure meets Clause 15’s forensic standard.

What authentication logs capture

An authentication log captures the login event: who attempted to connect, when, from which IP address and device, using which authentication method, and whether the attempt succeeded or failed. For a successful session, the authentication log records the session open event. It records nothing further until the next authentication event.

For a privileged user who authenticates to a production database, runs a series of queries, exports a dataset, modifies a stored procedure, and disconnects, the authentication log contains: connection timestamp, source IP, MFA method used, and disconnection timestamp. The queries run, the data exported, and the stored procedure modified are not in the authentication log.

What Clause 15’s forensic standard requires

Clause 15(a)’s forensic investigation standard requires that the audit trail be sufficient to reconstruct what happened during a session. For the database session described above, reconstruction requires the complete list of SQL queries executed, the tables and columns accessed, the data returned, and the modification made to the stored procedure. Without this, a forensic investigator examining a suspected data exfiltration incident cannot determine from the logs whether data was exported or what was accessed.

For a dispute resolution scenario, Clause 15’s evidence standard requires that the regulated entity can produce records showing what a specific user did in a specific session on a specific date. An authentication log showing the user connected is not evidence of what they did. A session recording showing every query they executed is.

The infrastructure gap

The gap between authentication logging and session activity logging is not configurational. Authentication logs and session activity logs are fundamentally different infrastructure layers. Authentication logs are generated by the identity and authentication system. Session activity logs for privileged access require a session proxy layer, such as AkkuReka, that sits between the authenticated user and the target system and records everything passing through it.

An organisation that has authentication logging but no session proxy infrastructure cannot produce session activity logs for privileged access regardless of how the authentication system is configured. The session activity logging capability requires deployment of a PAM-layer session proxy.

What Forensic-Grade Audit Trails Require Technically

Meeting Clause 15’s forensic standard across the full scope of a regulated entity’s critical systems requires session activity logging for every privileged access path to those systems.

SSH session logging

SSH sessions to Linux servers, Unix systems, and network devices require keystroke-level logging per command. Every command the administrator types, the arguments provided, the directory context, and the output produced must be captured with a timestamp. Full screen recording provides visual context. Keystroke logging provides structured, searchable data.

The combination of screen recording and keystroke logging is what makes SSH session evidence forensically useful. Screen recordings can be reviewed visually. Keystroke logs can be searched by command string, allowing investigators to find all sessions where a specific command was run without reviewing every recording manually.

Database session logging

Database sessions to MySQL, PostgreSQL, and other database management systems require SQL query capture. Every query executed during the session must be captured as structured data: query text, timestamp, database and table context. Full screen recording of the database client interface provides supplementary visual evidence.

SQL query capture is what makes database session evidence useful for both forensic investigation and dispute resolution. When a data integrity incident occurs, the investigation team can query the session logs for all SELECT statements against a specific table, all DELETE or UPDATE statements, and all data export operations. Without structured query capture, this investigation requires manual review of screen recordings.

RDP session logging

RDP sessions to Windows servers and workstations require full screen video recording at sufficient resolution and frame rate to reconstruct what was done during the session. RDP sessions involve graphical interfaces where activity cannot be captured as structured text. Screen recording combined with session metadata, open timestamp, active duration, and close timestamp, constitutes the session activity log for RDP.

Kubernetes and web application sessions

Kubernetes sessions require command log capture for kubectl operations. Web application sessions require session event logging covering page navigation, form submissions, and data access events.

How SMARTAudit Trails Address Clause 15

SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka, producing the forensic-grade audit trail Clause 15 requires across SSH, RDP, database, Kubernetes, and web application sessions.

Session coverage

SSH sessions produce full screen recordings and complete keystroke logs per command. MySQL and PostgreSQL sessions produce full screen recordings and structured capture of every SQL query executed. RDP sessions produce full screen video recordings at configurable frame rates. Kubernetes sessions produce session event recordings and command logs. HTTP and HTTPS web application sessions produce session recordings and event logs.

Storage and integrity

All recordings are stored encrypted with AES-256. The audit log is append-only and tamper-evident. Existing records cannot be modified or deleted after creation. This is the log protection standard Clause 15(c) requires. Logs are retained according to configured retention policies, with export capability for regulatory submission.

Forensic search capability

Recordings are indexed for forensic search by timestamp, command string for SSH sessions, and SQL query text for database sessions. This enables investigators to search across all sessions for specific commands or queries without reviewing every recording manually, satisfying the forensic investigation utility that Clause 15(a)’s standard implies.

Access and export

Recordings are accessible for in-browser playback directly from the Akku admin console without requiring file downloads or external media players. Structured audit log exports in JSON and CSV format are available via API and manual export for regulatory submission. Session recordings are exportable for forensic investigation and auditor review.

Akku’s RBI compliance mapping shows Audit Logs addresses Clauses 8(c), 15(a), 15(b), 15(c), 25(c), 27(b), and 30(f) across seven clause mappings, the highest single-module count in the RBI mapping.

Diagnostic Questions

For a privileged user who accessed a production database last month, can you produce every SQL query they executed during the session, searchable by query text, without reviewing a screen recording manually?

For a system administrator who made a configuration change on a Linux server three months ago, can you produce a keystroke log showing every command they ran during the session, including the specific configuration file they modified?

Are your audit logs stored in an append-only format where administrators with privileged access to the logging infrastructure cannot modify or delete existing records?

Can you produce on demand, for any 90-day window an RBI examiner specifies, a complete structured export of all authentication events and privileged session records across all critical systems without manual compilation?

For a disputed transaction or alleged unauthorised access event, can your organisation produce session-level evidence showing what the implicated user did during the relevant session, sufficient to satisfy the dispute resolution standard Clause 15 requires?

CTAs

See how Akku’s SMARTAudit Trails address RBI Clause 15 forensic audit trail requirements across SSH, RDP, database, and Kubernetes sessions.

Book a conversation with the Akku team to assess your current audit trail infrastructure against RBI Clause 15’s forensic evidence standard.

FAQs

What does forensic investigation standard mean in the context of RBI Clause 15, and how does it differ from standard audit logging?

A forensic investigation standard means the audit trail is sufficient to reconstruct a sequence of events, identify the responsible actor, and determine the scope of impact of an incident. Standard audit logging records that events occurred. A forensic-grade audit trail records what happened in sufficient detail to answer investigation questions: which commands were run, which data was accessed, what was modified, and in what sequence. For privileged access to critical systems, this requires session-level recording at the keystroke or query level, not authentication timestamps.

Does RBI Clause 15 apply only to privileged users or to all users?

Clause 15 applies to all access to information systems, not only privileged access. However, the forensic evidence standard is most demanding for privileged access scenarios because privileged users have the ability to make high-impact changes that require detailed reconstruction. For standard end users accessing business applications, application-level audit trails within those applications typically satisfy Clause 15’s requirements. For privileged users accessing servers, databases, and network infrastructure directly, session-level recording through a PAM-layer proxy is required because there is no application-level audit trail for direct system access.

What retention period should regulated entities apply to audit trail records under Clause 15?

RBI’s 2023 Master Direction does not specify a precise retention period in Clause 15 itself. Industry practice at RBI-regulated entities typically maintains authentication event logs for a minimum of two years, system configuration change logs for two years, and privileged session recordings for two years or longer for sessions involving access to critical banking systems. Entities should define retention periods in their IT security policy, ensure the periods are consistently applied, and verify that the retention periods satisfy the framework’s forensic investigation and regulatory examination requirements.

How does Clause 15’s tamper protection requirement apply to cloud-hosted audit logs?

Clause 15(c) requires that audit logs be protected against modification, deletion, or tampering, regardless of where they are stored. For cloud-hosted audit logs, tamper protection requires an append-only storage architecture where new records can be added but existing records cannot be modified or deleted. Access controls must prevent even privileged administrators from modifying log records. The cloud hosting model does not exempt the requirement. Akku’s audit log architecture is append-only regardless of deployment model, satisfying Clause 15(c)’s tamper protection requirement in both cloud-native SaaS and on-premises deployments.

Can the same session recordings that satisfy RBI Clause 15 also satisfy SEBI CSCRF PR.AA.S12 and ISO 27001 A.8.15?

Yes. SMARTAudit Trail recordings satisfy multiple framework requirements simultaneously. RBI Clause 15 requires audit trails suitable for forensic investigation. SEBI CSCRF PR.AA.S12 requires that privileged session activity be logged with sufficient detail to reconstruct actions taken. ISO 27001 A.8.15 requires logging of user activities, not login events. All three requirements are satisfied by keystroke logs for SSH sessions, SQL query capture for database sessions, and screen recordings for RDP sessions, stored in append-only, tamper-evident format and searchable for forensic investigation. The same evidence package serves all three frameworks.

What is the difference between Clause 15(a), 15(b), and 15(c), and do they require separate technical controls?

Clause 15(a) covers system access audit trails, requiring records of authentication events and session activity sufficient for forensic investigation. Clause 15(b) covers data modification and administrative action trails, requiring records of specific change events with actor identity and before-and-after state. Clause 15(c) covers log protection and availability, requiring tamper-evident storage and on-demand access. They address different layers and require complementary controls. Clause 15(a) is satisfied by authentication event logs and SMARTAudit Trails session recordings. Clause 15(b) is satisfied by administrative event logs capturing role changes, policy modifications, and user lifecycle events. Clause 15(c) is satisfied by the append-only audit log architecture applied across all log types. All three are required and satisfying one does not satisfy the others.

Introduction

DPDPA Chapters II and III establish six rights for Data Principals. Each right creates a corresponding technical obligation for the Data Fiduciary. The right to access personal data requires a self-service portal or fulfilment workflow capable of producing a structured summary of personal data and processing activities. The right to correction and erasure requires workflows that propagate changes across connected systems, not only in the primary data store. The right to grievance redress requires a documented complaint and response process with a timestamped record. The right to nomination requires a mechanism for registering and activating nominated representatives.

Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice. An organisation that has published a privacy notice describing its data principal rights commitment but has no technical mechanism for fulfilling a data access request has not implemented the right. The Data Protection Board of India will assess whether rights are technically exercisable, not whether they are described in a policy document.

This blog covers each of the six DPDPA Data Principal rights, what the Act specifically requires for each, and what technical infrastructure the Data Fiduciary must implement to fulfil them. All clause references are drawn from the DPDPA and Akku’s DPDPA compliance mapping documentation.

Right to Access Information Under Clause 11

Clause 11 gives Data Principals the right to obtain information about the personal data being processed about them and the processing activities being carried out.

What the clause requires

Clause 11(1)(a) gives Data Principals the right to obtain a summary of personal data being processed by the Data Fiduciary and the processing activities being undertaken with respect to that data.

Clause 11(1)(b) gives the right to know the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, along with a description of the personal data shared.

Clause 11(1)(c) gives the right to any other information related to personal data and its processing as may be prescribed by the Rules.

What this requires technically

The right to access requires a self-service portal through which a Data Principal can submit an access request and receive a structured response. At scale, manual fulfilment of access requests is not operationally viable. An organisation processing personal data of millions of customers cannot assign staff to manually compile data summaries for each access request received.

The response to an access request must be structured and complete. It must cover every category of personal data held, every processing purpose for which it is used, and every entity with whom it has been shared. This requires a data mapping that connects personal data categories to processing systems, and a mechanism for querying those systems to compile the response.

The disclosure of Data Processor identities under Clause 11(1)(b) requires that the Data Fiduciary maintain a current record of which processors hold which categories of personal data. This is a data governance obligation with a technical component: the processor record must be queryable at the time an access request is received.

Akku’s CIAM Consent Manager addresses Clauses 11(1)(a), 11(1)(b), and 11(1)(c) through Data Principal rights management workflows. The self-service portal enables access request submission and structured response delivery.

Right to Correction and Erasure Under Clause 12

Clause 12 gives Data Principals the right to correction, completion, updating, and erasure of their personal data.

What the clause requires

Clause 12(2)(a) gives the right to correction and updating of personal data that is inaccurate or incomplete. Clause 12(2)(b) gives the right to completion of personal data that is incomplete. Clause 12(2)(c) gives the right to erasure of personal data that is no longer necessary for the purpose for which it was collected.

Clause 12(3) requires that where the Data Fiduciary has shared personal data with another entity, the Data Fiduciary must inform that entity of the correction, completion, or erasure so that the entity can take corresponding action.

What this requires technically

Correction workflows must update personal data across every connected system where it is held. A correction applied only in the CRM but not in the marketing automation platform, the support system, and the billing system is an incomplete correction. The workflow must propagate the change to every downstream system holding the affected personal data.

Erasure workflows face the same multi-system challenge with additional complexity. Erasure must be complete and verifiable. The Data Fiduciary must be able to demonstrate that the personal data has been removed from every system where it was held, not only from the primary database. Where personal data is held in backups, the erasure timeline must account for backup retention cycles.

Clause 12(3)’s notification requirement creates an automated downstream communication obligation. When correction or erasure is completed, every Data Processor or other Data Fiduciary with whom the data was shared must be notified. At scale, this notification must be automated through the data processing infrastructure, not manually coordinated.

Akku’s CIAM Consent Manager addresses Clauses 12(2)(a), 12(2)(b), 12(2)(c), and 12(3) through correction and erasure workflow capabilities. The User Lifecycle Manager addresses Clause 12(3) through automated deprovisioning and data lifecycle workflows that propagate cessation events to connected systems.

Right to Grievance Redress Under Clause 13

Clause 13 gives Data Principals the right to have their grievances addressed by the Data Fiduciary before approaching the Data Protection Board of India.

What the clause requires

Clause 13(1) requires that every Data Fiduciary establish an effective mechanism for redressal of grievances of Data Principals. The mechanism must allow Data Principals to raise complaints about how their personal data is being processed and receive a response within a defined timeframe.

The Data Principal must exhaust the Data Fiduciary’s grievance mechanism before approaching the Data Protection Board. This creates a procedural requirement: the Data Fiduciary must have a functioning grievance process that produces documented responses, so that the Data Protection Board can assess whether the mechanism was effective before accepting a complaint.

What this requires technically

A grievance redress mechanism requires a complaint submission interface accessible to Data Principals through the same channels as the consent management system. Every complaint must be recorded with a unique reference number, submission timestamp, complaint category, and Data Principal identity. The response must be recorded with a resolution timestamp, the action taken, and the outcome communicated to the Data Principal.

The record of complaints received and responses provided is the evidence the Data Protection Board will examine when a Data Principal files a complaint claiming the grievance mechanism was ineffective. Without structured records showing that the complaint was received, investigated, and responded to within the required timeframe, the Data Fiduciary cannot demonstrate that the mechanism operated as required.

Akku’s CIAM Consent Manager addresses Clause 13(1) through grievance submission and response management workflows within the Data Principal rights management infrastructure.

Right to Nominate Under Clause 14

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

What the clause requires

Clause 14(1) gives every Data Principal the right to nominate any other individual who shall, in the event of the death or incapacity of the Data Principal, exercise the rights of the Data Principal in accordance with the provisions of the Act.

This right is unique to DPDPA among the frameworks covered in this series. It reflects the Act’s recognition that digital identity and personal data persist beyond individual incapacity events, and that Data Principals should be able to designate someone to manage their data rights in those circumstances.

What this requires technically

The nomination right requires a nomination registration mechanism within the consent management portal. A Data Principal must be able to register a nominee by providing the nominee’s identity details and their relationship to the Data Principal. The nomination must be stored as a structured record linked to the Data Principal’s identity.

When the Data Fiduciary receives a rights exercise request from a claimed nominee, the verification process must confirm the nominee’s identity, verify their registration as the Data Principal’s nominee, and verify the incapacity or death event that activates the nomination. The nominee’s rights exercise must be logged with the same audit trail as a direct Data Principal rights exercise.

Akku’s CIAM Consent Manager addresses Clause 14(1) through nominee registration and activation workflows within the Data Principal rights management infrastructure.

Right to Withdraw Consent Under Clause 6(3)

While Clause 6(3) sits within the consent provisions rather than the Data Principal rights chapter, the right to withdraw consent is operationally a Data Principal right and requires the same technical fulfilment infrastructure.

What the clause requires

Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent was given through a single action in a mobile application, withdrawal must be achievable through an equivalent single action in the same application. Clause 6(4) requires that the Data Fiduciary cease processing and, on request, erase the personal data when consent is withdrawn.

What this requires technically

Withdrawal must be a self-service action requiring no interaction with a human agent. The withdrawal interface must be accessible through the same channel as the original consent mechanism. Processing cessation must be automated, triggering notifications to every downstream system processing personal data under the withdrawn consent.

Where the Data Principal also requests erasure under Clause 6(4), the erasure workflow must propagate deletion requests across all connected systems and notify Data Processors under Clause 12(3).

Akku’s CIAM Consent Manager addresses Clauses 6(1), 6(3), 6(4), and 6(7) through consent withdrawal workflows with automated downstream processing cessation notifications. The User Lifecycle Manager addresses Clause 8(7)(a) and 8(7)(b) through deprovisioning workflows triggered by consent withdrawal events.

Right to Data Portability Under DPDPA

The DPDPA does not include an explicit data portability right equivalent to GDPR Article 20. However, Clause 11’s access right implicitly supports portability in practice: a Data Principal who receives a structured summary of their personal data under Clause 11(1)(a) can use that summary to transfer their data to another provider.

Organisations subject to both DPDPA and GDPR must implement data portability infrastructure for GDPR Article 20 purposes regardless. A structured data export capability that produces personal data in a machine-readable format satisfies both GDPR’s explicit portability requirement and DPDPA’s implicit access right infrastructure requirement.

Technical Infrastructure Required Across All Six Rights

Fulfilling all six Data Principal rights requires a common technical infrastructure: a Data Principal identity verification mechanism at the point of rights exercise, a self-service rights submission portal accessible across channels, structured record storage for every rights request and response, automated fulfilment workflows for correction, erasure, and downstream notification, and an audit trail covering every step of every rights fulfilment process.

This infrastructure cannot be bolt-on. It must be integrated with the consent management system so that rights exercises are linked to the Data Principal’s consent record. It must be integrated with the access governance infrastructure so that erasure and deprovisioning workflows operate through the same automated lifecycle management that governs normal access changes.

Akku’s CIAM Consent Manager addresses 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation, covering the consent lifecycle, notice management, Data Principal rights fulfilment, and preference management. The User Lifecycle Manager addresses automated lifecycle events triggered by rights exercises. Together, these modules constitute the technical infrastructure DPDPA Data Principal rights require.

Diagnostic Questions

If a Data Principal submitted a Clause 11 access request today, could your organisation produce a structured summary of every category of personal data held about them, every processing purpose, and every entity with whom their data has been shared, without a manual compilation exercise across multiple system administrators?

When a Data Principal exercises their right to erasure under Clause 12(2)(c), does the erasure propagate automatically to every connected system holding their personal data, and does the Data Fiduciary receive confirmation of completion from each system?

Does your grievance mechanism produce a structured record for every complaint received, with a unique reference number, submission timestamp, and response record, sufficient to demonstrate to the Data Protection Board that the mechanism is operating effectively?

Can a Data Principal withdraw consent through a single self-service action in the same interface where they gave consent, without contacting support, and does withdrawal trigger automated processing cessation across all connected systems?

Has your organisation implemented a nominee registration mechanism, allowing Data Principals to designate someone to exercise their rights in the event of death or incapacity, as Clause 14(1) requires?

CTAs

See how Akku’s CIAM Consent Manager addresses DPDPA Data Principal rights requirements across access, correction, erasure, grievance redress, and nomination.

Book a conversation with the Akku team to assess your current technical infrastructure against DPDPA Data Principal rights obligations.

FAQs

What is the difference between the right to access under Clause 11 and the right to correction under Clause 12?

Clause 11 gives Data Principals the right to obtain information about what personal data is held about them and how it is being processed. It is an information right. The Data Fiduciary must tell the Data Principal what data it holds, for what purposes, and with whom it has been shared. Clause 12 gives the right to change or remove that data. It is an action right. The Data Fiduciary must update inaccurate data, complete incomplete data, or erase data no longer necessary for its original purpose. Both rights require technical fulfilment infrastructure, but the infrastructure requirements are different: Clause 11 requires a data retrieval and summary capability, while Clause 12 requires update and deletion workflows that propagate across connected systems.

What timeframe does DPDPA set for fulfilling Data Principal rights requests?

The DPDPA itself does not specify response timeframes in the current text. Timeframes are expected to be defined in the Rules, which are yet to be finalised. GDPR’s 30-day response standard for Data Subject rights requests is a reference point that many organisations subject to both frameworks are applying as a working standard for DPDPA as well. Organisations should monitor the Rules publication for specific timeframes and design their fulfilment workflows to operate within the expected standard.

Does Clause 12(3)’s downstream notification requirement apply to all third parties or only Data Processors?

Clause 12(3) requires that where the Data Fiduciary has previously shared personal data with another Data Fiduciary or Data Processor, the Data Fiduciary must inform that entity of the correction, completion, or erasure so that the entity can take corresponding action. The obligation applies to both other Data Fiduciaries and Data Processors with whom the data was shared. This requires the Data Fiduciary to maintain a current record of every entity to whom each Data Principal’s personal data has been disclosed, which is a data governance obligation with direct technical implications for how data sharing is tracked and recorded.

How does the nomination right under Clause 14 interact with the consent management system?

When a nominated individual exercises a Data Principal’s rights following death or incapacity, they are exercising those rights on behalf of the Data Principal. The rights themselves, access, correction, erasure, grievance redress, are the same rights the Data Principal would exercise directly. The technical requirement is an identity verification layer at the point of nominee activation, confirming both the nominee’s identity and the activation event, followed by access to the same rights fulfilment workflows the Data Principal would use directly. The nominee’s actions must be logged with their identity, the Data Principal’s identity, and the activation basis in the same audit trail as direct Data Principal rights exercises.

What happens technically when a Data Principal withdraws consent and the Data Fiduciary no longer has a lawful basis for processing?

When consent is withdrawn and no other lawful basis under Clause 4 applies, the Data Fiduciary must cease processing the personal data for the purposes covered by the withdrawn consent. Technically, this means deprovisioning access to personal data processing systems for the Data Principal’s data, suppressing the Data Principal’s records from processing workflows, and notifying Data Processors operating under the same consent basis to cease processing. Where the Data Principal also requests erasure under Clause 6(4), deletion workflows must propagate across all connected systems. The automated deprovisioning workflow triggered by consent withdrawal is the technical implementation of this cessation obligation.

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

Yes. The overlapping infrastructure requirements are substantial. Both DPDPA Clause 11 and GDPR Article 15 require self-service access to personal data summaries. Both DPDPA Clause 12 and GDPR Articles 16 and 17 require correction and erasure workflows that propagate across connected systems. Both DPDPA Clause 6(3) and GDPR Article 7(3) require self-service consent withdrawal with automated processing cessation. Akku’s CIAM Consent Manager implements the rights fulfilment infrastructure that satisfies both frameworks from a single deployment, with the consent record data model extended to capture the specific fields each framework requires.

Introduction

Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated correctly over a defined period. The quality of that evidence determines the audit outcome. An organisation with strong technical controls but weak evidence infrastructure will produce an audit package that reflects what can be reconstructed rather than what actually occurred. An organisation whose controls generate continuous, structured evidence as a byproduct of daily operations will produce an audit package that reflects operational reality.

The evidence standard varies by framework. RBI Clause 15 requires forensic-grade audit trails suitable for dispute resolution. SEBI CSCRF GV.OC.S2(G3) requires on-demand log access in structured format. SOC 2 Type II requires continuous operating evidence sampled across the full audit period. ISO 27001 A.8.15 requires user activity logs, not authentication logs. DPDPA Clause 8(4) requires demonstrable proof that technical measures are operating. Each framework has specific evidence requirements, but the underlying infrastructure that produces the evidence is the same across all of them.

This blog covers the five categories of audit evidence that every major compliance framework requires, what each category must contain, what format and retention standards apply, and how IAM controls produce each category as a continuous output rather than a pre-audit compilation exercise.

Authentication Event Evidence

Authentication event evidence is the foundational layer of every compliance audit evidence package. It establishes who accessed which systems, when, from where, and with what authentication assurance. Every framework reviewed in this series requires it.

What it must contain

A compliant authentication event record must contain actor identity tied to a unique, individual user account with no shared credentials. Timestamp with sufficient precision, ISO 8601 format with millisecond precision is the technical standard. Source IP address and resolved geographic location. Device identifier for sessions from managed endpoints. Authentication method including the specific MFA factor used. Outcome, success, failure, or blocked, with failure reason where applicable.

RBI Clause 15(a) requires authentication records with sufficient detail for forensic investigation. SEBI CSCRF PR.AA.S8 requires that every authentication event be logged. IRDAI ICS Items 54 and 55 require logging of failed authentication attempts and policy violations. ISO 27001 A.8.15 requires logging of security events including authentication failures. SOC 2 CC6.1 requires logical access security infrastructure that produces these records.

Format and retention standards

Authentication event logs must be stored in structured format, JSON or CSV, queryable by actor, system, time range, outcome, and MFA method. They must be append-only and tamper-evident. Retention periods vary by framework: most Indian regulatory frameworks expect a minimum of one year, with RBI-regulated entities typically maintaining two years for critical system access logs.

How Akku produces it

Every authentication event across all connected applications generates a structured log record automatically through Akku’s centralised authentication layer. The event stream is continuous, append-only, and exportable in JSON and CSV format via API or manual export. No manual compilation is required to produce authentication event evidence for any time period within the retention window.

Access Provisioning and Deprovisioning Evidence

Access provisioning and deprovisioning evidence covers the governance of how access was granted, modified, and removed. This is the evidence category that demonstrates need-based access, least privilege, and lifecycle management controls are operating as required.

What it must contain

A compliant provisioning record must contain the requester identity, the approver identity and approval timestamp, the justification for the access grant, the specific access being granted including system and role or permission level, the provisioning execution timestamp, and confirmation of downstream synchronisation to connected applications.

A compliant deprovisioning record must contain the trigger event, whether employment termination, role change, access review revocation, or consent withdrawal, the systems from which access was removed, the removal timestamp for each system, and where SCIM is used, the sync confirmation from each connected application.

RBI Clause 8(c) requires documented access governance with approval records. SEBI CSCRF GV.PO.S1 to S5 require technical enforcement of access policies with evidence. IRDAI ICS Item 6 requires controlled provisioning and removal of temporary and contractor accounts. ISO 27001 A.5.16 and A.5.18 require formal identity management and access rights processes. SOC 2 CC6.2 requires formal user registration evidence and CC6.3 requires access modification and removal evidence.

Format and retention standards

Provisioning and deprovisioning records must be structured and queryable by user, system, date range, and approver. Records must be retained for at least the duration of employment plus one year for deprovisioning records, and for at least two years for provisioning records covering access to critical systems. SCIM sync confirmation records must be retained alongside the IAM platform records to demonstrate end-to-end completion.

How Akku produces it

Every provisioning and deprovisioning event through Akku’s User Lifecycle Manager generates a structured record automatically. Access request and approval workflows capture requester, approver, justification, and timestamp at the time of the event. SCIM-based provisioning generates downstream sync confirmation records. Automated deprovisioning on exit generates a timestamped record of every account removed across every connected application at the time of the offboarding event.

Access Review and Certification Evidence

Access review evidence demonstrates that entitlements were periodically examined and that access no longer appropriate was revoked. This is the evidence category that satisfies the periodic review requirements across every framework.

What it must contain

A compliant access review record must contain the review scope, which users and systems were included in the cycle. The review date and the identity of each reviewer. For each entitlement reviewed, the decision, certify or revoke, with a timestamp and the reviewer’s identity. For revocations, a corresponding deprovisioning record showing the access was actually removed following the revocation decision.

RBI Clause 23(a) requires periodic access reviews with documented outcomes. SEBI CSCRF PR.AA.S3 and PR.AA.S5 require periodic access reviews and recertification. IRDAI ICS Item 189 requires access reviews. ISO 27001 A.5.18 requires periodic review of access rights with documented evidence. SOC 2 CC6.3 requires that access be modified or removed based on the system of record for entitlements.

Format and retention standards

Access review records must be structured and queryable by review cycle, reviewer, user, and entitlement. For SOC 2 Type II purposes, review records from every cycle throughout the audit period must be available. Annual reviews produce a single evidence record that auditors can sample. Quarterly reviews produce four records per year, demonstrating consistent operation throughout the period.

How Akku produces it

Access review and re-certification campaigns in Akku generate timestamped records for every certification or revocation decision at the time of the review cycle. Campaign records capture scope, reviewer assignments, decision timestamps, and outcomes. Revocation decisions automatically trigger deprovisioning workflows, linking the review record to the corresponding access removal record.

Privileged Session Evidence

Privileged session evidence is the evidence category that most organisations lack when they first approach compliance audits. Authentication logs confirm privileged sessions occurred. Privileged session evidence captures what happened during them.

What it must contain

A compliant privileged session evidence package must contain the session request and approval record including target system, access level, duration, justification, and approver identity. The session activity record at the protocol layer: keystroke logs for SSH sessions, SQL query capture for database sessions, screen recordings for RDP sessions. Session metadata including session ID, actor identity, target system, start and end timestamps, session duration, and termination reason and actor. Credential lifecycle events: credential generated, injected, and revoked, with timestamps.

RBI Clause 15 requires audit trails suitable for forensic investigation, which for privileged sessions requires session-level recording. SEBI CSCRF PR.AA.S12 requires that privileged session activity be logged with sufficient detail to reconstruct actions taken. IRDAI ICS Items 144 and 145 require session-level audit trail maintenance. ISO 27001 A.8.2 and A.8.15 together require privileged access control and user activity logging. SOC 2 CC5.2 and CC7.2 require general technology controls and anomaly monitoring for privileged sessions.

Format and retention standards

Session recordings must be stored encrypted. Keystroke logs and SQL query capture must be stored as structured data, searchable by timestamp, command string, or query text. Session metadata must be stored in structured format alongside or linked to recordings. Retention periods for privileged session recordings are typically two years for regulated entities, with longer retention for sessions involving access to regulated data categories.

How Akku produces it

SMARTAudit Trails capture every privileged session through AkkuReka at the protocol layer. SSH keystroke logs, SQL query capture for MySQL and PostgreSQL, and RDP screen recordings are generated automatically for every session. All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console. The session approval workflow record and AkkuArka credential lifecycle events are stored alongside each session record in the audit log.

Consent and Data Principal Rights Evidence

For organisations subject to DPDPA and GDPR, consent and data principal rights evidence is a required evidence category covering how personal data processing was authorised and how Data Principal or Data Subject rights were fulfilled.

What it must contain

A compliant consent evidence record must contain the Data Principal or Data Subject identity, the notice version under which consent was given, the specific processing purpose, the consent timestamp, the channel, and the current withdrawal status with withdrawal timestamp if applicable. For each Data Principal rights request, the request type, submission timestamp, fulfilment actions taken, and fulfilment timestamp.

DPDPA Clause 6(7) requires that Data Fiduciaries maintain consent records. DPDPA Clause 8(4) requires demonstrable proof that technical measures are operating. GDPR Article 7(1) requires that controllers be able to demonstrate consent was given. GDPR Article 5(2) requires that controllers demonstrate compliance with data protection principles.

Format and retention standards

Consent records must be structured, queryable by Data Principal identity, processing purpose, notice version, and date range. They must be append-only: existing records cannot be modified, only new events added. Retention must cover the full period of processing plus sufficient time for regulatory examination. For DPDPA and GDPR, a minimum of three years after the last processing event is common practice.

How Akku produces it

Akku’s CIAM Consent Manager generates structured consent records for every consent event, update, and withdrawal. The consent record data model captures all required fields per Data Principal per processing purpose. The audit trail for every consent lifecycle event is append-only. Data Principal rights fulfilment workflows generate timestamped records of every request received and every action taken in response.

Assembling the Evidence Package for a Regulatory Examination

A complete audit evidence package for a regulatory examination draws from all five categories above. The assembly process is straightforward when the underlying evidence infrastructure generates continuous, structured outputs. It becomes a manual reconstruction exercise when evidence infrastructure is incomplete.

Evidence package structure by framework

For an RBI IS audit, the package typically covers: authentication event logs for the examination period, provisioning and deprovisioning records for a sample of users including joiners and leavers, privileged session recordings for a sample of critical system accesses, access review records from the last review cycle, and MFA enforcement evidence showing consistent enforcement throughout the period.

For a SEBI CSCRF examination, the package adds: structured log exports in the format requested covering any period SEBI specifies, dormant account management records showing automatic disabling with timestamps, and endpoint compliance records from GPO Manager and MDM.

For an ISO 27001 certification audit, the package covers: user activity logs for privileged sessions across the audit period, access rights review records from each cycle in the certification period, provisioning records for all users onboarded during the period, and anomaly detection and monitoring records demonstrating A.8.16 operating effectiveness.

For a SOC 2 Type II audit, the package covers: provisioning records from across the full audit period sampled by the auditor, deprovisioning records for departures during the period, access review records from every cycle in the period, MFA enforcement evidence across the period, and endpoint control configuration records.

What separates a defensible package from a reconstructed one

A defensible audit evidence package contains records generated at the time of each event, stored in tamper-evident format, with no gaps in coverage for the examination period. A reconstructed package contains records assembled before the audit from email threads, spreadsheet trackers, and log exports formatted for the occasion.

Auditors distinguish between the two through inconsistencies in timestamp formatting, gaps in coverage sequences, evidence that records were produced in batch rather than event-by-event, and inability to produce records for auditor-selected time windows outside the prepared sample.

The infrastructure difference is the same infrastructure this series has covered in each blog: a centralised IAM platform that generates structured, continuous, tamper-evident evidence as a byproduct of operating the controls it implements.

Diagnostic Questions

For any 30-day window within the last twelve months, can you produce a complete, structured authentication event log covering all connected systems without manual compilation from individual application logs?

For a sample of ten users who were onboarded and ten who departed during the last twelve months, can you produce the provisioning and deprovisioning records for each without reconstructing them from email history?

Do your access review records cover every cycle that ran during the last audit period, with timestamped decisions for every entitlement reviewed, or does evidence exist for only the most recent cycle?

For any privileged session to a critical system that occurred in the last 90 days, can you produce the session recording and structured activity log within the same business day of the request?

If a regulator requested a structured log export covering a specific 90-day period tomorrow, could your team produce it within 24 hours in a structured format ready for submission?

CTAs

See how Akku generates continuous audit evidence across authentication events, provisioning records, access reviews, privileged sessions, and consent records from a single platform.

Book a conversation with the Akku team to assess the completeness of your current audit evidence infrastructure.

FAQs

What makes an audit evidence package defensible versus one that will draw auditor scrutiny?

A defensible audit evidence package contains records generated at the time of each event, stored in append-only, tamper-evident format, with no gaps in coverage for the examination period. Records are structured and queryable, meaning the auditor can select any sample from any point in the period and receive a complete record. A package that draws scrutiny contains records assembled before the audit, with timestamps that suggest batch generation, gaps in coverage outside the prepared sample window, or formats inconsistent with records generated by operational systems at the time of events.

What is the minimum retention period for audit evidence across Indian regulatory frameworks?

Retention requirements vary by framework and record type. RBI-regulated entities typically maintain authentication event logs for two years and privileged session recordings for two years or longer for critical system access. SEBI CSCRF requires log retention sufficient for regulatory examination on demand, with industry practice at one to two years. IRDAI ICS requires retention defined in the organisation’s IT security policy, with one year as a common minimum. DPDPA and GDPR require consent records to be retained for the duration of processing plus a period sufficient for regulatory examination. Organisations subject to multiple frameworks should apply the longest applicable retention period for each evidence category.

How does SCIM connector failure affect the completeness of deprovisioning evidence?

SCIM connectors synchronise deprovisioning actions from the IAM platform to connected applications. A SCIM connector failure means that a deprovisioning action recorded in the IAM platform did not propagate to the connected application. The IAM platform record shows the deprovisioning occurred. The connected application still has an active account for the departed user. The deprovisioning evidence is incomplete because the record does not reflect the actual access state. Connector health monitoring detects these failures before they create access gaps, ensuring that the deprovisioning evidence in the IAM platform accurately reflects the access state in connected applications.

Why does SOC 2 Type II require evidence sampled from across the full audit period rather than a point-in-time sample?

SOC 2 Type II attests that controls operated effectively throughout the audit period, not only at a point in time. Auditors sample control outputs from multiple points across the period to verify consistent operation. A control that worked correctly for the month before the audit but has no evidence of operation for the preceding eleven months fails the operating effectiveness standard. The sampling approach is specifically designed to detect controls that are implemented for audit purposes but do not operate continuously. Continuous evidence generation throughout the period, not assembled before the audit, is the only way to satisfy the Type II sampling approach.

What structured export formats do Indian regulators typically require for log submissions?

SEBI CSCRF GV.OC.S2(G3) requires on-demand access to logs in a format accessible to SEBI for examination. In practice, structured formats including JSON and CSV are the standard for log submissions to Indian regulators. RBI IS auditors typically accept structured exports in either format. IRDAI examiners following the Annexure III checklist expect log evidence to be producible in structured format. The key requirement across all frameworks is that logs be queryable and exportable without manual reformatting, meaning the underlying log infrastructure must store events in structured format rather than unstructured text files.

Can audit evidence from Akku be submitted directly to regulators, or does it require additional formatting?

Akku’s audit log exports in JSON and CSV format are structured and contain all standard fields that regulatory submissions require: event ID, timestamp, actor identity, target system, event type, outcome, source IP, and geographic location. For most regulatory submissions, these exports can be submitted directly or with minimal formatting. For specific regulatory portals or reporting templates that require a defined schema, the structured export can be mapped to the required format. Session recordings from SMARTAudit Trails are accessible for in-browser playback and exportable for submission to auditors or regulators requiring forensic review of specific sessions.

Introduction

DPDPA Chapters II and III establish six rights for Data Principals. Each right creates a corresponding technical obligation for the Data Fiduciary. The right to access personal data requires a self-service portal or fulfilment workflow capable of producing a structured summary of personal data and processing activities. The right to correction and erasure requires workflows that propagate changes across connected systems, not only in the primary data store. The right to grievance redress requires a documented complaint and response process with a timestamped record. The right to nomination requires a mechanism for registering and activating nominated representatives.

Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice. An organisation that has published a privacy notice describing its data principal rights commitment but has no technical mechanism for fulfilling a data access request has not implemented the right. The Data Protection Board of India will assess whether rights are technically exercisable, not whether they are described in a policy document.

This blog covers each of the six DPDPA Data Principal rights, what the Act specifically requires for each, and what technical infrastructure the Data Fiduciary must implement to fulfil them. All clause references are drawn from the DPDPA and Akku’s DPDPA compliance mapping documentation.

Right to Access Information Under Clause 11

Clause 11 gives Data Principals the right to obtain information about the personal data being processed about them and the processing activities being carried out.

What the clause requires

Clause 11(1)(a) gives Data Principals the right to obtain a summary of personal data being processed by the Data Fiduciary and the processing activities being undertaken with respect to that data.

Clause 11(1)(b) gives the right to know the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, along with a description of the personal data shared.

Clause 11(1)(c) gives the right to any other information related to personal data and its processing as may be prescribed by the Rules.

What this requires technically

The right to access requires a self-service portal through which a Data Principal can submit an access request and receive a structured response. At scale, manual fulfilment of access requests is not operationally viable. An organisation processing personal data of millions of customers cannot assign staff to manually compile data summaries for each access request received.

The response to an access request must be structured and complete. It must cover every category of personal data held, every processing purpose for which it is used, and every entity with whom it has been shared. This requires a data mapping that connects personal data categories to processing systems, and a mechanism for querying those systems to compile the response.

The disclosure of Data Processor identities under Clause 11(1)(b) requires that the Data Fiduciary maintain a current record of which processors hold which categories of personal data. This is a data governance obligation with a technical component: the processor record must be queryable at the time an access request is received.

Akku’s CIAM Consent Manager addresses Clauses 11(1)(a), 11(1)(b), and 11(1)(c) through Data Principal rights management workflows. The self-service portal enables access request submission and structured response delivery.

Right to Correction and Erasure Under Clause 12

Clause 12 gives Data Principals the right to correction, completion, updating, and erasure of their personal data.

What the clause requires

Clause 12(2)(a) gives the right to correction and updating of personal data that is inaccurate or incomplete. Clause 12(2)(b) gives the right to completion of personal data that is incomplete. Clause 12(2)(c) gives the right to erasure of personal data that is no longer necessary for the purpose for which it was collected.

Clause 12(3) requires that where the Data Fiduciary has shared personal data with another entity, the Data Fiduciary must inform that entity of the correction, completion, or erasure so that the entity can take corresponding action.

What this requires technically

Correction workflows must update personal data across every connected system where it is held. A correction applied only in the CRM but not in the marketing automation platform, the support system, and the billing system is an incomplete correction. The workflow must propagate the change to every downstream system holding the affected personal data.

Erasure workflows face the same multi-system challenge with additional complexity. Erasure must be complete and verifiable. The Data Fiduciary must be able to demonstrate that the personal data has been removed from every system where it was held, not only from the primary database. Where personal data is held in backups, the erasure timeline must account for backup retention cycles.

Clause 12(3)’s notification requirement creates an automated downstream communication obligation. When correction or erasure is completed, every Data Processor or other Data Fiduciary with whom the data was shared must be notified. At scale, this notification must be automated through the data processing infrastructure, not manually coordinated.

Akku’s CIAM Consent Manager addresses Clauses 12(2)(a), 12(2)(b), 12(2)(c), and 12(3) through correction and erasure workflow capabilities. The User Lifecycle Manager addresses Clause 12(3) through automated deprovisioning and data lifecycle workflows that propagate cessation events to connected systems.

Right to Grievance Redress Under Clause 13

Clause 13 gives Data Principals the right to have their grievances addressed by the Data Fiduciary before approaching the Data Protection Board of India.

What the clause requires

Clause 13(1) requires that every Data Fiduciary establish an effective mechanism for redressal of grievances of Data Principals. The mechanism must allow Data Principals to raise complaints about how their personal data is being processed and receive a response within a defined timeframe.

The Data Principal must exhaust the Data Fiduciary’s grievance mechanism before approaching the Data Protection Board. This creates a procedural requirement: the Data Fiduciary must have a functioning grievance process that produces documented responses, so that the Data Protection Board can assess whether the mechanism was effective before accepting a complaint.

What this requires technically

A grievance redress mechanism requires a complaint submission interface accessible to Data Principals through the same channels as the consent management system. Every complaint must be recorded with a unique reference number, submission timestamp, complaint category, and Data Principal identity. The response must be recorded with a resolution timestamp, the action taken, and the outcome communicated to the Data Principal.

The record of complaints received and responses provided is the evidence the Data Protection Board will examine when a Data Principal files a complaint claiming the grievance mechanism was ineffective. Without structured records showing that the complaint was received, investigated, and responded to within the required timeframe, the Data Fiduciary cannot demonstrate that the mechanism operated as required.

Akku’s CIAM Consent Manager addresses Clause 13(1) through grievance submission and response management workflows within the Data Principal rights management infrastructure.

Right to Nominate Under Clause 14

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

What the clause requires

Clause 14(1) gives every Data Principal the right to nominate any other individual who shall, in the event of the death or incapacity of the Data Principal, exercise the rights of the Data Principal in accordance with the provisions of the Act.

This right is unique to DPDPA among the frameworks covered in this series. It reflects the Act’s recognition that digital identity and personal data persist beyond individual incapacity events, and that Data Principals should be able to designate someone to manage their data rights in those circumstances.

What this requires technically

The nomination right requires a nomination registration mechanism within the consent management portal. A Data Principal must be able to register a nominee by providing the nominee’s identity details and their relationship to the Data Principal. The nomination must be stored as a structured record linked to the Data Principal’s identity.

When the Data Fiduciary receives a rights exercise request from a claimed nominee, the verification process must confirm the nominee’s identity, verify their registration as the Data Principal’s nominee, and verify the incapacity or death event that activates the nomination. The nominee’s rights exercise must be logged with the same audit trail as a direct Data Principal rights exercise.

Akku’s CIAM Consent Manager addresses Clause 14(1) through nominee registration and activation workflows within the Data Principal rights management infrastructure.

Right to Withdraw Consent Under Clause 6(3)

While Clause 6(3) sits within the consent provisions rather than the Data Principal rights chapter, the right to withdraw consent is operationally a Data Principal right and requires the same technical fulfilment infrastructure.

What the clause requires

Clause 6(3) requires that consent be as easy to withdraw as it is to give. If consent was given through a single action in a mobile application, withdrawal must be achievable through an equivalent single action in the same application. Clause 6(4) requires that the Data Fiduciary cease processing and, on request, erase the personal data when consent is withdrawn.

What this requires technically

Withdrawal must be a self-service action requiring no interaction with a human agent. The withdrawal interface must be accessible through the same channel as the original consent mechanism. Processing cessation must be automated, triggering notifications to every downstream system processing personal data under the withdrawn consent.

Where the Data Principal also requests erasure under Clause 6(4), the erasure workflow must propagate deletion requests across all connected systems and notify Data Processors under Clause 12(3).

Akku’s CIAM Consent Manager addresses Clauses 6(1), 6(3), 6(4), and 6(7) through consent withdrawal workflows with automated downstream processing cessation notifications. The User Lifecycle Manager addresses Clause 8(7)(a) and 8(7)(b) through deprovisioning workflows triggered by consent withdrawal events.

Right to Data Portability Under DPDPA

The DPDPA does not include an explicit data portability right equivalent to GDPR Article 20. However, Clause 11’s access right implicitly supports portability in practice: a Data Principal who receives a structured summary of their personal data under Clause 11(1)(a) can use that summary to transfer their data to another provider.

Organisations subject to both DPDPA and GDPR must implement data portability infrastructure for GDPR Article 20 purposes regardless. A structured data export capability that produces personal data in a machine-readable format satisfies both GDPR’s explicit portability requirement and DPDPA’s implicit access right infrastructure requirement.

Technical Infrastructure Required Across All Six Rights

Fulfilling all six Data Principal rights requires a common technical infrastructure: a Data Principal identity verification mechanism at the point of rights exercise, a self-service rights submission portal accessible across channels, structured record storage for every rights request and response, automated fulfilment workflows for correction, erasure, and downstream notification, and an audit trail covering every step of every rights fulfilment process.

This infrastructure cannot be bolt-on. It must be integrated with the consent management system so that rights exercises are linked to the Data Principal’s consent record. It must be integrated with the access governance infrastructure so that erasure and deprovisioning workflows operate through the same automated lifecycle management that governs normal access changes.

Akku’s CIAM Consent Manager addresses 19 of the 33 total DPDPA clause mappings in Akku’s compliance documentation, covering the consent lifecycle, notice management, Data Principal rights fulfilment, and preference management. The User Lifecycle Manager addresses automated lifecycle events triggered by rights exercises. Together, these modules constitute the technical infrastructure DPDPA Data Principal rights require.

Diagnostic Questions

If a Data Principal submitted a Clause 11 access request today, could your organisation produce a structured summary of every category of personal data held about them, every processing purpose, and every entity with whom their data has been shared, without a manual compilation exercise across multiple system administrators?

When a Data Principal exercises their right to erasure under Clause 12(2)(c), does the erasure propagate automatically to every connected system holding their personal data, and does the Data Fiduciary receive confirmation of completion from each system?

Does your grievance mechanism produce a structured record for every complaint received, with a unique reference number, submission timestamp, and response record, sufficient to demonstrate to the Data Protection Board that the mechanism is operating effectively?

Can a Data Principal withdraw consent through a single self-service action in the same interface where they gave consent, without contacting support, and does withdrawal trigger automated processing cessation across all connected systems?

Has your organisation implemented a nominee registration mechanism, allowing Data Principals to designate someone to exercise their rights in the event of death or incapacity, as Clause 14(1) requires?

CTAs

See how Akku’s CIAM Consent Manager addresses DPDPA Data Principal rights requirements across access, correction, erasure, grievance redress, and nomination.

Book a conversation with the Akku team to assess your current technical infrastructure against DPDPA Data Principal rights obligations.

FAQs

What is the difference between the right to access under Clause 11 and the right to correction under Clause 12?

Clause 11 gives Data Principals the right to obtain information about what personal data is held about them and how it is being processed. It is an information right. The Data Fiduciary must tell the Data Principal what data it holds, for what purposes, and with whom it has been shared. Clause 12 gives the right to change or remove that data. It is an action right. The Data Fiduciary must update inaccurate data, complete incomplete data, or erase data no longer necessary for its original purpose. Both rights require technical fulfilment infrastructure, but the infrastructure requirements are different: Clause 11 requires a data retrieval and summary capability, while Clause 12 requires update and deletion workflows that propagate across connected systems.

What timeframe does DPDPA set for fulfilling Data Principal rights requests?

The DPDPA itself does not specify response timeframes in the current text. Timeframes are expected to be defined in the Rules, which are yet to be finalised. GDPR’s 30-day response standard for Data Subject rights requests is a reference point that many organisations subject to both frameworks are applying as a working standard for DPDPA as well. Organisations should monitor the Rules publication for specific timeframes and design their fulfilment workflows to operate within the expected standard.

Does Clause 12(3)’s downstream notification requirement apply to all third parties or only Data Processors?

Clause 12(3) requires that where the Data Fiduciary has previously shared personal data with another Data Fiduciary or Data Processor, the Data Fiduciary must inform that entity of the correction, completion, or erasure so that the entity can take corresponding action. The obligation applies to both other Data Fiduciaries and Data Processors with whom the data was shared. This requires the Data Fiduciary to maintain a current record of every entity to whom each Data Principal’s personal data has been disclosed, which is a data governance obligation with direct technical implications for how data sharing is tracked and recorded.

How does the nomination right under Clause 14 interact with the consent management system?

When a nominated individual exercises a Data Principal’s rights following death or incapacity, they are exercising those rights on behalf of the Data Principal. The rights themselves, access, correction, erasure, grievance redress, are the same rights the Data Principal would exercise directly. The technical requirement is an identity verification layer at the point of nominee activation, confirming both the nominee’s identity and the activation event, followed by access to the same rights fulfilment workflows the Data Principal would use directly. The nominee’s actions must be logged with their identity, the Data Principal’s identity, and the activation basis in the same audit trail as direct Data Principal rights exercises.

What happens technically when a Data Principal withdraws consent and the Data Fiduciary no longer has a lawful basis for processing?

When consent is withdrawn and no other lawful basis under Clause 4 applies, the Data Fiduciary must cease processing the personal data for the purposes covered by the withdrawn consent. Technically, this means deprovisioning access to personal data processing systems for the Data Principal’s data, suppressing the Data Principal’s records from processing workflows, and notifying Data Processors operating under the same consent basis to cease processing. Where the Data Principal also requests erasure under Clause 6(4), deletion workflows must propagate across all connected systems. The automated deprovisioning workflow triggered by consent withdrawal is the technical implementation of this cessation obligation.

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

Yes. The overlapping infrastructure requirements are substantial. Both DPDPA Clause 11 and GDPR Article 15 require self-service access to personal data summaries. Both DPDPA Clause 12 and GDPR Articles 16 and 17 require correction and erasure workflows that propagate across connected systems. Both DPDPA Clause 6(3) and GDPR Article 7(3) require self-service consent withdrawal with automated processing cessation. Akku’s CIAM Consent Manager implements the rights fulfilment infrastructure that satisfies both frameworks from a single deployment, with the consent record data model extended to capture the specific fields each framework requires.