Re: Data Breach concepts

Hi.

I missed the last meeting, but as per the minutes (thanks Beatriz) [1] 
there was a call for a spreadsheet with the Data Breach concepts, which 
I have compiled here: 
https://docs.google.com/spreadsheets/d/1JT0dYFUiEomuP5EvoivuCUX6H78d7I839VeT5o-4-bE/edit?usp=sharing

[1] https://w3c.github.io/dpv/meetings/meeting-2023-06-29.html

Regards,
Harsh

On 17/06/2023 03:14, Harshvardhan Pandit wrote:
> Hi.
> Please see/review the data breach draft at 
> https://harshp.com/dpv-x/data-breach/ (source: 
> https://github.com/coolharsh55/dpv-x/tree/master/data-breach)
> 
> The content needs editorial review (e.g. typos, sentence structure) - 
> which I will do once I finish writing. The review is for what content 
> should be present in the document - please see if there is anything 
> missing, misplaced in the wrong section, needs restructuring, etc.
> 
> In addition to what we discussed, I have also added three new sections 
> for Data Breach Impact Assessments (to show examples of impacts), 
> Mitigating Data Breaches (to show risk assessment before breaches 
> happen), and Data Breach registers (to show how breaches are 
> documented). They have the tentative topics which I will be working on 
> now. Please also review this as additional proposed content.
> 
> Regards,
> Harsh
> 
> On 26/05/2023 16:46, Harshvardhan J. Pandit wrote:
>> Hi. Please see below the proposal for data breach concepts based on 
>> discussions so far.
>>
>> The proposal is to add a data breach extension with IRI 
>> https://w3id.org/dpv/databreach (which is indicated using db: below). 
>> The prefix ex: represents example concepts that the adopter or 
>> implementor will create.
>>
>> Note: Security reporting requires strict and clear information i.e. to 
>> be explicit in cases where something is or isn't applicable. Due to 
>> the open world assumption of semantic web, where if information is not 
>> specified then it can mean it is not applicable or not available or 
>> something else - this ambiguity is problematic for cases such as data 
>> breach reporting. To assist with this, we should add special instances 
>> in DPV to assist with explicitly indicating information and to address 
>> the ambiguity arising from "open world" assumptions. These are grouped 
>> under the status `InformationAvailability` and can be used anywhere:
>> 1) dpv:UnknownApplicability - a special instance indicating 
>> information is unknown i.e. it is not known if the information exists 
>> or is applicable and therefore statements about its availability 
>> cannot be made (yet)
>> 2) dpv:NotApplicable - a special instance indicating context is not 
>> applicable
>> 3) dpv:NotAvailale - a special instance indicating the information is 
>> applicable but is not yet available
>>
>> -- Data Breach extension --
>>
>> Data Breach information has six parts.
>> Part 1) Information about the Data Breach itself i.e. when did it 
>> occur, who was the cause, etc. This is represented with the concept 
>> `DataBreach`
>> Part 2) Investigation of the Data Breach i.e. report specifying when 
>> it was detected, what has been affected, who has it been reported to. 
>> This is represented using the concept `DataBreachReport` with specific 
>> sub-types.
>> Part 3) Notifications i.e. communication about the breach between 
>> entities, e.g. Controller to DPA. This is represented using the 
>> concept `DataBreachNotification`.
>> Part 4) Impact Assessment that assesses the risks and impacts based on 
>> available information. This is represented using the concept 
>> `DataBreachImpactAssessment`.
>> Part 5) Breach Mitigation assessment which identifes the causes of the 
>> breach and specifes what changes were made to prevent further breaches 
>> or mitigate consequences of existing breach. This is represented using 
>> the concept `DataBreachMitigationAssessment`.
>> Part 6) Details about the organisation, including its establishments 
>> and lead authorities for handling the data breach.
>>
>> -- DataBreach --
>>
>> Data Breach is an event, which means it has temporal properties. These 
>> are indicated using dct:temporal which can specify the start (if 
>> known) and end (if known). If both are not available, then use 
>> dpv:NotAvailale.
>>
>> The 'source' of a breach is represented using the concept 
>> `dpv:RiskSource` which is also a specific event whose existence led to 
>> the breach taking place. For example, an employee left their desk 
>> unattended without locking it down. In addition, a 
>> `risk:Vulnerability` can be specified to indicate some weakness was 
>> exploited. This is not necessary, for example some accident can occur 
>> without it being a vulnerability.
>>
>> The 'cause' i.e. actor of the breach, whether intentional or 
>> unintentional, and regardless of malicious intent or accidents, is 
>> represented by `dpv:ThreatActor`. In the above case, the threat actor 
>> is whomever accessed the system after the employee left - this could 
>> be another employee, a cleaner, or someone else. The existence of an 
>> actor is not a necessity for a breach to take place, for example, a 
>> disk drive containing sensitive data being thrown away is a data 
>> breach regardless if someone manages to collect it or not.
>>
>> The 'status' of a data breach refers to whether the breach has been 
>> concluded or is still ongoing. This is represented by 
>> `DataBreachStatus` with possible values `DataBreachStatusUnknown`, 
>> `DataBreachOngoing`, `DataBreachHalted`, and `DataBreachConcluded`, 
>> `DataBreachTerminated`, and `DataBreachMitigated`. Here, halted refers 
>> to a breach being stopped but with uncertainty regarding it being 
>> resumed (which makes it ongoing again). Concluded means it has 
>> finished (on its own), Terminated means the actions of the entity have 
>> caused it to be stopped, and Mitigated means it has also been 
>> prevented from happening again.
>>
>> The 'type' of a data breach refers to categorisation. The DPAs suggest 
>> three categories - confidentiality breach where authorisation has 
>> failed, integrity breach where data has been modified, and 
>> availability breach where data access has been compromised. These 
>> explanations are simplified, and their origin is in information 
>> security (CIA model). Specifying the type of breach is important as it 
>> represents what 'definition' of a breach should be interpreted and 
>> informs the follow-up investigations and reporting. The typical notion 
>> of a data breach only occuring when someone else has access to data is 
>> only one of these definitions. The type of breach is indicated using 
>> `rdf:type` with values `db:ConfidentialityBreach`, 
>> `db:AvailabilityBreach`, and `db:IntegrityBreach`.
>>
>> A data breach can have several identifiers - for example those within 
>> an organisation, across organisations, or in correspondence with 
>> authorities. To indicate these, the concept `db:DataBreachIdentifier` 
>> is provided that is used with `dpv:hasIdentifier`. The separate 
>> concept allows further categorisation of identifiers, and more 
>> importantly to distinguish who has provided which identifier, e.g. 
>> using `dct:creator` and `dct:publisher`.
>>
>> To indicate speculative information about data breaches, e.g. for 
>> planning and risk assessment purposes, DataBreach is defined as a 
>> subclass of dpv:Risk, which means we can specify `dpv:hasRisk 
>> db:DataBreach` and `dpv:isMitigatedByMeasure` to indicate potential 
>> breaches and how they have been addressed.
>>
>> Examples:
>>
>> ex:Incident1A a db:DataBreach ;
>>      rdf:type db:ConfidentialityBreach ; # type of breach
>>      dct:temporal db:Unknown ; # start and end are unknown
>>      dpv:hasRiskSource db:Unknown ; # what caused the breach
>>      dpv:hasThreatActor db:Unknown ; # who caused the breach
>>      dpv:hasStatus db:DataBreachOngoing . # status of breach
>>
>> ex:Incident1B a db:DataBreach ;
>>      rdf:type db:IntegrityBreach ; # type of breach
>>      dct:temporal "2023-05-24/2023-05-26" ; # start and end
>>      dpv:hasRiskSource ex:LackOfSecurityTraining ; # what caused the 
>> breach
>>      dpv:hasVulnerability ex:WeakAuthentication ; # what failed or 
>> went wrong
>>      dpv:hasThreatActor ex:MaliciousHacker ; # who caused the breach
>>      dpv:hasStatus db:DataBreachConcluded . # status of breach
>> ex:WeakAuthentication a risk:Vulnerability ;
>>      dpv:isImplementedUsingTechnology ex:Software ; # vulnerability of 
>> what
>>      dpv:isImplementedByEntity ex:Processor . # entity where breach 
>> took place
>>
>> -- Data Breach Detection Report --
>>
>> The concept `db:DataBreachDetectionReport` specifies the reporting of 
>> a data breach being detected, along with any pertinent details about 
>> the detection itself. This is necessary to separate from the 
>> information about a data breach from when it was detected, for example 
>> to denote when an entity became 'aware' of the breach as separate from 
>> the temporal properties of the breach itself. As there can be multiple 
>> entities involved in a breach, e.g. processor and controller, they 
>> will each have their own detection report.
>>
>> The usual DCMI properties can be utilised here, e.g. `dct:subject` to 
>> indicate which data breach is the subject of this report, 
>> `dct:created` to indicate when the report was created - and hence when 
>> was a breach first 'detected', and `dct:creator` to indicate who 
>> created the report. To further report updates, `dct:modified` is 
>> available to indicate further changes.
>>
>> To indicate the source of information, for example in connection with 
>> who reported the breach, the property `dpv:hasDataSource` should be 
>> used, e.g. with values Employees, specific Data Subject, link to a 
>> news item, etc.
>>
>> To specify any communications providing information about the breach 
>> (detection), the property `dpv:hasNotice` should be used. This can be 
>> incoming information (entity is recipient) or outgoing (entity is 
>> sender). To specify information contents of a notice as a form of 
>> communication, `schema:Message` can be used.
>>
>> To report on the status of detection (as a form of investigation), the 
>> existing `dpv:ActivityStatus` concepts can be used.
>>
>> Examples:
>>
>> ex:IncidentReport2A a db:DataBreachDetectionReport ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasDataSource ex:Employee ; # breach was reported by an employee
>>      dpv:hasDataSource <https://nytimes.com> ; # breach was reported 
>> in a news
>>      dpv:hasDataSource ex:Processor ; # breach was reported by a 
>> Processor
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of the 
>> detection reporting
>>
>> ex:IncidentReport2B a db:DataBreachDetectionReport ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasDataSource ex:Processor ; # breach was reported by a 
>> Processor
>>      dpv:hasNotice ex:ProcessorReportsBreach ; # breach info sent by 
>> Processor
>>      dpv:hasNotice ex:ReportedBreachToAuthority ; # breach reported to 
>> DPA
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of the 
>> detection reporting
>>
>> ex:ProcessorReportsBreach a db:DataBreachNotice, schema:Message ;
>>      dct:subject ex:Incident1A ;
>>      schema:dateReceived "2023-05-24" ; # when the message was sent
>>      schema:sender ex:Processor ; # who sent it
>>      schema:recipient ex:Controller ; # who received it
>>      schema:messageAttachment <report.pdf> . # what were the contents
>>
>> ex:ReportedBreachToAuthority a db:DataBreachNotice, schema:Message ;
>>      dct:subject ex:Incident1A ;
>>      schema:dateSent "2023-05-24" ;
>>      schema:sender ex:Controller ;
>>      schema:recipient ex:DPC ;
>>      schema:messageAttachment <report.pdf> ;
>>      dpv:hasJustification [ # justification if reporting is >72 hours
>>          a db:DataBreachDelayedReportingJustification ;
>>          dct:description "here's what actually happened ..."@en ;
>>          ] .
>>
>> -- Data Breach Investigation Report --
>>
>> Following from detection, a preliminary investigation report needs to 
>> be drafted for cases when the breach has to be reported, e.g. within 
>> 72 hours. This is represented by `db:DataBreachPreliminaryReport`, 
>> which is a subclass of `db:DataBreachReport`. As with 
>> `db:DataBreachDetectionReport`, the properties of `dct:subject`, 
>> `dct:created`, and `dct:creator` are applicable here. In a preliminary 
>> investigation report, more details are expected to be present than at 
>> the time of detection.
>>
>> Other subclasses of `db:DataBreachReport` are associated with the 
>> stage of investigation, represented by `db:DataBreachOngoingReport` 
>> and `db:DataBreachConcludingReport`. These can be tied together into a 
>> common group through an instance of `db:DataBreachReport`, for example 
>> by using `dct:hasPart`.
>>
>> What personal data has been affected, indicated using 
>> `dpv:hasPersonalData` and specific categories of data, including 
>> `dpv:SpecialCategoryPersonalData`. To indicate the scale of data, 
>> `dpv:hasDataVolume` should be used with a qualifier, e.g. 
>> `dpv:HugeDataVolume`, and a quantifier using `dpv:hasDataVolume` to 
>> indicate the actual number of data records affected.
>>
>> To indicate data subjects affected, similarly `dpv:hasDataSubject`, 
>> `dpv:hasDataSubjectScale`, and `dpv:hasDataSubjectScale` are to be 
>> used. In addition to these, DPAs require reporting whether there has 
>> been any cross-border context to the data breach including data 
>> subjects or processing activities in multiple member states. To 
>> indicate data subjects are from specific jurisdictions, the property 
>> `dpv:hasJurisdiction` should be used.
>>
>> To indicate processing activities, similarly `dpv:hasProcessing` and 
>> `dpv:hasProcessingScale`, `dpv:hasJurisdiction` can be used. To 
>> indicate what technologies were involved, we have 
>> `dpv:isImplementedUsingTechnology`, and to specify who implemented it 
>> - `dpv:isImplementedByEntity`.
>>
>> The personal data, data subjects, processing, and other details can be 
>> grouped using `dpv:PersonalDataHandling` to indicate separation, such 
>> as for jurisdictions affected, or technologies affected. The 
>> granularity of this information is unbound as the 'graph' of what was 
>> affected can be as large or small as required. From the reporting 
>> forms, in most cases it is sufficient to indicate the abstract or 
>> summary information at this stage.
>>
>> To indicate risks we have `dpv:hasRisk`, for consequence we have 
>> `dpv:hasConsequence`, and for impact we have `dpv:hasImpact` - and 
>> their affected entity variants. These can be specified directly, or 
>> through an impact assessment represented by 
>> `dpv:DataBreachImpactAssessment` and `dpv:hasImpactAssessment`. Note 
>> that the concept of impact assessment here refers to impact on or for 
>> data subjects - the internal assessment of impact (e.g. loss of 
>> business) is not part of this impact assessment and could be 
>> represented separately through a risk assessment.
>>
>> The data breach reporting requires explicitly indicating whether there 
>> will be an impact to fundamental rights - most commonly as a Yes / No 
>> option. To indicate this, we need the concept 
>> `risk:ImpactOnFundamentalRights` in the risk vocabulary, which is 
>> expressed using `dpv:hasImpact`. To express whether this will take 
>> place or not, the `risk:hasLikelihood` should be used. I do not think 
>> there can ever be a likelihood of 0 - so the lowest value is extremely 
>> unlikely, which is 0.1 (or something akin to it). If this information 
>> is not available, then `dpv:NotAvailale` should be used.
>>
>> Data breach reporting requires information on what technical and 
>> organisational measures were in place before the breach, deficiencies 
>> identified, and any changes or additional measures taken to address 
>> the breach. To specify the affected TOMs, we have 
>> `dpv:hasTechincalMeasure` and `dpv:hasOrganisationalMeasure`. To 
>> specify limitations or failure, we have `risk:hasVulnerability` which 
>> together with `dpv:isMitigatedByMeasure` and 
>> `db:DataBreachMitigationMeasure` indicates that the data breach has 
>> been addressed.
>>
>> Examples:
>>
>> ex:IncidentReport3A a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "services/processes affected by the breach" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasDataSource ex:Processor ; # breach was reported by a 
>> Processor
>>      dpv:hasNotice ex:ReportedBreachToAuthority ; # breach reported to 
>> DPA
>>      dpv:hasConsequenceOn ex:ServiceA, ex:PDH9 ; # services affected
>>      dpv:hasConsequenceOn db:NotAvailale ; # further consequences not 
>> known yet
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>>
>> ex:IncidentReport3B a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "data, subjects, processing, technologies affected" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasPersonalData dpv:SpecialCategoryPersonalData ; # special 
>> category
>>      dpv:hasDataVolume dpv:HugeDataVolume ;
>>      dpv:hasDataSubject dpv:VulnerableDataSubject ; # vulnerable 
>> subjects;
>>      dpv:hasDataSubjectScale dpv:LargeScaleOfDataSubjects ;
>>      dpv:hasProcessing dpv:Store ;
>>      dpv:hasProcessingScale dpv:LargeScaleProcessing ;
>>      dpv:hasJurisdiction legal:IE, legal:FR, legal:DE ;
>>      dpv:isImplementedUsingTechnology ex:Software ;
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>>
>> ex:IncidentReport3C a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "indicating jurisdiction of data subjects and 
>> processing" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasPersonalData [
>>          rdfs:subClassOf dpv:SpecialCategoryPersonalData ;
>>          dpv:hasDataVolume dpv:HugeDataVolume ;
>>          dpv:hasDataVolume "300000" ; # records affected
>>          ] .
>>      dpv:hasDataSubject [
>>          rdfs:subClassOf dpv:VulnerableDataSubject ;
>>          dpv:hasJurisdiction legal:IE, legal:FR, legal:DE ;
>>          dpv:hasDataSubjectScale dpv:LargeScaleOfDataSubjects ;
>>          dpv:hasDataSubjectScale "300000" ; # people affected
>>          ] .
>>      dpv:hasProcessing [
>>          rdf:type dpv:Store ;
>>          dpv:hasJurisdiction legal:IE, legal:FR, legal:DE ;
>>          dpv:hasProcessingScale dpv:LargeScaleProcessing ;
>>          ] .
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>>
>> ex:IncidentReport3D a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "grouping using personal data handling" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasPersonalDataHandling [
>>          a dpv:PersonalDataHandling ;
>>          dpv:hasService ex:ServiceA ;
>>          dpv:hasPersonalData dpv:SpecialCategoryPersonalData ;
>>          dpv:hasDataVolume dpv:HugeDataVolume ;
>>          dpv:hasDataVolume "300000" ;
>>          dpv:hasDataSubject dpv:VulnerableDataSubject ;
>>          dpv:hasJurisdiction legal:IE, legal:FR, legal:DE ;
>>          dpv:hasDataSubjectScale dpv:LargeScaleOfDataSubjects ;
>>          dpv:hasDataSubjectScale "300000" ;
>>          dpv:hasProcessing dpv:Store ;
>>          dpv:hasProcessingScale dpv:LargeScaleProcessing ;
>>          dpv:isImplementedByEntity ex:Processor ;
>>          ] ;
>>      dpv:hasPersonalDataHandling [
>>          a dpv:PersonalDataHandling ;
>>          dpv:hasService ex:ServiceB ;
>>          dpv:hasPersonalData dpv:Email ;
>>          dpv:hasDataVolume dpv:SmallDataVolume ;
>>          dpv:hasDataSubject dpv:User ;
>>          dpv:hasDataSubjectScale dpv:SmallDataSubjectScale ;
>>          dpv:isImplementedByEntity ex:Controller ;
>>          ] ;
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>>
>> ex:IncidentReport3E a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "indicating risks and impacts" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasRisk [
>>          rdf:type risk:RiskToFundamentalRights ;
>>          dpv:hasLikelihood risk:ExtremelyLowLikelihood ;
>>          ] ;
>>      dpv:hasImpactAssessment ex:SomeImpactAssessment ;
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>>
>> ex:IncidentReport3F a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "indicating risks and impacts separately for groups" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasPersonalDataHandling [
>>          a dpv:PersonalDataHandling ;
>>          dpv:hasService ex:ServiceA ;
>>          dpv:hasPersonalData dpv:SpecialCategoryPersonalData ;
>>          dpv:hasDataSubject dpv:VulnerableDataSubject ;
>>          dpv:hasRisk [
>>              rdf:type risk:RiskToFundamentalRights ;
>>              dpv:hasLikelihood risk:HighLikelihood ;
>>              ] ;
>>          dpv:hasImpactAssessment ex:SomeImpactAssessment ;
>>          ] ;
>>      dpv:hasPersonalDataHandling [
>>          a dpv:PersonalDataHandling ;
>>          dpv:hasService ex:ServiceB ;
>>          dpv:hasPersonalData dpv:Email ;
>>          dpv:hasDataVolume dpv:SmallDataVolume ;
>>          dpv:hasRisk [
>>              rdf:type risk:RiskToFundamentalRights ;
>>              dpv:hasLikelihood risk:ExtremelyLowLikelihood ;
>>              ] ;
>>          dpv:hasImpactAssessment ex:SomeImpactAssessment ;
>>          ] ;
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>>
>> ex:IncidentReport3G a db:DataBreachPreliminaryReport ;
>>      rdfs:comment "indicating measures taken in response to the breach" ;
>>      dct:subject ex:Incident1A ; # which data breach this report 
>> refers to
>>      dct:created "2023-05-26T14:38:00" ; # when this report was created
>>      dct:creator ex:CompanyAlpha ; # who created the report
>>      dpv:hasTechincalMeasure [
>>          a dpv:PasswordAuthentication ;
>>          risk:hasVulnerability ex:WeakAuthentication ;
>>      ] ;
>>      dpv:hasTechincalMeasure [
>>          a dpv:CryptographicAuthentication, 
>> db:DataBreachMitigationMeasure ;
>>          risk:mitigatesVulnerability ex:WeakAuthentication ;
>>      ] ;
>>      dpv:hasOrganisationalMeasure [
>>          a dpv:Training, db:DataBreachMitigationMeasure ;
>>          risk:mitigatesRiskSource ex:LackOfSecurityTraining ;
>>      ] ;
>>      dpv:hasActivityStatus dpv:ActivityCompleted . # status of report
>> ex:DataBreach a dpv:Risk ;
>>      risk:hasRiskSource ex:LackOfSecurityTraining .
>> ex:LackOfSecurityTraining a risk:RiskSource ;
>>      risk:hasVulnerability ex:WeakAuthentication .
>> ex:WeakAuthentication a risk:Vulnerability ;
>>      risk:isVulnerabilityOf ex:Software .
>>
>> -- Data Breach Notifications --
>>
>> The earlier example showed messages being passed to inform about data 
>> breaches, for examples from processor to controller, and from 
>> controller to the DPA. The message contents are expected to be 
>> accompanied with a report of appropriate form, e.g. for detection, 
>> preliminary or final investigation - containing the impact assessment. 
>> Other than these, there is also a notification to the data subjects 
>> that must be represented. This is also done using the same concepts.
>>
>> Communications to authorities are represented using 
>> `db:AuthorityDataBreachNotice`. Those from processors to controllers 
>> (or other processors) are represented using 
>> `db:ProcessorDataBreachNotice`. Those coming from controllers (to 
>> authority or other controllers) are represented using 
>> `db:ControllerDataBreachNotice`.
>>
>> The difference in notifications to the data subjects is that there may 
>> be actions to be taken, for example to safeguard themselves against 
>> adverse impacts. To represent these, the concept 
>> `db:DataSubjectBreachNotice` is to be used. To indicate actions to be 
>> taken by the data subjects, the simplest representation would be to 
>> indicate `dpv:hasRisk` or `dpv:hasImpact`, along with `dpv:Likelihood` 
>> and `dpv:Severity`, and then using `dpv:isMitigatedByMeasure` to 
>> indicate what can be done. To indicate the medium of the notification, 
>> `dct:medium` should be used. Other DCMI concepts such as `dct:format`, 
>> `dct:instructionalMethod`, `dct:language` can also be used.
>>
>> To indicate whether some notifications are being planned, are ongoing, 
>> or have been completed - `dpv:ActivityStatus` can be used.
>>
>> Examples:
>>
>> ex:ProcessorReportsBreach a db:ProcessorDataBreachNotice, 
>> schema:Message ;
>>      rdfs:comment "Processor to Controller" ;
>>      dct:subject ex:Incident1A ;
>>      schema:dateReceived "2023-05-24" ; # when the message was sent
>>      schema:sender ex:Processor ; # who sent it
>>      schema:recipient ex:Controller ; # who received it
>>      schema:messageAttachment <report.pdf> . # what were the contents
>>
>> ex:ControllerReportsBreach a db:AuthorityDataBreachNotice, 
>> schema:Message ;
>>      rdfs:comment "Controller to Authority" ;
>>      dct:subject ex:Incident1A ;
>>      schema:dateSent "2023-05-24" ; # when the message was sent
>>      schema:sender ex:Controller ; # who sent it
>>      schema:recipient ex:DPA-IE ; # who received it
>>      schema:messageAttachment <report.pdf> . # what were the contents
>>
>> ex:DataSubjectNotified a db:AuthorityDataBreachNotice, schema:Message ;
>>      rdfs:comment "Controller to Data Subjects" ;
>>      dct:subject ex:Incident1A ; # can provide all or some info about 
>> breach
>>      schema:dateSent "2023-05-24" ; # when the message was sent
>>      dct:temporal "<start>/<end>" ; # period in which the messages 
>> were sent
>>      schema:sender ex:Controller ; # who sent it
>>      schema:recipient dpv:User ; # all users received this
>>      schema:recipient db:BreachedDataSubjects ; # only breach affected 
>> subjects
>>      dct:medium "website", "public announcement" ; # notifications 
>> provided
>>
>>      dpv:hasPersonalData pd:Email ; # what data has been breached
>>      dpv:hasImpact [
>>          a risk:Fraud ;
>>          risk:hasLikelihood risk:HighLikelihood ;
>>          dpv:isMitigatedByMeasure "check email authenticity" ;
>>          dct:instructionalMethod "link to educate about emails" ;
>>      ]
>>      dpv:hasActivityStatus dpv:ActivityProposed ;
>>      schema:messageAttachment <report.pdf> . # what were the contents
>>
>> -- Organisation Details --
>>
>> Reporting a breach requires information about the organisation. The 
>> DPC form asks for name (`dpv:hasName`), address (`dpv:hasAddress`), 
>> whether there are EU/EEA establishments, sector (Public, Private, 
>> Charity, Voluntary), sub-sector (NACE taxonomy), and internal ID for 
>> breach. Of these, the internal breach ID should be specified using 
>> `db:DataBreachIdentifier` and `dct:publisher` as indicated earlier.
>>
>> Of the rest, sector (e.g. public) is represented as a type of 
>> organisation (`dpv:PublicOrganisation`). The sub-sector is represented 
>> using `dpv:hasSector` and the NACE code. For EU/EEA establishments, we 
>> add the concept `dpv:Establishment` and use this along with 
>> `dpv:isMainEstablishmentFor` to indicate the jurisdiction, or use 
>> `dpv:isEstablishmentOf` to indicate parent company. To indicate the 
>> Processor, use `dpv:hasDataProcessor`.
>>
>> Examples:
>>
>> ex:Controller a dpv:DataController ;
>>      a dpv:PrivateOrganisation ;
>>      dpv:hasSector "<NACE>" ;
>>      dpv:hasDataProcessor ex:Processor ;
>>      dpv:isEstablishmentOf ex:ParentController ;
>>      dpv:isMainEstablishmentFor legal:FR . # France
>> ex:ParentController a dpv:DataController ;
>>      a dpv:PrivateOrganisation ;
>>      dpv:hasEstablishment ex:Controller ;
>>      dpv:isMainEstablishmentFor legal:EU .
>>
>> -- Next Steps --
>>
>> Go through the data breach concepts again - see if there is anything 
>> unclear or missing. If so - fix that. If not, proceed to create some 
>> examples based on well-known or well-studied cases to ensure that the 
>> above structure and proposal works. The concepts about Risk and 
>> Vulnerability seem somewhat unclear - that is because they have not 
>> been added yet. Based on whether they work in the above context - we 
>> will either add or refine them.
>>
>> Regards,
>> Harsh
>>
>> On 27/03/2023 12:55, Harshvardhan J. Pandit wrote:
>>> Hi. The below set of concepts are based on analysis by myself and 
>>> Georg, and what we have been discussing in the group so far.
>>
> 

-- 
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/

Received on Tuesday, 4 July 2023 07:41:29 UTC