Most Indian companies preparing for the Digital Personal Data Protection Act are starting in the same place: the privacy policy.
They are rewriting consent notices, updating cookie banners, adding a grievance officer's email to the footer, and hiring a law firm to review the document. And in isolation, none of that is wrong. A privacy policy that accurately describes your data practices is a real legal requirement under Section 5 of the DPDP Act.
But it is also approximately 5% of the actual compliance work.
The other 95% is engineering. Data mapping. Consent architecture built into the product. Deletion workflows that span every system in your infrastructure. Breach detection and notification systems that can meet a 72-hour deadline. Continuous monitoring that catches compliance drift before a regulator does.
Almost nobody is talking about this. The conversation around DPDP in India is dominated by policy templates, legal checklists, and deadline countdowns. The engineering work that determines whether a company is genuinely compliant or merely holding a well-formatted document sits quietly in the background, unaddressed.
This blog breaks down that engineering work, layer by layer, with references to the specific DPDP sections that mandate each one.
The iceberg problem
Think of DPDP compliance as an iceberg.
Above the waterline sits the privacy policy: the public-facing document that visitors, customers, and auditors see first. This is the part every law firm is equipped to fix. It is necessary, and it is insufficient.
Below the waterline sits everything else: where personal data actually lives in your infrastructure, how consent is recorded and propagated, whether you can fulfill an erasure request across every system that holds a user's data, whether you can detect a breach and report it within the mandated timeframe, and whether your compliance posture survives the next deployment.
The gap between these two layers is where real risk lives. A company with a beautifully written privacy policy and no data map is making a promise it cannot verify. A company with consent language reviewed by three lawyers but no mechanism to propagate consent withdrawal to downstream processors is compliant on paper and exposed in practice.
Based on over 300 DPDP audits across Indian startups in fintech, edtech, healthtech, and SaaS, the pattern is consistent. Companies invest in the visible layer and neglect the infrastructure underneath it. Not because they are negligent, but because the visible layer is what lawyers and consultants are trained to deliver. The engineering layer requires a different discipline entirely. For the full findings from that audit set, see The State of DPDP Compliance in India (2026).
Layer 1: The privacy policy and consent notices
DPDP Sections: 5, 6(1), 6(3)
This is where most compliance programs begin and, too often, where they end.
Section 5 requires a notice to be given before or at the time of requesting consent. The notice must describe every personal data item being collected, the purpose of processing each item, and the manner in which the Data Principal can exercise their rights. Section 6(1) requires that consent be free, specific, informed, and unambiguous, limited to the data necessary for the specified purpose. Section 6(3) mandates that the notice be available in English and every language listed in the Eighth Schedule of the Constitution, which currently includes 22 languages.
These are meaningful obligations. But they are obligations about a document: what it says, in what language, and when it is displayed. Fulfilling them is a legal and UX task. It does not require changes to your database, your infrastructure, or your product architecture.
The problem arises when companies treat this layer as the whole project. Across the audits we have conducted, 85% of Indian companies do not reference the DPDP Act in their privacy policy at all. 92% rely on implied consent (continuing to browse the site counts as agreement) rather than affirmative opt-in. 62% list rights that exist under GDPR but not under DPDP, such as data portability.
These are real gaps, and fixing them matters. But fixing them without addressing Layers 2 through 5 is like changing the label on a product without changing what is inside.
Layer 2: Data discovery and mapping
DPDP Sections: 8(3), 8(7), 11, 12
This is where the engineering begins.
When a user signs up for your product, their personal data does not stay in one database. It flows into your primary application database. It gets copied into your analytics pipeline. It reaches your payment processor. Pieces of it land in your marketing automation system, your customer support tool, your logging infrastructure, your cloud storage buckets, your database backups, and potentially several third-party SDKs.
Under the DPDP Act, multiple obligations depend on you knowing exactly where all of this data lives.
Section 11 grants Data Principals the right to access their personal data. When someone asks "what data do you have on me?", you need to be able to answer completely, across every system. Section 12 grants the right to correction and erasure. When someone asks you to delete their data, you need to know every location where it exists, not just the primary database but the analytics warehouse, the backup, the Razorpay payment records, the email marketing list, the exported CSV that someone put in a shared Google Drive.
Section 8(7) goes further. It requires you to erase personal data proactively once the purpose of collection has been fulfilled or once consent is withdrawn, even if the Data Principal does not explicitly request it. This obligation is impossible to fulfill without a data map.
A data map is not a spreadsheet listing your database names. It is a living record of where personal data exists across your entire infrastructure, how it flows between systems, who has access to it, what retention policies apply to each location, and whether you have the technical capability to delete a specific user's data from each one.
Most companies we audit cannot answer a basic question: if User #4,723 submitted an erasure request right now, how many systems would need to be touched, and how long would it take? The typical honest answer is "we would need to figure that out." That gap, the gap between the promise in the privacy policy and the operational reality, is the core compliance risk.
For companies running on AWS, a practical starting point is scanning S3 bucket naming patterns and lifecycle policies, checking whether RDS instances and DynamoDB tables have retention configurations, and mapping which services write to which data stores. Pattern matching on column names (email, phone, pan, aadhaar, dob) can surface personal data fields that were never formally catalogued. None of this is a privacy policy task. It is an infrastructure task.
Layer 3: Consent architecture
DPDP Sections: 5, 6(1), 6(4), 6(8)
This is the layer that separates a compliant product from a compliant document.
A consent architecture is not a checkbox on a signup form. It is a system that records every consent event with a timestamp, the specific purpose consented to, the version of the consent notice shown, the language it was displayed in, and the identity of the Data Principal who gave it. It stores this in an immutable, auditable ledger. And critically, it propagates changes in consent to every downstream system that processes data based on that consent.
Section 6(4) is the provision that makes this an engineering problem: consent withdrawal must be as easy as giving consent. If a user signed up with one click, they must be able to withdraw with one click. And withdrawal is not a request for the company to consider. It is a legal event that starts the erasure clock.
Here is the engineering challenge. A user revokes marketing consent. That revocation needs to propagate, in real time or near-real time, to every system that processes their data for marketing purposes: the email marketing platform, the push notification system, the analytics pipeline that feeds retargeting, the third-party enrichment vendor, the CDP. Each of these systems needs to stop processing the user's data for that purpose.
Most companies store consent status in one database and process data in fifteen others. When consent changes in the first, the other fifteen do not know. The marketing emails keep going. The analytics pipeline keeps tracking. The company is technically processing data without a lawful basis, which is a Section 6 violation, with penalties up to Rs. 50 crore per contravention.
The consent propagation problem is the single hardest engineering challenge in DPDP compliance. Solving it requires a message bus or event-driven architecture that treats consent changes as system events, not UI updates. It requires every downstream processor to subscribe to consent state and act on changes. And it requires audit logging at every step to prove that withdrawal was honored.
None of this is a document problem. A law firm cannot build a consent propagation engine. This is systems engineering. The implementation guide covers the ledger schema, purpose taxonomy, capture layer, and processor propagation: DPDP Consent Management: Complete Implementation Guide.
Section 6(8) introduces the Consent Manager framework, which becomes operational on November 13, 2026. Consent Managers will act as intermediaries, managing consent on behalf of Data Principals across multiple Data Fiduciaries. Companies that integrate with Consent Managers will need standardized APIs for consent ingestion and withdrawal propagation, adding another integration layer to the engineering work.
Layer 4: Rights management and erasure
DPDP Sections: 11, 12, 13, 14, 8(7)
The DPDP Act grants Data Principals five specific rights: access (Section 11), correction and erasure (Section 12), grievance redressal (Section 13), and nomination (Section 14). Each of these requires a workflow, not just a statement in a privacy policy.
When a Data Principal requests access to their data, the system needs to query the data map (Layer 2), collect all personal data associated with that individual across every system, compile it into a readable format, and deliver it. This is not a manual process that scales. For a company with thousands of users and data spread across ten systems, fulfilling access requests manually is a support burden that quickly becomes unsustainable.
Erasure is harder. Section 8(7) of the Act and Rule 8 of the DPDP Rules 2025 set out the framework. Personal data must be erased when consent is withdrawn, when the specified purpose is no longer being served, or when the individual has not engaged with the service within the retention period. The obligation extends to Data Processors: the Data Fiduciary must cause its processors to erase the data as well.
Consider a concrete example. An NBFC lending app collects income certificates, bank statements, and employment letters during loan appraisal. The application is rejected. The purpose of credit assessment is complete. Under Section 8(7), the NBFC must erase those documents without waiting for the applicant to request it. If the documents are sitting in an S3 bucket with no lifecycle policy, a document management system with no retention automation, and a backup that runs nightly with no user-level deletion capability, the company is in violation without knowing it.
Erasure across distributed systems requires coordination across primary databases, analytics warehouses, backup systems, third-party vendors, and any processor that received the data. It requires a deletion confirmation mechanism, ideally a deletion certificate, that proves the data was removed from every location. And it requires a retention policy that is not just written in a document but enforced technically, through S3 lifecycle policies, DynamoDB TTL settings, database job schedulers, and contractual deletion clauses with every vendor.
For children's data under Section 9, the rights management challenge is even more complex. The Rights Portal needs a parental verification layer: before a child's data request is processed, the system must verify that the requestor is the parent or legal guardian through a meaningful verification mechanism, not just a "I am the parent" checkbox. For edtech-specific Section 9 controls, see DPDP Compliance for Edtech.
Grievance redressal under Section 13 carries a 90-day response timeline. This requires intake tracking, SLA enforcement, escalation workflows, and audit trails showing the resolution process. Again: process engineering, not document drafting.
Layer 5: Breach response
DPDP Sections: 8(6), DPDP Rules: Rule 7
Section 8(6) requires every Data Fiduciary to notify the Data Protection Board and every affected Data Principal when a personal data breach occurs. Rule 7 of the DPDP Rules operationalizes this into a two-stage process.
Stage one is immediate notification. The Board must be informed without delay, with the nature, extent, timing, and location of the breach, and its likely impact.
Stage two is a comprehensive report, due within 72 hours. It must include the facts and causes of the breach, measures taken to mitigate risks, findings regarding responsible parties, steps to prevent recurrence, and a summary of notifications issued to affected individuals.
Two things make this an engineering problem, not a legal one.
First, the 72-hour clock starts when the organization becomes aware of the breach. "Becomes aware" requires detection infrastructure. If your team discovers a breach three weeks after it happened because nobody was monitoring access logs, the 72-hour clock started three weeks ago. This means you need real-time or near-real-time monitoring of data access patterns, anomaly detection, and alerting systems that can surface unauthorized access before it becomes a news story.
Second, India has two overlapping breach reporting frameworks. CERT-In requires reporting cybersecurity incidents within 6 hours. The Data Protection Board requires reporting personal data breaches within 72 hours. A breach involving personal data triggers both simultaneously. Your response workflow needs to handle both timelines in parallel.
The penalty for failing to notify the Board about a breach is up to Rs. 200 crore. There is no materiality threshold: a breach affecting ten records carries the same notification obligation as one affecting ten million.
Building breach readiness requires pre-populated notification templates, classification workflows that can determine whether a security incident involves personal data, escalation chains with defined roles, and dry-run exercises that test the entire response pipeline before a real incident occurs. These are operational and engineering deliverables, not legal documents.
Layer 6: Continuous monitoring and drift detection
This is what separates one-time compliance from sustained compliance.
Everything described in Layers 1 through 5 produces a compliance posture at a point in time. But products change. Engineering teams ship new features, add new data fields, integrate new third-party services, migrate databases, and modify API endpoints. Every one of these changes can introduce a new compliance gap.
A developer adds a new column to the user table that captures location data. The data map does not update automatically. The privacy policy does not mention location data. The consent notice does not list it as a purpose. The retention policy does not cover it. The deletion workflow does not know about it. A single, routine engineering change has silently broken compliance across four layers.
Continuous monitoring means running compliance checks on an ongoing basis: rescanning infrastructure for new personal data stores, comparing the current state of the system against the last known compliant state, flagging regressions, and alerting the team before a new deployment quietly creates a Section 6 violation.
This is the recurring value that justifies treating DPDP compliance as an ongoing discipline rather than a one-time project. It is also the layer that most consulting engagements do not cover, because consultants deliver reports at a point in time and leave. The product keeps changing.
The 5-second test
Here is a practical exercise you can run today.
Pick any user in your production database. Try to produce a complete record of every piece of their personal data across all your infrastructure: your primary database, your analytics tools, your payment processor, your marketing platform, your cloud storage, your backups, your third-party vendors.
Time yourself.
If it takes your team more than a day to answer with confidence, no privacy policy rewrite will make you DPDP compliant. The policy is the promise. Your infrastructure is whether you can keep it.
What this means for your compliance program
The DPDP Rules were notified on November 13, 2025. Full compliance is required by May 13, 2027. That gives organizations an 18-month implementation window, of which roughly 9 months remain as of the time of writing.
The Consent Manager framework becomes operational on November 13, 2026, which is the most concrete intermediate deadline. Penalty provisions, with maximums reaching Rs. 250 crore, are enforceable from the same date.
Most compliance programs are spending their time on Layer 1: the documents. The companies that will be genuinely prepared are the ones investing in Layers 2 through 6: the infrastructure, the engineering, the systems architecture that makes the promises in the documents actually operational.
DPDP compliance is not a legal project with some engineering support. It is an engineering project with some legal inputs. The sooner organizations recognize that distinction, the more effectively they will use the time they have left.
Privra is an AI-native firm that helps companies processing Indian personal data achieve continuous DPDP compliance, from infrastructure audits to consent architecture to ongoing drift detection. If you want to understand where your compliance gaps actually are, talk to us.