用户条款，如何让用户“同意”才合规

APUS • 2018-06-22 19:47

作者：APUS 研究院

来源：APUS（ID：apusapps）

写在前面的话：在上一篇文章《出海企业GDPR合规的痛点》中，我们介绍了企业在 GDPR 合规工作中的痛点，以及我们希望采取系列文章的形式与各位共同研究解决问题的心愿。从本期开始，我们将介绍关于 GDPR 的研究和理解。文章选题并没有遵循 GDPR 的章节顺序或其他的编排逻辑，每期内容可能比较随机。为了方便读者阅读，我们不会仅仅将 GDPR 条文或者 WP29 各项指引的内容按照字面意思翻译出来，而是希望尽量以我们的理解将 GDPR 的内容进行“本土化”和“日常化”。比如我们会使用国内的法律概念“意思表示”，再比如我们使用“企业”指代数据控制者或数据处理者，用“用户”指代数据主体（请 To B 企业谅解）。在条款引用上，我们选用瑞栢律师事务所翻译的 GDPR 的中文条款，详见《欧盟〈一般数据保护条例〉GDPR（汉英对照）》，瑞栢律师事务所译，法律出版社，2018 年 5 月第 1 版。

一、本期着重介绍

1. GDPR 中“同意”的轮廓；

2. Pu---D---C---Pr 模型

二、阅读本文可能需要理解的概念定义

同意：数据主体通过声明或明确定的行为，依照其意愿自愿作出的、具体的、知情的及明确的，表明其同意对其相关的个人数据进行处理的确认意思表示。

数据主体：GDPR 所保护的，已识别到或可被识别的自然人。

WP29：Article 29 Data Protection Working Party，是独立保护隐私数据安全的工作小组，已发布多个针对 GDPR 具有很强参考价值的指引性文件。

取得 GDPR 认可的用户“同意”可不是一件简单事。而且这还仅仅是一般意义上的“同意”，不涉及儿童、政府机关或者雇佣这样的特殊场景。

三、WP29 对“同意”的要求

我们简单总结了 WP29 对“同意”的要求，感兴趣的朋友们可以了解一下。

1. 企业不能对“同意”设置不合理的条件。比如很多公司在提供互联网服务中，会要求用户同意其采集一些和服务没有关系的非必要数据，或把必要数据用于其他目的，如果用户不同意就拒绝提供服务。我们理解这就是不合理的条件。假设一款查询天气的 APP ——X Weather（仅假设举例，不指向任何特定产品），不但使用用户查询的地点播报天气，还要求用户必须同意把这样的地点信息卖给航空公司去推销机票，否则用户就不能使用软件，这种捆绑就属于不合理的条件。

2. 企业应该保证用户的选择自由。选择自由，是说用户既有权拒绝同意，也有权撤销过去已经作出的同意，而且在行使上述权利时不应受到额外的损害。假设 X Weather 可以根据用户提供的精确位置为用户推送附近发生的新闻，在闪屏图刚结束后，X Weather 就会弹出要求用户同意提供 GPS 信息的弹窗。假如用户想撤销对上述提供 GPS 信息的同意，则需要联系 X Weather 的客服；或者一旦用户拒绝或者撤销该同意，X Weather 就由全国各大城市天气信息服务，变为仅提供北京、上海和广州的天气查询。这种情况下，X Weather 就没有给用户提供选择自由。

3. 需要用户同意的选项应该明确，而且描述使用目要周延。WP29 引用了 granularity （粒度或者颗粒度）的概念，非常传神。我们假设 X Weather 要把用户查询的地点信息卖给航空公司，其“同意”文案如下：

…我们需要使用您查询的地点为您播报该地的天气情况，同时该信息会分享给我们的合作伙伴用作商业目的…

两个目的合并为一个选项，颗粒度不够，不满足 GDPR 的要求。

4. 同意内容的披露要求。WP29 要求在取得用户同意时，至少要披露数据控制者的身份、数据处理的目的、需要收集和处理的数据类型、同意的撤销权、是否涉及纯自动化决策以及向不被欧盟认可的其他国家进行跨境传输。

5. 同意方式应当合理。首先是语言，不可以使用晦涩难懂或者太过专业的表达，应当保证一般人可以看懂。其次，为了让用户更明确自己同意的内容，应当把同意的内容和其他内容进行明确的区分。

6. 同意的动作应当明确。数据主体的同意应当是一种明确的声明或肯定的行为，而非类似默认勾选的同意方式。

WP29 还有一些其他要求，比如了解用户群体，或者需要满足其他的披露标准，感兴趣的读者可以自行查阅。

别慌，虽说 GDPR 式“同意”的要求很严，但取得用户的 “同意”并不是我们处理用户数据的唯一依据。履行合同、满足法定义务、保护自然人重大利益、行使公务职权或者企业的合法利益都可能成为处理用户数据的合法依据。

GDPR 第六条规定，当且仅当以下所列各项中至少有一项获得满足的情形下，数据处理方为合法：

1. 数据主体同意为一个或多个特定目的而处理其个人数据；

2. 数据处理是为履行数据主体作为一方的合同所必需，或者数据处理是在订立一项合同前为依据数据主体的要求采取特定行为所必需；

3. 数据处理是为履行控制者所负担的法律义务所必需；

4. 数据处理是为保护数据主体或另一自然人的重大利益所必需；

5. 数据处理是为执行公共利益领域的任务所必需或是为行使控制者被赋予的公务职权所必需；

6. 数据处理是为实现控制者或者第三方所追求的合法利益所必需，但数据主体所享有的、需要保护其个人数据的利益、基本权利和自由优先于上述合法利益的除外，尤其在数据主体为儿童的情形下。

可能有人问，既然“同意”这么严格，那我们为什么还要以同意作为处理数据的合法依据？因为从可操作性和实践经验来看，“同意”仍然是最可行和安全的。

首先，第六条中其他选项均有局限，必然有数据是需要经过用户“同意”，才能收集和处理。比如以履行合同为目的采集数据，企业需要严格界定为履行合同而必要采集数据的外延，使用数据的目的也仅能限制在履行合同和提供服务上；以履行法定义务为目的采集数据，需要确定法定义务的标准、数据的范围和数据处理的合理性。

其次，有些数据或处理方式，必须以取得用户“同意”为必要前提，比如 GDPR 第九条规定的特殊数据的收集和处理。

第三，在一些合作中，合作方可能要求只有取得企业用户“同意”，才向企业提供某些服务，比如个性化广告。像 Admob 在其网站上的声明：

Under the Google EU User Consent Policy, you must make certain disclosures to your users in the European Economic Area (EEA) and obtain their consent to use cookies or other local storage, where legally required, and to use personal data (such as AdID) to serve ads. This policy reflects the requirements of the EU ePrivacy Directive and the General Data Protection Regulation (GDPR).[ https://developers.google.com/admob/android/eu-consent]

因此我们不可忽视“同意”的重要。

四、GDPR 合规工作需要更新和维护——Pu---D---C---Pr 模型

我们经常说，GDPR 合规工作需要更新和维护。对于用户的“同意”同样需要更新。除了 GDPR 要求的周期性更新外，当业务变动时，也可能需要用户重新同意。

如果你不了解什么情况下的业务变动需要更新用户同意，可以参考以下的模型：

Purpose---Data---Consent---Process

处理目的---用户数据---用户同意---处理方式

我们简称其为 Pu---D---C---Pr 模型，代表因一定目的需要的一定数据经用户同意后进行了一系列处理。

当 Pu 和 C 发生变动，也就是处理目的变化的或者用户撤销了之前的同意，我们都需要变更或者重新取得用户同意。

D，也就是需要的数据，如果减少，我们理解不需要用户重新同意，最合规的做法是通知用户；如果增加，则需要重新取得用户同意。

Pr，也就是处理方式上发生了变化，我们需要分情况讨论。假设用户之前同意的数据处理目的是 P1，企业变动处理方式的目的是 P2，如果 P1 和 P2 是兼容的，不需要用户的重新同意，只需要通知用户产生的变化和 P1 P2 兼容的原因。如果 P1 和 P2 是不兼容的，那么需要取得用户重新的同意。怎么判断是否兼容，我们的理解是，标准是 P2 是否在一个普通用户同意 P1 时的合理预期中，需要考虑的因素包括 P1 和 P2 的关联、企业和用户的关系、处理方式变动会产生的影响，以及企业已有的数据保护机制，比如采用的加密技术或者数据库的构建方式。

图片1.png