Meeting minutes
Repository: w3c/dpv
ghurlbot, harsh is coolharsh55
Meeting notes are available at - https://
Updates to multilingual translations
tobias regretablly is not here to report back, so we will wait for updates regarding that
ghurlbot, get #89
Proposed change to include Non-Personal Data
No comments in terms of changes or further deliberations
<TallTed> apologies for early drop; conflicting call at :30.
<TallTed> If not on this group's radar already, BlackHat and similar conference presenters & attendees are likely to be good folks to enlist, especially for helping with the circular RISK analysis.
<TallTed> and then conflicting call was cancelled, so I'm back (still in the background) :-)
thanks ted, I will make note of it in the minutes
we are trying to avoid getting bogged down into risk assessments despite the discussion implying otherwise!
DGA extension
beatriz: waiting for review of proposed concepts and integration with DPV
georg: will review with beatriz and will report back findings in the next meeting
ghurlbot, get #62
ghurlbot, get #62
ACTION: beatriz and georg to review DGA proposed concepts
Risk Management concepts
delaram: what is the scope of 'risk' in DPV? Is it limited to personal data or also includes non-personal data?
harsh: Depending on the resolution of proposed change to include non-personal data, the scope of the concept 'risk' will also change to include non-personal data. However, the focus of the group will remain on the risks associated with processing of personal data or relevant systems (e.g. AI).
delaram: are we doing only a checklist for DPIA in terms of concepts or also more?
harsh: the scope if broader in terms of DPIA, but we are also not doing full risk management as in internal organisational processes. We take risk as the information to be documented based on legal or other requirements. So outcomes of things are recorded, and then relevant concepts are added in a backwards-fashion.
harsh: For example, for DPIA, we started with the outcomes in terms of allowing processing to continue or not, and then developed what led to the decision, then the risks and impacts, and then we had a risk ontology.
delaram: what is the relation to my work on AI risk? Should there be specific controls for AI within DPV for example? What about including risk sources as a taxonomy?
harsh: In terms of the AI Act, we do not include proposals at the moment to focus on regulations or requirements that are concrete and will not change. The AI Act categorisation of risks may change in the next draft, for example. Therefore once the AI Act has been finalised, you should update your concepts to the final version and submit to DPV as a proposal, similar to what we are doing with DGA.
harsh: In terms of risk sources - yes, a taxonomy would be useful.
Risk Assessment
delaram: what concepts from Risk related vocabularies be included in DPVCG?
harsh: There are far too many different vocabularies for risk, and they are too vague and are not consistent with each other. This leads to confusion for me every time I start to look up risk assessment concepts.
harsh: The ISO risk vocabulary, ISO 31073:2022, is too vague and does not give an indication on how the concepts are to be used. They are also too broad to be specific here.
harsh: The idea therefore is to take a good authoritative set of concepts, such as the NIST Guide for Conducting Risk Assessments https://
harsh: This is the set I used for modelling the incident vocabulary, where the concepts are as follows - Risk is caused by Threat, Vulnerability causes Threat, Risk Source causes Vulnerability or Threat to exist, Threat Actor takes advantage of Vulnerability to make Threat happen leading to Risk.
harsh: That was the left side or the pre-event concepts. The post-event concepts relate to Consequence of the Risk, which might be on a Process or Service, and the Impacts arising from thereon. I will share this example in an email to enable us to discuss adding concepts to DPV.
harsh: The goal is to keep it as a simple model for representing the relevant information required to be reported and documented, quite likely by legal requirements. For example, NIS2 has incident reporting, and GDPR has data breach reporting. We do not model how things work internally.
ACTION: harsh to send email regarding risk assessment concepts
Data Breach concepts
No issues found with data breach concepts. Paul would like to review the spreadsheet for concepts and report back next week.
ACTION: paul to review data breach concepts
Incident Reporting concepts
Based on the email sent by harsh - https://
The proposal is that these concepts be added to RISK extension, with data breach concepts being modified to be specialised from these, and added to the GDPR extension to reflect their requirement as per GDPR
georg and paul agree with the proposal (idea) and would like to review it
ACTION: georg and paul to review the Incident Reporting concepts
harsh: An example of the use of vocabulary is in the email where the use-case of a data breach shows both the breach and incident information being reported.
harsh: The idea was to have incident concepts be in RISK extension as they are related to security, so together with risk concepts. GDPR specific stuff like data breach in the GDPR extension, and then a separate extension for NIS2 specific concepts (also in the email) which we will take up as a separate proposal.
ghurlbot, bye