Processing Conditions

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.

Storage Conditions

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.

Data Source

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.

Entity Involvement

[=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.

Automation Level and Human Involvement

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-22989]]], 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=].

Decision Making and its Logic

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.

Classes