Privacy by Design Is Not a Checkbox: What the DPDP Act Requires from Your Data Architecture

Privacy by design is in the DPDP Act. Most engineering leaders treat it as aspiration. It is not — it is a set of architectural obligations flowing from your ROPA, and most BFSI data architectures are not compliant today.

Four architecture decisions DPDP mandates

The DPDP Act does not prescribe specific technologies. It prescribes outcomes — and those outcomes require four specific architecture decisions that most BFSI engineering teams have not yet made.

1. Data minimisation at ingestion. Section 6 of the Act requires that personal data collected must be limited to what is necessary for the stated purpose. For engineering teams, this means ingestion pipelines cannot vacuum up every available field "in case we need it later." A KYC onboarding flow that captures browsing behaviour, device fingerprints, and location data alongside PAN and Aadhaar is collecting data beyond what the stated purpose (identity verification) requires. The architecture must enforce field-level filtering at the point of collection — not downstream.

2. Purpose binding. Every personal data element must be tagged with the processing purpose for which it was collected. When a customer provides their mobile number for OTP verification during account opening, that number cannot be passed to the marketing platform for promotional SMS without separate, specific consent. Purpose binding is not a policy — it is a data attribute that must travel with the record.

3. Retention enforcement. The Act requires that personal data be erased when the purpose for which it was collected has been fulfilled. A retention policy document in a SharePoint folder is not enforcement. Enforcement means automated scheduled jobs that identify records past their retention period, execute deletion or anonymisation, and log the action with timestamps. The logs are your evidence that the obligation was met.

4. Consent linkage. Every processing activity in your ROPA must trace back to a lawful basis — most commonly, consent. The consent record (who consented, to what, when, via which notice) must be queryable and linkable to the processing activity. When a data principal withdraws consent, your systems must be able to identify every downstream process that relied on that consent and cease processing. This is an architectural requirement, not a manual workflow.

The data lake problem

Most BFSI organisations have invested heavily in data lakes and analytics platforms over the past decade. Customer data flows from core banking systems, CRM platforms, mobile apps, and third-party enrichment providers into centralised repositories — often with minimal metadata about why the data was originally collected.

This creates a fundamental DPDP compliance problem. When KYC data collected for identity verification under RBI norms flows into a marketing analytics pipeline, the processing purpose has changed. Under the DPDP Act, this requires separate consent. But the data lake does not know — and cannot know — that the data arrived under a KYC consent basis, because that metadata was stripped during ingestion.

The solution is not to stop using data lakes. It is to ensure that processing context — the purpose, consent basis, and retention period — travels with the data. This requires column-level metadata tagging at ingestion and purpose-aware access controls on the lake itself. Queries that access personal data must declare which processing purpose they serve, and the platform must validate that purpose against the consent record.

For most BFSI data architectures, this is a significant retrofit. It requires changes to ETL pipelines, data catalogue tooling, and access control layers. The engineering effort is real — but the alternative is operating a data platform that systematically violates purpose limitation, one of the Act's core principles.

Vendor processor obligations CTOs own

Every third-party API that processes personal data on your behalf is a "data processor" under the DPDP Act. The Act requires that data fiduciaries ensure processors implement appropriate security safeguards and process data only for the purposes specified.

CTOs manage these relationships as API keys, SDK integrations, and service contracts. But under the DPDP Act, they need to be managed as legal instruments — each requiring a Data Processing Agreement (DPA) that specifies what data is shared, for what purpose, retention limits, breach notification obligations, and sub-processor controls.

Consider the typical BFSI technology stack. Payment processors receive transaction data including card numbers and account identifiers. Analytics SDKs receive behavioural data from mobile apps. Cloud providers host databases containing customer records. Email service providers receive customer contact details. Each of these is a processing relationship that requires documented controls.

The CTO's obligation is not just to have DPAs in place — it is to ensure that the technical integration enforces the DPA terms. If the DPA says the processor will delete data within 30 days of service termination, the CTO needs to verify that the API supports deletion and that the deletion is actually executed. If the DPA says the processor will not use the data for their own purposes, the CTO needs to understand the processor's data practices well enough to validate that claim.

Most BFSI organisations have dozens of these relationships. Documenting them in the ROPA, maintaining current DPAs, and verifying compliance is an ongoing operational task — not a one-time exercise.

Practical implementation patterns

The architectural changes required for DPDP compliance are significant but tractable. Here are four patterns that engineering teams can implement incrementally.

Column-level tagging. Add metadata columns or tags to personal data fields in your primary data stores. At minimum, each personal data column should carry: data category (identity, financial, biometric, behavioural), processing purpose (the ROPA activity it belongs to), retention period (in months), and sensitivity classification (normal, sensitive, children's data). This metadata enables automated retention enforcement and purpose-aware access controls.

Consent reference IDs in transaction records. When processing is based on consent, store the consent record ID alongside the transaction data. This creates an auditable link between the processing activity and the lawful basis. When consent is withdrawn, you can query all records linked to that consent ID and take appropriate action (deletion, anonymisation, or cessation of processing).

Retention TTL via scheduled jobs. Implement automated retention enforcement using scheduled jobs (cron, Airflow, or equivalent). Each job targets a specific data category and retention period. The job identifies records past their retention date, executes the defined action (delete or anonymise), and writes an execution log with record counts, timestamps, and any exceptions. The execution logs become your evidence for retention compliance.

Audit log coverage for personal data access events. Extend your application audit logging to capture every access event involving personal data. Log the user, timestamp, data category accessed, purpose declared, and records affected. This is not just a security control — it is evidence that your access controls are functioning and that data is being accessed only for documented purposes. The audit logs feed directly into your assurance evidence vault.