Las DPDP Rules de India: el trabajo de ingeniería que vence en mayo de 2027

India publicó las Digital Personal Data Protection Rules, 2025 el 13 de noviembre de 2025, como G.S.R. 846(E). La mayoría de las normas que afectan a tu producto todavía no están en vigor. La regla 1(4) dice que las reglas 3, de la 5 a la 16, 22 y 23 «entrarán en vigor dieciocho meses después de la fecha de publicación de esta Gaceta». Cuenta dieciocho meses y llegas al 13 de mayo de 2027, algo más de siete meses a partir de hoy.

Esas reglas cubren los avisos, la seguridad, la comunicación de brechas, la conservación y la supresión, los datos de menores y las solicitudes de derechos. La regla 4, que permite a los Consent Managers registrarse ante la Data Protection Board, llega antes: un año después de la publicación, así que en torno al 13 de noviembre de 2026. El anuncio del Gobierno lo llama un calendario escalonado de 18 meses.

Esto va dirigido a los CTO y a los responsables de producto de aplicaciones de consumo, fintechs, edtechs y empresas de comercio electrónico indias, y de empresas extranjeras con usuarios en India. La Ley alcanza el tratamiento fuera de India cuando se realiza «en relación con cualquier actividad vinculada a la oferta de bienes o servicios a titulares de los datos en el territorio de India» (sección 3(b)). Lo que sigue es el software que tienes que construir o cambiar. No es un análisis jurídico de carencias: si estás dentro del ámbito, qué exenciones se aplican y cómo se redactan tus finalidades son preguntas para tus abogados.

Quién tiene trabajo de desarrollo de verdad

Si todos los datos de tus clientes están en una única plataforma SaaS estándar, buena parte de la fontanería (cifrado, registros de acceso, procesos de supresión) viene de la hoja de ruta del proveedor. Tu trabajo son los avisos, la configuración y los contratos. Lee esos contratos: la regla 6(1)(f) quiere las medidas de seguridad por escrito en ellos, y un ejemplo de la regla 8 te hace responsable de que tu proveedor cloud conserve los datos y los registros durante el año exigido.

El trabajo pesado recae en las empresas que gestionan sus propias aplicaciones y bases de datos, alimentan un almacén de datos con una docena de canalizaciones y llevan SDK de terceros en el cliente móvil. Es decir, en la mayor parte del internet de consumo indio.

Qué pide cada regla a tu software

Aviso (regla 3)

El aviso tiene que ser «comprensible por sí mismo, con independencia de cualquier otra información» que publiques. Como mínimo, ofrece «una descripción detallada de dichos datos personales», la finalidad específica y una descripción concreta de los bienes, servicios o usos que permite el tratamiento. También tiene que explicar cómo retirar el consentimiento, ejercer los derechos y presentar una reclamación ante la Board.

En la práctica:

• Genera los avisos a partir de un inventario de datos. Campo a campo, con su correspondencia con las finalidades. «Podemos recopilar información como» no es una descripción detallada.
• Versiona cada aviso. Cada registro de consentimiento tiene que apuntar al texto exacto que vio el usuario.
• Planifica los idiomas. La sección 6(3) de la Ley exige ofrecer la posibilidad de leer una solicitud de consentimiento en inglés o en cualquier idioma del Octavo Anexo de la Constitución. Guarda el contenido de los avisos como cadenas traducibles, no como un PDF.
• Cubre a los usuarios existentes. La sección 5(2) exige enviar un aviso, «tan pronto como sea razonablemente posible», a quienes dieron su consentimiento antes de la entrada en vigor de la Ley. Eso es una campaña a toda tu base de usuarios.

Consentimiento, retirada y Consent Managers

El consentimiento conforme a la sección 6 tiene que ser específico y limitarse a los datos que necesita la finalidad. La sección 6(10) te atribuye la carga de la prueba: en caso de conflicto, eres tú quien demuestra que se dio el aviso y se obtuvo el consentimiento. Esa frase es la razón por la que necesitas un registro de consentimientos y no una columna booleana.

Un registro que funcione anota, por usuario y finalidad: la versión del aviso, la marca de tiempo, el canal (web, aplicación, Consent Manager) y la acción (otorgado o retirado). Solo se añaden entradas.

Retirar el consentimiento tiene que ser tan fácil como darlo (regla 3(c)(i), sección 6(4)). Si el consentimiento fue un toque durante el alta, la retirada no puede ser un correo al soporte. Además, tiene que propagarse. La sección 6(6) exige dejar de tratar los datos, y hacer que tus encargados del tratamiento lo dejen también, en un plazo razonable. Así que el servicio de consentimiento publica los eventos de retirada a todos los sistemas y proveedores que actúan sobre esa finalidad: CRM, plataforma de marketing, canalización de analítica.

Un Consent Manager es un punto de contacto único registrado a través del cual un usuario puede «dar, gestionar, revisar o retirar su consentimiento» (sección 6(7)). Según el Primer Anexo, tiene que ser una sociedad constituida en India con un patrimonio neto de al menos dos crore de rupias (20 millones), su plataforma tiene que estar certificada de forma independiente conforme a las normas que publique la Board, no puede poder leer los datos que encamina y conserva los registros de consentimiento durante al menos siete años.

Las reglas dejan esa norma en manos de la Board. Construye ya una vía de entrada, de modo que un consentimiento o una retirada que llegue desde una plataforma externa se trate exactamente igual que uno de tu propia interfaz, y comprométete con un formato de intercambio solo cuando la Board lo publique. El registro se abre en torno al 13 de noviembre de 2026, así que la integración empezará, en la práctica, a principios de 2027.

Medidas de seguridad y registros (regla 6)

La lista mínima: cifrado, ofuscación, enmascaramiento o tokenización; control de acceso a los sistemas implicados; «visibilidad sobre el acceso a dichos datos personales, mediante registros, supervisión y revisión adecuados»; copias de seguridad para que el tratamiento pueda continuar tras un incidente; y conservación de «dichos registros y datos personales durante un periodo de un año».

El requisito de registro es donde fallan la mayoría de los sistemas. Los registros de infraestructura no te dicen quién leyó la ficha de qué cliente desde qué servicio, y necesitas esa respuesta un año después. Por tanto: registro de accesos a nivel de aplicación en cada almacén de datos personales, enviado a un sitio que los servicios no puedan alterar y conservado al menos un año. Empieza pronto; desplegarlo en muchos servicios lleva más tiempo que cualquier otra funcionalidad de esta lista.

Comunicación de brechas (regla 7)

En cuanto tengas conocimiento de una brecha, informas a cada usuario afectado «sin demora», a través de su cuenta o de un canal de contacto registrado: qué ha pasado, las consecuencias probables para él, qué estás haciendo, qué puede hacer él y a quién contactar. La Board recibe una descripción sin demora y, en un plazo de 72 horas, un informe detallado sobre las causas, la mitigación, cualquier conclusión sobre quién la causó, las medidas correctoras y las comunicaciones enviadas a los usuarios. La Board puede conceder más tiempo si se le pide por escrito.

En software: una forma de calcular el conjunto de afectados (que depende de los registros de acceso de arriba), plantillas redactadas de antemano, una vía de notificación que no pase por el sistema vulnerado y un procedimiento que indique quién presenta la comunicación ante la Board.

Supresión y conservación (regla 8)

La sección 8(7) exige suprimir los datos cuando se retira el consentimiento o la finalidad deja de cumplirse, salvo que otra ley exija conservarlos. La regla 8 añade dos cosas.

Primero, a tres categorías del Tercer Anexo se les aplica un fin presunto de la finalidad tras tres años sin contacto: las entidades de comercio electrónico con al menos dos crore (20 millones) de usuarios registrados en India, los intermediarios de juego en línea con al menos cincuenta lakh (5 millones) y los intermediarios de redes sociales con al menos dos crore. Se exceptúan el acceso a la cuenta y los tokens virtuales con valor almacenado. Tienes que avisar al usuario al menos 48 horas antes de la supresión, y un inicio de sesión la cancela. Eso es un rastreador de inactividad, un planificador y un proceso de notificación. Los tres años cuentan desde el último contacto o desde la entrada en vigor de las Rules, lo que ocurra más tarde, así que no vence ninguna supresión en años, pero el seguimiento tiene que ser correcto desde el principio.

Segundo, la regla 8(3) fija un mínimo: los datos personales, los datos de tráfico y los registros del tratamiento se conservan al menos un año desde el tratamiento. El ejemplo de la regla es un pedido de un libro electrónico cuyos detalles tienen que sobrevivir a la eliminación de la cuenta. Así que «eliminar mi cuenta» no puede significar DELETE FROM users. Significa: dejar de tratar, trasladar lo que haya que conservar a un almacén restringido con una fecha de conservación, y suprimirlo cuando pase esa fecha. Cada tabla necesita una clase de conservación, y también cada copia en las copias de seguridad, en el almacén de datos y en los sistemas de tus encargados.

Solicitudes de derechos y datos de contacto (reglas 9 y 14)

Los usuarios pueden pedir un resumen de sus datos y del tratamiento y la identidad de todos los responsables y encargados con los que los compartiste (sección 11), pedir su corrección, compleción, actualización o supresión (sección 12) y designar a alguien que actúe en su nombre en caso de fallecimiento o incapacidad (sección 14). La regla 14 te exige publicar cómo se presenta una solicitud y qué identificador necesitas, y responder a las reclamaciones en un plazo publicado de no más de noventa días. La regla 9 exige incluir en cada respuesta los datos de contacto de tu delegado de protección de datos, o de alguien que pueda responder.

Qué construir: entrada de solicitudes en la aplicación, verificación de identidad vinculada a la cuenta, un gestor de casos que lleve la cuenta de los noventa días, una exportación que encuentre los datos de un usuario en todos los servicios y un registro de comunicaciones de datos para que «¿con quién los compartisteis?» sea una consulta y no una investigación.

Menores y personas con discapacidad (reglas 10 a 12)

Según la Ley, un menor es cualquier persona de menos de dieciocho años. Antes de tratar datos de un menor necesitas el consentimiento verificable de un progenitor, y la regla 10 exige comprobar que el progenitor es un adulto identificable. La comprobación puede usar datos de identidad y edad que ya tengas de un progenitor registrado, datos que aporte el propio progenitor o «un token virtual vinculado a dichos datos» procedente de una entidad autorizada, lo que incluye a un proveedor de servicios Digital Locker. DigiLocker, del MeitY, publica API para solicitantes dirigidas a las organizaciones que obtienen documentos verificados; pide a tus abogados que confirmen qué fuentes cumplen la regla en tus flujos.

La sección 9(3) prohíbe el seguimiento, la supervisión del comportamiento y la publicidad dirigida a menores. Para una aplicación de consumo, eso es un problema de SDK, y la opción por defecto segura es desactivar los SDK de analítica y de publicidad en cualquier cuenta marcada como de un menor, en lugar de configurarlos para que cumplan.

La regla 11 cubre a los tutores legales de personas con discapacidad: verificas que el tutor fue nombrado por un tribunal, por una autoridad designada o por un comité local. Eso es una subida de documentos y una cola de revisión manual.

La regla 12 y el Cuarto Anexo eximen algunos tratamientos del requisito de consentimiento parental y de la prohibición de seguimiento, entre ellos la asistencia sanitaria, los centros educativos (para actividades educativas y de seguridad), la ubicación en tiempo real por motivos de seguridad y la comprobación de que un usuario no es menor. Una edtech no debería dar por hecho que cuenta como «centro educativo». Consigue esa respuesta por escrito.

Significant Data Fiduciaries (regla 13)

Si el Gobierno te designa Significant Data Fiduciary, la regla 13 añade una evaluación de impacto relativa a la protección de datos y una auditoría anuales con informe a la Board, una diligencia debida para que tu software algorítmico no ponga en riesgo los derechos de los usuarios y la obligación de mantener en India los datos personales que especifique el Gobierno. La sección 10 de la Ley añade un delegado de protección de datos con base en India y un auditor de datos independiente.

Lo que cuesta equivocarse

El Anexo de la Ley fija las sanciones máximas: hasta 250 crore de rupias (2.500 millones) por no adoptar medidas de seguridad razonables, hasta 200 crore (2.000 millones) por no notificar una brecha, hasta 200 crore por incumplir las obligaciones sobre los datos de menores, hasta 150 crore (1.500 millones) por las obligaciones adicionales de una Significant Data Fiduciary y hasta 50 crore (500 millones) por incumplir cualquier otra disposición.

Un plan de siete meses

Octubre de 2026: inventario. Haz una lista de todos los almacenes y canalizaciones que contienen datos personales de usuarios indios, incluidas las copias de seguridad, el almacén de datos, los registros y los encargados. Asigna cada campo a una finalidad. Marca a los usuarios menores, comprueba los umbrales del Tercer Anexo y pide la opinión de tus abogados sobre el ámbito y las exenciones.

Noviembre de 2026: diseño. Modelo de contenido y versionado de los avisos, esquema del registro de consentimientos, clases de conservación por tabla y flujo de solicitudes de derechos. Empieza el registro de accesos. A partir del 13 de noviembre, aproximadamente, sigue en la Board los Consent Managers registrados y la norma de interoperabilidad.

De diciembre de 2026 a enero de 2027: avisos y consentimiento. Pon en marcha el servicio de consentimiento, con los eventos de retirada propagados a los encargados. Traduce los avisos.

Febrero de 2027: conservación y supresión. Almacén de conservación restringido, procesos de supresión en los almacenes principales y en los encargados, y el rastreador de inactividad si estás en una categoría del Tercer Anexo. Modifica los contratos con los encargados para incluir las medidas de seguridad y la conservación de un año.

Marzo de 2027: derechos y brechas. Entrada de solicitudes, verificación, el gestor de casos con los noventa días, la exportación entre servicios y el registro de comunicaciones. Procedimiento de brechas, plantillas y una vía de notificación independiente, y después un simulacro de mesa.

Abril de 2027: menores y usuarios existentes. Control de edad, verificación del progenitor, desactivación de SDK para menores y revisión de tutores. Envía el aviso de la sección 5(2) a los usuarios existentes. Intégrate con los Consent Managers si la norma ya está publicada.

Principios de mayo de 2027: pruebas y congelación. Retira un consentimiento y confirma que la plataforma de marketing ha dejado de tratar los datos. Solicita una supresión y confirma que la copia del almacén de datos ha pasado a conservación. Reúne las evidencias, y deja de cambiar cosas la semana anterior al 13 de mayo.

Esto supone tres o cuatro líneas de trabajo en paralelo. En sistemas antiguos o sin documentar, el inventario por sí solo lleva más de un mes.

Dónde encaja esto

Si construiste para el RGPD, buena parte de la fontanería se aprovecha, y nuestra guía de RGPD orientada a ingeniería cubre los patrones de consentimiento y supresión. Las diferencias que duelen son el aviso detallado, el mínimo de conservación de un año y el consentimiento parental verificable hasta los dieciocho años. Para otro mercado asiático con su propio régimen, consulta el registro PSE de Indonesia.

Incorporamos a productos existentes servicios de consentimiento, procesos de conservación y supresión, registro de accesos y flujos de solicitudes de derechos, y sumamos ingenieros a tu equipo mediante la ampliación de equipos cuando el plan necesita más manos de las que tienes. Somos ingenieros, no abogados: el ámbito y la redacción les corresponden a tus abogados, y nosotros desarrollamos según su respuesta. Escribe a office@c9group.dev.