Should the client be informed every time when more personal data is requested under GDPR Article 13? A SaaS company offers some services, which require registration. Its clients are notified about Terms of Service and Privacy Policy during the registration process. Should the company send to the client an email according to GDPR Article 13 after the registration? If later the client adds some new personal data to her account info (e.g. profile image), should the company again inform the client about obtained new personal data according to GDPR Article 13?
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.
Belgium enacted an implementing law, the Act of 30th July 2018 on the protection of natural persons with regard to the processing of personal data. This, along with the GDPR, are the key legislative references that relate to your question. On 5th September 2017 the ECHR judged that it "considers that States should ensure that, when an employer takes measures to monitor employees' communications, these measures are accompanied by adequate and sufficient safeguards against abuse". This case set a precedent relevant to employee monitoring in Belgium. This is most definitely a data protection or privacy law matter and the DPO should be consulted. If they have to do research, that shouldn't be your concern as that is their job. The company must support the DPO in what they need to do that job, as such is literally written into the GDPR. Furthermore, in this case it would, by my evaluation, be necessary to conduct a Data Protection Impact Assessment (DPIA) for the monitoring activity, and if one has been done, it should document the recommendations and requirements or what is already in place. You as an individual may also ask a question of the Data Protection Authority: (NL) https://www.gegevensbeschermingsautoriteit.be/verzoek-klacht-indienen (FR) https://www.autoriteprotectiondonnees.be/introduire-une-requete-une-plainte You might ask them about your position and liability as an employee, but I would be more concerned, if I were you, with verifying that your actions are above board rather than trying to cover your ass just in case they aren't. Do the right thing, even if that means questioning the direction you've been given. AD logons still identify the person logging on, and may include source IP, which is specifically listed in the GDPR as within the scope of 'personal data'. So while there may be a legitimate need to process such data, it needs to be gone about in the right way. Actions taken by an employee are taken by the organisation in terms of processing personal data, so whatever you are asked or ordered to do, will be done by the company. If you are being offered no legal justification for doing so, you might document the direction you are given and question it respectfully, pointing out that if found to be unlawful, it is the company that would be in trouble, all while knowing that should there be for example an unfair dismissal, you have a record of who asked you to do what, how you challenged or questioned it, and what was the outcome.
Per GDPR Art 12(5), “any actions taken under Articles 15 to 22 and 34 shall be provided free of charge”. The right to rectification is Art 16 and reads in its entirety: The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. Thus, I think it would be invalid to charge a fee for an address change if that change was made in exercise of your data subject rights. If you didn't invoke this right, it's debatable whether charging a fee would be proper. On the one hand, they can charge whatever service they want (provided that this was part of the contract you entered). On the other hand, they have an obligation to assist you with your exercise of data subject rights. This includes recognising a data subject request even if you didn't explicitly invoke the specific GDPR article. For example, refusing a request for erasure just because you didn't invoke some magic GDPR words would be clearly noncompliant in my opinion. If the company offers multiple customer service options, charging for some of them may be all right. Typically, the lowest-cost solution for a company to deal with GDPR requests is to offer an online self-service option. An email to the data protection officer would typically also be free. Charging for phone support might be fine though. In an insurance context, there could also be a legitimate claim that updating your address is not a mere correction of your personal data, but a modification of the contract (depending on what you're insuring). Another possible counterpoint (which I think is not valid though) would be that the company never stored inaccurate data and therefore doesn't have to satisfy a rectification request.
The data processor is not responsible for complying with the GDPR. You are ultimately responsible, since you are the data controller. The data processor is merely required to assist you, but it's unclear what that means in the presented scenario. Per Art 28(3)(e) GDPR, the DPA must require the data processor to provide reasonable assistance: That contract or other legal act shall stipulate, in particular, that the processor: […] taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III; However, per Art 28(1) you can only engage processors that you deem sufficient to protect the data subject's rights: the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject. Here, it seems that your company failed to ensure that the processor provides the features you need for compliance. Many companies claim to be GDPR-compliant, but that doesn't mean that your use of their services will be GDPR-compliant as well. Depending on how the Art 28(3)(e) requirement was implemented in the DPA you may have a right to assistance even if the processor doesn't implement necessary features in their software, but enforcing this contract could require a lawsuit in a foreign jurisdiction (but that's par for the course for international B2B contracts). It is worth noting that the GDPR right to erasure doesn't always apply. In a processing activity where no erasure right is likely to arise, it would be perfectly fine to use a data processor that doesn't offer any possibility for erasure. Similarly, it can sometimes be legal to use technologies like Blockchain or Git that make erasure difficult or impossible. However, it is the responsibility of the data controller to analyze the impact of such a choice up front, before commencing the processing activities. In some cases, this could require a Data Protection Impact Assessment (DPIA). Note that transfers of personal data into the US are illegal or at least questionable in the wake of the 2020 Schrems II ruling. The Privacy Shield is no longer a legal basis for such transfers. Standard Contractual Clauses (SCCs) are technically allowed, but only “on condition that enforceable data subject rights and effective legal remedies for data subjects are available” (cf Art 46). The ECJ's judgement calls this into question. This could be a further incentive to migrate to a more GDPR-compliant service.
Contacting a business email about a business matter is usually fine, but in this case we have an unsolicited marketing communication (spam), not really a business matter. The client's jurisdiction likely has more specific rules about spam. Also, it is unusual (read: presumably illegitimate) to contact individual employees rather than the company's official address with the offering. From the GDPR perspective, every processing of personal data (such as email addresses that might identify natural persons) needs a legal basis (Art 6). Let's go through them: consent? No. necessary for performance of a contract involving the data subject? No. legal obligation? No. vital interests? No. public interest? No. legitimate interest? Perhaps. The client has a legitimate interest to conduct their business. However, this legitimate interest must not be overridden by the data subject's interests, rights, and freedoms. Such as the interest in not being disturbed by spam mails. It is the Data Controller's (your client's) responsibility to balance the legitimate interest themselves to determine whether they have a legal basis, but I really don't think that they do. In conclusion, your client's idea is a bad idea: They likely do not have a legal basis for this under the GDPR. They are likely violating more specific anti-spam laws in their jurisdiction. They are working hard to get their domain put on spam filter lists. Note that already the step of collecting employee email addresses is personal data processing and needs a legal basis. Of course, the GDPR does not apply when the client is not established in the EU and only processes the addresses of persons that are not in the EU.
When you use other services, the question is whether that service acts as an independent data controller, or as a data processor who only uses the data on your behalf. When engaging a data processor they must be legally bound to only use the data on your behalf, for example with a contract / data processing agreement (DPA). See Art 28 GDPR. Data processor status is attractive because processors are seen as an extension of the controller. In contrast, when sharing data with other controllers you would need a separate legal basis to authorize this sharing. Google offers tons of different services, so this question needs to be considered on a case by case basis. For Google Cloud services or Google Workplace, Google generally acts as a data processor. For other services, Google acts as a controller. Notably, Google Fonts does not offer a DPA so that you cannot claim they're acting as a processor in that context, regardless of what other Google services you use. An equally important problem when using Google services is the data transfer problem. Google is controlled from the US, but the US do not offer an adequate level of data protection (see the Schrems II judgement). Comparatively few Google services allow you to select where the servers are located, as to prevent transfers of personal data to countries where privacy cannot be guaranteed. For example, this is why Google Analytics (GA) is problematic. Google acts as a data processor for basic GA features but makes no promises about the location of servers. Thus, using GA implies a (probably) illegal transfer of personal data to the US.
a few quick notes that come to mind. As the commenters point out: DSGVO is indeed the German equivalent name to the GDPR (English term) "Imprint" isn't a privacy related topic that much, as such it's not really changed by the upcoming GDPR The GDPR changes many things, but the requirement for up front information isn't one of them - so it would've already been a rule to follow Sometimes the question who is responsible for privacy information might not be that easy to decide when you're on platforms. I take this situation as being pretty clear though. You are basically given a blank slate, you can do with that page whatever you want, and the visitor has no clue whatsoever that it might be hosted by Github. In addition to this, Github would be classified as a data processor (providing the tool) and you as the data controller who is in charge of practically everything except for the provision of the page. I hope this helps. Btw. it's not that hard anymore to write a privacy policy these days.
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.