The DPDP Act for Engineers: Data Residency Architecture, Not Policy

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. That is roughly ten months of runway from the time of writing. It is enough to build correctly and not enough to build 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.

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 (14 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), is the one that 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 is worth pinning down because it 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, a backup, a log line, a cache, or a 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 from 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 colocation facility, 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 referencing a StorageClass not backed by in-India storage, a Pod without the topology constraint pinning it to an India zone, 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.
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 to an in-India zone (topology + region label)."
        pattern:
          spec:
            nodeSelector:
              topology.kubernetes.io/region: "in-*"    # ap-south / on-prem "in-*" zones only
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution: "?*"
    - 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 — which makes crypto-shredding (destroying the key rather than chasing every copy) a viable residency-of-last-resort control: you can never prove no copy crossed a border, but you can prove no readable copy did.

The architecture is a self-hosted key layer: HashiCorp Vault (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. 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: rotate the KEK, keep the new one India-resident, and prior offshore ciphertext becomes permanently unreadable. This is the optionality pillar in cryptography — you change the residency posture of a whole data class without touching the applications that use it.

# Vault transit engine sealed by an India-resident HSM (PKCS#11).
# The KEK never leaves the module; crypto-shred a category = delete its transit key.
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 — enables 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: rotate then delete the category key to render every
# offshore copy unreadable.  $ 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 the 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 to a vendor 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 line items: 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: a default-deny egress posture 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 — so no cross-border data path
# exists 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:
    # 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, say, financial data, the offshore
# egress rule for pd-financial is simply never added (or 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 for it 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; 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 be able to 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 for access. So the forensic evidence has to sit inside your perimeter, in an append-only store you control. CERT-In separately requires security logs be kept within Indian jurisdiction for a rolling 180 days, and the DPDP retention rule requires certain traffic and processing logs be kept for at least a year. 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, append-only audit + security-log store sized for the dual clock:
# CERT-In (>=180 days, in Indian jurisdiction) and DPDP (>=1 year of traffic/processing logs).
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: audit-log-store-in
  namespace: security
  annotations:
    dpdp/retention-days: "400"                  # DPDP >= 365; headroom for legal hold
    certin/retention-days: "180"                # CERT-In minimum, in India
    certin/jurisdiction: "IN"                   # storage physically in India
    residency/immutable: "true"                 # WORM / object-lock backed
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ceph-mumbai-object-lock     # object-lock / WORM, in-IN
  resources:
    requests:
      storage: 2Ti
# A scheduled integrity job (not shown) asserts the two clocks continuously:
# --assert-retention=180d --assert-in-region=IN --assert-append-only --alert-on-gap.
# A log gap becomes a finding you surface before the regulator does.

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 in the provider's hands. Self-hosted infrastructure in an Indian colocation facility — your own Kubernetes, HSM, and network — is the only model green on every row, at the cost of carrying the operational burden yourself.

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 a green cell 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 time to be the first kind of team — provided the building starts from the infrastructure, not the policy PDF.