Processing

Obtain is the broad concept representing various ways of obtaining or collecting data. Collect is a specific way of obtaining data, with other ways being to Derive or Infer it from existing data, or to Observe it. While it can be argued that Collect and Observe are the same method since observing data implies collecting data, the model here represents distinctions which become important in context. For example, to distinguish between data obtained from a person (collect) and data being detected through a signal (observe). Further Generate represents data being generated i.e. where it didn't exist before, whereas Derive and Infer have a link to some existing data which is used to produce the new data. Similarly, Acquire implies the data already exists elsewhere and is being 'acquired' in to the current context - for example by way of taking over a process or company.

Most common uses of processing operations use the term 'collect' to represent all of the above, which can be misleading or ambiguous. Therefore, we suggest using the accurate verb to represent the processing operation accurately, or failing that, to use Obtain as the generic term. In particular, we caution again misappropriating Collect for Infer as there is an important distinction which is lost in context regarding the potential inaccuracy of inferred data which is a result of the method of inference. Data quality issues with collection can also be present, but represent a different category of 'errors' in operation. Further, inferences also have an important role when it comes to privacy matters - such as when inferencing sensitive or special categories of data which are not typically visible to the individual or source, whereas collection is explicit about the data being collected.

Similarly, we also caution against mixing Derive which implies a derivation or transformation operation on existing information, such as a first name from a full name, with Infer where the intended output is not already present within the information. Sometimes these distinctions are not clear, or can involve ethical concerns which can vary from minor concerns such as inferring emotions from text to severe pseudo-scientific theories such as phrenology. Accurately depicting the processing operations is a key factor in carrying out risk and impact assessments as the risks associated with derived and inferred data are distinct and have different assessments and mitigations.

Store represents the processing operation where data is stored i.e. preserved for later use. Merely stating Obtain does not imply that data is stored e.g. it could be collected, used, and then discarded. Therefore, whenever data is stored, we strongly suggest explicitly denoting Store as the processing operation. The processing operation Store does not distinguish the manner in which data is stored (e.g. as bytes, documents, images), nor the location of storage (e.g. on device, in cloud). These are all described through Storage Conditions.

Use is a generic concept that represents data that has been obtained or is stored is being used to do something (which could be a purpose). There are specific forms of usage, such as Access, Query, and Retrieve which are technical operations, and Profiling and Tracking which are complex operations which involve additional concepts, but are expressed as processing operations to denote their nature as technical operations which by itself does not describe why they are taking place (i.e. the purpose).

Operations where data is not being actively used (towards something) but is being technically organised or transformed is represented by Transform and its specific concepts. This includes Anonymise and Pseudonymise, as well as Combine which includes other data. Transformations can happen as part of general data management, and do not by themselves necessarily imply they are being done towards a goal e.g. data is being aggregated and then later it is used by retrieving. This separation allows representing information about transformations in a granular manner without involving the use of this information (later) in various contexts.

Disclose means to disclose the data (to someone or something). It is the generic concept for more specific forms of disclosure such as Display, Export, and the commonly used Share. We recommend using Disclose concepts to represent data being disclosed between entities, such as when showing the user some data, or sharing information with another entity. We also highlight the distinction between the use of Disclose and Transfer - where transfers simply means movement of data, whereas disclosure has an implication regarding crossing a boundary of an entity and may or may not involve a transfer.

Transfer represents the technical notion of data movement from one location to another. Legally, this is an important concept where this movement happens between locations that cross a jurisdictional boundary. To represent this, we suggest using CrossBorderTransfer. Merely transferring data does not by itself imply concepts such as Share or Disclose. Therefore, to accurately and unambiguously express what processing operations are taking place, we recommend using Transfer with another concept where necessary.

For CrossBorderTransfer, it may be desirable to state the location or jurisdiction in question. This can be declared within the instance through dpv:hasLocation and dpv:hasJurisdiction. Note that we only recommend stating the location the data is being transferred to i.e. the target and not the current or source location, as that is the relevant information within a 'cross-border transfer'. The current location should be stated in its own context e.g. for Store or Obtain or Use.

Remove is the generic concept representing removal of data from the current context. This removal can be through Delete operations where data is logically removed - but where in theory it can be retrieved again (e.g. disk retrieval algorithms), or Erase where the data is removed in a way that retrieval is not possible (e.g. overwriting with null values). There is also Destruct which has a stronger implication of no recovery possible from any method - which can be used to describe aspects such as deletion of all copies of data from backups.

To indicate that the process involves profiling and tracking processing operations, the concepts Profiling and Tracking are provided. While profiling and tracking are more complex concepts as compared to collect or use or store as 'simple' operations, they are included in the processing operations taxonomy as they represent specific ways of using (personal) data, and by themselves do not provide sufficient indication of the purpose or intended objective for why they are being performed.

Tracking is further distinguished as TrackingByFirstParty and TrackingByThirdParty to reflect the commonly used terms for tracking performed by entities considered as 'first' and 'third' parties within a context. While the DPV itself does not (yet) model these first/third relations, these concepts reflect existing uses of the term and therefore the DPV relies on these existing definitions and uses to guide the usage of these concepts. For reference, see the Do Not Track terminology page. Similarly, DPV's definition of Profiling is a minimal representation of creating a profile of a person based on the use of (some) data. To indicate specific definitions of profiling, e.g. in a law like the EU's GDPR, this concept should be extended to reflect the specific definition, such as the eu-gdpr:Profiling concept defined in the [EU-GDPR] extension based on the definition in GDPR's Article 4-4.

To describe conditions associated with processing, such as its duration, or specific locations, the concept ProcessingCondition provided and extended as ProcessingDuration and ProcessingLocation along with the relation hasProcessingCondition. Storage, which is a specific form of processing, has additional dedicated concepts as StorageCondition as it is a commonly used concept. The concepts are useful to describe processing and storage conditions in policies, conditions, rules, or documentation - which are important tools for implementing and determining data protection and privacy considerations as well as legal compliance.

The [TECH] extension provides relevant concepts to indicate technical aspects such as a server located in a specific location and provided by a cloud provider, which is being used to carry out the processing operations.

This taxonomy provides concepts for representing information about storage conditions, e.g. how long the data will be stored for, its erasure, or its restoration. It also enables representing the source(s) of data, the use of automation, and the extent of human involvement within the automation.

The processing taxonomy uses the concept Store to indicate data is being stored. To specify additionally information such as its location, erasure or deletion, the generic concepts and relations associated with processing (i.e. location and duration) can be used. However, to emphasise that information about storage - such as policies, conditions, rules, or documentation - are critical on considerations of data protection and privacy as well as legal compliance, DPV provide specific concepts related to these.

The concept StorageCondition and the relation hasStorageCondition represent the general or abstract conditions associated with storage of data. This is specialised to indicate StorageDuration, StorageDeletion, StorageRestoration, and StorageLocation. This enables a document to directly specify information such as: "storage duration is 6 months" or "storage restoration uses 3 geo-distinct backup servers".

To indicate the use of cloud storage services, the [TECH] extension provides relevant concepts to represent the use of such cloud services as well as the actors involved to provide or develop them.

For declaring the source of data, the DataSource concept along with hasDataSource relationship is provided to indicate where the data is collected or acquired from. For example, data can be obtained from the data subject directly (e.g. given via forms) or indirectly (e.g observed from activity, or inferred from existing data), or from another entity such as a third party.

Data can be sourced from a public or a non-public source. The distinction is important given that a public source has different implications (and justifications) for the availability of that data as well as how it can be used. To represent these, DPV uses sub-types of data source as PublicDataSource and NonPublicDataSource. Public data sources can be datasets published by authoritative bodies, or census reports, or (public) websites. Non-public data sources are anything that is not publicly available - so data subjects, third parties, etc.

The following data sources are defined within DPV:

1. DataSubjectDataSource to indicate the data is sourced from Data Subject(s) e.g. when data is collected via a form or observed from their activities go to full definition
2. DataControllerDataSource to indicate the data is sourced from Data Controller(s), e.g. a Controller inferring data or generating data go to full definition
3. ThirdPartyDataSource to indicate the data is sourced from a Third Party, e.g. when data is collected from an entity that is neither the Controller nor the Data Subject

In addition to these, the concepts PublicDataSource and NonPublicDataSource are also provided to indicate whether the data being sourced was publicly available or not.

EntityInvolvement specifies how an entity is involved in terms of being permitted to do something, or not being permitted to do something. It contains two sets of correlated concepts as EntityPermissiveInvolvement for 'permissive' and EntityNonPermissiveInvolvement for 'non-permissive' involvements. For example, OptingOutFromProcess represents a 'permissive' involvement where the entity can opt-out, while CannotOptOutFromProcess is its 'non-permissive' counterpart which indicates the entity cannot opt-out. Other concepts provided concern challenging the process and its inputs and outputs, correcting the process and its inputs and outputs, reversing the process' effects and its inputs and outputs, and withdrawing from a process.

In addition to the above involvements, two additional concepts provided are: EntityActiveInvolvement and EntityPassiveInvolvement to represent whether the involvement of an entity can be considered 'active' or 'passive'. Here, the term 'active' means the entity actively engages with the processing or system or technology, and 'passive' means it does not. For example, a person filling a web form to enter their data has an active involvement, whereas a person being monitored via a CCTV has a passive involvement. Note that here the terms 'active/passive' do not represent or concern the 'awareness' or 'comprehension' of the entity, and only represent the involvement in terms of operating or using or being subjected to the system or process. The concept EntityInformedStatus should be used to represent whether the entity is informed or not.

To represent how humans are involved, the concept HumanInvolvement and relation hasHumanInvolvement are provided. Human involvement is broadly specified in terms of HumanInvolved and HumanNotInvolved. Where humans are involved, additional concepts such as HumanInvolvementForDecision or HumanInvolvementForInput provide a clear representation of the involvement. Terms such as 'human-in-the-loop' were discussed and not used due to their unclear definitions and non-compatible uses across documents. Instead, the DPV defined concepts provide unambiguous representation of how humans are involved, and can be mapped to definitions of such terms within specific use-cases.

DPV defines concepts to specify the 'level of automation' and 'human involvement' in processing operations. These are in addition to entity involvement so as to specifically indicate how humans are involved in the automated operations.

AutomationLevel describes the level of automation associated with processing operations. It is based on the levels defined by ISO/IEC 22989:2022 Artificial intelligence concepts and terminology, which consist of NotAutomated (level 0) where no automation is involved, to FullAutomation (level 5) representing automation without human involvement, and Autonomous (level 6) representing automation which can modify its operational goals without human intervention. Automation levels are specified by using the relation hasAutomationLevel.

To indicate more specific applications: DecisionMaking and AutomatedDecisionMaking refer to use of processing to make decisions, AlgorithmicLogic for explaining the use of algorithms and specifics of processing logic, EvaluationScoring to indicate the processing evaluates or assigns scores (or metrics), InnovativeUseOfNewTechnologies to indicate there are innovative uses of novel technologies, and SystematicMonitoring to indicate the processing performs a systematic (or systemic) monitoring. These additional concepts are intended to model areas or topics that are considered sensitive or high-risk or require caution.