欧盟新近执法中所见的隐私设计

编者按：

关于数据的安全、个人信息保护、不正当竞争等方面的重大案例：

今天和大家分享的文章关注欧盟新近执法中所见的隐私设计。作者为朱悦。

欧盟《通用数据保护条例》（GDPR）第25条规定了基于设计的隐私（隐私设计）。概而言之，处理者需要在处理发生前和处理过程中以综合考虑处理性质、处理范围、处理场景、处理目的、对主体权利和自由造成的风险的方式、当前水平以及实施成本的方式，在技术和组织层面落实个人信息保护的各项原则。无论是违反GDPR各项原则和相应规则，还是在此之外未能满足与性质、范围、场景、目的、风险、水平或成本相适应的保护要求，都有可能违反隐私设计规则。在这个意义上，隐私设计既是整部GDPR的“缩影”，又是环绕GDPR的“外冕”。然而，换个角度来看，这也意味着实现隐私设计的充分合规更多地只是愿景——毕竟，充分实现相应合规不仅意味着始终妥当落实GDPR的各项原则和相应规则，还意味着在此之外对于各项处理始终有着综合的考量、并相应补足了保护的程度。这几乎是只存在于理想中的情况。即使只考虑相关指南所建议的合规措施，也是如此。于是，更加切实地理解隐私设计的方法，是从实际执法和调查出发总结得到两种案例：第一种是因为违反其他原则或规则导致违反隐私设计规则的案例，第二种是单独地违反了隐私设计规则的案例。由此可以提炼五方面的规律。

案例类别	提炼要点
因为违反其他规定而违反隐私设计	通常由于违反GDPR的其他九类规定而导致，每一类又对应于若干更加具体的典型事实： 1 在与主体的物理/数字交互过程中没有能够落实最小化原则 2 相关信息处理系统的设计或设置导致处理超出了同意所对应的、或为其他合法性基础所必需的范围 3 在缺乏合法性基础的前提下开展营销 4 未能及时删除或匿名化个人信息，特别是由于相应系统设计而导致的未能及时删除或匿名化 5 与相应系统设计有关的个人信息质量问题 6 主体权利行使遭到妨碍，特别是由于相应系统的设计使得其遭到妨碍 7 由于未能采取适当安全措施导致信息泄露事件 8 应当实施DPIA，但却没有实施 9 其他同时违反许多原则和规则的重大案件
单独地违反了隐私设计	对隐私设计合规性的体系化分析通常可以细分为十二个具体步骤，每一类又可以展开为更具体的要点： 1 识别处理及其相关信息，尤其是需要在具体或抽象的程度上抉择 2 识别处理的性质，与处理本身的识别有密切联系 3 识别处理的范围，包括定量和定性的层面 4 识别处理的场景，越是敏感则越需要具体 5 识别处理的目的，主要是体系适用要求的确切性 6 识别存在风险的主体权利和自由，相应风险类型需要求全，具体参照相关指南 7 识别风险的可能性，具体参照相关指南 8 识别风险的严重性，具体参照相关指南 9 分析技术和组织措施的当前水平，动态考虑市场可得的水平，符合或高于GDPR保护水平的框架、标准、认证等可以作为参照，具体参照相关指南 10 分析成本，包括时间和人力成本，但不能仅因成本而决定不采取特定的措施，具体参照相关指南 11 综合判断相应处理上的隐私设计合规性，对于特定风险可能要求足够实质有效的措施 12 分析违规情形下的处罚，参照相关指南
整体地观照所有的隐私设计规则执法	1 体系化的隐私设计规则既是GDPR其他原则和规则的“缩影”，又是迈向更高保护要求的“冕景”。体系化地解释和适用这一条款，很大程度上也是在体系化地解释和适用GDPR 2为了实现并阐明隐私设计的充分合规，相应合规工作需要与整体合规体系一齐以覆盖从处理识别到风险纾解的“端到端”方式同步开展、实施 3 隐私设计规则的实践执法主要集中于外界可以感知的情形。根据相关处理者的重要程度不同，“可以感知”的相应程度也存在差异 4 特别是对于涉及重大案件的处理者而言，“可以感知”需要以专业机构的监督能力作为边界，风险纾解的“实质有效”接近于严格责任，隐私设计规则的分步展开适用最为充分 5 隐私设计规则的实践执法也体现了各国数据当局执法方向和风格的差异，体现在爱尔兰、波兰、意大利、芬兰、希腊等多地数据当局的相应决定中

因为违反其他规定而违反隐私设计

理论而言，违反GDPR其他所有的原则或规则都有可能导致对隐私设计规则的违反。实践当中，如此违反隐私设计的近一百五十个案件集中于九类具体的情形。第一类是在与主体的物理/数字交互过程中没有能够落实最小化原则。第二类是相关信息处理系统的设计导致处理超出了同意所对应的、或为其他合法性基础所必需的范围。第三类是在缺乏合法性基础的前提下开展营销，这一类占据了案件总数的一小半。第四类是未能及时，特别是由于相应系统的设计而未能及时删除个人信息。第五类是与相应系统设计有关的个人信息质量问题。第六类是主体权利行使遭到妨碍，特别是由于相应系统的设计使得其遭到妨碍。第七类是由于未能采取适当的安全措施导致了信息泄露事件、进而导致违反，这一类占据了案件总数的一多半。第八类是应当实施信息保护影响评估（DPIA），但却没有实施。最后一类则是在同时违反许多原则和规则的重大案件当中，几乎总是同时存在着对于隐私设计规则的违反。

我们对于九类违反隐私设计的情形各自稍作展开。由于其间引述的许多案例都是相对熟悉的，所以均以高度简化的方式叙述。第一类案件不外乎以下三种情形的一种：要么是和主体间往来的单据出于各种方便的考量展示了主体的姓名、头衔、电话甚或相片等信息，但实则没有必要；要么是在故障报损等流程中额外收集个人信息，但实则没有必要；又或者是强制要求主体通过注册其他需要处理额外个人信息的账户——例如微软账户——才能交互。这些都有可能同时导致对于最小化原则、其他原则规则以及隐私设计规则的违反。第二类案件则几乎总是以下两种情形的一种：出于安防等目的设置连续摄录、范围过度开阔的监控，而没有设置为触发特定条件时单次拍摄、且仅覆盖必要范围；或者，通过建立共享系统、建立社交群组或群发电子邮件等方式共享信息时，没有预先开发或使用限制披露类型（例如名字不可见）或限制披露范围（例如密抄）的隐私设置，导致期待之外的信息共享或泄露。第三类案件对应的情形更加简单——在完全没有获取合法性基础，或者已经收到主体反对的前提下开展电话或短信邮件营销。于是不仅违反其他许多原则和规则，也很难称为符合隐私设计的规则。第四类案件对应于两种非常典型的情形。第一种是没有注意到系统自行生成的、包含个人信息的日志，或者是没有注意到数据库对个人信息的自动备份。第二种是数据库在设计阶段就没有考虑到删除的需求，导致删除非常不便。第五类案件同样对应于两种颇为典型的情形，一是收集或存储时没有设置合理的校验导致个人信息出错，二是更改数据库更新规则时没有充分测试导致个人信息出错。第六类案件依然是对应于两种非常典型的情形。其一是对于主体行使权利设置自行打印、填写、邮寄实体表格等造成不便的前置条件。其二则是由于系统设计的因素导致主体无法便捷地访问其个人信息，例如X光机或核磁共振机器的设计导致其处理的信息只能通过刻录光盘导出，而无法打印输出。第七类案件对应的具体情形最是“丰富多彩”，主要包括以下造成个人信息泄露的安全事件：个人信息丢失且无法恢复、遗失含有个人信息的硬件资产、访问权限控制失败导致非法访问、服务器或数据库暴露于公网（甚至可以通过常用搜索引擎在结果的第一页就搜索到）、没有针对常见安全风险进行充分的安全测试、使用真实个人信息开展测试、使用真实个人信息容灾备灾、未经加密传输个人信息、未经加密或假名化而存储个人信息、使用不安全的网络协议、在知晓安全事件后没有及时开展应对和纾解，等等。这些情形都有可能同时导致对于采取安全措施和隐私设计义务的违反。第八类案件顾名思义，是因为在涉及个人健康信息处理等需要实施DPIA的场景中没有实施DPIA而“买一送一”的处罚。最后，在 Meta/Facebook案、IAB案、Foodinho案、Deliveroo案、意大利国家电力案、Fastweb电信案、布达佩斯银行案等若干违法事实复杂、违反规则众多、处罚最为严重、公众最为关注的重大案件当中，相应处理者常常同时违反了与各类处理原则、合法性基础、透明性、主体权利行使、自动化决策、处理者义务、安全措施、DPIA或个人信息跨境传输保障充分性有关的众多GDPR的规定，其中通常也伴有对于隐私设计的违反。

单独地违反了隐私设计规则

因为违反其他规定而违反隐私设计的一百五十多个案件占据了绝大多数。尽管如此，由于这些占据绝大多数的案件的相关分析多是“羚羊挂角”般地简洁，剩下的单独地违反隐私设计规则的零星案件有着别样的重要意义。这些零星的案件又可以细分为两部分。一部分是其实违反了GDPR的其他规定，但由于相应的违法事实评价为国内法评价所吸收等实践原因，所以最终只在GDPR下调查和处罚了隐私设计。另一部分则是真正重要、也可以令人更加体系化地了解隐私设计的案件。其中不仅排比分析了处理性质、处理范围、处理场景、处理目的、对主体权利和自由造成的风险、当前水平、实施成本等各项因素，还对为何特定的技术和组织措施与相应因素（不）相适应展开说理。借助这些案件，不仅可以对隐私设计的合规形成更加深入的理解，还可以展望在GDPR下实现完美的、充分的合规究竟意外着什么——须谨记，理论上说这是每项处理都要满足的要求。

参照这部分案件，对于隐私设计的分析可以大致地分为十二个具体的步骤。一是识别处理及其各方面相关信息的基础步骤。由于处理是个“臭名昭著地难以划界”[1]的概念，这一基础步骤实际也有一定的“技艺”的成分。从合规的角度看，处理的识别整体而言是宜抽象不宜具体；然而对于可能引起重大案件的处理者所实施的、相对高风险的处理而言，具体而非抽象地识别相应处理，有可能更好地分隔、管控其合规风险。从第二步开始是基于隐私设计规则的合规性分析。作为分析开端的第二步是进一步识别处理的“固有”性质——“固有”和下文的“高风险”可谓神同形异。这一步与先前如何识别处理有着密切的联系。一般而言，处理的性质主要包括其是否涉及特殊类型个人信息、是否属于自动化决策、是否涉及不对等权力关系、是否超出主体的期待、以及是否涉及主体行使权利的障碍，等等。具体而言，是否涉及儿童、是否公开披露和其他类型的事实也有可能认定为处理的固有性质。一旦由此认定为处理的固有性质，在后续所有步骤中都可以作为、也确实时常作为进一步论证的前提。第三步是识别处理的范围，主要是处理所涉及的主体的内涵和外延，特别是其范围是否特定、范围内的绝对数量以及在地域上的分布，等等。进一步可以得到处理的范围是“宽”还是“窄”的定性判断。第四步则是识别处理的场景或者说环境。这一步与其他步骤颇多重叠，但细致程度更甚。具体来说，主要是针对处理者、处理的个人信息、相应信息的主体以及处理发生的环境等各项场景维度，根据分析的需要引入足够细致的事实。例如对于公开披露儿童移动电话号码信息的场景，在其所处理的个人信息这一维度上，便可引入相应号码通常不会公开共享、通常不会通过其他渠道披露、允许在任意地点实时地与儿童主体联系、可以进一步用作其他服务的识别符、以及监护人难以发现经过移动电话发生的联络等等“场景化”所需的事实。其他场景维度上亦可按需细化。之后的第五步是识别处理目的。这一步骤本身并无特别之处，主要还是对相应目的的描述需要达到GDPR其他原则和规则所要求的确切程度。第六、七、八步虽然相对复杂，但基本上可以对照有关DPIA的指南开展，故而不必在有关隐私设计的讨论中赘述，只需要额外指出三点。首先是处理者内部已经实施的DPIA或类似评估当为数据当局的主要依据——这也是其常常一同处罚未实施DPIA和未实现隐私设计的原因。如果相应处理者足够重要，“有幸”引起来自外部机构的研究、审计和监督，这些机构形成的研究也有可能成为数据当局的分析依据。第二点是风险类型应当求全。这意味着隐私设计的合规性分析中需要考虑的风险并不要求其实际发生或者其发生概率达到一定的阈值。凡是存在潜在可能的风险即需要列举。第三点是综合第六、七、八步和先前步骤的相关信息，特别是关于固有性质和范围宽窄的信息，同样可以形成关于风险整体严重是否为“高”的定性，此处尤其需要关注与固有性质有关的、且其潜在可能后果最为严重的风险。接下来的第九、十、十一步仍然主要与这些风险有关。虽然隐私设计要求处理者考虑的是当前水平的、市场可得的技术和组织措施，并不要求采取任何特定的措施、或者是成本不成比例的措施，也不是设定严格责任的条款，但先前识别的（高）风险有没有在第三步的范围内得到充分解决依旧很重要。对于涉及重大案件的处理者而言，此处甚至可能接近于严格责任。例如在联系人导入的“号码-账户”匹配功能导致恶意爬取者积累海量用户信息数据库的场景中，仅仅采取限制速率、用户分类、增加验证和红蓝对抗等通行的、只在一定概率上纾解风险的措施并不充分，从而依然可能导致对于隐私设计规则的违反。于是，一旦识别得到（高）风险，则其纾解措施需要更加实质有效。简单罗列其他合规工作未必能够“药到病除”。如果在第十一步得到违反规定的结论，最后一步便是分析相应的处罚，包括最高可达1000万欧元或年营业额2%的罚款。结合先前已经识别得到的、有关处理的众多事实和已经相当体系化的GDPR下的罚款计算指南“五步法”即可展开此处分析，故而也不再赘述。

结语：整体地观照所有的隐私设计规则执法

以上总结了在GDPR之下由于违反隐私设计规则受到处罚或调查的两种案件。一种是由于违反其他原则或规则导致的隐私设计违反案例，进而可以总结九大类、更多小类的典型违反情形；一种是单独地违反隐私设计的案例，进而可以总结适应相应条款的十二个步骤，以及每个步骤具体的展开方式和判断尺度。在此基础上，还可以进一步提炼五方面的规律。第一，隐私设计规则确实是GDPR的“缩影”和“外冕”。适用相应条款的十二个步骤——当然，实践中最好不要有最后一步，很大程度上也是GDPR所理想的合规体系建设和开展步骤。第二，既然如此，隐私设计合规最好是与隐私合规体系一齐以覆盖从识别处理到风险纾解的“端到端”方式同步开展、实施。否则，不可避免地需要在步骤中的一个或多个上打折扣、埋风险。与此同时，在需要论证或辩白合规性时，从隐私设计的角度出发梳理、组织相关材料是相对简明有效的途径。无论是开展、实施，还是论证、辩白，都要突出就相应处理而言，合规工作在时间上的前置性和持续性。第三，从实践中的处罚或调查出发，违反隐私设计的处罚集中于主体或外部监督机构可以感知的违规情形。或者不太严格地说，前端的隐私合规紧迫性要远大于后端。毕竟绝大部分的相关案件还是集中在“门口有探头，票据贴相片，营销不停歇，行权不方便”等典型情形，或者是公开的信息泄露事件，然后才会再“捎带”出后端的隐私设计问题。针对隐私设计规则的执法，或可因此与国内针对违法违规的专项工作彼此比较。第四，虽然理论上隐私设计规则确实不是严格责任条款，但对于可能身处重大案件的处理者而言，似乎实际效果上颇为接近。对于这些处理者来说，由于外界机构会以相当深入的方式对其开展感知和监督，无论是在前端还是后端都存在相当迫切的合规需要。对于这部分处理者的风险纾解要求同样相当严厉，相应场景中的“实质有效（纾解风险）”与“严格责任”几难区分。此外，也正是在针对这部分处理者的案件中，隐私设计的规则才得到了最为充分、细致的展开。第五，总体而言，隐私设计案件的调查方向和具体说理或许体现了各国数据当局执法方向和说理风格的显著差异。尤其是爱尔兰、波兰、意大利、芬兰、希腊、奥地利、法国、匈牙利、德国多地等数据当局，可谓各有千秋。从合规实践或理论借鉴的角度看，爱尔兰当局的相关决定通常更为重大、细致——其他成员国的争辩意见自然也是“居功甚伟”。当然，以上所有分析都是非常初步的。不仅出于行文聚焦考虑忽略了隐私设计的部分理论要素和少量正面案例，也没有来得及吸收若干正在形成的、晚近（重大）案件的进展。均待后续补正。

[1] 参见Kuner, Christopher, et al. "The EU General Data Protection Regulation: A Commentary/Update of Selected Articles." Update of Selected Articles (May 4, 2021).

部分参考文献

Agencija za zaštitu osobnih podataka: […].

Αρχή Προστασίας Δεδομένων Προσωπικού Χαρακτήρα: 13/2021.

Αρχή Προστασίας Δεδομένων Προσωπικού Χαρακτήρα: 20/2021.

Αρχή Προστασίας Δεδομένων Προσωπικού Χαρακτήρα: 4/2022.

Autorité de protection des données: 74/2020.

Autorité de protection des données: 82/2020.

Autorité de protection des données: 03/2021.

Autorité de protection des données: 24/2021.

Berliner Beauftragten für Datenschutz und Informationsfreiheit: 711.412.1.

Catalan Data Protection Authority: PS 28/2021.

Commission Nationale Informatique & Libertés: SAN-2021-021.

Commission Nationale Informatique & Libertés: SAN-2022-020.

Data Protection Commission: IN-19-7-2.

Data Protection Commission: IN-20-7-4.

Data Protection Commission: IN-21-4-2.

Data Protection Commission: […].

Datatilsynet: 18/04147-23/KBK.

Datatilsynet: 2021-441-10244.

Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit: […].

European Data Protection Board: Guidelines 4/2019 on Article 25 Data Protection by Design and by Default.

Garante per la protezione dei dati personali: 9256486.

Garante per la protezione dei dati personali: 9685922.

Garante per la protezione dei dati personali: 9735672.

Garante per la protezione dei dati personali: 9817058.

Kuner, Christopher, et al. "The EU General Data Protection Regulation: A Commentary/Update of Selected Articles." Update of Selected Articles (May 4, 2021).

Nemzeti Adatvédelmi és Információszabadság Hatóság: 2020/66/21.

Nemzeti Adatvédelmi és Információszabadság Hatóság: 85-3/2022.

Γραφείο Επιτρόπου Προστασίας Δεδομένων Προσωπικού Χαρακτήρα: 11.17.001.008.029.

Tietosuojavaltuutetun toimisto: 2984/182/2019.

Tietosuojavaltuutetun toimisto: 6132/151/2019.

Tietosuojavaltuutetun toimisto: 6609/163/2019.

Tietosuojavaltuutetun toimisto: 6097/161/2021.

Tietosuojavaltuutetun toimisto: 6813/171/2021.

Urząd Ochrony Danych Osobowych: DKN.5130.1354.2020.

Urząd Ochrony Danych Osobowych: DKN.5130.2815.2020.

Urząd Ochrony Danych Osobowych: DKN.5131.22.2021.

数据保护官（DPO）社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时，DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月，DPO社群举行了第一次线下沙龙。沙龙每月一期，集中讨论不同的议题。目前DPO社群已超过400人。关于DPO社群和沙龙更多的情况如下：

DPO线下沙龙的实录见：

域外数据安全和个人信息保护领域的权威文件，DPO社群的全文翻译：

关于数据与竞争政策的翻译和分析：

健康医疗大数据系列文章：

网联汽车数据和自动驾驶的系列文章：

网络空间的国际法适用问题系列文章：

关于保护网络和信息系统安全的相关文章包括：

《网络数据安全管理条例（征求意见稿）》系列文章：

《数据安全法》的相关文章包括：

赴美上市的网络、数据安全方面的两国监管乃至冲突方：

个性化广告或行为定向广告（behavioral targeting advertising）系列的文章：

人脸识别系列文章：

内容安全方面的文章如下：

关于中美与国家安全相关的审查机制的文章：

地缘政治与跨国科技公司运营之间的互动影响：

围绕着TIKTOK和WECHAT的总统令，本公号发表了以下文章：

关于个人数据和域外国家安全审查之间的关系，见：

关于健康医疗数据方面的文章有：

关于数据执法跨境调取的相关文章：

第29条工作组/EDPB关于GDPR的指导意见的翻译：

数字贸易专题系列：

关于《数据出境安全评估办法》的系列解读文章

美国方面的个人信息保护立法的文章：

关于个人信息安全影响评估的文章如下：

关于数据要素治理的相关文章包括：

关于印度的数据保护和数据治理政策和技术文件的文章有：

关于欧盟技术主权相关举措的翻译和分析：

关于我国《个人信息保护法》的文章：

围绕供应链安全，本公众号曾发表文章：

围绕着出口管制，本公众号曾发表文章：

传染病疫情防控与个人信息保护系列文章

关于人工智能安全和监管，本公号发布过以下文章：

关于业务场景中数据跨境流动的文章如下：