The Digital Personal Data Protection Act, 2023 is not a policy compliance exercise. The obligations it creates land directly on your IT infrastructure. Consent must be captured, stored, and made withdrawable through a technical system. Access to personal data must be controlled and auditable. Data Principal rights including access, correction, and erasure require automated workflows to fulfil within the timeframes the Act implies. Breach notification requires the ability to identify what data was affected, who had access to it, and when.
Most IT teams approaching DPDPA are doing so through a legal and compliance lens: reading the Act, mapping obligations, writing policies. The technical implementation is a separate and more demanding exercise. A policy stating that consent will be obtained is not a consent management system. A policy stating that access will be controlled is not an access control implementation.
This blog covers what DPDPA specifically requires at the technical layer, clause by clause, across consent management, access controls, data principal rights, and audit readiness. All control references are drawn directly from the Act and from Akku’s DPDPA compliance mapping documentation.
DPDPA compliance covers both technical and organisational obligations. Board-level governance, data protection policies, vendor contracts, and the appointment of a Data Protection Officer are outside the scope of what any technology platform addresses. What follows covers the technical and system-driven layer specifically.
Consent is the primary lawful basis for processing personal data under DPDPA for most organisations. The Act sets specific technical requirements for how consent must be obtained, recorded, managed, and withdrawn. These requirements cannot be satisfied by a checkbox on a web form backed by no structured data infrastructure.
DPDPA Clause 5(1) requires that a notice be given to the Data Principal before consent is sought. That notice must be in clear and plain language, specifying the personal data to be collected and the purpose of processing. Clause 5(2) requires that existing consents obtained without a compliant notice be refreshed.
Clause 6(1) requires that consent be free, specific, informed, unconditional, and unambiguous. Clause 6(3) requires that consent be as easy to withdraw as it is to give. Clause 6(4) requires that processing cease and data be erased when consent is withdrawn, subject to legal retention obligations. Clause 6(7) requires that consent records be maintained.
Clause 9(1) requires additional protections for processing personal data of children, including verifiable parental consent.
A technically compliant consent system must version notices so that each version is tied to the consent records obtained under it. When the notice changes, affected Data Principals must be re-consented under the new version. This is not achievable with a static terms-and-conditions page.
Consent records must be timestamped, tied to a specific Data Principal identity, linked to a specific notice version, and scoped to a specific processing purpose. A single consent record covering all processing purposes does not satisfy Clause 6(1)’s specificity requirement.
Withdrawal must be operationalised as a self-service workflow that the Data Principal can initiate without contacting support. When withdrawal is received, the downstream systems must be notified to cease processing. For workforce systems, this maps to deprovisioning access to personal data systems. For customer-facing systems, this maps to CIAM consent withdrawal workflows.
Akku’s CIAM Consent Manager addresses Clauses 4(1), 5(1), 5(2), 5(3), 6(1), 6(3), 6(4), 6(7), 8(3), and 9(1) directly. It provides centralised consent record storage, versioned notice management, preference management across channels, full consent audit trails for every update, and withdrawal workflows that trigger downstream processing cessation. Akku’s DPDPA compliance mapping shows 19 of the 33 total clause mappings are carried by the CIAM Consent Manager module, reflecting how central consent infrastructure is to the Act’s technical requirements.
Clause 8 of DPDPA imposes a direct obligation on Data Fiduciaries to implement technical and organisational measures to ensure that personal data is processed only for the purposes for which it was collected, and that access is limited to authorised personnel. This is an IT engineering obligation, not a policy statement.
Clause 8(4) requires Data Fiduciaries to implement appropriate technical and organisational measures to ensure effective observance of the provisions of the Act. This includes ensuring that processing is limited to authorised purposes and that access to personal data is restricted to personnel who require it.
Clause 8(5) requires Data Fiduciaries to protect personal data under their possession or control by implementing reasonable security safeguards to prevent personal data breaches.
Clause 8(7)(a) requires erasure of personal data as soon as it is reasonable to assume that the purpose for which it was collected is no longer being served. Clause 8(7)(b) requires erasure upon withdrawal of consent.
Clause 8(4) maps directly to RBAC and access governance controls. Access to systems that process personal data must be role-based, limited to personnel with a current, documented need, and reviewed periodically to ensure it remains appropriate. An employee who has moved to a different function but retains access to a customer data system is a direct Clause 8(4) deficiency.
Clause 8(5) maps to the broader IAM security controls layer: Adaptive MFA to prevent unauthorised authentication, contextual access controls to restrict access by device, IP, and location, and privileged access management to govern administrator access to systems holding personal data. AkkuReka brokers all privileged sessions to personal data systems, ensuring no direct access without a governed, recorded session.
Clause 8(7) maps to automated deprovisioning. When employment ends, access to personal data systems must be revoked promptly and completely. When consent is withdrawn, the processing entitlements tied to that consent must cease. Both require automated lifecycle management with a timestamped, auditable deprovisioning record. A manual offboarding checklist does not produce the structured proof that a regulatory inquiry would require.
Akku’s access control modules, covering RBAC, ABAC, contextual access, adaptive MFA, and automated lifecycle management, collectively address Clause 8(4), 8(5), 8(7)(a), and 8(7)(b). The IGA module’s access reviews and re-certification campaigns provide the periodic review mechanism that Clause 8(4)’s ongoing observance requirement implies.
Chapters III of DPDPA establishes six rights for Data Principals. Each right creates a corresponding technical obligation for the Data Fiduciary. The right exists on paper only if the technical infrastructure to fulfil it exists in practice.
Clause 11(1)(a) gives Data Principals the right to obtain a summary of personal data being processed and the processing activities. Clause 11(1)(b) gives the right to know the identities of other Data Fiduciaries and Data Processors with whom data has been shared. Clause 11(1)(c) gives the right to any other information related to personal data and its processing as prescribed.
Clause 12(2) gives Data Principals the right to correction, completion, updating, and erasure of personal data. Clause 12(3) requires that where a Data Principal has previously shared personal data with another entity, that entity must be informed of corrections or erasures.
Clause 13(1) gives Data Principals the right to grieve: to register a complaint with the Data Fiduciary before approaching the Data Protection Board.
Clause 14(1) gives Data Principals the right to nominate another individual to exercise their rights in case of death or incapacity.
The right to access under Clause 11 requires a self-service portal through which Data Principals can request and receive a structured summary of their personal data and processing activities. This cannot be a manual process at scale. For organisations with large customer bases, manual fulfilment of data access requests within any reasonable timeframe is operationally unviable.
The right to correction and erasure under Clause 12 requires workflows that can update or delete personal data across connected systems, not just in one database. An erasure request fulfilled in the CRM but not in the marketing automation platform, the support ticketing system, or the billing system is an incomplete erasure.
Akku’s CIAM Consent Manager addresses Clauses 11(1)(a), 11(1)(b), 11(1)(c), 12(2)(a), 12(2)(b), 12(2)(c), 12(3), 13(1), and 14(1). The User Lifecycle Manager addresses Clauses 6(6), 8(7)(a), 8(7)(b), and 12(3) through automated deprovisioning and data lifecycle workflows triggered by consent withdrawal or role change events.
DPDPA’s breach notification obligation under Clause 8(6) requires Data Fiduciaries to notify the Data Protection Board and affected Data Principals in the event of a personal data breach. The technical prerequisite for this is a structured audit trail that can identify what data was affected, which systems were involved, and who had access at the time. Without that infrastructure, breach notification is guesswork.
Clause 8(5) requires implementation of reasonable security safeguards to prevent personal data breaches. Clause 8(6) requires intimation of personal data breaches to the Data Protection Board of India and to each affected Data Principal in such a manner as may be prescribed.
Clause 8(4) requires ongoing observance of the provisions of the Act, which includes maintaining evidence that technical measures are operating effectively, not merely that they are implemented.
Breach notification under Clause 8(6) requires the ability to determine, at the time of discovery, which Data Principals were affected, what categories of personal data were involved, which systems held the data, and which users or processes had access to those systems during the relevant window. This determination requires structured, searchable audit logs with sufficient granularity.
Authentication logs alone do not provide this. Session activity logs for privileged access to personal data systems, capturing commands executed and queries run, are the audit trail that makes breach scoping operationally viable. Without them, the scope of a breach can only be estimated, not determined.
Akku’s SMARTAudit Trails capture every privileged session to connected systems at the protocol layer, producing a searchable record of every command and query executed. The append-only, tamper-evident audit log architecture ensures that records cannot be modified after the fact, which is the integrity standard a regulatory inquiry would require.
The access governance layer, covering provisioning records, approval trails, access review outcomes, and deprovisioning records, provides the complementary evidence of who had access to personal data systems, on what basis, and for what period. Together, these constitute the audit infrastructure that makes Clause 8(5) and 8(6) compliance demonstrable rather than asserted.
Akku’s DPDPA compliance mapping covers 24 of the 38 technical compliance items in the Act, with 33 total clause mappings across 11 platform modules. The remaining items relate to organisational obligations, governance requirements, and areas outside the scope of IAM platforms.
The coverage is distributed across the platform as follows. The CIAM Consent Manager carries 19 of the 33 mappings, covering the consent lifecycle, notice management, Data Principal rights, and preference management. The User Lifecycle Manager covers Clauses 6(6), 8(7)(a), 8(7)(b), and 12(3) through automated lifecycle workflows. The access control modules, covering RBAC, adaptive MFA, contextual access, and PAM, collectively address Clause 8(4) and 8(5). The IGA module addresses Clause 8(4) through access governance and SoD enforcement.
The practical implication is that a single Akku deployment, configured correctly across its modules, addresses the technical layer of DPDPA without requiring separate point solutions for consent management, access control, and audit trail generation. The consent audit trail, the access governance records, and the session activity logs all exist within one platform, accessible through one interface, and exportable in structured format for regulatory submission.
Which clauses of DPDPA create direct technical obligations for IT teams?
The primary technical obligations fall under Clauses 5 and 6 (consent notice and management), Clause 8(4) (appropriate technical measures for authorised processing), Clause 8(5) (security safeguards to prevent breaches), Clause 8(7) (erasure on purpose completion or consent withdrawal), and Clauses 11 through 14 (Data Principal rights fulfilment). Each of these requires a technical system to implement, not a policy document to state.
What is the difference between a consent record and a consent management system?
A consent record is a single captured data point: a user clicked agree on a particular date. A consent management system maintains versioned notices, ties each consent to a specific notice version and processing purpose, records every update and withdrawal with a timestamp, supports self-service withdrawal, and notifies downstream systems when consent is withdrawn. DPDPA Clause 6 requires the latter. A database row recording a checkbox state does not satisfy the Act’s specificity, withdrawability, or audit trail requirements.
Does DPDPA require erasure of personal data when an employee leaves?
Clause 8(7)(a) requires erasure of personal data as soon as it is reasonable to assume that the purpose for which it was collected is no longer being served. For employee data, departure is the event that triggers this determination. In practice, this means automated deprovisioning of access to personal data systems, combined with data retention policies that define how long employee personal data is held and on what legal basis. The access revocation component is an IAM obligation. The data retention and deletion component requires a broader data governance framework.
What does DPDPA require for Data Principal rights fulfilment?
Clauses 11 through 14 give Data Principals rights to access, correction, erasure, grievance redress, and nomination. Each right requires a technical fulfilment mechanism. Access requests require a self-service portal producing structured summaries. Correction and erasure requests require workflows that propagate changes across connected systems. Grievance redress requires a documented complaint and response process. At scale, manual fulfilment of these rights is not operationally viable within any reasonable timeframe.
How does DPDPA’s breach notification requirement differ from GDPR’s?
GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a breach. DPDPA Clause 8(6) requires intimation to the Data Protection Board of India and to each affected Data Principal in a manner to be prescribed. The prescribed timelines and format are subject to the Rules, which are yet to be finalised. However, the technical prerequisite is the same under both frameworks: structured audit logs that enable rapid identification of affected Data Principals, data categories, and access history at the time of the breach.
Can a single IAM platform address DPDPA’s full technical compliance requirement?
Akku addresses 24 of the 38 technical compliance items in DPDPA, covering consent management, access controls, Data Principal rights workflows, audit trail generation, and lifecycle management. The remaining items relate to organisational obligations and governance requirements that sit outside the scope of any IAM platform. Full DPDPA compliance requires both the technical controls that IAM provides and the organisational measures that governance frameworks, legal counsel, and data protection officers address.
Your organisation has forty-three applications. Each one manages its own users. Each one has its own provisioning process, its own…
Your PAM platform covers privileged access. Ask your infrastructure team how much of it, and the answer will involve a…
Your SCIM provisioning connector ran its last sync six hours ago. It failed. Nobody received an alert. Nobody knows. The…
Your MDM platform reports device location. What it does not tell you is how much of the shift that location…
What is the most sensitive system in your organisation? Not the most technically complex. The one with the highest concentration…
Here is a question worth asking your compliance team: how long would it take to produce the evidence package for…