This document provides additional details and examples for risk and impact assessment concepts used in the Data Privacy Vocabulary [[DPV]], and is a companion to the [[DPV]] specification.

Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.

Introduction

For risk and impact assessment, DPV's provides a 'lightweight risk ontology' based on commonly utilised concepts of [=Risk=], [=RiskMitigationMeasure=], [=Consequence=], and [=Impact=] along with risk assessment concepts of [=RiskLevel=], [=Severity=], and [=Likelihood=]. Through these concepts, information about what risks and impacts exist as well as their qualitative and quantitative assessment (severity, level) can be sufficiently expressed.

For a more comprehensive representation of risk assessment, mitigation, and management concepts, the [[[RISK]]] extension should be used which is based on relevant standards such as the ISO/IEC 31000 series. The [[RISK]] extension also provides taxonomies for these concepts which permits representation of information such as different types of consequences and impacts or concepts representing levels, severities, and likelihoods. It also provides representations of risk matrices, modelling incident and associated statuses, and categorises of 'controls' for a clearer application of measures.

Risk

[=Risk=] within the DPV is concerned with 'probable negative effects', and is indicated by using [=hasRisk=]. A risk event is a probable event that may lead to negative consequences and impacts (hence it is a 'risk'). It is important to note that a risk is a hypothetical event i.e. it is a probability that something may occur. The concept `risk:Incident` in [[RISK]] extension represents incidents which have occured and provides the necessary concepts to connect them to risks for what had been previously assessed as well as to indicate what are the further risks associated with an incident.

[=Likelihood=], associated using [=hasLikelihood=], represents the likelihood or probability or chance of something (risk in this case) taking place. The [[RISK]] extension defines concepts to indicate likelihoods with various scales e.g. as a set of 3 concepts representing high likelihood, moderate likelihood, and low likelihood.

[=Severity=], associated using [=hasSeverity=], represents the severity or 'extremeness' or 'intensity' of something (risk in this case). The [[RISK]] extension defines concepts to indicate severities with various scales e.g. as a set of 5 concepts representing very high severity, high severity, moderate severity, low severity, and very low severity. [=SensitivityLevel=] represents the 'sensitivity' of some context (e.g. personal data) as a measure of how severe risks associated with it are (e.g. to indicate how sensitive the personal data is). It is associated using the relation [=hasSensitivityLevel=].

[=RiskLevel=], associated using [=hasRiskLevel=], represents the combination of severity and likelihood in the form of 'risk level' that provides a cohesive qualitative assessment of risk. The [[RISK]] extension defines concepts to indicate risk levels with various scales e.g. as a set of 3 concepts representing high risk, moderate risk, and low risk.

Risk Mitigation Measure

[=RiskMitigationMeasure=] is a measure taken to mitigate the risk. Here the use of the word 'mitigate' follows from its use in legal documents and includes avoiding, reducing, replacing, removing, transforming, sharing, and other operations related to risk treatment. In normative risk related guides and standards, mitigation is only one operation within risk treatment processes.

Risks can have multiple mitigation measures, which are indicated by using [=isMitigatedByMeasure=] relation. A mitigation measure may address multiple risks, which are indicated by using [=mitigatesRisk=]. The [=RISK=] extension provides a more granular taxonomy of risk mitigation measures, including risk controls which enable expressing aspects of the intended effect of a measure on risk (or other events) - e.g. to remove the source or to alter the consequence.

Risk remaining after 'mitigation' or 'treatment' is represented by [=ResidualRisk=], which is a subcategory of [=Risk=] and uses the same relations to express likelihood, severity, level, and further mitigations. It is associated by using [=hasResidualRisk=] and [=isResidualRiskOf=] relations.

Consequence & Impact

The concepts [=Consequence=] and [=Impact=] in DPV are provided with a specific modelling of consequences and impacts. The DPV concept for consequence represents the consequence of an event (e.g. risk or incident), and impact is a specific type of consequence which as significance to an entity. DPV considers effects on technical systems (e.g. service disruption) and minor effects on entities (e.g. delayed process) as consequences from major effects focused on entities (e.g. harms) as impacts. Based on this, we recommend using consequences and impacts in the following manner:

1. [=Consequence=] to indicate the immediate effect of an event where it is not significant to an entity - this can be disruption of the system or service, or loss of data, or other such events. Most technical events would fall under consequence.
2. To indicate what the consequence has affected, the relation [=hasConsequenceOn=] is provided. The effect of consequence can be material or non-material, and can be on a system, agent, or legal entity.
3. [=Impact=] to represent consequences which have a significant effect on one or more `dpv:Entity`. Impacts are associated by using [=hasImpactOn=] relation, and the impact is always on an entity. The significance of impact is associated with how it affects the entity e.g. financial loss, physical or mental harm, or impact on rights.
4. The entity being affected by the impact is indicated by using [=hasImpactOn=].

The consequences and impacts can reuse the risk assessment properties to describe likelihood and severity. Consequences and impacts can also be chained together e.g. to describe a consequence (service diruption) leads to another consequence (wasted time) which leads to an impact (financial loss). Consequences and impacts can be hypothetical (i.e. risks) or actual (i.e. incidents).

Consequences and impacts can be positive (e.g. benefit) or negative (e.g. harm). The relations associating them with entities or systems should be interpreted accordingly. For example, if the impact is a harm - which is negative, then the impacted entity should be understood as being the one that is harmed. If instead the impact is compensation - which is positive, then the impacted entity should be understood as being the one that is compensated.

The [[RISK]] extension provides a taxonomy of consequences and impacts which covers commonly utilised terms such as harm, data breach, equipment failure, financial loss, and malware attack. It also provides a taxonomy of positive consequences and impacts which are not 'risks', such as benefits, renumerations, and compensation.

Risk and Impact Assessments

To support assessments associated with risks and impacts, DPV provides the following concepts:

1. [=RiskAssessment=] regarding risk assessments.
2. [=SecurityAssessment=] regarding assessment of security, and [=CybersecurityAssessment=] as assessment of cybersecurity.
3. [=ImpactAssessment=] to impact assessments, with [=PIA=] representing Privacy Impact Assessments (PIA) and [=DataTransferImpactAssessment=] for assessment of impacts in data transfer.
4. [=RightsImpactAssessment=] as a specific impact assessment that involves assessing impact on rights, with [=DPIA=] representing Data Protection Impact Assessment (DPIA) and [=FRIA=] representing Fundamental Rights Impact Assessment (FRIA).
5. [=DataBreachImpactAssessment=] represents assessment of data breaches and is defined as a rights impact assessment as at least privacy (for personal data) or commercial rights (for non-personal data) will need to be assessed in a data breach.

The relations [=hasRiskAssessment=] and [=hasImpactAssessment=] enable associating a risk and impact assessment with a process, service, or other contexts. There can be multiple assessments associated with the same context, e.g. for covering different topics or representing assessments at different stages or temporal periods. Assessments can indicate their 'subjects' and other metadata by using a relevant vocabulary such as [[[DCT]]]. Assessments can also record dates associated with their use to audit a system or process, and the relevant status to record the outcome of that process e.g. to indicate approval.

Vocabulary Index

Contributors

The following people have contributed to this vocabulary. The names are ordered alphabetically. The affiliations are informative do not represent formal endorsements. Affiliations may be outdated. The list is generated automatically from the contributors listed for defined concepts.

• Arthit Suriyawongkul (ADAPT Centre, Trinity College Dublin)
• Axel Polleres (Vienna University of Economics and Business)
• Beatriz Esteves (IDLab, IMEC, Ghent University)
• Bud Bruegger (Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein)
• Damien Desfontaines ()
• David Hickey (Dublin City University)
• Delaram Golpayegani (ADAPT Centre, Trinity College Dublin)
• Elmar Kiesling (Vienna University of Technology)
• Fajar Ekaputra (Vienna University of Technology)
• Georg P. Krog (Signatu AS)
• Harshvardhan J. Pandit (ADAPT Centre, Dublin City University)
• Javier Fernández (Vienna University of Economics and Business)
• Julian Flake (University of Koblenz)
• Mark Lizar (OpenConsent/Kantara Initiative)
• Maya Borges ()
• Paul Ryan (Uniphar PLC)
• Piero Bonatti (Università di Napoli Federico II)
• Rana Saniei (Universidad Politécnica de Madrid)
• Rob Brennan (University College Dublin)
• Rudy Jacob (Proximus)
• Simon Steyskal (Siemens)
• Steve Hickman ()