Implementing Cryptographic Controls for DPDPA: Encryption Standards at Rest and in Transit

Key Takeaways

• Rule 6(1)(a) of the DPDP Rules 2025 names encryption first among the minimum "reasonable security safeguards," alongside obfuscation, masking and virtual tokens — the wording is "securing of personal data through encryption," not "where practicable." Rule 6 applies from 13 May 2027.
• Saying "yes, we encrypt" is not sufficient — the Board will ask: which algorithm, what key length, who controls the keys, how often do they rotate, and whether microservice-to-microservice traffic is also covered.
• AES-256-GCM at rest and TLS 1.3 in transit are the prevailing industry standards that define "reasonable" in the DPDPA context; use envelope encryption with cloud KMS-managed keys for key lifecycle control.
• Demonstrable encryption with AES-256 that prevents key compromise limits Board penalty exposure under Section 33(2)(e), which explicitly requires the Board to weigh mitigation actions when setting penalty amounts.
• Data Processors must also encrypt personal data — Rule 6(1) covers processing done on the Data Fiduciary's behalf by a Data Processor, and Rule 6(1)(f) requires the contract with the processor to provide for reasonable security safeguards, which means your DPAs must specify algorithm minimums, KMS standards, and audit obligations.
• Key management is where encryption implementations fail: cloud KMS services with HSM backing, automatic annual rotation, IAM-gated access, and audit logs retained for at least one year per Rule 6(1)(e).
• Encryption configuration must be validated in your CI/CD pipeline — treat unencrypted personal data storage as a blocking deployment gate, not a post-deploy finding.

Key terms: Data Fiduciary — entity determining purpose/means of processing (GDPR: Data Controller). Technical and Organisational Measures (TOMs) — the security controls enumerated in Rule 6(1)(a)-(g) that operationalise Section 8(5)'s "reasonable security safeguards" requirement. Key Management Service (KMS) — cloud service for cryptographic key lifecycle management (AWS KMS, Azure Key Vault, GCP Cloud KMS). Data Encryption Key (DEK) / Key Encryption Key (KEK) — envelope encryption pattern where DEKs encrypt data and are themselves encrypted by a KEK stored in the KMS.

Table of Contents

1. Introduction
2. Which Encryption Standards Satisfy DPDPA Rule 6(1)(a)?
3. The Engineering Translation: Framework Control Mappings
4. Implementation Guide: Cryptographic Controls for DPDPA
   • Step 1: TLS 1.3 Configuration for Data in Transit
   • Step 2: AES-256 Encryption at Rest
   • Step 3: Cloud KMS Configuration
   • Step 4: Key Rotation Policy
   • Step 5: Infrastructure-as-Code Validation
5. The Liability Argument: Encryption as a Defense
6. Downloadable Resources
7. FAQ: DPDPA Encryption Requirements
8. Key Takeaways
9. Next Steps

Introduction

Your database stores 2.5 million records of Indian users' personal data. A threat actor exploits a misconfigured API gateway and exfiltrates a subset of those records. Two questions will determine whether your organisation faces a penalty extending to two hundred and fifty crore rupees or a defensible position before the Data Protection Board of India.

First: was the data encrypted? Second: did the attacker obtain the keys?

The DPDPA encryption requirements are not aspirational guidance. Rule 6(1)(a) of the DPDP Rules 2025 names encryption first among the minimum "reasonable security safeguards" required under Section 8(5) of the Act. The exact wording is "securing of personal data through encryption" — not "consider encrypting" or "where practicable." This is a floor, not a ceiling.

Yet most organisations treat encryption as a binary checkbox: "yes, we encrypt." That answer collapses under scrutiny. Encrypt with what algorithm? What key length? Who controls the keys? How often do they rotate? Is the data encrypted in transit between your microservices, or only at the load balancer? Is your backup pipeline encrypted, or does it dump plaintext to cold storage?

This article answers those questions with production-grade specifications. It maps the DPDPA's legal obligations to specific cryptographic controls, provides cipher suite configurations for TLS 1.3 and AES-256, walks through key management architecture across AWS KMS, Azure Key Vault, and GCP Cloud KMS, and explains exactly how proper encryption changes your liability calculus when the Board comes knocking.

Which Encryption Standards Satisfy DPDPA Rule 6(1)(a)?

The encryption obligation lives across four legal anchors: Section 8(5) sets the duty, Rule 6(1)(a) names encryption as the safeguard, Rule 6(1)(c) and (e) set the audit-log floor, and Section 33(2)(e) ties strong encryption to penalty mitigation. The five subsections below walk each anchor in turn.

Section 8(5): The Foundation -- Reasonable Security Safeguards

"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

This is the obligation that encryption most directly serves. The Act does not specify particular cryptographic standards -- it delegates the operational details to the Rules.

Rule 6(1)(a): Encryption as a Statutory Minimum

Rule 6(1) requires, 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" -- Rule 6(1)(a), DPDP Rules 2025

Rule 6 applies from 13 May 2027, eighteen months after the Rules were notified. Three things to note. First, encryption is listed as an example of "appropriate data security measures," not the only option — but it is the first option named and the most universally applicable. Second, the rule covers the full spectrum of data protection techniques: encryption, obfuscation, masking, and tokenisation. Third, there is no carve-out for data "at rest" versus "in transit" — the obligation covers personal data in all states.

Rule 6(1)(c) and (e): Logging and Retention of Access to Encrypted Data

Rule 6(1) also requires: "(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" and "(e) ... retain such logs and personal data for a period of one year, unless compliance with any law for the time being in force requires otherwise" -- Rule 6(1)(c) and (e), DPDP Rules 2025

Your encryption implementation must include audit logging of key access events. When a decryption key is used, who requested it, when, and for what purpose must be recorded and retained for a minimum of one year.

Section 8(4): Technical Measures Mandate

"A Data Fiduciary shall implement appropriate technical and organisational measures to ensure effective observance of the provisions of this Act and the rules made thereunder." -- Section 8(4), DPDPA 2023

Encryption is not just a safeguard against breaches -- it is an "appropriate technical measure" that demonstrates compliance with the Act's broader requirements. An organisation that can demonstrate a well-architected cryptographic control framework has stronger evidence of Section 8(4) compliance than one relying on policy documents alone.

The Liability Calculus: How Encryption Affects Penalty Determination

The Schedule to the DPDPA specifies that breach of Section 8(5) (failure to take reasonable security safeguards) may attract a penalty extending to two hundred and fifty crore rupees. Section 33(2) lists the factors the Board considers when determining penalty amounts:

Section 33(2) factors include: "(a) the nature, gravity and duration of the breach; (b) the type and nature of the personal data affected by the breach; ... (e) whether the person took any action to mitigate the effects and consequences of the breach, and the timeliness and effectiveness of such action" -- Section 33(2), DPDPA 2023

Encryption directly addresses factor (e). If exfiltrated data was encrypted with AES-256 and the attacker did not compromise the key material, the practical impact of the breach is substantially reduced -- the data is computationally unusable. This does not eliminate the breach notification obligation under Section 8(6), but it provides concrete evidence of mitigation that the Board must consider when setting the penalty amount.

Rule 6(1)(f): Data Processor Encryption Requirements

Rule 6(1) requires: "(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)(f), DPDP Rules 2025

Your Data Processing Agreements must specify encryption standards for Data Processors. A Data Fiduciary that mandates AES-256 and TLS 1.3 in its own infrastructure but permits a Data Processor to store personal data in plaintext has a compliance gap under both the encryption rule and the processor-contract rule.

The Engineering Translation: Framework Control Mappings

The framework control mapping is the bridge between DPDPA encryption obligations and the certifications your auditor already understands. Every encryption duty in this article maps cleanly to a specific ISO 27001:2022 Annex A control, a SOC 2 TSC, and a NIST CSF 2.0 subcategory — so an existing programme can absorb DPDPA without parallel evidence.

Threat Model Context: STRIDE

From a threat modelling perspective, DPDPA encryption obligations address these specific threat categories:

• Information Disclosure: The primary threat. Encryption renders exfiltrated data computationally unusable without key material. This directly mitigates the most common trigger for Section 2(u) personal data breaches.
• Tampering: Authenticated encryption (AES-GCM) provides integrity verification alongside confidentiality, detecting unauthorised modification of personal data.
• Elevation of Privilege: Envelope encryption with KMS-managed keys ensures that database administrators cannot read personal data without explicit key access grants, enforcing separation of duties.

Implementation Guide: Cryptographic Controls for DPDPA

The implementation guide turns the encryption rule into a five-step build: TLS 1.3 transport, AES-256 storage, cloud KMS, key rotation, and CI/CD validation. Sequence matters — without the KMS layer, the algorithm choice in steps 1 and 2 is hollow.

What does a DPDPA-compliant encryption architecture look like?

A DPDPA-compliant encryption architecture operates at three layers: transport (TLS 1.3), storage (AES-256), and key management (Cloud KMS). Each layer must be independently configured and audited. The five steps below take you from a blank infrastructure to a compliant encryption stack.

HowTo: Implement DPDPA Encryption Controls

1. Configure TLS 1.3 cipher suites and mTLS for all data-in-transit channels (load balancer, service mesh, database connections).
2. Implement AES-256-GCM field-level encryption for all personal data at rest, using per-record Data Encryption Keys (DEKs).
3. Deploy cloud KMS (AWS KMS / Azure Key Vault / GCP Cloud KMS) with HSM backing, annual automatic key rotation, IAM-gated access policies, and audit logging retained for at least one year.
4. Add OPA encryption policies to your CI/CD pipeline to enforce Step 1–3 controls on every infrastructure change before deployment.

Architecture Overview: The Encryption Envelope

Step 1: TLS 1.3 Configuration for Data in Transit

TLS 1.3 is the transport-layer baseline for DPDPA — it eliminates by design the cipher suites and handshake patterns that have been broken in TLS 1.0/1.1 and weakened in some TLS 1.2 deployments. TLS 1.2 remains acceptable for legacy compatibility but only with a restricted AEAD cipher suite. TLS 1.0 and 1.1 are deprecated and must not be used for personal data transport.

Recommended TLS 1.3 cipher suites:

# nginx TLS 1.3 configuration for DPDPA compliance
# Maps to: Rule 6(1)(a) — encryption in transit

ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers on;

# TLS 1.3 cipher suites (configured via OpenSSL 1.1.1+)
# These are the only three cipher suites in TLS 1.3:
#   TLS_AES_256_GCM_SHA384       (preferred)
#   TLS_CHACHA20_POLY1305_SHA256 (mobile/low-power)
#   TLS_AES_128_GCM_SHA256       (acceptable)
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

# TLS 1.2 fallback — restricted to AEAD ciphers only
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';

# ECDH curve preference
ssl_ecdh_curve X25519:secp384r1;

# HSTS header — enforce TLS for 1 year
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# OCSP stapling for certificate validation performance
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;

Mutual TLS (mTLS) for service-to-service communication:

# Istio service mesh mTLS configuration
# Enforces TLS 1.3 between all services in the mesh
# Maps to: Rule 6(1)(a), Rule 6(1)(b) — access control + encryption

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: dpdpa-strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT  # All service-to-service traffic must use mTLS
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: dpdpa-tls-settings
  namespace: production
spec:
  host: "*.production.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
      # TLS 1.3 is the default in Istio 1.14+
      # Verify with: istioctl proxy-config secret <pod>

Step 2: AES-256 Encryption at Rest

AES-256 is the storage-layer baseline for DPDPA — it is the prevailing industry baseline against which "reasonable security safeguards" are likely to be measured. Every storage system that holds personal data must implement it. AES-256-GCM is preferred over AES-256-CBC because GCM provides authenticated encryption (confidentiality + integrity in one primitive); CBC needs a separate MAC and is more error-prone in production.

Database-level encryption with field-level controls:

"""
field_level_encryption.py

Implements field-level encryption for personal data fields
using AES-256-GCM with envelope encryption. Each record gets
a unique Data Encryption Key (DEK) wrapped by a KMS-managed
Key Encryption Key (KEK).

Maps to: Rule 6(1)(a) — encryption of personal data
"""
import os
import base64
from dataclasses import dataclass
from datetime import datetime, timezone
from typing import Optional

from cryptography.hazmat.primitives.ciphers.aead import AESGCM


@dataclass
class EncryptedField:
    """Represents an encrypted personal data field."""
    ciphertext: bytes
    nonce: bytes          # 96-bit nonce for AES-256-GCM
    kek_id: str           # KMS key ID used to wrap the DEK
    wrapped_dek: bytes    # DEK encrypted by KMS KEK
    encrypted_at: datetime
    algorithm: str = "AES-256-GCM"


class DPDPAFieldEncryptor:
    """Encrypts personal data fields per Rule 6(1)(a).

    Uses envelope encryption:
    1. Generate a random 256-bit DEK per record
    2. Encrypt the field value with DEK using AES-256-GCM
    3. Wrap the DEK with a KMS-managed KEK
    4. Store the wrapped DEK alongside the ciphertext
    5. Log the encryption event for Rule 6(1)(c) audit
    """

    def __init__(self, kms_client, audit_logger, kek_id: str):
        self.kms = kms_client
        self.audit = audit_logger
        self.kek_id = kek_id

    def encrypt_field(
        self,
        plaintext: str,
        field_name: str,
        data_principal_id: str,
    ) -> EncryptedField:
        """Encrypt a single personal data field.

        Args:
            plaintext: The field value to encrypt
            field_name: Name of the field (for audit logging)
            data_principal_id: ID of the Data Principal

        Returns:
            EncryptedField with ciphertext and key metadata
        """
        # Step 1: Generate a random 256-bit DEK
        dek = AESGCM.generate_key(bit_length=256)

        # Step 2: Encrypt the field with AES-256-GCM
        aesgcm = AESGCM(dek)
        nonce = os.urandom(12)  # 96-bit nonce
        ciphertext = aesgcm.encrypt(
            nonce,
            plaintext.encode("utf-8"),
            # Additional authenticated data: field name + principal ID
            # Binds ciphertext to its intended context
            f"{field_name}:{data_principal_id}".encode("utf-8"),
        )

        # Step 3: Wrap the DEK with KMS KEK
        wrapped_dek = self.kms.encrypt(
            key_id=self.kek_id,
            plaintext=dek,
            encryption_context={
                "field": field_name,
                "principal": data_principal_id,
                "purpose": "dpdpa_field_encryption",
            },
        )

        # Step 4: Audit log the encryption event (Rule 6(1)(c))
        self.audit.log(
            event="field_encrypted",
            field_name=field_name,
            data_principal_id=data_principal_id,
            kek_id=self.kek_id,
            algorithm="AES-256-GCM",
            timestamp=datetime.now(timezone.utc).isoformat(),
        )

        # Zero out the plaintext DEK from memory
        dek = b'\x00' * len(dek)

        return EncryptedField(
            ciphertext=ciphertext,
            nonce=nonce,
            kek_id=self.kek_id,
            wrapped_dek=wrapped_dek,
            encrypted_at=datetime.now(timezone.utc),
        )

    def decrypt_field(
        self,
        encrypted: EncryptedField,
        field_name: str,
        data_principal_id: str,
        requester: str,
    ) -> str:
        """Decrypt a personal data field.

        Every decryption event is logged per Rule 6(1)(c).
        """
        # Step 1: Unwrap DEK via KMS
        dek = self.kms.decrypt(
            key_id=encrypted.kek_id,
            ciphertext=encrypted.wrapped_dek,
            encryption_context={
                "field": field_name,
                "principal": data_principal_id,
                "purpose": "dpdpa_field_encryption",
            },
        )

        # Step 2: Decrypt field with AES-256-GCM
        aesgcm = AESGCM(dek)
        plaintext = aesgcm.decrypt(
            encrypted.nonce,
            encrypted.ciphertext,
            f"{field_name}:{data_principal_id}".encode("utf-8"),
        )

        # Step 3: Audit log the decryption event (Rule 6(1)(c))
        self.audit.log(
            event="field_decrypted",
            field_name=field_name,
            data_principal_id=data_principal_id,
            requester=requester,
            kek_id=encrypted.kek_id,
            timestamp=datetime.now(timezone.utc).isoformat(),
        )

        # Zero out DEK
        dek = b'\x00' * len(dek)

        return plaintext.decode("utf-8")

Step 3: Cloud KMS Configuration

Cloud KMS is the key-management layer that turns AES-256 from a checkbox into a defensible control. Key management is where most encryption implementations actually fail: the algorithm can be perfect, but if keys are stored in environment variables, committed to source control, or managed without rotation, the entire scheme collapses.

AWS KMS configuration (Terraform):

# aws_kms_dpdpa.tf
# KMS key for DPDPA personal data encryption
# Maps to: Rule 6(1)(a) — key management for encryption

resource "aws_kms_key" "dpdpa_personal_data" {
  description             = "DPDPA personal data encryption - Rule 6(1)(a)"
  deletion_window_in_days = 30
  enable_key_rotation     = true  # Automatic annual rotation
  key_usage               = "ENCRYPT_DECRYPT"
  customer_master_key_spec = "SYMMETRIC_DEFAULT"  # AES-256-GCM

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "RootAccountAccess"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "ApplicationEncryptDecrypt"
        Effect = "Allow"
        Principal = {
          AWS = var.application_role_arns  # Only app roles
        }
        Action = [
          "kms:Encrypt",
          "kms:Decrypt",
          "kms:GenerateDataKey",
          "kms:GenerateDataKeyWithoutPlaintext",
          "kms:ReEncryptFrom",
          "kms:ReEncryptTo",
          "kms:DescribeKey",
        ]
        Resource = "*"
        Condition = {
          StringEquals = {
            "kms:EncryptionContext:purpose" = "dpdpa_field_encryption"
          }
        }
      },
      {
        Sid    = "DenyDeleteToNonAdmins"
        Effect = "Deny"
        Principal = { AWS = "*" }
        Action = [
          "kms:ScheduleKeyDeletion",
          "kms:DisableKey",
        ]
        Resource = "*"
        Condition = {
          StringNotEquals = {
            "aws:PrincipalArn" = var.kms_admin_role_arn
          }
        }
      }
    ]
  })

  tags = {
    compliance  = "dpdpa-rule-6-1-a"
    data_class  = "personal_data"
    environment = var.environment
  }
}

resource "aws_kms_alias" "dpdpa_personal_data" {
  name          = "alias/dpdpa-personal-data-${var.environment}"
  target_key_id = aws_kms_key.dpdpa_personal_data.key_id
}

# CloudTrail logging for KMS key usage — Rule 6(1)(c)
# Ensure CloudTrail is enabled with management events
# Key usage events are logged automatically
# Retention: minimum 1 year per Rule 6(1)(e)

resource "aws_cloudwatch_log_group" "kms_audit" {
  name              = "/dpdpa/kms-audit/${var.environment}"
  retention_in_days = 365  # Rule 6(1)(e): 1 year minimum
}

Azure Key Vault configuration (Terraform):

# azure_keyvault_dpdpa.tf
# Azure Key Vault for DPDPA personal data encryption

resource "azurerm_key_vault" "dpdpa" {
  name                = "dpdpa-${var.environment}-kv"
  location            = "centralindia"  # Pune region
  resource_group_name = var.resource_group_name
  tenant_id           = data.azurerm_client_config.current.tenant_id
  sku_name            = "premium"  # HSM-backed keys

  # Purge protection: prevent accidental key deletion
  purge_protection_enabled   = true
  soft_delete_retention_days = 90

  network_acls {
    default_action = "Deny"
    bypass         = "AzureServices"
    ip_rules       = var.allowed_ip_ranges
    virtual_network_subnet_ids = var.allowed_subnet_ids
  }
}

resource "azurerm_key_vault_key" "dpdpa_personal_data" {
  name         = "dpdpa-personal-data-key"
  key_vault_id = azurerm_key_vault.dpdpa.id
  key_type     = "RSA-HSM"  # HSM-protected
  key_size     = 4096

  key_opts = ["encrypt", "decrypt", "wrapKey", "unwrapKey"]

  rotation_policy {
    automatic {
      time_before_expiry = "P30D"
    }
    expire_after         = "P365D"  # Annual rotation
    notify_before_expiry = "P30D"
  }

  tags = {
    compliance = "dpdpa-rule-6-1-a"
    data_class = "personal_data"
  }
}

# Diagnostic settings for audit logging — Rule 6(1)(c)
resource "azurerm_monitor_diagnostic_setting" "kv_audit" {
  name                       = "dpdpa-kv-audit"
  target_resource_id         = azurerm_key_vault.dpdpa.id
  log_analytics_workspace_id = var.log_analytics_workspace_id

  enabled_log {
    category = "AuditEvent"
  }

  metric {
    category = "AllMetrics"
  }
}

GCP Cloud KMS configuration (Terraform):

# gcp_kms_dpdpa.tf
# GCP Cloud KMS for DPDPA personal data encryption

resource "google_kms_key_ring" "dpdpa" {
  name     = "dpdpa-personal-data-${var.environment}"
  location = "asia-south1"  # Mumbai region
}

resource "google_kms_crypto_key" "dpdpa_personal_data" {
  name     = "personal-data-encryption-key"
  key_ring = google_kms_key_ring.dpdpa.id

  purpose  = "ENCRYPT_DECRYPT"

  version_template {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"  # AES-256-GCM
    protection_level = "HSM"  # Cloud HSM backing
  }

  # Automatic key rotation — annual
  rotation_period = "31536000s"  # 365 days

  # Prevent accidental destruction
  lifecycle {
    prevent_destroy = true
  }

  labels = {
    compliance = "dpdpa-rule-6-1-a"
    data_class = "personal-data"
  }
}

# IAM binding: only the application service account can encrypt/decrypt
resource "google_kms_crypto_key_iam_member" "app_encrypter" {
  crypto_key_id = google_kms_crypto_key.dpdpa_personal_data.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
  member        = "serviceAccount:${var.app_service_account_email}"
}

# Audit logging is enabled by default in GCP Cloud Audit Logs
# Ensure Data Access logs are enabled for Cloud KMS
resource "google_project_iam_audit_config" "kms_audit" {
  project = var.project_id
  service = "cloudkms.googleapis.com"

  audit_log_config {
    log_type = "DATA_READ"
  }
  audit_log_config {
    log_type = "DATA_WRITE"
  }
}

Step 4: Key Rotation Policy

Key rotation is the operational discipline that keeps the cryptographic scheme honest over time. It limits the blast radius of any single compromised key and provides cryptographic agility for algorithm upgrades. The policy below aligns with the DPDPA encryption rule and prevailing industry practice.

Step 5: Infrastructure-as-Code Validation

Infrastructure-as-code validation is the gate that prevents Steps 1–4 from drifting after launch. Encryption configuration is validated in CI/CD on every infrastructure change, before any resource is created. The OPA policy below enforces the encryption rule against Terraform plans.

# policies/dpdpa/encryption.rego
# Enforces Rule 6(1)(a): encryption of personal data
# Used as a CI/CD gate for Terraform plan validation

package dpdpa.encryption

# Deny S3 buckets without server-side encryption
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket_server_side_encryption_configuration"
    rule := resource.change.after.rule[_]
    algo := rule.apply_server_side_encryption_by_default[_].sse_algorithm
    algo != "aws:kms"
    msg := sprintf(
        "S3 encryption must use aws:kms (AES-256 via KMS). Found: %s. "
        "Rule 6(1)(a) requires encryption with managed keys. [%s]",
        [algo, resource.address]
    )
}

# Deny RDS instances without storage encryption
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_db_instance"
    resource.change.after.storage_encrypted != true
    msg := sprintf(
        "RDS instance '%s' has storage_encrypted=false. "
        "Rule 6(1)(a) requires encryption at rest. [%s]",
        [resource.change.after.identifier, resource.address]
    )
}

# Deny RDS instances using default KMS key
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_db_instance"
    resource.change.after.storage_encrypted == true
    resource.change.after.kms_key_id == null
    msg := sprintf(
        "RDS instance '%s' uses default AWS-managed key. "
        "DPDPA requires customer-managed KMS keys for key lifecycle control. [%s]",
        [resource.change.after.identifier, resource.address]
    )
}

# Deny EBS volumes without encryption
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_ebs_volume"
    resource.change.after.encrypted != true
    msg := sprintf(
        "EBS volume '%s' is unencrypted. Rule 6(1)(a). [%s]",
        [resource.change.after.tags.Name, resource.address]
    )
}

# Deny Elasticache replication groups without encryption
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_elasticache_replication_group"
    resource.change.after.at_rest_encryption_enabled != true
    msg := sprintf(
        "Elasticache '%s' lacks at-rest encryption. Rule 6(1)(a). [%s]",
        [resource.change.after.replication_group_id, resource.address]
    )
}

# Deny Elasticache without in-transit encryption
deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_elasticache_replication_group"
    resource.change.after.transit_encryption_enabled != true
    msg := sprintf(
        "Elasticache '%s' lacks in-transit encryption. Rule 6(1)(a). [%s]",
        [resource.change.after.replication_group_id, resource.address]
    )
}

The Liability Argument: Encryption as a Defense

The liability argument is the reason encryption is worth real engineering investment, not just a compliance line item. Section 33(2)(e) requires the Board to weigh mitigation actions when setting penalty amounts — and well-implemented encryption is the most effective pre-breach mitigation available. The two scenarios below show the calculus in practice.

Scenario A -- No encryption: An attacker exfiltrates 100,000 records of personal data stored in plaintext. The Board assesses: (a) nature and gravity -- high, plaintext data is immediately usable; (b) type of data -- names, emails, addresses; (e) mitigation actions -- none at the data layer. The Data Fiduciary has no data-layer security measure of the kind Rule 6(1)(a) requires (encryption, obfuscation, masking or virtual tokens). The penalty assessment under Section 33(2) will reflect this failure.

Scenario B -- Proper encryption: The same attacker exfiltrates the same records, but the data was encrypted with AES-256-GCM using per-record DEKs wrapped by KMS-managed KEKs. The attacker obtained ciphertext but not key material. The Board assesses: (a) nature and gravity -- reduced, the data is computationally unusable; (e) mitigation actions -- encryption with industry-standard controls, key material not compromised, immediate key rotation post-detection. The penalty calculus is materially different.

This is not hypothetical reasoning. Section 33(2)(e) explicitly asks whether the person "took any action to mitigate the effects and consequences of the breach, and the timeliness and effectiveness of such action." Encryption is the most effective pre-breach mitigation action available.

KMS Terraform Configurations

• AWS KMS (Terraform) — AWS KMS customer master keys with automatic rotation, CloudTrail logging, and least-privilege policies
• Azure Key Vault (Terraform) — Azure Key Vault with soft delete, purge protection, and diagnostic logging
• GCP Cloud KMS (Terraform) — Google Cloud KMS with 90-day rotation and Cloud Logging integration

TLS 1.3 Configuration Templates

• Kubernetes Ingress NGINX (YAML) — TLS 1.3 Ingress with cert-manager automatic certificate provisioning
• NGINX (Config) — TLS 1.3 standalone NGINX configuration with HSTS and OCSP stapling
• HAProxy (Config) — TLS 1.3 HAProxy load balancer configuration
• Envoy Service Mesh (YAML) — TLS 1.3 Envoy configuration for microservice mTLS

Database Encryption Configurations

• PostgreSQL (SQL) — Column-level encryption with pgcrypto, TLS enforcement, and audit logging
• MySQL (Config) — InnoDB tablespace encryption and TLS client connection enforcement
• MongoDB (Config) — WiredTiger encryption at rest and TLS/mTLS configuration

Related: CI/CD Encryption Enforcement

For automated encryption validation in CI/CD pipelines, see:

• OPA Encryption Policy — Infrastructure-as-code encryption enforcement
• GitHub Actions DPDPA Gates — Automated encryption validation in CI/CD

FAQ: DPDPA Encryption Requirements

Does DPDPA mandate specific encryption algorithms like AES-256?

No. Rule 6(1)(a) requires "securing of personal data through encryption" but does not specify an algorithm. However, AES-256-GCM is the industry standard for symmetric encryption and is the minimum you should implement. Using a deprecated algorithm (DES, 3DES, RC4) or a weak key length (AES-128 for highly sensitive data) would undermine the "reasonable" in "reasonable security safeguards." The Board will assess your controls against prevailing industry standards, and AES-256 is that standard.

What is Rule 6(1)(a) and what does it require?

Rule 6(1)(a) of the DPDP Rules 2025 is the operational specification for Section 8(5)'s "reasonable security safeguards" requirement. It mandates "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." Encryption is one of four listed examples, but it is the first-listed and most universally applicable control. The Rule applies to personal data in all states: at rest, in transit, and in processing.

How does encryption affect penalty determination under DPDPA?

Section 33(2)(e) requires the Board to consider whether the Data Fiduciary "took any action to mitigate the effects and consequences of the breach, and the timeliness and effectiveness of such action." If exfiltrated data was encrypted with AES-256-GCM and the attacker did not obtain key material, the data is computationally unusable -- this materially reduces the "nature, gravity" assessment under Section 33(2)(a) and provides concrete evidence of effective mitigation. Encryption does not eliminate breach notification obligations under Section 8(6), but it substantially changes the penalty calculus.

Are Data Processors required to encrypt personal data?

Yes, indirectly but bindingly. Rule 6(1)(f) requires Data Fiduciaries to include "appropriate provision in the contract entered into between such Data Fiduciary and such a Data Processor" for "reasonable security safeguards." This means encryption obligations must flow down to your Data Processors through contract. A Data Fiduciary that mandates AES-256 in its own infrastructure but permits a Data Processor to store personal data in plaintext has a Rule 6(1)(f) compliance gap. Your DPAs should specify minimum algorithms (AES-256 at rest, TLS 1.3/1.2 in transit), key management requirements, rotation schedules, and audit logging obligations.

How does DPDPA encryption differ from GDPR requirements?

GDPR Article 32 requires "appropriate technical and organisational measures" including "encryption of personal data" but, like DPDPA, does not mandate specific algorithms. The key practical difference is that GDPR applies the concept of "pseudonymisation" (which can include encryption) as a means of reducing privacy risk and enabling certain processing activities. DPDPA has no equivalent pseudonymisation framework -- there is no "sensitive personal data" category either (the 2019 PDP Bill's special categories were dropped from the 2023 Act). Under DPDPA, all personal data is governed uniformly and encryption is a baseline safeguard, not a risk-reduction mechanism that unlocks different processing rules.

Is TLS 1.2 sufficient, or must we upgrade to TLS 1.3?

TLS 1.2 with AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) and ECDHE key exchange remains acceptable. TLS 1.3 is preferred because it eliminates vulnerable options by design -- there are no CBC cipher suites, no RSA key exchange, and the handshake is encrypted. If you are deploying new infrastructure, use TLS 1.3 exclusively. For legacy systems, TLS 1.2 with a restricted cipher suite is defensible.

Do we need to encrypt data that is already behind a VPC or private network?

Yes. Rule 6(1)(a) makes no exception for network topology. Defense-in-depth requires encryption at every layer. A VPC misconfiguration, compromised jump host, or insider threat can bypass network-level controls. Encryption at rest and in transit ensures the data remains protected regardless of network boundary failures.

How does encryption interact with the data erasure obligation under Section 8(7)?

Cryptographic erasure -- destroying the encryption key rather than overwriting the data -- is a valid erasure technique for encrypted data. When the KMS key is destroyed, the associated ciphertext becomes computationally irrecoverable. This is particularly useful for backup systems where direct data deletion is impractical. Ensure your KMS key lifecycle policy supports this by maintaining separate keys for data that may have different retention requirements.

What about client-side encryption for mobile applications?

Client-side encryption adds a layer of protection but does not replace server-side obligations. The Data Fiduciary remains responsible for encryption under Rule 6(1)(a) regardless of what the client does. Client-side encryption is a valuable defense-in-depth measure, particularly for data in transit, but your server-side encryption architecture must be independently compliant.

Our Data Processor says they use "encryption" but cannot specify the algorithm or key length. Is that acceptable?

No. Rule 6(1)(f) requires "appropriate provision in the contract" for security safeguards. "We use encryption" is not an appropriate provision. Your Data Processing Agreement should specify minimum acceptable algorithms (AES-256 at rest, TLS 1.3/1.2 in transit), key management requirements (customer-managed keys or HSM-backed), rotation schedules, and audit logging obligations. If a Data Processor cannot meet these specifications, that is a compliance risk for the Data Fiduciary.

Key Takeaways

• Rule 6(1)(a) puts encryption in the legal minimum, not just best practice. The DPDP Rules 2025 explicitly list "securing of personal data through encryption" (alongside obfuscation, masking and virtual tokens) among the minimum "reasonable security safeguards" under Section 8(5), applicable from 13 May 2027.
• Implement AES-256-GCM for data at rest and TLS 1.3 for data in transit. These are the prevailing industry standards that define "reasonable" in the DPDPA context. Use envelope encryption with KMS-managed keys to maintain key lifecycle control.
• Key management is where encryption implementations fail. Use cloud KMS services (AWS KMS, Azure Key Vault, GCP Cloud KMS) with HSM backing, automatic annual key rotation, IAM-gated access, and audit logging retained for a minimum of one year per Rule 6(1)(e).
• Encryption directly affects your penalty calculus. Section 33(2)(e) requires the Board to consider mitigation actions when determining penalties. Data encrypted with AES-256 that is exfiltrated without key compromise is computationally unusable -- this materially changes the severity assessment.
• Validate encryption configuration in your CI/CD pipeline. Use OPA policies against Terraform plans to enforce encryption at rest for every storage resource and encryption in transit for every network endpoint. Treat unencrypted personal data storage as a blocking deployment gate.
• Extend encryption requirements to Data Processors contractually. Rule 6(1)(f) requires your contract with each Data Processor to provide for reasonable security safeguards. Your DPAs must specify algorithm minimums, key management standards, and audit obligations.
• Log every key access event. Rule 6(1)(c) requires visibility into personal data access. KMS audit logs showing who decrypted what, when, and from where are essential evidence for a Board inquiry.

Next Steps

Need to architect DPDPA-compliant cryptographic controls for your data infrastructure? StateCheck Security designs encryption architectures that satisfy Rule 6(1)(a) across cloud providers, database systems, and application layers. We work with your infrastructure team to implement KMS configurations, validate TLS posture, and build the audit trail that demonstrates compliance when the Board asks.

Request a DPDPA Compliance Audit

Related Articles

• The DPDPA Breach Notification: Automating SIEM Alerts to Legal Workflows -- What happens when encryption fails to prevent a breach. Rule 6(1)(a) encryption controls and breach notification under Rule 7 (the two-clock model) are two sides of the same coin -- prevention and response.
• The DPDPA to ISO 27001 Mapping Guide: Leveraging Annex A for Privacy Compliance -- Maps Section 8(5) to ISO 27001:2022 A.8.24 (Use of cryptography) and the broader Annex A control set.
• Engineering Privacy by Design: Implementing DPDPA at the CI/CD Pipeline -- The OPA encryption policies in this article are one gate in a three-gate privacy-aware CI/CD pipeline. This companion piece covers the full pipeline architecture.
• Zero Trust Architecture as a DPDPA Compliance Enabler -- Encryption in transit (mTLS) is a core component of Zero Trust. This article covers the broader IAM and network architecture.