How long can an employer keep financial details after employee has left under GDPR? I finished a job in 2019, but just received notification of a data breach at that job in 2021, and my bank account number, sort code, national insurance number, full name, address and date of birth were compromised. As far as I know under GDPR data controllers can only hold data for as long as they have grounds to process it - does anyone know what this means in practice for HR and financial records? (e.g. why would they need my bank details for over a year after they had stopped paying me?) I'm wondering whether I have grounds for compensation or to sue my ex-employer for keeping such sensitive data for so long and letting it be compromised. Jurisdiction is England and Wales.
The retention periods depend on the exact legal basis for keeping such records. For example, accounting records might reasonably involve at least your bank account number, sort code, full name, and address. Under Section 388 of the Companies Act 2006, accounting records must be kept for three to six years, depending on the type of company (private or public). This would indicate that the company was within its right (and duty!) to hold records relating to at least the 2018 fiscal year.
gdpr The obligation to provide a privacy policy stems from GDPR Articles 13 and 14. When the information has to be provided depends on when personal data is obtained. Information under Art 13 (data obtained directly from the data subject) must be provided at the time when the personal data is being obtained. Since most websites will obtain personal data pretty much continuously, they will likely have to keep this information available continuously as well. Information under Art 14 (data obtained from other sources) must be provided within a reasonable time after obtaining the information, but at the latest when the data subject is contacted. So this depends very much on when data is obtained, and whether personal data is obtained directly from the data subject. E.g. a website generally obtains some personal data directly from the data subject every time a user visits the page, thus it will likely have to keep a minimal privacy policy available all the time, for all visitors (whether registered or not). In contrast, for individual instances of personal data processing, it may be sufficient to provide the information only once. For example, if we ask a user to enter information to enter a raffle, the privacy policy regarding the raffle might only have to be shown in context of the form where the user can enter data. However, all such approaches stink. Doing the bare minimum that's explicitly required is an easy way to run afoul of more foundational GDPR principles, e.g. the Art 5(1)(a) requirement that all data processing must be transparent (compare also Art 12(1)), and the Art 5(2) accountability principle: the data controller must be able to demonstrate how what they're doing is compliant. The Art 13 and 14 time frames are the latest point in time at which this information has to be actively provided to the user (compare also the guidelines on transparency WP260). But it would be entirely possible for a court to argue that the transparency principle implies that all such information must be available to the user for the duration of all related processing activities, possibly both before and after the data subject was explicitly informed. The WP260 document also emphasizes that the data controller must take the reasonable expectations of the users into account, and most users expect a “privacy policy” link in the footer of every page. As a more general point, the GDPR never requires that data subjects agree to a privacy policy. A privacy policy is largely unidirectional information, not a contract. Under some circumstances, the data controller may rely on consent as a legal bases for processing, and will then have to obtain consent from the data subject. In the course of this, it is necessary to provide information about the specific processing activities for which consent is being asked. Usually, this is done by a short summary with key information, and a link to the privacy policy for the full details (a layered privacy notice, compare the WP260 document and the EDBP guidelines on consent 05/2020). But valid consent can only be obtained for specific processing activities, not for a bundle of processing activities or a privacy policy in its entirety.
That GDPR Disclaimer is no protection in some jurisdictions: the applicable laws to that situation in germany for example don't care about the GDPR: Cold calling, mailing, or e-mailing private people to advertise services all is handled by the same law: Without the consent it is expressly illegal under §7 of the law against unfair competition (Gesetz gegen unlauteren Wettbewerb UWG) and such cases are rather Slam-Dunk if the origin can be made out. The punishment can be a 300.000 € fine. The fact that to email someone you need their e-mail address and that e-mail addresses and private addresses are by default considered personally identifiable information is making it worse for the advertizer: Without either an exception (there is none available to cold-emailing) or special allowance of the person the data belongs to, you violate §4 of the federal data protection law (Bundesdatenschutzgesetzes BDSG) just by handling their e-mail address. That's a separate crime from the UWG one, adding up to another 300.000 € fine under §43 BDSG - or even up to 2 years in prison under §44 BDSG! Oh, and if the email does not contain a proper sender's address, that's another chance for a huge fine under the UWG... So, GDPR is your least trouble, if you violate the marketing laws of a country, or their own data privacy laws. A disclaimer means nothing as the act of sending the mail, even to an unintended addressee, is what is illegal and the law as written does not give a damn about 'I didn't want to advertise to that person' when in fact you sent them unwanted advertisements. Oh, and the very repository you suggest? It would violate the very same §4 BDSG and be illegal for processing private data if it was not actively asked to do that by the end user. As a result, that database is useless: It does kick back all people not in its database. Its database is incomplete because only few people give their address to that database as people not aware of the database never add their data on their own. So it regularly violates §4 BDSG with every German citizen's e-mail address it gets and kicks back, and claiming those addresses would be OK, it throws the company trying to check the database under the bus because they rely on data that is impossible to be reliable. tl;dr Don't do cold-(e)-mail marketing. You throw yourself into boiling oil with a lit torch in hand. further reading Other laws banning such behavior I had listed here, and I quote myself: The US has the CAN-SPAM-Act, which illegalizes sending unsocialised advertisements. You may NOT send a mail if any of the following is true: it has no opt-out the email was gained by 'harvesting' contains a header not matching the text contains less than one sentence the adressee does not have any relation to you In fact, you are liable for a 5-digit fine per infringing e-mail in the US. The FTC itself suggests to never buy e-mail lists - as E-mail harvesting or generating any possible e-mail adress itself is illegal.
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.
The way you describe this UUID, it is pseudonymous data (see GDPR Art 4(5) and Recitals 28–29). That is, it is not directly identifying, but you have a mapping between pseudonyms and identifiers that can be used to re-identify this data. Effective pseudonymisation requires not only that the data is logically separate, but that there are effective organisational and technical measures preventing re-combination by unauthorized persons. Alongside with encryption, pseudonymisation is one of the safety measures that the GDPR explicitly requires whenever appropriate (see Art 25, Art 32). Pseudonymous data is still personal data, because you can easily re-identify the data. The PII concept is US-specific and is misleading in a GDPR context, where it is not the inherently identifying characteristics of the information that matters, but the realistic ability of the data controller to single out data subjects to whom this data relates (compare Art 4(1) and Recital 26). However, were you to irrevocably erase the UUID–email mapping, things are more tricky. There is no longer any connection with directly identifying data, so this data might be anonymous. On the other hand, such a persistent UUID still allows you to recognize/distinguish persons, so it might still be personal data. This might be the case especially when the UUID is used in long-lived cookies of website visitors, thus matching the GDPR's concept of an “online identifier”. This conclusion could be avoided by limiting reuse of UUIDs, e.g. creating a new UUID after some context-dependent appropriate duration. The GDPR does not require all data to be stored in the EU, but requires international transfers of personal data to have sufficient protections. If you're processing these data in countries without adequate legal protections (like the United States), additional safeguards have to be used. Pseudonymisation could be part of such safeguards, and has been suggested by some data protection authorities in the wake of the Schrems II ruling. However, pseudonymisation alone does not make the international transfer legal, it is more of a strategy to reduce remaining risks. I think that your systems has a good chance of being OK, but not neccessarily so. If in doubt, perform a DPIA and possibly consult your data protection authority under GDPR Art 36. If feasible, storing/processing data only in the EEA or in countries with an adequacy decision will simplify compliance. Safeguards such as pseudonymisation could be strengthened by rotating UUIDs, and by restricting access to the table with identifiers.
Contacting a business email about a business matter is usually fine, but in this case we have an unsolicited marketing communication (spam), not really a business matter. The client's jurisdiction likely has more specific rules about spam. Also, it is unusual (read: presumably illegitimate) to contact individual employees rather than the company's official address with the offering. From the GDPR perspective, every processing of personal data (such as email addresses that might identify natural persons) needs a legal basis (Art 6). Let's go through them: consent? No. necessary for performance of a contract involving the data subject? No. legal obligation? No. vital interests? No. public interest? No. legitimate interest? Perhaps. The client has a legitimate interest to conduct their business. However, this legitimate interest must not be overridden by the data subject's interests, rights, and freedoms. Such as the interest in not being disturbed by spam mails. It is the Data Controller's (your client's) responsibility to balance the legitimate interest themselves to determine whether they have a legal basis, but I really don't think that they do. In conclusion, your client's idea is a bad idea: They likely do not have a legal basis for this under the GDPR. They are likely violating more specific anti-spam laws in their jurisdiction. They are working hard to get their domain put on spam filter lists. Note that already the step of collecting employee email addresses is personal data processing and needs a legal basis. Of course, the GDPR does not apply when the client is not established in the EU and only processes the addresses of persons that are not in the EU.
Congrats, you've done well to minimize your processing of personal data. But I think you're still processing personal data, and are subject to the GDPR. Serving a website necessarily involves processing an IP address. This IP address will typically be personal data. While you are not storing the IP address, the GDPR's definition of “processing” extends beyond storage and pretty much covers doing anything with that IP address. As far as I know this is not an entirely settled matter, but it's better to err on the side of caution and to assume that you are in fact performing a processing activity. Even a static web page can easily lead to additional relevant processing of personal data, for example if the HTML embeds resources from third party domains. Since your website is clearly targeted at the public, it does not fall under the GDPR's exception for “purely personal or household” purposes. So I think you do need a (minimal) privacy notice that contains at least the items mentioned in Art 13 GDPR. The main reason why some people try to avoid posting a privacy notice is because it must disclose your identity and contact details. But in Germany, that information has to be provided anyway due to the Impressumspflicht. As part of your GDPR compliance obligations, you must protect how data is processed by others on your behalf. A hosting provider will typically act as your data processor. For this to be legal, you need a contract / data processing agreement that fulfills the conditions in Art 28 GDPR. This contract binds the data processor to only use the data as instructed by you, and not for their own purposes. European hosting providers sometimes include the necessary terms in their terms of service / AGB, but you should check to make sure. Netcup expects you to accept their data processing amendment in your account settings. In the hypothetical case that you were not processing any personal data at all, the GDPR would not apply and it wouldn't require you to post a privacy notice. Other laws might still have information obligations, notably the German TMG and TTDSG.
The data controller is obliged to use “all reasonable measures to verify the identity” of the person exercising their data subject rights (GDPR, Recital 64). That sentence has caused a lot of confusion: “all reasonable”: does this mean all measures the controller can be reasonably burdened with, or all measures that are necessary for identifying the data subject with reasonable certainty? “identity”: does that mean the identity of a natural person, or just a check that the person exercising their data subjects rights is identical with the data subject? So depending on how the company interprets this, there is a lot of leeway regarding which info may be requested from you. In general, being able to log in to the service should be all that is necessary (compare also Recital 57). Note that the company doesn't just have to satisfy your data subject rights, they also have to protect your data against unauthorized access. Giving an attacker access just because they control a particular email address might not be secure enough (but is in practice because the attacker could use a password-reset functionality to get the full credentials anyway). You do not lose your data subject rights if you used pseudonymous/fake data: the service may still contain other personal data regarding you, for example usage profiles. You are still a data subject. Pseudonyms can also be identifying data, e.g. Art 4(1) calls online handles out as a kind of personal data. However, this does lead to complications with companies that interpret identity verification as ensuring that the person making a request is a particular natural person. If the controller isn't sure about your identity, they can request additional information (Art 12(6)). If the data subject cannot be identified, the data subject rights do not apply (Art 11(2)). However, that describes a subtly different scenario: that the data held by the controller lacks identifying data. You do have a right to access and a right to rectification (correcting the data they hold about you). However, they require the exact same identity verification as the right to erasure. That you were underage at the time of account creation is likely irrelevant now, if the data in the account doesn't indicate your true age. Unless the subject matter of the online service makes an age restriction necessary, the relevant age limits are 13-16 years (Art 8 GDPR, subject to EU member state laws) or 13 years (COPPA, U.S.). If you believe you have provided all data that is reasonably necessary to verify your identity and your data subject rights are denied to you, you can issue a complaint with your local data protection authority. In Germany, each Bundesland has their own Datenschutzbeauftragte agency. Below, relevant GDPR excerpts used in this answer. “Erasure” is Art 17 but Art 12 covers modalities for exercise of data subject rights. Recitals are explanatory but not normative. Art 12(6): Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. Art 11(2): Where […] the controller is able to demonstrate that it is not in a position to identify the data subject, […] Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification. Recital 57: Identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller. Recital 64: The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers.