Is Data Protection Officer obliged to conduct training of staff according to Article 39 of GDPR? GDPR Article 39(1)(b) states: The data protection officer shall have at least the following tasks: (b) to monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data, including the assignment of responsibilities, awareness-raising and training of staff involved in processing operations, and the related audits; In my country (Poland), legal experts in their publications claim that this provision requires the DPO to conduct training. When I read this law in English, I have the impression that it is rather about the obligation to monitor training of staff. The GDPR translation into Polish is known to be full of errors, so I would like to know how it is understood in other countries and languages. So, is the DPO obliged to conduct training or not?
As a native English speaker I would read this as requiring the DPO to monitor all the things listed (i.e. you are correct). Furthermore it would be ridiculous for the DPO to be personally responsible for doing all of these things. If you were supposed to perform "assignment of responsibilities" yourself that would pretty much make you the Chief Operations Officer. If you are only required to monitor job assignments for compliance then by the same logic you are only required to monitor training. Having said that, there is an established principle in the safety industry that compliance should have an independent reporting line up to the top management, and I think its the same for financial regulations too. You cannot be an effective DPO if you are just watching from the sidelines. So I would expect a DPO to have: Line responsibility for audits and routine compliance work such as privacy impact assessments, with a dedicated team of people if necessary. This ensures that there is an independent reporting line from everyday work up to the DPO. Do not accept a situation where data protection work is carried out by the project and then handed to you to file once it is complete, because it never will be. Project managers have a lot of competing priorities and they are extremely good at avoiding anything that sits between them and project completion. You MUST have your own people in the project to see what is happening and the power to stop a project if it is not compliant. If they won't give you that, turn down the job. Budget responsibility for training (with the work actually done by specialist contractors or the company in-house training department) Notification of job assignments where data protection is part of the responsibility.
The GDPR has a fairly broad concept of personal data: any information that relates to an identifiable person. This is far more than directly identifiable information! The concept of identifiability is further explained in Recital 26: To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. So indirectly linkable information can still be personal data. In your example, that ID can be easily re-identified with a particular person if you know who the secretary was between 2012 and 2014. It is quite likely that there are members in the club with this knowledge, or that this information can be gained from public sources like newspaper reports. Thus, you should assume that your member IDs are at most pseudonyms, but not anonymous. They are likely still personal data. However, it doesn't necessarily follow that you would have to erase everything. Art 17 comes with lots of caveats and exceptions. For example, if you are processing this personal data under a legitimate interest, and someone requests erasure, you might have overriding grounds to continue processing anyway. E.g. such a legitimate interest could involve security or auditability purposes. There might also be such a legitimate interest for keeping some history for the club, but there would have to be a decision based on the individual circumstances. Furthermore, you can of course retain data e.g. due to a legal obligation, or when this information is necessary for the establishment of or defence against legal claims. I understand your desire to keep some data around. Instead of asking “do I have to delete this?” it might be more productive to consider “under which legal basis can I keep this?”. I think you might have a legitimate interest, but you'd have to carry out a balancing test between the various interests and rights. A really problematic approach would be to hold on to de-identified data in the belief that it no longer were personal data. Such a belief is usually mistaken. True anonymization that meets the GDPR's definition is really hard, in particular because you would also have to prevent indirect identification, also by other actors than yourself. There are theoretical models that can help with anonymization, e.g. with k-anonymization methods you'd ensure that there are no unique records in the DB. But this can be tricky to apply correctly, so I'd recommend to only treat aggregate statistics as truly anonymous. In 2012, the ICO has published an anonymization code of practice (PDF). It is no longer up to date with the current legal environment (in particular since the GDPR has expanded the concept of identifiability), but it provides a good overview of both the difficulties of preventing re-identification and an overview of potential solutions.
If the lawyer has legitimate concerns, his first port of call would be the ICO https://ico.org.uk/. Before the ICO will take his complaint further he'll have had write to you expressing his concerns and received a written response that presumably he is unhappy with, and wants to take the issue further. Most companies have a data compliance team who will have policies and procedures to log breaches like this and decide what course of action to take in response. Not every breach needs to be brought to the attention of the ICO, and they have a handy self assessment tool to see if you should report the breach. https://ico.org.uk/for-organisations/report-a-breach/ In your situation, I don't think this constitutes a serious breach which will require investigating. It's simply an admin error. If it is unlikely to pose a risk to any of the individuals they will say something like: You should keep an internal record of the breach as detailed in Article 33 (5) of the GDPR, including what happened, the effects of the breach and remedial actions taken. The definition of risk according to the ICO is: "This risk exists when the breach may lead to physical, material or non-material damage for the individuals whose data have been breached". So in this case I'd assume a simple apology (Bcc'd :) ) and a record of what happened, how it happened, and the action taken to prevent it happening again should suffice.
The line they'll rely on for GDPR compliance is the first part of that sentence - "If you agree to this during the order process", which suggests that there will be a separate request to opt in to marketing communications at some other time in the process. Check any order documents. There's likely to be a tick box or similar on at least one. If that implies opting out rather than opting in there may be grounds to argue with that under GDPR, but there's nothing in the quoted text that suggests a problem.
GDPR rights and obligations cover different things: A duty of the data processor towards the government of the country where they operate to present certain documentation, and to implement technical and organizational measures to protect data. These would be audited by government agencies, not the individual customer. A single data subject cannot waive them. A duty of the data processor to process and store personal data only with a legal justification. User consent is one possible justification, if it is informed, revokable, etc. So a single data subject can waive a &quot;ban&quot; on storing his or her data in a database along with all the other users who waived that &quot;ban,&quot; but the duties towards the government regarding that data would still apply. A duty of the data processor to respond to an Article 15 request by the data subject in a certain way and timeframe. If a data subject writes a letter to the data processor and explicitly states that the letter is not an Article 15 request, then Article 15 does not apply. The data subject would of course have the right to make an Article 15 request at a later time.
Great question - I work for a London based company who use a large amount of location data. The process for deletion of data is not as simple as it first sounds. We recently had a deep dive with our legal team and as a result actually created a product to process deletions. Personal data from users/customer is carried for lots of reasons, not just marketing. What if you're asked to delete data that is needed to bill customers, information that may be relevant to a legal case or information that needs by law to be retained for the purposes of audit? GDPR does not make it illegal to carry personal information, it simply needs you to justify why you are keeping the information - inform the named person about this and provide them with a timescale for deletion. For example if you are required by law to store a record of emails to document the work done, but the user asks you to delete that information. You would be entitled to keep that information but only for the purposes of maintaining that audit trail. You would delete all associated customer data that was unnecessary such as CRM info, payment details etc.. but could keep the audit trail. The proper way to respond to the user's deletion request would be "your data will be kept in a secure server for the purposes of maintaining an audit trail for x amount of time. Once this time has elapsed it will be deleted. If you are unhappy with our use of this data please contact our data officer". GDPR isn't designed to catch you out - if you have a legitimate reason to keep that information then you are entitled to. The law was designed to stop marketers and advertisers hoarding huge amounts of information, as well as undermine Google/Facebook's duopoly on our personal information.
Maybe this changes something, maybe not. But at first glance, yes, avoiding US-based vendors does help comply with Schrems II. They need not be EU-based. Definition of an international data transfer The GDPR unfortunately does not define what an international transfer is, and just explains when they may be lawful: Art 44: Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country […] shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country […] to another third country […]. […] This has been interpreted, in particular by the official EU SCCs and by EDPB guidance, to imply two roles: the data exporter, and the data importer. Per those EDPB guidelines, a transfer occurs when three criteria are fulfilled together: The data exporter is subject to GDPR (e.g. as a controller via Art 3, or as a processor via an Art 28 data processing contract). The exporter discloses or makes available personal data to the importer. The importer is in a &quot;third country&quot; (for EU GDPR: anything outside the EU/EEA). Note that these importer/exporter aspects are independent from roles like &quot;controller&quot; or &quot;processor&quot;. It also does not depend on where in the world the exporter is situated. Applying this to your scenario How does this apply to your scenario? I am assuming Alice Inc is subject to the GDPR (criterion #1). Now, Alice Inc can process personal data, and that's not an international transfer, even if Alice Inc is in the US (or any other third country). The general GDPR rules apply, such as the requirement to implement appropriate technical and organizational measures to ensure compliance and security of processing operations. If Alice Inc engages data processors to process personal data on Alice Inc's behalf, then this would fulfil criterion #2 (disclosure to a third party). For example, hosting providers generally act as data processors. Any other kind of data sharing (e.g. to other data processors) would also fall under this category. Tricky in an US context: while employees would be agents of Alice Inc and would not be separate recipients, contractors/freelancers would also be potential data importers. If those data importers are based in the EU/EEA, then criterion #3 is not fulfilled and there's no international transfer. For example, using an EU-based hosting providers would sidestep Chapter V of the GDPR completely. If those data importers are based outside of the EU/EEA, then criterion #3 is triggered and we have an international transfer. Lawfulness of international data transfers When there is an international transfer, it must be adequately protected. In order of decreasing priority: country has an EU adequacy decision appropriate safeguards for a group of companies: Binding Corporate Rules (BCRs) Standard Contractual Clauses (SCCs) Art 49 specific situations What SCCs and BCRs do is to translate enough of the GDPR from statutory law into a contract to ensure adequate protection. But to be effective, they must actually be enforceable, and the data importer must actually be able to comply with those rules. In Schrems II, the CJEU found that the US (at that time) did not offer an adequate level of data protection, and that SCCs are probably invalid as well since importers cannot comply with both the SCCs and with US surveillance laws. Before using SCCs, it is effectively necessary to perform a transfer impact assessment (TIA) analyzing, among other things, the legal context of the importer's country. It may be possible to defuse this, for example by using supplemental security measures like end-to-end that prevent unlawful use of the data even if it falls into the wrong hands. However, such measures also tend to prevent intended use, especially in a cloud context. In the DPC Ireland decision against Meta Ireland (PDF), the DPC finds: 7.202 In summary, therefore, I am satisfied (and I so find) that: (1) US law does not provide a level of protection that is essentially equivalent to that provided by EU law; (2) Neither the 2010 SCCs nor the 2021 SCCs can compensate for the inadequate protection provided by US law; and (3) Meta Ireland does not have in place any supplemental measures which would compensate for the inadequate protection provided by US law. 7.203 Accordingly, in making the Data Transfers, I find that, subject to the analysis contained at Section 8 below, Meta Ireland is infringing Article 46(1) GDPR. Implications of using non-US vendors As already mentioned, using EU-based data processors avoids the international transfer problem due to the way how international transfers are defined. Even if an international transfer occurs, that might not be a problem. Some countries have an EU adequacy decision, for example Canada, Israel, or South Korea. While there would nominally be an international data transfer that needs to be disclosed e.g. in a privacy notice, there is no additional bureaucracy required. In other countries, transfer tools like SCCs might work. A TIA might show that that the issues discussed in the Schrems II decision and the DPC decision wouldn't apply there. But isn't that a contradiction? You correctly point out a problem with the GDPR's approach to data transfers: This would however have little effect on the access to the data, in that if US law enforcement turned up at the offices of Alice Inc. they could be required to hand over the data and their access to the data will not be changed in any way by the location of the web hosting. Yes, this is arguably a loophole. However: If the US-based Alice Inc is a data processor in behalf of another controller, that controller would likely be violating the GDPR by transferring personal data to Alice. If Alice Inc is a data controller: while this might not be a violation of the Chapter V rules on international data transfers, such a scenario could be argued to be an Art 24 or Art 32 violation instead (requirement to ensure compliance and security). When Alice Inc transfers personal data to data importers, that is less visible to data subjects, and outside of their immediate control. However, when Alice Inc collects data on data subjects, that is more visible to data subjects, in particular through an Art 13 or Art 14 privacy notice. That notice must also contain the identity of the data controller, which would disclose that Alice is US-based, which may enable to data subjects to make more informed choices. This won't help Meta While moving to non-US data processors can be a sensible compliance approach for many companies, it is less useful for multinationals like Meta. In this context, Meta is an Irish data controller who engages platform and development services from an American company. Even if Meta Ireland tries to perform all GDPR-covered processing activities outside the US, it's actual corporate structure situates some processing activities such as administration tasks in the US and other third countries. If my above analysis is correct, it would have been easier for Meta to comply with GDPR if the US-based Meta company were the data controller.
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”.