Does GDPR apply to internal employees data? Currently, our team has a number of internal tools that aid the testing and deployment of our products. These are used solely by internal employees, and record actions taken (such as when a file has been viewed). The recorded data contains identifiable information, such as their Windows username - which can be used to identify a specific individual. We also process this data, to provide statistics on individual's work, to managers who are also internal. Does this data, also need to comply with GDPR - or does GDPR only apply to data from the public?
Yes, it also applies. However, an employment implies they agree to having employment related data stored and processed (e.g., to be paid). When there are performance related bonuses in the contract, this will likely (but IANAL) imply they agree to performance data being collected and stored appropriately. Furthermore I would assume most of such data processing (such as knowing who is responsible for a certain change, who created a file, modified it etc.) falls into "legitimate interests" of the employer, as this information may be necessary for operations. I'd assume (still IANAL) that much of the consequence wrt. GDPR is the right to have your data erased. So a company should be prepared to remove such data when an employee leaves the company, e.g., by clearing the responsible person fields upon request. At least for data where there is no legal requirement to have such data provenance. But: consult your lawyer for a proper legal opinion!
The GDPR does not outlaw such processing of personal data. It merely regulates how and for what purposes you can process personal data. In general, you can conduct any processing activity as long as it has a clear purpose and a legal basis. Here, the purpose would likely be something like “conducting business with my clients” and the legal basis would be a “legitimate interest”. A legitimate interest always requires a balancing test that weighs your interests against the interests and rights of the affected persons. For example, can the affected persons reasonably expect such processing activities? In a professional setting, it can probably expected that business partners keep notes about contact persons so your intended processing could be fine. The GDPR does impose some general constraints. There are general principles like data minimization and storage limitation – you should only collect data that is necessary for your purpose, and shouldn't store it for longer than necessary. You should think about appropriate technical and organizational measures (TOMs) to protect the processing activity, for example about how your CRM is hosted, how backups are made and how security updates are installed, who has access to the personal data, and how the people with access to the personal data can be trained. For example, such training might inform your employees that they can only use the data in the CRM for business purposes, but absolutely not for personal purposes like asking Gina from reception out for a date.
According to my knowledge I am not allowed to share other people's full name nor phone number nor email address without their permission. That is not correct. According to GDPR Article 2: This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. This Regulation does not apply to the processing of personal data ... ... (c) by a natural person in the course of a purely personal or household activity; GDPR Recital 18 states in relevant part: (2) Personal or household activities could include correspondence and the holding of addresses, or social networking and online activity undertaken within the context of such activities. Personal data that is not processed by &quot;automated means&quot;, for example data which is transmitted verbally, by hand writing, or by manually sent email, is not covered by the GDPR. Data which is used by a natural person for &quot;personal activities&quot; is also not covered. Consulting one's personal lawyer might well be a personal activity unless it is a business matter. Even if such a transfer of data were in scope for the GDPR, consent of the data subject (DS) is not the only available lawful basis. GDPR article 6 permits any of several possible lawful bases to be used, particularly paragraph 1 point (f) which reads: (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Also possibly relevant is point (c) which reads: processing is necessary for compliance with a legal obligation to which the controller is subject; In short, providing one's personal lawyer with the names and addresses of relevant people in connection with a legal issue is not at all likely to be prohibited by the GDPR, nor to require the consent of the people whose names and contact info are provided. However, a comment by user PMF reads: The Data Protection laws are mostly for companies, not for individuals. This is an overstatement. The laws do apply to natural persons as DCs, although enforcement is largely targeted at businesses, particularly large, for-profit businesses.
The GDPR allows the right to access to be limited if this access would “adversely affect the rights and freedoms of others” (Art 15(4) GDPR). However, access to the recording would not give you more information than you've already received during the phone call, so this exemption is quite unlikely to apply in any case. UK data protection law also has a large list of additional exceptions, as summarized here by ICO guidance. These exemptions also cover some aspects of trade secrets, and even mention insurance examples. However, not such exemption is likely to apply in your case: the recording would not give you more information than you already have. If the data controller is concerned about some parts of the conversation, they should provide a redacted copy and explain why the redactions were performed. They should not reject the request outright. If the data controller wants to reject the request entirely, they must do so within the time frame for the DSAR (one month), must explain their reasons, and must inform you that you're allowed to lodge a complaint with your supervisory authority or to sue them. However, ICO guidance is flexible on how detailed the reason for refusal can be: Where an exemption applies, the reasons you give to an individual for not complying with a request may depend upon the particular case. For example, if telling an individual that you have applied a particular exemption would prejudice the purpose of that exemption, your response may be more general. However, where possible, you should be transparent about your reasons for withholding information. Here, I don't see any reason why full transparency would be a problem, so I would expect that the data controller can point to a specific exemption in UK data protection law. If you are unsatisfied with the data controller's response, please consider lodging a complaint with the supervisory authority. In the UK, this is the ICO. On the ICO complaints page, you can fill out the online form about “your personal information concerns”.
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
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;