Is revision history (audit/change log) compliant with GDPR&#39;s right to rectification? Assume, there's a model called CustomerDetails, which contains the following properties: ContactEmail - an email address for contacting purposes, ContactAddress - a postal address for contacting purposes, DefaultDeliveryAddress - default address for delivery when creating orders, DefaultInvoiceAddress - default address to be printed on invoice, when creating orders, and other properties. All entities in the system are by default audited, ie. they contain change log / revisions history. Any user can change own CustomerDetails data by himself/herself. If user changes that information via web-interface, then what is correct: there can be no trace of previous information: no revisions history for the CustomerDetails entity, or there must be a possibility to delete own revisions for user: extra user interface to view+delete revisions, or there is only obligation to delete revisions of CustomerDetails, if Right to erasure (‘right to be forgotten’) is exercised?
The GDPR does not mandate specific features, but that any processing is lawful and transparent etc. So what would be the purpose of storing a revision history? Once that is clear you can work out an appropriate legal basis (e.g. a legitimate interest) and then figure out which data subject rights apply. For example, let's assume that there is a security interest in keeping a revision history, so that (a) mistaken edits can be rolled back, and (b) the user can be notified of possibly unauthorized changes. This would be a legitimate interest primarily of the account holder, secondarily of you as the system operator. Of course, such security requirements have to be proportional, but I'd see that as given when there's a payment method on file. You are required to apply appropriate safety measures and to apply the data minimization principle. E.g. is it necessary to store this revision history for all eternity? No, one or two months will likely be sufficient. Who should have access to this data? If the purpose is to defend against unauthorized access, it could make sense to only give out this data on request, and otherwise only make it available to support and security staff. Now we can discuss how this interfaces with rectification or deletion. That the user is able to rectify their data themselves is very good. However, that doesn't imply a prohibition on keeping a revision history: the revision history indicates what data was stored at what point in time, and is by definition correct. This assumes that you are not using the revision history for any other purposes. When the legal basis is a legitimate interest, a request for erasure has to be preceded by (or implies) an objection (opt-out) to further processing. The objection must weighed against the legitimate interest: the objection can be denied when there are overriding grounds to continue processing. This might be the case for a security purpose: if someone with unauthorized access can just erase their traces, the purpose cannot be achieved. But perhaps the user could opt out when they create their account? Or opt-out later, but with some delay to still achieve the security purpose at the time of opt-out? In any case, erasure is required when the data is no longer necessary for its purpose – this ties back to picking an appropriate retention period, as discussed above. So it's not really possible to provide a general answer, and it really depends on the specific purpose you are trying to achieve.
You seem to have a solid understanding of the ePrivacy implications, but lack a fundamental insight: your organization does not have a right to achieve its mission or a right to disseminate unwanted marketing. But other people do have a right to not be subject to excessive marketing. Of course, reality is more complex, so it's probably not entirely impossible to do marketing. In your point 1, you note that some EU/EEA/UK countries distinguish ePrivacy protections between consumer and business subscribers. You can research the exact rules in the potential customer's country. This may allow you to email corporate/business accounts. I would strongly advise against messaging via Linkedin if there is a chance that the person is using that account for personal purposes like networking or hunting jobs, not just for conducting official company business. ePrivacy has markedly different rules for email marketing vs phone marketing. Whereas there are pretty strict rules for electronic messages and robocalls, manual cold calling can be OK from an ePrivacy perspective. However, many EU/EEA/UK countries have rules that go beyond ePrivacy, and may have a kind of do-not-call registry that you must respect. Of course manual calls take more effort than spamming emails, but recall the above point that you don't have a right to spam other people. Phone calls are probably the most appropriate approach when the company lists individuals' phone numbers on its website. This will at least give you a few seconds of attention with a real human, more than you can expect from an email that is likely to be caught by spam filters. Marketing via physical mail tends to have very lax rules. Note that every company/business that has a website will have to disclose its contact details including an address there, so this information is easy to acquire. However, chances are low that anyone would seriously engage with that marketing. You can consider alternatives to direct marketing, so that interested companies eventually come to you. Things like press releases, writing guest articles in industry publications, speaking at relevant conferences, working on search engine optimization, buying ads. On the GPDR aspects: GDPR and ePrivacy overlap, and it is necessary to comply with both sets of rules (GDPR likely applies here via Art 3(2)(a)). But where they potentially contradict each other, ePrivacy as the more specific law has precedence. For example, ePrivacy overrides the default GDPR legal basis rules when it comes to email marketing to existing customers (opt-out basis, no consent needed) or to using cookies (needs consent unless strictly necessary). Information that relates to corporations is not personal data, but information that relates to individual employees or to sole proprietors would typically be personal data. Since you are unlikely to obtain consent for using this data, you would need an alternative GDPR legal basis such as a &quot;legitimate interest&quot;. Relying on a legitimate interest requires that you conduct a balancing test, weighing your interests like marketing against the recipient's interests, rights, and freedoms. Core question in this context is whether the data subject can reasonably expect their personal data to be used like this, taking into account the nature of their relationship with you. Since there is no pre-existing relationship, claims of a legitimate interest are weak to start with. However, it may be possible to argue that when a company makes employee contact details available via its website (not LinkedIn!) then relevant marketing can be reasonably expected. I would rather not rely on such arguments, though.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
If you mean the Regulation of Investigatory Powers Act 2000 (aka RIPA), it doesn't provide for mandatory retention of communications data. Broadly speaking, RIPA is about interception as opposed to mass surveillance or retention just in case. The Data Retention (EC Directive) Regulations 2009 obliged &quot;public communications providers&quot; to retain what is commonly known as 'metadata', i.e. information about the communication - the originating phone number, the receiving phone number, the date, time and duration (if relevant), the type of call or message - not the content of the communication. See Schedule 1. In April 2014, in the case known as Digital Rights Ireland the Court of Justice of the European Union declared the EC Directive invalid. In response, the UK made the Data Retention and Investigatory Powers Act 2014 (DRIPA) - sunsetted on 31 December 2016. This provided for the Secretary of State to issue a data retention notice to a communications services provider (CSP), requiring it to retain the data types set out in the Schedule to the 2009 Regulations. DRIPA's Explanatory Notes support my claims above with a summary of the history. This was replaced by the Investigatory Powers Act 2016 (IPA), Part 4 of which deals with the retention of communications data. Here too the retention is of the metadata not the content (see s11(87) and the Explanatory Notes).
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.
The GDPR does not provide specific rules about password resets. However, the GDPR contains a general obligation for the data controller to implement “appropriate technical and organisational measures” (TOMs), see Art 24 + 32 GDPR. What is appropriate depends on the “state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity”. A password reset functionality is complicated from a security perspective. On one hand, such functionality is really good because it ensures availability of the service for the user. On the other hand, such features can provide a backdoor to the service, undermining security goals such as confidentiality and integrity. These aspects must be balanced, and there is not necessarily one correct balance for every scenario. What the one-person IT department of a small company does can reasonably be different from what a multi-million user social network does. TOMs do not have to be purely technical – they can also include organisational aspects, for example training for customer service employees, and occasional checks to ensure that customer service staff doesn't abuse their access. But nevertheless, TOMs must be measured against the state of the art. Password reset by sending a time-limited one-time reset link with a cryptographically secure nonce to an email address is a state of the art method, assuming that no 2FA/MFA is involved. In some contexts, having customer service staff assign a new, random, one-time password could also be appropriate, for example if implementing a more secure workflow would be prohibitively expensive. Then, organizational measures would be more important. Failing to notify the account holder that someone requested a password reset is not state of the art, and represents a possible security risk. The data controller is required to defend against such risks! Resetting the password to a fixed default value is a very grave security risk, since it could aid unauthorized account takeover by a third party. It is unlikely that such a password reset approach could be GDPR-compliant.
Is there any sources of information where extraction of data from a closed source application and provided to a data subject is further defined? No, the GDPR is based on &quot;general principles&quot; and does not concern itself with implementation details for such matters. It's possible there's EU case law on this, but I can't find any. Am I within my rights to insist on this, even if to comply they would have to do some software development? Yes you can demand it, but they don't have to comply with your demand. The information only has to be provided in a &quot;concise, intelligible and easily accessible form, using clear and plain language.&quot; and they only have to provide the information electronically where &quot;reasonably practical&quot; to do so, and they only have to take &quot;reasonable steps&quot; to do all this per Section 52 of the Data Protection Act 2018 which implements GDPR into UK law. You can complain to the Information Commissioner's Office, and they will decide if Section 52 has been complied with or not. 52 Form of provision of information etc (1) The controller must take reasonable steps to ensure that any information that is required by this Chapter to be provided to the data subject is provided in a concise, intelligible and easily accessible form, using clear and plain language. (2) Subject to subsection (3), the information may be provided in any form, including electronic form. (3) Where information is provided in response to a request by the data subject under [the Right of access by the data subject], the controller must provide the information in the same form as the request where it is practicable to do so.
The GDPR's right to erasure just applies in some specific situations. While messages you wrote on Slack are personal data, they are generally also part of a larger discussion with others. If your messages are removed, the discussion becomes incomplete, so that will violate the freedom of expression of those others. Art. 17(3) GDPR provides an exception for the right of erasure in such cases. So basically, whoever is the controller, you probably don't have the right to have your messages to be deleted. However, you would have the right to have your account pseudonymized like Slack replied in the Reddit post you linked to. See also my answer in "Does a user have the right to request their forum posts deleted?". Basically, it is correct that Slack can be just the processor. Even if the controller cannot get access to more than 10000 messages unless they pay. However, Slack is not allowed to do anything with those messages, except when the controller says so. In its Privacy Policy, Slack distinguishes between customer data and other data. It states to be the processor for the customer data, but controller for the other data. Because those are tied together, I am not sure this distinction can be made. If not, Slack and the customer will be joint controllers, but it requires probably a court case to decide on that. For example, the Court of Justice of the European Union has ruled (in the Fashion ID case) that putting a Facebook "like" button on your website, makes you a joint controller together with Facebook. And (in the Wirtschaftsakademie case) that also creating a Facebook "fan" page makes you a joint controller. But neither of those are very similar to the situation with Slack.