Is a bank account history of transactions considered personal data in the sense of GDPR? For archival purposes, I'm trying to get the full history of transactions on my bank account since I opened it in 2019. I know my bank still has it since it's visible in the mobile app (I can scroll down to the very first transaction). However, there's no way to export it in a processable manner (the online export form only gives one month of transactions, and there's a paid service that can get up to two years). I sent an e-mail to my bank asking for a dump of all the personal data their systems contain about me (as per GDPR article 15), and they provided me with... my name, address, phone number and SSN. In their (the DPO's) response, they wrote that any request about the transaction history is to be made to my bank advisor – this is not what I want, since they then point me to the paid service that only gives 2 years of operations. In any case, I understand that transactions on my account fit the definition of personal data since they're directly attached to my bank account, which is under my name, and that since the transactions are stored on their systems I should be able to get them in a processable format as per article 15. Am I wrong in that understanding?
Yes, your transaction history is your personal data. Personal data is any information relating to an identifiable person. Your transaction history relates to you, and you're definitely identifiable for the bank. You have access to the transaction history to the app, which would probably satisfy Art 15 GDPR. You do also have a right to data portability under Art 20 GDPR which allows you to get your data in a machine-readable format – but strictly speaking this right only applies to data you provided yourself. You could try to explicitly invoke this right. Your GDPR rights must be satisfied without cost. Your bank almost certainly does provide machine-readable API access, in conformance with the open banking mandate from the Revised Payment Services Directive (PSD2, Directive (EU) 2015/2366). The Directive requires your EU member state to have passed a law that gives you “the right to make use of services enabling access to account information”, if you're already using online banking. However, the exact details of that right will depend on the laws in your EU member state. You might already be able to connect to your transaction history via Open Banking software such as GNU Cash.
My interpretation of the GDPR when it comes to a contact form is as long as your privacy notice states that what data you collect in the contact form and what legal basis that data is used for you are fine. Someone submitting a contact form in my opinion is their consent to reply back to them regarding the data in which they have submitted. Another good clause to have in your privacy policy is to basically state if the user submits information about another natural person that they have consent from that natural person for that data and what it would be used for. The internet is the internet. People have been trolling it for years. People have also submitted false information for years. The best a business can do is simply outline what their site does, what data is collected and what it will be used for. That along with what legal basis it’s processed for and following it makes you GDPR compliant in that regard. As to withdrawing consent and the rights given by the GDPR that’s all specific to what infustructure a business has in place. As a developer I know the headaches of the GDPR. Most of it resides in the fact data is not centralized and thus can’t easily be retrieved, modified, or removed. Once you’ve tackled that aspect providing the user their rights under GDPR isn’t to far off.
An app(lication program) is software run on the end-users machine. That does not fall under the GDPR. Any processing (including storage) you do on user data has to be compliant with the GDPR. Allows a user to authenticate via e.g. Facebook and stores some basic data (optional) Authentication via Facebook leaves GDPR compliance to Facebook (AFAIK). It would be a good idea to provide alternative authentication methods, such as Google and an "own account" user name and password so that the user doesn't have to share information with a multinational company in order to use your service. The "basic data" will need to be processed according to the GDPR. As long as the "optional" part is "opt in" (i.e. the user needs to at least click on something) then this means you have permission to process that data. Providing this "basic data" as a JSON or CSV file should meet data portability requirements. Allows a user to upload a GPX file (a route or some other activity) Stores the above file to Google's database Allows the user to analyze that file. Since the user is actively choosing to upload each file you have permission to do this. You should make it clear in your privacy policy that the data will be held by Google. Doing so should not be a problem as Google has set up the legal framework to do this under the GDPR. You don't have to store the information encrypted, but you should use encryption (e.g. HTTPS) for any data transmission. Allowing the user to analyse the file is not an issue; either the user is doing it on their own machine (GDPR irrelevant) or you are doing it under user instruction (meaning you have consent). Since the user has uploaded GPX files they already have data portability on those files. You should tell your users that while you will employ best endeavours you don't promise to keep their files accessible and they should maintain their own private copies. That way if your entire database gets corrupted they can't blame you for loss of data. Finally, make sure there is a "Close my account and delete all my data" option.
The European Convention on Human Rights has an article about privacy (article 8). Note that this is from the Council of Europe, which is not the same as the European Union: non-EU member states such as Russia, Turkey, and Azerbaijan are also part of the Council of Europe and therefore the ECHR. I'm not sure if you first have to go to a lower court, but the European Court of Human Rights is the authority on this (commonly mistaken for the European Court of Justice, but they are distinct entities). According to this ruling of the ECtHR, it is not illegal to monitor your employees' communications per se. However, the monitoring has to be: for legitimate purposes ("the employer had only accessed the account in the sincere belief that it contained only messages of a professional, not personal, nature"), proportionate ("it was the only possible way available"), and communicated to the employee (or, if the monitoring is not announced, at least the restriction on personal use should be communicated, for example through company policy). In the European Union, there is also the GDPR, but this does not change much. It applies to your employer the same as any other organisation and basically says that they have to be reasonable about it: collect only what they need, for a legitimate purpose, and tell you about it. I think you should be able to request a copy of any data they collected about you, ask a human to review an automated decision, and your other usual rights. They don't need your consent to start collecting data, as Esa Jokinen already commented: "GDPR doesn't even require consent to handle PII data, but the consent is just the last option when there's no other legitimate reason to process the data." In fact, your employer probably cannot ask you for consent: because of the employer–employee imbalance of power, the consent would probably not be considered to be freely given (where this article mentions "The GDPR states", I think they are referring to recital 43).
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
The conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. As for it being legal for website operators to log the IP-addresses of visitors, this is covered by the following paragraph (also pointed out by phoog in a comment). The paragraph says it is legal to process personal data if 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. (my emphasis) You are not the only web site that logs IP addresses for the purpose of security. Every web site I've ever worked on - from those controlled by large corporations to tiny NGOs - do this. This security practice will not be impacted by the GDPR (if it were, I am sure we would have heard about it by now). there is the EU cookie law too If your website are going to be accessible to European citizens and not only accessible by your friends and familiy, you have to comply with the EU cookie directive of 2002 (a exemption for "personal websites" does not exist).
Personal data is any information relating to an identifiable person, whether that information is public or not. The student website is definitely processing personal data of faculty. Any website is also necessarily processing personal data of visitors due to technical reasons, even though hosting has been outsourced to a third party. There's always a server, you just might not be managing it yourself. Thus, GDPR applies. Just because it processes personal data doesn't mean that the student website would be illegal. It just means the students are responsible for GDPR compliance of that website. Since the website is controlled by students and not by the university, the university DPO has no say here and the university can't demand the website to be hosted in a particular manner. Nevertheless, the DPO's suggestions might be quite sensible. Typical GDPR compliance steps include: having a clear purpose for which the personal data is being processed having a legal basis for that processing (here, probably a “legitimate interest” which will require a balancing test), see Art 6 providing transparent information to the data subjects providing a privacy notice to website visitors, see Art 13 notifying faculty per the requirements in Art 14 GDPR preparing to fulfill data subject rights such as access, rectification, and erasure when using a legitimate interest, there's also a right to “object” (opt-out) implementing appropriate technical and organizational measures to ensure security and compliance of your processing activities, see Art 24+32 making sure that third parties to which you outsource processing activities are contractually bound as “data processors” to only use the data as instructed by you, see Art 28 if you transfer data to non-European countries, having appropriate safeguards in place Does this sound complicated? It can be complicated. The point is that the internet is no longer the lawless Wild West. Just because you can easily publish a site with personal data, doesn't mean that you should. The GDPR is about requiring data controllers to find an appropriate balance with the rights and interests of the affected persons. Of course there are countries with less regulation, but there are also countries with fewer taxes and that isn't necessarily good for society. The easiest way to avoid these responsibilities will be to stop publishing the site as students – and instead taking up the university DPO's offer to have the university run the site. Which is less fun, of course, but the adult thing to do. If this motivates you further: note that the data controller (the people responsible for the site) must publish their contact information in the privacy notice, typically name + email + street address. The GDPR contains no exceptions that would help here. There is an exception for purely personal or household activities. But if the website would be available to the general public, it would be difficult to argue that this is purely personal. There's also case law such as the Lindqvist case requiring a narrow interpretation of that exception. In Art 9, the GDPR does mention that some restrictions are lifted if the data subject made the information public themselves. But that isn't relevant here, because Art 9 is only about extra-protected sensitive data, e.g. health information, union membership, or sexual orientation.
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.