数据保护应当遵循“四个全覆盖”的要求:覆盖数据的全生命周期;覆盖业务经营、风险管理和内部控制流程中的全部数据;覆盖内部数据和外部数据;覆盖所有分支机构和附属机构。
具体来说,为确保数据相关运作合法合规,企业应将数据保护体系贯彻数据的全生命周期,配合建立网络安全相关法律法规要求的各项制度,符合法律法规对于个人信息保护的各项规定要求。参照相关国家标准的细化要求,进行个人信息全生命周期的合规安排。
回到本篇主题,那何为个人信息收集?
对于这个问题,《个人信息安全规范》第3.5条、《个人信息告知同意指南》第5.1条、《网络安全法》第41条均对个人信息收集做了说明,我们来看看《个人信息安全规范》第3.5条,其他的相关法规条款请读者自行查阅。
《个人信息安全规范》第3.5条规定:个人信息收集是指获得个人信息的控制权的行为,包括直接收集个人信息和间接收集个人信息两种方式。其中直接收集个人信息是指个人信息主体主动提供、通过与个人信息主体交互或记录个人信息主体行为等自动采集的行为;间接个人信息收集是指通过共享、转让、搜集公开信息等间接获取个人信息的行为。
接下来,我将从个人信息收集的合法性、必要性、被收集者同意、征得被收集者同意的例外、隐私政策优化、间接获取个人信息的要求等六方面来探讨个人信息收集的合规化。
《个人信息安全规范》第5.1条规定了收集个人信息的合法性要求,我们在实践中可参照它的要求来进行实施:
不能以欺诈、诱骗等不正当方式误导用户同意收集个人信息或打开可收集个人信息的权限,比如故意欺瞒、掩饰收集个人信息的真实目的。
在实际实施中,可以通过实际的技术测试来判断是否有误导行为。但对于宣称收集信息只用于A功能而实际上却用于B功能的行为,除了通过抓包测试外,也可以与开发面谈问询,例如B功能的实现肯定需要个人信息做为支撑,但它没有明面上收集,那这里的个人信息从何而来?
首先,《隐私政策》中不能存在“等、例如”字样,这是规定的。也就是说,我们需要全面的梳理业务功能,而不能因为懒惰,在隐私政策中使用“等、例如”字样,进而可避免宣称收集信息只用于A功能而实际上却用于B功能的行为。
在实际监管中,抓包测试就能发现一切端倪。监管机构也是用这种方式做测试,然后对不合规APP进行通报整改的,除了监管机构,合规比较严格的客户也会进行尽调审计。
根据《APP违法违规认定方法》第4条和《APP自评估指南》评估项7,我们可以实践满足个人信息收集的必要性要求,必要性的要求包括:
收集的个人信息类型或打开的可收集个人信息权限不得与现有业务功能的应用场景无关,不得过度收集或过度索权。\n\n实践中典型的问题一般包括:
(1)过度收集用户通讯录、短信、通话记录等,或收集身份证号、人脸、指纹等作为应用开启使用的前提条件。
(2)通过积分、奖励等方式诱导用户,收集身份证号、人脸、指纹等信息。
(3)APP在用户还未使用相关功能或服务时,提前申请开启通讯录、定位、短信、相机等权限。
需要注意的是,“现有业务功能”是指现有的,而非过去或准备开发的新业务功能。
产生这种现象的原因,一般是开发人员因为懒惰,采取了一刀切的方式解决合规要求,此时需要安全向产品、开发普及其中的合规要求,从而使产品走向合规。
在实践中,一个应用更新新的功能非常普遍,此时就要避免出现新功能的索权上继续使用一刀切的模式,使用户不同意新功能的索权导致整个应用都不能使用。而解决这个问题的方法和上个一样,需要安全向产品、开发普及其中的合规要求,从而使产品走向合规。
在实践中典型的问题是按照一定的频次收集位置信息、IMEI或频繁读取通讯录、短信、图片等。一般情况下,公司存在该方面业务需要的,都没有太大问题,因为如何才算得上频繁并没有考量标准。但需要我们重点关注的,就是业务功能根本不需要这些数据,却进行频繁收集的情况。
前面我们说了,收集的个人信息必须是要有对应的业务功能的,因此,在实践中,APP可以将改善服务质量、提升用户体验、定向推送信息、研发新产品等目的与其他业务功能相结合,从而确保使用个人信息的类型与具体业务功能相对应。
对于一揽子收集的问题有一个特殊情况,Android 6.0以前,APP在安装前需要先获取所有权限,得到用户同意后才能进行安装,Android 6.0及之后谷歌才开发了即时权限获取功能,即用到这个权限的时候再申请,不再安装前一揽子获取。而目前市面上APP基本都还支持Android 6.0之前的版本,这属于不可抗力因素。
但是对于Android 6.0及之后的系统,仍一揽子收集就是我们自己的责任了,在实践中我们通过简单的测试就能判断它是否合规。同时,在实际测试中,我们应当注意,用户不同意应仅影响与所拒绝提供个人信息相关的业务功能,不能影响其他业务功能的正常使用,不得以不同意一揽子授权为理由不提供任何单一服务。
你这种问题只需简单的测试就能发现,因此在APP上线前,可以先做好合规测试。
对于被收集者同意,根据《网络安全法》第41条的分析,具体的要求包括:
实践中常见的问题包括APP运行时,缺乏向用户明示且征求用户同意的环节,收集IMEI、设备MAC地址、通讯录等个人信息。或APP运行时,虽然有向用户并经用户同意的环节,但个人信息收集发生在用户同意前。
(1)在实际监管中,可以通过抓包测试,检测在征得用户同意前是否向服务端发送了个人信息,对于不合规的地方,可以要求开发进行修复改进。
(2)用户明确表示不同意后,不得收集个人信息或打开可收集个人信息的权限
实践中有很多用户明确表示不同意后,仍收集个人信息或打开可收集个人信息权限的情况,网络运营者应当尊重用户意愿,在用户明确拒绝收集个人信息或打开可收集个人信息权限的请求后,不得收集个人信息或打开可收集个人信息的权限。
此外,需要注意的是,用户明确拒绝收集个人信息或打开可收集个人信息权限的请求后,应仅影响与拒绝提供个人信息或打开可收集个人信息权限相关的业务功能,不得影响用户正常使用其他业务功能。
(3)实际收集的个人信息或打开的可收集个人信息的权限,应与声明并经用户同意的收集规则保持一致
隐私政策的作用不仅在于告知用户并获得用户的同意,还在于网络运营者自身收集个人信息的约束。用户在悉知并同意隐私政策后,对网络运营者在个人信息收集处理上会形成合理期待。
实践中可以先通过了解实际业务,优化隐私政策让隐私政策合规化,再通过技术测试来判断应用是否合规,对于与隐私政策不相符的地方,可连同产品、开发等人员进行合规化改进。
(4)不得以默认选择同意个人信息保护政策等非明示方式征求用户同意\n目前市面上常见的不合规现象包括:默认勾选同意、注册即表示同意等。而被监管机构通报的也大多属于这一类。
在实践中,合规的方式应当是用户自主做出肯定性动作,肯定性动作包括主动勾选、主动点击、主动填写或输入、主动开启、主动签名等方式。对于是否合规,通过简单的测试即可得出结论。
(5)不得未经用户同意更改其设置的可收集个人信息权限状态,如APP更新时自动将用户设置的权限恢复到默认状态
举例:你自己发布出去的个人信息
例:比如要你履行xx合同的义务时,收集个人信息的情况,无需征得你同意
举例:比如从合法的新闻报道、政府公开等渠道收集个人信息的
举例:比如发现、处置产品或服务的故障
举例:关于新闻单位的,不举例
(k)个人信息控制者为学术研究机构,出于公共利益开展统计或学术研究所必要,且其对外提供学术研究或描述的结果时,对结果中所包含的个人信息进行去标识化处理的。
举例:关于科研院所的,不举例
先科普个小知识,隐私政策的出现主要来源于当初欧盟的GDPR,在当时国内还没有相关法律,因此为了统一业务合规,大多数跨国公司在国内业务中也使用了隐私政策,而现在,《个人信息安全规范》中将其规定为个人信息保护政策。但由于隐私政策这个名称使用已久,我们今天仍称将其之为隐私政策。
企业设计隐私政策要符合自身的基本情况和所处行业的特征,不能生搬硬套。
首先,要明确告知用户,企业收集、利用及保护个人信息的方式;其次,要使用浅显易懂的表达方式,明确告知用户收集数据的类型、使用目的,并在获得用户明确同意的情况下进行相关的数据操作;再次,要为用户删除数据、注销账户提供渠道,明确对用户数据的共享、发布方式,确保不会侵犯个人隐私;最后,要明确告知用户发生争议时的询问和投诉渠道,以及争议解决机制等。
除此外,企业也要积极探索创新的隐私条款展现方式,例如,隐私条款使用弹窗告知、敏感信息采集进行即时提示等。
(1)向个人信息主体说明网络运营者收集处理个人信息的相关规则,保证个人信息知情权的有效实现,同时构成对网络运营者自身行为的约束;
(2)网络运营者获取个人信息主体授权的重要依据,在个人信息主体同意后,其可以作为网络运营者配合监督管理的重要机制,用以证明获得授权以减轻或豁免责任的重要凭证。\n依据国内法规,隐私政策的具体要求如下:
实践中,隐私政策应当以单独成文的形式发布,而不是作为用户协议、用户说明等文件中的一部分存在。
同时,隐私政策应易于访问,在进入APP主界面后,应通过4次以内的点击就能够访问到隐私政策,并且隐私政策的链接位置应当突出、无遮挡,不应该出现隐私政策链接无效、文本无法显示的的情形。
另外,隐私政策应易于阅读,不应该是清一色无差别文本,不应有文字过小过密、颜色过淡、模糊不清、冗长繁琐等问题,造成阅读起来一团浆糊。
(1)明示收集个人信息的业务功能和各项业务功能所收集的个人信息类型\n隐私政策中应当将收集个人信息的业务功能、各项业务功能所收集的个人信息类型逐项例举,不能因为懒惰梳理或为额外收集留有余地而使用“等、例如”字样。这个就不再多说了。
(2)显著标识个人敏感信息类型
(2)应说明个人信息存储和超期处理方式\n隐私政策中应说明个人信息的如下情况:
(1)存放地域,如果在境外,应说明境外的哪个国家或地区;
(2)存储期限,应说明明确的存储期限,或法律规定范围内的最短期限;
隐私政策中应对网络运营者在个人信息保护方面采取措施和具备能力进行说明,如身份鉴别、数据加密、访问控制、安全审计等。
(1)对外共享、转让、公开披露个人信息的目的;
(2)涉及的个人信息类型;
(3)接收方累心或身份;
(4)各自的安全和法律责任。
应当注意的是,对于第三方的说明,应避免直接使用“提供给第三方”等类似过于宽泛的表述。
隐私政策中应对以下用户操作方法提供明确说明:
(1)个人信息查询;
(2)个人信息更正;
(3)个人信息删除;
(4)用户账户注销;
(5)撤回已同意的授权。
需要注意的是,这些方法应该是方便用户操作且能切实保障用户该等权利的有效实现,避免出现一纸空文的情况。
隐私政策中至少提供以下一种投诉渠道:
(1)电子邮件;
(2)电话;
(3)传真;
(4)在线客服;
(5)在线表格。
一般情况下,传真和表格是不会用到的。
应明确标识隐私政策发布、生效或更新日期。按照一般实践,该标识一般在隐私政策的文首或文末。
一般在发生业务功能变更、个人信息出境变更、使用目的变更、联系方式变更等变更时,要进行隐私政策更新。在隐私政策更新后,可以通过弹窗方式提醒用户重新阅读,并通过用户手动点击确认、手动勾选等方式获得用户的再次授权。
不应在隐私政策中设置免责等不合理条款
隐私政策中不应存在免除自身责任、加重用户责任、排除用户主要权利条款,例如:隐私政策中列明 “您须对您本人在使用本APP所提供的服务时的一切行为、行动(无论是否故意)负全部责任”。
这里的免除自身责任,是指运营者免除依照法律规定应当负有的强制性法律义务;这里的加重用户责任,是指运营者要求用户在法律规定的义务范围之外承担责任或损失;排除用户主要权利,是指运营者排除用户依照法律规定或依照合同的性质应当享有的主要权利。
在间接获取个人信息时,应当做到有限尽调!因为你不知道合作方共享或授权过来的数据是从哪来的。
在实践中,有限尽调包括:
如果发现个人信息提供方存在不合规情况,应视违法违规程度要求其限期改正或终止相关合作!