GDPR concerning IP logging by hosting company inside EU If I, located outside the EU, use a server of a hosting company, which is located in the EU (as well as their servers), for a simple website without any data collection, forms, cookies and the like, there are still the IP addresses of the visitors which are being processed (at least stored), e.g. for security and/or legal reasons. Now to my understanding I am the data controller of my website, and the hosting company is the data processor of the IP data of the visitors (they store it on their servers and might do some statistics, but I never touch this data). An EU paper on GDPR states the following (page 11, 12 of Guidelines 3/2018 on the territorial scope of the GDPR): The separate question then arises of whether the processor is processing in the context of its establishment in the Union. If so, the processor will be subject to GDPR processor obligations under Article 3(1). However, this does not cause the non-EU controller to become subject to the GDPR controller obligations. That is to say, a “non-EU” controller (as described above) will not become subject to the GDPR simply because it chooses to use a processor in the Union. Concerning the scenario above, is it sufficient to make sure that my hosting company in the EU fullfills GDPR, describe the setup (including a link to the hosting company's privacy policy) in my data policy, and point data requests to the hosting company?
It is in this context important to recall what a data controller and a data processor is. The data controller is the person or entity responsible for the data processing. They determine the purposes and means of this processing. A data processor merely performs data processing on the controller's behalf. The processor must not process data for their own purposes, but can make low-level decisions about the means of processing. For example, a controller may specify the purpose of ensuring the security and integrity of the services, or the purpose of creating basic statistics. The processor might implement this in part through the means of keeping a logfile. Often, such purposes are agreed upon via a data processing agreement or the terms of service, leading to the legal fiction that the processor was instructed by the controller. In your scenario, the controller is presumably not subject to the GDPR1, and therefore does not need a clear purpose or a legal basis for their processing activities. However, the EU-based data processor is bound by the GDPR, and can only process data as instructed by the controller. The processor has to comply with the GDPR with respect to how they carry out the processing activities, but the processing activities themselves don't have to be GDPR-compliant. Thus, it might be perfectly fine for an EU-based hosting provider to keep logfiles with IP addresses, even if those logfiles wouldn't be GDPR-compliant. 1: Whether GDPR applies to a non-EU data controller depends not on whether processing occurs in the EU, but on whether the controller is offering goods or services to people in the EU, or observing behaviour of people in the EU – see Art 3(2) GDPR. The cited guidelines continue to enumerate which provisions of the GDPR would still apply to EU processors working on behalf of non-EU data controllers (pages 12–13). These requirements are about how the controller and processor work together and relate to internal compliance of the data processor, but they do not affect the processing activities themselves. You mention that you would link to the hosting provider's privacy policy and direct data subject requests to the hoster. This misunderstands the role of the data processor. The data controller is the single point of contact for data subjects. The data processor is not a data controller in this scenario. They cannot issue a privacy policy for the controller's processing activities, and cannot respond to data subject requests. Their only relationship is with the data controller. If the hosting provider were to post a privacy policy for these processing activities, they would act like a controller (possibly a joint controller) and could bring the processing activities within scope of the GDPR – not what you are intending. However, since GDPR does not apply to the processing activities in this scenario, the data subject rights in the GDPR do not apply. As far as GDPR is concerned, no privacy policy is needed and no data subject requests have to be answered. If the data processor receives such requests, their only obligation is to forward them to the controller, who can then handle them (possibly ignoring them).
Art. 15(4) GDPR says: (4) The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others. If I was the controller in this situation, and I believed that this would endanger the students that have criticised the professor, I would base my argument for not complying on this. In addition, Art. 85 GDPR requires member states to: [...] reconcile the right to the protection of personal data pursuant to this Regulation with the right to freedom of expression and information [...] So you may be able to argue that the students posting messages are engaging in "processing for journalistic purposes and the purposes of academic, artistic or literary expression", depending on the laws of the particular member state. (edit: this could be difficult since you mention it is a private database). The second case seems just like the first in terms of GDPR, but may constitute defamation. Defamation (or libel) laws differ wildly in each country; he Wikipedia article on Defamation explains the situation in each member state in more detail. In the third case: if the professor submits a request based on the rights of a data subject other than himself, they don't need to comply. These requests need to come from the data subjects themselves, not just a random person assuming authority. (although I suppose it's possible for them to give power of attorney to the department head if they wanted to) Personal data and the rights that GDPR provides to data subjects always relate to a natural person, not an institution or a company.
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
There doesn't seem to be any legal requirement to show banners to announce the use of strictly necessary cookies ("functional cookies"). However, the GDPR's transparency principle requires you to disclose the purpose and legal basis for all processing of personal data. This could be done via a banner, but more commonly via a site-wide privacy policy. The GDPR requires such information to be provided at the latest at the time when personal data is collected. A layered disclosure approach could use banners to alert visitors to the privacy policy, but I'd want to avoid this to prevent confusion with non-compliant consent banners. Of course, GDPR only applies when the cookies are used for processing of personal data. Cookies are handled more specifically by the EU's ePrivacy directive, for which each country has it's own implementation. You should therefore check with local laws and guidance from your local data protection agency.
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).
Is there any sources of information where extraction of data from a closed source application and provided to a data subject is further defined? No, the GDPR is based on &quot;general principles&quot; and does not concern itself with implementation details for such matters. It's possible there's EU case law on this, but I can't find any. Am I within my rights to insist on this, even if to comply they would have to do some software development? Yes you can demand it, but they don't have to comply with your demand. The information only has to be provided in a &quot;concise, intelligible and easily accessible form, using clear and plain language.&quot; and they only have to provide the information electronically where &quot;reasonably practical&quot; to do so, and they only have to take &quot;reasonable steps&quot; to do all this per Section 52 of the Data Protection Act 2018 which implements GDPR into UK law. You can complain to the Information Commissioner's Office, and they will decide if Section 52 has been complied with or not. 52 Form of provision of information etc (1) The controller must take reasonable steps to ensure that any information that is required by this Chapter to be provided to the data subject is provided in a concise, intelligible and easily accessible form, using clear and plain language. (2) Subject to subsection (3), the information may be provided in any form, including electronic form. (3) Where information is provided in response to a request by the data subject under [the Right of access by the data subject], the controller must provide the information in the same form as the request where it is practicable to do so.
Backups and archived data are included within the scope of GDPR, simply because: (a) The scope of which data the regulation applies to is defined as: 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. (GDPR, Article 2(1): Material Scope, page 32) and (b) the exclusions listed in Article 2(2) do not mention anything about backups/archives (also on page 32). The new rules for most organisations will mean they need to review and possibly change how they operate their backup/restore procedures so that risks of data breach are managed and significantly reduced to a level which follows the data protection principles in Article 5(1) and so they can demonstrate compliance as required by Article 5(2): 1.Personal data shall be: (a) processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’); (b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’); (d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’); (e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’); (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’). 2.The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’). (GDPR, Article 5: Principles relating to processing of personal data, pages 35-36) Some practical tips to help with GDPR compliance: Rather than backing up everything in bulk as whole systems, organisations may find it easiest to separate systems backups and personal data backups so that systems backups can be kept for much longer retention periods than might be allowed/justifiable for the personal data. For larger organisations that have much more complex backup arrangements, much higher capacity backups and tape systems with archives that are kept offline, they may need to create a new backup strategy that will support the legal requirements of GDPR for ensuring 'erased' records are not retained any longer than necessary, and that older backups are replaced by newer backups so that stale/outdated personal data is not retained and rectified/amended records take effect in backups without delay. Organisations that have become used to keeping backups of everything forever will need to modify their practices and culture in order to comply with the 'what is necessary' and 'no longer than necessary' requirements by implementing a backup strategy that has defined retention periods for specific data sets or records as appropriate. If a stored backup is in a form which makes it very difficult to modify (e.g. a single record within a large database which spans numerous backup tapes) contained records which a data subject has requested be erased, then it may be considered reasonable if these records are erased upon every subsequent restore prior to processing of the data, until such time these records are not included in the backups. You'll need to keep a record of anyone that requests to be forgotten, and remember to follow-up to complete erasure at the appropriate dates if it can't be done immediately, and when the data is destroyed the data subject needs to be informed: The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. Where the data subject makes the request by electronic form means, the information shall be provided by electronic means where possible, unless otherwise requested by the data subject. If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy. (GDPR, Article 12(3-4): Transparent information, communication and modalities for the exercise of the rights of the data subject, page 40) Additionally to complicate things further, if any third party processors ('recipients') have had access to their data, you need to inform them too: The controller shall communicate any rectification or erasure of personal data or restriction of processing carried out in accordance with Article 16, Article 17(1) and Article 18 to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller shall inform the data subject about those recipients if the data subject requests it. (GDPR, Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing, page 45) In the event of a breach you may still need to notify data subjects that have requested to be forgotten! Obviously the backups would still need to be encrypted and subject to suitable protections, see Article 32 - Security of Processing (pages 51-52).
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").