Do data privacy requirements apply to watch lists and sanctions lists? There are different sanctions lists and watch lists all over the world maintained by governments &amp; ministries, like well-known ones: OFAC lists, EU Consolidated Sanctions, CIA &amp; FBI watch lists and many more. They often contain quite a lot of personal information about name variations, addresses, DOBs etc. which is usually considered as PII (as soon as it allows identifying a person) and should fall into a regulation of GDPR and similar. However, this data is openly accessed and even aggregated by projects like OpenSanctions. So here's the question -- is it a special exceptional case that data privacy rules do not apply to sanctioned person data, or is it a worldwide violation of data privacy rules (very unlikely)? In a former case, who is authorised to decide that this person's data can be accessed without a restriction? A more practical question would be, if let's say I want to collect some data about disqualified directors in the UK (https://beta.companieshouse.gov.uk) or another country, should I apply technical measures in line with the regulation (GRPR for instance) to protect this data in my system (e.g. encrypt it at rest)? Please advise if it's an off-topic &amp; I should move this question to another hub.
There are a few different grounds under which PII can be handled. Perhaps the most discussed at the moment of GDRP introduction is consent, because of the wave of consent-seeking. But there are a number of other grounds. "Necessary for contract execution" is a trivial one, to deliver a pizza you'll need an address. The relevant ground for sanctions lists is also pretty obvious in hindsight, you may process PII in order to comply with legal obligations. Note that this is still an integral part of the GDPR, not an exception to the GDPR. That means you need to apply all the basic GDPR rules. You need to explicitly store where you got the PII from, for which purpose, and you need to document how you're using it. Note that this might be hard - why do you need to store this data? Why can't you just check the list as the moment it's relevant? The GDPR for a large part depends on you justifying your actions, not just in hindsight but already up front.
Does criticizing public figures constitute libel especially in a private group? It depends on the specifics, but a priori your description suggests that the defense of honest opinion would be applicable. This is regardless of whether the subject is a public figure and regardless of whether the statements were in private --albeit non-privileged-- communications. Case law surely provides guidelines or precedents on how the details and circumstances of the events would fare on the parties' legal position, but I am not knowledgeable of UK/English law. Does X have a counterclaim for illegally accessing the data? The matter seemingly depends on how the religious leader had or gained access to the data. Even if he gained access by stealing or hacking a device or account, X would not have standing to [counter-]sue unless the device or account belongs to X. Be mindful of the possibility that third party might have made the disclosure to the religious leader. In that case, actionability (if any) of the disclosure only encompasses the third party, not the religious leader. X's intent that his statements stay only among the participants does not necessarily imply that participants' disclosure elsewhere is unlawful.
Yes If you are in the EU, or your players are in the EU and your service is targeted at some part of (or all of) the EU, then this pretty clearly falls within the scope of the GDPR. Such a service would be collecting data associated with natural persons. At least some of it would be made public along with an online identifier, and other parts would be processed and stored, even if disclosed only in anonymized form. (By the way it is a non-trivial task to anonymize data well enough that it is no longer persona data under the GDPR. But let's suppose yoru methods are good enough.) Under GDPR Article 6 the DC must have a lawful basis for such processing. If the basis is &quot;consent&quot; then the consent must be freely given, whch means giving consent may not be a condition of using the service. Under GDPR Article 13 a notice must be sent to the Data Subject (DS) when the data is collected from the subject, including some 11 items or categories of information about the collection process, the Data Controller (DC), the purposes of processing, the legal basis of processing (which the DC must define), who will receive the data, the data retention period, and various rights of the DS. Such a service must be prepared to respond to data access and data erasure requests, under articles 15-17, and data restriction requests under article 18. It must provide a method for a DS to easily make such requests. Other GDPR provisions may well apply in addition to these, but that is enough to show that such service is very likely to be within the scope of the GDPR, unless none of the DSs are present in the EU or the related market area.
It would probably already be illegal based on national laws that comply with Directive 95/46/EC (of the European Parliament and of the Council of 24 October 1995). What's new with GDPR include: the sanctions that can be imposed the accountability i.e. you must be able to provide documented evidence on your practices even before something happens the obligation to report all data breaches. So you'd definitely have more concrete responsibility to follow good security practices under the GDPR.
The GDPR consists largely of principles instead of concrete rules. It's possible to reasonably believe that you are fully compliant, but then have a court rule against you. Thus, a company might mitigate risks by getting experienced compliance consultants, and by not toeing the line of what is and isn't allowed. But at some point, working to reduce the remaining risk is not worth the effort. This will depend very much on the business. E.g. an adtech business will likely want to tolerate more risk than a bank. As the interpretation of the GDPR evolves, compliance efforts must adapt. For example, the Schrems II judgement that invalidated the EU–US Privacy Shield shifted our understanding on the legality of international transfers. This judgement was not necessarily surprising for anyone who paid attention, so to some degree it was possible to prepare in advance. But that judgement was the kind of shift in jurisprudence where you can't fix your compliance by filling out one extra form, but rather have to rethink all international transfers of personal data – a blow to US SaaS providers and European SMEs that depend on them. Some parts of the GDPR are geared to assist with a compliance process. For example, larger data controllers must create a Records of Processing Activities (ROPA) register. This lists all processing activities and their legal basis, which helps spotting potential compliance gaps. Risky processing activities require an Impact Assessment (DPIA) where the controller has to weigh different factors against each other and determine appropriate safeguards. While the GDPR doesn't necessarily say whether something is allowed or not, it frequently provides factors that must be considered in an analysis. In addition to the GDPR itself, there's a lot of guidance available. Data protection authorities publish guidelines and can also be consulted directly. In fact, that's sometimes explicitly required. In the EDPB, the different authorities coordinate with each other and publish a series of EU-wide guidelines. Sometimes the subject is very specialized, sometimes the guidelines touch on a very general matter such as the concept of “consent”. These guidelines are an effectively–binding interpretation and thus bring welcome clarity to a compliance process.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
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.
Technically, yes, GDPR might apply. Filming other people does involve the processing of personal data, and GDPR will apply unless this is for “purely personal or household purposes”. But exactly that will be the case for most holiday snapshots or short clips for your personal social media. As far as I understand, you do not have to worry about purely personal activities. Even if GDPR would apply, this doesn't mean it would be illegal. It means you'd need a “legal basis”, such as a “legitimate interest”. If there are just a couple of people in the background of a video, it's possible that their rights might weigh less important than your interest in shooting the video – but that would need a case by case analysis. Your legitimate interest would almost certainly prevail if you need to record a crime to which you are victim. Regardless of GDPR concerns, note that this is just a small aspect of legal concerns. Instead, also consider personality rights copyright (if art or architectural works are visible) / freedom of panorama customs and reasonable expectations of other people These issues will depend largely on the specific country or area you are travelling to. Europe is not homogenous in its perception of privacy issues. For example, consider the issue of dashcams in a car. These are considered to be quite normal in some European countries, but effectively illegal in others.