GDPR Compliance - notification of data breach In Art. 33, the GDPR specifies that a controller must notify a personal data breach to the supervisory authority after having become aware of it. 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. 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. In this case, does the controller need to notify the supervisory authority? Even if there is no evidence of a breach? 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. 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?
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.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. 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. 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. 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. 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. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload 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.
How can I truly say that I 'consent' to data collection and processing when I am coerced, so to speak, by the threat of failing my courses if I do not use this novel software? There is no need for you to "consent". Consent is just one of the reasons that allows a data processor to collect your data. There are other reasons that allows the data processor to capture your data. In this case, it seems of application the "legitimate interest clause", as it is in your university's legitimate interest to capture your activity in order to evaluate you. Of course, that covers only the data collected that is relevant to that interest. They will certainly capture your identity and your answers, they may log your sessions and may try to gather some data to detect if you are somehow cheating, but they would not be allowed to check which are your favorite pornhub videos because that is not relevant for the university's legitimate interest. Art. 6 of the GDPR states: Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. This page also provides some in-depth analysis
According to my knowledge I am not allowed to share other people's full name nor phone number nor email address without their permission. That is not correct. According to GDPR Article 2: This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. This Regulation does not apply to the processing of personal data ... ... (c) by a natural person in the course of a purely personal or household activity; GDPR Recital 18 states in relevant part: (2) Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. Personal data that is not processed by &quot;automated means&quot;, for example data which is transmitted verbally, by hand writing, or by manually sent email, is not covered by the GDPR. Data which is used by a natural person for &quot;personal activities&quot; is also not covered. Consulting one's personal lawyer might well be a personal activity unless it is a business matter. Even if such a transfer of data were in scope for the GDPR, consent of the data subject (DS) is not the only available lawful basis. GDPR article 6 permits any of several possible lawful bases to be used, particularly paragraph 1 point (f) which reads: (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Also possibly relevant is point (c) which reads: processing is necessary for compliance with a legal obligation to which the controller is subject; In short, providing one's personal lawyer with the names and addresses of relevant people in connection with a legal issue is not at all likely to be prohibited by the GDPR, nor to require the consent of the people whose names and contact info are provided. However, a comment by user PMF reads: The Data Protection laws are mostly for companies, not for individuals. This is an overstatement. The laws do apply to natural persons as DCs, although enforcement is largely targeted at businesses, particularly large, for-profit businesses.
There is no requirement about "data" in the GDPR, so provided this is just "data", no. An empty form with fields for personal data contains no personal data. On the other hand, if the form is filled in by the user with personal data (as defined in GDPR article 4), and you receive a copy of the filled in form and process these personal data (as defined in GDPR article 4) - then the answer is: Yes. However, if you do not process the personal data (i.e. the form is just printed out on paper and filled in with a pen, and nobody except the data subject has access to the piece of paper with the filled in form - then the answer again is "no").
As @gnasher729 has commented, "a merely hashed password database is criminally insecure. Salted + hashed is the standard, and protecting your database is also required." GDPR Paragraph 78 says (inter alia) In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Hash without salt is hardly good design.
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
Art.5(1)(f) contains: Personal data shall be: (f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’). Art. 25 and Art. 32 also contain similar requirements. What is appropriate has to be determined, as the GDPR does not contain an exact definition. However as processor you don't have to worry about that, as Art.5(2) Contains: The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’). But you need to inform the controller if you think an instruction violates the GDPR. But it is up to the controller to decide what to do. Art. 28(3) requires a contract between controller and processor which requires the processor to: (...) that the processor: (c) takes all measures required pursuant to Article 32; (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions. But again, the controller is responsible for this contract.