一、GB/T 35273-2020 10.2 标准原文

二、条款解读说明

2.1 告知是事件处置中的主体权益保护动作

当个人信息安全事件已经可能对个人信息主体造成现实风险时，及时告知并不是品牌公关动作，而是帮助主体采取自我保护措施的重要手段。GB/T 35273-2020第10.2条要求组织及时将事件相关情况通知受影响主体；在难以逐一通知时，也应采取合理有效的方式发布公众警示信息。这说明组织不能因影响面大、沟通成本高或担心舆情，就拖延或弱化告知义务。

2.2 10.2要求告知“可执行”，而不是“形式完整”

2.3 告知内容越模糊，主体越难降低风险

一些组织担心信息过多会引发恐慌，因此把告知写成“某系统发生异常，请注意账户安全”之类的空泛表述。这样做表面上降低了披露程度，实则削弱了主体采取防范措施的能力。标准要求说明事件内容和影响、已采取或将要采取的处置措施、自主防范建议和补救措施，目的就是让主体能够根据自身风险做出判断，例如修改口令、提高警惕、核查账单、关注身份冒用风险等。

2.4 难以逐一告知时，警示信息仍应具体有效

当受影响主体数量巨大、联系方式缺失或个体无法准确识别时，标准允许采取合理、有效的方式发布公众警示信息。但这并不意味着只在官网角落放一则模糊公告即可。合理有效的警示至少应让潜在受影响人群看得见、看得懂，并知道如何核验自身是否受到影响、如何联系组织、如何降低风险。

2.5 告知是后续信任恢复的起点

在事件处置中，主体往往对“组织有没有第一时间告诉我”高度敏感。如果通知及时、说明清楚、补救具体，用户更可能理解组织正在承担责任；反之，如果通知迟缓、信息含混或缺乏联系人，事件本身的影响会迅速叠加为信任危机。10.2因此不仅是告知要求，也体现组织对主体权益的尊重程度。

三、实施要点

3.1 建立分层告知策略

• 根据事件类型、影响范围和可触达程度设计逐一告知与公众警示两类方案。
• 优先选择能快速触达受影响主体的渠道，并保留发送记录。
• 对高风险事件应同步提供热线、在线客服或专门邮箱。

3.2 准备可复用的告知模板

• 模板至少覆盖事件内容、影响范围、处置措施、防范建议、补救措施和联系人。
• 区分账户泄露、联系方式泄露、敏感信息泄露、误共享等不同情形。
• 避免使用过度法律化、用户无法理解的表述。

3.3 让防范建议具体可执行

• 针对不同风险给出明确建议，如修改密码、警惕诈骗、关注异常交易、联系官方核实等。
• 如果组织能提供额外保护措施，也应明确说明获取方式。
• 对无法完全排除的持续风险要如实提示，不应轻描淡写。

3.4 做好通知后的持续沟通

• 设置专门联络窗口处理后续咨询、投诉和补救申请。
• 根据处置进展适时补充更新重要信息。
• 将告知效果和用户反馈纳入事件复盘。

四、常用工具与实施方法

五、典型案例

案例1：通知内容过于模糊

1. 背景：企业向用户发送“系统异常提醒”，未说明涉及的信息类型和风险。
2. 问题：用户无法判断自己是否需要改密、核查账户或提高警惕。
3. 改进：在通知中明确受影响信息类型、可能后果和具体防范建议。

案例2：人数众多只发官网公告

1. 背景：大规模事件发生后，企业仅在官网页脚发布一则简短公告。
2. 问题：警示信息触达率低，难以视为合理有效的公众警示。
3. 改进：结合App推送、站内消息、公众号和媒体公告等多渠道发布警示。

案例3：通知后无人接听咨询

1. 背景：通知中留下客服电话，但企业未增加接线能力，用户无法获得补救指引。
2. 问题：形式上有联系方式，实质上无法支持主体后续维权和防范。
3. 改进：设置专项联络窗口和FAQ脚本，保障通知后的持续沟通能力。

六、成文信息管理要求

10.2要求组织证明其已及时、有效地告知受影响主体，并提供后续补救与联系路径，因此通知类资料应可追溯、可核验。

1. 建议保留的成文信息
   • 事件通知模板、公众警示模板和版本记录
   • 触达渠道选择依据、发送日志和失败重试记录
   • 通知文案、FAQ、客服脚本和专项联系人安排
   • 用户咨询、补救申请和投诉处理记录
   • 告知效果评估和后续补充通知记录
2. 管理要求
   • 告知记录应与事件登记、影响评估和补救措施相互对应。
   • 触达失败、退信、号码失效等情况应纳入补充通知方案。
   • 通知后收到的高频问题应进入复盘和模板优化。

七、常见误区及踩坑提醒