- From: Harshvardhan Pandit <me@harshp.com>
- Date: Fri, 16 Jun 2023 21:14:37 -0500
- To: "public-dpvcg@w3.org" <public-dpvcg@w3.org>
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 Saturday, 17 June 2023 02:14:46 UTC