Does the GDPR cover reference to court proceedings? On this site many good answers are referenced by real court cases, usually in the form Surname vs. Surname [date] &lt;link to further details&gt;. There also exist documents (example is US so as not to breach GDPR) that collect multiple court cases that share features, and publish them together. The UK Data Protection Act 2018 specifies additional rules about processing criminal offence data that are quite strict, and would seem to include posting court proceedings on stackexchange: What is criminal offence data? This covers a wide range of information about offenders or suspected offenders in the context of: criminal activity; allegations; investigations; and proceedings. you can only process criminal offence data if the processing is either: under the control of official authority; or authorised by domestic law. This means you need to meet one of the conditions in Schedule 1 of the DPA 2018. What is the law here? Is posting references to court cases in the UK/EU processing data? Is there an exception that allows this? Are we all breaking the law? What about stackexchange, who collects many of these references and makes them available to the public in a searchable form?
Privacy against publication of criminal convictions has been considered in the High Court in NT1 &amp; NT2 v Google LLC [2018] EWHC 799 (QB), if I may run the risk of posting a legal citation myself. But note that the claimaints there are anonymized, as often happens in criminal trials as well. In some cases, the court may give an injunction against disclosing names or details, and can hand down both a public and a private judgement, with the latter being a restricted document that does have the identifying details. So this question could only apply to mentions of criminal process where the accused is actually identified. (And I think just saying &quot;R v Smith&quot; is not enough - the posted or linked text would have to give some identifying detail about which Smith it is, the nature of the crime, etc.) I have no qualms at all about talking about NT1 and NT2. The claimants brought a case against Google for making available information about their long-spent convictions, including on GDPR grounds although it took place just before the implementation of GDPR in UK law. Dealing with that argument under the prior legislation, the judge found that of the various exemptions claimed by Google, the condition The information contained in the personal data has been made public as a result of steps deliberately taken by the data subject. (found in the Data Protection Act 1998, Schedule 3, paragraph 5, implementing the Data Protection Directive that preceded GDPR) applied, because of a longstanding principle for criminal conduct. The idea is that (paragraph 111): A person who deliberately conducts himself in a criminal fashion runs the risk of apprehension, prosecution, trial, conviction, and sentence. Publicity for what happens at a trial is the ordinary consequence of the open justice principle [...] The same must be true of the details of the offending, and other information disclosed in open court, including information about himself which a criminal reveals at a trial or in the course of an application. The core principles are the same as the carve-out from defamation law for the fair and accurate reporting of criminal proceedings (paras 44-49). That &quot;made public&quot; condition can now be found in a slightly different context in the Data Protection Act 2018, Schedule 1, Part 3, paragraph 32, which mirrors Article 9(2)(e) of the GDPR for the purpose of Article 10: This condition is met if the processing relates to personal data which is manifestly made public by the data subject. Since this is virtually the same condition of European provenance, in the same context of surrounding rules, I think the precedent is a good guide. For courts themselves, law reports, and journalism or scholarship, there are other specific grounds to rely on. Individual Stack Exchange posters are surely covered under the general exemption for posting on social media in a private capacity, GDPR 2(2)(c) as interpreted through its Recital 18. For the site itself, as in the case of NT1 and NT2, there could well be a legal claim made about the inclusion of criminal conviction information in a posted answer. (In general, such a post, being free text, could contain all sorts of defamatory statements or other objectionable content.) The court would have to look at the competing interests and the level of harm. NT1 was not successful but NT2 was. The example scenario, where we are talking about a very brief mention of a criminal case, cited because it illustrates a legal point rather than because there's anything relevant about the person mentioned, is quite far from the grounds complained of by NT2. For NT2, there was a newspaper article in which he was &quot;quite inappropriately, portrayed as one of a rogues' gallery of serious criminals&quot; (para 188), eight years after the end of his sentence, and it was this that he wanted removed from search results. In particular, the academic exemption (para 13) seems strong, in the same way that it would be for a publisher of legal academic content. The test of &quot;substantial public interest&quot; does not apply, because this exemption comes through paragraph 36 in the case of criminal convictions; it's enough to show a reasonable belief that publication would be in the public interest. Google was not able to rely on the &quot;journalism&quot; version of this exemption (again, under the prior law) because they are a totally generic search engine for all kinds of data and purposes (para 100 of the 2018 judgement). The public interest test, and the accompanying &quot;legitimate interest&quot; for the data controller, do not seem too difficult in this example.
This is a perfectly common question. &quot;What is your full name?&quot; &quot;Do you have any aliases?&quot; &quot;What other names do you go by?&quot; Like any other question, though, it must be relevant, and you should be prepared to explain why it is relevant. If the court allows the question, the defendant must answer.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
There’s some truth in it When a matter, particularly a criminal matter, is before a court or sub judice, public comment is forbidden and may be contempt of court unless they are “a fair and accurate report of legal proceedings held in public, published contemporaneously and in good faith.” Technically, it only applies to media reporting (probably including social media) and only while the proceedings are active. Proceedings become active when there is an arrest, oral charge, issue of a warrant, or a summons. Notwithstanding, there is nothing preventing an organisation having a “no comment” policy on any matter once there is police involvement.
You premise is correct. The processor is someone that processes data on your behalf, and since the GDPR definition of processing is extremely broad, that is about every third party subcontractor that you use for data processing, including various cloud providers. I'm afraid it will soon become a huge mess with a gazillion contracts to sign. I disagree. Yes, the GDPR says that a contract between the controller and processor must exist, but Article 28 of the GDPR does not say anything about how the controller shall document these instructions. Basically, in cases like the one you describe where John Doe relies on a web agency for having a contact form on the web, there will be a standardized (by the web agency) service agreement between the John Doe (controller) and the web agency (processor). There is nothing stopping the parties from agreeing that this service agreement that John Doe accepted as part of the onboarding procedure is also the DPA as required by the GDPR. Putting something like the following in the service agreement would do it: The parties agree that this Service Agreement between You (controller) and Us (processor) set out Your complete and final instructions to Us in relation to the processing of Personal Data and that processing outside the scope of these instructions (if any) shall require prior written agreement between You and Us. You also agree that We may engage Sub-processors to process Personal Data on Your behalf. The Sub-processors currently engaged by Us and authorized by You are listed in Annex A. I think we will se a lot of amendments in service contracts as the GDPR gets better understood, but I don't really see a flood of DPAs in addition to these amended service contracts.
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.
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!
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.