Resellers under GDPR - disclosure of data processors or countries of data storage? A significant number of web-design and I.T. consultancy companies typically re-sell third party services related to their own as part of their product/service portfolio, to give a few examples, website hosting, domain names, email hosting, VOIP phone services etc. Sometimes these may be white-labelled services promoting the reseller's brand and hiding the fact they don't provide the service directly themselves. This is good for resellers as it increases their service portfolio and turnover, good for customers because it reduces their involvement in the complex technical arrangements and enables a sort of one-stop shop for their I.T. requirements, however these resellers would definitely be data processors themselves under the GDPR. In the insurance world, it is required for companies to publish/disclose the name of the company that underwrites the insurance. Is there any similar requirement under GDPR for data processors (resellers in this case) to disclose the country or countries where the data is stored and processed, or the names of third party data processors involved? I'm struggling to find anything to this effect but without such a requirement it makes compliance very difficult for data controllers (and processors looking to sub-contract to further data processors) when shopping around for compliant solutions if this information is not disclosed/published prior to enquiring.
Q1. Is there a requirement under GDPR for data processors to disclose sub-processing arrangements and the names of the organisations involved in this? "The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes." -- EU General Data Protection Regulations (GDPR) Article 28 Paragraph 2 This clearly states that the processor would need to make clear that they are subcontracting the services and get permission for this as part of the contract, but doesn't specify whether the subcontractors must be named and identified. Perhaps there is other prior existing subcontracting legislation that requires them to be named? Some procurement contracts as supplied by controllers may specify a list of nominated (allowed) sub-contractors or require the full identification of sub-contractors though I've not found anything in law that requires they be named other than as part of a specific contractual obligation. Q2. Is there a requirement under GDPR for data processors to disclose the country or countries where data is stored and processed? "Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor: ... (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. ..." -- EU General Data Protection Regulations (GDPR) Article 28 Paragraph 3(h) This clearly states the data processor must make available to the data controller all details required to demonstrate compliance. It's quite likely larger organisations may choose to make this simple for data controllers by supplying this information in the form of a completed Data Privacy Impact Analysis document. "Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information: ... (e) where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards; ..." -- EU General Data Protection Regulations (GDPR) Article 30 Paragraph 1(e) This clearly states the data controller must maintain a record of the country or countries involved if any of these are outside the EU, and so this information must be made available to the controller as stated above.
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.
If I have correctly untangled the law, Schedule 2 of the Data Protection Act part 3 identifies as a condition where you are not prohibited from revealing personal data: The processing is necessary for compliance with any legal obligation to which the data controller is subject, other than an obligation imposed by contract. The Animal Welfare Act 25(1) says An inspector may require the holder of a licence to produce for inspection any records which he is required to keep by a condition of the licence I can't tell if you are required to keep customer names, but if you are, it looks like the pieces fit together and you would have to provide the records. Call a solicitor to be sure, though.
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 statute only applies to EU residents Wrong. GDPR applies to everyone in the EU (Art. 3). This means tourists are also covered. Residence status is completely irrelevant (Recital 14(1)): The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence There is no provision for data processors/controllers to demand proof from data subjects of them being located in the EU. You can challenge them, but if they refuse to provide proof you will still be liable to fulfill their GDPR request should they indeed be present in the EU.
There is a lot going on in this question, so I'll pick out some individual aspects. Last but not least, I'll discuss if GDPR even applies. Does the GDPR require consent for X? Almost always, no. Consent is only one of many legal bases of processing. A common alternative to consent is a “legitimate interest” where a balancing test is performed between this legitimate interest and your interests, rights, and freedoms. Consent is typically only appropriate if this balancing test fails, for example if you would not reasonably expect this processing activity to occur. It's worth noting that it's a reasonably common occurrence that businesses are sold or merged. This is not unexpected. In general, you would not be required to consent to such a transfer. What can a company do with personal data acquired through a merger/acquisition? The GDPR does not provide explicit provisions for this case. But it might be useful to think about the two cases where (a) the new company is a continuation or successor of the original one, and (b) where the data is transferred (“sold”) to an otherwise unrelated company. In case (a) where the business is continued as normal, there is no change. In case (b) where data is transferred to a separate company, things are more complicated. The original company would need a legal basis for transferring the data. But as mentioned above, there might be a legitimate interest. Arguably, such a transfer could also be based on Art 6(1)(b) if the transfer is necessary to continue to provide the service, for example if the original company would otherwise have to terminate service. Of course, activities like data brokering where access to data is granted to unrelated third parties would generally fail to be covered by contractual necessity or a legitimate interest, and would probably need consent – but that doesn't seem to be the case here. When a data controller (such as the new company) acquires your personal data from sources other than directly from you, then they are subject to the notice requirements in Art 14. They have to actively notify you about their processing activities. But because you received emails that mentioned the transfer, this condition might have been met. Of course the new company continues to be bound by the purpose limitation principle as detailed in Art 6(4) – they can only use the data for purposes that are compatible with the purposes for which the data was initially collected. Thus, the new company cannot arbitrarily widen processing purposes, though some change in scope is certainly permissible. How does the GDPR right to object and to restrict processing apply here? The Art 21 GDPR right to object means that if the legal basis for a processing activity is a “legitimate interest”, then you can ask for an opt-out. But in some cases, this objection does not have to be granted. An objection essentially requires the controller to repeat the legitimate interest balancing test, taking into account the “grounds relating to [your] particular situation” that you provided in the objection. The Art 18 GDPR right to restrict processing is an alternative to the right to erasure. It applies only in narrow circumstances, for example while an objection is being checked. It is likely that you were informed about the transfer to a new company about 1 month in advance, so that you would have been able to prevent this transfer by closing your account prior to the deadline. If the new company conducts processing activities based on a legitimate interest, then their presumably GDPR-compliant privacy notice about which you were notified will certainly explain that you have a right to object. Is the new company GDPR-compliant? That is impossible to tell, but nothing you've shown so far indicates that they're non-compliant. My largest issue with this story is that the new company is from Australia, a country with extraordinarily bad privacy protections (as of 2022). However, due to the way how the GDPR treats international transfers of data, this doesn't prevent Australian data controllers from being GDPR-compliant, although it does make it difficult for other companies to use services based in Australia. Does GDPR even apply? Whether GDPR applies to a non-European company depends only on whether they either offer goods or services to people who are in Europe (“targeting criterion”), and whether the monitor people's behavior that takes place in Europe. Factors such as your citizenship would be irrelevant. I'll ignore the monitoring criterion, and focus on the targeting criterion. I'll assume that you are in Europe (EU/EEA or UK). Whether a company is targeting people in Europe depends primarily on the company's intentions. It does not matter whether the service is accessible from Europe. Thus, it is quite possible that the original company was not subject to the GDPR. Then, any questions about GDPR, consent, and data transfers are moot. In contrast, the new company clearly mentions GDPR-compliance, which would only matter if they intend for people in Europe to use their services. So GDPR probably applies to them, giving you the full suite of GDPR data subject rights as (hopefully) outlined in their privacy notice. And as long as they notified you that they acquired your personal data in accordance of Art 14, I don't seen anything that they might have done wrong in respect to this acquisition/merger.
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.
From a German perspective, it would be absolutely normal and expected that you're providing identity &amp; contact information publicly. Per §5 TMG (Impressumspflicht / Anbieterkennzeichnung) this is required for German tele-media offerings, such as websites or email providers, even if non-commercial. Whereas for you as an upstanding and diligent email provider an abuse@... address should be enough, the German context expects a street address where you could be served with a lawsuit… There absolutely are privacy and free speech issues with this compelled self-doxxing. But by running an email service, you're not just acting as a private person. Your privacy interests and the transparency and security interests of other people have to be balanced. Now since you are not in Germany, the TMG does not apply to you. You have no legal obligation to provide this information. However, the ISP also has no legal obligation to to deliver your email. The ISP does have an obligation to apply appropriate organizational and technical safety measures. It seems that one organizational measure they have found appropriate is that they will only deliver emails from providers that provide public contact information, as would be the norm in Germany. I am not entirely sure how the GDPR applies here. The GDPR doesn't really allow or prohibit disclosures of personal data, it just requires that every purpose of processing for personal data has a legal bases per GDPR Art 6. One such legal basis is a legitimate interest, which boils down to a balancing test between your rights and freedoms and other people's interests. I'm also not sure if the contact information should be classified as personal data in this context, because the contact info primarily relates to your role as an email provider. I'm also not sure if the ISP is processing your personal data in the sense of the GDPR when they merely require you to publish it on your own site. They would be processing it as soon as they scrape, store, or otherwise use this info.