印度 DPDP 规则：2027 年 5 月之前要完成的工程工作
印度于 2025 年 11 月 13 日以 G.S.R. 846(E) 公告了《2025 年数字个人数据保护规则》（Digital Personal Data Protection Rules, 2025）。其中与您的产品相关的大部分规则尚未生效。第 1(4) 条规定，第 3 条、第 5 条至第 16 条、第 22 条和第 23 条“自本公报发布之日起十八个月后生效”。数满十八个月，就落在 2027 年 5 月 13 日，离今天只有七个多月。
这些条款涵盖告知、安全、泄露通报、保留与删除、儿童数据以及权利请求。允许同意管理人（Consent Manager）向数据保护委员会注册的第 4 条生效得更早：发布后一年，即 2026 年 11 月 13 日前后。政府的公告称之为 18 个月的分阶段时间表。
本文写给印度消费类应用、金融科技、教育科技和电子商务公司的 CTO 与产品负责人，以及拥有印度用户的外国公司。该法也适用于在印度境外进行的处理，只要它“与向印度境内的数据主体提供商品或服务的任何活动有关”（第 3(b) 条）。下文讲的是您必须构建或修改的软件，而不是一份法律差距评估：您是否在适用范围内、适用哪些豁免、您的目的如何措辞，这些都是律师的问题。
谁真正有开发工作要做
如果您所有的客户数据都放在一个套装 SaaS 平台上，那么大部分底层功能（加密、访问日志、删除任务）都来自厂商的路线图。您的工作是告知、配置和合同。要读一读那些合同：第 6(1)(f) 条要求把安全保障措施写进合同，第 8 条的一个示例还规定，您要对您的云服务商把数据和日志保存满规定的一年负责。
繁重的工作落在那些运行自己的应用和数据库、用十几条流水线向数据仓库供数、并在移动客户端中集成第三方 SDK 的公司身上。这几乎就是印度消费互联网的大部分。
每条规则对您的软件提出了什么要求
告知（第 3 条）
告知必须“能够独立于您发布的任何其他信息而被理解”。它至少要给出“此类个人数据的逐项说明”、特定目的，以及该处理所支持的商品、服务或用途的具体说明。它还必须说明如何撤回同意、行使权利以及向委员会投诉。
在实践中：
- 从数据清单生成告知。 逐个字段，对应到目的。“我们可能会收集诸如以下的信息”算不上逐项说明。
- 为每一份告知做版本管理。 每一条同意记录都必须指向用户看到的确切文本。
- 为多语言做规划。 该法第 6(3) 条要求提供以英语或宪法第八附表所列任何语言阅读同意请求的选项。把告知内容保存为可翻译的字符串，而不是 PDF。
- 覆盖现有用户。 第 5(2) 条要求“在合理可行的情况下尽快”向在该法生效之前已经给予同意的人发出告知。这是一次面向全体用户的推送。
同意、撤回和同意管理人
第 6 条下的同意必须是具体的，并限于目的所需的数据。第 6(10) 条把举证责任放在您身上：发生争议时，由您证明已经给出告知并取得了同意。正是这句话，决定了您需要一本同意账本，而不是一个布尔字段。
一本可用的账本，按用户和目的记录：告知版本、时间戳、渠道（网页、应用、同意管理人）以及操作（给予或撤回）。只追加，不修改。
撤回必须和给予同意一样容易（第 3(c)(i) 条，第 6(4) 条）。如果同意是在注册流程中轻点一下完成的，撤回就不能是给客服发一封邮件。撤回还必须传递出去。第 6(6) 条要求您在合理时间内停止处理，并使您的数据处理者停止处理。所以，同意服务要把撤回事件发布给每一个基于该目的行事的系统和供应商：CRM、营销平台、分析流水线。
同意管理人是一个经注册的单一联络点，用户可以通过它“给予、管理、查看或撤回其同意”（第 6(7) 条）。根据第一附表，它必须是在印度注册成立、净资产至少 2000 万卢比的公司，其平台必须依据委员会公布的标准通过独立认证，它不得能够读取其所传递的数据，并且须将同意记录保存至少七年。
规则把这项标准留给委员会制定。现在就构建一条入站路径，让来自外部平台的同意或撤回，与来自您自己界面的完全一样地得到处理，并且只在委员会公布传输格式之后才确定采用哪种格式。注册在 2026 年 11 月 13 日前后开放，所以现实地说，集成要到 2027 年初才会开始。
安全保障措施和日志（第 6 条）
最低清单包括：加密、混淆、掩码或令牌化；对相关系统的访问控制；“通过适当的日志、监控和审查，对此类个人数据的访问保持可见”；备份，以便在事件发生后继续处理；以及“将此类日志和个人数据保留一年”。
大多数系统在日志要求上有欠缺。基础设施日志无法告诉您是谁从哪个服务读取了哪个客户的记录，而一年之后您需要这个答案。所以：在每一个个人数据存储上做应用层的访问日志，把日志送到服务无法篡改的地方，至少保留一年。尽早开始；在众多服务中推开这件事，比这里任何单项功能花的时间都长。
泄露通报（第 7 条）
在知悉泄露后，您要通过用户账户或已登记的联系渠道“毫不迟延地”告知每一位受影响的用户：发生了什么、对他们可能造成的后果、您正在做什么、他们可以做什么，以及联系谁。委员会要毫不迟延地收到一份说明，然后在 72 小时内收到一份详细报告，内容包括原因、缓解措施、关于肇事者的任何调查结果、补救措施以及已向用户发出的通报。经书面请求，委员会可以允许更长的时间。
在软件上：一种计算受影响范围的方法（这取决于上面说的访问日志）、事先写好的模板、一条不经过被入侵系统的通知路径，以及一份写明由谁向委员会提交报告的运行手册。
删除与保留（第 8 条）
第 8(7) 条要求在同意被撤回或目的不再存续时删除数据，除非其他法律要求保留。第 8 条又加了两点。
第一，第三附表所列的三类主体，在三年没有联系之后被视为目的终止：在印度拥有至少 2000 万注册用户的电子商务实体、至少 500 万注册用户的在线游戏中介，以及至少 2000 万注册用户的社交媒体中介。账户访问和储值代币除外。您必须在删除前至少 48 小时提醒用户，而一次登录就会取消删除。这需要一个不活跃状态跟踪器、一个调度器和一个通知任务。这三年从最后一次联系或规则生效之日起算，以较晚者为准，所以多年内都不会有删除到期，但跟踪必须从一开始就是正确的。
第二，第 8(3) 条设定了一个下限：个人数据、流量数据和处理日志，自处理之日起至少保留一年。该条的示例是一笔电子书订单，其详细信息在账户删除后必须保留。所以“删除我的账户”不能等于 DELETE FROM users。它意味着：停止处理，把必须保留的内容移入一个带保留期限的受限存储，期限届满时再删除。每一张表都需要一个保留类别，备份、数据仓库和您的处理者系统中的每一份副本也一样。
权利请求和联系方式（第 9 条和第 14 条）
用户可以要求获得其数据和处理情况的摘要，以及您与之共享数据的每一个受托人和处理者的身份（第 11 条），可以要求更正、补全、更新或删除（第 12 条），并可以指定一人在其死亡或丧失行为能力时代为行使权利（第 14 条）。第 14 条要求您公布提出请求的方式和所需的标识符，并在公布的期限内答复投诉，该期限不得超过九十天。第 9 条要求在每一次答复中都附上您的数据保护官，或一位能够答复问题的人员的联系方式。
需要构建的有：应用内的请求受理、与账户绑定的身份核验、一个按九十天计时的案件跟踪器、一个能跨服务找到用户数据的导出功能，以及一份共享登记簿，让“您和谁共享了数据”成为一次查询，而不是一次调查。
儿童和残障人士（第 10 条至第 12 条）
根据该法，儿童是指未满十八岁的任何人。在处理儿童数据之前，您需要父母可核验的同意，而第 10 条要求核实父母是一名身份可识别的成年人。核实可以使用您已经掌握的已注册父母的身份和年龄信息、父母提供的信息，或者由授权实体提供的“与此类信息相对应的虚拟令牌”，授权实体包括数字储物柜（Digital Locker）服务提供商。印度电子和信息技术部（MeitY）的 DigiLocker 为获取经核验文件的机构发布了请求方 API；请律师确认哪些来源能在您的流程中满足该规则。
第 9(3) 条禁止针对儿童的跟踪、行为监测和定向广告。对于消费类应用，这是一个 SDK 问题，稳妥的默认做法是对任何被标记为未成年人的账户直接关闭分析和广告 SDK，而不是试图把它们配置到合规状态。
第 11 条涉及残障人士的合法监护人：您要核实该监护人是由法院、指定机关或地方委员会指定的。这需要一个文件上传功能和一个人工审核队列。
第 12 条和第四附表把部分处理排除在父母同意要求和跟踪禁令之外，其中包括医疗保健、教育机构（用于教育活动和安全）、出于安全目的的实时定位，以及确认用户不是儿童。教育科技公司不应想当然地认为自己算作“教育机构”。要拿到书面答复。
重要数据受托人（第 13 条）
如果政府把您公告为重要数据受托人（Significant Data Fiduciary），第 13 条会增加以下要求：年度数据保护影响评估和审计，并向委员会提交报告；尽职调查，确保您的算法软件不会危及用户的权利；以及把政府指定的任何个人数据保留在印度境内。该法第 10 条还要求设立常驻印度的数据保护官和独立数据审计师。
出错的代价
该法的附表规定了最高罚款：未采取合理安全保障措施的，最高 25 亿卢比；未通报泄露的，最高 20 亿卢比；违反儿童数据相关义务的，最高 20 亿卢比；违反重要数据受托人附加义务的，最高 15 亿卢比；违反其他任何规定的，最高 5 亿卢比。
七个月计划
2026 年 10 月：盘点。 列出每一个存有印度用户个人数据的存储和流水线，包括备份、数据仓库、日志和处理者。把每个字段对应到一个目的。标记儿童用户，核对第三附表的门槛，并就适用范围和豁免听取律师意见。
2026 年 11 月：设计。 告知内容模型和版本管理、同意账本的数据结构、每张表的保留类别、权利请求流程。开始做访问日志。11 月 13 日前后之后，关注委员会公布的已注册同意管理人和互操作标准。
2026 年 12 月至 2027 年 1 月：告知与同意。 上线同意服务，把撤回事件分发给各处理者。翻译告知内容。
2027 年 2 月：保留与删除。 受限保留存储、覆盖主存储和处理者的删除任务，以及（如果您属于第三附表所列类别）不活跃状态跟踪器。修订处理者合同，加入安全保障措施和一年保留期的条款。
2027 年 3 月：权利与泄露。 请求受理、核验、九十天案件跟踪器、跨服务导出、共享登记簿。泄露运行手册、模板和一条独立的通知路径，然后做一次桌面演练。
2027 年 4 月：儿童与现有用户。 年龄门槛、父母核验、针对未成年人的 SDK 开关、监护人审核。向现有用户发出第 5(2) 条要求的告知。如果标准已经发布，就与同意管理人集成。
2027 年 5 月上旬：测试与冻结。 撤回一项同意，确认营销平台已经停止。提出一次删除请求，确认数据仓库中的副本已经进入保留状态。整理好证据，并在 5 月 13 日之前的那一周停止任何变更。
这个计划假定有三到四条并行的工作线。对于较老或缺乏文档的系统，光是盘点就要花一个多月。
本文的位置
如果您曾为 GDPR 做过开发，相当一部分底层功能可以沿用，我们的 GDPR 工程指南介绍了同意和删除的模式。真正让人吃力的差异在于逐项告知、一年保留下限，以及对十八岁以下用户需要可核验的父母同意。关于另一个有自己监管制度的亚洲市场，请参阅印尼 PSE 注册。
我们在现有产品中构建同意服务、保留与删除任务、访问日志和权利请求流程；当计划需要的人手超过您现有的人手时，我们也通过人员增补为您的团队补充工程师。我们是工程师，不是律师：适用范围和措辞属于您的律师，我们按照他们的答复来构建。请写信到 office@c9group.dev。