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