信息安全技术个人信息安全规范

很多团队做合规时卡在同一处：规范条文看懂了，但落到自家产品上不知道从哪一项开始查、查到什么程度算过。这篇不讲法条翻译，只给一份按环节走的对照清单和排查顺序，让你能在半天内把差距列出来，并知道哪些数字要去站内页面现查。

很多团队做合规卡在同一处：规范条文逐字看懂了，落到自家产品上却不知道从哪一项开始查、查到什么程度算过。问题不在理解，在缺少一份「按环节走」的对照清单。

这篇不讲法条翻译，只给排查顺序和判断标准，让你能在半天内把差距列出来，并知道哪些具体数字要去站内页面现查。全文只讲个人信息安全规范这一个角度，不讲别的。

先确认这份规范管不管你、什么时候必须动手

判断适用只看一个动作：你的产品会不会收集、存储、使用、共享、转让、公开披露个人信息。只要沾其中任何一项，就落在这份规范关注的范围内；纯内部、不涉及自然人的数据不在其列，不用硬套。

触发场景

新功能上线前、隐私政策改版、接入第三方 SDK 或外部模型接口、做大促前拉用户名单

不适用情形

面向企业客户且只处理法人数据的系统、完全离线不落盘的一次性计算

先做的一件事

到安全与合规分区把术语口径对齐，别把个人信息、敏感个人信息、去标识化混着用

• 把上面四个触发场景固定成自查节点，写进研发流程，而不是想起来才做
• 每次触发先问一句：这次新增或变动了哪些个人信息字段，有没有动同意逻辑
• 术语不统一时先停下来对齐口径，否则后面每一步都在错的地基上查
• 到安全与合规分区核对当时对个人信息、敏感个人信息的界定，口径会更新，别凭记忆

收集环节：最小必要怎么落到字段级

最小必要不是一个态度，是一个可以逐字段过的动作。做法是把收集清单拉出来，每个字段问三个问题，三个都答不上来就砍掉。落不到字段的合规讨论，最后都会变成文档上的空话。

1. 拉字段表把产品涉及的个人信息字段全部列出，标注来源、用途、是否必填，缺项就是后续审计的窟窿
2. 过三问这个字段不收集功能还能不能跑、能不能晚一点再收、能不能只存摘要不存原值，三问全否就删
3. 拆可选与必要可选信息单独开关、单独说明用途，不用默认勾选或捆绑同意；用户拒绝后功能降级，而不是直接不可用
4. 单独处理敏感项涉及证件、生物特征、精准位置、金融账户的，走单独同意与更严格的访问控制，别和普通字段放同一张表
5. 留证把每个字段的收集目的、依据、留存期限写成一行记录，后续审计直接调取

这里最容易被忽略的是「晚一点再收」：很多字段在注册环节并不需要，等到用户真正用到某功能时再收，既降低了收集量，也降低了出事时的暴露面。

存储与留存：期限和权限要能说清

留存期限的判断标准很简单：从目的倒推。目的达成即删或匿名化；写不出具体期限的字段，本身就是风险点。具体口径会随规定更新，到安全与合规分区核对当时的说明，别把某一次看到的数字当成永久标准。

• 权限最小化：能看明文的人越少越好，排障走脱敏视图或临时授权，授权结束自动回收
• 加密与脱敏不是二选一：传输侧靠加密，展示与测试侧靠脱敏，解决的问题不同，别互相顶替
• 删除要有执行路径：用户申请删除时逐项确认覆盖范围，只删主库是最常见的漏项
• 定期复查高权限账号列表，离职和转岗后仍有效的账号是典型隐患

共享、转让与外部接入：边界怎么划

共享前先定角色：对方是受托处理还是独立控制者。前者要有委托协议约束用途和再委托，后者要单独取得同意。角色定错，后面所有条款都是错配。

接第三方模型或工具时，先看数据会发到哪、留多久、是否用于训练，这类判断可以参照 key-safety 里的原则，再按本篇的对照清单逐条落到字段——原则定方向，字段表才是能查的东西。

• 先列第三方清单：每个接入方写清数据类型、传输方式、留存说法、是否能用于训练
• 调试日志与会话缓存单独扫一遍：带出手机号、身份信息的日志比正式接口更容易出事
• 跨境或跨主体传输前，先确认是否要走评估或标准合同路径，别等出事再补
• 第三方清单每接一个新工具就更新，不更新等于没有

差距排查顺序：先查什么后查什么

顺序不是随便排的，原则是「改动成本从低到高、事故影响从大到小」。字段层面的问题改起来最便宜，权限与日志涉及线上事故面，第三方和留存期限牵扯外部，文档与政策文本放最后——文档写得再漂亮，前面几张表不齐也没用。

1. 跑第一遍四张表拉齐，先不追求完美，追求能把现状写下来
2. 标注差距每条差距标上改动成本和影响面，决定先改哪一批
3. 隔期重跑过一段时间用同一套清单再跑一遍，看的是趋势和新增项有没有被漏掉，不是看一次结论
4. 核对动态数字价格、期限、门槛这类会变的内容，到安全与合规分区和站内对应页面按当时的数字核对

合规不是一次通过的考试，是一套能重复跑的清单——跑得动、留得下证据，才算落地。