DPDP Compliance for Engineering Teams

Your legal team told you the company needs to be DPDP compliant. They handed you a privacy policy to publish and a checklist that includes things like "implement consent management" and "enable data subject rights." Now the work sits on your team, and none of the guides you've read describe what to actually build.

This is that guide. If you run a B2B SaaS product, start with DPDP Compliance for Indian SaaS Companies for the dual Fiduciary/Processor model and multi-tenant erasure specifics.

DPDP compliance for engineering teams is a specific set of technical deliverables. Not policies. Not workflows. Actual code, actual infrastructure, actual instrumentation. This post breaks down what those deliverables are, mapped to the DPDP sections that require them, at a depth an engineering team can execute against.

The framing throughout: DPDP is a systems architecture problem, not a legal one. The team that owns it is you, not the general counsel. Your role is to build the systems that let the company make and keep the promises the privacy policy is claiming.

The engineering deliverables, mapped to DPDP obligations

Below is the full stack, in the order we recommend building it. Each layer depends on the ones below it.

Layer 1: Data discovery and mapping

What DPDP requires: Sections 5, 8(3), 8(7), 11, 12. You must know what personal data you hold, where it lives, and how it flows to fulfil notice, accuracy, erasure, access, and breach obligations.

What to build:

Automated PII discovery. A scanner that runs on a defined cadence (weekly minimum, on-deploy ideal) across every environment holding data:

• Production databases (Postgres, MySQL, MongoDB, DynamoDB)
• Analytics warehouses (BigQuery, Snowflake, Redshift)
• Object storage (S3, GCS, Azure Blob)
• Backup systems
• Logging infrastructure (CloudWatch, Datadog, Sentry)

Detection engine combining three methods:

1. Column-name heuristics (catches masked/tokenized data)
2. Regex validation for India-specific identifiers (Aadhaar with Verhoeff checksum, PAN format, UPI, GSTIN, IFSC)
3. NER-based detection for unstructured text fields

A Record of Processing Activities (RoPA) database. Not a spreadsheet. A queryable data model that captures, for every PII location: data element, purpose of collection, lawful basis, retention period, processors receiving it, cross-border transfer status, deletion procedure, owner. This becomes the source of truth for every downstream compliance workflow. For the engineering walkthrough, see how to discover every place personal data lives.

Change detection. Alerts when new PII appears in unexpected locations, when a new column matches PII patterns, when a new S3 bucket is created without lifecycle policies. Every deployment can introduce compliance drift; you need instrumentation to catch it.

Rough scope: 4 to 8 weeks of engineering time for initial build, plus ongoing operations.

Layer 2: Consent architecture

What DPDP requires: Sections 5, 6(1), 6(3), 6(4), 6(8). Consent must be free, specific, informed, unconditional, unambiguous, with clear affirmative action. Notice must be in 23 languages. Withdrawal must be as easy as giving consent. Consent must propagate to every processor.

What to build:

A consent event ledger. Every consent event stored with timestamp, Data Principal identifier, purpose, notice version, language shown, and the specific action taken (granted, withdrawn, modified). Immutable append-only log. This is the audit evidence the Data Protection Board will actually request.

A purpose-based consent model. Consent is not "user agreed." It is "user agreed to purpose X at time T with notice version V." Every processing activity in your system must be tied to a specific purpose in this model. If a processing activity has no matching consent record, that activity is unauthorized.

Consent propagation infrastructure. This is the hardest engineering deliverable. When consent state changes, every downstream system needs to know. Practical approach:

• Emit consent events to a message bus (Kafka, SNS, EventBridge)
• Every service that processes personal data subscribes to consent events for its purpose
• Services check consent state on every processing operation, or cache it with a short TTL
• Third-party processors receive consent updates via API calls to their consent endpoints (Sendgrid unsubscribe API, Segment DELETE endpoint, marketing platform preference APIs)

Notice delivery in 23 languages. For consent, DPDP Section 6(3) requires the notice to be available in English and every language in the Eighth Schedule. Options:

• Build a translation pipeline (typically using a language model or translation service, then human review for legal accuracy)
• Integrate a Consent Manager that handles multilingual notice delivery
• At minimum, cover English, Hindi, and your top 3 regional user languages, with English as fallback

Withdrawal parity. If signup uses one click, withdrawal must be one click. Not buried in account settings. Not requiring a support ticket. Build a "manage my data" page accessible from the user's account with equal prominence to the signup flow.

Consent Manager integration (needed by November 13, 2026). The Consent Manager framework (Section 6(8)) requires the ability to receive and propagate consent from India-incorporated registered Consent Managers. Build the API layer to accept Consent Manager-delivered consent events and treat them equivalently to direct consent.

The full build sequence — ledger schema, purpose taxonomy, capture UX, propagation, withdrawal, and Consent Manager ingestion — is in DPDP Consent Management: Complete Implementation Guide.

Rough scope: 8 to 16 weeks of engineering time, largely dependent on how many downstream processors you have.

Layer 3: Rights fulfilment

What DPDP requires: Sections 11, 12, 13, 14. Data Principals have the right to access their data, correct it, request erasure, seek grievance redressal, and nominate someone to exercise rights on their behalf.

What to build:

A DSR (Data Subject Request) portal. Not an email address. A self-serve interface where users can:

• Request a complete export of their personal data
• Request correction of specific fields
• Request erasure of their account and associated data
• File a grievance and track its resolution
• Nominate a nominee

A DSR orchestration engine. When a user submits a request, the system:

1. Verifies the user's identity (typically via re-authentication + additional verification for high-risk requests)
2. Queries the data map to find every location holding the user's data
3. Executes the request across every location (parallel execution, with retry logic for failed calls)
4. Collects deletion confirmations from third-party processors
5. Compiles evidence: what was done, when, by which system
6. Notifies the user within the mandated timeline

Third-party processor delete endpoints. For every processor in your data map, know their deletion mechanism:

• Sendgrid: Suppression API
• Segment: DELETE /v1/workspaces/{workspace}/regulations for GDPR-style deletes (also works for DPDP)
• Mixpanel: /api/2.0/engage/delete
• Klaviyo: Data Deletion API
• Freshdesk / Intercom: Contact deletion API
• Razorpay: Customer data deletion request
• AWS: S3 object delete + versioning cleanup

For each, wrap the vendor's API in a consistent internal interface. Your orchestrator calls the internal interface; the interface handles vendor-specific quirks.

Retention automation. Under Section 8(7), you must proactively erase data when the purpose is fulfilled, even without a user request. This requires:

• Retention policies defined per data category (aligned to the RoPA)
• Automated cleanup jobs that enforce retention (S3 lifecycle policies, DB scheduled deletes, DynamoDB TTL)
• Legal-hold override mechanism for data that must be retained for tax, KYC, or regulatory reasons

Grievance tracking. A ticketing system for grievances with:

• 90-day SLA enforcement (mandated by DPDP Rules)
• Escalation to Grievance Officer
• Escalation to Data Protection Board if resolution fails

Nominee handling. A workflow for verifying a nominee's identity and letting them exercise rights on behalf of a deceased or incapacitated Data Principal. Low-frequency but the requirement exists (Section 14).

Rough scope: 6 to 12 weeks of engineering time, depending on the number of third-party processors requiring integration.

Layer 4: Breach detection and notification

What DPDP requires: Section 8(6), Rule 7. Report personal data breaches to the Data Protection Board and every affected Data Principal within 72 hours. No materiality threshold. India also has CERT-In's 6-hour cybersecurity incident reporting rule that runs in parallel.

What to build:

Anomaly detection on data access. Real-time monitoring of:

• Unauthorized database queries (queries outside normal access patterns)
• Bulk exports (large SELECT queries, mass S3 downloads)
• Unusual API access (spikes in requests to user data endpoints)
• Credential-based access anomalies (logins from unusual locations, unusual hours)

A breach classification workflow. When a security incident is detected, the workflow must determine:

• Was personal data affected? (If yes: DPDP triggered)
• Was any cybersecurity incident involved? (If yes: CERT-In triggered)
• Which Data Principals were affected? (Query the data map to find users whose data was in the affected system)
• What data categories were involved?
• Estimated volume of affected records

Pre-populated notification templates. For both DPB and Data Principal notifications, aligned to Rule 7 field requirements:

• Nature and scope of breach
• Type of data affected
• Number of Data Principals affected (with categories)
• Timing and location
• Consequences that could arise
• Measures taken

Templates need to be operational in your incident response tooling so they can be filed within the 72-hour window. Do not draft them during an incident.

Parallel notification pipelines. One workflow for CERT-In (6-hour), one for DPB (72-hour), one for affected Data Principals (concurrent with DPB filing). Automate as much as possible; the last thing you want is a manual notification process during a breach.

A tabletop exercise cadence. Quarterly breach simulations that test the full pipeline end-to-end. Most breach notification failures are not detection failures; they are notification pipeline failures under real time pressure.

Rough scope: 4 to 8 weeks for initial build, plus ongoing operations. Aim to run first tabletop exercise within 90 days of go-live.

Layer 5: Security safeguards

What DPDP requires: Section 8(5), Rule 6. Reasonable security safeguards to protect personal data.

What to build (or verify):

• Encryption at rest for every data store containing personal data
• Encryption in transit (TLS 1.2+ for all API traffic, mutual TLS for internal service-to-service where feasible)
• Access controls enforcing least privilege (IAM roles, RBAC, no shared credentials, MFA for all human access to production)
• Audit logging for every access to personal data, retained for a minimum of one year per Rule 6
• Regular vulnerability scanning and patching cadence
• Backup security (encrypted, access-controlled, tested restore procedures)
• Network segmentation isolating databases from public internet, with private subnets and bastion hosts for admin access
• Secret management (not hardcoded credentials, rotation policies)

Most engineering teams have some of this. The DPDP-specific requirement is documented evidence that these controls exist and are operational. That evidence is what Rule 6 asks for.

Rough scope: Varies enormously by starting maturity. Most companies need 2 to 6 weeks of hardening work plus ongoing operations.

Layer 6: Continuous compliance instrumentation

What DPDP requires: Implicit across the whole Act. Compliance is a state you maintain, not achieve.

What to build:

Compliance drift detection. Automated checks that run on every deployment:

• Is a new PII column being added without RoPA update?
• Is a new S3 bucket being created without lifecycle policy?
• Is a new third-party integration being added without vendor DPA review?
• Is a new API endpoint being added that returns personal data without consent verification?

Compliance dashboards. Real-time view of:

• Consent capture rates
• DSR request queue and SLA status
• Breach notification readiness (last tabletop, current mean time to notification)
• Data map coverage (percent of production data stores scanned in last 30 days)
• Third-party processor DPA status (percent with executed DPA, expiration dates)

Regulatory change monitoring. DPDP Rules will evolve. New sub-regulations will be published. Sectoral overlays (RBI, SEBI, IRDAI) will change. Someone or something needs to monitor these and translate them into engineering tickets.

Rough scope: 4 to 8 weeks for initial instrumentation. Ongoing.

The org design question

DPDP compliance for engineering teams cannot be a side project for a rotating cast of engineers. It needs an owner.

Options:

Option A: Privacy Engineer as a dedicated role. Common in enterprise. One or more engineers with primary responsibility for the compliance stack. Reports to CTO or DPO.

Option B: Platform team ownership. Compliance infrastructure sits with the platform or infra team as one of many concerns. Works for smaller companies where platform team has bandwidth.

Option C: Cross-functional working group. Engineers from product, platform, and security rotate through compliance work. Least effective. Nobody owns the tail work of maintaining coverage, evidence, and drift detection.

Option D: Outsourced to an AI-native compliance firm. The operational layer (Layer 1 discovery, Layer 6 drift detection, evidence generation) can be managed externally with AI agents plus expert review. Your team owns the integration points and the remediation execution.

For most Indian startups and mid-market companies, Option D is the most cost-effective path. It removes 60% of the ongoing operational burden from your engineering team while keeping the strategic and remediation work in-house.

The order of build: what to prioritize if you have limited time

If you have 90 days:

1. Data discovery and RoPA (Layer 1). Everything else depends on it.
2. Basic consent capture with proper affirmative action and unbundling (partial Layer 2).
3. Manual DSR fulfilment workflow with tracking (partial Layer 3).
4. Breach notification templates ready to file (partial Layer 4).
5. Verify existing security safeguards meet Rule 6 (Layer 5).

If you have 6 months, add: 6. Consent propagation infrastructure (full Layer 2). 7. Automated DSR orchestration (full Layer 3). 8. Anomaly detection for breach precursors (full Layer 4).

If you have 12 months: 9. Continuous compliance instrumentation (Layer 6). 10. Consent Manager integration (Layer 2 completion). 11. Tabletop exercise cadence established.

By May 2027 you need all six layers operational.

The most common engineering failure modes

Failure 1: Building consent capture without consent propagation.

You add a "Manage Preferences" page. It updates a boolean in the users table. Every downstream system keeps processing as if consent is still granted, because none of them know about the boolean. This is the single most common engineering gap we see. Consent state that doesn't propagate is consent theater.

Failure 2: Building erasure without processor reach.

You build a "delete my account" flow. It nulls the users table row. Sendgrid still has the email. Segment still has the events. Mixpanel still has the profile. Your primary database is clean; your ecosystem is not. This is a Section 12 violation.

Failure 3: Confusing DSR fulfilment with data export.

You interpret Section 11 as "let users download their data." That is one piece. The full requirement is a complete accounting of what data you hold, from every source. Missing systems in the export is a compliance failure even if the report format looks clean.

Failure 4: Treating retention as a documentation exercise.

Your retention schedule says "delete after 90 days." Nothing in your infrastructure actually enforces that. The data sits there. When an auditor asks for evidence of deletion, there is none. Retention must be automated, not documented.

Failure 5: Underestimating the third-party surface.

You catalog 8 vendors. There are 34. The ones you missed include the analytics tool a marketing intern connected via Zapier, the AI content tool your product team is testing, the old A/B testing platform that was never fully disconnected. Every one is a compliance surface.

The self-audit for engineering leaders

Answer these honestly:

1. If a user submits an erasure request right now, how many systems does your team need to touch, and how long will it take?
2. Can you produce a list of every column in every database that contains personal data, updated in the last 30 days?
3. If your marketing tool receives a consent withdrawal event today, will it stop processing that user's data within a reasonable time?
4. If a breach is detected in production at 2 AM Saturday, what happens between then and 74 hours later (the DPB deadline)?
5. When your team ships a new feature that adds a personal data field, what triggers a compliance review?

If the answer to any of these is "we would need to figure that out," that is your priority engineering work.

Where Privra fits

Privra is built by engineers, for engineers. Our AI agents run the operational compliance layer (Layer 1 discovery, Layer 4 breach detection, Layer 6 drift monitoring) as a continuous service. Your team owns the integration points and the remediation calls. We handle the tail work of keeping the data map current, catching new PII locations before they become gaps, and generating the evidence trail that survives audit.

The result: your engineering team focuses on shipping product, not maintaining a compliance program.

Talk to us about your DPDP engineering plan.