Can a German employer force employees to submit personal data to a contractor? A German higher-education institution recently introduced a new measure to facilitate Covid-19 contact tracing: next to each door (i.e. entrances to the building, the lecture rooms, the labs and some other places), there is a QR code that must be scanned using an app by a company. The goal is to track who was in a specific room at a specific time. The rule applies to employees, students and visitors. People who don't have a smartphone, should visit a specific URL on the contractor's website and enter their data manually. People who do not wish to provide these data should not enter the building at all. The higher-education institution claims that this is all perfectly legal because it conforms to the local Corona Law (i.e. Baden-Wüttemberg's Corona law, in force since 30 September 2020, which is also available in English) and because the contractor's treatment of the data conforms to the GDPR. However, I am not totally convinced that the reference to these two pieces of legislation is sufficient: §6 of Baden-Wüttemberg's Corona law allows organisations to collect certain data about attendees, participants etc. but does not state that these persons can be forced to submit their data to a third party (i.e. a contractor to the organisation they are visiting). The GDPR is relevant when people willingly submit their data but does not seem to be a legal basis for forcing people to submit data to a third party. Note that this contractor is not mentioned in employee contracts as a company with which the higher-education institution might share data. So my question is whether an employer can force employees and students to submit data to a contractor without violating the principle of informational self-determination.
The university has a legal obligation to collect certain data from attendees, including employees an visitors. It has decided to keep these records in digital form, and offers a smartphone app as a convenience. The university has outsourced the data processing activity to a third party. This is perfectly legal under the GDPR, if that third party is contractually bound to only process the data as instructed, and not for their own purposes. Whereas the university acts as a data controller (Verantwortlicher), the third party would be a data processor (Auftragsverarbeiter). I have some doubts though whether an app or a website is indeed the solution that offers the best data protection, especially taking into account the GDPR's data minimization principle. Requiring updates when entering or leaving any room is potentially excessive. Given the sensitivity of the data, the university should have performed a data protection impact assessment to weigh the consequences of this measure. At least for employees, the measure would likely have to be approved by the union (Personalrat) as well.
I think you could count decline-events, but not track users who declined tracking. But I also think such information isn't useful for demonstrating compliance. Therefore, you should avoid storing extra data about people who do not give consent. When consent is required for analytics. The GDPR provides a general framework for processing personal data. The ePrivacy Directive (ePD) overrides this general framework when it comes to cookies and similar technologies related to accessing information on the end user's device. Per ePD, such access is only allowed when it is strictly necessary to provide the service explicitly requested by a user, otherwise consent is required. Thus, analytics cookies require consent and setting an analytics-declined cookie is strictly necessary. But this consent requirement relates specifically to storage cookies, not to collecting analytics data. Thus, you might have a legitimate interest in collecting data with cookie-less analytics, which could involve counting cookie-consent decline events. Unfortunately, most analytics systems collect very broad categories of data and cannot be limited to a necessary subset. Even such limited analytics (unless they are truly strictly necessary for operating the site) should support an opt-out. I don't think you could legitimately gather analytics about such opt-out events. GDPR audits. Your motivation for collecting statistics about consent-decline events is to be prepared for a GDPR audit. This is probably not necessary, but it depends. It might be useful to distinguish between internal/voluntary audits and data protection audits by the supervisory authority. You might voluntarily review your compliance to convince stakeholders that you're compliant, and such voluntary audits might be part of the appropriate technical and organizational measures a data controller has implemented in accordance with Art 24, Art 25, and Art 32 GDPR. You should collect any statistics you need for this purpose, e.g. to ensure that the opt-in rate looks realistic. But since you can set the parameters of this audit, it makes no sense to collect data “just in case”. Under Art 58(1), your supervisory authority can audit your data processing and can compel you to provide any information it requires. This is similar to how a tax authority can compel you to produce business records for auditing purposes. This is closely related with your general obligation to be able to demonstrate compliance with the GDPR (Art 5(2)). More specifically, the controller is required per Art 7(1) to be able to demonstrate that the data subjects have given valid consent, but does not prescribe how to demonstrate this. How to demonstrate that valid consent was given. For demonstrating that consent was given, there are no clear best practices. However, this topic is briefly discussed in EDPB guidelines 05/2020 on consent. They recommend that you retain records about the following: that a data subject in a given case has consented how consent was obtained when consent was obtained information provided to data subject at the time that the controller's workflow meets all relevant criteria for valid consent Some of these are process-level concerns about how you ask for consent. For example, you might record video walkthroughs of your consent management solution to demonstrate how consent can be declined, given, and revoked. You should definitely keep a version history of the text and information that was displayed to users when they were asked for consent. I think you should also be able to explain in your front-end code how the result from your consent management solution is used to load relevant features (and that they aren't loaded before consent is given). If a feature or service is made conditional on consent, it might be good to have a short written analysis that consent is still freely given under the requirements of Art 7(4). But other aspects relate to the individual data subject and the individual consent-giving event. Some consent management solutions send a small record about the consent to a backend server where it is stored with a timestamp, so that it can be later traced that and when consent was given. I've also seen consent management tools that show a timeline of events to the user (when consent was requested, and when consent for which purpose was given and revoked). I think such detailed insight into an pseudonymous individual's consent status is a very powerful way to demonstrate compliance. What is not relevant here is information about data subjects who declined consent in the first place. Consent means opt-in. The default is that no consent is given. To demonstrate that consent was obtained in a valid manner, information about data subjects who didn't consent isn't necessary or useful. So I expect that you would be fine in an audit without collecting such data. In fact, the lack of a clear purpose and necessity for collecting this data could be argued to be without legal basis and violate the GDPR's data minimization principle. And even when recording information about those data subjects who did consent, the EDPB guidelines remind us that this “should not in itself lead to excessive amounts of additional data processing”.
You probably can't refuse to use such services. The relationship between you and these services is very different when you interact with them as a consumer, versus when these services are provided on behalf of your employer. In the latter case, the service is (or at least should be) bound as a data processor who can only* use your personal data as instructed by the data controller, your employer. Thus, it is your employer who determines for what purposes your data will be used, not the cloud service. Your employer has a legitimate interest in providing a modern and secure productivity suite to its employees, and in requiring you to use such services for efficient communication and collaboration. Of course it would be possible to provide some such services on-premises, but the GDPR doesn't really discriminate between self-hosted and third party services, as long as the third party service is contractually bound as a data processor. To a large degree, this is of course a legal fiction. The cloud services deploy new features all the time, and all that your employer can really do is agree to those changes, including agreeing to new ways for how to process your data. Also, the service provider may act both as a data processor on behalf of your employer for some purposes, but as their own data controller for others. E.g. in Google Workspace (formerly GSuite, formerly Google Apps for Business) Google collects analytics data about how you use their Docs product, and they use it for their own purposes. However, they would only process the document itself as a data processor. This is quite different in the consumer version where Google can use personal data for their own purposes, although within the limits of their privacy policy. Within your work account, you do have some privacy controls, similar to a consumer account. While your employer can set defaults and restrict features, you are not forced to share all data. E.g. in a Google Account, you can “pause” web and app activity (i.e. browsing history) that would otherwise be collected from Chrome browsers while logged in with your work account, or from Android devices that are managed by your employer. This data would potentially be used by Google for Ads, even with a Workspace account (I'm not sure). However, Google Workspace services generally do not feature ads themselves, e.g. the paid Gmail version does not feature ads. The largest real issue with the use of such services by an European employer is the international transfer of data to a non-EU jurisdiction, especially into the U.S. The GDPR offers many alternatives for how such transfers can be protected. In the past, the EU and US had used the Privacy Shield mechanism. However, it was found to be invalid in the 2020 Schrems II ruling, due to concerns about US mass surveillance. Subsequent guidance from supervisory authorities explained that it's not sufficient to use “standard contractual clauses” as an alternative protection, but that additional safeguards have to be implemented, which would effectively deny the personal data to actors in the US. Both Google and Microsoft offer some “data sovereignty” choices that prevent international transfers into the US. However, those have to be configured appropriately by your employer. Thus, instead of asking “can these services be used?” to which the answer is yes, it might be better to ask “is my employer using these services in a compliant manner?”. If you have concerns about such issues, you can contact your employer's data protection officer
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).
A data subject access request can be valid even if it wouldn't disclose new information. The right to access ties in with the GDPR's transparency principle (finding out which data is being processed) and with the right to rectification (are there any mistakes in the data being processed?). For rectification, it's pretty much ideal if you get back exactly the data you expect – but you're allowed to check with an access request. The Art 12(5) limitations on excessive or manifestly unfounded requests do put a limit on the right to access, but this limit helps controllers respond to legitimate requests. For example, if a request is clearly intended to harass the controller with busywork, it can be denied as unfounded. Similarly, requesting access to the same data very frequently would be excessive. However, the controller has burden of proof to show that the request is excessive or unfounded – basically impossible for a one-time request for specific data. A request is not automatically excessive just because it is likely to only return data you already know. But ultimately, detailed guidance on the interpretation of “excessive” is up to the supervisory authorities – the GDPR itself provides no guidance. Aside from the above exception, access can only be denied if it would adversely affect the rights and freedoms of others. For example, you could be denied access to non-anonymous performance reviews. There would be no such adverse effect for basic information about your employment. If a data controller improperly considers your request as excessive or unfounded, you can lodge a complaint with your supervisory authority, e.g. the ICO in the UK. Most controllers are suddenly extremely helpful once contacted about an official complaint.
There are no direct penalties per GDPR. The data controller must make sure that the person making the request is the data subject, or at least authorized by the data subject. If the controller has reasonable doubts about the identity, they should request additional information for identification purposes. The controller must find a middle ground between violating the GDPR by rejecting a potentially valid request and violating the GDPR by disclosing data to potentially unauthorized recipients. Having reasonable technical and organization measures that prevent unauthorized disclosure is part of the controller's responsibilities per Art 24. What the data controller can do is to block future requests from the alleged stalker. When a request is “manifestly unfounded or excessive, in particular because of their repetitive character”, then the controller can charge a reasonable fee or refuse to act on the request (Art 12(5) GDPR). But it's up to the controller to prove that the requests are unfounded or excessive, it is not possible to reject potentially valid requests on sight. Depending on what the alleged stalker does with the obtained data, they would fall within the scope of the GDPR themselves and would probably be violating it because there is no sufficient legal basis. Also, the alleged stalker, as a data controller, would be required to inform the data subject about subsequent processing of the data per Art 14 GDPR. Attempting to obtain another person's personal data through an access request would have to be punishable by other laws. For starters, such attempts would likely involve identity theft, and successfully obtaining the data would probably be a kind of fraud.
It is not legal in the case of a company. They must also accept communications by post. In the UK, &quot;a company must at all times have a registered office to which all communications and notices may be addressed.&quot; (s 86, Companies Act 2006). It must display the address of its registered office on its website, business letters, and order forms (r 25, Company, Limited Liability Partnership and Business (Names and Trading Disclosures) Regulations 2015). It must also disclose the address to you if you ask for it in writing (r 27). A failure to do either of these is a criminal offence (r 28). As a practical matter you can also look up the address yourself on the Companies House register if you know the name or registered number of the company. The company must provide you with its registered name on all forms of business correspondence (r 24) (this is a wider definition than that for disclosure of its registered office address). A company cannot rely on the fact that the registered office address it has given to Companies House is out of date. It must continue to accept communications at any address on the register for 14 days after it notifies Companies House of any change. (s 87, Companies Act 2006).
Obtaining consent for cookies is not required by the GDPR at all. Instead it is covered by the e-privacy directive, which as a directive rather than a regulation, must be implements by specific legislation in each individual country. The exact requirements vary with the law of each country. An e-privacy regulation has been proposed, which would have scope similar to the GDPR, would replace the Directive, and would not require national implementing legislation. However it has not yet been adopted. Proposed versions have significantly different requirements than the current Directive. Nor does the GDPR require consent for advertising that does not involve the processing of personal information, unlike some other privacy laws such as the California CCPA. However, if the Google package sets cookies without consent that are not strictly necessary for operation of the web site, it might well fail compliance with some of those national laws implementing e-privacy. Also, even necessary cookies must be disclosed to the user, as I understand it, possibly only in general terms. Several national Data Protection agencies have said that cookie compliance is not a major priority, at least not until an e-privacy regulation is in place. But that does not mean that lack of compliance is legal. Unfortunately I see no way for a developer using the Google package to correct this issue within the package. One would either have to implement a different solution, or trust that Google will fix this before enforcement becomes a serious issue. However, the app developer could add a separate general cookie consent banner, and turn off all adds if consent is not given, I believe.