Despite a ROPA being based only on requirements established by [[GDPR]] Art. 30, our prior work found variance amongst ROPAs templates provided by 6 DPAs in terms of what information needed to be documented. The additional fields were related to what the DPAs considered best practices to assist organisations in collecting and representing information from their various business processes. We harmonised the requirements from different templates to construct a ’common semantic model’ for ROPA (CSM-ROPA) to enable the representation of all DPA-specified ROPA information. We then represented these information requirements through concepts from the [[[DPV]]] to provide an interoperable machine-readable vocabulary that can act as a mediation mechanism between stakeholders and tools operating on ROPA and associated compliance processes. In this section, we present results from our extended work where we analysed and incorporated ROPA templates from all EU DPAs to create a single (and truly) ‘common semantic model‘ for ROPA and represented it using DPV to provide a consistent and interoperable specification for representing ROPA and its relevant information.
The DPV provides a semantic vocabulary consisting of hierarchical taxonomies of concepts relevant to GDPR, such as personal data, purposes, processing operations, technical and organisational measures, legal bases, and entities. We chose DPV as it provides the most comprehensive vocabulary for our purposes, is open and accessible, has ongoing development and mechanisms to submit contributions, and is familiar to the authors. The process of representing identified concepts using DPV used the methodology: for each term, we identified whether the DPV contained the (semantically) exact concept - which we call an 'exact match', failing which we looked for the closest relevant term(s) which could be used as a substitute - called a 'partial match', and if any existing term could not represent the term - we considered it a 'new term' to be proposed to the DPVCG for inclusion in the DPV.
Of the 47 unique concepts found through ROPA templates analysis, we found 44 exact matches, one partial match, and two new terms proposed and added to the DPV. The output of this was the CSM-ROPA consisting of 47 concepts covering information requirements from GDPR and DPA templates for representing a ROPA. CSM-ROPA, through the use of DPV concepts, provides the ability to express a ROPA as a machine-readable and interoperable 'graph' that can be utilised in technological solutions for automating processes associated with ROPA and GDPR compliance. The CSM-ROPA data and analysis are available online at https://w3id.org/dpcat/csm-ropa. The table below provide an overview of this mapping.
GDPR | Field | DPV | Mapping | Controllers | Processors |
---|---|---|---|---|---|
5 | Location of personal data | dpv:StorageLocation | E | R | R |
5.1 | Data Sources | dpv:DataSource | E | R | O |
6.1 | Legal basis | dpv:LegalBasis | E | M | O |
6.1 | Link to record of consent | dpv:Consent | E | R | R |
9.1 | Special Personal Data | dpv:SpecialCategoryPersonalData | E | R | O |
9.1 | Vulnerable Data Subjects | dpv:VulnerableDataSubject | E | R | O |
22.1 | Automated decision-making or profiling | dpv:AutomatedDecisionMaking | E | R | R |
26.1 | Joint Controller agreement | dpv:JointDataControllersAgreement | E | R | N/A |
28 | Data Processors | dpv:DataProcessor | E | R | M |
28.3 | Data Processing Contract | dpv:DataProcessingAgreement | E | R | R |
28.3 | Data processor contract | dpv:ControllerProcessorAgreement | E | R | R |
30.1 | Status of processing | dpv:Status | S | M | M |
32 | Tech/Org measures implementation | dpv:Technology | E | R | R |
32 | Security measures | dpv:TechnicalOrganisationalMeasure | E | R | R |
32 | Technologies used | dpv:Technology | E | R | R |
33.5 | Data Breach | dpcat:DataBreachRecord | S | R | R |
35 | Risk management | dpv:RiskMitigationMeasure | E | R | O |
35 | DPIA Results | dpv:DPIA | E | R | O |
35 | Relevant DPIA | dpv:DPIA | E | R | R |
36.1 | Impact Assessments | dpv:ImpactAssessment | E | R | R |
36.1 | Prior Consulatations | dpv:Consultation | E | R | R |
37.6 | External DPO organisation | dpv:DataProtectionOfficer | E | R | R |
⨯ | Name of Business Process | dpv:PersonalDataHandling | Pt | O | O |
⨯ | Owner of Process | dct:contactPoint | E | M | M |
⨯ | Type of Processing | dpv:Processing | E | O | O |
13, 14, 15 | Data Subject Rights | dpv:DataSubjectRight | E | R | O |
28, 30.1(c) | Data Categories Transfer to Third Parties | dpv:Transfer, dpv:PersonalData | E | R | R |
30.1(a) | DPO contact | dpv:hasName, dpv:hasContact | E | MC | MC |
30.1(a) | Representative | dpv:Representative | E | MC | N/A |
30.1(a) | Representative contact | dpv:hasName, dpv:hasContact | E | MC | N/A |
30.1(a) | Name of joint controller | dpv:JointDataController | E | MC | N/A |
30.1(a) | Contact details of joint controller | dpv:hasName, dpv:hasContact | E | MC | N/A |
30.1(b) | Purposes of processing | dpv: Purpose | E | M | O |
30.1(b) | Main/Auxilary Processing | dpv:Importance (Primary, Secondary) | E | O | O |
30.1(c) | Personal Data Categories | dpv:PersonalDataCategory | E | M | M |
30.1(c) | Categories of data subjects | dpv:DataSubject | E | M | M |
30.1(d) | Categories of Recipients | dpv:Recipient | E | MC | MC |
30.1(e) | Third Countries Data Transfer | dpv:ThirdCountry | E | MC | MC |
30.1(e) | Appropriate Safeguards | dpv:Safeguard | E | MC | MC |
30.1(f) | Retention/Deletion Periods | dpv:StorageDuration, | E | M | O |
30.1(g) | Technical and organisational measures | dpv:TechnicalOrganisationalMeasure | E | M | M |
30(1)(a) | Data Controller contact | dpv:hasName, dpv:hasContact | E | M | M |
30(1)(a) | Data Protection Officer | dpv:DataProtectionOfficer | E | MC | MC |
44-47 | Nature of Transfer | dpv:DataTransferLegalBasis | E | MC | MC |
6.1(f) | Legitimate interests | dpv:LegitimateInterest | E | R | R |
6.1(f) | Legitimate interests assessment | dpv:LegitimateInterestAssessment | E | R | R |
6, 14, 30.1(b) | Data Combination | dpv:Combine | E | R | O |