Introduction

The Digital Personal Data Protection Act, 2023 creates technical obligations that require infrastructure changes, not only policy updates. Consent management systems must be built or upgraded. Access controls for personal data systems must be implemented and evidenced. Data Principal rights fulfilment workflows must be operational. Audit trails must be continuous and tamper-evident. None of these are achievable by updating a privacy policy document.

Most IT teams approaching DPDPA compliance face a common challenge: the obligations are clear in principle but the implementation sequence is not. Attempting to implement everything simultaneously produces incomplete results across all areas. A phased approach that prioritises the highest-risk obligations first, builds the foundational technical infrastructure before the dependent controls, and produces auditable evidence at each phase is more effective than a parallel implementation attempt.

This 90-day action plan is structured around three 30-day phases. Phase one builds the foundational access control and identity infrastructure that every other DPDPA technical obligation depends on. Phase two implements consent management and Data Principal rights workflows. Phase three implements audit trail infrastructure, lifecycle management automation, and evidence packaging. The sequence is deliberate: access controls must be in place before consent management can be layered on top, and both must be operational before the audit trail evidence they generate can be packaged for regulatory examination.

All clause references are drawn directly from the DPDPA and Akku’s DPDPA compliance mapping documentation, which covers 24 of the 38 technical compliance items with 33 total clause mappings.

Phase One: Access Controls and Identity Infrastructure (Days 1 to 30)

Phase one addresses the Clause 8(4) and 8(5) obligations: appropriate technical measures to ensure processing is limited to authorised purposes and reasonable security safeguards to prevent personal data breaches. These are the foundational controls that all other DPDPA technical obligations build on.

Priority 1: Centralised identity store and SSO

If your organisation’s applications authenticate through separate credential systems, centralising authentication is the first infrastructure task. Every application that processes personal data must authenticate through a single identity layer. This is not a convenience feature for DPDPA purposes: it is what makes Clause 8(5)’s security safeguard requirement technically implementable at scale.

Actions for days 1 to 10: Inventory all applications that process personal data of Indian residents. Identify which applications authenticate through a centralised IdP and which maintain separate credentials. Prioritise migration to centralised authentication for applications processing the highest volumes or most sensitive categories of personal data.

Priority 2: Role-based access controls for personal data systems

Clause 8(4) requires that processing be limited to authorised purposes. Technically, this means RBAC must define which users can access which personal data systems for which purposes. Every user’s access to personal data systems must be tied to a role definition that reflects their authorised processing activities.

Actions for days 10 to 20: Map each role in your organisation to the personal data systems that role legitimately requires access to. Define RBAC role configurations in your IAM platform reflecting these mappings. Identify users whose current access exceeds what their role requires and initiate access reduction.

Priority 3: Adaptive MFA for personal data system access

Clause 8(5) requires reasonable security safeguards. MFA is the primary authentication security safeguard. For personal data systems, MFA must cover both end-user access and privileged administrator access.

Actions for days 20 to 30: Deploy Adaptive MFA for all applications processing personal data. Extend MFA to infrastructure-level access for administrators with privileged access to personal data systems through PAM. Verify that MFA enforcement is consistent across all covered systems and that the authentication event log is capturing MFA method and outcome per event.

Phase Two: Consent Management and Data Principal Rights (Days 31 to 60)

Phase two addresses the Clause 5 and 6 obligations for consent management and the Clauses 11 through 14 obligations for Data Principal rights. These require a consent management system, not policy documentation.

Priority 4: Consent management infrastructure

Actions for days 31 to 40: Deploy a consent management system capable of maintaining purpose-specific consent records per Data Principal. Configure versioned notice management for each processing purpose for which consent is the lawful basis. Define the consent record data model covering Data Principal identity, processing purpose, notice version, consent timestamp, channel, and withdrawal status.

For organisations with existing consent capture mechanisms, assess whether current records satisfy the Clause 6(7) record-keeping requirement. A database row recording form submission does not constitute a compliant consent record. If current records are insufficient, design a migration or re-consent strategy.

Priority 5: Consent withdrawal workflows

Clause 6(3) requires that withdrawal be as easy as giving consent. Clause 6(4) requires processing cessation on withdrawal.

Actions for days 40 to 50: Implement self-service withdrawal interfaces in every channel where consent was originally captured. Configure automated downstream processing cessation notifications triggered by withdrawal events. Test the end-to-end withdrawal workflow: Data Principal initiates withdrawal, downstream systems receive cessation notification, processing stops, and the withdrawal event is recorded with a timestamp in the consent audit trail.

Priority 6: Data Principal rights fulfilment workflows

Clauses 11 through 14 require operational rights fulfilment infrastructure for access requests, correction and erasure requests, grievance redress, and nomination.

Actions for days 50 to 60: Implement a Data Principal rights submission portal accessible through the same channels as the consent management system. Configure structured request logging with unique reference numbers and timestamps. Build correction and erasure workflows that propagate changes across all connected systems processing the relevant personal data. Implement the grievance submission and response mechanism with documented response records.

Phase Three: Audit Infrastructure, Lifecycle Management, and Evidence Packaging (Days 61 to 90)

Phase three implements the ongoing operational controls and evidence infrastructure that make DPDPA compliance continuous rather than point-in-time.

Priority 7: Privileged access session recording for personal data systems

Clause 8(5) requires security safeguards for personal data systems. For privileged users with direct access to databases and servers holding personal data, session-level recording is the security safeguard that produces the forensic evidence standard required by a regulatory examination.

Actions for days 61 to 70: Deploy AkkuReka’s session proxy for all privileged access to databases and servers holding personal data. Verify that SMARTAudit Trails are capturing SQL query logs for database sessions and keystroke logs for SSH sessions. Confirm that session recordings are stored encrypted and indexed for forensic search.

Priority 8: Automated lifecycle management for personal data access

Clause 8(7)(a) requires erasure when the processing purpose is no longer served. Clause 8(7)(b) requires cessation and erasure on consent withdrawal. Both require automated deprovisioning workflows, not manual offboarding checklists.

Actions for days 70 to 80: Configure automated deprovisioning workflows triggered by employment termination events from HR systems. Verify that deprovisioning propagates to all connected applications processing personal data, with SCIM sync confirmation records for each. Configure dormant account detection with a defined inactivity threshold for accounts with access to personal data systems. Implement access review campaigns for personal data system access on a defined cadence.

Priority 9: Audit trail verification and evidence packaging

Clause 8(4) requires that technical measures be demonstrable. This requires that the audit trail generated by phases one through three is structured, complete, tamper-evident, and producible on demand.

Actions for days 80 to 90: Verify that the centralised audit log captures authentication events, provisioning and deprovisioning events, consent lifecycle events, Data Principal rights request and response events, and privileged session events in a single queryable trail. Test the evidence package assembly: for a sample of Data Principals, verify that the consent record, access record, and any rights exercise records can be produced in structured format without manual compilation. Run a tabletop exercise simulating a Data Protection Board examination request and assess whether the evidence package produced would satisfy the request within 24 hours.

What the 90-Day Plan Does Not Cover

This plan covers the technical and system-driven layer of DPDPA compliance. Several obligations are outside the scope of what any technology platform addresses and must be progressed in parallel through legal and governance workstreams.

Appointment of a Data Protection Officer or consent manager as required under the Act. Data protection impact assessments for high-risk processing activities. Review and update of data processing agreements with Data Processors. Assessment of cross-border data transfer mechanisms for personal data transferred outside India. Board-level governance of the data protection programme. Staff training on DPDPA obligations and data handling procedures.

These workstreams should run concurrently with the technical implementation phases, not sequentially. The technical controls this plan implements are necessary but not sufficient for full DPDPA compliance.

Key Milestones and Evidence Checkpoints

End of Phase One (Day 30): Every application processing personal data authenticates through a centralised identity layer. RBAC role configurations reflect authorised processing purposes. MFA is enforced for all personal data system access. Authentication event logging is producing continuous, structured records.

End of Phase Two (Day 60): A compliant consent management system is operational with versioned notices, purpose-specific records, and self-service withdrawal. Data Principal rights fulfilment workflows are live and producing structured request and response records.

End of Phase Three (Day 90): Automated deprovisioning is triggered by employment termination and consent withdrawal events. Access reviews are running on a defined cadence. Privileged session recordings exist for all database and server access to personal data systems. A complete audit evidence package can be assembled on demand without manual compilation.

Diagnostic Questions

Has your organisation completed an inventory of all applications processing personal data of Indian residents, and do you know which of those applications currently authenticate through a centralised identity layer?

For each processing activity where consent is the lawful basis, does a purpose-specific consent record exist per Data Principal, or does your current system capture a single agreement covering all processing?

If the Data Protection Board requested evidence of your technical security measures for personal data systems today, could you produce structured authentication event logs, access records, and privileged session recordings within 24 hours?

When an employee who had access to personal data systems leaves your organisation, does their access cease automatically across all connected systems within the same business day, with a timestamped audit record of every account removed?

Has your organisation tested the end-to-end Data Principal rights fulfilment workflow, from submission through to correction or erasure propagation across connected systems, with a documented record of the test and its outcomes?

CTAs

See how Akku addresses DPDPA technical compliance requirements across consent management, access controls, lifecycle management, and audit trails.

Book a conversation with the Akku team to assess your current technical posture and plan your DPDPA implementation sequence.

FAQs

What is the most critical DPDPA technical obligation to implement first?

The foundational obligation is Clause 8(4)’s requirement for appropriate technical measures to ensure processing is limited to authorised purposes. Technically, this means centralised authentication and role-based access controls for personal data systems must be in place before consent management or rights fulfilment workflows can be layered on top. Without knowing who can access which personal data systems and under what authorisation, consent management alone does not constitute appropriate technical measures. Access controls are the foundation on which all other DPDPA technical obligations rest.

Does the 90-day timeline apply to all organisations, or does it vary by organisation size and complexity?

The 90-day timeline is a structured framework, not a universal commitment. Larger organisations with complex application landscapes, multiple data processing systems, and large Data Principal populations will require more time for each phase. The sequence of phases is consistent regardless of organisation size: access controls before consent management before audit infrastructure. What varies is the time required within each phase. Organisations with existing centralised identity infrastructure and mature access controls may compress phase one significantly. Organisations building consent management from scratch may require more time in phase two.

What should organisations do about personal data collected before DPDPA came into force?

Clause 5(2) requires that Data Fiduciaries who collected personal data before the Act came into force, without providing a Clause 5-compliant notice, must provide a compliant notice as soon as reasonably practicable and give Data Principals the opportunity to withdraw consent. Technically, this requires identifying which Data Principals’ records were collected under pre-Act processes, delivering a compliant notice to each, and recording their response in the consent management system. This re-consent exercise should be incorporated into phase two of the implementation plan, following deployment of the consent management infrastructure.

How does DPDPA compliance interact with existing ISO 27001 or SOC 2 programmes?

Organisations with existing ISO 27001 or SOC 2 programmes will find substantial overlap with DPDPA’s technical obligations. Clause 8(5)’s security safeguards requirement maps directly to ISO 27001 A.8.5, A.8.2, and A.8.15. Clause 8(4)’s access limitation requirement maps to ISO 27001 A.5.15 and SOC 2 CC6.2 and CC6.3. Organisations that have implemented these controls for ISO 27001 or SOC 2 purposes have already addressed a significant portion of DPDPA’s technical layer. The primary DPDPA-specific addition is the consent management infrastructure under Clauses 5 and 6, which has no direct ISO 27001 or SOC 2 equivalent.

What evidence should organisations be able to produce for a Data Protection Board examination?

A Data Protection Board examination of DPDPA compliance will typically focus on: consent records demonstrating that processing is based on valid consent, access control records showing that personal data access is limited to authorised personnel, deprovisioning records demonstrating that access ceases when the processing purpose is no longer served, Data Principal rights fulfilment records showing that rights exercises were responded to appropriately, and security safeguard records demonstrating that technical measures are implemented and operating. All of these must be producible from structured, queryable systems in a format suitable for regulatory submission, not assembled through manual compilation before the examination.

What is the consequence of not having a compliant consent management system when DPDPA enforcement begins?

Processing personal data without a valid lawful basis under DPDPA is a violation of the Act. Where consent is the intended lawful basis, processing without a compliant consent record means there is no demonstrable lawful basis for the processing. The Data Protection Board can direct the Data Fiduciary to cease processing, impose financial penalties, and require remediation. The absence of a compliant consent management system is not only a technical gap: it is a fundamental lawful basis gap that affects the legality of all processing activities that rely on consent.