GDPR SCCs vs. India's DPDPA Cross-Border Data Transfer Rules: A Technical Comparison

Key Takeaways

• GDPR and DPDPA use opposite transfer models: GDPR blocks transfers by default (whitelist/adequacy), while DPDPA permits transfers by default (negative list/blacklist). Complying with one does not satisfy the other.
• As of October 2026, the DPDPA restricted-countries list contains zero entries — all cross-border transfers from India are currently permitted under Section 16, but this is subject to change via government notification.
• GDPR Standard Contractual Clauses (SCCs) are NOT valid DPDPA compliance mechanisms — they are different legal frameworks. SCCs address the EU-side obligation; DPDPA compliance requires a separate Data Processing Agreement: a valid contract under Section 8(2) that provides for reasonable security safeguards, as Rule 6(1)(f) requires.
• Section 16(2) explicitly preserves sectoral regulator authority: RBI, SEBI, and IRDAI can impose data localisation requirements that are stricter than DPDPA's permissive default, regardless of the Section 16 restricted list.
• AWS (ap-south-1/ap-south-2) and Azure (Central India/South India/West India) provide India-resident regions; dual compliance requires region-pinned data stores with KMS keys locked to Indian regions.
• Rule 6 security safeguards — encryption, access control, logging, and processor contracts — follow the data across borders and remain mandatory regardless of destination.
• Architect for dynamic restriction enforcement from day one: use a configuration-driven policy engine, not hardcoded rules. MeitY can issue restriction notifications with minimal advance notice.

Key terms: Data Fiduciary — entity determining the purpose and means of personal data processing (GDPR equivalent: Data Controller). Negative List Model — the DPDPA's cross-border transfer approach: transfers are freely permitted unless the Central Government restricts a specific country by notification (Section 16). Standard Contractual Clauses (SCCs) — a GDPR mechanism requiring pre-approved contractual terms for data transfers outside the European Economic Area; not recognised as a transfer mechanism under DPDPA. Significant Data Fiduciary (SDF) — a Data Fiduciary designated by the Central Government as high-risk, subject to additional obligations including a Data Protection Officer and Data Protection Impact Assessment. Transfer Impact Assessment (TIA) — a post-Schrems II GDPR requirement under SCC Clause 14 to assess whether the destination country's laws provide essential equivalence with EU protection; required for EU→India transfers, not required under DPDPA.

Table of Contents

1. The Legal Framework: DPDPA Cross-Border Transfer Rules
   • Section 16: The Negative List Model
   • Rule 15: Implementation Mechanics
   • The Restricted Countries List: Current Status (October 2026)
   • Security Safeguards That Follow the Data
   • Data Processor Governance Across Borders
2. The Legal Framework: GDPR Standard Contractual Clauses
   • The Whitelist (Adequacy) Model
   • The 2021 SCC Framework
   • Transfer Impact Assessment (TIA)
3. How Does DPDPA Section 16 Differ from GDPR's SCC Model?
4. The Engineering Translation: Framework Control Mappings
5. Implementation Guide: AWS/Azure Data Residency for Dual Compliance
6. FAQ: Common Questions on DPDPA Cross-Border Data Transfer
7. Key Takeaways
8. Downloadable Resources

Introduction

If your organisation processes personal data of Indian residents while also handling EU data subjects, you are navigating two regulatory regimes that agree on almost nothing about how cross-border data transfers should work.

The GDPR, in force since 2018, requires affirmative justification for every transfer outside the European Economic Area. The DPDPA, with its cross-border provisions phasing into full operation by mid-2027, takes the inverse position: transfers are freely permitted unless the Indian Central Government issues a restriction order. The practical result is that a multinational corporation (MNC) operating in both jurisdictions cannot satisfy one framework by simply complying with the other.

This article provides a detailed comparison of DPDPA cross-border data transfer rules against GDPR's Standard Contractual Clauses (SCCs), maps both to established security frameworks, and delivers the infrastructure configuration patterns -- specifically for AWS and Azure -- that enable dual compliance without duplicating your entire data platform.

The Legal Framework: DPDPA Cross-Border Transfer Rules

Section 16: The Negative List Model

The DPDPA's approach to cross-border transfers is codified in Section 16, which establishes a permissive default:

"The Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified." -- Section 16(1), DPDPA 2023

This is a "negative list" or "blacklist" model. Personal data may flow to any jurisdiction worldwide unless the Central Government issues a notification explicitly restricting transfers to a specific country or territory. Section 16(2) preserves the applicability of any other Indian law that provides a higher degree of protection or restriction -- meaning sectoral regulators (RBI for financial data, SEBI for securities data, IRDAI for insurance data) can impose stricter requirements independently.

Rule 15: Implementation Mechanics

Rule 15 of the DPDP Rules 2025 operationalises Section 16:

"Any personal data processed by a Data Fiduciary under the Act may be transferred outside the territory of India subject to the restriction that the Data Fiduciary shall meet such requirements as the Central Government may, by general or special order, specify in respect of making such personal data available to any foreign State, or to any person or entity under the control of or any agency of such a State." -- Rule 15, DPDP Rules 2025

The critical engineering implication: the Central Government can impose restrictions through either "general orders" (applying to entire sectors, data categories, or destination countries) or "special orders" (targeting specific Data Fiduciaries or transfer scenarios). This means your compliance architecture must support dynamic policy enforcement -- a restriction could arrive with minimal advance notice.

The Restricted Countries List: Current Status (October 2026)

As of October 2026, no country or territory has been placed on the restricted list under Section 16. The Central Government has not issued any notification restricting cross-border transfers to any specific jurisdiction. Cross-border data transfers from India are currently permitted to all destinations, subject to the continuing obligations under the DPDPA (consent, security safeguards, data principal rights) applying to the data throughout its lifecycle abroad.

This status is subject to change. The DPDP Rules were notified on 13 November 2025 with phased commencement: Section 16 of the Act and Rule 15 both come into force on 13 May 2027. Separately, Rule 13(4) requires Significant Data Fiduciaries (SDFs) to ensure that personal data specified by the Central Government, on the recommendation of a committee it constitutes, is not transferred outside India together with the traffic data pertaining to its flow.

Engineering implication: Build your transfer governance system to support dynamic restriction enforcement from day one. Hardcoding "all transfers permitted" into your architecture is a technical debt that will become a compliance incident.

Security Safeguards That Follow the Data

Even where transfer is permitted, Rule 6 of the DPDP Rules 2025 mandates that security safeguards travel with the data. The Data Fiduciary remains liable regardless of where processing occurs:

"A Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach, which shall include, at the minimum,— (a) appropriate data security measures, such as securing of personal data through encryption, obfuscation, masking or the use of virtual tokens mapped to that personal data; (b) appropriate measures to control access to the computer resources used by such Data Fiduciary or such a Data Processor, wherever applicable; (c) visibility on the accessing of such personal data, through appropriate logs, monitoring and review, for enabling detection of unauthorised access, its investigation and remediation to prevent recurrence; ... (f) appropriate provision in the contract entered into between such Data Fiduciary and such a Data Processor, wherever applicable, for taking reasonable security safeguards; ..." -- Rule 6(1), clauses (a)–(c) and (f), DPDP Rules 2025

This means your Data Processor agreements for cross-border transfers must contractually bind the receiving party to Rule 6 safeguards -- and you must have the technical means to verify compliance.

Data Processor Governance Across Borders

Section 8(2) requires that Data Processors be engaged only "under a valid contract," and Section 8(5) makes the Data Fiduciary responsible for the security of data processed by any Data Processor, including those operating outside India:

"A Data Fiduciary shall protect personal data in its possession or under its control, including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards to prevent personal data breach." -- Section 8(5), DPDPA 2023

Unlike GDPR, the DPDPA does not prescribe specific contractual clauses for processor agreements. The obligation is outcome-based: the Data Fiduciary must ensure "reasonable security safeguards" regardless of the contractual mechanism used.

The Legal Framework: GDPR Standard Contractual Clauses

The Whitelist (Adequacy) Model

GDPR Article 45 permits transfers only to countries or territories that the European Commission has determined provide an "adequate level of protection." For all other destinations -- including India, which does not have an EU adequacy decision -- one of the following mechanisms must be in place:

• Standard Contractual Clauses (SCCs) -- pre-approved contractual templates (Article 46(2)(c))
• Binding Corporate Rules (BCRs) -- for intra-group transfers (Article 47)
• Codes of conduct or certification mechanisms with binding commitments (Article 46(2)(e)-(f))
• Derogations for specific situations (Article 49) -- consent, contract necessity, public interest

For most EU-India data flows, SCCs are the primary mechanism.

The 2021 SCC Framework

The European Commission's 2021 Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) introduced a modular structure covering four transfer scenarios:

Transfer Impact Assessment (TIA)

Post-Schrems II, Clause 14 of the SCCs requires a Transfer Impact Assessment before execution. Parties must evaluate:

1. The specific circumstances of the transfer (data categories, sensitivity, volume)
2. The laws and practices of the destination country (India, in this case)
3. Whether supplementary measures are needed to ensure "essential equivalence" with EU protection

For India, the TIA must account for India's surveillance laws (Information Technology Act 2000, Section 69), the absence of an independent data protection authority (the Data Protection Board of India is a government-constituted body, not an independent regulator in the EU sense), and the broad government powers under DPDPA Section 16 to restrict transfers unilaterally.

How Does DPDPA Section 16 Differ from GDPR's SCC Model?

The Engineering Translation: Framework Control Mappings

Cross-border data transfer obligations under both GDPR and DPDPA map to established security and privacy framework controls. The following table provides the crosswalk for organisations maintaining ISO 27001, SOC 2, or NIST-aligned programmes.

Cross-Border Transfer Obligation Mapping

Unmapped Gaps

Implementation Guide: AWS/Azure Data Residency for Dual Compliance

For organisations that must satisfy both GDPR SCCs and DPDPA cross-border rules, the cloud infrastructure architecture must enforce data residency at the platform level while maintaining the flexibility to serve both EU and Indian data subjects.

Architectural Principle: Region-Pinned Data, Global Compute

The core pattern is straightforward: store personal data in the jurisdiction of origin, process it there by default, and transfer it only through governed pipelines.

flowchart LR
    subgraph EU["EU Region (eu-west-1 / West Europe)"]
        EU_DB[(EU Personal Data)]
        EU_APP[Application Tier]
        EU_KMS[EU KMS Keys]
    end

    subgraph IN["India Region (ap-south-1 / Central India)"]
        IN_DB[(India Personal Data)]
        IN_APP[Application Tier]
        IN_KMS[India KMS Keys]
    end

    subgraph GOV["Transfer Governance Layer"]
        POLICY[Policy Engine]
        AUDIT[Audit Logger]
        RESTRICT[Restriction Config]
    end

    EU_APP -->|Governed Transfer| GOV
    IN_APP -->|Governed Transfer| GOV
    GOV -->|If Permitted| EU_APP
    GOV -->|If Permitted| IN_APP

    style EU fill:#e6f3ff,stroke:#0066cc
    style IN fill:#fff3e6,stroke:#cc6600
    style GOV fill:#f0f0f0,stroke:#666

Alt Text: Architecture diagram showing region-pinned data stores in EU and India cloud regions connected through a central transfer governance layer that enforces policy checks before permitting cross-border data flows.

AWS Configuration: Enforcing India Data Residency

1. S3 Bucket Policy -- Region Restriction (Terraform)

# Enforce that Indian personal data stays in ap-south-1
resource "aws_s3_bucket" "india_pii" {
  bucket = "myorg-india-personal-data"
  # S3 buckets are region-pinned at creation
}

resource "aws_s3_bucket_policy" "india_residency" {
  bucket = aws_s3_bucket.india_pii.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyReplicationOutsideIndia"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:PutReplicationConfiguration"
        Resource  = aws_s3_bucket.india_pii.arn
        Condition = {
          StringNotEquals = {
            "s3:ReplicationDestinationBucket" = [
              # Only allow replication to other ap-south buckets
              "arn:aws:s3:::myorg-india-personal-data-replica"
            ]
          }
        }
      },
      {
        Sid       = "EnforceEncryptionInTransit"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:*"
        Resource = [
          aws_s3_bucket.india_pii.arn,
          "${aws_s3_bucket.india_pii.arn}/*"
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      }
    ]
  })
}

# KMS key pinned to ap-south-1 -- data encrypted with this key
# cannot be decrypted outside the region
resource "aws_kms_key" "india_pii_key" {
  provider    = aws.ap_south_1
  description = "DPDPA-compliant encryption key for Indian PII"

  # Key policy restricts usage to India region principals
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "RestrictToIndiaRegion"
        Effect    = "Allow"
        Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" }
        Action    = "kms:*"
        Resource  = "*"
        Condition = {
          StringEquals = {
            "aws:RequestedRegion" = "ap-south-1"
          }
        }
      }
    ]
  })
}

2. AWS Organizations SCP -- Prevent Data Egress

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3ReplicationOutsideIndia",
      "Effect": "Deny",
      "Action": [
        "s3:PutReplicationConfiguration"
      ],
      "Resource": "arn:aws:s3:::myorg-india-*",
      "Condition": {
        "StringNotLike": {
          "s3:ReplicationDestinationBucket": "arn:aws:s3:::myorg-india-*"
        }
      }
    },
    {
      "Sid": "DenyRDSSnapshotCopyOutsideIndia",
      "Effect": "Deny",
      "Action": "rds:CopyDBSnapshot",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "rds:CopyDestinationRegion": "ap-south-1"
        }
      }
    }
  ]
}

Azure Configuration: Enforcing India Data Residency

1. Azure Policy -- Restrict Resource Locations

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "in": [
            "Microsoft.Storage/storageAccounts",
            "Microsoft.Sql/servers",
            "Microsoft.DocumentDB/databaseAccounts",
            "Microsoft.KeyVault/vaults"
          ]
        },
        {
          "field": "tags['data-residency']",
          "equals": "india"
        },
        {
          "not": {
            "field": "location",
            "in": [
              "centralindia",
              "southindia",
              "westindia"
            ]
          }
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

2. Azure Policy -- Enforce Customer-Managed Keys for Indian PII

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "tags['data-residency']",
          "equals": "india"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/encryption.keySource",
          "notEquals": "Microsoft.Keyvault"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Dual Compliance Architecture: The Transfer Governance Layer

For organisations subject to both GDPR and DPDPA, the transfer governance layer is the architectural component that decides whether a given data flow is permitted, logs the decision, and enforces the policy.

# transfer_governance.py
# Policy engine for cross-border data transfer decisions
# Supports both GDPR SCC requirements and DPDPA Section 16 restrictions

from dataclasses import dataclass
from enum import Enum
from typing import Optional
import json
import logging

logger = logging.getLogger("transfer_governance")


class Regime(Enum):
    GDPR = "gdpr"
    DPDPA = "dpdpa"
    BOTH = "both"


class TransferDecision(Enum):
    PERMITTED = "permitted"
    BLOCKED = "blocked"
    REQUIRES_SCC = "requires_scc"
    REQUIRES_REVIEW = "requires_review"


@dataclass
class TransferRequest:
    source_region: str          # e.g., "ap-south-1", "eu-west-1"
    destination_region: str     # e.g., "us-east-1", "eu-central-1"
    data_classification: str    # e.g., "personal_data", "sdf_specified_data" (Rule 13(4))
    data_subject_jurisdiction: str  # "IN", "EU", "BOTH"
    processor_has_scc: bool
    processor_has_dpa: bool     # DPDPA-compliant Data Processing Agreement
    sectoral_regulator: Optional[str] = None  # "RBI", "SEBI", etc.
    is_sdf: bool = False        # Significant Data Fiduciary


class TransferPolicyEngine:
    def __init__(self, config_path: str):
        """
        Load transfer policies from a configuration file.
        The restricted_destinations list is updated via CI/CD
        when MeitY publishes new notifications.
        """
        with open(config_path) as f:
            self.config = json.load(f)
        self.dpdpa_restricted = set(
            self.config.get("dpdpa_restricted_destinations", [])
        )
        self.gdpr_adequate = set(
            self.config.get("gdpr_adequate_countries", [])
        )
        self.sectoral_rules = self.config.get("sectoral_rules", {})

    def evaluate(self, request: TransferRequest) -> TransferDecision:
        """Evaluate a transfer request against all applicable regimes."""
        decisions = []

        if request.data_subject_jurisdiction in ("IN", "BOTH"):
            decisions.append(self._evaluate_dpdpa(request))

        if request.data_subject_jurisdiction in ("EU", "BOTH"):
            decisions.append(self._evaluate_gdpr(request))

        # Return the most restrictive decision
        if TransferDecision.BLOCKED in decisions:
            return TransferDecision.BLOCKED
        if TransferDecision.REQUIRES_REVIEW in decisions:
            return TransferDecision.REQUIRES_REVIEW
        if TransferDecision.REQUIRES_SCC in decisions:
            return TransferDecision.REQUIRES_SCC
        return TransferDecision.PERMITTED

    def _evaluate_dpdpa(self, req: TransferRequest) -> TransferDecision:
        """Apply DPDPA Section 16 / Rule 15 logic."""
        dest_country = self._region_to_country(req.destination_region)

        # Check negative list
        if dest_country in self.dpdpa_restricted:
            logger.warning(
                f"Transfer to {dest_country} blocked by DPDPA restriction"
            )
            return TransferDecision.BLOCKED

        # Check sectoral overrides (RBI, SEBI, etc.)
        if req.sectoral_regulator:
            rule = self.sectoral_rules.get(req.sectoral_regulator, {})
            if rule.get("localisation_required", False):
                if dest_country != "IN":
                    return TransferDecision.BLOCKED

        # SDF localisation: personal data specified by the Central Government under Rule 13(4)
        # (DPDPA has no "sensitive personal data" category)
        if req.is_sdf and req.data_classification == "sdf_specified_data":
            return TransferDecision.REQUIRES_REVIEW

        # Valid processor contract (Section 8(2)) with security-safeguard provision (Rule 6(1)(f))
        if not req.processor_has_dpa:
            return TransferDecision.REQUIRES_REVIEW

        return TransferDecision.PERMITTED

    def _evaluate_gdpr(self, req: TransferRequest) -> TransferDecision:
        """Apply GDPR Chapter V transfer rules."""
        dest_country = self._region_to_country(req.destination_region)

        # Adequacy check
        if dest_country in self.gdpr_adequate:
            return TransferDecision.PERMITTED

        # SCC check
        if req.processor_has_scc:
            return TransferDecision.REQUIRES_SCC  # TIA still needed

        return TransferDecision.BLOCKED

    def _region_to_country(self, region: str) -> str:
        """Map cloud region identifiers to country codes."""
        region_map = {
            "ap-south-1": "IN", "ap-south-2": "IN",
            "centralindia": "IN", "southindia": "IN",
            "eu-west-1": "EU", "eu-central-1": "EU",
            "westeurope": "EU", "northeurope": "EU",
            "us-east-1": "US", "us-west-2": "US",
            "eastus": "US", "westus2": "US",
        }
        return region_map.get(region, "UNKNOWN")

Transfer policy configuration file (update via CI/CD when MeitY publishes notifications):

{
  "dpdpa_restricted_destinations": [],
  "gdpr_adequate_countries": [
    "EU", "GB", "CH", "JP", "KR", "NZ", "AR", "CA", "IL", "UY", "AD",
    "FO", "GG", "IM", "JE"
  ],
  "sectoral_rules": {
    "RBI": {
      "localisation_required": true,
      "description": "RBI mandates that payment system data must be stored only in India"
    },
    "SEBI": {
      "localisation_required": false,
      "requires_board_approval": true
    }
  },
  "last_updated": "2026-04-02",
  "meity_notification_reference": "None as of 2026-10-17"
}

Production Implementation Note: The code above is a simplified demonstration of the core transfer governance logic. For the complete production-ready implementation with comprehensive validation, audit logging, TIA assessment workflows, and configuration examples, see the standalone transfer_governance_engine.py in the downloadable code templates. The production version includes 500+ lines with full error handling, retry logic, and integration patterns for AWS/Azure environments.

FAQ: Common Questions on DPDPA Cross-Border Data Transfer

Does DPDPA require Standard Contractual Clauses like GDPR?

No. The DPDPA does not recognise SCCs as a transfer mechanism at all. The two frameworks operate on entirely different legal bases. GDPR SCCs satisfy the EU-side obligation when data moves to India (a non-adequate country). The DPDPA-side obligation is satisfied by (a) the destination not being on the restricted list, (b) meeting any requirements the Central Government specifies by general or special order under Rule 15, and (c) maintaining Rule 6 security safeguards and a valid Data Processing Agreement (Section 8(2)). In practice, your contracts must address both regimes separately -- a single SCC document cannot provide dual compliance.

Which countries are currently restricted under DPDPA Section 16?

None, as of October 2026. The Central Government has not issued any notification under Section 16 restricting transfers to any country or territory. All cross-border transfers from India are currently permitted under DPDPA, subject to Rule 6 security safeguards remaining in place at the destination. This will change: build your architecture to enforce dynamic restriction enforcement rather than assuming the current permissive status persists.

How does DPDPA cross-border transfer differ from GDPR?

The core difference is the default position. GDPR blocks transfers unless justified (whitelist/adequacy model) -- most countries require SCCs, BCRs, or binding commitments before EU personal data can flow there. DPDPA permits transfers unless restricted (negative list/blacklist model) -- transfers flow freely until the Central Government issues a Section 16 notification blocking a specific country. The practical result: your GDPR compliance work (executing SCCs for EU→India flows) is entirely separate from your DPDPA compliance work (maintaining Rule 6 safeguards and monitoring MeitY notifications for the restricted list).

What happens to data security obligations when data is transferred outside India?

They remain fully in force. Rule 6(1) of the DPDP Rules 2025 applies to personal data in the Data Fiduciary's possession or under its control, including processing undertaken on its behalf by a Data Processor, and draws no distinction by location. Its safeguards -- encryption (Rule 6(1)(a)), access control (Rule 6(1)(b)), audit logging (Rule 6(1)(c)), and contractual provisions with the receiving Data Processor (Rule 6(1)(f)) -- therefore apply wherever the data is processed. Under Section 8(1) the Data Fiduciary remains responsible for processing by its Data Processors, including at the destination. This must be reflected in your Data Processing Agreements with overseas processors.

Can RBI or SEBI impose stricter data transfer restrictions than DPDPA?

Yes, explicitly. Section 16(2) of the DPDPA preserves the applicability of any other Indian law that provides a higher degree of protection or restriction on cross-border transfers. This means sectoral regulators operate independently of -- and can override -- DPDPA's permissive default. RBI already mandates that payment system data be stored only in India. SEBI imposes board-approval requirements for certain securities data transfers. IRDAI has similar powers for insurance data. If your organisation is regulated by any of these bodies, their rules apply on top of DPDPA's Section 16 regime.

What is a Transfer Impact Assessment and does DPDPA require one?

DPDPA does not require a TIA. A Transfer Impact Assessment is a post-Schrems II GDPR requirement under SCC Clause 14: before executing SCCs for an EU data transfer, both parties must assess whether the destination country's laws provide "essential equivalence" with EU protection. For transfers of EU data into India, the TIA must assess the DPDPA framework, India's IT Act 2000 (including Section 69 interception powers), and the government-constituted (rather than independent) nature of India's Data Protection Board. This is an EU-side obligation only -- there is no DPDPA equivalent.

How do Significant Data Fiduciaries differ in cross-border obligations?

SDFs face additional requirements under Section 10 and Rule 13, including an independent data auditor (Section 10(2)(b)), a Data Protection Impact Assessment and audit once every twelve months (Rule 13(1)), and a localisation obligation. Under Rule 13(4), the Central Government, on the recommendation of a committee it constitutes, may specify personal data that an SDF must process subject to the restriction that the data and the traffic data pertaining to its flow is not transferred outside India. If your organisation processes large volumes of Indian personal data, architect for data residency as a default posture rather than an exception.

Which AWS/Azure regions count as "India" for DPDPA purposes?

For AWS: ap-south-1 (Mumbai) and ap-south-2 (Hyderabad). For Azure: Central India (Pune), South India (Chennai), and West India (Mumbai). Data stored in these regions remains within Indian territory. Ensure your infrastructure-as-code enforces these regions for resources tagged with Indian personal data classifications.

Key Takeaways

• GDPR and DPDPA use opposite transfer models. GDPR blocks transfers by default (whitelist via adequacy decisions). DPDPA permits transfers by default (blacklist via government notification). Neither framework's compliance satisfies the other.
• No countries are currently restricted under DPDPA. As of October 2026, no MeitY notification has been issued under Section 16 restricting transfers to any jurisdiction. This will change. Build for it now.
• Rule 6 safeguards follow the data across borders. Encryption (Rule 6(1)(a)), access control (Rule 6(1)(b)), logging (Rule 6(1)(c)), and contractual provisions with Data Processors (Rule 6(1)(f)) are mandatory regardless of destination.
• Sectoral regulators override DPDPA's permissive stance. RBI payment data localisation, SEBI requirements, and IRDAI rules apply on top of DPDPA. Tag your data flows with applicable regulators.
• SCCs are necessary for the EU side, but irrelevant to the India side. Your contracts must address both regimes. A single SCC does not provide dual compliance.
• Architect for dynamic restriction enforcement. Use configuration-driven policy engines, not hardcoded transfer rules. The Central Government can issue restriction notifications with minimal advance notice.
• Region-pin your data in cloud infrastructure. Use S3 bucket policies, Azure Policy, SCPs, and region-locked KMS keys to enforce data residency at the platform level.

📊 GDPR-DPDPA Comparison Matrix (CSV)

Comprehensive side-by-side comparison across 21 dimensions covering legal model, transfer mechanisms, restricted destinations, processor contracts, security safeguards, breach notification, DPO requirements, and more. Includes cross-references to ISO 27001:2022, SOC 2 TSC, and NIST CSF 2.0 for each dimension.

Download Comparison Matrix (CSV) | 21 dimensions × 7 columns

✅ Dual Compliance Implementation Checklist

36-week phased implementation guide with pre-assessment questionnaire, 8 phases covering legal foundation, security safeguards, data residency architecture, transfer governance automation, breach notification, and continuous compliance. Includes SDF-specific requirements and common pitfalls appendix.

Download Implementation Checklist (Markdown) | 36 weeks, 8 phases

💻 Production-Ready Code Templates

• AWS Data Residency (Terraform) — Complete Terraform configuration for region-restricted S3, KMS, Organizations SCP, and CloudTrail
• Azure Data Residency (ARM Template) — Azure Policy definitions for location restriction, CMK encryption, and TLS enforcement
• Transfer Governance Engine (Python) — Configuration-driven transfer approval engine evaluating GDPR adequacy + DPDPA Section 16 restrictions

Browse Code Templates | Terraform + ARM + Python

📄 Quick Reference Card

2-page condensed guide covering core model comparison (whitelist vs. negative list), decision matrix (Can I transfer?), GDPR SCC modules, EU adequacy countries, DPDPA Rule 6 safeguards, critical timelines, and common pitfalls. Print for desk reference during cross-border architecture reviews.

Download Quick Reference (Markdown/PDF) | Printable

All resources are open-source and production-ready. Use them to accelerate compliance, reduce audit costs, and demonstrate engineering rigor to regulators.

Next Steps

Cross-border data transfer compliance under dual GDPR-DPDPA regimes is an infrastructure problem as much as a legal one. If your organisation is evaluating its transfer governance architecture or needs to implement the AWS/Azure configurations described in this article, contact StateCheck Security for a compliance architecture review.

Related articles from our DPDPA compliance series:

• The DPDPA to ISO 27001 Mapping Guide: Leveraging Annex A for Privacy Compliance -- Understand how ISO 27001:2022 controls map to DPDPA obligations, including the cross-border transfer controls (A.5.14) discussed in this article.
• SOC 2 Privacy Criteria vs. DPDPA: Bridging the Gap for Indian SaaS Companies -- For SaaS companies managing cross-border data flows, this article maps SOC 2 Trust Services Criteria to DPDPA requirements.
• Implementing Cryptographic Controls for DPDPA: Encryption Standards at Rest and in Transit -- Deep dive into the encryption requirements (Rule 6(1)(a)) that apply to all cross-border data transfers.
• Zero Trust Architecture as a DPDPA Compliance Enabler -- How Zero Trust principles support the access control requirements (Rule 6(1)(b)) for data transferred across jurisdictions.