What legal conditions do I have to meet to open an open source website? I'm working on a website for a pretty long time and in the close future I want to open it into the public. The problem is, my website collects personal data and cookies which (in my country - Poland) must be documented in something called privacy policy because of GDPR, etc, etc. I've written some basic policy, but I'm stressed about locations. In every policy I saw, there were an address of a company working on the site. I don't want to share my private address. I'm scared about this.
Don't collect or process personal data Many (though of course not all) websites can easily be run without collecting or otherwise processing any personal data. The position of GDPR is that if you are not able to fulfil the basic, simplest core conditions for processing personal data (understanding what you're processing and why and why it's allowed, describing it in a privacy policy, having a non-underage person who's responsible for that) then you are not allowed to process personal data of other people. So don't. Build your website so that any personal data are not collected.
Does GDPR apply if my web app stores personal data on the user's phone only? No. If you are not processing Personally Identifiable Information (PII) then the GDPR does not apply to you. This is what a web browser does when it asks to remember your username and password for this web site. You are providing a tool, the user is using that tool to process their own data. I do offer to back up the user's personal data At this point you are processing the users PII, and the GDPR does apply to you. Even though you do not have enough information to identify an individual, as it can be used with other information to identify an individual it is PII. From the ICO: Can we identify an individual indirectly from the information we have (together with other available information)? Even if you may need additional information to be able to identify someone, they may still be identifiable. That additional information may be information you already hold, or it may be information that you need to obtain from another source. When considering whether individuals can be identified, you may have to assess the means that could be used by an interested and sufficiently determined person.
The employee must, during and after employment, without limitation in time, observe a duty of confidentiality regarding [...] the Company's internal affairs such as business plans, profitability, pricing, employees, methods, processes, routines, code and the like as well as other information that the Company typically wants to keep secret The pure information that the company had at some time a security problem with their product is internal knowledge you only gained through working there. By what is written here, you are indeed prohibited from speaking about it. If it were public knowledge, you could point to a press release and say &quot;I did that, that was me fixing the problem&quot;. That would work. Because it doesn't share anything that isn't public anyway. But you cannot share things the company wants to keep secret. Finding out whether that contract is legally enforcable in your country and juristiction is the job of a real lawyer, but just as written, they are right. You signed a contract to not do that, not talk about it an certainly not publish it on the internet. So you should not do that, unless a good lawyer you trust tells you otherwise. That said, &quot;I found a security flaw&quot; is about as impressive as &quot;I found a dollar on the floor&quot;. Maybe you can talk about your knowledge to prevent something like it happening. That says nothing about whether or not it happened in your old company, and for me as an employer it is much more valuable to have you on board with structured knowledge you can apply, than with your memories of being lucky once.
If you are not processing the personal information of EU citizens yourselves then you are unlikely to be classed as data processors under GDPR (check Article 3: Territorial Scope, p.32-33). If you were to operate a Software-as-a-Sevice (SaaS) solution then you would be a data controller/processor (or both) and GDPR would certainly apply if you have EU citizens as customers/users. While I can't see any reference to software vendors in the GDPR text, as a software vendor it would be in your interest to ensure your products meet the criteria set out in Article 25 (Data Protection by design and by default, p.48) in order to help your customers to comply, such as: Implement appropriate technical measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects. Implement appropriate technical measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons. These along with similar organisational measures are the responsibility of the data controller, but unless your software helps them to comply they may be forced to consider alternative solutions which reduce their overall risk. If your software already has a number of such controls in place it may be worth putting a white-paper or similar communication together which can inform your customers of how your software helps them to comply. There does not appear to be any direct liability to the software vendor through GDPR. If a data breach is the result of a design flaw or implementation bug in the software and your customer gets fined as a result, they may be likely to pursue you on grounds of the software not being fit-for-purpose and lacking the appropriate technical controls required to ensure data privacy. In this event, your defence will rely upon records of designing and implementing controls, records of software testing and remediation, and having in place suitable procedures to ensure security patches can be quickly deployed to your customers when required. Further clarification as requested: If your organisation doesn't process the personal data, doesn't have any third parties process it on your behalf (includes hosting companies) or have any access to it ever, then you're neither a controller or processor. However, if your customers ever send you personal data or grant you temporary access to personal data as part of troubleshooting issues with your software, then you would be a processor in this context and would need an appropriate contract in place and would need to ensure the appropriate technical and organisational controls are implemented to comply with GDPR and reduce risk of a personal data breach. Additionally, if international data transfers take place as part of this (e.g. sending/accessing files over the Internet) you would need to ensure your organisation is able to provide an equivalent level of protection for the rights of the data subjects - for example if you are in the U.S. you would likely need to voluntarily join up to the EU-U.S. Privacy Shield or use the EU's Model Contract Clauses within your contracts in order for it to be legal for EU-based businesses to use you as a data processor. For more information about international transfers read the EU's Data Transfers outside the EU page. Ref: GDPR
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.
GDPR does not cease to apply because of the location of data storage. It applies based on the location of the data processor, data controller, and data subject. If you are in the EU, you are a data subject covered by GDPR. It does not matter where the data are stored. Note that you are asked to confirm that you're aware that US laws may be less protective, but you're not asked to acknowledge that anything about the arrangement causes the "laws of your country/region" not to apply. The company also does not seem to be claiming that they don't apply, although it seems that they want you to think so, and it's not clear whether they think so. You are correct that GDPR doesn't allow its protections to be waived. A data subject may always consent to certain processing, and some processing may be performed without consent, but it's not possible to waive the right to withhold consent for processing that does require it.
Question 1. Are technical identifiers personal data? Yes. If they identify a person. For example an IP Address is considered personal data, because a person or household can be identified by an IP. Yes, I know that technically there are a lot of exceptions. But in general, if you have an IP, you can identify the subscriber given the right databases. So if your identifier, lets say a generated GUID, identifies a customer or something the customer can be linked to, it is personal data. Question 2. Can technical identifiers be stored in measurement devices? Just because something is personal data, does not mean you are forbidden from using it. As long as you need it to do your job, you can store it. The internet would not work, if everybody was forbidden from storing any IP address. So to summarize it: yes, it is personal data since it identifies a subscriber. However, it is needed for the job your subscriber asked you to do. So for as long as the job takes, it is legal to store it. Once your job is done, you would be required to delete it. But consent trumps everything. If your subscriber consents to you keeping all data of such incidents to improve your network and handle future incidents better, then it's legal. Just let them sign it with your other legal paperwork. Done. No problem. You could just periodically delete all records that have no consent for long term storage beyond the current incident. Lets say every 24h or 48h. You should get the details on the wording of the paperwork and the period that it is legal to keep the data as &quot;current incedent related&quot; from your data protection officer or legal department.
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. And Article 7.4 backs this up with When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.