Is asking users to waive GDPR compliance a legal way of escaping GDPR data handling requirements? I have recently come across this part of an app from a well-known US company: Is this a legal way of handling some of the technical obstacles GDPR introduced? Is this a "flexible" interpretation of the law or is it straight up illegal? To give the whole picture - I was asked where I live and based on that I was presented with this consent sheet. If I don't check the box, I cannot move any further - I have to give consent if I want to use the app. I was OK with giving that consent, but does that mean I also lose my rights that come with GDPR? The right to download my data, the right to be forgotten etc? I'm not interested in shaming the company, but I am interested in knowing if the approach - "I'll ask if they are OK with losing those rights so that I can do whatever I want" - is a correct way of handling the law. I didn't assume GDPR is "optional". Kind of defeats the purpose of having it if companies can put this in the fine print or worse - disallow anybody to use their software unless they give their private data to them with no strings attached. I saw and read a connected question here, but in my situation, I am actually unable to do anything unless I accept the terms.
GDPR does not cease to apply because of the location of data storage. It applies based on the location of the data processor, data controller, and data subject. If you are in the EU, you are a data subject covered by GDPR. It does not matter where the data are stored. Note that you are asked to confirm that you're aware that US laws may be less protective, but you're not asked to acknowledge that anything about the arrangement causes the "laws of your country/region" not to apply. The company also does not seem to be claiming that they don't apply, although it seems that they want you to think so, and it's not clear whether they think so. You are correct that GDPR doesn't allow its protections to be waived. A data subject may always consent to certain processing, and some processing may be performed without consent, but it's not possible to waive the right to withhold consent for processing that does require it.
That GDPR Disclaimer is no protection in some jurisdictions: the applicable laws to that situation in germany for example don't care about the GDPR: Cold calling, mailing, or e-mailing private people to advertise services all is handled by the same law: Without the consent it is expressly illegal under §7 of the law against unfair competition (Gesetz gegen unlauteren Wettbewerb UWG) and such cases are rather Slam-Dunk if the origin can be made out. The punishment can be a 300.000 € fine. The fact that to email someone you need their e-mail address and that e-mail addresses and private addresses are by default considered personally identifiable information is making it worse for the advertizer: Without either an exception (there is none available to cold-emailing) or special allowance of the person the data belongs to, you violate §4 of the federal data protection law (Bundesdatenschutzgesetzes BDSG) just by handling their e-mail address. That's a separate crime from the UWG one, adding up to another 300.000 € fine under §43 BDSG - or even up to 2 years in prison under §44 BDSG! Oh, and if the email does not contain a proper sender's address, that's another chance for a huge fine under the UWG... So, GDPR is your least trouble, if you violate the marketing laws of a country, or their own data privacy laws. A disclaimer means nothing as the act of sending the mail, even to an unintended addressee, is what is illegal and the law as written does not give a damn about 'I didn't want to advertise to that person' when in fact you sent them unwanted advertisements. Oh, and the very repository you suggest? It would violate the very same §4 BDSG and be illegal for processing private data if it was not actively asked to do that by the end user. As a result, that database is useless: It does kick back all people not in its database. Its database is incomplete because only few people give their address to that database as people not aware of the database never add their data on their own. So it regularly violates §4 BDSG with every German citizen's e-mail address it gets and kicks back, and claiming those addresses would be OK, it throws the company trying to check the database under the bus because they rely on data that is impossible to be reliable. tl;dr Don't do cold-(e)-mail marketing. You throw yourself into boiling oil with a lit torch in hand. further reading Other laws banning such behavior I had listed here, and I quote myself: The US has the CAN-SPAM-Act, which illegalizes sending unsocialised advertisements. You may NOT send a mail if any of the following is true: it has no opt-out the email was gained by 'harvesting' contains a header not matching the text contains less than one sentence the adressee does not have any relation to you In fact, you are liable for a 5-digit fine per infringing e-mail in the US. The FTC itself suggests to never buy e-mail lists - as E-mail harvesting or generating any possible e-mail adress itself is illegal.
The pragmatic answer is to just ask the data subject what they would like to have erased. The GDPR's right to erasure DOES NOT requires that you “delete all their records in [your] database”. Compared to other GDPR rights, it has a quite limited scope. It is necessary that one ground for erasure in Art 17(1) applies, and none of the exceptions in Art 17(3) apply. For example, you are allowed to retain any data that you need to fulfill a legal obligation (exception in Art 17(3)(b)), such as an obligation to keep financial records for a number of years. In the case of providing course completion certificates, I would assume that your legal basis for providing this service is a contract with the data subject. Contracts directly with the data subject can serve as a legal basis for processing per Art 6(1)(b). It doesn't matter if the contract was paid (consideration is not a necessary element of a contract in civil law systems). As long as this contract is in force, there are no Art 17(1) grounds for erasure. But if the contract is terminated, Art 17(1)(a) would apply: “the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed”. So the data subject could release you from your contractual obligation to provide the certificate verification service, and then require you to delete any personal data in connection with that service. In the unlikely case that you are using a different legal basis for hosting the certificate service: legal basis applicable? grounds for deletion Art 6(1)(a) consent maybe Art 17(1)(b): consent can always be withdrawn Art 6(1)(b) contract yes (see discussion) when the contract is terminated Art 6(1)(c) legal obligation unlikely per legal requirements Art 6(1)(d) vital interests no Art 6(1)(e) public interest unlikely per legal requirements Art 6(1)(f) legitimate interest maybe Art 17(1)(c): objection to further processing per Art 21(2) For all of these legal bases, it is the case that once the legal basis expires, then Art 17(1)(a) provides grounds for erasure. In fact, proactive erasure (without waiting for a data subject request) may be required in line with the Art 5(1)(b) purpose limitation and Art 5(1)(e) storage limitation principles. To quickly summarize all Art 17(1) grounds for deletion: Art 17(1)(a): data is no longer necessary Art 17(1)(b): consent withdrawn (only if Art 6(1)(a) consent was used as legal basis) Art 17(1)(c): objection to further processing (only if Art 6(1)(f) legitimate interest was used as legal basis) Art 17(1)(d): unlawful processing always merits erasure Art 17(1)(e): erasure is required by law Art 17(1)(f): special right to erasure for children Note that it is, in principle, possible to provide certificates without storing personal data. This could make it unnecessary to think about data subject rights like erasure. For example, you could provide a certificate to users. The certificate contains personal data, and you do not store a copy of the certificate. But you could use cryptographic signatures to prevent forgery of the certificate. The signature can be verified without having to store personal data. If you are familiar with web development, the same technique is used for JWT tokens: the data in the token is signed by a secret key so that it can be verified whether a token (and the data in the token) was created validly, without having to store a copy of the data in the token. Limitations of this approach are well-known, such as making it difficult or impossible to revoke certificates. In practice, such data-minimization techniques are overkill. The GDPR only requires appropriate security measures. If you have a legal basis (such as a contractual obligation with the data subject) then it is perfectly fine to store a certificate with personal data in your service. The GDPR obligations stemming from such a processing activity are not particularly onerous.
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").
Yes, their waiver has no legal basis and is invalid under the GDPR. They should have hired a better lawyer. GDPR rights cannot be waived (mrllp.com). The last bit should have been: Therefore, in consideration of my participation in any project, I understand that retaining my name and email address, as described above, does not require my consent and that the right of erasure, as spelled out in the GDRP Article 17 (1) b does not apply. The legal basis for our lawful processing of this personal data is Article 6 (1) f ("processing is necessary for the purposes of the legitimate interests pursued by the controller"). I.e. there is nothing in the GDPR that compels GitLab to erase this information, but their waiver is bogus. Keeping track of individual contributions in a software projects is necessary for a number of reasons, including security (if somebody contributes code that jeopardizes security, you want to audit everything that person has contributed).
The GDPR allows the right to access to be limited if this access would “adversely affect the rights and freedoms of others” (Art 15(4) GDPR). However, access to the recording would not give you more information than you've already received during the phone call, so this exemption is quite unlikely to apply in any case. UK data protection law also has a large list of additional exceptions, as summarized here by ICO guidance. These exemptions also cover some aspects of trade secrets, and even mention insurance examples. However, not such exemption is likely to apply in your case: the recording would not give you more information than you already have. If the data controller is concerned about some parts of the conversation, they should provide a redacted copy and explain why the redactions were performed. They should not reject the request outright. If the data controller wants to reject the request entirely, they must do so within the time frame for the DSAR (one month), must explain their reasons, and must inform you that you're allowed to lodge a complaint with your supervisory authority or to sue them. However, ICO guidance is flexible on how detailed the reason for refusal can be: Where an exemption applies, the reasons you give to an individual for not complying with a request may depend upon the particular case. For example, if telling an individual that you have applied a particular exemption would prejudice the purpose of that exemption, your response may be more general. However, where possible, you should be transparent about your reasons for withholding information. Here, I don't see any reason why full transparency would be a problem, so I would expect that the data controller can point to a specific exemption in UK data protection law. If you are unsatisfied with the data controller's response, please consider lodging a complaint with the supervisory authority. In the UK, this is the ICO. On the ICO complaints page, you can fill out the online form about “your personal information concerns”.
The GDPR is wide in scope, and flexible in application. Therefore it is not possible to give an absolute yes/no as to whether masking text with asterisks is or is not lawful. We can gain a deeper insight by looking at the GDPR itself. Firstly, the definition of processing (Art. 4 lit. 2): any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction As mentioned by amon, the principles relating to processing of personal data (Art. 5) are highly relevant, insofar as the activity constitutes processing. In particular, purpose limitation: [Personal data shall be] collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes ...and data minimisation: [Personal data shall be] adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed I would argue that making available the personal data on an invoice is processing. There are two separate operations: Making the data available to authenticated users; and Making the data available to non-authenticated users The purpose of making it available to authenticated users may be different to the purpose of making it available to non-authenticated users. Again acknowledging amon, the necessity of making the data available to non-authenticated users must be examined, as too must the means by which a non-authenticated user gains access to an invoice: are they using a URL that contains a token of some kind? Is this unique in some way? It could be that the presentation of a token itself constitutes authentication and thus authorisation to view the entire invoice, in which case further redaction may not be necessary if there is a clear necessity to disclose the entire contents to such a user. Whether the token expires or is limited to a certain referrer would be part of complying with the integrity and confidentiality principle and Art. 32 (Security of processing) by implementation of technical measures. When considering pseudonymisation and anonymisation, you will note that the redaction of name and address data from a certain view of the invoice, while nevertheless displaying the invoice number, constitutes pseudonymisation, since it would be possible with unfettered access to the remaining data, to determine the name and address from the invoice number, but not for the non-authenticated user whose view is redacted. In such a case, I fail to see how or why the replacement of a string with the same number of asterisks, or starting with the real character is secure or even practical, when the entire field could simply be replaced with a fixed-width string of asterisks or other filler, thus providing the user with no right or necessity to view the personal data with no further insight into what the personal data may or may not be.
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”.