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

讨论

对ROPA相关研究的影响

我们的文献综述（第2节）表明，尽管对GDPR合规性进行了充分研究，但缺乏专门针对ROPA的学术研究。Labadie和Legner[11]将“处理活动记录的维护”确定为组织GDPR数据管理（子）的核心能力。DPCat通过扩展Labadie和Legner的模型将其转化为IT系统能力。此外，DPCat还增加了聚合各种责任数据、与利益相关者交换机器可读ROPA信息、生成DPA特定合规记录以及ROPA数据质量保证机制的子功能（图[图：能力模型gdpr]）。

Labadie and Legner capability model for data management in GDPR [11] extended with “Maintain ROPA” system capabilities using DPCat—highlighted with bold text and red borders

此外，对DPA ROPA模板的分析（第3节）已经证明了DPA方法之间先前未记录的差异程度，这会影响DPO和GDPR意识系统设计者或集成商。CSM-ROPA的创建为表示ROPA相关信息提供了本体结构。通过利用DPV作为社区认可的规范，该规范借鉴了DPO、法律专家和技术专家的技能、要求和专业知识，它为建立语义协议提供了强有力的基础，以解决现有工作中发现的差距[11]、[24]、[25]。此外，CSM-ROPA通过提供目标本体支持基于语义的现有方法，例如Huth提出的企业架构模型[13]。

通过将ROPA流程转移到数据编目方法，DPCat规范有助于采用现代元数据驱动的数据治理[40]。这反过来又促使采用数据管理来支持组织内和组织间的异构信息源和合规性[11]。这也符合欧盟最近关于将数据治理置于个人和基于人工智能的数据处理中心的建议[46]。与迄今为止大多数组织表现出的ROPA治理和自动化水平较低相比，这些进步是显著的，并为数据保护的有效技术和工具迈出了一步。

对真实世界GDPR合规性的影响

本节讨论了DPCat对ROPA治理的影响：加强当前ROPA数据维护的主要手动操作的一致性，对隐私和数据保护软件的影响，以及对大型组织内数据交换的影响。

DPCat在EDPS ROPA中的应用突出了将机器可读数据与面向人的文档分离所需的繁琐工作，即使数据是半结构化的表格形式，但是当使用DPCat将它们转换为RDF时，容易将它们用作机器可读信息的差异和不一致性是显而易见的。此外，必须从数据集中的其他PDF文档中进行交叉引用或推断，从而导致验证困难和更多不一致的机会。通过为机器可读ROPA信息收集提供灵活的分层方法，DPCat支持分析和逐步集成或自动化来自轻量级元数据导向方法的过程，该方法强调DCAT-AP和GDPR第30条要求更详细的责任信息知识模型，该模型扩展到个人数据处理的完整DPV模型以及其他本体或数据集。无论选择何种级别的建模，DPCat都将在组织中ROPA数据维护的简便性和一致性方面提供显著优势，从而降低合规成本。

用于数据保护的商业软件产品[7]包括支持组织单位的工具，主要针对DPO或维护组织文件的合规单位。然而，它们是信息孤岛，因为它们缺乏与其他系统的互操作性。作为回应，软件公司可能会开发API或适配器，将这些API或适配器连接到其他系统，这将需要对所有利益相关者使用的每个系统进行更新和集成。当组织任命新的处理器、收购公司或添加新系统时，这就变得特别困难。相比之下，DPCat为ROPA信息提供了一个单一的集成点，可供任何数据保护、法规遵从性和运营业务系统使用。

DPCat还解决了现有文献（U1）中缺少的真实组织内部用例的信息需求。例如，一位合著者是一个由五个部门组成的组织的DPO，他们有自己的DPO（DPO），其中包括分布在英国、欧盟和美国的29个附属法律实体。在这样的组织中，存在大量的集团内部信息流。该组织利用共享服务，如IT支持、数据分析服务和人力资源。还有大量指定的处理者为附属公司提供服务。该组织拥有有限数量的联合控制人关系，组织内部处理更为常见。在此，DPO[14]面临的挑战是确保收集处理活动的复杂性，并在众多ROPA文件中准确反映。为此，该组织使用了几个独立的专有解决方案，这些解决方案仍然很大程度上依赖人工工作和文档。在这样的环境中，将DPCat方法应用于ROPA数据管理可以实现更大的自动化，并跨越所涉及的异构IT系统，以实现法规遵从性和业务运营。应对不断变化的内部数据处理环节的多样性是授权DPO监控个人数据处理、与利益相关者沟通并识别不合规行为的关键。这有助于更好地管理合同和法律规定的外部关系和合规活动。

DPCat部署面临的实际挑战

增强数据治理的要求

尽管许多组织都接受数字化带来的生产力和敏捷性，但它们仍在与数据治理的基本原则斗争[10]。必须明确定义数据的约定用途，并且组织必须确保数据的使用与监管环境积极相关。组织需要定义商定的数据质量行为和政策，谁将访问数据，如何解释数据，以及数据将保留多长时间。组织在个人数据方面面临的挑战是定位、分类和编目问责制数据。DPCat鼓励部署机器可读数据目录平台，如综合知识档案网络（CKAN）[47]，该平台提供支持所有这些活动的用户友好界面和工具。此外，积极维护的数据目录的存在促进了组织内更广泛的数据治理活动。

在检查ROPA数据治理部署的联邦或分布式方面时，处理器的作用非常重要。他们需要根据DPCat规范对ROPA进行更新。此活动可能存在阻力，或者处理器可能需要技术援助以满足DPCat要求。利益相关者广泛采用DPCat将带来巨大的好处，但即使一家公司选择使用它，也会带来好处，因为DPCat可以用作出口格式。DPCat作为一个单一的综合集成点提供了一些帮助；如果处理器能够遵守它，那么与专有解决方案不同，这种集成成本应该是一种可重复使用的努力，可以用于扮演数据控制器角色的许多客户。

约定的语义

需要一个约定的本体来描述数据处理活动是DPCat成功的关键。这种对隐私术语缺乏共同理解的情况限制了隐私技术行业的发展[24]。DPCat提供了一种供应商可以采用的解决方案，因为它基于两种现有标准，即DCAT和DPV。尽管如此，供应商通常受其客户或监管机构的驱动而采用开放标准。因此，DPA角色的重要性将在下一节讨论。除非DPA参与，否则将由DPO和其他隐私软件客户要求ROPA管理的互操作解决方案。

DPAs的作用

DPA可以在自动化监管中发挥重要作用，使合规更容易实现[48]。当我们比较RegTech的成功时，我们看到监管机构支持和促进数字合规，积极推动和支持数字监管合规标准，并作为监管自动化的推动者，积极创造数字合规环境[10]。采用DPCat进行数据控制器与DPA之间的通信将有利于DPA在审计ROPA时进行审计、违规调查或检查。为了实现DPCat的采用，DPA需要与处理个人数据的技术创新者和组织建立共生关系，开发开源合规工具、数字法规和沙盒[49]，以及商定的通用语义词汇，如DPCat[10]。积极主动的DPA肯定会加快DPCat的使用，而且肯定会有一些技术进步，例如在线DPIA模板[50]。然而，我们正处于GDPR法规自动合规的早期阶段。

局限性

虽然CSM-ROPA和DPCat推动的方法为数据治理中与维护和使用符合GDPR合规要求的ROPA相关的挑战提供了有希望的解决方案，但它也有一些需要解决的局限性，以确保其在实践中有效。在本节中，我们将讨论已确定的局限性，并提出解决这些局限性的未来努力。

范围的限制

DPCat规范反映了源自CSM-ROPA的信息需求，该信息需求是基于GDPR需求以及DPA指南和有关ROPA的模板构建的。虽然这使得DPCat足以执行与ROPA相关的任务，但它没有考虑ROPA与其他合规文件（如DPIA（数据保护影响评估）、TIA（传输影响评估））、数据泄露记录以及控制器-处理器或控制器-控制器协议）之间的信息相关性和重叠。

在每种情况下，与ROPA中存储的一些信息都有明显的重叠，并且有必要将这些信息与ROPA本身联系起来。例如，DPIA可能涉及分布在不同ROPARecord实例中的多个处理活动。虽然ROPA可以通过单个信息与DPIA文档链接，但将DPIA信息表达为与ROPA信息类似的信息是有利的，以实现更好的信息互操作性和治理，并鼓励创建可用于使用相同信息的所有基于合规性的活动的工具。这可以通过进一步开发基于DCAT的解决方案来实现，该解决方案用于满足上述要求的法律合规任务所需的所有信息。

词汇的限制

DPV构成了DPCat的一个重要方面，因为它提供了以机器可读和可互操作的方式表示GDPR相关术语的词汇表。因此，DPV的任何限制也将反映在DPCat的能力内。鉴于DPV是社区管理的资源（通过DPVCG），有一个论坛可以根据DPCat应用程序的需要提出添加和补充。然而，必须在DPCat和DPV版本之间建立更好的一致性，以提供DPCat使用和解释的可靠性，例如，通过将DPCat对DPV的使用固定到特定版本。

管辖权的限制

DPCat作为一种解决方案是以欧盟为中心的，因为它（仅）直接满足GDPR要求。然而，组织可能更需要以不同管辖区或管辖区不可知的方式记录其处理活动。为了解决这种情况，可以对DPCat进行广泛的修改，例如采用者自己的管辖区特定词汇表，这可能会导致实现之间的不兼容。一种解决方案是将DPCat开发成域和管辖权不可知的规范，然后提供GDPR特定的概念作为扩展。这反映了当前关于将DCAT扩展到DCAT-AP的工作，以及GDPR特定概念的规定，例如通过DPV的GDPR扩展（DPV-GDPR）[51]，这些概念与“主要”DPV分离。

“数据形状”的限制

如前面第6节所述，信息的查询和验证需要一致性或关于数据是如何结构化或“成形”的预先知识。如果没有这一点，生成的SPARQL查询和SHACL形状可能很难表达或变得复杂。为了确保DPCat实现的一致性，特别是对于信息交换，强制执行底层信息的一致性至关重要。尽管DCAT（和DCAT-AP）为目录和数据集作为资源的表达提供了这种一致性，但需要解决DPV特定信息表达中缺乏这种一致性的问题。为此，我们建议开发定义信息期望和要求的用例，例如“数据传输必须指定位置”，以创建相应的“SHACL形状”，协调不同实施者应如何使用DPCat指定信息。该活动可由DPVCG进行，以使所有DPV采用者受益，否则，可在DPCat内部进行，以确保其应用的一致性。