印度 DPDP 规则落地后先改哪三处：同意取证、90 天请求响应和泄露通报

一听说印度的数据保护规则出来，不少团队的第一反应是：那我把服务器搬到印度去。机房选好、迁移排期拉出来、域名解析切过去，三个月忙完，回头一看，通知书里列的义务一条没少。原因很简单，这套规则约束的是你怎么处理个人数据，不是机器摆在哪块土地上。位置变了，行为没变，风险敞口原地不动。

误区：把服务器搬进印度，换来的是交付时延，不是义务减免

这个误会之所以顽固，是因为它符合直觉。跨境业务里我们习惯了「物理位置决定法律管辖」的思路：数据落在哪个国家，就归哪个国家管。于是遇到新规则，第一反应就是把物理位置挪过去，眼不见为净。

但《数字个人数据保护法》（DPDP Act, 2023）这套框架的落点是数据受托方（Data Fiduciary）的行为义务：给没给通知、同不同意到位、请求有没有按期答、泄露有没有通报、安全保障措施有没有维持。这几条跟你把机器放在孟买、放在新加坡还是放在法兰克福，没有直接的抵扣关系。搬机器只能在很少的几件事上帮到你——比如某些类别的数据被要求留在境内时，本地节点是唯一能落地的选项；再比如面向印度用户的写入延迟确实会降一些。这些都是交付侧收益，不是合规侧收益。

更实际的一点是，本地化要求在这套规则里是「政府可以通过通知指定」的形态，作用在「特定类别的数据」上，而不是一刀切的全量数据。也就是说，在你没搞清楚自己手上哪些数据属于可能被指定的类别之前，全量迁移是一笔花在不确定收益上的钱。真要动手，顺序反过才对：先盘数据流，再决定机器放哪。

一万网络深耕 IDC 19 年（成立于 2007 年），印度及南亚方向的节点资源与合同口径可以提前问清楚，但合规改造这部分只能由业务方自己认领。

规则实际给的是什么时间表：三档，不是一次到期

真正决定你现在该干什么的，是规则给出的分阶段实施表。印度电子和信息技术部（MeitY）在 2025-11-13 通知发布了《2025 年数字个人数据保护规则》（DPDP Rules, 2025），让法案从「通过」进入「分批开闸」。这批通知之前共收到 6,915 条公众意见。时间表分三档，每一档对应完全不同的工作量。

第一档，即时生效（2025-11-13 起）。法案第 1(2)、2、18 至 26、35、38 至 43 条，以及 44(1)、44(3) 条；规则第 1、2、17 至 21 条。这一档的核心是设立并运作印度数据保护委员会（Data Protection Board of India），也就是把监管主体先立起来。对企业来说，这一档的直接动作不多，但它意味着从此有一个可以对着你提问的机构存在。

第二档，一年内（约 2026-11）。法案第 6(9)、27(1)(d) 条；规则第 4 条。内容是同意管理器（Consent Manager）的注册与运作。这一档看着只涉及两个条款半，但它牵扯的是架构：同意管理器必须是印度公司，而且要向委员会注册。你不可能临时换一家，也不可能自己封一枚内部开关冒充。

第三档，十八个月内（约 2027-03）。法案第 3 至 5 条、6(1) 至 6(8) 条、6(10) 条、7 至 10 条、11 至 17 条、27 条（27(1)(d) 除外）、28 至 34 条、36、37、44(2) 条；规则第 3、5 至 16、22、23 条。通知、同意、数据主体权利、安全保障措施、泄露通报——这是本篇要讲的三处改造全部在这一档。

这里要打断一下「十八个月很充裕」的错觉。它是从 2025-11-13 起算的，不是从你读到这篇文章起算；剩下的时间里，真正能改的是你的日志结构、你的身份主键设计、你的存储分层，而这些东西一旦上线再改，代价是成倍往上走的。同意记录补录不了，历史操作日志造不出来，这些只能往前留，不能回头补。

第一处改造：通知与同意必须能取证，而不是能弹窗

先看通知（Notice）的规则要求。数据受托方给出的通知必须独立、清晰、通俗易懂，要说明清楚三件事：收集的具体个人数据是什么、处理目的是什么、以及不提供这些数据会怎样。同时要提供撤回同意的途径（撤回必须和给出一样容易）、行使权利的途径、以及向委员会投诉的途径。

「独立」这个词在系统设计里最容易被牺牲掉。常见的做法是把它塞进注册流程的一个折叠条款里，或者做成一堵看不完的长墙——这在工程上省事，在规则语言里是不成立的。拆出来看它的实际含义：通知是一个有版本、有内容、能对得上某次具体收集的独立对象，而不是页面上的一段 HTML。

所以取证改造的核心是：把「用户看到了什么」这件事从 UI 里抽出来，落成一条不可抵赖的记录。一条可用的同意凭证至少要带这些字段——同意事件唯一标识、主体在本系统的标识、当时生效的通知版本号、通知内容的哈希、同意的具体目的集合、采集渠道、语言版本、时间戳、以及与之对应的撤回操作指针。少了通知版本号和内容哈希，你将来只能证明「他点过同意」，证明不了「他同意的是哪一版内容」，而这恰恰是争议发生时的焦点。

撤回的对称性也是工程问题，不是文案问题。给出同意是一次点击就完成的话，撤回就必须也是一次点击能完成。如果你的同意在前端一次写入、撤回却要发邮件找客服走工单，那这个「一样容易」当场就不成立。更隐蔽的一种错配是：同意写进了业务库的主流程，撤回却只改了营销标签，下游的推荐、画像、广告回传仍然按「已同意」跑，等于撤了个寂寞。

留多久这件事，规则里没有给出一个通用数字，所以别去猜一个填进参数表。正确的定法是倒推：从你最长的举证周期往回推。举证周期取决于你的争议解决节奏和用户回访窗口，取决于你的业务是否涉及长期订单、是否涉及儿童（儿童的处理有可验证监护人同意的要求）、以及是否被认定为重要数据受托方（Significant Data Fiduciary，有独立审计和影响评估的附加义务，审计报告天然要求你拿得出跨期间的证据）。换句话说，留存期不是一个合规参数，是几个不同期限取最大值的结果。

同意管理器注册在最前面：它是印度公司，替换成本不在你手里

三档时间表里最容易被人忽略的一件事：同意管理器的那一档比主体义务早。规则第 4 条在约 2026-11 就到位，规则第 3、5 至 16 条要到约 2027-03。这意味着你要先确定「由谁来管同意」这件事，再去做通知和同意的落地——顺序反了会返工。

约束是明确的：同意管理器必须是印度公司，且须向委员会注册。这一条把很多「我们自己在内部做一个同意中心」的想法直接否掉了。你可以在内部做同意的记录与执行，但那一层由其承担的职责，不能靠自封替代。

从工程接口看，需要提前确认几件事：你的同意凭证 ID 能否被对方引用和回查；撤回事件是推还是拉，超时怎么定；用户在管理器侧改了同意，你的下游同步延迟上限是多少，在这段延迟窗口里已经触发的处理动作要不要回滚；以及历史同意在切换管理器时怎么迁移，迁移后旧的版本号还能不能被验证。这些都不是上线前一周能谈完的事，而一旦选定了某家，切换本身的成本就不在你手里了。

第二处改造：一个数据主体请求，要在多少个系统里传播

接下来是真正吃成本的一处。数据主体可以提出访问、更正、更新、删除类请求，规则给的响应上限是最长 90 天。同时，申诉处理流程必须在网站或应用上公布，并且要在合理时间内响应，同样不超过 90 天。

90 天听起来宽裕到近乎放松。但你把手摊开数一遍系统会经历什么，感受会立刻变。

假设一个用户在你的 App 里提交了「删除我的全部个人数据」。这条请求要传播的终点大概包括：账号与主库里的用户表、订单与账单系统、客服工单库、营销与消息推送系统、埋点与行为分析管道、数据仓库与下游报表、搜索索引与缓存、对象存储里的导出文件与账单 PDF、邮件与短信服务商那边的联系人副本、以及备份与快照。如果你的业务还涉及代为处理的其他受托方，链条还要往外延一层。

这条链路上最难的不是删除，是定位。绝大多数公司的用户标识在各系统之间是不统一的：App 用设备 ID，业务库用自增 ID，分析管道用匿名 ID，客服用手机号，邮件服务商用邮箱。一个主体进来，如果没有一张稳定的身份映射表，你要做的是一次跨系统的身份拼图，而这张拼图本身往往没有时效保证。判断题变成了：你怎么证明你找全了？

第二个难点是备份。删除指令落到备份里通常只有两种处理方式：把备份也擦一遍（成本高且会破坏快照的完整性设计），或者明确记录该条数据在备份中的存活窗口，并在恢复流程里挂一道「重删过滤器」——恢复之后再执行一次针对这批黑名单标识的删除。第二种在工程上现实得多，但它要求你的备份可被检索，且恢复时有明确的钩子。纯冷热分离的磁带层在这里会成为流程断点。

第三个难点是已触发动作的不可撤回。消息已经发出去了、推荐已经生成了、第三方回传已经握手了。这里要提前定的边界是：你承诺的是「停止后续处理」还是「抹掉历史痕迹」，两者的工作量差一个数量级，而在外部相邻的处理者那里，你能控制的通常只有前者。

90 天怎么倒排：把它砍成几截，每截留出自检

把 90 天摊成一条直线用是最常见的死法——第 85 天发现某个系统的删除回调没生效，已经没有重做的时间。

比较稳的切法是分成先行段、执行段、复核段。先行段做身份核验与资产定位，也就是上面说的那张身份映射与系统清单；这一段必须产出一份可核对的清单：主体在各系统的标识、涉及的数据域、预计处理动作。执行段按顺序下发给各系统，发一个记一个，用 ticket 状态而不是口头确认。复核段不看工单是否「已完成」，而是去每个系统抽验实际结果，尤其是那些异步队列订阅的系统，常常接受了指令但执行失败且没有报错。

每一段内部还要留自检时间，因为你要交出去的东西不是「我们尽力了」，而是「本次请求的闭环材料」。闭环材料包括：受理时间戳、核验方式记录、各系统的处理回执、无法处理项的原因说明、最终回复内容与发送通道、以及申诉入口有没有在回复里给到。少了最后一项，你在 90 天框架下的第二道门（申诉）就没关上。

还有一点，公布申诉流程这件事本身要落到界面上，不是写在法律文书里。它的验收标准应该具体到：在网站的哪个页面可见、从提交入口几步可达、回复承诺时限写没写清楚、以及调用方是谁。这些属于「30 分钟能改完但没人改」的那类缺陷。

第三处改造：泄露通报是一条时效链路，不是一封邮件

第三处是个人数据泄露。规则的描述是：数据受托方须及时（promptly）以通俗语言告知受影响的个人，说明事件的性质与可能后果、已采取的措施、以及可以求助的联系方式；同时通知数据保护委员会。

「及时」这两个字比一个明确的小时数更难对付。给了具体小时数的规则，你可以倒排：检测 → 定性 → 通知，每步占多少。只写「及时」的规则，等于把时钟的判断权交给了事后审查的人，而你必须在事前就证明自己的链路足够快。所以工程上的应对不是凑一个数，而是压缩掉链路上的不确定性。

先看成文要求。受影响的个人要被告知的内容是四项：事件性质、可能后果、已采取措施、可求助的联系方式。这四项里最难在慌乱中备齐的是第二项和第三项——它们需要事实支撑，而事实来自取证。如果你的日志留存不足、或者日志与业务库同库同删、或者日志采集那一层没有独立留存，泄露发生时你会在「要尽快通报」和「还不知道发生了什么」之间硬顶。

再看通知对象。受影响个人的名单不是从通讯录里导出的，是从受影响数据域反查出来的。这就要求你平时就知道：哪张表对应哪一类数据、哪类数据关联哪些主体标识、能不能在给定时间内把这个名单跑出来。这项能力平时完全隐形，出事当天成为唯一瓶颈。

这条链路上的典型失效其实是组织层的：检测到的是安全团队，决定是否构成泄露的是法务，知道受影响范围的是数据团队，能发出去的是运营，而计时器从第一秒就在走。可验收的做法是把链路前置成一份「预签署决策树」——什么级别的事情由谁在什么条件下直接触发通报动作，哪些情况必须升级。等到事件来了再拉个群讨论要不要通报，时间已经不在你手里。

处罚是记得清楚的：未维持合理安全保障措施，最高 25 亿卢比（₹250 crore）；未按要求通报泄露、或违反与儿童相关的义务，最高 20 亿卢比（₹200 crore）；其他违规，最高 5 亿卢比（₹50 crore）。把「没通报」单独列出一档，本身就说明了立法者对这条链路的重视程度——它不是一个通知偏好，是一条独立义务。

这三处改造对机器、存储和日志意味着什么

到这里可以把共性的技术结论抽出来。三处改造指向同一批底层能力：

其一，日志与业务库必须解耦。如果业务库的删除操作会连带删掉操作日志，那么「请求处理留痕」和「泄露取证」这两件事会同时失效。审计类日志要写在与业务数据不同的生命周期策略上，访问权限也要分开——能删业务记录的人不应该同时能删掉自己删过的证据。

其二，留存期要分层定，不要全局一刀切。同意凭证、请求处理记录、权利请求工单、安全事故日志这几类东西的留存，应该分别按各自的举证周期计算，而不是统统套一个磁盘预算。冷热分层在这里的价值不是省钱，是让「长周期留存」这件事在成本上变得可做：热层保证可查，冷层保证可在要求时还原。

其三，跨区复制会牵动存储。这一点最容易被架构评审漏掉。当存在副本时，「删除」的语义从单机操作变成了分布式一致性问题：源删了，副本有没有删；副本删了，快照里的历史有没有被抬出来；新加的一个只读从库有没有被纳入删除登记的范围。任何一条没接进删除链路的下游都会成为这条清理链路上的漏点。所以每一次新增副本、新增报表库、新增异地备份，都应该触发一次删除登记表的更新，而不是等到某次请求做不完才发现。

其四，取证要机械化。靠事后补材料、靠人回忆、靠聊天记录当凭证的都不可靠。同意凭证的生成、请求回执的回收、备份黑名单的执行结果，都应该是系统默认产出物，而不是「需要时导出」。一条判断标准：这件事如果在没有当事人加班的情况下做不出来，它就不算落地。

留存期的取舍：留久了是负债，留短了没证据

留存策略是这三处改造里唯一没有标准答案的部分，也是最容易被拍脑袋的部分。

留得短的风险很直观：举证时拿不出东西。同意凭证如果随账户注销一起清除，那么将来争议的主题恰恰是无法证明的那次同意；安全事故日志如果滚动清理得太快，泄露调查连影响窗口都圈不出来。

留得久的风险是另一种：多留的每一份副本，都是一个额外的泄露面，也是一次额外的删除义务。数据仓库里那个没人敢删的历史分区、对象存储里自动 export 的用户信息快照、早已经不再使用但一直没下线的分析集群——它们不产生价值，却在泄露时成为必须通报的一部分，在删除请求来临时成为必须传播到位的一环。很多团队最后发现自己的存储预算有一大块被消耗在维持这堆无效副本上，而这些副本本身不带任何业务价值。

所以取舍的顺序应该是：先按义务确定「必须留」的几类留痕（同意凭证、请求的处理回执、安全事件的取证日志），给它们明确的留存期限和访问审计；再回头审视所有「顺手留了」的副本，把没有明确用途的那批直接进清理。这两件事的先后顺序不能调换——先把副本清理干净，将来每一条删除请求的传播范围都会小一圈。

不同业务体量下的取舍：先做哪一段

小团队最容易掉进去的坑是照搬大厂方案。看到别人做了完整的同意中台，自己也招标一套，结果产品上线了流程还没改完。

体量比较小、数据只在少数几个系统里流转的团队，优先级应该这么排：先定身份主键，再做同意记录，最后补自动化。身份主键先行，是因为它决定了后续所有请求能不能快速定位；同意记录次之，因为它直接影响取证能力；自动化可以最后做，早期手工台账+严格记录也是可以接受的状态，只要每条都有回执。

体量中等、系统数量上两位数、有明显的上下游数据流的团队，瓶颈在系统清单。这类团队最该先做的不是买工具，是出一份「数据域—系统—责任人」三列清单，明确每个数据域落在哪几个系统、谁是 owner、删除接口有没有、有没有异步队列参与。这份清单既是请求传播的路网，也是泄露时的导航图。没这张图，你在 90 天里有一半时间花在问「这个数据在哪里」。

体量较大、或者很可能被认定为重要数据受托方的团队，要把独立审计和影响评估当成设计输入而非合规补丁。附加义务包括独立审计、影响评估、对部署技术加强尽职调查、以及遵守政府对特定类别数据（包括本地化要求）的限制。前两项都要求你拿出过程材料，第三项要求你能说清自己部署了什么、为什么这样部署——也就是说，技术选型的决策理由本身也要留痕。这条对习惯了口头决策的技术团队是非常不友好的，但它恰恰是大体量方最容易被卡住的地方。

哪些义务有豁免边界，别把豁免当成默认成立

这套规则存在几处豁免或例外，但它们比看上去窄，别拿去当免责设计。

儿童与无法独立作决定的残障人士：须取得父母或合法监护人的可验证同意，医疗、教育、实时安全等有限豁免情形除外。「可验证」是关键词——一个勾选「我已年满 18 岁」的复选框不构成验证。「有限豁免」也是关键词——豁免只覆盖列举出来的那些目的，不是「只要业务看起来正当就行」。如果产品的用户画像包含未成年人，这块的工作量要比想象中大，因为它要把验证过程本身做成可举证的。

受限辖区的跨境传输：政府可以通过通知，指定限制向其传输个人数据的司法辖区。这里要做的是一件非常具体的事：维护一张「受限辖区清单 + 实际传输台账」，台账里记录数据类型、接收方、目的、所在辖区。规则给的形态是「通过通知指定」，也就是说清单是动态的、需要我们自己定期有人跟进的，不是写进配置文件就一劳永逸的。把它当成一份要定期核查的活文档，而不是一条长期有效的常量。

上诉渠道：对委员会决定的上诉机关是电信争议解决与上诉法庭（TDSAT）。这条看似离工程很远，但它提醒一件事——争议会有正式程序，程序就要看材料。你平时留下的每一份留痕，最后都是这段程序里的书面证据。

一张表看清三处改造与两项台账

什么情况下确实需要印度境内节点，什么情况下不必

回到开篇那个问题。搬机器不是全错，只是它回答的不是「义务怎么免」，而是另外几个具体问题。

确实需要的情形主要有两类。一是你手上真有属于「可能被指定本地化要求的特定类别数据」，且你已经通过自查确认了这批数据的范围——这种情况下本地节点是落地的前提，没有别的办法。二是你的印度用户侧写入/读取时延已经在影响业务指标，本地节点解决的是交付体验问题。这两类都成立，但它们都需要先用前面那张「数据域—系统」清单确认过再说。

不必的情形同样清晰。如果你的数据里没有被指定类别要求本地化的部分，节点放在哪都不会改变你的义务清单；如果你还没做过数据盘点和链路梳理，那么先迁移等于把现在的混乱复制一份到新机房，然后带着两倍的系统数量去做 90 天请求传播。还有一种常见理由是「客户要求数据必须在印度」——这种要求往往是客户自己的法务出于谨慎提的宽泛表述，值得回去问清楚具体指向哪几类数据、哪个环节，多半会收窄成一小块。

一句结论：印度这一轮真正吃掉成本的是「请求要跨多少个系统传播」和「同意/通知要留多久且怎么取证」，把机器搬进印度并不会自动抵掉任何一项。位置决定的是时延和个别品类的存放约束，行为决定的是你能不能在 90 天里闭环、在泄露当天讲清楚发生了什么。钱应该先花在后面这两件事上。

一万网络深耕 IDC 19 年（成立于 2007 年），印度及南亚方向的节点资源与合同口径可以提前问清楚，但合规改造这部分只能由业务方自己认领。

十八个月看着很长，倒排下来第一件事实在日志里

把三档时间表摊平：约 2026-11 是同意管理器那一档，约 2027-03 是通知、同意、权利请求、安全保障与泄露通报这一档。中间这段时间真正能提前做完、且完全不能事后补的，是日志结构与身份主键。

理由已经在前面铺完了——同意凭证没法补录，历史操作日志造不出来，请求传播依赖的那张身份映射表也只能从现在开始建立。这三样都属于「今天开始做才有，明天想起做已经晚了」的类型。相比之下，策略文书、流程文件、界面上的申诉入口，都是临近生效也能补的。

所以如果只挑一件事今天下午就开始，我会选：把所有的既有数据去向盘点清楚，压一张「数据域—系统—责任人—删除接口」的清单出来。它是请求传播的路网，是泄露通报的导航图，也是判断机器该放哪的唯一依据。这份清单做出来之后，你会发现后面所有决策都变简单了，包括开篇那个「要不要搬机器」的问题。

数据来源与核验说明：印度 DPDP 法案与 2025 年规则的公开时间表

材料来自印度电子和信息技术部新闻稿、印度政府公开答复与行业协会对规则的整理；时间表以 2025-11-13 为起点；文中未引用任何实测、压测数据。具体核对点包括：《数字个人数据保护法》（DPDP Act, 2023）于 2023-08-11 由议会通过；《2025 年数字个人数据保护规则》（DPDP Rules, 2025）于 2025-11-13 通知发布，官方新闻稿口径为 2025 年 11 月中旬，规则制定前共收到 6,915 条公众意见；三档生效范围即时生效档、一年档、十八个月档所对应的法案与规则条款；通知需具备独立、清晰、通俗易懂的要求及撤回须与给出同意一样容易；数据主体权利请求与申诉处理的最长 90 天响应；泄露须及时以通俗语言告知受影响个人并通知数据保护委员会；处罚上限分别为 25 亿卢比（₹250 crore）、20 亿卢比（₹200 crore）与 5 亿卢比（₹50 crore）；同意管理器须为印度公司并向委员会注册；政府可通过通知指定限制传输辖区；重要数据受托方的附加义务；儿童与特定残障人士的可验证监护人同意及有限豁免；以及对委员会决定的上诉机关为 TDSAT。

本篇所有费率、时延、价格类信息均未涉及，不进行机型或带宽推荐，也不引用任何客户案例。涉及「具体时段如何分配」的工程建议属于通用做法，需以自有业务的真实链路为准。