Does the European Union allow to store medical (sensitive) data in cloud platforms such as Amazon Web Services or Google Cloud? Does the EU allow to store patients medical data in cloud databases from providers such as Amazon Web Services or Google Cloud? What are the legal requirements? Can you point at some legal source about this matter?
Storing medical data in cloud services can be legal, but isn't necessarily so (as with any other kinds of data). The GDPR considers health-related data as “special categories” of data per Art 9. Processing such data is forbidden, unless an exception applies. Per Art 9(2)(h) such processing is allowed when it is […] necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law or pursuant to contract with a health professional and subject to the conditions and safeguards referred to in paragraph 3 Paragraph 3 requires that processing under 9(2)(h) only occurs under the responsibility of someone who is subject to an obligation of secrecy per Union or member state law, e.g. a doctor. Paragraph 4 allows individual member states to add further conditions, including limitations, to such processing. Assuming that electronic storage or processing of health data is in fact necessary, the GDPR does not make a strong distinction between in-house processing, and processing via Data Processors. Of course, the usual conditions for using data processors and performing international transfers apply. However, a data controller processing medical data will almost certainly have to first perform an Art 35 Data Protection Impact Assessment. This DPIA must consider various risks. Transferring data into third countries is risky. Using data processors is risky. But processing data in-house can also be risky, so using an external service could improve things. There is a lot to be balanced here. Where the planned processing has high risks, the responsible supervisory authority has to be consulted first (Art 36). The authority can provide “advice”, or even ban the processing per Art 58.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.
I spent a few years working in and around the Energy industry - including a stint working at a supplier, I'm no longer there so unfortunately I no longer have access to the email chains I had discussing this with legal. The consensus at the time was that a "traditional" i.e. non-half-hourly (NHH), non-smart meter reading itself was not considered personal data - they are conceptually tied to a metering point (which may or may not be a physical meter), not to an individual and don't represent an individual's energy consumption (the granularity of the reading is insufficient to tell anything about the usage profile) But this information, while all around the implementation of GDPR it was a couple of years back and to be honest it was bugging me that I might be out-of-date on the current practices so I reached out to a former colleague who was the Data Protection Officer at the supplier I worked at to try and get a more up-to-date take. He's since moved on but was there until recently so has more experience with the topic since GDPR actually went into effect. I asked him whether a) estimated opening reads were considered "personal data" and b) what would happen with a request to change one under article 16 and he had this to say, I've translated industry-speak in square brackets: a) for NHH ["Non Half Hourly" - meters that are read ad-hoc, essentially all non-smart domestic meters will be this] an estimated reading wasn't personal data automatically until the billing flag was set in CRM and those would be the only ones we'd include on an SAR [Subject Access Request], any others are internal data not personal. HH ["Half Hourly" - meters for higher consumption users, typically larger business premises are billed on increments for each half hour so have readings for each] and remote [smart meter] readings are always personal for domestic and microb [micro-businesses are a certain class of non-domestic energy customer see condition 7A] b) erm no! we'd only change it if the value in CRM didn't match the value in the D10 [industry Data Flow used to transmit meter reads] for some reason. if they match it's an accurate representation of what we estimate the reading to be so it's just a vanilla billing dispute not a data protection issue so i'd have punted it to [name of person who was head of metering] From that it would sound as though the estimated read would count as personal data - so long as it's being used for billing purposes, but that doesn't mean they have to accept your read in it's stead. It all comes down to accuracy - GDPR requires that personal data be "accurate" but provides no definition as to what "accurate" means (which makes sense since you can't give a one-size-fits-all answer that isn't an encyclopedia) and while The Electricity Directive 2019 confirms the need for accuracy in billing again it doesn't tell us what that means. The implementation is left to member state regulators. In the UK this is OFGEM and all opening meter readings are validated through third parties (so you don't end up with the foxes guarding the hen house!) and are calculated using the following formula: Last validated reading for the meter point &lt;= supplied reading &lt;= (expected daily usage x number of days since last validated reading x 2.5) where "expected daily usage" is obtained from a database maintained by the regulator - it's calculated off meter type, property type, property use, previous validated reads etc. So if the customer provides a reading that falls outside the above the supplier can (and in practice invariably will) reject it as being inaccurate. Now this is why the when a meter reading is provided matters - reads you provide are always assumed to be the read on the day you give them. With opening reads there's some leeway, I can't remember the official rule on how much but usually they give you up to the next estimated read is generated but more on that later. Now if the reading you're trying to submit is a "now" reading and it's failed the validation criteria and you aren't happy with the rejection you can force the issue by demanding the supplier come read the meter. You don't say how long has passed since the opening read - more than the week from what you've said so presumably at least a month (guessing you've had at least your first bill). Now if they are saying the opening read was X (based on the estimated usage) and you're it should have been X + Y and the current reading is X + Y + Z you want to pay your actual usage Z not Y + Z. What you need to do is dispute the opening read, which you're entitled to do, arguably GDPR of Article 16 gives you this right, but on it's own it's a weak argument. There's established means by which an estimated read's "accuracy" is determined and assuming they followed that they're going to just tell you that as far as they are concerned it is accurate. Any challenge to that accuracy is going to have to be done within the legal/regulatory frameworks for assessing accuracy, that's what they're there for, if they won't accept your reading escalate that to the regulator - and as soon as you can. OFGEM for example allow disputing of opening reads for 12 months - it doesn't have to be resolved within that 12 months it just has to be lodged with them within that time. If you try and use the GDPR angle to pursue this IMHO it's going to muddy the waters and not help you get what you need - pursue this on billing accuracy.
No, you do not need to show a privacy policy just for running a publicly accessible server, as long as any traffic data such as IP addresses is only used as strictly necessary for providing the service requested by the user. The background here is that while GDPR is a very general law, the ePrivacy directive (ePD) provides more details for telecommunication and information society services, which also includes SSH servers. Per ePD Art 6, traffic data may be used (1) for the purpose of the transmission/service or when the data has been anonymized, (2) for billing purposes, or (3) for marketing or value added services, when the user has given their consent. Information about the processing is only required under ePrivacy for cases (2) and (3), but not for processing that is strictly necessary. Now the tricky question is under what circumstances you can log (failed) log-in attempts or use tools like fail2ban. One argument is that such measures are strictly necessary to ensure the security of the communication, but these measures are evidently not necessary for performing the transmission in the sense of ePD. There are a few ways to resolve this: necessity has to be interpreted more broadly, and security measures are indeed necessary. For example, ePD Art 6(5) mentions fraud detection, without authorizing it explicitly. an IP address is effectively anonymized in the sense of the ePD since you do not realistically have means for linking the IP address to any particular person. This is a fairly weak argument, but could be supported by GDPR Recital 26 which defines anonymous data. Counterpoint: IP addresses are online identifiers which are explicitly included in the definition of personal data in GDPR Art 4(1). an IP address is not just traffic data that falls under the ePD, but also personal data that falls under the GDPR. When the IP address is merely used to make a transmission, it is not processed as personal data and only ePD concerns apply. But when we process it to ban the IP, it is processed as personal data under a legitimate interest. This processing does not fall under any of the categories from ePD Art 6, so that only GDPR concerns apply. These include a requirement to inform the data subject about the processing at the time in accordance with GDPR Art 13, which could be satisfied by displaying a link to a privacy policy in the course of the login process. For a legitimate interest argument, it also depends on the expectations of the typical data subject. Since some security measures such as security logs are normal and should be expected, a legitimate interest argument is likely to be strong. I think this is the correct conclusion, even though the “it's not traffic data, or at least doesn't fall under the ePD” argument is quite weak. It hinges on the assumption that security measures are not “value added services”. This fits the intent of the ePD, but not the actual definition of value added services. In any case, you do not need to ask for consent unless you're required to obtain consent e.g. under ePD Art 6(3) or because your processing of personal data relies on consent as the legal basis per GDPR Art 6. It also has to be noted that ePD has no immediate effect, but has to be implemented by each EU member state in national law. These laws can provide more specific guidance.
Great question - I work for a London based company who use a large amount of location data. The process for deletion of data is not as simple as it first sounds. We recently had a deep dive with our legal team and as a result actually created a product to process deletions. Personal data from users/customer is carried for lots of reasons, not just marketing. What if you're asked to delete data that is needed to bill customers, information that may be relevant to a legal case or information that needs by law to be retained for the purposes of audit? GDPR does not make it illegal to carry personal information, it simply needs you to justify why you are keeping the information - inform the named person about this and provide them with a timescale for deletion. For example if you are required by law to store a record of emails to document the work done, but the user asks you to delete that information. You would be entitled to keep that information but only for the purposes of maintaining that audit trail. You would delete all associated customer data that was unnecessary such as CRM info, payment details etc.. but could keep the audit trail. The proper way to respond to the user's deletion request would be "your data will be kept in a secure server for the purposes of maintaining an audit trail for x amount of time. Once this time has elapsed it will be deleted. If you are unhappy with our use of this data please contact our data officer". GDPR isn't designed to catch you out - if you have a legitimate reason to keep that information then you are entitled to. The law was designed to stop marketers and advertisers hoarding huge amounts of information, as well as undermine Google/Facebook's duopoly on our personal information.
The main US law that governs patient access to medical records is called HIPAA, the Health Insurance Portability and Accountability Act of 1996. Here is a brief summary of the patient record provisions from the federal Department of Health and Human Services. There are further details, intended for providers, here. In general, you are entitled to receive a copy of your records, or to have them sent to another doctor. But they can charge a reasonable fee to cover the costs of copying and mailing the records. I am not sure how this applies to a physical model: whether the doctor would be required to send the original or to make a copy (which could be expensive), or whether it would be considered a "record" at all for the purposes of this law.
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.