How far up the chain of internet provision does my GDPR responsibility go? Say I host a web page on my computer, and you visit that site from somewhere in Europe. The web server on my computer will know your IP address, and I can choose to &quot;forget&quot; it as soon as the request is completed (eg. pipe apache logging to /dev/null) or keep them and abide by the GDPR such as responding to SAR's. However there are a number of entities involved in the process that may, and probably do, keep logs of the transaction. These entities will include my ISP, BT (who provide the to house infrastructure), some number of backbone companies, and your ISP. I cannot access these logs, and given that I think it is a legal requirement to keep logs I think I cannot avoid such logging by choosing a different ISP. How much of this logging am I responsible for under the GDPR?
You are only responsible for the data that you collect or process, or data that you direct others to collect or process on your behalf. You are not responsible for the actions of third parties that may carry out incidental collection or processing that you have no control over - this includes such things as your ISP, backbone providers etc, but if you direct a service provider (eg Cloudflare, Amazon AWS etc) to cache your content and process it on your behalf then you need to include that fact in your data processing policy and link to the providers own data processing policy.
The "Contribution activity" is extracted from repositories hosted on Github. Looking at the privacy statement, Github considers itself as a hosting service for those repositories. See EU Directive 2000/31/EC Article 14 for the exact definition and conditions: Article 14 Hosting Where an information society service is provided that consists of the storage of information provided by a recipient of the service, Member States shall ensure that the service provider is not liable for the information stored at the request of a recipient of the service, on condition that: (a) the provider does not have actual knowledge of illegal activity or information and, as regards claims for damages, is not aware of facts or circumstances from which the illegal activity or information is apparent; or (b) the provider, upon obtaining such knowledge or awareness, acts expeditiously to remove or to disable access to the information. Paragraph 1 shall not apply when the recipient of the service is acting under the authority or the control of the provider. This Article shall not affect the possibility for a court or administrative authority, in accordance with Member States' legal systems, of requiring the service provider to terminate or prevent an infringement, nor does it affect the possibility for Member States of establishing procedures governing the removal or disabling of access to information. Article 2(4) GDPR defines that the GDPR does not apply (to Github) in this case This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive. Extracting data from the repositories to create a nicely formatted contribution activity list, would still be considered hosting as defined at Directive 2000/31/EC, because Github does not (manually) redact or modify commits. So if you want to hide your contribution activity, you must delete the contributions. And you should not ask Github to do that, but ask the owners of the repositories. And they might have good reasons to deny your request. If an owner of a repository denies your request without a good reason, you can ask Github to do so. But Github would then probably deny that request, because they explain in their privacy statement that modifying the history is not possible: The email address you have supplied via your Git commit settings will always be associated with your commits in the Git system. If you chose to make your email address private, you should also update your Git commit settings. We are unable to change or delete data in the Git commit history — the Git software is designed to maintain a record — but we do enable you to control what information you put in that record. edit To further clarify why Article 14 of Directive 2000/31/EC applies, see case C-236/08 (Google v. Louis Vuitton) where the European Court of Justice clarifies the meaning of that article (ECLI:EU:C:2010:159): In that regard, it follows from recital 42 in the preamble to Directive 2000/31 that the exemptions from liability established in that directive cover only cases in which the activity of the information society service provider is ‘of a mere technical, automatic and passive nature’, which implies that that service provider ‘has neither knowledge of nor control over the information which is transmitted or stored’. Accordingly, in order to establish whether the liability of a referencing service provider may be limited under Article 14 of Directive 2000/31, it is necessary to examine whether the role played by that service provider is neutral, in the sense that its conduct is merely technical, automatic and passive, pointing to a lack of knowledge or control of the data which it stores. The way Github creates/shows the contribution activity is in my opinion technical, automatic and passive. That means it is not liable, and that implies that the GDPR does not directly apply, unless data is unlawful, and someone notifies Github of that: The restriction on liability set out in Article 14(1) of Directive 2000/31 applies to cases ‘[w]here an information society service is provided that consists of the storage of information provided by a recipient of the service’ and means that the provider of such a service cannot be held liable for the data which it has stored at the request of a recipient of that service unless that service provider, after having become aware, because of information supplied by an injured party or otherwise, of the unlawful nature of those data or of activities of that recipient, fails to act expeditiously to remove or to disable access to those data. Surely the GDPR might be the reason data is unlawful. But you need a reason, in particular based on Article 17 ("right to be forgotten"). For example if personal data of a 12 year old child is processed without permission of it's parent. Without such a reason the legitimate interest of the repository owner will probably prevail (who wants to keep the git history complete).
This issue touches upon two distinct GDPR rights: Art 15 right to access: you have a right to receive a copy of all personal data concerning you that are undergoing processing (including storage). Access may only be denied where this would “adversely affect the rights and freedoms of others.” Art 20 right to data portability: if processing is being carried out by automated means, and processing is based on certain legal bases (consent or contract, but not legitimate interest), then you have a right to receive a copy of your personal data in a machine-readable format, for personal data that you have provided to the data controller. Whereas the right to access is fairly straightforward, the right to data portability applies under much more narrow conditions. Basically, it's a right that you can download any data that you've uploaded so that you can move to a different service. Google Takeout is primarily concerned with your right to data portability, and provides your data in a machine-readable format. Any photos that you've uploaded to Google Photos, you'll be able to download. Thus, it could be technically compliant to exclude information that they've inferred about your personal data, such as image-recognition results. Such results would still be personal data under the GDPR definition of the consent, and would be covered by your right to access. Google might argue that you already have access to this data through the web interface. In my opinion the GDPR clearly requires the data controller to provide a “copy”, i.e. the data in some durable form – not merely access through a web interface. Whereas your question is specifically about Google, the same issue applies to other services as well. E.g. Ruben Verborgh has an interesting blog series on trying to get access to all their data from Facebook, though unsuccessful so far. Similar to your scenario, Facebook offers a download for personal data but does not include all personal data in this download. In one of the documents provided by Facebook in the course of the exchange, they note that they allow access to photo tags through the web interface, but do not include this in downloaded data – without providing further justification.
Given a large database of email addresses that you can't prove have given consent to receive email, the only legal thing to do with it, is to (securely) delete it. (I am going to switch your question about a larger company to a bank: in the UK, big pharma is forbidden from advertising to individuals.) In principle the rules are the same for a huge bank and everything down to a self-employed plumber. In practice the plumber will be told "don't do that again" rather than fined. This case was treated under the Data Protection Act, which has a maximum fine of £500,000&nbsp;&ndash; so a big bank would probably have been fined more, but not necessarily much more. Under GDPR, fines are related to turnover, so the fine would be a lot bigger for a large bank. The incident is a year old now. Details here.
People running web servers are generally liable for contributory culpability, when some user breaks the law by putting the material on the server. There are legal mechanisms for relieving the server guy from this burden. The best-known mechanism is "DMCA takedown", where you publish contact information so that an offended person can serve up a proper legal claim that you are distributing material that they own copyright to. If you follow the rules, you may enjoy "safe harbor" protection against contributory liability: one of the requirements is that you have to take infringing material down. The specific requirements can depend on the nature of the liability and jurisdiction, but generally involves a "hands off" involvement where the person has no knowledge of what's going on on his server. So just disclaiming responsibility does not work. There are other more serious violations, such as distribution of child porn or transmission of top secret information. Jurisdiction is not totally central to internet questions, and I could sue you (the server guy) in US courts, or (depending on the offense: copyright infringement of a particular item) in UK courts. Nailing this down specifically to Sweden is harder, but recall that The Pirate Bay had a whopping judgment against them.
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).
Yes, it triggers the GDPR obligations Considerations: Can you surely identify those residing in Europe? In that case you should ask them to sign up again and confirm the consent. A lot of mailing lists are doing just that. Did they previously give consent and you can document it? If so, then you can argue that you have the required consent. Do you have business in Europe? If not then I don't think they would bother to go after you. You could just walk away from the fine. What other personal informastion are you storing? If you know who reside in Europe then you already have more info than just the email. The email address itself wouldn't be much of a documentation issue, SAR or Portability task.
The obligation to notify the supervisory authority (CNIL in your case) no longer exists. It was part of the previous regulatory framework, but it is not part of GDPR (which takes affect tomorrow). If you use CCTV that may monitor employees (i.e. they sometimes enter the HQ to consult with the owner), your obligations under the GDPR is basically to inform the employees that the CCTV cameras are there. I.e. Data subjects are entitled to understand when their personal data is being processed, covering the transparency aspect of processing. The use of CCTV must be communicated via signage which indicates the areas covered and instructions for further information.