【欧盟RoPA】DPCat：基于GDPR的可互操作和机器可读数据处理目录规范 ，第二部分

ROPA的信息和数据治理

前一节中描述的CSM-ROPA能够以机器可读和可互操作的方式表示ROPA，并涵盖GDPR和DPA ROPA模板中的信息要求。然而，ROPA在实践中并不是一份单独的文件，而是一组相关的不断发展的信息，必须定期收集和维护。因此，维护ROPA所需的信息可能有一个或多个内部来源，如部门、单位或指定人员，这些“组织单位”提供有关其各自流程和活动的数据。ROPA还可能有一个或多个外部来源，如加工商、承包商、供应商，这些“外部实体”提供建立商定活动记录和保证合规义务所需的信息。

ROPA为DPO提供了组织实践的重要概述[22]，是DPO合规义务的一部分（GDPR第39条）[40]。这需要内部利益相关者（如单位或部门）与外部利益相关者，如DPA、审计员和认证机构之间的沟通，以整理ROPA治理所需的信息。

我们提出了五个用例，探讨了关键利益相关者及其在ROPA相关数据治理中的“异构源”角色。这遵循了先前工作[6]中的方法，即识别与GDPR合规相关的利益相关者和信息流，并建立基于此开发机器可读性和语义互操作性机制的实用性。（注：在这方面，我们依靠P.Ryan作为30多个法律实体的活跃DPO的经验）

在我们的分析中，我们认为DPO是一个组织内的指定实体，负责根据GDPR的义务监督ROPA相关流程（第39条）。从这个角度来看，我们探讨了基于特定利益相关者的存在或参与及其对DPO收集和维护ROPA相关信息职责的影响的可能组合。我们还认为数据控制者是主要类型的组织，尽管需要数据处理者来维护ROPA并让DPO作为利益相关者参与。数据控制器的用例比数据处理器的用例更复杂，满足控制器的ROPA要求的解决方案可以简单地修改以供处理器使用。

本练习最后提出了以机器可读和可互操作的格式表达ROPA相关信息的论点。第6节介绍了DPCat作为我们的解决方案，以在利益相关者之间沟通或交换ROPA相关信息，并帮助实现合规流程的自动化。

用例U1：数据控制器

图[图：ropa-U1]所示的这个用例代表了一个维护ropa（GDPR第30条）的单一数据控制器，它识别并记录了在其职责范围内进行的相关处理活动。此外，作为最佳实践，控制员必须评估相关DPA提供的指南和模板，并相应地调整其文档流程，以满足任何其他建议或要求。其DPO使用由控制者编制的ROPA作为监督合规性的责任的一部分。DPA或审计员（例如认证机构）也可以访问ROPA，作为其与控制者或调查或审计过程通信的一部分。

Basic generation of legal requirement ROPA

这些利益相关者之间的信息流可能涉及：（i）符合GDPR第30条要求的ROPA；（ii）符合DPA指南和模板的ROPA；（iii）出处，例如ROPA发行人、时间戳、联系方式；以及（iv）ROPA的选择性部分，例如时间段、特定处理活动。

用例U2数据控制器与内部组织单位

第二个用例如图[fig:ropa-U2]所示，通过四个“组织单位”或部门（营销、人力资源、IT服务和网络服务）的内部信息流扩展了U1，其中用于生成ropa的相关数据必须整理到一个公共位置[4]。U2还涉及与每个单位就每个部门的记录维护进行潜在的跟进，并建立“联系点”和“负责实体”。外部信息流（即DPA和审计员）保持不变，因为内部单位不是独立的法律实体，需要接受直接调查。

Organisational units updating and maintaining ROPA

除了U1中的利益相关者之外，这些利益相关者之间的关键信息流可能涉及：（i）每个内部组织单位的完整或部分ROPA信息；（ii）来源，例如，作为发行人的部门、联系人或负责实体、时间戳、联系方式；（iii）将部门信息整理成外部利益相关者的共同ROPA；以及（iv）ROPA的选择性部分，例如特定部门。

用例U3：带数据处理器的数据控制器

第三个用例如图[fig:ropa-U3]所示，具有额外的信息流，其中控制器及其DPO从指定的处理器收集相关信息。在所有部门共用处理器或在组织层面进行管理的情况下，U3是U1的扩展。如果组织单位使用特定外部供应商（即数据处理器），U3则是U2的扩展。在这种情况下，我们考虑了数据治理通常由内部单位管理的实际情况，尽管GDPR将数据处理器与数据控制器直接关联。

除了U1和U2之外，这些利益相关者之间的关键信息流包括：（i）来自指定处理者的ROPA信息；（ii）来源，例如来源、时间戳、联系方式；三将来自不同来源的信息整理成共同的ROPA；和（iv）ROPA的选择性部分，例如特定处理器。

A data controller with organisational units and data processors

用例U4：联合控制器关系中的数据控制器

第四个用例如图[图：ropa-U4]所示，扩展了U3，数据控制器与两个或多个控制器建立联合控制器关系，根据GDPR第26条共享处理责任。类似于将处理器与U3中的组织单位关联的可能性，联合控制器也可以类似地与处理仅限于单元活动的情况下的单元相关联。在U4中，控制器及其DPO具有关于从其他（联合）控制器收集相关信息以及任何潜在后续行动的附加信息流。

除U3外，这些利益相关者的关键信息流还包括：（i）联合控制人提供的ROPA信息；（ii）出处，例如来源、时间戳、联系方式；（iii）将来自不同来源的信息整理成共同的ROPA；和（iv）ROPA的选择性部分，例如特定（外部）控制器。

Data controller in a joint controller relationship

用例U5:DPO监督多个数据控制器

用例U1–U4考虑了使用DPO管理其ROPA信息的数据控制器的视角。在U5中，如图[图：ropa-U5]所示，我们考虑DPO是提供“DPO即服务”的外部组织或个人的场景。我们称该实体为“外部DPO”，并认为其职责涉及监督多个组织。外部DPO必须解决几个组织的U1–U4问题，这将转化为额外的信息流。这不同于与其他外部实体（即DPA或审计员）相关的信息流，因为外部DPO需要包括内部组织单位和数据治理流程在内的信息，以便准确理解和执行潜在的后续任务。

除U1–U4外，这些利益相关者的关键信息流包括：（i）从多个组织收集ROPA信息；（ii）为特定控制器生成ROPA；（iii）来源，例如来源、时间戳、联系方式；（iv）分离反映组织单位（如部门）的人事保护法相关信息；（v） ROPA的选择性部分，例如特定控制器的特定部门。

A DPO overseeing multiple data controllers

需求分析

由于只要符合法律要求，GDPR并不规定或关注如何生成或维护ROPA，因此组织有权决定适合其合规方法和风格的实践。例如，一个组织可以选择维护由DPO集中监督的ROPA，从外部获取所有来源的信息，并将其整理成通用文件（例如电子表格），然后添加到信息管理系统中。或者，组织可以选择为其每个部门保存单独的ROPA文件。

在这两种情况下，当DPA或审计员提出要求时，组织必须根据特定标准（如反映特定处理活动或特定时间段）编制ROPA。组织必须首先从其ROPA文件中识别相关信息并提取所需信息。该任务可能涉及DPO或负责实体的手动工作，除非组织使用支持此类用例的技术解决方案，并基于自动化提供更简单的工作流。

识别这些不同的用例使我们能够收集和协调有关信息表达的要求，并将其解释为使用CSM-ROPA进行数据治理。我们指出，解决方案必须：

1. 说明信息来源，例如部门、处理者；
2. 从离散的、可能是部分的信息人工制品中整理ROPA，例如部门的目的、处理器的技术措施；
3. 记录出处，例如时间戳；
4. 记录组织细节，如联系点、负责实体；
5. 维护不同的记录，例如部门、处理者或时间段；

我们提出了使系统能够使用这些信息的附加要求：

1. “包装”：与内部或外部利益相关者共享ROPA记录，例如部门到DPO或处理者到控制者；
2. 查询：从ROPA中检索部分信息，例如特定时段或过程；
3. “导出”：根据要求生成ROPA文件，例如GDPR第30条；
4. “自定义”：根据要求的差异，例如特定DPA模板的附加信息，自定义信息存储、检索和导出；
5. “保证”：为记录提供数据完整性和其他质量保证；

我们提出了进一步的额外要求，以激励运营细节：

1. 机器可读性：用于使用自动化和工具进行信息管理；
2. 互操作性：利益相关者之间的一致性和解释；
3. “开放性”：实现跨技术或供应商的无锁定采用；
4. “可扩展性”：为用例或上下文需求（例如，附加术语、新信息需求）定制解决方案；
5. “可验证”：通过验证信息的正确性和完整性来支持信息管理，例如，所有必要的字段都声明为有效的信息类型，以及支持合规流程以确保有效性和问责制，例如，确保每个处理都有目的。

由此，我们得出结论，CSM-ROPA虽然足以代表生成ROPA所需的信息，但不足以满足相关利益相关者之间交换或使用信息的要求。在下一节中，我们将此作为开发“目录”的激励因素，该目录可以封装ROPA相关信息，并满足其维护和与利益相关者交换的要求。