GDPR Compliance - notification of data breach
<p>In Art. 33, the GDPR specifies that a controller must notify a personal data breach to the supervisory authority <strong>after having become aware of it</strong>.</p>

<p>Case 1: A database dump with personal data is hosted for a period of time on a server that is accessible from the internet. The file can be downloaded without authentication from anyone knowing the url.<br>
The controller has no evidence of someone downloading the file because the web server hosting the file keeps no logs, or not all logs for the full period of time that file was available for download are kept on the server because they get automatically rotated.</p>

<p>In this case, does the controller need to notify the supervisory authority? Even if there is no evidence of a breach?</p>

<p>Case 2: say a web application available from the internet grants access to some users to sensitive personal data. This is the primary use case for this web app. The website uses https to encrypt data in transit. For some configuration error on the web server, https gets disabled and all traffic to this website is in clear for a period of time.</p>

<p>In this second case, does the controller need to notify the supervisory authority? Even if there is no evidence of a breach because no man in the middle attack was detected?</p>

<p>The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.”</p>

<p>In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed.</p>

<p>This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened.</p>

<p>The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant.</p>

<p>If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies.</p>

<p>In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here.</p>

<p>As a technical remark, simply <em>offering</em> HTTPS is not sufficient to prevent MitM attacks – users must be <em>forced</em> to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here <a href="https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security" rel="noreferrer">HSTS and HSTS preload</a> would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.</p>

gdpr