This document provides guidance for representing information associated with data breaches using the [[[DPV]]]. Such information includes details about the breach event, its detection, preliminary and subsequent investigations, notifications and communications, risk and impact assessments, and mitigations.

This document is published by the Data Privacy Vocabularies and Controls Community Group (DPVCG) as a deliverable and report of its work in creating and maintaining the Data Privacy Vocabulary (DPV).

Contributing to the DPV and its extensions The DPVCG welcomes participation regarding the DPV, including expansion or refinement of its terms, addressing open issues, and welcomes suggestions on their resolution or mitigation. For further information, please see the contribution section.

Introduction

A data breach is an event and has temporal and causal properties to indicate when and why it took place. Some of this information may or may not be known - for example, when a breach is first detected the start and end times may be unknown, with subsequent investigations identifying this information. In addition, information may not be accurate or may be incorrect - for example, a preliminary investigation may state that the affected data was encrypted whereas subsequent investigation may discover that it was unencrypted. Therefore, the information about a breach continues to change as the investigations progress.

How the changes themselves should be recorded is outside the scope of this guidance since it relates to the organisation's governance practices. For example, the organisation may keep a single record of the data breach and update it as new information is available, or alternatively the organisation may create distinct records of the data breach to represent discrete information available at different stages of investigation. Similarly, the investigation of a breach's impact is also separate to the analysis of the cause of the breach and may be carried out at various points based on the availability of information. For example, availability of new information may trigger an additional requirement to conduct an impact assessment based on the perceived changes in risk and consequences.

This guide therefore is limited to the following information about data breaches:

  1. Information about the Data Breach itself i.e. when did it occur, who was the cause, etc.
  2. Investigation of the Data Breach i.e. report specifying when it was detected, what has been affected, who has it been reported to
  3. Notifications i.e. communication about the breach between entities, e.g. Controller to DPA
  4. Impact Assessment that assesses the risks and impacts (to data subjects) based on available information
  5. Breach Mitigation assessment which identifies the causes of the breach and specifies what changes were made to prevent further breaches or mitigate consequences of existing breach
  6. Details about the involved organisation, including establishments and lead authorities for handling the data breach.
  7. Provide requirements and obligations related to GDPR in the above information.

While the [[DPV]] and this guide are written in a jurisdiction agnostic manner, it is heavily based on the [[GDPR]] and [[NIS2]] definitions and requirements regarding data breaches and incidents. Where relevant, GDPR and NIS2 specific information and requirements are provided separately within the respective sections.

The following sources were used in the development of this document:

DataBreachHandlingProcedure to add to Organisational Measures.

The following namespaces are used throughout this document:

prefixURI
base (default) https://w3id.org/dpv/databreach#
dpv https://w3id.org/dpv#
dpv-gdpr https://w3id.org/dpv/dpv-gdpr#
risk https://w3id.org/dpv/risk#
dct http://purl.org/dc/terms/
ex https://example.com/

Data Breach Lifecycle

A data breach incident starts from when a breach is suspected or detected, and ends with a final report detailing all impacts and mitigation measures taken in connection with it. In addition to these, organisational processes may involve unclear or ambiguous information, for example - where sufficient information is not available to state whether a breach exists, or where a breach is suspected but not yet confirmed.

Between the suspicion or detection of a breach and the end of handling it, there are various stages that correlate with: the availability of information, carrying out investigations based on available information, communicating with other entities such as authorities and data subjects in connection with the breach, and carrying out assessments as part of investigations regarding risk management and impacts on data subjects. Each of these stages may require record-keeping and documentation outlining the facts at that point in time.

To represent these stages and their associated information, the following are the lifecycle stages as modelled within the [[RISK]] extension regarding incidents and data breaches:

  1. Suspected: a data breach is suspected. This stage typically represents processes to discover the validity of this suspicion to confirm a breach detection. It may optionally involve recording the suspicion and communicating it to relevant entities e.g. to the service provider if the suspected breach is for its service.
  2. Detected: a data breach has been detected. This stage is followed by processes to determine whether the breach has concluded or is ongoing, and to ascertain the cause, nature, and effect of the breach. It requires recording the detection, and may involve communication to relevant entities e.g. to the Data Protection Authority within 72 hours as per GDPR.
  3. Ongoing: a data breach has been detected and is currently ongoing or is in progress. This stage should have processes already underway to investigate and ascertain mitigations to stop the breach as well as recover from its impacts. Typically, there are no separate records for an ongoing breach, and there may optionally be communications associated with it e.g. to the Data Protection Authority with an update of the situation, or to the Data Subjects with measures to protect against the breach impacts.
  4. Halted: a data breach has stopped but has a likelihood of being resumed i.e. it cannot be said with certainty that the breach is 'over' or has 'concluded'. There may be records to note the breach halting. A process may be undertaken at this stage to determine whether the breach has merely halted or has concluded, and the possibility of using mitigation measures to ensure the breach does not occur again.
  5. Concluded: a data breach has stopped of its own accord and does not have a likelihood of being resumed. This typically represents the 'end' of the breach, and there may be processed to identify the root causes and mitigation measures to ensure it does not occur again, as well as to 'recover' from the breach. This stage is recorded and will have documentation to note the stopping of the breach.
  6. Terminated: a data breach has been stopped through mitigation measures and does not have a likelihood of being resumed. This typically represents the 'end' of the breach, and may have processes to 'recover' from the breach. This stage is recorded and will have documentation to note the stopping of the breach.
  7. Mitigated: the data breach has been prevented from recurring again through the use of mitigation measures. been concluded, and all activities that need to be carried out have been carried out. This is the final activity which represents a cessation of the breach handling process. This stage is recorded and will have documentation to note the stopping of the breach.

In the above, the breach incident is separated from its investigation or 'breach handling process', which can occur at any stage depending on when the breach has been detected as well as the effectiveness of the response to it. Based on the breach, the following documented reports are typically expected by the [[GDPR]] and [[NIS2]] in connection with a data breach and are used to communicate the breach to entities e.g. to authorities.

  1. Incident Suspected Report: A report documenting an incident being suspected.
  2. Incident Detection Report: A report documenting an incident being detected. The report may have information missing regarding the breach, for example whether the breach is still ongoing or what personal data or data subjects have been affected. Under GDPR, this report provides documentation for when the data breach was detected and it essential for the notification to an authority within 72 hours.
  3. Incident Assessment Report: A report documenting an assessment of an incident in terms of affected personal data, data subjects, systems, and processes. It can be undertaken or revised as new information is made available or to document the assessment in a specific context. For the GDPR, a Data Breach Impact Assessment (DBIA) is a specific type of incident assessment that provides information the impacts of the breach on data subject's rights and freedoms.
  4. Incident Handling Report: A report documenting the handling or response to an incident. It includes details of what steps the organisation has taken to halt, terminate, or mitigate the incident, as well as to recover from its effects.
  5. Incident Preliminary Report: A report documenting an incident investigation is in its preliminary stage, typically sent to an authority such as to notify the breach within 72 hours under the GDPR.
  6. Incident Ongoing Report: A report documenting an incident or its handling as being in progress or ongoing, typically sent to an authority as a follow-up to the preliminary report to update them on the status of the data breach and its effects.
  7. Incident Concluding Report: A report documenting indicating the conclusion of an incident investigation and handling. It represents the 'end' of the incident handling process and is relevant both to the organisation for its records-keeping as well as in communications to authorities. It typically has a completed assessment in terms of impacts (on organisation as well as data subjects) and its handling (i.e. response, recovery, mitigation).

In the process of handling a data breach, various information will be communicated - for example to notify the authority or controller about a breach detection, or to indicate to data subjects how they should safeguard themselves. Such communications are termed as Data Breach Notices based on the relevant phrase Data Breach Notification. Categories of notifications communicated throughout the lifecycle of the breach are as below.

  1. Notice from Processor: a processor informing another processor or controller about a breach
  2. Notice from Controller: a controller informing a processor or another controller about a breach
  3. Notice to Authority: informing an authority about the breach
  4. Notice to Data Subjects: notice sent to data subjects informing them about a breach

The structure and form of information within notices varies based on the actors involved and the availability of information to them. For example, notices sent between Processors and Controllers have differences in terms of the information they communicate and its use in assessments. The processor's data breach assessment may be unaware about the exact nature of data or the extent of data subjects affected, which also limits the identification of impacts. Similarly, notices sent to the data subjects do not have detailed assessments about the breach, but instead will only provide a subset of the total information, and will typically include contextual information such as what measures the data subjects should take in order to safeguard themselves.

Data Breach Event

The concept risk:DataBreach represents the event of a data breach. It is a subtype of dpv:Risk to denote the common use and reference of referring to "risk of data breach". This allows risk assessment and management concepts to be applied to data breaches, and to associate consequences and impacts arising from it.

The temporal properties associated with a breach include its occurrence i.e. when the breach started and ended - as its duration. This is indicated using the relation dct:temporal to specify the start (if known) and end (if known). If both are not available, then dpv:NotAvailable is used as the value. There can be more than one duration for the same breach, for example to represent three different non-continuous events considered a part of a single data breach incident. Whether to represent this as a single or three different breaches is a contextual choice and decision. For example, where the three events accessed different data or systems or need different mitigation measures - it may be sensible to treat them as separate breaches.

The concepts for representing risk assessment in the context of data breach is currently being discussed. Its outcomes need to be integrated in this document in terms of the specified concepts and their usage in examples.

The 'source' of a breach is the event which led to the breach taking place. It is represented using the concept dpv:RiskSource and associated with the breach using dpv:hasRiskSource relation. An example of a source of data breach is where an employee left their office computer unattended without locking it. The lack of security in securing office machines is a vulnerability, represented using the concept risk:Vulnerability and associated using the relation risk:hasVulnerability. Vulnerabilities represent a weakness or limitation that was exploited in order to create the risk source event which then leads to the data breach. Vulnerabilities are not necessary for a risk source to realise, for example an accident can occur without a vulnerability.

The 'cause' of a breach is the actor or agent that caused the breach to take place through intentional or unintentional means, and regardless of malicious intent or accidents. It is represented by risk:ThreatActor and associated using risk:hasThreatActor In the above case of an unattended office computer, the threat actor is whomever accessed the system after the employee left - this could be another employee, a cleaner, or an external person entering the premises. 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 considered a data breach regardless of whether anyone actually accesses the data on 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 and associated using dpv:hasStatus. The following statuses are defined to represent commonly encountered stages:

In these statuses, the use of 'halted' refers to a breach being stopped but with uncertainty regarding it being resumed - where if it resumes the 'ongoing' status is applicable again. The status 'concluded' refers to situations where the breach has stopped without active effort from the breached entity, whereas 'terminated' means the actions of the breached entity have caused it to be stopped, and 'mitigated' means it has also been prevented from happening again. These distinctions are relevant as the measures used in termination can be found ineffective, or may be effective only for a short duration or in limited cases, whereas the concluded breach has no mitigation associated with it being stopped - and hence there is a risk of the breach happening again. Mitigated is distinct from these as it also refers to future breaches of the same type being prevented from occurring. The measures used to stop an ongoing breach (termination) may be distinct from those used to prevent it in the future (mitigation).

The 'type' of a data breach refers to categorisation based on the effect of the breach on the affected data. The Data Protection Authorities suggest three categories - 'confidentiality breach' where there is unauthorised or accidental disclosure of or access to data; 'integrity breach' where there is unauthorised or accidental alteration or modification of data; and 'availability breach' where there is unauthorised or accidental loss of access or loss of data (e.g. via destruction or transformation). These explanations are simplified, and their origin is in the 'CIA model' used in information security to categorise incidents using these three categories. 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 occurring when someone else has access to data is only one of these definitions (confidentiality). The type of breach is indicated using rdf:type with values dpv-breach:ConfidentialityBreach, dpv-breach:AvailabilityBreach, and dpv-breach:IntegrityBreach - which are defined as subtype of dpv-breach:DataBreach. A single data breach incident can have one or more types i.e. these types are not mutually exclusive.

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 dpv-breach:DataBreachIdentifier is used and associated with using dpv:hasIdentifier. The distinct concept allows further categorisation of identifiers, and more importantly to distinguish who has provided which identifier, e.g. using dct:creator and dct:publisher.

Data Breach Reports

Reports about a data breach document information about the breach as well as its investigation and handling activities. They are represented by DataBreachReport, and are separated into types to represent detection of a breach and stage of investigation/breach handling - preliminary, ongoing, concluded. These are represented by DataBreachPreliminaryReport, DataBreachOngoingReport and DataBreachConcludingReport respectively. Reports can be embedded or linked to each other. For example, a single larger report as an instance of DataBreachReport can reference instances representing the different stages through dct:hasPart, for example to represent a comprehensive or grouped reporting of data breach when communicating with authorities.

Detection Report

A breach detection report is the documentation detailing specifies the reporting of a data breach being detected, along with any pertinent details about the detection itself. It is meant to be generated at specific points in time for record-keeping purposes, and to be communicated to other entities where needed for compliance purposes. The detection information is necessary to be separated from the information about a data breach (earlier section) to indicate contextual information - 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.

To represent the breach detection report, the concept dpv-breach:DataBreachDetectionReport is to be used. The usual DCMI properties are to 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 should be used to document details such as sender and recipient. To report on the status of detection (as a form of investigation), the existing dpv:ActivityStatus concepts should be used.

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 dpv-breach:DataBreachPreliminaryReport, which is a subclass of dpv-breach:DataBreachReport. As with dpv-breach: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.

To indicate what personal data has been affected, the relation dpv:hasPersonalData is to be used, with values of type dpv:PersonalData or its categories such as dpv:SpecialCategoryPersonalData. To indicate the scale of data, dpv:hasDataVolume is to be used. Qualifiers can reuse the existing DPV concepts, e.g. dpv:HugeDataVolume, and quantifiers where indicating the actual number of data records affected is necessary can directly specify the value or use an instance or subtype of dpv:DataVolume with rdf:value to denote the quantity.

To indicate data subjects affected, the relation dpv:hasDataSubject is to be used to denote the category of data data subjects, and the relation dpv:hasDataSubjectScale to be used to denote their scale. Similar to how Data Volume can be a qualifier or a quantifier, the scale of data subjects can be based on dpv:DataSubjectScale or a quantity.

To indicate processing activities, the relation dpv:hasProcessing is to be used to denote the specific types of processing taking place, and the relation dpv:hasProcessingScale is to be used to indicate its scale - with dpv:ProcessingScale or a quantifier to indicate number of data records. To indicate the geographic coverage, the relation dpv:hasJurisdiction is be used to indicate the affected jurisdictions. To only indicate locations without associating jurisdiction, the relation dpv:hasLocation can be used.

To indicate what technologies were involved, the relation dpv:isImplementedUsingTechnology is to be used, and to specify who implemented it the relation dpv:isImplementedByEntity is to be used.

In addition to scale of data, data subjects, and processing, the Data Protection Authorities also require reporting whether there is any cross-border context to the data breach including data subjects or processing activities in multiple jurisdictions. While this information can be derived from the values of dpv:hasJurisdiction, the concept CrossBorderDataBreach is provided as a subtype of DataBreach to explicitly indicate this information. Here, 'cross-border' can mean one or more of the following: data subjects from multiple jurisdictions are involved, processing (including storage and transfer) takes place in multiple jurisdictions, or the organisation is based on or operates in multiple jurisdictions. To distinguish between these, no further subtype are defined as, instead the information is to be represented directly in its appropriate context, e.g. through dpv:hasJurisdiction to directly indicate affected jurisdictions, or to indicate jurisdictions in connection with values of dpv:hasDataSubject, dpv:hasProcessing or dpv:ProcessingContext, and associating jurisdictions with an entity.

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 data breach reporting forms present on authority websites, in most cases it is sufficient to indicate the abstract or summary information at the preliminary stage.

To indicate risks the relation dpv:hasRisk is to be used, for consequence the relation dpv:hasConsequence is to be used, and for impact the relation dpv:hasImpact is to be used. The [[RISK]] extension provides taxonomies that can be used with these. The risks, consequences, and impacts can be specified directly in connection with the breach or the report, or through an impact assessment. The impact assessment associated with a data breach is represented by DataBreachImpactAssessment as a subtype of 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, the concept risk:ImpactOnFundamentalRights from [[RISK]] is to be used with the relation dpv:hasImpact. To express whether risks or impacts will materialise i.e. take place or not, the relation risk:hasLikelihood is to be used. Here, rather than specifying the likelihood as impossible or 0, it is better to specify the lowest value as as the likelihood being extremely unlikely - which in [[RISK]] is modelled as the value 0.01. If any information is not available, then dpv:NotAvailable should be used.

Data breach reporting also 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, the relations dpv:hasTechincalMeasure and dpv:hasOrganisationalMeasure are to be used. To specify their limitations or failures, the relation risk:hasVulnerability is to be used, with dpv:isMitigatedByMeasure and dpv-breach:DataBreachMitigationMeasure to indicate how the data breach has been addressed.

Data Breach Notifications

The earlier examples showed messages being passed to inform other entities 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, or containing the impact assessment. Other than these, the notifications to data subjects are also of a similar form but with different contents - where there may be information on steps to be taken for the data subjects to mitigate impacts.

To distinguish between these different types of communications, the following subtype of dpv:Notice are defined:

  1. AuthorityDataBreachNotice: A Notice sent to an Authority from a Processor or Controller or an Authority or Data Subject.
  2. ProcessorDataBreachNotice: A Notice sent to a Processor from another Processor or a Controller or an Authority.
  3. ControllerDataBreachNotice: A Notice sent to a Controller from a Processor or another Controller or an Authority.
  4. DataSubjectBreachNotice: A Notice sent to one or more Data Subjects from a Controller.

The contents of notices between Controllers, Processors, and Authorities will typically include information about the breach which are represented here as various reports. 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 indicate actions to be taken by the data subjects, the simplest representation would be to directly indicate dpv:hasRisk or dpv:hasImpact, along with dpv:Likelihood and dpv:Severity, and then using dpv:isMitigatedByMeasure to indicate what can be done.

Metadata about the notices, as forms of communication, is to be represented using the DCMI and Schema.org vocabularies. For example, to indicate the medium of the notification, dct:medium should be used, with dct:format, dct:instructionalMethod, and dct:language providing further information about the contents. Similarly, schema.org is to be used to denote the correspondence of notices as instances of schema:Message. This enables use of schema:dateSent and schema:dateReceived to indicate the timestamps associated with the notice, schema:sender and schema:recipient to record entities involved, and schema:messageAttachment to link to information or documents exchanged.

To indicate whether some notifications are being planned, are ongoing, or have been completed - dpv:ActivityStatus is to be used. This is relevant to indicate and differentiate between planned activities and those that have been completed - which is relevant for demonstration of legal obligations.

Organisation Details

Reporting a breach requires information about the organisation. This information should also be represented using the same vocabulary. For example, the Irish Data Protection Commission's data breach reporting form asks for name (dpv:hasName), address (dpv:hasAddress), whether there are EU/EEA establishments (see next para), sector (one of Public, Private, Charity, Voluntary - use entity types from DPV), sub-sector (using dpv:hasSector and the NACE taxonomy), and an internal ID for breach (using dpv:hasIdentifier with DataBreachIdentifier).

For EU/EEA establishments, DPV contains the concept dpv:Establishment which is to be used along with the relation dpv:isMainEstablishmentFor to indicate the main establishment for a given jurisdiction, and the relation dpv:isEstablishmentOf to indicate parent company.

Data Breach Impact Assessment

What is a DBIA?

A Data Breach Impact Assessment (DBIA) is similar to a Data Protection Impact Assessment (DPIA) in that it is undertaken to assess the risks and impacts to data subjects, where the DPIA is intended to address a planned process and the DBIA relates to a data breach that has taken place. A DBIA is essential in order to determine whether to notify authorities and data subjects regarding the breach, and to plan the necessary measures to handle the breach. If the DBIA indicates that the breach is likely to result in a risk to the rights and freedoms of individuals - then the authorities have to be notified. If the DBIA indicates a high risk to the rights and freedoms of individuals - then both the authorities and data subjects have to be notified.

A DBIA is based on the information available at a given time. Therefore, it can be undertaken at any stage in the Data Breach handling process - from preliminary where fewer information is known to final where all information is available. As such, the same DBIA (i.e. addressing the same data breach) can evolve over time in terms of its identified risks and impacts based on the corresponding changes in information.

To represent a DBIA, the concept DataBreachImpactAssessment is used. The DCMI metadata terms are available for annotating it with relevant information and descriptions (e.g. title, dates, provenance) as well as to associate it with a specific data breach using dct:subject.

Information in a DBIA

A Data Breach Impact Assessment (DBIA) typically contains the following information, which here is categorised into three distinct categories:

  1. Information about the Breach: Type of breach; Nature, sensitivity, and volume of personal data; Special characteristics of the individual; Special characteristics of the data controller; Number of affected individuals
  2. Risk Assessment: risks and impacts to rights and freedoms, their risk levels, likelihoods, and severity of consequences for individuals. Additionally also specific risks such as ease of identification of individuals or extent and ability to comprehend and reuse data.
  3. Outcomes: activities to be undertaken based on the assessment

The information about the breach in terms of what data or individuals have been affected is the same as that present in a Data Breach Report, and therefore can be included through a link to the report itself or explicitly added to the assessment in a manner similar to that of the report.

Information about the risk assessment includes the specifics of what risks are applicable, the consequences and impacts arising from it, their severity and likelihood, and the impacted stakeholders. In these, the specific risks and impacts to the rights and freedoms of individuals are an important consideration that must be present. Additionally, specific risks commonly associated with data breaches should also be mentioned. Such risks include (re-)identification of individuals through breached data e.g. because the data contained identifying information, or could be combined with other available data; or the risk of breached data not being safeguarded sufficiently (e.g. weak encryption) which could lead to its potential misuses.

Risk Assessment

A typical risk assessment undertaken for data breach incidents informs about risks associated with data (e.g. unauthorised access, restoration) and individuals (e.g. identifiability, harms). To represent these, we use [[[RISK]]] concepts. The following examples demonstrate risk assessments based on data breach incidents.

Examples

Impact on Rights and Freedoms

How to express risk to fundamental rights - present, not present

Examples

Mitigations and Residual Risks

How to show mitigations

Examples

Preventing Data Breaches

How to document that a data breach has been prevented - using risk assessment

Risk of data breach - mitigated by measure

Examples

Common causes of data breaches - guidance and mitigations

Examples

Data Breach Register

What is a Data Breach Register? Incident record. Why to maintain it? How to maintain it?

What information is present in a breach register?

How to record breaches? status? outcomes?

Examples