DPDP Act for Engineers: India's Data Residency Architecture

For three years the standard engineering posture toward India's data-protection law was to wait. The Digital Personal Data Protection Act was passed in August 2023, but with no operative rules it had no teeth an architect had to design against. That waiting period is over. On 13 November 2025 the Ministry of Electronics and IT notified the Digital Personal Data Protection Rules, 2025, and with them a phased commencement schedule: the Data Protection Board of India stood up immediately, the consent-manager regime becomes live twelve months out, and the substantive compliance obligations — security safeguards, breach notification, retention limits, Significant Data Fiduciary duties, and cross-border controls — become enforceable on 13 May 2027. Roughly ten months of runway from the time of writing: enough to build correctly, not twice.

This article is the engineering read of that regime — not a legal summary; your counsel will produce a more precise register of obligations than anything here. It is the translation layer between that register and the infrastructure: which clause forces a decision about node topology, which about who signs the encryption keys, which you cannot unwind cheaply later. The theme is the one Stribog holds across every regime, from the EU's NIS2/DORA/AI-Act convergence onward: a compliance guarantee is only as strong as the technical control underneath it, and a control an auditor can verify beats one taken on trust.

The DPDP Act is also distinct from its EU cousins in a way that matters architecturally. Where the GDPR restricts cross-border flow by default and permits it only to adequate jurisdictions, the DPDP Act permits flow by default and restricts it only where the government says so. That permissiveness is a trap: it invites teams to leave data wherever it sits, until a Significant Data Fiduciary designation or a category-specific localization notification makes that placement illegal overnight. The right response is not to localize everything today — it is to build so that localizing any data category tomorrow is a configuration change, not a re-platforming project. Selling into government widens the same requirement further, since MeitY empanelment and the cloud-selection framework fix the substrate before a contract exists.

The Act Is Now a Deadline: What Commences and When

The DPDP Rules 2025 commence in three phases, and the phasing changes what you build first. Phase one, on notification (13 November 2025), stood up the Data Protection Board of India and its procedural machinery. Phase two, twelve months out (13 November 2026), brings the consent-manager regime — Board-registered intermediaries for granting and withdrawing consent across fiduciaries — into force. Phase three, eighteen months out (13 May 2027), governs your architecture: security safeguards, the two-stage breach-notification duty, retention and erasure limits, Significant Data Fiduciary obligations, and cross-border controls all become enforceable together.

The vocabulary maps onto system boundaries. A Data Principal is the individual the data is about — the data subject, in GDPR terms. A Data Fiduciary determines the purpose and means of processing — the controller, almost certainly you. A Data Processor processes on the fiduciary's behalf under contract — your sub-processors, managed services, and third-party APIs. Accountability sits with the Data Fiduciary and does not transfer to a processor: if your payments vendor leaks a Data Principal's records, the regulator's enquiry lands on you. That is why the sub-processor chain must be a first-class artifact in your architecture, not a spreadsheet updated once a year.

Click to zoom

Residency Is an Enforcement Problem, Not a Policy Promise

The phrase "our data stays in India" is, in most deployments, a statement about a contract, not about the system. It usually means the primary bucket is region-pinned and the vendor's terms assert residency. Neither fact constrains where a replica, backup, log line, cache, or support engineer's export actually travels. Rule 6 of the DPDP Rules — reasonable security safeguards — requires appropriate technical measures including encryption in transit and at rest, access control, and logging sufficient to detect and investigate a breach. Rule 6 does not itself mandate localization, but it makes the fiduciary responsible for knowing and controlling where protected data flows — control you assert from the platform, not a contract.

Enforced residency is a property of five layers the platform owns. Classification tags personal data and its traffic data at ingress. Placement pins workloads and volumes to nodes physically in India — a Mumbai or Hyderabad colo, or a verified India region. Admission control refuses to schedule anything that violates placement. Egress control removes the network path by which data could cross a border at all. And key custody ensures that anything which does leave — a replicated backup, a mis-routed export — is ciphertext no one outside your jurisdiction can read. Miss one layer and the guarantee has a hole an auditor will find.

Click to zoom

The admission layer is where policy-as-code earns its place. On Kubernetes, a Kyverno or OPA admission policy can reject any workload that would land personal data outside the residency boundary — a PVC on a StorageClass not backed by in-India storage, a Pod without the topology pin to an India region, or a workload lacking the data-classification label the pipeline depends on. The policy is the control; the PolicyReport it emits is the audit evidence — both from the same mechanism.

# Kyverno ClusterPolicy — refuse to place classified personal data outside India.
# Enforced at admission; the PolicyReport it emits is the audit artifact.
# Region allow-list uses real topology.kubernetes.io/region codes, not "in-*".
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: dpdp-data-residency
  annotations:
    dpdp-control: "Rule 6 reasonable security safeguards; residency enforcement"
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: personal-data-must-pin-to-india
      match:
        any:
          - resources:
              kinds: ["Pod"]
      preconditions:
        all:
          - key: "{{ request.object.metadata.labels.\"data-classification\" || '' }}"
            operator: Equals
            value: "personal-data"
      validate:
        message: "Personal-data workloads must pin nodeSelector topology.kubernetes.io/region to an India code."
        deny:
          conditions:
            all:
              - key: "{{ request.object.spec.nodeSelector.\"topology.kubernetes.io/region\" || '' }}"
                operator: AnyNotIn
                value: ["ap-south-1", "ap-south-2", "centralindia", "southindia", "asia-south1", "in-mumbai", "in-hyderabad"]
    - name: personal-data-storageclass-must-be-in-india
      match:
        any:
          - resources:
              kinds: ["PersistentVolumeClaim"]
      validate:
        message: "PVCs holding personal data must use an in-India-backed StorageClass."
        deny:
          conditions:
            all:
              - key: "{{ request.object.metadata.labels.\"data-classification\" || '' }}"
                operator: Equals
                value: "personal-data"
              - key: "{{ request.object.spec.storageClassName }}"
                operator: AnyNotIn
                value: ["ceph-mumbai-block", "ceph-hyderabad-block", "in-south1-ssd"]

Who Holds the Keys Decides Who Holds the Data

Encryption at rest is table stakes under Rule 6, but the property that determines residency is key custody, not ciphertext location. If data sits in India while the keys live in a foreign-parent provider's managed service, the plaintext is reachable by whoever can compel that provider. Hold the keys instead in a hardware security module inside your jurisdiction, and ciphertext that escapes the boundary is inert — crypto-shredding (destroying the key rather than chasing every copy) is residency of last resort: you cannot prove no copy crossed a border, only that no readable copy did.

The architecture is a self-hosted key layer: HashiCorp Vault Enterprise (HSM module) or OpenBao fronting an HSM physically in India, with envelope encryption so data keys are wrapped by a key-encryption-key that never leaves the module. PKCS#11/HSM auto-unseal is Enterprise-only on Vault; on the community side use OpenBao, whose PKCS#11 seal is not licence-gated. Workloads fetch data keys at runtime through the External Secrets Operator or Vault Agent, never embedding key material in images or manifests. When a category is later localized, enforcement is already in place: delete the category transit key (after setting deletion_allowed=true on its /config), keep successor keys India-resident, and prior offshore ciphertext becomes permanently unreadable. This is the optionality pillar in cryptography — change a whole data class's residency posture without touching the applications that use it.

# Vault Enterprise or OpenBao transit sealed by India-resident HSM (PKCS#11).
# Community Vault cannot use PKCS#11 seal. KEK never leaves the module;
# crypto-shred a category = delete its transit key (deletion_allowed first).
seal "pkcs11" {
  lib            = "/usr/lib/softhsm/libsofthsm2.so"   # prod: Thales/Utimaco in-IN
  slot           = "0"
  key_label      = "vault-kek-in-mumbai"
  hmac_key_label = "vault-hmac-in-mumbai"
}

# One transit key per DPDP data category — category-scoped crypto-shred.
# $ vault secrets enable transit
# $ vault write -f transit/keys/pd-financial type=aes256-gcm96
# $ vault write -f transit/keys/pd-health    type=aes256-gcm96

# App encrypts via Vault; plaintext keys never touch the pod filesystem.
# $ vault write transit/encrypt/pd-financial plaintext=$(base64 <<< "$RECORD")

# Residency-of-last-resort: enable deletion, then delete the category key to render every
# offshore copy unreadable. Leave deletion_allowed=false until the shred is authorised.
# $ vault write transit/keys/pd-financial/config deletion_allowed=true
# $ vault delete transit/keys/pd-financial

The Significant Data Fiduciary Tier and the Localization Lever

The DPDP Act reserves a heavier obligation set for entities the Central Government designates Significant Data Fiduciaries, on volume and sensitivity of data processed, risk to Data Principals, and impact on sovereignty. An SDF must appoint a Data Protection Officer resident in India and answerable to its board — not outsourced or held by a foreign-resident executive — appoint an independent data auditor, and run a Data Protection Impact Assessment and audit every twelve months, reporting significant observations to the Board. These are not paperwork: the DPIA and audit both consume evidence your platform must produce on demand.

This is where the negative-list design becomes an architectural forcing function rather than a convenience. The right posture is a residency boundary that is classification-driven and switchable: every record carries a category label from ingress, and the enforcement layers — placement, admission, egress — read it. Localizing a category then means changing which categories egress permits offshore, not rebuilding the data path. The network layer is where this switch physically lives: default-deny egress with a Cilium egress gateway means no cross-border path exists unless you explicitly create one, per namespace, per category.

# Default-deny egress, then narrow allow-lists — no cross-border data path
# unless explicitly created. Localizing a category = removing its egress rule.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-cross-border-egress
  namespace: pd-financial            # namespace scoped to one DPDP data category
spec:
  endpointSelector:
    matchLabels:
      data-classification: personal-data
  egressDeny:
    # Block egress to everything outside the in-India CIDR set.
    - toCIDRSet:
        - cidr: 0.0.0.0/0
          except:
            - 10.0.0.0/8             # in-cluster / in-IN colo fabric
            - 100.64.0.0/10          # in-IN private interconnect
  egress:
    # DNS must be allowed explicitly under default-deny egress.
    # Omit rules.dns so port 53 to kube-dns permits all queries. If you add L7
    # DNS filtering later, Cilium treats * as one label (not across "."): real
    # service FQDNs need matchPattern "*.*.svc.cluster.local" (or matchPattern
    # "*" for unrestricted DNS) — see Cilium Layer 7 DNS policy docs.
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
    # Only in-India datastores and the in-India audit sink are reachable.
    - toEndpoints:
        - matchLabels:
            app: postgres-mumbai
    - toEndpoints:
        - matchLabels:
            app: audit-log-store-in
---
# When the SDF localization notice lands for financial data, the offshore
# egress rule for pd-financial is never added (or is removed). The boundary
# was always a switch — nothing to re-architect.

Cross-Border Transfer: The Negative List and Why It Is Not Reassurance

Section 16 sets a permissive baseline: a Data Fiduciary may transfer personal data to any country except those the Central Government restricts by notification. As of mid-2026 none has been notified, so general cross-border flow is broadly lawful — strikingly liberal next to the GDPR, which forbids transfer unless the destination is adequate or covered by a safeguard. The Rules add that transfers remain subject to conditions the government may impose by order. Accountability does not transfer with the data: the fiduciary remains answerable after it crosses the border.

A permissive rule is not reassurance, because it sits over sectoral localization that already binds and the SDF lever that can bind at any time. India's payments regulator has required payment-system data to be stored only in India since 2018, and the RBI and SEBI cloud instruments layer supervisory-access and exit duties on top of that; insurance and other regulated domains add their own residency constraints. A fintech is therefore already under hard localization for a slice of its data before DPDP's category mechanism even activates. The engineering conclusion matches the cloud-repatriation playbook from the DORA exit-strategy angle: you must demonstrate and exercise keeping a defined data class inside a jurisdiction — not merely assert you could if asked.

The Dual-Clock Breach Reality: CERT-In's Six Hours, DPDP's Seventy-Two

An Indian Data Fiduciary that suffers a breach runs two clocks at once, set to very different times. The DPDP Rules operationalize a two-stage notification to the Board: an initial intimation without delay the moment the fiduciary becomes aware of a breach, then a detailed report within seventy-two hours covering the facts, extent, cause where known, and mitigation. Affected Data Principals must also be notified without delay in plain language — what happened, what data, what they can do, how to reach you. Separately and earlier, the CERT-In Directions of April 2022 require specified cyber incidents to be reported within six hours of noticing them. One incident can trigger both, on clocks that start together but expire hours apart.

The engineering implication is that breach response cannot depend on evidence you must request from a vendor: if your logs live in a third party's managed service, the six-hour CERT-In clock can expire while you are still filing a support ticket. So the forensic evidence has to sit inside your perimeter, in an append-only store you control. CERT-In separately requires a rolling 180 days of security logs — the Directions say maintained within Indian jurisdiction, while CERT-In's own FAQ Q35 asks whether a copy must sit in India *only* and answers that logs may *also* be stored abroad if producible on demand in reasonable time — wording that reads more naturally as an additional-copy allowance than a substitute for the India-based copy, on a document that disclaims being able to amend the Directions in the first place — with Q36 carving out financial-transaction logs, which must sit in Indian jurisdiction regardless — and the DPDP Rules layer two distinct one-year floors on top of that: Rule 6(1)(e), part of the reasonable-security-safeguards duty, requires retaining logs and personal data for one year to enable detection, investigation, and remediation of unauthorised access and continued processing during a compromise; Rule 8(3) separately requires retaining personal data, traffic data, and processing logs generally for a minimum of one year from the date of processing — both retention floors sit against the Rule 8(1)–(2) erasure timeline and must be reconciled per data class. The self-hosted observability and audit stack that keeps telemetry inside your perimeter is, in the Indian context, not a cost choice — it is what makes the six-hour clock survivable.

# In-India Ceph RGW audit sink. Object Lock must be enabled at create —
# PutObjectLockConfiguration alone fails with InvalidBucketState (409) on
# RGW if the bucket was not created lock-enabled (docs.ceph.com radosgw/s3).
# Versioning is required with Object Lock. A bare ObjectBucketClaim creates
# a normal mutable bucket and does not enable lock. PVCs/annotations enforce nothing.
# CERT-In (>=180d in-IN) + DPDP Rule 6/8 (logs + personal data, >=1 year).
#
# 1) Create the bucket WITH Object Lock enabled (S3: x-amz-bucket-object-lock-enabled):
aws s3api create-bucket \
  --bucket audit-log-store-in \
  --endpoint-url https://rgw.in.example \
  --object-lock-enabled-for-bucket
#
# 2) Then set COMPLIANCE default retention (>=400 days covers 180d + 1y headroom):
aws s3api put-object-lock-configuration \
  --bucket audit-log-store-in \
  --endpoint-url https://rgw.in.example \
  --object-lock-configuration \
  'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=400}}'
#
# Integrity job: --assert-retention=180d --assert-in-region=IN --assert-object-lock

Deployment Models Against the Requirements

Not every deployment model can satisfy the DPDP and CERT-In control set by design, and the gaps are predictable. A US-parent hyperscaler's India region can pin storage and even hold logs in-country, but its control plane, key management, and sub-processor chain remain partly offshore and opaque — and it carries the same foreign-government-access exposure the EU compliance analysis identifies for the CLOUD Act. An India-incorporated cloud running managed Kubernetes resolves the legal-layer exposure and holds logs and keys in-country, but leaves the control plane with the provider. Self-hosted infrastructure in an Indian colo — your own Kubernetes, HSM, and network — is the only model green on every row, at the cost of the operational burden.

Click to zoom

The gap map is not an argument that every workload belongs on bare metal in Mumbai — it is a decision instrument. Data classes with no localization exposure and low sensitivity can sit on a managed India region with contractual residency and lose little. The classes that fall, or plausibly will, under the SDF localization lever, sectoral localization, or the highest breach-penalty exposure are where green versus amber is the difference between a defensible control and a promise. Place workloads by regulatory exposure, not uniformly; the stateful data layer and the object storage behind it most reward being brought fully in-house.

The Long Game: Build the Boundary Before You Are Told To

The DPDP regime will not stand still: the Rules were three years behind the Act, and the first category-localization notification, the first SDF designations, and the first enforcement orders are all ahead of us. An architecture optimized for the exact text of the Rules as they read in mid-2026 will need rework each time the surface shifts; the one that endures is built on the invariant beneath the clauses — personal data whose placement, encryption, egress, and audit trail are properties of a platform you operate, controls an auditor can verify and an engineer can change with a pull request. That is the long-game posture Stribog brings to every regime: do not chase the regulation, build the sovereignty that makes it a configuration concern. A team that has already made its residency boundary a switch absorbs the next notification as a diff; one that treated residency as a contract clause absorbs it as an incident. The ten months to 13 May 2027 are enough to be the first kind of team — if building starts from the infrastructure, not the policy PDF.