Knowledge Base

The European Whistle Blowing Directive

New requirements for companies and authorities imposed by the European Whistle Blowing Directive The EU aims to protect future whistleblowers through the newly introduced Whistle Blowing Directive (Directive 2019/1937) in order to effectively tackle corruption, fraud, misconduct and negligence. Member states had until December 17, 2021 to incorporate the directive into national law. ## Is the Directive applicable to my company? Covered by the directive are, of course, public areas such as public procurement, transport safety and environmental protection, but also private sector areas such as product safety. The protection of privacy and the security of personal data are also within the direct scope of the directive. Under the Directive, companies are required to establish internal reporting channels and member states are encouraged to establish so-called "external reporting channels" with public authorities. ## How are reports submitted? The directive stipulates that whistleblowers must first submit a report through internal reporting channels. If such internal reporting channels are not available, whistleblowers can contact the external reporting channels provided for this purpose directly. Whistleblowers are thus fully protected by the provisions of the Directive in the absence of an internal reporting channel. Under certain conditions, this would also be the case if the whistleblower - in the absence of an internal reporting channel - turns directly to the public (and thus produces serious damage to the image). Attempts to prevent whistleblowers from using the internal or external reporting channels or to "punish" them in any way are additionally punished by the member states through appropriate sanctions. Thus, current and former employees, contractors, trainees, job applicants and other business partners are extensively protected as whistleblowers. This protection includes the aforementioned protection against reprisals of any kind, i.e. including suspension, dismissal, transfer or any other form of worse treatment - insofar as this is connected with the report. Any obligation to maintain confidentiality is invalidated by the provisions of the Directive, and contractual penalties and further liability are generally excluded. In addition, whistleblowers benefit from a reversal of the burden of proof, so that a mere prima facie case is sufficient for protection under the Directive. Since whistleblowers are so strongly protected, it is advisable for every company to set up a corresponding reporting channel. Such a reporting channel is mandatory for companies in certain sectors (such as financial services), the public sector and private companies with at least 50 employees. ## How must such an internal reporting system be set up? * The internal reporting system must be available to all employees, but can also be extended to business partners and other external third parties. <br> * How a report is submitted can be determined by the companies themselves. Thus, the use of an online platform, a hotline, but also the oral submission through a personal meeting is conceivable. However, the latter could potentially harbor dangers. <br> * An impartial person or department must be assigned to process the reports. <br> * The reporting channel itself must be secure, i.e. the identity of the whistleblower or of persons mentioned in the report must be kept confidential. <br> * Access by unauthorized employees must be prevented. <br> * A confirmation of the filing of the notification must be issued within 7 days. <br> * Information must be provided to the whistleblower within 3 months about investigations and follow-up actions. <br> * Anonymous reporting must be possible. <br> * The internal reporting system must fully inform whistleblowers of the possibility of making an external report to the competent authority. <br> To summarize, the establishment of an appropriate whistleblower system is therefore urgently recommended for all companies and authorities.

Nov 13, 2022
10 reasons for open source software instead of American cloud service providers

Outlined below, we would like to point out some of the advantages of using open source software (instead of the numerous cloud services from the USA). Especially from a data protection perspective, the use of open source software is advisable compared to other solutions from third countries. ## Can personal data be stored in the USA without any problems? Currently, the transfer of personal data to third countries - such as the USA - is not (or no longer) covered by an international agreement, as the Privacy Shield" was declared insufficient. Even in the case of a subsequent new framework agreement, there are numerous concerns with regard to data protection law; these are based in particular on the fact that, for example, American security authorities could request access to the data stored there at any time (and no information is provided about the access). The FBI, for example, sends out so-called "National Security Letters" or "NSLs" which request data from providers and at the same time order them to keep quiet about this fact under threat of punishment. An equivalent level of data protection in Europe as prescribed by the GDPR is therefore very difficult to achieve, especially when particularly sensitive data such as health data is stored or processed. From a data protection perspective, the most important thing for a company is arguably to maintain its own data sovereignty. This refers to complete control over the company's own data and the data of its customers. By handing data over to a cloud service solution, this sovereignty is to a large extent relinquished. ## What is the advantage of open source? When using open source software, moreover, the code and the way the software works can always be reviewed. Certain functions and routines can be adapted more easily than is the case with normal software. Also, no "backdoors" can be hidden in the software, because the code is open source as described in the input and can therefore be viewed by anyone. Open source software can be operated or hosted by companies internally on their own servers, while SaaS solutions (e.g. from the USA) are also hosted on servers not controlled by your own company. When the software is operated on the company's own servers, a higher degree of sovereignty is therefore achieved, because it is the company alone that decides where, how and when the data is processed or stored, and not another service provider. Another advantage is likely to be the elimination of liability risks, because data processing agreements usually have to be concluded with an external service provider, which also provide for joint liability. Any company is very reluctant to be liable for hardly foreseeable risks in the data processing of the selected service provider. Another advantage is likely to be the elimination of liability risks, because data processing agreements usually have to be concluded with an external service provider, which also provide for joint liability. Any company is very reluctant to be liable for hardly foreseeable risks in the data processing of the selected service provider. ## Why are cloud service providers problematic? A very big disadvantage of using large cloud service providers is the transfer of the data to other service providers, as the large providers are usually unable to handle the wide range of tasks on their own. Thus, the data is also passed on to numerous subcontractors in different countries. Tracking these data transfers is hardly controllable and difficult to follow up. A concrete example is the list of subcontractors for Google's popular G-Suite with more than 60 different subcontractors (as of July 29, 2022, URL: In the event of future "data breaches," there is not only the risk of significant fines, but also the very real risk of a loss of reputation when using insecure service providers. ## So what are the advantages of using open source software instead of the big cloud services? 1. data sovereignty is maintained 2. no (unnoticed) access by foreign security authorities 3. no backdoors 4. open source software can be customized 5. less liability risks 6. fewer contracts with service providers 7. higher security standards possible 8. self hosting 9. protection against image loss 10. verification of open source software by independent experts

Nov 11, 2022
hacked - do I have to inform my customers about a data breach?

A Data Breach can occur even under the best of circumstances. If a loss or a so-called "personal data breach" occurs, the supervisory authority must be notified within 72 hours pursuant to Art. 33 GDPR. If there is also a high risk for the data subject(s), the breach must also be notified to the data subject pursuant to Art. 34 GDPR. The aim of the notification requirements is not to punish a company for any misconduct, but rather to minimize the risks - resulting from the breach - for the data subjects. ## What must I report to the authority? In terms of its content, the notification to the supervisory authority must contain at least a description of the nature of the personal data breach, the contact details of the data protection officer, a description of the likely consequences, and a description of measures already taken and proposed. The notification must be made by the data controllers themselves. Accordingly, if a breach has occurred at a processor, the notification must be made by the controller (principal) and not the processor. The notification to the supervisory authority is made independently of the notification to the data subjects themselves. Having to inform customers about such a data protection incident can also have an impact on future business relationships, so such a notification should also be transparent about the protective measures taken so as not to forfeit the last trust of customers. ## Do I have to notify my customer? For this reason, with regard to the notification obligation (of the data subjects), a consideration must be made as to what extent the personal rights and freedoms of the data subjects are endangered by the data breach. According to Art. 34 GDPR, this is regularly the case if there is a high risk. Such a high risk exists if a forecast shows that a low level of damage is either highly likely to occur or that the damage (with a low probability of occurrence) could be high. This forecast must also include whether notification could mitigate the risks to affected individuals. In such a case, notification to the data subjects would also be considered mandatory in any case. Moreover, data subjects within the meaning of this regulation can only be natural persons, because otherwise no personal data would be affected. ## Are there exceptions to the<br> notification obligation? There are some exceptions to this notification obligation according to Article 34 (3) of the GDPR. However, all exceptions are based on the fact that either measures have already been taken before or immediately after the incident, which reduce the risk for the data subjects to an acceptable (see above) risk. Thus, in the case of a Data Breach in which - according to the state of the art - encrypted data has been lost, notification is generally not required. If notification is only possible with an enormous amount of effort (e.g., due to the large number of people affected), public announcement of the incident is also possible as an alternative. In summary, in the event of a data protection incident, notification can only be dispensed with in cases where the risk to the data subjects is very low.

Nov 13, 2022
Google Analytics and data protection

**The use of Google Analytics is almost no longer allowed for Austrian website operators. The reason for this is the success of the NGO noyb, which partially managed to file a complaint against Google Analytics with the Austrian Data Protection Authority (DPA). The reason was the violation of the general principles of data transfer according to Art. 44 GDPR.** Google Analytics is the most popular analytics tool on the market, but in recent years there have been repeated complaints about questionable data protection practices by Google. Among the complainants was the organization [noyb ]( Max Schrems, which filed 101 model complaints against companies in 30 EU and EEA countries for their use of Google Analytics and Facebook Connect after the [Schrems II decision]( This was followed by the DPO’s first [complaint decision](, which concerned the transfer of data from the website to Google. ## Decision by the Austrian supervisory authority The Austrian data protection authority ultimately concluded that the use of Google Analytics constitutes a breach of the GDPR. ### Personal data First, the supervisory authority examined whether personal data were processed in the process. [Art.4 No. 1 GDPR ]( >"’personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier [...]." By activating Google Analytics and visiting the website (, the following information is transmitted to the Google server: - unique network identifiers representing both the browser and the device of the complainant as well as that of the first respondent (using the Google Analytics account of the first respondent as webmaster); - address and HTML title of websites and subpages visited by the complainant; - information about the browser, operating system, screen resolution, language selection and the date and time the website was accessed; - the IP address of the device used by the complainant. The supervisory authority determined that these data are personal data within the meaning of Art. 4 No. 1 GDPR. can distinguish website visitors based on the above points and determine whether they are new or returning users. The visitor is thus selected from a homogeneous group of all website visitors and identified by an identifier. This assumption is reinforced by [Recital 26 S. 4](, [Recital 30](, as a unique identifier can be combined with any other listed element such as browser data or IP address, increasing the likelihood that a website visitor is identified. This raises the question of why did not consider using the "IP anonymization function" of Google Analytics. admitted in its statement to the supervisory authority that this function was not implemented correctly. However, the DPO argued that a proper implementation would not have changed the rating. This is because the identifier is linked to so many other elements that the personal reference still exists. ### Data transfer with consequences In this case, the Austrian supervisory authority finds that there is **not a sufficient level of protection** in the transfer of data from to Google through an instrument of [Chapter V]( of the GDPR and thus a violation of Art. 44 GDPR has occurred. The standard contractual clauses that had agreed with Google do not ensure an adequate level of protection under Art 44 GDPR. This is because Google is subject to surveillance by the US Secret Service pursuant to [50 US Code § 1881 ]( known as FISA 702). This means that the current additional measures are not sufficient to exclude the possibility of surveillance and access by the secret service. No other instrument under Chapter V of the GDPR can be used for the data transfer. In the explanatory memorandum to the decision, the institution refers to EDPB's "[Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data](". Central to this is the statement (para. 70) that the "additional measures" referred to in the Schrems II judgment can only be considered effective if they close the legal loopholes identified by the data exporter when an examination of the legal situation in the third country has taken place. The authority quotes the EDPB’s statement from this document: > "If, ultimately, you cannot ensure an essentially equivalent level of protection, you must not transfer the personal data." (p. 28). The following additional contractual and organizational measures were agreed upon: - the notification of data subjects of requests by the secret service (whether permissible at all in individual cases), - the publication of a transparency report or a guide for cooperation with the secret service, - the review of all requests for information from the secret service. Google has also announced these technical measures: - Protecting communications between Google services, protecting data in transit between data centers, and protecting communications between users and websites. - Implementation of "on-site security ". - Encryption of "data at rest" in data centers. With regard to the [contractual and organizational measures ]( by the authority, it is not apparent how effective these are from EDPB's perspective. It is also unclear to what extent the possible technical measures would prevent access by the United States Secret Service. For example, the agency objects to the encryption techniques provided by Google, as well as tot he requirements of EDPB, which stated in its aforementioned recommendations to the U.S. that a data importer covered by 50 U.S.C. § 1881a (FISA 702) must grant access to the data, which could explicitly extend to encryption keys (para. 76). The ruling concerns the operator of the website, and is not directed against Google LLC (USA), as the requirements of Chapter V of the GDPR do not have to be met by the data importer, but only by the data exporter. ## Is it time for a Google Analytics alternative? As mentioned above, this decision was the first of 101 model complaints. Other countries are already following. Just two weeks after the Austrian data protection authority’s groundbreaking decision, the **French supervisory authority, CNIL**, also announced that the use of Google Analytics on websites violates the GDPR. In the following months, **the Italian and Danish data protection authorities** published similar notices. It is expected that other EU countries will follow suit. If they come to the same conclusion, this will not only have consequences for the use of Google Analytics in Europe. As a further consequence, **EU companies will no longer be allowed to use US cloud services** in the future. This decision will inevitably lead to discussions. On the one hand, US companies will have to adapt their products to the GDPR; on the other hand, EU companies should look for more data privacy-friendly alternatives. Another solution could be to change U.S. laws to better protect EU citizens data or to ban the use of EU citizens data on servers outside the US. If personal data continues to be transferred to the U.S. without adequate safeguards, severe penalties could be imposed. US-President Biden signed an executive order on Oct. 7, 2022, outlining steps on the [data protection framework ]( the **European Union and the United States**. The aim is to create the legal framework in the USA, on the basis of which the EU Commission's review process for an adequacy decision can then be initiated. The Executive Order is thus intended to pave the way for a new chapter in data transfers to the USA. However, critics complain that secret service will continue to have access to personal data of EU citizens. Read more here. There is already a trend away from Google Analytics towards European solutions. We can help you find a GDPR-compliant and secure solution for your needs. [Arrange an appointment with us]( right away, because data protection is our top priority!

Nov 30, 2022
Risks when using SaaS tools from the USA

Companies and other institutions in Europe are increasingly turning to SaaS tools from outside Europe. Common examples are tools from companies such as Google, Microsoft, SalesForce, HubSpot and Calendly. However, when it comes to processing user data, one could almost speak of "Schrödinger's data processing", because whether the data processing actually takes place lawfully or not - is never guaranteed with sufficient certainty. ### Requirements under the GDPR for DPA Data transfers to unsafe third countries - which at present undoubtedly include the USA - are subject to many legal restrictions. For example in the case of Google's GSuite and Workspace (e-mails, cloud storage, calendars and more for companies), Google uses so-called "suitable guarantees", standard contractual clauses, certifications and more to establish an appropriate level of data protection. ### Legal uncertainties when using SaaS tools from the USA Data controllers in Europe can conclude corresponding data protection agreements with Google, for example. Companies should also do so, since these data processing operations appear at first glance to be data processing according to Art 28 GDPR. Unfortunately, the use of these tools is associated with many legal uncertainties. Three points stand out clearly: 1. legal uncertainty regarding access possibilities (by security authorities). 2. legal uncertainty with regard to subcontractors for commissioned data processing 3. legal uncertainty due to existing alternatives in the fulfillment of the contract. #### Access capabilities of U.S. authorities In the U.S., it is possible for security authorities to access data of European users and institutions at any time, provided that this data is stored with a U.S. company. The USA has special means at its disposal here, such as so-called "National Security Letters". These are requests from the government to companies to hand over data without disclosing it. No court order is required to issue such requests, i.e., investigative authorities can issue these requests themselves and companies such as Google, Apple, Microsoft, etc. must comply with them. Also, the Cloud Act from the US allows **extensive access by US authorities** to data stored by US companies. Prior to the enactment of the Cloud Act, access to such data was generally only possible in the context of a so-called mutual legal assistance request (here, the authorities of the state in question - in which the data is stored - are asked for "help"). After the enactment of the Cloud Act, from the perspective of the U.S. authorities, a request for mutual legal assistance is no longer necessary and the data must be surrendered. Therefore, from the U.S. perspective, foreign authorities (such as German authorities) no longer need to provide prior consent. #### Unmanageable number of subcontractors Especially large SaaS services such as Google GSuite/Workspace use an enormously high number of subcontractors. A list of the subcontractors used at Google can be accessed at With this enormously high number of subcontractors - distributed all over the world - the first justified doubts arise as to whether all subcontractors and, if applicable, their subcontractors are extensively audited or have merely been contractually obligated to certain procedures in paper form. At this point, it should under no circumstances be forgotten that the data controller always remains the data controller. This has also been specifically regulated for the case of data processing by Art. 24 GDPR. The purpose of the introduction of this additional regulation is to assign the responsibility and liability for any processing of personal data to the person who carries out these processing operations himself or has them carried out (cf. recital 74 of the GDPR). Another problem also arises from the design of data processing with such large companies and extensive tools. If large companies such as Microsoft or SalesForce independently determine the purposes and means of processing, this does not constitute data processing pursuant to Art. 28 (10) of the GDPR, but rather joint responsibility. As a result, there may be a lack of data subject consent to transfer data to an additional controller and all processing activities might **factually not be allowed**. In practice, it must now be checked whether the contracts with such companies precisely describe which services are provided and how the data is processed. In the absence of such provisions, it can be assumed that, as described above, the decision on the purposes and means of processing no longer lies with the original controller. This leads to numerous problems and violations of the provisions of the GDPR. #### Existing alternatives for contract fulfillment Further, there is a legal uncertainty that cannot be overlooked, as alternatives to many of these Software tools exist within Europe. Also, in most cases, data subjects have not given consent to the transfer of personal data to countries such as the US. In these cases, however, processing is based by data controllers on the purpose of fulfilling a contract. However, it is obvious that the processing in the U.S. as such - in most cases - is not necessary for the performance of the contract. This is because the processing operations necessary for fulfillment of the contract could also be mapped within a company or at least within Europe. This inevitably means that the processing of data subjects' data in the U.S. cannot be "simply" based on the purpose of fulfilling the contract and lacks the consent of the data subjects, which in turn poses significant risks for data controllers. A secure alternative to SaaS solutions are open source tools. Glasskube enables you to install and operate open source software automatically in your data center or cloud, and thus process data securely and in compliance with the GDPR.

Nov 27, 2022