How does the personal/household activity exemption not apply to domestic CCTV pointed to the street? I am surprised to learn that, in the UK, private/domestic CCTV cameras pointed to the public street make the owner GDPR controller — with all the consequences like having to respond to data requests from all those strangers who were filmed. In Czech Republic though, the personal/household activity exemption applies (edit: no, it does not, my bad). Was/is it correct for the courts to not apply the exemption? How is filming the street with personal CCTV substantially different from filming it with a phone? (other than for the operator not being visible to the strangers — which makes the first impression for them that nothing is being filmed).
Why do you expect different courts to determine different laws in the same way? The Czech and UK laws that implement the GDPR are necessary different because they are the products of different legislative and legal traditions and are written in different languages. The differences may be minor but they will exist. Particular cases will have different factual and legal nuances and be interpreted by different courts with very different judicial traditions. Czech courts set no precedents in UK courts and vice-versa. It’s no surprise that there will be different outcomes. Even jurisdictions with much closer legal traditions like US Federal Circuit Courts and Australian states often have divergent precedents on similar (or the same) legislation.
the statute only applies to EU residents Wrong. GDPR applies to everyone in the EU (Art. 3). This means tourists are also covered. Residence status is completely irrelevant (Recital 14(1)): The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence There is no provision for data processors/controllers to demand proof from data subjects of them being located in the EU. You can challenge them, but if they refuse to provide proof you will still be liable to fulfill their GDPR request should they indeed be present in the EU.
The goal of the GDPR is to ensure a single market for personal data processing throughout the EU. Since all EU/EEA member states now have equivalent levels of data protection, it doesn't matter in which member state data is stored or processed. Member states cannot generally limit this single market via national laws. Furthermore, secure processing may be possible outside of the EU/EEA as discussed in Chapter 5 of the GDPR. Some countries such as Japan have been asserted an adequate level of data protection so that no special safety measures are necessary. For other countries, a transfer of personal data may be possible under so-called Standard Contractual Clauses which detail the responsibilities of the data exporter/importer. However, the recent Schrems II ruling has invalidated the (partial) adequacy decision for the United States, and has strongly hinted that SCCs only work if the parties are actually able to honor their responsibilities under the SCC (which is not the case with some surveillance laws). Data protection is likely not ensured for processing in the US or by US-controlled companies (even if the processing usually takes place within the EU). Given the sensitivity of health data, this means you should likely avoid using the typical public cloud providers (regardless of availability region). Depending on where your company is based, you might also be disqualified as a data processor by EU data controllers. So the GDPR has no data residency requirements that limit the processing/storage to Germany, but some data residency requirements to keep the data in the EU. However, there may be non-GDPR obligations that mandate how the data can be processed, but I'm not familiar with those (the German regulatory landscape for tele-health is very uneven, differs between German states, but is also improving a lot recently). Since you're processing health data, you should pay special attention to Art 9(3) GDPR which is expanded in German law by §22 BDSG to list a catalogue of possible safety measures you should consider, but none of them are related to data residency. §78 BDSG has further details on transfers into non-EU countries, such as emphasizing that human rights must be guaranteed in the target country.
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
Video surveillance is not necessarily illegal, but you do need a very solid legal basis. You should not install a camera in your lab without going through your department's usual processes, likely involving the data protection officer and the Betriebsrat/Personalrat which MUST sign off on such workplace surveillance measures. I don't quite see how a vote among colleagues could authorize this surveillance. Your organization's data protection officer should be able to help you to place the video surveillance on safer footing, or to find better alternatives. Implementing video surveillance could first require a written data protection impact assessment (Datenschutz-Folgeabschätzung). Some pointers below. GDPR/DSGVO compliance starts with three questions: What is the purpose for which personal data is being processed? What is the legal basis for this processing? What means can be used to achieve the purpose, collecting the minimal amount of data necessary? You need to think further about the purpose for which surveillance is necessary. In particular, a camera does not prevent accidents and there might be less invasive ways to prevent intrusion (such as locking the door). Cameras are a fairly extreme measure, and are typically only used as a deterrent to crime, e.g. to deter robbers at a bank counter. The legal basis (GDPR Art 6) you choose is quite relevant because consent (opt-in, Einwilligung) is not generally possible in an employment context, and legitimate interest(berechtigtes Interesse) is not available to public authorities. While companies could use a legitimate interest, this interest must be compelling enough to outweigh the rights and freedoms of the affected data subjects even if they object (try to opt-out). In its guidelines to video devices, the EDPB (EDSA) has also mentioned that the legitimate interest must be non-speculative. The mere concern that equipment could be damaged by an anonymous co-worker is not enough, but past incidents could make this interest legitimate – the amount of surveillance must be proportionate to the actual risks. The disgruntled co-worker could escalate by contacting the data protection officer, lodging a complaint with your state's supervisory authority, or by suing your employer. It is not guaranteed that they would succeed, but it doesn't seem like this instance of surveillance is entirely proper. I would deactivate the cameras until you are sure that the camera surveillance is being performed legally.
Note: I am not familiar with Washington law, but I can make an educated guess as to what is happening here. I am guessing that the couple in question are the joint registered owners of the motor vehicle. In many jurisdictions, motor vehicles are treated differently from &quot;normal&quot; things, they are treated as inherently dangerous and thus ownership carries a certain set of responsibilities. (Similar to e.g. owning a firearm, which carries with it certain restrictions on how it can be stored, for example.) One of those responsibilities is to keep track of who is operating the motor vehicle. Therefore, unless the operator of the motor vehicle can clearly be identified without incurring unreasonable cost, tickets for traffic violations are generally addressed to the registered owner, who can then forward them to the responsible operator. (Note that &quot;unreasonable cost&quot; does not have to be monetary. It could also be an invasion of privacy: it is less invasive to just ask the owner to identify the operator than to e.g. surveil the owner's property to find out who is using the vehicle or run facial recognition against the owner's family, friends, and colleagues.) In many jurisdictions, there is a form attached to the ticket (or downloadable from some website) which will look something like this: I accept the ticket: [ ] I do not accept the ticket [ ] because … I was operating the vehicle, but I did not run the red light [ ] I was not operating the vehicle [ ] … the vehicle was operated by: name ___, address ___ … I do not know who was operating the vehicle at that time [ ] If you claim not to know who was operating the vehicle at the time in question, that might have other consequences. In some jurisdictions, you can then be ordered to keep a logbook, for example. If the vehicle then gets caught again and you again claim to now know who was operating it, or you cannot produce the logbook, you might get fined for violating the court order to keep a logbook.
In the U.S. this is a notoriously perilous area of the law, particularly because the laws regarding recording vary so much between the states. A good source for this question is the RCFP. To give you an example: In Pennsylvania it is a felony to record "oral communication" in any circumstance in which the speaker would be justified in expecting it to not be recorded. Legally, as soon as you turn on an audio recorder in PA, you had better make sure nobody unaware that you're recording wanders within range of your microphone!
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").