Risk Extension

To express likelihoods, the RISK extension provides the following groups of concepts. Each concept is associated with a suggested value to represent the extent or degree of the concept between 0..1 using rdf:value e.g. ExtremelyLowRisk has a value of 0.01 and HighLikelihood has a value of 0.75. Each group uses these values to express a range within a group e.g. in 3LikelihoodLevels the LowLikelihood (0.25) covers the range 0 to 0.25, while in 7LikelihoodLevels it covers the range from 0.1 (VeryLowLikelihood) to 0.25. Adopters can thus choose the appropriate ranges, and as the values are suggestions - they can be changed to match the requirements of the use-case.

• 3LikelihoodLevels which contains 3 likelihood levels of HighLikelihood (0.75), ModerateLikelihood (0.5), and LowLikelihood (0.25)
• 5LikelihoodLevels which contains the 3 likelihood levels from 3LikelihoodLevels as well as VeryHighLikelihood (0.9) and VeryLowLikelihood (0.1)
• 7LikelihoodLevels which contains the 5 likelihood levels from 5LikelihoodLevels as well as ExtremelyHighLikelihood (0.99) and ExtremelyLowLikelihood (0.01)

To express severity in a convenient manner, the RISK extension provides the following groups of concepts, where each concept is also associated with a suggested value similar to likelihood to represent the extent or degree of the concept between 0..1 using rdf:value

• 3SeverityLevels which contains 3 Severity levels of HighSeverity (0.75), ModerateSeverity (0.5), and LowSeverity (0.25)
• 5SeverityLevels which contains the 3 Severity levels from 3SeverityLevels as well as VeryHighSeverity (0.9) and VeryLowSeverity (0.1)
• 7SeverityLevels which contains the 5 Severity levels from 5SeverityLevels as well as ExtremelyHighSeverity (0.99) and ExtremelyLowSeverity (0.01)

To express risk levels in a convenient manner, the RISK extension provides the following groups of concepts where each concept is associated with a suggested value to represent the extent or degree of the concept between 0..1 using rdf:value similar to likelihood and severity concepts.

• 3RiskLevels which contains 3 RiskLevel levels of HighRisk (0.75), ModerateRisk (0.5), and LowRisk (0.25)
• 5RiskLevels which contains the 3 RiskLevel levels from 3RiskLevels as well as VeryHighRisk (0.9) and VeryLowRisk (0.1)
• 7RiskLevels which contains the 5 RiskLevel levels from 5RiskLevels as well as ExtremelyHighRisk (0.99) and ExtremelyLowRisk (0.01)

Risk Matrix is a popularly used technique for qualitative risk analysis, through which a risk's likelihood and severity are used to obtain an overall risk level. To support its use, the RISK taxonomy provides concepts representing risk matrices of the format 3x3, 5x5, and 7x7. The concepts are expressed as combinations of Severity (Sx) and Likelihood (Lx) levels, and the resulting Risk Level (Lx) being used as its label. For example, the concept RM3x3S1L3 represents a node in a 3x3 matrix with Severity and Likelihood level low (n=1) and Likelihood level high (n=3) with a resulting Risk Level of 'Moderate'. Similarly, RM7x7S4L7 represents a node in a 7x7 risk matrix with Severity level moderate (n=4) and Likelihood level extremely high (n=7) with the resulting Risk Level of 'Very High Risk'.

It is possible to change the risk levels for the risk matrix by replacing the supplied labels with a custom one. For example, to indicate that the concept RM3x3S1L3 should be 'Low Risk' instead of 'Moderate'. Ideally, this should be done by extending the relevant concepts to indicate a custom / use-case specific enumeration of risk levels and scores. The below table showcases the risk matrix collections provided in the RISK extension. The concepts in each cell can be clicked on for the full definition table. The colours are indicative and are not part of the vocabulary.

To indicate the duration of the incident, the [DPV] concept dpv:Duration and relation dpv:hasRelation can be used, or dct:temporal from [DCT] can be used, or other means such as the [TIME] ontology or XSD types. If this information is unknown, then dpv:NotAvailable should be used. If the incident is ongoing, only the start would be available and represented within the period or duration information. The taxonomy of statuses for IncidentStatus is provided to indicate whether the incident is ongoing or concluded (on its own) or it was terminated due to some action taken), which is indicated in context using the relation dpv:hasStatus.

IncidentIdentifier represents an identifier associated with an incident. This concept assists in specifying identifiers that may be assigned by the directly affected entity, or to share identifiers for tracking the same incident amongst entities, or to share an identifiers as a common reference when reporting an incident to authorities.

IncidentImpactAssessment represents an impact assessment conducted specifically for the incident. It can be associated in contexts, such as for an IncidentReport by using the relation hasAssessment and hasImpactAssessment .

An IncidentMitigationMeasure is a 'mitigation measure' taken specifically in relation to an incident - such as to reduce the effects or to inform affected stakeholders. The use of 'mitigation' here is from the legal terminology, and includes a broad range of options available under the typical risk management vocabulary such as eliminating, detecting, modifying, and so on. The relation isMitigatedByMeasure can be useful to associate the measure with an incident.

IncidentNotice is a notice specifically about an incident, such as for providing information to stakeholders, or to report the incident to authorities. It can be associated in context using hasNotice . Note that extensions modelling legal requirements such as [EU-GDPR] and [EU-NIS2] will provide specific concepts that extend this notice concept corresponding to obligations around reporting.

IncidentRegister is a record of incidents (including near-misses and other relevant statuses). It can be associated in context using hasRecordOfActivity , and also through hasOrganisationalMeasure .

Further metadata about incidents can be modelled through the [DCTERMS] vocabulary. The DPVCG also welcomes participation and contributions to expand this incident related vocabulary in the RISK extension.

IncidentStatus refers to the status of the incident itself, and IncidentInvestigationStatus refers to the status of the investigation associated with an incident. Such investigations are obligations under specific legal requirements, such as for data breaches under GDPR, and security incidents under NIS2. These laws require notifying relevant authorities regarding an incident within specific time frames varying from initial preliminary notifications of an incident occurring, to later notifications with a full report when the incident handling has been completed.

An IncidentReport represents a report regarding an incident with the goal of documenting information about an incident found through investigations - such as when it occurred, its scope, effects, sources, as well as information about the investigations itself. The RISK extension defines specific categories of reports to support legal reporting obligations, such as IncidentDetectionReport for reporting when an incident has been detected, or IncidentPreliminaryReport for a preliminary (early) report when the incident and/or its investigation is still ongoing and the complete details may not be available.

As IncidentReport as defined as a kind of OrganisationalMeasure , they can be associated or involved in context through the relations hasOrganisationalMeasure for a broad reference to reporting as a measure, and hasRecordOfActivity to specifically assert the report as a record of the investigation process.

The RISK extension provides a taxonomy of concepts such as HumanErrors, Damage, and Harm that represent 'events' that can used in specific roles within the use-case. For example, HumanErrors can be a 'source of risk' where a software developer introduces a bug/error in the code; a 'risk' where the software user accidentally deletes critical data while using the software - where the source is poorly designed UI/UX; and a 'consequence' where the developer accidentally uses the incorrect backup when recovering from a data breach - where the risk is the data breach and the source is insecure system settings. This example highlights that 'roles' such as risk source, risk, consequence, and impacts are contextual assertions, and that the same 'event' or 'concept' can take on different roles in different settings.

The taxonomy provided in RISK is intended to support such broad use of concepts for taking on different roles as needed within the context. This is particularly valuable as the areas of cybersecurity and AI technologies are rapidly evolving landscapes where new risks and consequences frequently emerge, and depending on the perspective the same concept can act as a consequence (e.g. early in development stages) or be the source of risks (e.g. later in deployment stages). Further, the RISK extension also aims to support the creation of 'thesauri' or 'catalogues' of concepts - such as a 'risk catalogue', which provides a curated list of concepts that stakeholders can use in their respective contexts.

To enable such varied uses of the taxonomy, the RISK extension uses 'meta concepts' called PotentialRisk, PotentialRiskSource, PotentialConsequence, and PotentialImpact that represent the potential roles that a concept can take within a context. A concept expressed as PotentialRisk and PotentialConsequence means that the concept can potentially act as a risk or a consequence based on common uses of that concept, but it does not mean that the concept is always a risk or a consequence. The person or system that is identifying risks and consequences can then refer to this categorisation as a hint for what concepts could be applicable in their use-case rather than having to go through the entire taxonomy.

The concepts such as PotentialRisk are also helpful to curate thesauri and catalogues. For example, when creating a risk catalogue associated with testing phase of software development, we can express the source of risks (as PotentialRiskSource) and then provide these to the developers and testers to assess for a particular software iteration, and record which risks are applicable (as Risk ). Similarly, if the organisation wants to create two catalogues of common software risks and user risks, it can extend PotentialRisk as PotentialSoftwareRisks for potential risks that may occur in software and PotentialUserRisks which may occur due to users, then annotate the RISK taxonomy using these, and provide it as inputs to consider in the risk assessment process.

To further support the utility of the taxonomy, where possible, concepts are also categorised based on the commonly utilised 'CIA triad model' in information security, where 'CIA' stands for 'Confidentiality', 'Integrity', and 'Availability'. These are represented by the specific concept being declared as an instance of ConfidentialityConcept, IntegrityConcept, and AvailabilityConcept respectively.

A PotentialRiskSource represents a concept which can be a risk source or act like a risk source in specific concepts. The concept can also be used to create domain or sector or use-case specific groupings of concepts which can act as risk sources in context. Concepts which can act as a potential risk source are defined as an instance of PotentialRiskSource.

A PotentialRisk represents a concept which can be a risk or act like a risk in specific concepts. The concept can also be used to create domain or sector or use-case specific groupings of concepts which can act as risks in context. Concepts which can act as a potential risks are defined as an instance of PotentialRisk.

A PotentialConsequence represents a concept which can be a consequence or act like a consequence in specific concepts. The concept can also be used to create domain or sector or use-case specific groupings of concepts which can act as consequences in context. Concepts which can act as a potential consequence are defined as an instance of PotentialConsequence.

A PotentialImpact represents a concept which can be an impact or act like an impact in specific concepts. The concept can also be used to create domain or sector or use-case specific groupings of concepts which can act as impacts in context. Concepts which can act as a potential impact are defined as an instance of PotentialImpact.

A TechnicalRiskConcept represents a concept that is technical in nature or relate to a technical or technological process, and which then can be applicable as a risk source, risk, consequence, or impact in specific concepts.

A OrganisationalRiskConcept represents a concept that is organisational in nature or relates to an organisational process, and which then can be applicable as a risk source, risk, consequence, or impact in specific concepts.

A SocietalRiskConcept represents a concept that is societal in nature or relates to a societal process or event or effect, and which then can be applicable as a risk source, risk, consequence, or impact in specific concepts.

A TechnicalRiskConcept represents a concept that is legal in nature or relates to a legal process, and which then can be applicable as a risk source, risk, consequence, or impact in specific concepts.