The mandatory data breach notification requirement is one of the fundamental changes introduced under Europe’s new data protection regime, the GDPR. According to recent studies, almost 60,000 data breaches have been notified to the competent authorities since 25 May 2018 when the GDPR became applicable in the EU.  Data breaches may have various reasons and most of them do not result from deliberate cyber attacks.
You may think that security issues in the source code should just be considered a technology problem, and as a result, focus on mitigating steps. However, news on the most severe security breaches (such as Facebook, Uber and Equifax cases) highlights that undiscovered code vulnerabilities can cause massive data breaches. If a tech company discovers a potential vulnerability in its code that results in a notifiable data breach, the organization must also notify the competent authority within 72 hours of becoming aware of the breach, where feasible. In certain cases, communication to users may also be required.
The rules on data breach notification are quite complex and obviously not every security update triggers the notification requirement. In order to be able to meet the new data protection obligations, there are a few factors and considerations your security team should be aware of in relation to detected source code vulnerabilities.
First things first: Is personal data affected?
The GDPR defines a “personal data breach” as:
“ A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.” 
Accordingly, a data breach may affect the confidentiality, availability and/or integrity of personal data. As the Article29 Data Protection Working Party points out in its guideline  (the Guideline), a data breach is a type of security incident. The data protection rules only kick in if the security incident involves a breach of personal data. In order to find out if the GDPR applies, it is important to define the scope of the information that may have been affected by the incident. If it appears that the incident involves any information relating to an individual who can be directly or indirectly identified, you should also consider the rules of the GDPR in addition to patching the vulnerability. Make sure to involve your GDPR expert or DPO as soon as possible.
While source code insecurities may result in data breaches, not all security incidents are reportable. The GDPR requires the controller to notify the competent supervisory authority of a breach, unless it is unlikely to result in a risk of adverse effects.  An adverse effect can be, for example, loss of control over personal data, damage to reputation, discrimination, identity theft or fraud, as well as financial loss. Consequently, besides identifying the categories of information that may have been affected by the incident, it is also important to assess the potential risks that the vulnerability may bring about, and then notify the relevant authorities if necessary.
When is GDPR notification required?
Unfortunately, the GDPR does not provide a threshold for the severity of breaches. Also, none of the authorities have published an official assessment tool or detailed viewpoint with respect to source code vulnerabilities under the GDPR. However, the Guideline and the recommendations of national authorities provide for certain examples that may serve as a starting point when assessing an incident.
Let’s look at an example in the Guideline where a website hosting company detects an error in the code which controls user authorization for a website.
Without a doubt, if the company has any evidence in hand that suggests that the vulnerability has been exploited and that data has been unlawfully accessed by bad actors, this will be a notifiable breach involving probably high risks for data subjects. 
In addition, if a vulnerability is so obvious that anybody can have a look at the accounts of other users through a simple trick, there is a significant risk of unauthorized access. This could be a notifiable breach especially if the insecurity has existed for a long time and the company does not have a system for comprehensive logging.  In this case, it is not possible to determine whether access has happened or not.
On the other hand, if this happened for a short period of time, one could argue that the likelihood of unauthorized access is very limited. If your company stores detailed logs of user access and nothing suggests that the vulnerability has been exploited, then the guidelines suggest that the incident may not be a notifiable breach. 
Documentation is key
Assuming that you are lucky enough to have found an insecurity before external parties or hackers do, or you come to the conclusion that the potential risk of personal data being affected by the vulnerability is very low, you might not need to notify the data protection authority.
Even in such cases, however, it is not enough to simply release the relevant patch. Incidents must always be documented. As part of the accountability requirement under the GDPR, you must keep records of potential data breaches regardless of whether you are required to notify the authorities or not.
Failing to notify them when required or to document a breach can result in a significant fine; up to 10 million euros or 2 per cent of your global turnover. Undoubtedly, it is important to make sure you have a process in place to ensure you detect vulnerabilities and where necessary, notify the authorities of a breach on time, as well as record the necessary details.
The information above is for informational purposes only and does not constitute legal advice. To obtain advice with respect to a particular issue, you should contact your attorney.
 DLA Piper GDPR data breach survey: https://www.dlapiper.com/en/uk/insights/publications/2019/01/gdpr-data-breach-survey/
 Article 33 of the GDPR
 Guidelines on Personal data breach notification under Regulation 2016/679 (Adopted on 3 October 2017 and last Revised and Adopted on 6 February 2018)
 Article 33 of the GDPR
 See example ii) of the Guideline
 The ICO suggests this apporach according to its webinar on Data Breach Reporting (19 July 2019): https://ico.org.uk/about-the-ico/news-and-events/events-and-webinars/data-breach-reporting-webinar/
 See example vii) of the Guideline