《信息安全技术-个人信息告知同意指南(征求意见稿)》(2021-05-14)

隐私政策定制与审核

app合规审核与开发意见

个保体系建设与合规培训

数据出境与GDPR合规



信息安全技术个人信息告知同意指南


Information security technology - Guidelines for personal information notices and consent



(征求意见稿)


2021-05-14




XXXX-XX-XX 发布XXXX-XX-XX 实施

国家市场监督管理总局

国家标准化管理委员会

GB/T XXXXX—XXXX




目  次


前  言

1范围

2规范性引用文件

3术语和定义

4缩略语

5告知同意的适用情形

5.1收集使用个人信息时的告知同意

5.2使用目的变更时的告知同意

5.3对外提供个人信息时的告知同意

5.4告知同意的其他情形

6免于授权同意的情形

6.1收集使用个人信息时免于授权同意的情形

6.2使用目的变更时免于授权同意的情形

6.3对外提供个人信息时免于授权同意的情形

7告知同意的基本原则

7.1告知的基本原则

7.2同意的基本原则

7.3告知同意需考虑的要素

8告知

8.1告知机制设计

8.2告知的内容

8.3告知的展示

8.4告知的适当性

9 同意

9.1同意模式选择

9.2同意机制设计

9.3同意的撤回

9.4同意的证据留存

附 录 A (资料性附录) 未成年人个人信息的告知同意

附 录 B (资料性附录) SDK 收集使用个人信息场景下的告知同意

附 录 C (资料性附录) IoT 场景下的告知同意

附 录 D (资料性附录) 公共场合场景下的告知同意

附 录 E (资料性附录) 个性化推荐场景下的告知同意

附 录 F (资料性附录) 云计算服务场景下的告知同意

附 录 G (资料性附录) 互联网金融场景下的告知同意

附 录 H (资料性附录) 车载场景下的告知同意

附 录 I (资料性附录) 网上购物场景下的告知同意

附 录 J (资料性附录) 快递物流场景下的告知同意

附 录 K (资料性附录) 个人身份认证场景下的告知同意

附 录 L (资料性附录) 互联网房产经纪服务场景下的告知同意

参考文献



前  言


本标准按照GB/T 1.1—2009《标准化工作导则第1部分:标准的结构和编写》给出的规则起草。 请注意本文件的其他内容可能涉及专利,本文件的发布机构不承担识别这些专利的责任。

本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口。

本标准起草单位:中国电子技术标准化研究院、深圳腾讯计算机系统有限公司、中国信息通信研究院、北京理工大学、北京小米移动软件有限公司、华为技术有限公司、阿里巴巴(北京)软件服务有限公司、北京字节跳动科技有限公司、北京三快科技有限公司、北京邮电大学、北京奇虎科技有限公司 等。

本标准主要起草人:何延哲、赵冉冉、洪延青、胡影、葛鑫、陈湉、朱玲凤、衣强、田申、刘笑岑、 娜迪娅、谭礼格、王艳红、王枞、陈松、周晨炜、张有科、闵京华、刘熙君、徐彩曦、刘俊河、李腾、张娜、彭骏涛、张朝、严少敏、邓婷、张灵子、康琼、张屹、马可、姚一楠、孟靖卓、付伟、庄子骏、王磊、刘熙君、魏书音、苏亚林、杨立春、王昕、徐雨晴、汪巍、封莎、吴涵、焦伟、白晓媛、陈绍良、 宋杰、朱通、袁立志、王劲松、罗妍等。




信息安全技术个人信息告知同意指南



1范围


本标准提供了网络运营者在个人信息处理过程中告知的内容、机制,以及如何征得个人信息主体同 意收集、使用、对外提供个人信息的指导和建议。

本标准适用于网络运营者实施个人信息告知同意的各类情形。



2规范性引用文件


下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。

GB/T 25069—2010信息安全技术术语

GB/T 35273—2020信息安全技术个人信息安全规范



3术语和定义


GB/T 35273—2020 界定的以及下列术语和定义适用于本文件。为了便于使用,以下重复列出了GB/T35273—2020 中的某些术语和定义。


3.1

个人信息personal information

以电子或者其他方式记录的能够单独或者与其他信息结合识别特定自然人身份或者反映特定自然

人活动情况的各种信息。

注:个人信息包括姓名、出生日期、身份证件号码、个人生物识别信息、住址、通信通讯联系方式、通信记录和内容、账号密码、财产信息、征信信息、行踪轨迹、住宿信息、健康生理信息、交易信息等。

[GB/T 35273—2020,定义3.1,做了修改:删除注2和注3]


3.2

个人敏感信息personal sensitive information

一旦泄露、非法提供或滥用可能危害人身和财产安全,极易导致个人名誉、身心健康受到损害或歧视性待遇等的个人信息。

注:个人敏感信息包括身份证件号码、个人生物识别信息、银行账号、通信记录和内容、财产信息、征信信息、行踪轨迹、住宿信息、健康生理信息、交易信息、14 岁以下(含)儿童的个人信息等。

[GB/T 35273—2020,定义 3.2,做了修改:删除注 2 和注 3]


3.3

个人信息主体personal information subject

个人信息所标识或者关联的自然人。

注:关联是指个人信息反映了特定自然人活动情况的信息,但不包含直接的标识符。

[GB/T 35273—2020,定义3.3,做了修改:增加注]


3.4

个人信息控制者 personal information controller 有能力决定个人信息处理目的、方式等的组织或个人。[GB/T 35273—2020,定义3.4]


3.5

告知notice

使个人信息主体知晓其个人信息处理活动及其有关规则的行为。

注:处理活动包括个人信息的收集、存储、使用、共享、转让、公开披露、删除等过程。


3.6

同意consent

个人信息主体对其个人信息进行特定处理作出明确授权的行为。

注:包括通过积极的行为作出授权(即明示同意),或者通过消极的不作为而作出授权(如信息采集区域内的个人信息主体在被告知信息收集行为后没有离开该区域)。

[GB/T 35273—2020,改写定义3.7]


3.7

明示同意explicit consent

个人信息主体通过书面、口头等方式主动作出纸质或电子形式的声明,或者自主作出肯定性动作,

对其个人信息进行特定处理作出明确授权的行为。

注:肯定性动作包括个人信息主体主动勾选、主动点击“同意”“注册”“发送”“拨打”、主动填写或提供等。

[GB/T 35273—2020,定义3.6]


3.8

对外提供external provision

个人信息控制者通过共享、转让、公开披露等方式将个人信息传输或披露给第三方的行为。



4缩略语


AI人工智能(Artificial Intelligence)

API应用程序接口(Application Programming Interface) IoT物联网(Internet of Things)

PC个人电脑(Personal Computer)

SDK软件工具开发包(Software Development Kit)



5告知和同意的适用情形


5.1收集个人信息时的告知同意


收集个人信息时,个人信息控制者可先行判定需要告知的场景,除去本标准第 6 章所述例外场景外, 需向个人信息主体告知收集、使用个人信息的目的、方式和范围等规则,并获得个人信息主体的授权同意,若涉及收集个人敏感信息的,需征得个人信息主体的明示同意。收集个人信息包括但不限于以下情形:

a)个人信息主体主动填写、选择、上传等主动提供个人信息的;

b)个人信息控制者通过智能终端、API、SDK、IoT 设备、浏览器、传感器等自动采集个人信息的;

c)个人信息控制者通过与用户交互记录个人信息主体行为的;

d)个人信息控制者通过从第三方共享、转让间接接受、查询等方式间接获取的;

e)个人信息控制者从非完全公开渠道搜集个人信息的;

注:非完全公开通常是指个人信息主体披露信息,但信息无法被互联网任何人上进行公开访问的状态,如设置了账户登录、关注、安装客户端、开通代理等条件。

f)个人信息控制者从个人信息主体关联身份或账号收集个人信息的;

g)个人信息控制者使用大数据、AI 等技术分析、关联和生成个人信息的。


5.2使用目的变更时的告知同意


个人信息控制者因业务所需,超出与收集个人信息时所声称的目的具有直接或合理关联的范围使用 个人信息,即变更使用目的的,需向个人信息主体告知变更原因,变更后个人信息的使用目的、方式和 范围,并再次征得个人信息主体的明示同意。使用目的变更包括但不限于以下情形:

a)个人信息控制者收集个人信息后,超出原有授权的业务功能范围应用于新的业务场景的;

b)个人信息控制者通过个人信息或其他信息加工处理后形成新的个人信息并进行处理,但此前未告知个人信息主体其个人信息会进行加工处理生成新的个人信息的;

c)个人信息控制者发生收购、兼并、重组、破产等变更时,变更后的个人信息控制者超出原有授 权范围使用个人信息的;

d)个人信息控制者因业务需要将个人信息传输到境外进行处理,但此前未告知个人信息主体相关个人信息出境情况或者已告知个人信息主体个人信息出境情况但出境情况发生了重大变更的, 出境情况包括但不限于出境的个人信息类型、数量和敏感程度、出境目的、出境方式、接收方的身份和数据安全保护措施等信息。

e)个人信息控制者基于不同产品或服务将所收集的个人信息进行汇聚融合的,但此前未告知个人 信息主体相关情况的。


5.3对外提供个人信息时的告知同意


个人信息控制者对外提供个人信息时,需向个人信息主体告知个人信息类型、提供目的、接收方身 份或类型及可能产生的后果等,并事先获得个人信息主体的授权同意。对外提供个人信息包括但不限于 以下情形:

a)个人信息控制者因业务所需向第三方共享个人信息;

b)个人信息控制者因业务变更等原因,向第三方转让个人信息,且不再保留个人信息;

c)个人信息控制者因相关法律法规、国家政策、社会公共利益等要求或合理事由,以不定向方式向社会公开披露个人信息;

d)个人信息控制者因相关法律法规、国家政策、社会公共利益等要求,按规范、流程向特定的第三方提供个人信息;

e)其他个人信息控制者对外提供个人信息的情形,但个人信息控制者向接受其委托、为其提供个人信息处理服务的情形除外。


5.4告知同意的其他情形


以下情形通常需要对个人信息主体进行告知,具体包括:

a)涉及个人信息出境情形时,告知出境的原因或目的、处理方式、可能产生的影响等;

b)当个人信息控制者与第三方为共同个人信息控制者时,双方在个人信息安全方面分别应分别承担的责任和义务;

c)个人信息控制者在其产品或服务中接入具备收集个人信息功能的第三方产品或服务时,第三方收集使用个人信息的规则;

d)在个人信息主体拒绝提供个人信息时,可能产生的影响,例如拒绝提供某些个人信息可能会影响部分业务功能的正常使用;

e)在个人信息主体撤回授权同意时,可能产生的影响,例如,个人信息主体关闭定向推送功能、 关闭系统敏感权限等场景下告知个人信息主体关闭定向推送功能或系统敏感权限时可能产生的影响;

f)在个人信息主体注销账号时,涉及的规则及其可能产生的影响;

g)对个人信息进行汇聚融合时,可能对个人信息主体权益产生的影响;

h)发生个人信息安全事件时,可能对个人信息主体合法权益造成的侵害或影响。


6免于授权同意的情形


6.1收集使用个人信息时免于授权同意的情形


6.1.1概述

以下情形中,个人信息控制者收集、使用个人信息的,以适当方式告知个人信息主体收集、使用目 的的,可以无需征得个人信息主体的授权同意。


6.1.2与个人信息控制者履行法律法规规定的义务相关的

a)履行反洗钱监管要求,收集实名身份信息及相关交易记录;

b)履行网络实名制要求,收集手机号码、有效身份证件等可以验证个人信息主体身份的信息;

c)履行法律规定的网络运营管理和网络安全等义务,收集相关网络日志信息(如 IP 地址、访问时间、设备等);

d)差旅住宿、航空、铁路运输、出行服务等行业,按照相关法律法规规定收集个人信息主体的实 名身份信息;

e)法律、行政法规、部门规章、规范性文件所规定其他个人信息控制者应当履行的义务。


6.1.3与国家安全、国防安全直接相关的

a)国家安全、国防安全的定义与范围由《中华人民共和国国家安全法》《中华人民共和国国防法》 等法律明确规定。

b)“直接相关”是国家或国防安全面临现实而紧迫的危险或者有关法律直接规定的相关要求。


6.1.4与公共安全、公共卫生、重大公共利益直接相关的

a)发生自然灾害(地震、海啸、台风、山体滑坡等)、公共突发事件(群体性事件、火灾)、重大 安全生产事故(坍塌、矿难、危险品泄漏等)时,为搜救被困人员、挽救生命安全而向个人信 息主体或个人信息控制者收集基站位置、网络地址等信息。

b)在发生重大传染性疾病疫情期间,为加强防控疫情,向个人信息主体或其他个人信息控制者收集用于分析疫情迁移趋势的信息,对疑似病例人员采样进行病原体监测,详细登记其个人信息、 联系方式等。

c)其他与公共安全、公共卫生、重大公共利益直接相关个人信息收集、使用情形。


6.1.5与刑事侦查、起诉、审判和判决执行等直接相关的

a)与犯罪侦查直接相关的,例如为侦查刑事案件,侦查机关根据法律规定,向其他个人信息控制 者或个人信息主体收集、使用犯罪嫌疑人、被告人的指纹、DNA 等生物信息、通话记录、上网记录等个人信息。

b)“直接相关”是指根据《中华人民共和国监察法》、《中华人民共和国刑事诉讼法》、《中华人民 共和国民事诉讼法》等法律明确规定的方式与程序,对具体案件开展的调查活动。

c)根据公安、监察等司法机关依法调取前述信息的,个人信息控制者无需告知个人信息主体。


6.1.6出于维护个人信息主体或其他个人的生命、财产等重大合法权益但又很难得到本人授权同意的

a)因突发情况导致个人信息主体失踪、失联,无法联系个人信息主体,且如不及时采取措施,可能导致其面临生命安全的。

b)因患者陷入严重昏迷无法取得本人同意,医生为救助患者必须检测其血型以向其输血。

c)个人信息主体面临遭遇电信网络诈骗、非法传销或针对人身安全等违法犯罪侵害风险时,收集 威胁源等信息阻断涉嫌违法犯罪的活动。

d)其他出于维护个人信息主体或其他个人生命、财产等重大合法权益但又难以获得本人授权同意 的情形。


6.1.7所涉及的个人信息是个人信息主体自行向社会公众公开的

a)收集、使用个人信息主体在开放式网络平台上自行向所有用户公开的信息,包括但不限于主动 设置、填写或上传的头像、昵称、性别、学历、单位、地区等个人信息。

b)个人信息主体在开放式网络平台使用过程中,明确知悉相关活动会被平台公开展示的信息,例 如:点赞、评论、关注、转发、排名列表等。

c)个人信息主体主动向相关机构、企业、组织提供信息,在提供时明确知悉其提供的信息将会被 收集方向社会公众公开。例如:被合法披露的包含法定代表人、懂事、监事、高管等个人信息 在内的工商登记信息。

d)个人信息主体如果将已自行向社会公众公开的信息撤回,个人信息控制者不应继续收集,但不 影响原收集行为。个人信息主体发现个人信息控制者继续使用其已撤回的公开信息的,可以要 求个人信息控制者停止使用,个信息控制者接到个人信息主体通知的,应当停止继续使用。


6.1.8根据个人信息主体要求签订和履行合同所必需的

“履行合同所必需”是指履行与个人信息主体的合同时客观上所必要的,或是应个人信息主体的要 求在缔约前采取的行动所客观必要的,即当不收集相关数据的情况下,合同在客观上无法履行。下列个 人信息收集活动可以被视为“履行合同所必需”:

a)购物网站为实现其基本功能寄送用户网购的商品而收集、使用用户的姓名、住址和联系电话, 网络租房平台为实现其基本功能与用户签订租房合同,收集用户的实名信息、手机号码等个人信息。

b)购物网站为用户提供的购物车功能,记录用户放入购物车的商品数据。

c)网站为用户提供订阅、评论、点赞、收藏、转发功能,记录用户行为信息,但如果将前述信息 用于互联网个性化广告展示、个性化推送的,需获得个人信息主体的授权同意。

d)金融业机构在开展金融业务活动中必需进行授信、调查而收集的必要信息。

e)与个人信息主体求职、就业直接相关的,例如用人单位收集个人信息主体投递的包含姓名、联 系电话、学历背景、工作经验等个人信息的简历。

f)房屋、汽车中介、租赁业为达成撮合交易等目的,在进入相关业务功能时收集联系方式、标的 物基本信息以及为达成此类合同所客观必要的信息。

g)为履行合同约定的售后服务等条款,收集、存储与交易相关的信息:例如:购买时间、型号、 联系方式等。

h)其他可以被认为是履行合同所必需的情形,包括但不限于本指南附录所列相关场景中所需履行 合同所必要的情形。

注:个人信息保护政策的主要功能为公开个人信息控制者收集、使用个人信息范围和规则,不宜将其视为合同。


6.1.9维护所提供产品或服务的安全稳定运行所必需的,如发现、处置产品或服务的故障

a)个人信息控制者为确保产品或服务的安全稳定运行,收集用户的设备类型、应用安装情况、网 络运行日志、崩溃报告等日志信息用于分析和改善软件运行情况;

b)个人信息控制者防止恶意注册、批量点击等危害运营安全活动,收集用户设备信息、日志信息、 网络接入情况等信息;

c)为训练反欺诈、识别违法信息、音视频,而对去标识化的信息进行标注、机器学习和进行识别 的;

d)其他维护所提供产品或服务的安全稳定运行所必需收集的情形。


6.1.10个人信息控制者为学术研究机构,出于公共利益开展统计或学术研究所必要,且其对外提供学术研究或描述的结果时,对结果中所包含的个人信息进行去标识化处理的

a)学术研究机构为调查研究某公共政策对不同性别、不同年龄、不同地区的人群的影响情况,收 集、使用被调查人员的性别、年龄、地区等个人信息,但在提供研究成果时对所包含的个人信 息进行去标识化处理;

b)学术研究机构为研究与改进人工智能等技术,对经过去标识化的照片、音频、视频进行研究或 训练。


6.1.11个人信息控制者为新闻单位,且其开展合法的新闻报道所必需的

a)报社、电台、电视台为报道某大学志愿者在贫困山区支教的情况,收集、使用了志愿者的姓名、 在读学校等个人信息等;

b)其他为报道新闻信息而收集个人信息的情形。


6.1.12从合法公开披露的信息中收集个人信息的,如合法的新闻报道、政府信息公开等渠道

a)国家审计署网站公告的移送违纪违法问题线索的查处情况等。

b)从司法机关公开的诉讼文书公开网站中获取的个人信息主体的相关个人信息。

c)工商登记网站中依法公示的企业法定代表人、董事、监事、高管等信息。

d)公安机关、监察机关、司法机关依法履行职责过程中,依法向社会公开的相关犯罪嫌疑人、被 告人、当事人的相关个人信息。

e)其他从合法公开披露的信息中收集个人信息的情形。


6.1.13其他免于授权同意的情形

a)收集将个人信息匿名化处理后形成的数据;

b)个人信息控制者因重组、分拆、调整等主体变更导致向继受者提供或者转移个人信息的情形;

c)法律法规规定的其他情形。


6.2使用目的变更时免于授权同意的情形


a)以下情形中,个人信息控制者变更个人信息使用目的时,可无需征得个人信息主体的授权同意:

1)新设目的与原先授权目的有直接或必要的关联,个人信息控制者采取等同的处理规则和不 低于原使用目的的安全保护措施;

2)将所收集的个人信息用于学术研究或得出对自然、科学、社会、经济等现象总体状态的描 述,且使用学术研究或描述的结果时,对个人信息进行去标识化处理的。

b)以下情形中,个人信息控制者可以综合考虑变更个人信息使用目的对个人信息主体造成的影响,在不会对个人权益带来超出原授权使用目的的影响的前提下,决定是否免于授权同意:

1)服务升级、改造后使用个人信息的频率、用户画像计算和展现方式、与个人信息主体的互 动方式发生调整的;

2)对个人信息进行汇聚融合,以提升服务质量、安全水平等的;

3)变更后目的经个人信息安全影响评估后无高风险,且向用户告知评估结果的。


6.3对外提供个人信息时免于授权同意的情形


a)GB/T 35273《信息安全技术 个人信息安全规范》9.5 规定的情形下,个人信息控制者共享、转让、公开披露个人信息时,需以适当方式告知个人信息主体目的,但无需获得个人信息主体的 授权同意;

b)个人信息控制者可以参照本指南 6.1 规定的相关情形,确定对外提供个人信息时是否属于无需获得个人信息主体的授权同意的情形;

c)个人信息主体主动要求对指定第三方提供的个人信息时,可向第三方直接提供,免去再次征得 授权同意过程;

d)个人信息主体与第三方达成明确协定,同意第三方可以从个人信息控制者直接获取其个人信息, 且第三方展示可信的凭据时,个人信息控制者可向第三方直接提供,免去再次征得授权同意过 程。


7告知同意的基本原则


7.1告知的基本原则


个人信息控制者在实施告知时需考虑以下基本原则,保证告知过程切实有效:

a)公开透明——公布收集、使用个人信息的范围、目的,不隐瞒产品或服务所收集的个人信息及 其使用目的,不采取故意遮挡、隐藏等方式诱导个人信息主体略过告知内容;

b)逐一传达——向个人信息主体逐一告知相关内容,不能通过邮件、电话或短信方式告知的也可 采取公告方式;

c)适时充分——当涉及具体业务功能收集、使用等个人信息处理场景时,在收集行为发生前,或 触发个人信息收集行为时,对个人信息主体进行充分告知;

d)真实准确——反映产品或服务真实、准确的个人信息收集使用范围、目的;

e)具体明确——告知个人信息的类型、目的等内容需结合实际业务场景,不使用格式化条款;

f)清晰易懂——告知文本符合个人信息主体的语言习惯(如简体中文),使用标准化语言、数字、 图示等,避免使用有歧义的语言。


7.2同意的基本原则


个人信息控制者在实施同意时需考虑以下基本原则,保证征得授权同意过程切实有效:

a)告知一致——征得授权同意的授权范围与所告知内容相一致;

b)自主选择——主动向个人信息主体展示征得授权同意的选项,支持其自行做出选择,不给出同 意时,仅影响当前服务类型的正常使用;

c)时机恰当——在个人信息收集行为发生前,且同步传达告知内容时,征得个人信息主体同意, 以增进个人信息主体对业务功能与所收集的个人信息之间关联性的理解;

d)分类独立——区分产品或服务的服务类型后,分别征得个人信息主体同意,不采用捆绑方式强 迫个人信息主体一次性接受或拒绝所有可能收集的个人信息。


7.3告知同意需考虑的要素


个人信息控制者在实施告知同意时还可以考虑以下要素,优化告知同意的方案和机制:

a)友好展示——使用友好、生动、形象的方式编辑告知内容(如使用插图、漫画等),优化告知内容风格及其组织形式,以促进个人信息主体理解;

b)适应载体——告知内容、展示形式、征得授权同意的方式等可以根据告知载体的类型、界面特点进行适应性设计,如适宜的字体大小、额外的震动和语音提示等;

c)考虑影响——确定告知内容的详细程度和个人信息主体给出“肯定性动作”进行同意的明确程度时,可根据个人信息处理活动对个人权益影响程度进行权衡,包括对个人信息主体使用服务过程的用户体验等因素;

d)区分阶段——根据个人信息主体使用产品和服务业务功能的范围和个人信息处理阶段,结合隐私政策、用户协议、提示语句等不同文本的性质和展示效果,设置具体的告知同意方案;

e)兼顾差异——充分考虑复杂多样的网络条件、技术差异,个人信息主体的理解能力、水平(例 如儿童或残障人士)等,使用可以广泛适用或针对特定群体的告知同意解决方案。


8告知


8.1告知机制设计


个人信息控制者实施告知时需结合产品或服务的具体特点,基于本标准第7.1和7.3中的原则及8.2中 的告知内容,选择适当的告知方式或多种告知方式的组合,具体包括:

a)一般告知,主要用于个人信息控制者向个人信息主体全面阐述个人信息收集使用等规则,包括:

1)个人信息控制者需针对其个人信息处理活动制定个人信息保护政策,例如专门、单独的隐 私政策或文本协议,并以易于访问的方式公开展示;

2)个人信息控制者宜将隐私政策的完整内容置于产品或服务基本业务功能开启时与告知相 关的交互界面中,并通过弹窗提示、突出链接等明显方式,主动提示个人信息主体阅读隐 私政策;

3)设计交互式界面展示隐私政策时,避免使用与背景颜色过于相近的字体、刻意缩小字号、 弹出键盘遮挡、置于边缘等方式造成个人信息主体不易发现隐私政策;

4)无法实现交互式界面展示隐私政策的,需考虑其他方式保证在收集个人信息前的必要环节, 以发送通知、邮件(或信件)、提供文档(包括电子版或纸质版)、张贴告示等方式向个人信息主体主动发送;

5)当逐一向个人信息主体告知成本过高或者有显著困难时,宜以公告的形式发布;

6)宜通过图标、文字、应用名称、动画、音/视频等多种形式编辑不同的告知内容,以达到良好的告知效果;

7)本标准第6章所述的免于授权同意的情形,可采用一般告知方法予以提前告知。

b)增强式告知,主要为促进个人信息主体进一步理解个人信息保护政策中的核心内容,采用个人信息主体不可绕过的方式(如弹窗等)向个人信息主体展示相关信息,以协助其作出是否授权同意的决定,包括:

1)增强式告知的内容浓缩了一般告知的关键规则,突出展示个人信息主体最关心的内容,语 言简洁、精炼,方便阅读;

2)增强式告知的方式需凸显与一般告知方式的差异,其告知内容更加容易被个人信息主体所 获取,如一般告知仅为要求个人信息主体勾选、点击等方式提醒,则增强式告知采用弹窗 方式向个人信息主体直接展示相应内容;

3)在产品或服务基本业务功能开启前(如个人信息主体初始安装、首次使用、注册账号等情形),如以链接等方式展示隐私政策等个人信息收集使用规则时,宜采用增强式告知方式将隐私政策关键规则直接展示到个人信息主体面前;

4)在个人信息主体选择使用其他业务功能时,可通过增强式告知方式向个人信息主体告知所 提供其他业务功能收集使用个人信息的关键规则;

注:如果个人信息主体选择使用的其他业务功能非常简单,业务功能名称即可明示个人信息收集目的、使用用途的,可以不选择采用增强式告知方式。

5)涉及开通收集个人生物识别信息的业务功能时,可通过增强式告知方式向个人信息主体告知个人生物识别信息收集使用规则;

6)涉及对基于不同目的所收集个人信息进行汇聚融合处理并应用于新设目的时,可通过增强 式告知方式向个人信息主体告知具体情况;

7)涉及发生个人信息安全事件、产品或服务停止运营、通过接受转让、收购等方式获取个人 信息等事件触发的特殊情形,宜通过弹窗、邮件、短信、站内信等增强式告知方式向个人 信息主体告知具体情况;

8)涉及可能对个人权益产生重大影响的个人信息收集使用行为时,可选择电话方式增强式告 知。

c)即时提示,主要是在个人信息主体使用产品或服务过程中,进一步加强个人信息主体对个人信息控制者收集使用个人信息的具体规则和收集使用状态的掌握,尤其是当个人信息控制者收集使用个人敏感信息,或个人信息收集使用规则发生局部变化时,可采用即时提示的方法, 包括:

1)即时提示的内容需简洁明了,提示方式需结合产品或服务特点灵活选择;

2)收集个人敏感信息(身份证号、银行账号、行踪轨迹等),宜采用弹窗、浮窗、文字备注、提示条等方式进行即时提示;

3)采用API等方式(如智能终端操作系统提供的“地理位置”等权限)自动采集个人敏感信息时,宜采用标记闪烁、提示音等方式进行即时提示;

4)使用目的变更、对外提供个人信息、个人信息处理规则发生变化时,宜使用弹窗、浮窗、 短信、邮件、消息推送等显著方式进行即时提示;

5)当涉及可能对个人权益产生重大影响的个人信息收集使用行为时,宜选用电话、语音留言 等方式即时提示;

6)个人信息主体注销账号时,可将注销的条件、带来的影响进行即时提示;

7)当个人信息主体拒绝同意或撤回同意收集个人信息时,可将带来的影响进行即时提示。

d)除上述机制外,不同场景下的具体告知机制可参考附录A-L。


8.2告知的内容


8.2.1一般告知内容


一般告知内容包括但不限于:

a)个人信息控制者基本情况,个人信息的收集、使用、存储、对外提供、安全保护情况,个人信 息主体的权利和实现机制,处理个人信息主体询问、投诉的渠道和机制等。

注:具体可参考 GB/T 35273《信息安全技术 个人信息安全规范》5.5 节“个人信息保护政策”和附录 D 要求。

b)一般告知还可以包括以下内容:

1)产品或服务可能收集的个人信息类型全集,可以个人信息主体主动提供、自动采集、间接 获取、加工生成等不同方式予以分类描述;

2)收集的个人信息涉及个人敏感信息的,明确标识或突出显示;

3)区分说明各业务功能所收集的个人信息类型,或逐一说明每类个人信息的收集使用目的、 方式;

4)区分说明哪些个人信息类型为各业务功能所必需,哪些个人信息类型为个人信息主体可选 择提供;

注:必需是指一旦缺少该个人信息将导致该类型服务无法实现或无法正常运行。

5)提供个人信息后能够获取的权益,例如个人信息主体可以享受更加有针对性的服务,个人 信息控制者可以确保在某些特殊情况下为个人信息主体提供更安全的产品和服务等;

6)提供告知中应遵循的个人信息的使用权利和义务,及个人信息主体授权选项;

7)在某些业务功能停止运营之前,应及时向个人信息主体告知已停止继续收集相关个人信息, 采取的对个人信息删除或匿名化等措施,以保证个人信息主体可以终止同意授权;

8)涉及数据出境时的个人信息处理规则;

9)保存期限届满后的处理规则;

10)个人信息主体可以再次查看告知内容的方法和路径;

11)具备的数据安全能力、安全组织、安全流程,必要时可公开数据安全和个人信息保护相关 的合规证明;

12)涉及 Cookie 等同类技术(包括脚本、Clickstream、Web 信标、Flash Cookie、内嵌 Web 链接等)收集个人信息,需简要说明相关机制,以及收集个人信息的目的、类型;

13)涉及嵌入的第三方代码、插件(如 SDK)收集个人信息,需说明第三方身份或类型,及收集个人信息的目的、类型、方式等。

14)产品或服务涉及本标准第 6 章所述的免于授权同意的具体情形及其说明。


8.2.2增强式告知内容


增强式告知内容包括但不限于:

a)增强式告知内容为个人信息保护政策的关键规则的,可结合具体业务场景以及增强式告知界面 样式进行自定义,包括但不限于:

1)产品或服务基本业务功能所必需个人信息类型,以及收集方式、目的等;

注:必需是指一旦缺少该个人信息将导致该类型服务无法实现或无法正常运行。

2)是否使用自动化决策等机制等可能对个人信息主体权益产生显著影响的方式;

3)个人信息保护投诉的联系方式、个人信息保护工作机构或相关负责人联系方式等渠道;

4)个人信息保护政策的结构、访问链接等;

5)个人信息保护政策中发生变化的规则;

6)其他需要强调的内容。

b)首次使用产品或服务的不同业务功能时(包括临时启用或上线的业务功能),增强式告知内容需注重体现该业务功能所必需个人信息类型,以及收集方式、目的等信息,以及与整体个人信 息保护政策有所区别的内容;

c)开通收集个人生物识别信息的业务功能时,增强式告知内容需注重体现收集、使用个人生物识 别信息的目的、方式和范围,以及存储时间等规则;

d)对基于不同目的所收集个人信息进行汇聚融合时,增强式告知内容需注重体现汇聚融合的目的、 对个人信息主体产生的影响,必要时还可告知个人信息安全影响评估结果是否风险可控;

e)发生个人信息安全事件时,增强式告知内容需体现 GB/T 35273《信息安全技术 个人信息安全规范》10.2 b)中的内容;

f)产品或服务停止运营时,增强式告知内容需注重体现对其所持有的个人信息进行删除或匿名化 处理的情况;

g)通过接受转让、收购等方式获取个人信息时,增强式告知内容需注重体现是否会继续履行原个 人信息控制者的责任和义务,是否涉及个人信息使用目的变更等。


8.2.3即时提示内容


即时提示内容包括但不限于:

a)收集的个人敏感信息类型,以及收集使用个人敏感信息的目的等;

b)是否处于自动采集个人敏感信息的状态;

c)待变更后的个人信息使用目的等;

d)涉及间接获取个人敏感信息类型、第三方身份类型等;

e)因新设目的需要,需转让、共享、公开披露的个人敏感信息类型等;

f)提供个人信息投诉途径或相关联系方式以对复杂处理机制进行答疑;

g)拒绝同意或撤回同意收集个人信息后,对个人信息主体使用产品或服务的具体影响,如是否能够正常使用或无法正常使用的功能等;

h)个人信息主体注销账号时,验证身份所需个人信息类型、设置的注销条件和理由、注销后的影响等;

i)与通用收集使用规则中不完全一致需要特殊说明的内容;

j)其他需要强调和特殊说明的内容。


8.3告知的展示


8.3.1告知界面的展示

个人信息控制者应当以便于个人信息主体立即阅读的方式展示告知内容,且内容简洁、主次分明。 此外,还应当根据环境与情景的不同进行调整,优化告知内容的展现形式,包括:

a)PC 端可以采取弹出窗口和下拉列表的方式展示告知内容;

b)移动终端可以采用多层次的告知模式,通过简短提炼概述(可包含文字和图示)告知、提示关 键内容,同时提供完整版告知内容的链接;

c)IoT 设备可在用户手册、说明书、或者设备标签上提供告知内容或相关访问链接,在设备连接互联网时还可通过绑定该设备的移动端程序展示告知内容;

注:如果设备配备显示屏且足以展示告知内容的,也可以在自带的显示屏上进行展示。

d)书面等方式告知时,可将核心告知内容布置于签字确认区域附近。

8.3.2告知内容的展示

告知内容展示需以个人信息主体视角的用户体验和权益保障为中心,包括:

a)收集的个人信息涉及个人敏感信息的,需明确标识或突出显示;

b)告知文字的显示方式(字号、颜色、行间距、清晰度等)不能造成阅读困难;

c)个人信息处理规则等告知内容发生重大变化的部分,需明确标识或突出显示;

d)将对个人信息主体产生重要影响或易于引起异议或争端的内容靠前推送,以便于个人信息主体 获取;

e)针对特殊群体,提供除文本外的图片、语音或视频等对告知内容进行阐述。


8.4告知的适当性


8.4.1告知的适当时机和频率

设置合理的告知时机,有助于个人信息主体更加明确地掌握个人信息控制者所设定的个人信息处理 规则,如果告知的时间点和收集个人信息的时间点相差较大,将使个人信息主体无法获知告知内容与所 收集个人信息之间的关系;如果仅采用首次告知方式,由于告知内容过多,将使个人信息主体无法获知 后续具体个人信息处理活动中的规则,可能需要进行同步告知或再次告知。通常,同步告知、再次告知 可采用增强式告知或即时提示的方式。

同时,个人信息控制者需要注意以适当的频率或时间间隔确认现有的告知或发起新告知。个人信息 控制者应当避免告知的频率过低,导致告知的内容与时机情况不符;同时避免告知的频率过高对个人信 息主体造成不必要的打扰。

个人信息控制者告知时机与频率应与个人信息主体体验感及舒适度相平衡。告知的时机包括:

a)首次使用前:个人信息主体在首次使用产品或服务时,可进行首次告知;

b)信息收集前:个人信息控制者在收集个人信息前,可进行同步告知;

c)间接获取时:通过其他载体收集或间接获取个人信息时,可进行同步告知,因客观条件所限(无 联系渠道)需在获取个人信息后,及时进行主动告知;

d)目的变更前:个人信息控制者变更个人信息收集使用目的、方式、范围前,可进行再次告知;

e)信息对外提供前:个人信息控制者在对外提供个人信息前,可进行同步告知;

f)产品更新后:产品更新后个人信息保护政策发生变化的,可进行再次告知;

g)注销账户时:个人信息主体在注销账户时,可进行同步告知;

h)停止运营前:个人信息控制者在停止业务运营前,可紧急进行同步告知;

i)安全事件发生后:个人信息控制者发生对个人信息有严重影响的安全事件时,可紧急进行同步 告知。

注:个人信息控制者处理活动发生变更需要获得个人信息主体的授权同意的,应当考虑个人信息主体是否可以查阅同意内容的历史记录,以及之前的同意至再次征求同意经历了多长时间。如果个人信息主体可以随时查阅其历史同意内容,或距上次告知时间较短,个人信息控制者可以选择仅告知变更内容,并征得个人信息主体对变更内容的授权同意。否则,个人信息控制者在告知变更内容并征得个人信息主体对变更内容的授权同意之外,还需确认个人信息主体授权同意的原始内容。


8.4.2告知的适当位置

个人信息控制者需在个人信息主体习惯性访问的位置进行告知,包括:

a)在个人信息主体注册页面、登录页面、移动互联网应用程序启动页、社交媒体首页等显著位置 显示个人信息收集处理规则;

b)采取浮窗、弹窗等方式告知时,优先选取网站、移动互联网应用程序主界面,相关内容位于界 面中央位置;

c)在网站、应用程序交互式界面展示隐私政策时,不宜藏匿太深,如打开主界面起,多于 4 次点击、滑动等才能访问到隐私政策;

d)需要个人信息主体主动填写和提交个人信息时,可以在填写或选择框中使用灰色字体简述目的 等内容。


9同意


9.1同意模式选择


9.1.1明示同意模式


个人信息控制者征得同意时,需优先采用明示同意的方式,确保个人信息主体在理解收集目的和相 关处理规则的基础上自主给出的、具体的、清晰明确的意愿表示,且避免采取被动接受、默认选择的机 制,以致个人信息主体忽略对个人信息处理规则的关注。明示同意的模式主要包括:

a)设置交互式界面,由个人信息主体做出主动勾选、主动点击“同意”“下一步”“继续”、滑动滑块、主动发送等动作表示意愿;

b)由个人信息主体主动填写、输入个人信息表示意愿;

c)由个人信息主体开启可收集个人信息的 API 接口、权限表示意愿;

d)个人信息主体通过纸质或电子的书面声明、签字确认表示意愿;

e)个人信息主体通过主动出示证件等方式展示个人信息表示意愿;

f)个人信息主体通过电子签名方式表示意愿;

g)个人信息主体通过电话录音、视频录像等方式表示意愿。

个人信息控制者可结合产品或服务的特点,可能多个人信息主体造成影响的程度等因素,选择上述 同意模式中的一种或几种。

收集个人敏感信息时,未成年个人信息等个人信息时,需采用上述 a)-f)模式征得个人信息主体或/

和其监护人的明示同意。

注:收集年满 14 周岁未成年人的个人信息前,需征得未成年人或其监护人的明示同意;不满 14 周岁的,需征得其监护人的明示同意;


9.1.2单独同意模式


对于以下场景下的授权同意,应进一步选择使用单独同意的方式以充分保障个人信息主体能充分知情和自主授权。单独同意是指对于某类具体的业务功能或特定目的的个人信息处理活动,通过增强式告 知或即时提示等方式,单独向个人信息主体告知处理个人信息的目的、方式和范围、以及存储时间、安 全措施等规则,并由个人信息主体明示同意,单独同意过程不应捆绑与被同意事项不相关的任何业务功 能或处理目的。

a)处理种族、民族、宗教信仰、个人生物特征、医疗健康、金融账户、个人行踪等个人敏感信息;

b)向境外提供境内运营中收集和产生的个人信息;

c)基于特定目的对外提供个人敏感信息;

d)以不定向方式向社会公开披露个人信息;

注:如将公共场所安装图像采集、个人身份识别设备收集的个人图像、个人身份特征信息等公开需要图像、数据中所涉及所有个人信息主体的单独同意。

e)法律法规规定应取得个人信息主体单独同意的处理行为;


9.1.3其他授权同意模式


除明示同意的模式外,以下方式可被认为是通过消极的不作为而作出授权同意的模式,包括:

a)个人信息主体明确已看到收集使用规则的提示(如文本、链接等)、收到相关电子邮件、信函后,未主动作出答复,仍然继续执行涉及个人信息收集使用的操作;

b)个人信息主体被普遍认为能知晓正常使用产品或服务需要收集基本的个人信息,未对相关规则 作深入了解直接使用了产品或服务。例如,直接插入手机 SIM 卡连接移动网络时,被移动运营商收集 SIM 卡相关设备信息,使用浏览器直接打开网页进行访问,网站运营者会收集 MAC 地址、IP 地址等网络状态信息;

c)个人信息主体在发现个人信息存在被收集的可能性后,未选择进一步表示个人信息不愿被收集的意愿,或未改变其当前的活动状态。例如,个人信息主体知晓进入了图像采集区而不退出, 知晓了电话可能会被录音但未挂断;

d)个人信息主体主动表示愿意与个人信息控制者达成一致性约定,但未对达成一致性约定过程中 涉及的个人信息收集使用表达意见,例如,企业对希望入职的员工执行了工作背景调查。

基于本标准第 8 章内容,在选取适当方式充分履行向个人信息主体告知的义务后,如因客观条件限制、或从有利于保护个人信息主体权益等角度出发,且经个人信息影响评估后对个人信息主体权益不会 造成显著影响的,可考虑采用非明示同意的授权同意方式。具体涉及的情形如下:

–产品或服务的业务场景网络等环境条件受限;

–产品或服务的展示界面和展示方式受限;

–涉及特殊弱势群体,如残疾人、精神病患者等时,向其充分告知存在困难;

–基于最小必要原则考虑,为实现业务功能仅收集无法直接关联到个人身份的个人信息;

–执行明示同意需要收集额外联系方式等个人信息才可以实现;

–执行同意需要付出大额成本才可以实现;

–告知后执行同意可能对个人信息主体使用产品或服务的良好习惯带来削减;

–告知后执行同意可能影响业务运营安全的;

–告知后执行同意有助于保护个人信息主体权益;

–需告知的目的等内容为本标准第 6 章直接相关的。


9.2同意机制设计


个人信息控制者在明确告知的机制和内容后,应基于本标准第 7.2 和 7.3 中的原则,选择不同的同意模式,并设计相应的同意机制,以保证个人信息主体权利得到充分保障,个人信息控制者设计同意机 制时需注重考虑以下方面:

a)明确是否针对所有的告知行为均设置获得个人信息主体的授权同意的机制;

注:部分告知场景可能只侧重于向个人信息主体传达相关情况,如发生个人信息安全事件后向个人信息主体通知可采取的措施等。

b)个人信息控制者需以个人信息主体能够清楚理解的方式设计同意机制,在同意界面清晰地、明

确地向个人信息主体展示如何给予授权同意,使个人信息主体能够清楚地、无疑问的操作以表 达同意;

c)个人信息控制者宜在展示告知内容的同一页面征得个人信息主体的同意;

注:若告知内容与征得授权同意不在同一页面,个人信息主体可能会对授权同意的内容产生困惑。若无法在同一页面进行告知并征得授权同意,应当采取进一步措施确保个人信息主体了解其同意的内容。

d)个人信息控制者应当避免选取模棱两可的同意机制,必须确保个人信息主体授权同意的行为可

以与其它行为区分开来,使个人信息主体授权同意的意图毋庸置疑,例如将个人信息主体对同 意隐私政策后使用相应业务功能与愿意参与商业推广活动相混淆;

注 1:通过设置“下一步”“注册”“继续”“登录即代表注册”等方式征求个人信息主体授权同意时,明确执行上述动作与同意隐私政策等个人信息收集使用规则之间的逻辑关系;

注 2:在执行个人信息安全影响评估工作的过程中,可采取与个人信息主体代表沟通、调研等方式分析同意机制是否模棱两可。

e)个人信息控制者应当将个人信息处理的同意与其它同意区分开来,且不应将其隐匿在其它事项

中,使得个人信息主体被迫或接受;

注:例如个人信息主体接受一般性的服务条款通常不构成个人信息主体授权同意处理其个人信息。

f)个人信息控制者应通过区分不同类型目的的方式逐步征得个人信息主体授权同意,以保障个人 信息主体表达自主意愿;

注:当产品或服务提供多项需收集个人信息的业务功能时,不采取强迫、捆绑等方式要求个人信息主体接受个人信息收集请求,具体可参考 GB/T 35273《信息安全技术 个人信息安全规范》5.3 节。

g)个人信息控制者提供某类业务功能或在特定的处理目的时,应允许个人信息主体就满足业务功

能或特定目的必需收集的个人信息,与提升服务质量和用户体验、提高安全性、支撑产品或服 务改进等目的所收集的可选个人信息分别授权同意;

h)如收集个人信息可能对个人信息主体权益造成重大财产损失的,可同时使用多种方式确保个人信息主体充分知情,如在交互式界面执行“下一步”“同意”等操作基础上,进一步采取电话回访、签字确认等方式;

i)个人信息控制者设计同意机制时,宜参照有关国家标准,通过个人信息安全工程等方法,对处 理个人信息的系统架构进行充分考虑,以便于支持个人信息主体执行撤回授权操作,以及在系 统中同步进行限制使用、删除等处理;

j)当个人信息主体拒绝授权同意后,宜采用适当的方式向用户展示、说明拒绝后的结果,避免采 用卡死、退出、频繁打扰等方式,具体包括:

1)设计相关机制,在个人信息主体最终拒绝授权同意后,自动删除在个人信息主体征得授权 同意过程中提交的个人信息。例如,个人信息主体填写了部分个人信息,但最终未同意进 行上传操作;

2)个人信息主体拒绝授权同意后,如相关个人信息为提供服务所必需,可再次向个人信息主 体告知目的等规则,提醒个人信息主体进行授权同意;

3)个人信息主体拒绝授权同意后,如相关个人信息并非为提供服务所必需,需避免向用户频 繁询问打扰(如 48 小时内多次询问)方式征得授权同意;

注:个人信息主体主动选择使用某业务功能触发征得授权同意的动作,不属于频繁询问打扰。

4)个人信息主体拒绝授权同意某业务功能收集使用个人信息后,宜切换至产品或服务的基本 业务功能或其他业务功能相关界面;

5)个人信息主体拒绝授权同意基本业务功能收集使用个人信息后,可切换至不涉及个人信息收集的服务模式(如静态页面、非个性化的浏览页面等),如不提供该模式的,可再次向个人信息主体告知目的,如个人信息主体再次拒绝,可采取退出方式不再提供服务。

k)除上述内容外,不同场景下的征得授权同意案例可参考附录 A-L。


9.3同意的撤回


个人信息控制者需设立便捷机制使个人信息主体能够随时撤回其授权同意,并应考虑以下几点:

a)授权同意的撤回不影响在撤回前基于授权同意作出的个人信息处理;

b)个人信息主体在作出授权同意之前,个人信息控制者需告知其拥有撤回授权同意的权利,且撤 回同意的操作的容易程度与授权同意相当;

c)如果个人信息主体无法撤回同意,个人信息控制者需向个人信息主体解释造成该情况的原因;

d)个人信息控制者在实施同意撤回动作之前,需确认请求提出者为个人信息主体本人或有权处理 者;

e)个人信息主体撤回特定业务功能收集个人信息的授权时,个人信息控制者需避免暂停供其他业 务功能,或降低其他业务功能的服务质量,除非用户拒绝或撤回的个人信息授权是其他业务功 能所必需;

f)个人信息主体撤回同意后,非经个人信息主体再次授权同意,个人信息控制者不应再处理相关个人信息,个人信息主体要求删除信息的,个人信息控制者需及时删除或匿名化相关个人信息。


9.4同意的证据留存


a)个人信息控制者可根据自身情况留存同意的证据用于可能的自证需求。可以选择的证据内容包 括且不限于以下内容:

1)个人信息控制者根据个人信息收集处理活动的评估,设计并实施告知和确认同意方案的记 录。记录可包括:根据个人信息敏感性及风险程度选择告知同意方式的判断记录、告知内 容的撰写与批准记录、真实实施与设计一致的验证记录等;记录的方式可包括个人信息控 制者内部的文档或邮件记录、个人信息影响评估工具记录、专业咨询机构提供的第三方意 见记录等。

2)与个人信息主体关联的同意记录。记录可包括:个人信息主体 ID、同意的方式、同意的时间、该同意对应的告知内容等。记录方式可包括:个人信息主体授权同意的页面或过程 的直接留存、与该同意有逻辑关联的日志记录、与该同意有逻辑关联的数据库标记等;

3)涉及不同时间段发布的需征求个人信息主体授权同意的隐私政策等个人信息保护政策文 本及版本;

4)当多个个人信息控制者之间分享个人信息时,与其它个人信息控制者共同设计和实施告知 和确认同意方案的记录。记录可包括:与其它个人信息控制者对告知和确认同意责任的分配约定记录、对其它个人信息控制者的尽职调查记录、与其它个人信息控制者就上述 a) b) 两类记录共享的约定记录。

b)个人信息控制者可根据相关法律法规要求和自身举证的需要决定证据留存的时限,建议留存时 间不少于 2 年;

c)个人信息控制者留存同意的证据需遵循最小必要原则,避免以留存征得授权同意证据为由,扩 大个人信息的收集范围;

d)个人信息控制者需对留存证据本身的使用范围严格限制,并采取足够的技术和管理措施保障数 据安全;

e)个人信息控制者如需委托第三方保存或公证留存的证据,需要求受委托的第三方遵守同等的数 据安全和使用控制要求。



附 录 A

(资料性附录)

未成年人个人信息的告知同意


收集使用年满14周岁的未成年人的个人信息前,宜将个人信息使用规则等信息告知该未成年人或其 监护人,并征得该未成年人或其监护人的明示同意;收集不满14周岁的儿童个人信息前,应将个人信息使用规则等信息告知该儿童的监护人,并征得其监护人的明示同意。


A.1告知的内容


收集使用未成年人个人信息的告知,除本标准 8.1 中的相关信息外,还可以包含下列信息:

a)未成年人个人信息的敏感性与注意事项;

b)针对未成年人个人信息的敏感性所采取的特别的安全保障措施;

c)监护人更正、管理未成年人个人信息的方式和途径;

d)监护人正确履行监护职责,教育引导儿童增强个人信息保护意识和能力的方式;

e)若涉及幼儿园、学校等决定采用自动化设备收集未成年人个人信息的,可以说明采取此类措施的正当性、合法性与必要性,有必要时可提供相关的个人信息安全影响评估报告的全文或摘要, 与监护人进行集体沟通的,可以告知沟通的总体情况与结论。


A.2告知同意的方式


A.2.1核验未成年人和监护人身份的方式


个人信息控制者可以采取合理措施核验个人信息主体的年龄,区分个人信息主体为不满 14 周岁的儿童以及已满 14 周岁的未成年人的情形。

若个人信息主体为不满 14 周岁的儿童,则宜采取合理措施核验该未成年人监护人的身份;若个人信息主体为已满 14 周岁的未成年人,则宜继续采取合理措施核验该未成年人监护人的身份。

核验的方式宜充分考虑不同的产品或服务在受众群体上的本质差异,如果对所有的产品或服务都采 取同一核实方式,可能会对用户造成打扰,例如,对于有关个人所得税查询的产品或服务而言,如果一 昧地要求个人信息主体进行严格的身份验证,则很可能会招来个人信息主体的不满。因此,对于不同的 产品或服务宜采取不同强度的核验方式。


a)核验未成年人身份的方式

1)未成年人非为主要受众群体的产品或服务:未成年人极少使用手机银行、租房等产品或服 务,此时宜采用验证强度较低的方式进行核实,例如,通过弹窗或提供勾选功能询问个人 信息主体是否已年满 14 周岁,让用户主动点击确认是否已年满 14 周岁;或通过可以在隐私政策的弹窗中告知若为不满 14 周岁的未成年人需在取得监护人的同意后才可使用相关产品或服务等。

2)不能区分未成年人是否为受众群体的产品或服务:未成年人和非未成年人使用游戏、社交 等产品或服务的可能性都比较大,此时宜采用验证强度较高的方式进行核验,例如,让个 人信息主体输入生日信息(精确到年月日)、身份证号;或通过弹窗询问的方式等合理的方式进行身份验证,但上述措施不应超过必要限度(例如不应要求未成年人上传其手持身 份证的照片)。

3)明显使用受众为不满 14 周岁的儿童的产品或服务:对于面向儿童的教育、影视等应用或产品,宜直接履行相关未成年人保护义务,在首次开启或运行时向监护人履行告知义务, 不再对儿童身份进行验证。


注 1:核验的方式宜充分考虑不同的产品或服务在受众群体上的本质差异,如果对所有的产品或服务都采取同一核实方式,可能会对用户造成打扰,例如,对于有关个人所得税查询的产品或服务而言,如果一昧地要求个人信息主体进行严格的身份验证,则很可能会招来个人信息主体的不满。因此,对于不同的产品或服务宜采取不同强度的核验方式。


b)核验监护人身份的方式

1)若根据以上方式核验个人信息主体的身份为未成年人的,宜根据产品收集未成年人信息的情况,决定是否继续验证监护人身份。对于应用或产品收集未成年人信息量大,或一旦处理不慎可能导致严重侵害未成年人身心健康的(例如,学校为统计学生相关情况而收集的考试成绩、作业完成情况以及身体健康情况等),宜继续采取合理措施核验监护人身份。为确保授权的有效性,合理措施可包括短信验证、电话验证、邮箱验证、超链接验证等; 对于经过隐私影响评估认为对未成年人不会造成严重身心侵害或财产损失的,可以通过应用弹窗等方式敦促监护人履行监护义务。

注 2:应用或产品可以采取多种并行的措施完成未成年人或监护人的身份验证,避免仅因一种验证模式失效(例如无法接收验证码)导致应用或产品无法使用。

i.终端或应用仅单独面向未成年人的:核验的方式可采取短信验证、电话验证、邮

箱验证等合理措施进行。例如,对于一旦处理不慎,可能对未成年人身心、财产造成损失的,可以通过让该未成年人输入监护人的手机号码,将验证监护人身份 的内容发送至监护人的手机上,监护人可通过回复特定字段以表示是否为该未成 年人的监护人;对于难以对未成年人造成严重侵害的,可以通过弹窗等显著提示 的方式要求监护人履行监护职责等。

注 3:短信内容可参照:尊敬的用户您好!这里是 xxxx,根据国家有关未成年人个人信息保护的要求,收集使用年满 14 周岁的未成年人的个人信息前,宜征得该未成年人或其监护人的

明示同意;收集不满 14 周岁的未成年人的个人信息前,应征得其监护人的明示同意。若您是

xxx 的监护人,请回复“1”,若不是请回复“2”。本条短信 5 分钟内容有效。

ii.若产品或服务为未成年人和监护人提供了不同终端或应用界面的,核验的方式可 直接在监护人终端或应用界面中完成。例如,在未成年人的终端或应用界面提示 为满足国家有关未成年人个人信息保护的要求,需要该未成年人将有关产品或服 务的个人信息使用规则等信息告知其监护人,此时该未成年人的终端或应用界面 上已生成用于分享给其监护人的超链接或二维码。未成年人可分享超链接或二维 码至其监护人,其监护人打开该超链接或扫一扫该二维码之后可以下载或进入监 护人专门的终端或应用,该监护人可在该终端或应用界面上确认其是否为该未成 年人的监护人;或在监护人界面设置主动开启未成年人设备的开关,监护人端开 与未成年人端通过 WLAN、蓝牙、移动网络完成鉴权和连接的,视为完成验证等。

2)若根据以上措施未能有效进行监护人身份验证的,当发生监护人投诉认定错误时,产品宜 提供监护人监护申请渠道,提交与被监护人相关信息进行平台验证,如户口验证。


A.2.2告知的方式


终端或应用仅单独面向未成年人的,宜使用未成年人可理解的方式进行告知,包括但不限于短信、 消息推送、电子邮件等方式,并在相关协议或交互界面中重点说明收集、使用未成年人信息的情况和敏感性,可参考身份核验的合理措施向其监护人进行告知,即在核验其为未成年人身份后,继续核验其监护人身份时,可将相关需要告知的信息采用短信、消息推送、电子邮件的方式向其监护人告知,或者在产品首次运行或开启时,通过弹窗未成年人保护模式,增加未成年人用户保护须知链接等方式向未成年 人或其监护人进行告知。

注 4:短信内容可参照:尊敬的家长您好!这里是 xxxx,根据国家有关未成年人个人信息保护的要求,收集使用年满 14 周岁的未成年人的个人信息前,宜向该未成年人或其监护人告知个人信息使用规则等信息,并征得该未成年人

或其监护人的明示同意;收集不满 14 周岁的未成年人的个人信息前,应向该未成年人的监护人告知个人信息使用规

则等信息,并征得其监护人的明示同意。您的孩子正在试图使用我们提供的 xxxx 产品或服务,有关该产品或服务的个人信息使用规则等信息请您点击 xxxx(超链接方式)进行了解。

若产品或服务为未成年人和监护人提供了不同终端或应用界面的,可以根据角色分别制定告知方案。 未成年人端可以通过简明、易于理解的形式展示其在使用产品或服务过程中可能遇到的个人信息问题, 并加以注意;监护人端可以通过弹窗、提示框、文字说明等形式详细说明未成年人信息收集、使用的情 况,并重点提示未成年人个人信息的敏感性。例如,在未成年人的终端或应用界面提示为满足国家有关 未成年人个人信息保护的要求,需要该未成年人将有关产品或服务的个人信息使用规则等信息告知其监 护人,此时该未成年人的终端或应用界面上已生成用于分享给其监护人的超链接或二维码。未成年人可 分享超链接或二维码至其监护人,其监护人打开该超链接或扫一扫该二维码之后可以下载或进入监护人 专门的终端或应用,该监护人可在该终端或应用界面上查询相应需要告知的内容。

若涉及幼儿园、中小学校、社会教育培训机构等决定为未成年人配置教学、辅导等设备,以及在学习、游乐场公共场合场景下收集未成年人个人信息的,可以通过信件、公示、签署协议、即时通讯工具, 以及包括学校决定集体采购用于教学的设备终端(供每个学生使用的 Pad 等)等方式告知未成年人监护人个人信息使用规则等信息。告知的方式可参考附录 D。

注 5:幼儿园、学校决定采用自动化设备收集未成年人信息(例如,为检验教学质量而采取监控设备、采用电子课

程应用软件布置教学作业、采用物联网设备辅助教学等),一旦投入建设或进行采购,则监护人便难以做出有效反对。因此在决定采用自动化设备前,宜开展个人信息安全影响评估并与监护人进行集体沟通协商,根据协商结果做出最终决定。


A.2.3同意的方式


终端或应用仅单独面向未成年人的,可参考向未成年人的监护人进行告知的方式,并在告知时同时 征求监护人的同意,即在将相关需要告知的信息采用短信、消息推送、电子邮件的方式向其监护人告知 时征求监护人的同意。

注 6:短信内容可参照:尊敬的家长您好!这里是 xxxx,根据国家儿童人个人信息保护的要求,收集使用年满 14 周

岁的未成年人的个人信息前,应向该未成年人或其监护人告知个人信息使用规则等信息,并征得该未成年人或其监护人的明示同意;收集不满 14 周岁的未成年人的个人信息前,应向该未成年人的监护人告知个人信息使用规则等信息,并征得其监护人的明示同意。您的孩子正在试图使用我们提供的 xxxx 产品或服务,有关该产品或服务的个人信息使用规则等信息请您点击 xxxxx(超链接方式)进行了解。若您同意您的孩子使用该产品或服务,请回复“TY”,若不是请回复“NO”。本条短信 5 分钟内容有效。

若产品或服务为未成年人和监护人提供了不同终端或应用界面的,可在向监护人告知个人信息收集 使用规则等信息时同时征求监护人的同意。例如,在监护人通过弹窗展示授权页面,让监护人选择“同意”或“拒绝”,或在监护人得到充分告知前提下,主动将其终端与未成年人应用进行绑定,可以视为监护人同意等。

若涉及幼儿园、中小学校、社会教育培训机构、儿童游乐场等单位收集使用未成年人个人信息的,可以在通过信件、公示、签署协议、即时通讯工具等方式告知未成年人的监护人个人信息收集使用规则 等信息时,征求其监护人的同意。同意的方式可参考附录 D。

注 7:幼儿园、学校为根据法律法规要求和必要的教学管理所需而收集未成年人信息的(例如学籍信息、考勤信息、考试成绩等),可以免于征求同意,属于本标准 6.1 中收集使用个人信息时免于告知同意的情形。







附 录 B

(资料性附录)

SDK 收集使用个人信息场景下的告知同意


SDK 是 Software Development Kit 的缩写,即“软件开发工具包”。简单来看,它是辅助开发某一类应用软件的相关文档、范例和工具的集合。对 App 来说,为了提高开发效率,可以将某项功能交给第三方来开发,第三方服务提供商将服务封装为工具包(即 SDK)供开发者使用。目前,SDK 类型主要包括:第三方登录分享类、支付类、推送类、广告类、数据统计分析类、地图类、风控插件以及一些基础库等。

SDK 提供者指开发并运营 SDK 的组织或个人。SDK 集成者指集成 SDK 并使用其功能的组织或个人,在 App 直接集成 SDK 的情况下,也称“宿主 App 运营者”。


B.1告知的内容


涉及集成和使用具有个人信息收集、处理的第三方 SDK 的移动应用,告知中还应包含以下内容:

a)第三方 SDK 组件列表或组件类别示例;

b)第三方 SDK 是否进行了智能移动终端操作系统权限调用以及调用的主要权限(但 App 基于现有技术水平内无法或未能检测到第三方 SDK 权限调用行为的除外);

c)第三方 SDK 收集的主要数据及使用目的(但 App 基于现有技术水平内无法或未能检测到第三方 SDK 数据采集行为的除外);


B.2告知同意的适用情形


B.2.1一般的告知情形/收集使用个人信息时的告知同意


收集使用个人信息的告知同意情形原则上同标准5.1 要求。对于SDK 本身存在收集个人信息的情况, 应将所收集的个人信息类型及收集使用的目的告知个人信息主体。为此,SDK 提供者应将 SDK 收集个人信息的全部情况(参考 GB/T 35273 5.3)通过合同、开发者协议等形式先行告知宿主 App 运营者, SDK 提供者与宿主 App 运营者依据标准所适用的情形,针对涉及个人信息收集的情况,采取适宜的方式进行个人信息收集的告知同意,SDK 提供者应提供必要的配合,否则宿主 App 运营者应停止集成该SDK,SDK 提供者应停止收集处理行为。根据 SDK 的功能不同,具体情况可以分为:

a)当 SDK 提供者不是个人信息控制者、仅作为数据处理者时(即提供的 SDK 为功能性 SDK, 所收集的个人信息全部为宿主 App 运营者控制),SDK 提供者应告知宿主 App 运营者 SDK收集个人信息的功能和范围;宿主 App 运营者应在 SDK 收集个人信息前向个人信息主体告知并应征得个人信息主体同意。

b)当 SDK 提供者仅从宿主 App 运营者处共享个人信息时,宿主 App 运营者应向个人信息主体告知信息对外提供情况并应征得个人信息主体同意(标准主体 5.3)。

c)当 SDK 提供者是直接个人信息控制者时(即 SDK 提供者通过 SDK 直接收集个人信息,宿主APP 不能控制收集到的个人信息),SDK 提供者应首先向宿主 App 运营者告知所收集的个人信息类型及收集使用的目的,范围等。宿主 App 运营者同意后方可集成 SDK,SDK 提供者应通过SDK 本身或通过宿主 APP,在收集个人信息前向个人信息主体告知并应征得个人信息主体同意。例如,SDK 提供者通过单独用户界面的交互形式征得个人信息主体同意。

注:如电商网站的支付SDK,点击支付 SDK 服务商的图标后会跳转/展示到 SDK 对应的页面上进行登录以及支付,在此场景下支付 SDK 独立收集并处理支付相关的个人信息,支付 SDK 宜在用户注册或使用服务时告知用户,展示第 9.1 条的告知内容,并征得用户的同意。

d)当 SDK 提供者与宿主 App 运营者构成共同个人信息控制者时(即 SDK 提供者通过 SDK 直接

收集个人信息,宿主 App 运营者同时也可以控制收集到的个人信息),SDK 提供者应首先向宿主 App 运营者告知所收集的个人信息类型及收集使用的目的、范围等。宿主 App 运营者同意后方可集成 SDK,宿主 App 运营者和 SDK 提供者各自或共同说明收集个人信息情况,并应征得个人信息主体同意。


B.2.2使用目的变更时的告知同意


如存在本附录中SDK前述相关信息重大变更的情况,则应更新告知,并重新征得用户同意。


B.3免于告知同意的情形


a)当 SDK 提供者不是直接的个人信息控制者时,宿主 App 运营者应对个人信息主体负有有效告知同意义务。告知同意的例外适用标准主体 6.1 部分.

b)当SDK 提供者不是直接的个人信息控制者但后续通过宿主App 运营者的提供而成为个人信息控制者时,宿主 App 运营者应对个人信息主体负有有效告知同意义务。告知同意的例外适用标准主体 6.3 部分.

c)当 SDK 提供者是直接的个人信息控制者时,SDK 提供者对于宿主 App 运营者的告知同意例外适用于标准主体 6.1 和 6.3 部分;宿主 App 运营者基于被告知的信息,对个人信息主体告知同意的例外适用于标准主体 6.1 和 6.3 部分。




附 录 C

(资料性附录) IoT 场景下的告知同意


IoT 是 internet of things 的缩写,中文为“物联网”。物联网是指通过“随时”和“随地”连接任何事物而创建的一个全新的、动态的网络。


C.1告知的内容


参考 8.2 节中所列的告知内容。


C.2告知同意的方式


C.2.1智慧生活场景下的告知同意方式


C.2.1.1告知同意方式


智慧生活设备是围绕用户家居生活的各种设备,包括照明设备、家用电器、各类传感器、监控摄像 头等,智慧生活设备可以连接到云,由云端提供管理和服务,并通过控制设备,如手机、音箱等对其进 行控制。

个人信息控制者(“控制者”)通过智慧生活设备收集个人信息的告知同意包括以下方式:

a)弱界面交互的产品,其告知内容通过建立连接设备上的 web UI 上展示,并获得用户的同意; 如无线路由器、CPE(用户驻地设备);

b)在用户手册、说明书或者设备标签上提供告知内容或访问链接;

c)若控制者通过智慧生活设备收集的个人信息,控制者可以通过与用户交互的 App 告知用户, 并获得用户同意;

d)智慧生活平台提供对智慧生活设备的管理和服务。为实现对智慧生活设备的管理和服务,控制 者需要通过智慧生活平台收集注册到智慧生活平台上的设备的相关信息。在收集该信息前,控 制者应通过与用户交互的 App 告知用户所收集的个人信息,并征得用户同意;

e)智慧生活平台上的业务提供方作为数据控制者(例如,提供智慧生活设备的第三方厂商)为实 现智慧生活相关业务所收集的用户个人信息,应由业务提供方实现告知,并获得用户同意;

f)若 App 在与智慧生活设备绑定前就已经开始收集个人信息的,应当通过该 App 进行告知同意。控制者通过智慧生活设备向第三方分享、从第三方获得个人信息的告知同意包括:

a)为实现智慧生活平台和第三方平台之间的互联,当用户授权第三方账号登陆时,控制者应按照 第 5.1 条的要求,向用户展示控制者通过智慧生活平台从第三方平台获得的用户设备等个人信息的类型、目的等内容,并获得用户同意。

b)若涉及控制者通过智慧生活平台向第三方共享用户个人信息的,控制者应按照第 5.3 条和第

8.1.1 d)条的要求告知用户,并获得用户同意。

c)若智慧生活平台所提供的服务若跳转到由第三方提供的服务界面,且该第三方独立收集、使用 用户个人信息的,控制者还应告知用户第三方服务的名称。


C.2.1.1 告知的时机


控制者通过智慧生活设备或服务收集用户个人信息前,应该告知用户所收集的个人信息并获得用户同意,包括首次使用智慧生活设备或服务时。


C.2.2运动健康场景下的告知同意方式


C.2.2.1告知同意方式


运动健康指为用户提供运动指导和健康服务的产品或服务,运动健康设备包括智能手表、智能手环、 耳机等穿戴设备和健康管理设备,如体脂秤、血压计、健身设备等。

运动健康场景下收集个人信息的告知同意包括:

a)运动健康设备多为没有屏幕或屏幕尺寸受限等难以进行告知同意的设备,与运动健康设备相关 的个人信息处理控制者可以在提供运动健康服务的 APP 上实现告知同意。

b)用户通过提供运动健康服务的 APP 绑定运动健康设备前,控制者应告知用户的运动数据、健康数据等个人信息同步到提供运动健康服务的 APP;若存在设备间数据同步,则控制者应告知用户同步的设备名称、在设备间分享的数据类型,并告知用户停止共享的方式。

c)控制者通过运动健康平台收集用户的基础个人信息(如身高、体重等)、运动信息、健康信息等个人信息应在收集信息前明确告知用户,并获得用户同意。

运动健康场景向第三方分享个人信息的告知同意包括:用户使用运动健康服务时,其个人数据可以 共享给第三方,以使用户使用第三方应用提供的服务,在数据共享前控制者应按照正文按照第 5.3 条和

第 8.1.1 d)告知用户,并得到用户授权,并告知用户取消授权的方式。


C.2.2.2告知的时机

用户首次使用运动健康服务、绑定运动健康设备、或使用三方运动健康提供服务时,告知用户。


C.2.3智能音箱场景下的告知同意方式


智能音箱是指可连接网络实现播报新闻、播放音乐、互动聊天以及可能包含控制其他智能家庭设备 的功能,可能采用语音等交互方式操控的音箱。


C.2.3.1.告知同意方式


控制者通过智能音箱收集个人信息的告知同意包括以下方式:

a)若智能音箱配备显示屏且足以展示告知内容的,控制者可以在自带的显示屏上进行展示并获得用户同意。

b)若智能音箱不配备显示屏,或者为了更好的阅读体验,控制者可以在其他终端展示,并通过(在 屏幕直接显示或在印刷包装上)提供二维码、短链接(URL)等方式引导个人信息主体访问, 或者采用语音播报提示重要内容,并获得用户同意,但应避免在此过程中收集个人信息。

c)若智能音箱可以绑定 APP,控制者可以通过绑定该设备的 APP 展示告知内容,并通过 APP 获得用户同意。此种情况下,宜在 APP 启动或账号登录时向用户展示告知内容,并通过 APP 获得用户同意。

d)对于用户来说可感知及可预期的功能所对应的个人信息数据收集、存储、使用等行为,可以在隐私政策等个人信息使用规则中体现以告知用户,并获得用户同意。

智能音箱向第三方分享、从第三方获得个人信息的告知同意包括:

a) 当智能音箱是其他智能家居设备的控制中枢,且该智能家居设备由其他个人信息控制者处理个人信息的,或者智能音箱集成了其他控制者开发的应用的,则控制者通过智能音箱在向其他个 人信息控制者传输或者获取其他个人信息控制者收集的个人信息前(比如控制者需要通过智能 音箱将用户操作指令传输给其他设备实现操作,而其他设备操作后需要返回操作结果等给智能音箱进而播报给用户),应当告知用户并获得用户同意。

注:如果智能音箱设备的个人信息控制者仅提供工具供个人信息主体(用户)使用,且不对个人信息进行访问的, 不属于收集。例如,用户仅在本地唤醒智能音箱,以及后续在本地与智能音箱进行交互的行为,如果上述行为涉及的个人信息不回传至控制者,则不属于通过智能音箱收集用户个人信息,因而对此无需进行用户告知同意。


C.2.3.1告知的时机


用户首次使用智能音箱 APP、绑定智能音箱设备、或使用第三方智能家居设备时,告知用户。对于允许多用户(例如,家庭中的不同成员)的设备,可以采用代为授权的方式获得同意。但是对

于需要识别用户身份的功能(例如,支付、人脸识别等),仍需在每个用户首次使用时获得同意。


C.2.4告知的形式


告知的形式参考 8.2 节,包括隐私声明、隐私通知等。具体形式可以为弹窗询问、开关、链接、文字展示等。注意展示的字体、行距等足以让用户可清晰阅读。


附 录 D

(资料性附录)

公共场合场景下的告知同意


公共空间是指向不特定的社会公众开放的、供公共使用和活动的场所,包括市政道路、建筑物、公园、广场、绿地、滨水区域等开放式空间,也包括政府机关或企事业单位管理的机场、火车站、学校、 图书馆、商场、餐饮娱乐产所、公共交通工具等非开放式空间。


D.1告知的内容


a)建议个人信息控制者在产品 PC 端、移动端与公共场所的问讯处、柜台、管理办公室等处同时提供完整隐私政策或条款文本,供个人信息主体需要时查阅,内容宜包括本指南 8.1 建议的告知内容。

b)商场等公共场所收集未成年人个人信息的告知参照附录 A。

c)在不特定人群进入的公共场所收集人脸等个人敏感信息的,应当符合法律法规的相关规定,并 明确标识信息采集设备的性质和目的。

d)在特定人进入的场所采集人脸特征等个人敏感信息的,应当明确标识信息采集设备的性质和目 的,并征得信息主体或其合法监护人的授权同意,依据法律法规和相关约定的情况除外。

e)在学校场景下采用人脸识别或者脑电波检测等技术收集人脸、脑电波等个人敏感信息的,应当 明确标识信息采集设备的性质和目的并征得信息主体或其合法监护人的授权同意,并为信息主 体提供拒绝的路径和方式。

f)在新零售场景下采用刷脸登陆、刷脸支付等技术时收集人脸等个人敏感信息的,应当明确标识 信息采集设备的性质和目的并征得信息主体或其合法监护人的授权同意,并为信息主体提供其 他登陆或支付的路径和方式,依据法律法规和相关约定的情况除外。

注:收集人脸信息仅用于与设备本地已存储的人脸信息进行比对或进行本地化处理而没有回传服务器的,不属于人脸信息的收集行为。


D.2告知同意的方式


a)在汽车站、火车站、地铁站、机场、商场等公共场所收集个人信息时,建议个人信息控制者以显著方式向个人信息主体进行展示告知。公共场所张贴告知内容宜简短易懂,效果宜显著醒目, 同时告知获取更多相关信息的途径。方式包括但不限于:

1)在汽车站、火车站、地铁站、机场、商场、店铺入口显著处张贴告知,例如:本地铁站安 装有人脸识别系统,用于进行人群分流安检,我们承诺会保护您的人脸等信息安全,详情 可向询问台咨询或扫描二维码。又如:本商场安装有人脸识别系统,以便进行客流分析或 进行个性化推荐。我们承诺会保护您的人脸等信息安全,详情可向询问台咨询或扫描二维 码。

2)在摄像头安装显著处张贴告知,例如:此处摄像头用于人脸识别,以便实现 XXX 目的。我们承诺会保护您的人脸等信息安全,详情可咨询收银台或扫描二维码。

3)在人脸识别购物柜显著处张贴告知,例如:此购物柜使用人脸识别支付,我们承诺会保护 您的人脸等信息安全,详情可扫描二维码。

4)在商场或柜台导购导引时告知,例如:您成为我们的会员需要收集您的生日和地址,用于给您寄送赠品。我们不会泄露您的个人信息,具体信息您可以查询我们官网的隐私政策。

5)在顾客于柜台交易支付页面显著处张贴或者弹窗告知隐私政策。


b)当个人信息主体拒绝在公共场所收集其个人信息时,建议相关公共场所提供不收集个人信息的 选择方案,例如,不参与分流安检的通道;不成为会员的购买方式;不通过人脸识别的支付方 式等。

c)公共场所收集未成年人个人信息的告知参照附录 A。

d)公共场所出于公共安全等原因由公权力安装摄像头或查询、向外提供个人信息参照本指南 6.1

与 6.3 相关条款。


D.3免于告知同意的情形


个人信息控制者在公共空间收集个人信息的,以下情形属于“收集使用个人信息的告知同意例外” 中所列的特殊情形,无需征得个人信息主体的明示同意:

a)信息主体自行公开的信息,但信息主体明确拒绝或者处理该信息侵害其它重大利益的除外。

b)与个人信息控制者履行法律法规规定的强制性义务相关的;

c)与国家安全、国防安全直接相关的;

d)与公共安全、公共卫生、重大公共利益直接相关的,例如在公共场所接入安防监控系统,并将监控系统与公安等监管部门对接;

e)所涉及的个人信息是个人信息主体自行向社会公众公开的,例如收集、使用用户在公共空间自行向公众公开的本人姓名、电话、照片等个人信息;

f)为履行或签订个人信息主体与个体信息控制者之间的合同所必要的,例如乘坐公交时,公交记录的用户刷卡时间、刷卡人 ID、刷卡方式、乘车地点和下车地点等;

g)法律法规规定的其他情形。

注:个人信息控制者在公共空间收集个人信息,但在收集前难以取得个人信息主体明示同意的,如果数据处

理不以“识别信息主体身份”为目的且不会对个人信息主体合法权益产生不利影响的,可以不经用户明示同意,但应当向个人信息主体提供了解其具体数据处理目的和方式的途径,并向用户提供撤回同意的渠道。例如,商场运营者出于优化商户管理、活动管理等合法正当目的,会基于商城内部署监控系统,统计和分析商场的人流量等。个人信息控制者基于上述场景收集完数据后,如果希望将收集的数据用于识别特定信息主体身份(例如收集人脸识别数据用于课堂情况监测或个性化推荐),应当就该等数据处理目的取得该信息主体的明示同意。



附 录 E

(资料性附录)

个性化推荐场景下的告知同意


个性化推荐是指个人信息控制者利用个人信息,通过算法向个人信息主体有针对性地推送商品、新 闻、资讯、音视频、广告等信息。仅根据热度、地区或时间流等自然排序的信息分发模式不属于个性化 推荐。


E.1告知的内容


告知的内容向个人信息主体告知个性化推荐的内容,除本标准规定可以告知的相关信息外,还可以 包含下列信息:

a)个性化推荐功能收集的数据类型以及通俗简单的一般原理或通用的实现方式;

b)个性化推荐功能由第三方个人信息控制者提供的,可以告知第三方主体情况、数据处理方式等 信息。例如:信息流推送功能由第三方提供的,可以在进入相关功能时向个人信息主体告知该 服务的提供者,并可以通过链接等形式展示收集、处理、共享数据的情况;

c)个人信息主体管理个性化推荐功能的方式,例如:告知用户如何关闭程序化广告推送或者如果 管理个性化推送的标签、模块等;

d)如提供采用非个性化推荐的同类功能,可以告知进入或开启该功能的方式,例如:告知用户在 相关频道、板块可以浏览非个性化信息;

e)可以在用户协议、隐私政策、说明文案等灵活方式说明可能对个人信息主体的权益或自主决策 造成的影响。


E.2告知同意的方式


告知同意的方式向个人信息主体提供个性化推荐功能或服务,可以通过下列方式向个人信息主体告 知个性化推荐功能或服务收集、使用个人信息的情况:

a)以个性化推荐为核心业务模式的(例如:资讯浏览、音视频播放、社区论坛等),可以在 App首次使用前,通过交互设计(弹窗、文字说明、提示条、提示框、提示音)等方式向个人信息主体进行告知,用户通过点击弹窗、提示框按钮等方式表达已知并同意接受个性化推荐功能;

b)通过相关业务功能、板块、频道向个人信息主体提供个性化推荐的,可以在首次开启前,通过 弹窗、提示条、浮层等显著提示的方式进行告知;

c)提供互联网广告服务的个人信息控制者,可以在专门页面或可访问的文档中以简单通俗的方式 告知程序化广告的服务的一般通用基础原理;

d)个人信息主体主动提交的信息被用于个性化推荐的,宜告知信息分发的基本方式或原理,例如: 用户在短视频平台发布作品、进行评论、点赞进行分发的,宜告知可能会被推荐给对其提交信息感兴趣的其他相关用户。例如:帐号发布信息后,系统可以将该信息(文字、音视频)推送给关注该帐号或可能对该信息感兴趣的其他帐号;

e)个人信息控制者在提供个性化推荐时,可以在信息流、文章、音视频相关位置进行标识,或者 在栏目、版块、页面相关位置标注相关信息通过个性化推荐方式推送。

注:在广告联盟的广告活动场景下,如果采取标识方式提示个性化内容的,当媒介方成员不具备对广告推送内容和展示形式控制权时,可以由需求方平台以标识需求方平台身份。




附 录 F

(资料性附录)

云计算服务场景下的告知同意


云计算是一种计算资源的新型利用模式,客户以购买服务的方式,通过网络获得计算、存储、软件 等不同类型的资源。云服务商向客户提供云服务的同时,若收集使用客户的个人信息,宜将个人信息收 集使用规则等信息告知客户,并征得客户的明示同意。云服务客户在向最终用户提供服务时,若收集最 终用户的个人信息,宜将个人信息收集使用规则等信息告知最终客户,本附录仅对云服务商对云服务客 户的告知同意内容和方式给出参考。

图 F.1 中对不同服务模式下云服务商和客户的个人信息告知责任进行了划分。


image.png


图 F.1 不同云服务模式下的个人信息告知责任划分


F.1告知的内容


云服务商在向云服务客户提供服务时,收集的信息若涉及客户的个人信息,除本标准 8.1 中的相关信息外,宜将收集个人信息的目的同步告知客户,并征得客户的同意:

a)云服务客户的账号信息,包括登录账号、手机号、鉴别信息等;

b)云服务客户的实名认证信息,云服务客户的实名认证信息包括个人或企业的认证信息,如姓名

/企业名称、身份证号/营业执照号、手机号/邮箱等信息。

c)云服务客户采购云服务的消费信息,包括充值信息、交易记录、订单信息等;

d)云服务客户的个人信息的存储位置信息,当存储位置发生变化时,也应同步告知云服务客户。

e)云服务客户在向最终用户提供服务时,若收集使用最终用户的个人信息,作为个人信息控制着 应承担最终用户的个人信息保护责任。


F.2告知同意的方式


云服务商在收集个人信息时,宜向云服务客户告知收集、使用个人信息的目的、方式和范围,并获 得个人信息主体的授权同意,若涉及收集个人敏感信息的,宜征得个人信息主体的明示同意。云服务场景下的告知同意可根据云服务商和客户的约定,通过人机交互的方式告知同意或通过合同约定的方式进 行告知同意。


F.2.1人机交互式告知同意


人机交互式告知同意适用于客户通过 Web 管理控制台或智能终端自助获取云服务的应用场景,云服务商宜在收集客户个人信息前,通过提供隐私保护政策的方式,征得用户的同意,可通过设计如下功 能实现告知同意的目的:

a)当用户在 Web 管理控制台获取云服务时,云服务商宜在注册(登录)页面设置隐私保护政策的链接,用户在首次注册或登录管理控制台时,云服务商宜提示客户仔细阅读隐私政策的条款, 并通过要求客户主动点击的方式征得用户同意。

b)当客户在移动智能终端上获取云服务时,云服务商宜在 APP 首次运行时,通过弹窗等方式提示客户仔细阅读隐私政策的条款,并征得用户同意。

c)当获取用户敏感信息或试图打开获取用户敏感信息的系统权限时,应通过弹窗的方式征得用户 的同意。

d)当隐私保护政策的内容发生变更时,云服务商应通过弹窗、站内信、公告或邮件的方式告知用 户。


F.2.2合同约定式告知同意


合同约定式的告知同意适用于云服务商和客户通过签署纸质合同明确云服务内容和责任的场景,云 服务商应将隐私保护政策作为合同的附件,告知客户收集、使用个人信息的目的、方式和范围,双方签 署正式合同即可视为已经征得客户的明示同意。




附 录 G

(资料性附录)

互联网金融场景下的告知同意


互联网金融场景下的告知同意主要涉及三类场景:

金融借贷,是指为用户提供从金融机构进行个人消费贷款服务,包括授信、借款、还款与交易记录 等功能,这里的金融机构是指有放贷资质的银行、消费金融公司、小贷公司等在网络上提供借贷服务的 机构。

助贷业务,是指金融科技机构通过自有系统或渠道筛选目标客群,在完成自有风控流程后,将较为 优质的客户输送给持牌金融机构、类金融机构,经持牌金融机构、类金融机构风控终审后,完成发放贷 款的一种业务。

网络支付,是指收款人或付款人通过计算机、移动终端等电子设备,依托公共网络信息系统远程发 起支付指令,且付款人电子设备不与收款人特定专属设备交互,由持有支付许可证的非银行支付机构为 收付款人提供货币资金转移服务的活动。


G.1告知的内容


G.1.1收集使用个人信息的告知


a)金融机构收集法律法规要求的个人信息和实现服务所需的个人信息时,应将所采集的个人信息 类型及采集使用的目的告知个人信息主体,并通过个人信息主体对信息收集主动做出肯定性动 作征得其明示同意。

1)当金融机构出于向个人信息主体提供授信、借款、还款、交易记录等产品或服务而收集使 用个人信息时,应当在实名认证、绑定银行账户信息、获取个人征信信息、紧急联系人信 息、借贷交易记录等基本功能开启前,向个人信息主体告知基本业务功能所必要收集的个 人信息类型,包括网络日志、手机号码、身份证件信息、账户信息、银行账户信息、个人 征信信息、紧急联系人信息、借贷交易记录等。并向个人信息主体说明拒绝提供或拒绝同 意收集将带来的影响,并通过个人信息主体对信息收集主动做出肯定性动作(如勾选、点 击“同意”或“下一步”等)征得其明示同意;

2)当金融机构出于向个人信息主体提供产品或服务的扩展业务,包括但不限于基于定位的扩 展功能、基于相机的扩展功能、基于通讯录的扩展功能、基于日历的扩展功能、基于麦克风的扩展功能,收集使用个人信息时,应当在扩展业务功能开启前,向个人信息主体注意 告知所提供扩展业务功能及所必要收集的个人信息,并允许个人信息主体对扩展业务功能 逐项选择同意。

b)助贷机构在其业务场景中向个人信息主体告知除本标准 8.1 中的相关内容外,还可以包含下列内容:

1)收集个人信息的目的,助贷机构收集个人信息通常包含以下目的:产品展示与推荐、实人身份认证、初步信审、资金匹配、还款管理、安全保障等。例如,基于产品展示与推荐的目的,可以向个人信息主体告知,助贷机构基于用户画像向平台用户提供借款产品展示、 推荐,及其他商品或服务推荐的服务。

2)收集个人信息的方式,助贷机构通常基于以下方式收集个人信息:

i.在网页或应用程序页面内由个人信息主体主动填写、输入、上传等方式收集姓名、手机号码、个人身份信息、银行账户信息、住址、工作信息、紧急联系人、教育状况、 学历信息、婚姻状况等;

ii.通过与个人信息主体交互或记录个人信息主体行为等自动采集的方式收集平台交易 信息、设备信息、服务日志等;

iii.以及通过共享、转让、收集公开信息间接获取方式收集征信信息、位置信息、运营商 信息等;

3)收集个人生物识别信息前,助贷机构宜对安全保障措施予以说明并告知;在原则上不共享、转让个人生物识别信息的基础上,如合作金融机构确有获取个人生物识别信息的业务需求, 助贷机构需单独向个人信息主体告知目的、涉及的个人生物识别信息类型、数据接收方的 具体身份和数据安全能力等。

c)非银行支付机构收集法律法规要求的个人信息和实现服务所需的个人信息时,应将所采集的个 人信息类型及采集使用的目的告知个人信息主体,并通过个人信息主体对信息收集主动做出肯 定性动作征得其明示同意。

1)当非银行支付机构出于向个人信息主体提供消费、转账、支付账户充值和提现、交易记录等产品或服务而收集使用个人信息时,应当在开立支付账户、实名认证、绑定银行账户信息、支付交易验证时,以及设立、变更、挂失密码和数字证书等基本功能开启前,向个人信息主体告知基本业务功能所必要收集的个人信息类型,包括网络日志、手机号码、身份基本信息、身份证件信息、支付账号信息、银行账户信息、客户操作行为、交易信息、交易身份验证信息等,并向个人信息主体说明拒绝提供或拒绝同意收集将带来的影响,并通过个人信息主体对信息收集主动做出肯定性动作(如勾选、点击“同意”或“下一步”等) 征得其明示同意。


G.1.2对外提供个人信息的告知


a)金融机构向与其存在业务关系的第三方提供个人信息的,应当事先明确告知信息主体接收信息 的第三方的类型,提供目的、第三方收集、处理、使用个人信息的用途、范围和可能产生的后 果等,并取得信息主体的明示同意。

b)金融机构在评估个人信息保护及信息安全风险程度较低的情况下,通过协议方式委托第三方服务商对信息进行使用及处理,如计算机系统外包服务、科技外包服务商、广告服务、云服务、 债务追讨、司法诉讼、法律及财务专业咨询机构、第三方 SDK/API、小程序等。

1)固定类型的委托外包服务可在隐私政策或服务合同内予以列明,清晰告知客户;

2)不固定类型的委托外包服务可在具体应用场景予以说明,显著标示、提示第三方服务商名 称。

注 1:委托第三方处理信息之前,应充分审查、评估第三方服务商保护个人金融信息的能力,通过委托

处理协议约定职责和义务,对外部供应商、外部合作机构进行监督,并约定第三方服务商不得转委托。金融机构对委托机构及信息安全义务承担首要责任,不因委托而转移、减免。


G.2告知同意的适当性


助贷业务告知同意的适当时机:可以在借款客户选择“申请借款”、“立即申请”、“立即借款”等类 似表述后,并在借款申请的基本业务功能开启前,向个人信息主体告知基本业务功能所必要收集的个人 信息类型,以及个人信息主体拒绝提供或拒绝同意收集将带来的影响。

注 2:这样操作告知的时间点和收集个人信息的时间点相差时间适当,且明确知道该客户具备借款意图后(非游客状态)向其告知较为合适,同时避免对无借款意图的客户造成不必要的打扰。


G.3免于告知同意的情形


以下情形中,个人信息控制者共享、转让、公开披露个人信息,无需事先获得个人信息主体的授权 同意:

a)提供给中国人民银行反洗钱中心;

b)提供给中国互联网金融协会、中国支付清算协会及其他合法成立的行业协会;


除以上内容,互联网金融场景下个人信息告知的内容、方式、展示、适当性,同意模式与实现形式 等,可遵循指南的一般规定。


G.4互联网金融场景个人信息分类分级对照参考表(以网络借贷、助贷业务为主进行示例)


结合《JR/T 0171-2020 个人金融信息保护技术规范》4.2“个人金融信息类别”和互联网金融业务特点,以下列出了互联网金融业务常见个人信息分类及分级对照参考表。

注 3:关于互联网金融业务场景下的个人信息分类分级标准,可参考《JR/T 0171-2020 个人金融信息保护技术规范》



个人金融信息大类

个人金融信息子类

互联网金融业务个人信息

用户鉴别信息

C3

银行卡磁道数据(或芯片等效信息、卡片验证码(CVN CVN2、卡片有效

期、银行卡密码、网络支付交易密码

银行卡有效期信用卡卡号

账户(包括但不限于支付账号、证券账

户、保险账户)登录密码、交易密码、查询密码

登录密码

用于身份鉴别的个人生物识别信息

手持身份证照片



支付账号及其等效信息,如支付账号、证件类识别标识与证件信息(身份证、护照等、手机号码

姓名

手机号码、银行预留手机号码银行卡卡号、开户行信息

身份证号码、护照号码、证件号后四位



账户登录用户名

用户名、微信用户名




电子设备信息ALLCARRIER/WIFI 基本信




/ALLIMSI/ALLNUMBER/IDFA/操作系统




/系统版本/当前网络/MAC/IMEI/IMSI/序列

身份与金融状况信息、用



/制造商/型号/设备唯一标识(设备 ID/

于金融产品与服务的关键信息

C2

用户鉴别辅助信息,如动态口令、短信验证码、密码提示问题答案、动态声纹密码(若用户鉴别辅助信息与账号结合使用可直接完成用户鉴别,则属于 C3 类别信息)

内存容量/安装应用列表/图片数量/相册属性

/加速度/电池/设备仰角/屏幕亮度/摄像头像素/分辨率/语言/情景模式/OS/OSVer/是否模拟器/DNS/运动步数

网络信息:应用版本号/运营商编码应用流量

信息




短信验证码、短信列表




电子邮箱(邮箱地址)




最高学历、工作职业




紧急联系人信息、手机通讯录

工作地区、GPS 位置信息

电子通讯设备相册(Exif)信息

收货人姓名、收货人手机号、收货人详细地址、订单信息

渠道号、登录状态、客户端参数、用户ID







直接反映个人金融信息主体金融状况的信息,如个人财产信息(包括网络支付

账号余额、借贷信息。

平均月收入

第三方征信信息中的部分或全部信息

用于金融产品与服务的关键信息,如交

易信息(如交易指令、交易流水、证券委托、保险理赔)等。


用于履行了解你的客户(KYC)要求, 以及按行业主管部门存证、保全等需要, 在提供产品和服务过程中收集的个人金

融信息主体照片音视频等影像信息。

身份证照片、肖像照、银行卡影像借款用途、还款来源

其他能够识别出特定主体的信息,如家庭地址等。

GPS 定位短信

通讯录联系人姓名、电话号码等信息

机构内部信息

C1

账户开立时间、开户机构


基于账户信息产生的支付标记信息

充值记录、划款记录、提现记录,账户余额

C2C3 类别信息中未包含的其他个人金

融信息



注 4:个人金融信息主体因业务需要(如贷款)主动提供的有关家庭成员信息(如身份证号码、手机号码、财产信息)、用户手填联系人或通讯录信息,可依据上表示例进行对照分类分级。



附 录 H

(资料性附录)

车载场景下的告知同意


车载场景是指以车载终端作为载体,通过网络连接实现人车交互及功能服务的各种应用场景,包括 信息娱乐功能、交通信息管理功能、应急救援功能等。车载场景随着网络技术、大数据算法能力、AI 技术等的发展有所变化,可能会出现更多的融合模式。


H.1告知


H.1.1告知的内容


在车载场景下,除本标准第 8.1 中的相关信息外,还可以包含以下内容:

a)车载系统、应用服务的内容、使用说明、性能、标准及相关服务的提供者的详细信息;

b)车辆销售商、车载系统服务商、车载应用服务商在提供服务时对于个人信息的收集及共享情况;

c)车辆所有人、驾驶员及其他个人信息主体查询各个人信息控制者隐私政策的方式和途径;

d)车辆所有人、驾驶员及其他个人信息主体查询、管理个人信息的方式和途径;

e)车辆内通过自动化设备及车载系统采集驾驶员及乘车人个人信息的,可以通过功能介绍及说明书等向个人信息主体说明采取此类措施的正当性、合法性与必要性。


H.1.2告知的方式


车载场景下选择个人信息处理有关的规则等内容的告知方式时,除本标准 8.2 的相关内容外,宜充分考虑车辆驾驶场景的特殊性,依据道路交通安全法律法规、国家及行业标准的相关规定,选择适当的告知方式。在进行告知及与个人信息主体交互时,不宜在行车场景下设置任何可能干扰驾驶的产品方案。

车载场景下选择的适当的告知方式,可以包括以下一种或多种:

a)对于驾驶人及乘车人来说,可感知及可预期的功能所对应的个人信息数据收集、存储等行为,可以采取“使用即同意”或“默认开启”等的方式,在隐私政策等个人信息使用规则体现 即视为告知;

b)在车辆使用说明书或销售协议中对于车载系统及应用服务进行介绍,并将服务相关的个人信息控制者、个人信息处理活动及个人信息控制者就个人信息处理活动制定的基本规则或查看规则的具体路径和方式进行告知;

c)在车载系统控制层面为各个人信息控制者提供向个人信息主体告知个人信息处理活动制定的基本规则的交互界面或可行设计,个人信息控制者通过前述交互页面或可行设计向用户展示隐私政策等个人信息处理活动的规则;

d)存在车机互联或账号设定等交互的产品,可以选择将告知内容通过建立连接的移动设备进行展示;

e)提供服务时如收集人脸、指纹等个人敏感信息时,宜在交互过程中向个人信息主体明示收集信息的目的,可以采用语音提示方式引起个人信息主体的注意。

注 1:如信息仅用于或存储在车载终端没有回传服务器,不属于个人信息的收集行为。


H.1.3告知的展示


车载场景下选择告知展示的形式时,宜结合车辆具体性能、车载系统的安装位置等合理设置。基于车内环境、驾驶场景等因素,可以采取如下方式的一种或多种:

a)提供网页、二维码等渠道方便个人信息主体在非车内及汽车启动场景下阅读;

b)提供语音、视频等方式,在保证行车安全的场景下,根据个人信息主体的选择对告知内容进行展示;

c)对于个人信息主体产生重要的或易于引起异议或争端的内容,宜在销售过程中进行功能介绍及信息收集相关说明,以便车辆购买人理解并作出判断。


H.2同意


H.2.1同意模式的选择


车载场景下选择合适的同意模式时,除本标准 9 的相关规定外,宜对车辆购买者、车辆驾驶员、乘车人的不同特点进行考虑,在可能的情况下,结合服务场景(出租/运营场景或私人使用)和个人信息处理活动的特性,采用不同的同意模式:

a)车载服务或服务中的个人信息处理活动可能对车辆购买者权益造成重大影响时,车辆生产商、销售商宜在销售前向车辆购买者充分、完整的介绍功能、服务及信息收集情况。同时, 可在销售协议设置相关条款,车辆购买者在采购协议签署中完成明示同意;

b)向驾驶员征求同意时不宜以可能干扰驾驶的方式进行,且不宜将驾驶行为和个人信息处理活动进行绑定;

c)在个人信息主体使用语音交互、人脸识别、地图导航等功能时,个人信息主体使用服务即可视为其同意个人信息控制者收集其个人信息的行为。同时,宜为个人信息主体提供撤回同意或删除已收集个人信息的路径和方式,依据法律法规和相关约定或超出技术能力和合理成本的情况除外;

d)对于个人信息的收集如无法隔离不同个人信息主体时,可以采用代为授权或默示同意方式。 同时,为个人信息主体提供撤回同意或删除已收集信息的路径和方式,依据法律法规和相关约定或超出技术能力和合理成本的情况除外。



附 录 I

(资料性附录)

网上购物场景下的告知同意


网上购物是指消费者通过购物网站获取商品信息,在发生购买意向后通过电子订购单发出购物请求,然后填写详细地址与联系方式,通过货到付款、第三方支付等形式支付当前消费额,之后厂商以 快递形式发货至消费者的交易过程。

网上购物是为用户提供网上购买商品或服务的服务类型,包括商品展示、搜索、下单、交付、 客服售后等功能。


I.1告知的内容


a)收集用户手机号码:至少应明确说明收集信息用途。建议通过输入框背景文字等方式提示用户, 引导其主动输入手机号码,避免直接从第三方处收集其手机号码。

b)收集用户与网络产品与服务之间通信内容:至少应明确说明收集信息用途。例如,在用户拨通客服电话时提示用户:“为了保证服务质量,您的本次通话可能会被录音。”

c)收集用户身份证件信息:由于其与用户人身与财产安全高度相关,应明确说明收集信息用途、安全保障措施和拒绝提供或拒绝同意将带来的影响。

d)收集个人地址或地理位置信息:应告知用户收货人地址的用途。个人地理位置应告知用户其收 集目的和使用场景。

e)收集支付账户信息:由于该类信息直接关系用户个人财产安全,应明确说明收集的用途,使用 的场景,安全保障措施等。收集银行卡号、第三方支付账号信息并出于方便用户使用而保存相 关信息前,应告知用户相关保存的支付信息的使用范围。

f)收集用户生物识别特征信息:由于其与用户人身与财产安全高度相关,应明确说明收集信息用途、安全保障措施和拒绝提供或拒绝同意将带来的影响。同时,应当增加“关闭”此类应用的 功能。


I.2告知同意的方式


I.2.1隐私权政策的展示


隐私权政策应当有明确的生效日期和版本信息,内容公开发布且易于访问,例如,web 网站主页、移动应用程序安装页等显著位置设置链接。

a)固定位置展示

1)web 网站主页页尾处应设置专门的隐私权政策链接,确保用户可以随时访问隐私权政策内容。网页中应当采用侧边栏、目录树等便于用户阅读的形式。

2)应用程序应在其 APP 中设置专门的隐私权政策链接,确保用户可以随时访问隐私权政策内容。推荐在 APP 中设置专门的“隐私”板块集中展示政策与相关控制措施。

b)历史版本展示

1)网络产品与服务的隐私权政策在变更时,应确保变更前的上一版本也可在 web 网站或应用程序中的适当位置可公开访问。例如,淘宝网规则-协议专区中可查询淘宝网历史版本的隐私权政策。


I.2.2告知同意的时机

a)注册账号时同意隐私权政策:在用户注册账号时,以弹窗等形式向用户展示隐私条款核心内容, 核心内容简洁、精炼、易阅读;核心内容下方提供完整的隐私条款链接,并通过用户主动作出勾选“同意”的形式征得用户同意。

1)用户在 web 网站注册账号,网页应弹出浮框提示用户阅读包括隐私权政策在内的协议, 并引导用户点击同意。

2)用户在应用程序注册账号时,若属于综合类、复杂场景的应用程序,应用程序应弹出浮框提示用户阅读包括隐私权政策在内的协议,并引导用户点击同意。

3)用户在应用程序注册账号时,若属于垂直类、场景相对单一的应用程序,可以在注册页明确提示用户阅读包括隐私权政策在内的协议,并引导用户同意协议并注册。

b)隐私权政策重大变更的同意

1)隐私权政策发生排除用户权利、加重用户义务的重大变更,,在网页端用户登录时应提示 协议更新。

2)隐私权政策发生排除用户权利、加重用户义务的重大变更,在用户首次进入应用程序时应提示用户并取得同意。

c)使用其他账号登录时同意隐私权政策

1)当在本网络产品与服务的账号之外,提供使用其他网络产品与服务账号登录的功能时, 应引导提示用户阅读并同意本网络产品与服务的隐私权政策。

2)当使用其他网络产品与服务的账号登录功能时,应在为用户提供信息发布功能前,要求用户绑定手机号码,确保符合法律关于实名制的要求。

d)用户首次进入应用程序时同意隐私权政策。用户首次进入应用程序时(APP新安装或者首次注册),可在用户打开APP时提示用户阅读隐私权政策,并简要说明APP收集使用信息的基本情况。

e)增加支付方式时,如添加个人银行卡用于网上购物支付时,应在网页端或App客户端提示用户 阅读相关支付协议。





附 录 J

(资料性附录)

快递物流场景下的告知同意


快递物流场景下的告知同意,主要涉及的业务流程包含注册、下单、收件、支付、中转、清关、转 运、查单、派件;实现全流程业务需采集寄件人、收件人、快递业务员的个人信息。


J.1告知的内容


收集使用快递物流个人信息的告知,除本标准 8.1 中的相关信息外,还可以包含下列信息:

a)快递物流寄件场景中,用户寄件下单个人信息的收集告知、采集实名制信息的告知、寄递用户 提供个人信息不详或错误可能导致的后果告知、营业场所收寄视频监控的告知、遵守禁止寄递 和限制寄递物品的有关规定告知,相关物品保价规则和物品保险服务项目告知;

b)快递物流清关场景中,进出口一国关境采集清关信息的告知;

c)快递物流转运场景中,客户委托转运或对到达不了的地方交由其他快递组织承运的告知;


J.2告知同意的方式


a)快递物流寄件场景采集个人信息的告知方式

1)当寄递用户进行自主下单时,快递服务组织应通过寄递单式、网站、寄递合同、寄递服务 协议、隐私政策、弹窗、页面明显提示等方式获得用户明示同意后,方可进行个人信息的 收集,如必要信息:收寄件人姓名、收寄件人手机号、收寄件人地址、收寄件人邮箱、身 份证件(身份证、护照)、物品名称、物品价值、寄递详情单号、付款方式等;

2)寄递用户自行到营业场所寄送物品,快递服务组织应在场所进行公告视频监控的告知;

3)寄递用户提供个人信息不详或错误可能导致的后果告知、相关物品保价规则和物品保险服 务项目可通过寄递服务协议及快递业务员口头告知;

4)采集实名制信息、查验禁止寄递和限制寄递的物品前,快递服务组织应通过短信、寄递服 务协议等方式通知用户;

注 1:寄件短信告知内容可参照:您的预约已成功,请您保持电话畅通,我们将尽快安排收派员上门取件, 为了确保快件的安全运送,请配合收派员开箱检查,并进行身份证实名制采集,感谢您的支持与信任。

b)快递物流清关收集使用个人信息的告知

当寄递用户需收取国际或港澳台快递时,快递服务组织应通过弹窗、页面明显提示等方式告知用户, 并提供用户上传通关信息的功能;

注 2:清关短信告知内容可参照:尊敬的客户,您好!您有一票通过 XXX 寄递的快件,为了确保您的货物顺利清关至中国内地,根据《中华人民共和国海关对进出境快件监管办法》,运单号 XXX 需要提供身份证正反面图片, 若已上传可忽略此短信,上传方式如下:1.点击身份证上传专属通道 XXX 进行上传;2.微信上传:查找并关注 XXX 公众号,关注成功后选择【我的】→【通关服务】上传。如有疑问可拨打客服热线 XXX,谢谢!

c)快递物流转运,对外提供个人信息的告知

快递服务组织对于偏远地址等快件到达不了的地方,如有通过委托方式第三方开展寄递服务的,应 通过隐私政策、寄递服务协议、电话明确告知寄递用户第三方处理、使用个人信息的特定的用途,取得 寄递用户的明示同意,并应充分审查、评估第三方保护寄递用户个人信息的能力,签订寄递用户信息安 全保障协议。




附 录 K

(资料性附录)

个人身份认证场景下的告知同意


个人身份认证也称为“个人身份验证”或“个人身份鉴别”,是指通过实名、实人、实证的方式, 在系统中确认个体身份的过程,从而确定该个体是否具有对某种资源的访问能力、使用某种功能的权利、 享有某项服务。个人身份认证按其技术实现方式分为离线验证和在线验证两种。


K.1离线身份验证


离线身份验证,信息控制者往往通过人工或其实体产品,基于身份证件的验证和采集人像方式,配 合活体检测,再通过离线人证比对,完成个人信息主体的身份核验。离线身份验证,广泛应用于政务办 理、酒店前台、人脸门禁/闸机、企业考勤机、自助柜机、通关核验等。若这些身份验证应用中,包含在线验证部分,应属于在线身份验证,如通过公安部“互联网+可信身份认证平台”在线验证实体身份证的真实性、有效性。


K.1.1告知的内容


a)建议信息控制者在验证身份的产品, 如 PC 端、移动端、自助机、通关设备等,与个人信息主体有近距离交互的设备,告知验证个人身份认证的目的、相关条例、收集范围等包括本指南

8.1 建议的告知内容。

b)在与个人信息主体交互的场所,如:问讯处、柜台、管理办公室,将完整隐私政策或条款文本, 供个人信息主体需要时查阅,内容包括本指南 8.1 建议的告知内容。

c)在收集人脸等个人敏感信息的,应当符合法律法规的相关规定,并明确标识信息采集设备的性 质和目的。并获得个人信息主体的授权同意,依据法律法规和相关约定的情况除外。

注:收集人脸信息仅用于与设备本地已存储的人脸信息进行比对或进行本地化处理而没有回传服务器的,不属于人脸信息的收集行为。

d)验证未成年的身份认证时,应当明确标识信息采集设备的性质和目的并征得信息个人主体其合

法监护人的授权同意。


K.1.2告知的内容方式


a)信息控制者在与个人信息主体有近距离交互的设备,应以显著方式向个人信息主体进行展示告 知,范本如下:

1)公共交通场景:为保障乘客的出行安全,依据《规定或条例名称》,请您配合工作人员进行身份验证。

2)安全场所场景:<场所名称,如机房>是安全重地闲人免进,进出<场所名称>请先进行身份 验证。

b)当有人脸识别时,应告知使用目的和范围,例如:人脸识别仅用于识别您的身份,我们承诺会 保护您的人脸等信息安全

c)当个人信息主体拒绝个人身份认证时,建议相关场所提供不收集个人信息的选择方案,例如, 不能进入场所、不能进入通道等。

d)公共场所收集未成年人个人信息的告知参照附录 A。



K.2在线身份验证


在线身份认证,信息控制者通过其产品(APP、PC)采集个人主体身份信息、标识,并将个人身份信息、个人信息主体所控制的口令、密码设备,等其他验证因子转交给身份认证机构,由身份认证机 构对个人信息主体的身份进行鉴别。因整个身份验证过程中,往往存在着个人敏感信息从信息控制者到 身份认证机构的信息传递,应按本指南 8、9 章节的要求,对个人信息主体进行告知,并在得到个人信息主体同意后,信息控制者才能将个人敏感信息交给相关身份认证机构进行验证。身份验证机构,在收 到信息控制者发来的身份验证请求时,如信息中包括个人敏感信息的,应检查信息控制者是否经过了个 人信息主体的授权,通过对授权目的、时间、使用范围等合规性评判,鉴别个人身份,并向信息控制者 提交身份认证结果信息。


K.2.1告知的内容


a)信息控制者在其 APP 和 PC 等与个人信息主体交互的设备上,在对个人身份认证告知同意设计时,应结合个人身份认证的具体目的、具体信息化实现方式、个人身份信息的使用范围、信息控制者具体处理方式等,设计相关的告知内容,告知内容应公开透明、真实准确、具体明确、 清晰易懂,内容宜包括本指南 8.1 建议的告知内容。

b)信息控制者向身份认证机构传递个人敏感信息,如姓名、身份证号码等,应明确向个人信息主 体告知,内容包括:认证目的及用途、认证机构的名称、范围和可能产生的后果等,并取得信 息主体的明示同意。

c)在收集人脸等个人敏感信息的,应当符合法律法规的相关规定,并明确标识人像识别的性质和目的,是否传输明文信息,或经去标识化、匿名化、加密等处理后仅传输人脸特征,是否存储人脸信息及存储时间,人脸识别完成后是否删除原始图像信息,是否支持查询收集使用情况、 撤回对人脸识别的同意、持续留存了人脸信息等,并获得个人信息主体的授权同意,依据法律法规和相关约定的情况除外。

d)身份认证机构与个人信息主体存在主动告知及具备同意能力的,身份认证机构在接受到信息控 制者发来的身份认证请求时,身份认证机构也应向个人信息主体明示身份认证请求,并取得个 人信息主体的明示同意后,可进行相关的身份认证服务。

e)当需要验证未成年人身份的,应将认证目的及用途、认证机构的名称、范围和可能产生的后果 等,告知个人信息主体的合法监护人,并征得其合法监护人的授权同意。


K.2.2告知的内容方式


a)信息控制者应在其 APP、PC 等产品中,以显著方式向个人信息主体进行展示告知。例如:

1)实名认证场景:为落实《……》的要求,<平台名>需对您的身份信息进行收集(姓名、身份证号、手机号),并通过<身份验证机构名称>核实您的身份信息,是否同意?

2)业务办理场景:您正在办理<业务名>,<平台名>将对您的身份信息进行收集(姓名、身份证号、手机号),并通过<服务机构名称>核实您的身份信息。是否同意?

b)有人脸识别时,应告知使用目的和范围,例如:人脸识别仅用于识别您的身份,我们承诺会保 护您的人脸等信息安全。

c)当个人信息主体拒绝个人身份认证时,建议信息控制者不收集个人信息的选择方案,例如:拒 绝提供具备实人认证信任等级的人脸信息,只能使用基本的间接实名认证登录服务或无权访问 该信任等级下的操作等。

d)身份认证机构与个人信息主体存在主动告知及具备同意能力的,身份认证机构在接受到个人信息控制者发来的身份认证请求时,身份认证机构也应明示身份认证请求。例如: <应用名> 正在核验您的身份,您是否同意?


K.3告知同意的信息证据留存


a)信息控制者应将告知同意进行证据留存,请参阅本指南的 9.4 章节。留存包括:业务 ID、个人主体 ID、同意的方式、同意的时间、同意对应的告知内容、同意时间等。

b)身份认证机构在认证过程中,如有向个人信息主体明示身份认证请求的,也应参阅本指南的

9.4 章节,将告知同意进行证据留存,留存证据信息,包括:业务 ID、个人主体 ID、同意的方式、同意的时间、同意对应的告知内容、同意时间等。

c)信息控制者与身份认证机构之间,可将个人信息主体告知同意进行证据留存共享,以便更好的 让身份认证机构判断身份认证请求的合规性。双方也可约定委托第三方或公证留存相关告知同 意证据,如:经公证机关公证;使用符合电子签名法规定的可靠的电子签名;由记录和保存电 子数据的中立第三方平台提供或者确认。

d)数据控制者不应以留存同意证据为由,增加个人识别信息的收集。告知同意的证据在与身份认 证机构共享告知同意证据时,应以最小必要原则。对标识个人信息主体的信息应采用加密、去 标识化等安全措施。




附 录 L

(资料性附录)

互联网房产经纪服务场景下的告知同意


互联网房产经纪服务平台,是指帮助房产经纪机构和房产从业人员员通过网络向用户提供房产经纪 服务,帮助用户获得线上找房、看房、带看、认证、签约、交易、支付等信息技术服务和房产经纪服务 的平台(以下简称“平台”)。

基于房产交易金额大、周期长、风控需求高的特性,房产服务平台必须依赖于收集和使用用户的个人身份信息、购房资格信息、房屋信息、房屋产权信息、财产状况信息、交易信息和支付信息等,对房源可售性、真实性、交易双方身份的真实性、交易资格的合法性、交易行为的有效性等进行核验和审查, 以确保整个线上交易流程顺利、安全地完成。同时房产服务平台也必须依赖于收集和使用房产从业人员的个人身份信息和作业行为信息,对从业人员的服务能力和服务行为进行评价,促进服务质量及用户和服务人员匹配效率的提升。


L.1告知同意的内容


房产经纪服务平台个人信息的告知,除本标准 8.1 中的相关信息外,还可以包含下列信息:

a)房产经纪服务协作网络如何在协作机构之间共享房源信息和求租求购或其他房产需求信息,以 促成机构间协同;

b)是否允许有房屋租购需求的用户关闭或限制服务人员通过线上拨号的方式提供咨询服务。


L.2告知同意的方式


宜结合个人信息主体的角色、与用户的交互界面和场景、个人信息的收集方式、处理的目的等因 素,采用不同的告知同意模式:

a)针对平台一般用户

在用户首次安装/注册互联网房产经纪服务平台的应用程序时,应设置“隐私政策”的交互式界面, 由个人信息主体做出主动勾选、主动点击“同意”“下一步”“继续”、滑动滑块、主动发送等动作表示意愿。

b)针对房源业主

1)当业主(含业主的合法授权人,下同)自行通过平台填写提交房产信息和联系电话,拟发 布房源信息时,平台宜再次通过电话方式对房产信息发布的影响对业主进行告知,征得业 主口头同意后再将业主信息推送给拟为其服务的经纪人,并在达成委托协议后,才能对外 展示房源信息;

2)当业主委托平台的房产经纪机构代为发布房源和租售房产时,房产经纪机构和经纪人应在

《委托协议》签署环节对收集业主的身份信息、房屋基本信息、房屋权属信息以及联系方 式信息通过口头方式进行告知,业主在纸质或线上电子协议上签字或电子签名即表示同意;

3)当业主通过平台的房产经纪机构达成房屋租售协议和居间协议时,房产经纪机构和经纪人 宜在协议签署环节对收集房源业主的产权证明文件、婚姻证明文件、配偶及共有权人身份 证明文件等达成交易的必要信息进行口头告知,业主在纸质或线上电子协议上签字或电子 签名即表示同意。

c)针对意向租售客户

1)针对在平台直接发起预约请求的客户,应设置交互界面,告知用户在线发起租购咨询服务 或预约看房请求时其联系方式将被推送给经纪人用于向用户推送满足需求的房源信息或 联系带看行程;

2)针对通过经纪人发起预约请求的客户,应在经纪人向平台录入客户手机号时,通过向手机 号发送短信的方式对“隐私政策”的内容进行告知;

3)当租售客户通过平台的房产经纪机构达成房屋租售协议和居间协议时, 房产经纪机构和经纪人宜在协议签署环节对收集租售客户的身份信息、家庭信息、收入证明、银行流水信 息及联系方式等达成交易的必要信息等进行口头告知,业主在纸质或线上电子协议上签字 或电子签名即表示同意。

d)针对房产从业人员

1)互联网房产服务平台应通过与服务机构的平台协议和平台规则等,明确服务机构应向其从 业人员告知互联网房产服务平台的辅助作业应用程序如何收集和使用其身份信息和作业 信息等的隐私政策;

2)在房产经纪人首次安装/注册互联网房产经纪服务平台提供的辅助作业的应用程序时,应设置“隐私政策”的交互式界面对房产经纪人进行告知。


L.3免于同意的情形


以下情形属于互联网房产经纪服务平台“收集使用个人信息的告知同意例外”中所列的特殊情形, 无需征得个人信息主体的同意:

a)收集环节免于授权同意的情形

1)房产从业人员若拒绝平台收集其个人身份信息和作业行为信息,拒绝接受平台对服务质量 的监督和把控,互联网房产经纪服务平台有权拒绝为其提供服务;

2)房产经纪机构依法律要求必须收集的个人信息:

i.基于《房地产经纪管理办法》的规定,房地产经纪机构对外发布房源前应查看委托人的房屋及房屋权属证书,委托人的身份证明等有关资料,并应当编制房屋状况说明书, 若委托人拒绝提供信息,房地产经纪机构有权拒绝接受委托。

ii.房地产经纪机构属于反洗钱义务机构,有义务交叉验证客户姓名、性别、证件号码等 身份信息后再向客户提供经纪服务,若客户不同意提供信息,房地产经纪机构有权拒 绝提供经纪服务。

b)共享环节免于授权同意的情形

为完成房产交易的款项支付、房源价值估值、税金缴纳、房屋主管机构的网签,平台接受房地产经 纪机构的委托后,需按照相关机构的要求与资金支付公司、第三方税务服务系统、评估公司、房屋交易 主管机关系统进行信息的共享,若客户拒绝共享相关信息,平台有权拒绝提供服务。



参考文献


[1]中华人民共和国网络安全法(2016 年 11 月 7 日第十二届全国人民代表大会常务委员会第二十四次会议通过)

[2]全国人大常委会关于维护互联网安全的决定(2000 年 12 月 28 日第九届全国人民代表大会常务委员会第十九次会议通过)

[3]全国人大常委会关于加强网络信息保护的决定(2012 年 12 月 28 日第十一届全国人民代表大会常务委员会第三十次会议通过)

[4]中华人民共和国电子商务法(2018 年 8 月 31 日第十三届全国人民代表大会常务委员会第五次会议通过)

[5]电信和互联网个人信息主体个人信息保护规定(2013 年 7 月 16 日中华人民共和国工业和信息化部令第 24 号公布)

[6]ISO/IEC 29100:2011Information technology—Security techniques—Privacy framework

[7]ISO/IEC DIS 29184Information technology—Online privacy notices and consent

[8]APEC Privacy Framework,APEC,2005

[9]Consumer Privacy Bill of Rights Act of 2015 (Administration Discussion Draft), White House,2015

[10]CWA 16113:2012Personal data protection good practices

[11]EU General Data Protection Regulation,2015

[12]EU-U.S Privacy Shield,2016

[13]The OECD Privacy Framework,OECD,2013