Choosing DPA to submit data breach complaint (EU-specific) Context The institution I am working for - in EU member-state A - recently suffered a cyber-attack which led to data being copied from the institution's infrastructure outside of it. The offenders asked for ransom to not publish the data, which the institution refused to pay, leading to a data breach. We are still waiting (roughly 30 days, now) to be informed by our law department about what exact data have been breached. I am working remotely for that institution, residing in EU member-state B for the last 4 years and 4 months. My Question I am considering to submit a complaint to the corresponding DPA about the breach and the way our institution is/has been handling the situation. Nevertheless, I am not sure to which the &quot;corresponding DPA&quot; in my case is. Should I address the DPA of my home country, B, where I stay in, my institution country's DPA, A, or probably both? Would it be better if, probably on top of that, I also address some EU body/institution, since more than one member-states are involved?
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.
This is less of a compliance question, and more of an infosec question. On one hand, you want to be able to restore access to an account to users who have lost their access. On the other hand, you must prevent unauthorized access e.g. from hackers. These factors must be balanced. Whether you'll fulfil a data subject access request will generally follow the same criteria as deciding whether you'll reset someone's access credentials, so I'll mostly discuss identity verification in general. Trying to validate names is generally pointless from a security perspective, since the name on the account might not be real, or because validation documents like scans from a passport can be easily forged. When a service has identity validation measures like requesting a copy of photo ID, or requesting a photo of you holding up a validation code written on paper, that doesn't actually help validating that the person requesting access is the account owner, but that the person requesting access appears to be a natural person, and now documents about their identity are on file. A lot of information like names, birthdates, or addresses is also not at all secret and could be easily guessed by a malicious actor. Most websites work by equating access with control over an email account. If you can receive a password reset code over email, you have access. In effect, this delegates the responsibility of account recovery to the email or OAuth provider. So the issue is what happens when someone loses their email account, which is not entirely uncommon for accounts that are multiple years old. One reasonable (and likely GDPR-compliant solution) is to deny access when someone loses their account. Quite a lot of services operate this way. A milder form of this is to email the old address that someone is trying to take over the account, and turn over the account only if you have other evidence of ownership and there has been no reply over multiple weeks. Since this is part of an identity verification measure, I don't think the GDPR's normal 1 month deadline would apply. However, this approach is very risky: an attack can succeed through the mere inaction of the true account holder, and it would arguably be a data breach if you give access to the wrong person – safer for erasure requests only. Also, emails like “click here or we'll delete your account” look a lot like spam (I get a lot of those about alleged problems with my Paypal account). A potentially more reasonable approach is to use questions about the account to verify ownership. When did they create the account? When did they last use it? Can they answer questions about non-public content of the account? (But don't let an attacker choose the questions!) You see some older sites that ask the user to select a “security question” for recovery purposes. But this isn't a best practice – they are frequently the weakest link in an authentication system. If the user answers truthfully, the answer may be easy to guess or discover for an attacker. E.g. the infamous “what is your mother's maiden name” question is horrendously insecure in the age of Facebook. If the user provides a more secure answer, that is essentially just another password that's even easier to lose than an email account. High-value accounts typically offer a secondary authentication method as a fallback. E.g. my bank can send me new access codes via physical mail. GitHub can optionally link a Facebook account for recovery purposes. But these measures would be overkill for most cases. Especially collecting a physical address for the sole purpose of offering account recovery would likely violate the GDPR's data minimization principle, though it may be fine when the user opts in with freely given consent. To summarize: what you're trying to do is extremely difficult, because you've need to balance different security aspects: keeping malicious actors out, and letting legitimate account owners in. Whereas I'd resolve that by denying any account recovery or subject access requests, other approaches exists with other risk profiles. The GDPR requires you to perform reasonable identity verification measures, but what is reasonable depends on the business context and is ultimately an infosec question.
It may be legal or it may not For example, if any of the users are in the European Union, then the GDPR applies and the person storing the information is a data controller and has legal obligations. These include, having a legitimate reason for storing them, storing them only for as long as necessary for that reason, notifying the individuals that the data is being stored and why, deleting it upon a users request etc.
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.
In the UK it is an offence to cause a computer to gain unauthorised access to any program or data held in any computer (s1 Computer Misuse Act 1990). It seems likely that other European jurisdictions have similar laws. Certainly Germany does: Penal Code 202a data espionage (German text - English translation). (I mention Germany because the linked thread does.) It might constitute theft in the jurisdiction if the finder did not take reasonable steps to find the owner - which may include informing the police of the find. Depending on the jurisdiction it might count as 'treasure' or abandoned property such that the finder is obliged to inform the authorities (the jurisdiction has the presumption of ownership of abandoned or lost property - e.g. Scotland), which then decide what to do with it. Legally speaking it seems to me that, to declare it legal, we have to get over such hurdles. [edit] There seems to be some dispute in the comments that cryptocurrency is subject to any regulation, counts as property, is something of value or is something that is owned and can be stolen, such that the person in the questioner's scenario could be held to account under the law for his behaviour. Aren't they merely numbers? No - plainly they do have value because people trade them with currency and goods and services. The UK's tax authority, HMRC, "does not consider cryptoassets to be currency or money" but sees them as having economic value because "they can be 'turned to account' - for example, exchanging them for goods, services, fiat currency (that is money declared by a government to be legal tender) or other tokens". They are "a new type of intangible asset". Individuals are liable "to pay UK tax if they are a UK resident and carry out a transaction with their tokens which is subject to UK tax". They are liable for "Income Tax and National Insurance contributions on cryptoassets which they receive from their employer as a form of non-cash payment [or from] mining, transaction confirmation or airdrops." (HMRC cryptoassets for individuals) Are they property? Something that can be owned, something that can be dishonestly appropriate (i.e. stolen)? That's the interesting dispute. Recently, the High Court of England and Wales ruled in a bitcoin ransomware-related case that "for the purpose of granting an interim injunction in the form of an interim proprietary injunction ... crypto currencies are a form of property capable of being the subject of a proprietary injunction". In that judgment there is some discussion of the authorities for considering or deciding they are property. ([2019] EWHC 3556 (Comm)) read from para 50 if not the whole judgment. In at least two other cryptocurrency-related cases the High Court treated the cryptocurrency as property. Vorotyntseva v Money-4 Limited, trading as Nebeus.com [2018] EWHC 2598 (Ch) and Liam David Robertson v Persons Unknown 2019. There was also a suggestion in the comments that the police would not understand and would not be interested. But there are several jurisdictions where people have been investigated, arrested, prosecuted and convicted of crimes relating to cryptocurrencies. A simple internet search for bitcoin theft, fraud or money laundering will result in some reports. In any case their interest or lack of it is irrelevant to what the law may say.
In order to process data (which includes storing data), a data controller must establish one or more of the lawful bases contained at Article 6(1) of the UK GDPR. Briefly, those are: a) Consent of the data subject b) Necessary for performance of a contract with the data subject c) Necessary for compliance with a legal obligation d) Necessary to protect vital interests of data subject or another person e) Necessary for public interest or exercise of official authority vested in the controller f) Necessary for controller's legitimate interests Clearly a) and d) don't apply. As you've settled the debt, it seems unlikely to me that b) or f) apply. That leaves c) and e). A common example under c) would be a requirement by Companies House or HMRC to keep accounting records for a certain period of time. Some public bodies may also find it necessary, under e), to retain records which they need to be able to carry out their other functions. It seems highly unlikely to me that either of these would justify retention for your &quot;lifetime&quot; however. I would start by sending them a written demand to have your data erased under Article 17(1). Make sure you also specifically request that they provide you with all the information (and in particular the purposes of the processing) under Article 15(1), and that, in the event that they refuse to erase your data, they explain the reasons why pursuant to Article 12(4). Their response on these points will be helpful in establishing whether there is a lawful basis. Your next step after that is either to complain to the ICO or to apply to court for a compliance order under Section 167 of the Data Protection Act 2018. The former is free while the latter is not and carries risks of cost if you are unsuccessful. If you opt for one of these steps, make sure you cite the relevant provisions of the GDPR and explain why you think there is no lawful basis for the data retention (including by referencing any response you received from them). &quot;I have read GDPR guides on how to request erasure, but I don't really feel this applies- I want to have my account deleted, not the track record of the loan and repayment&quot; It doesn't matter whether we are talking about your account or your track record. What matters is whether the account constitutes personal data, which it almost certainly does, per the definition at Article 4(1): &quot;‘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 such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;&quot;
I think there are a couple of different ways to look at this. Deduplication is a technical detail that's irrelevant here While the data may be deduplicated on a technical level, the files remain logically distinct. If users 1 and 2 upload identical files, and then one user edits or deletes their file, this will not affect the other user's data. Users cannot tell whether their files are duplicates of someone else. From the user's perspective, it makes no difference whether or not the storage uses deduplication, except perhaps via the cost of the service. Because there is no user-perceptible difference, it would be difficult to interpret some GDPR significance into this scenario. Whose personal data is it anyway? Personal data is any information that relates to an identifiable data subject. The files here are likely to be their uploader's personal data. Thus, the uploaders would also have a right to have their uploaded files erased. In case of deduplicated storage, this would affect their logical copy. The contents of the uploaded files might also be personal data relating to a third party. Then that third party might have a right to get the file contents erased. But this right must be invoked with the data controller for that processing activity, which might be company A, company B, or the uploaders, depending on context. Which leads us to the next aspect: Company A is not responsible for handling erasures From your description, it sounds like company A is a data processor providing services on behalf of company B. In turn, B might be a processor acting on behalf of the uploaders. In any case, it seems that A would not be the data controller for these processing activities. Data subject rights like erasure must be invoked against the controller, as only the controller can understand whether such a request should be granted. The right to erasure is not absolute, and depends a lot on why that data is being processed. In particular: Personal data need not be erased if it is still necessary For example, a person might very well be the data subject of some of these files, and might then ask for erasure. But if the files are being stored because they are going to be needed as evidence in legal proceedings, the data subject can't use this GDPR right to destroy evidence. The data controller would be allowed to refuse a request in such cases. It could now happen that two different users of this deduplicated storage are storing the same file, but for entirely different purposes. Blanket deletion of all copies of a file could be quite problematic. Note that deletion is also a &quot;processing activity&quot; and needs a legal basis under the GDPR. Unexpected data loss could be a data breach. One user's erasure could be another user's reportable data breach incident. Thus, I would strongly expect such requests to be handled on a logical file level, not on the deduplicated storage level. Caveat: public access and cloned files If the (logical) file is made available to the public who can then clone or copy this file, and if the &quot;original&quot; is taken down due to an erasure request (or copyright takedown notice), it might be appropriate to remove logical clones as well. Again, this might not involve deleting the contents on the deduplicated storage level, but it might affect other users' copies. In a GDPR context, the grounds for this would be the Art 17(2) right to be forgotten: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. But this depends crucially on who those other controllers are. If A is the sole controller, the logical files could probably be deleted directly. If B or the end users are controllers, it could be more appropriate to forward the erasure request to them.
It seems that A is the data controller and X is a data processor who processes personal data on behalf of A, and will only use the data as instructed by A. This will be formalized by a contract/data processing agreement per Art 28 GDPR, which is probably meant here by a “order processing contract”. The Art 33 GDPR responsibility to notify the supervisory authority in the event of a data breach lies solely with the data controller A, not the processor X. However, the processor X is required to notify the controller A “without undue delay”.