How does the GDPR apply to software developed by one company and used by another? Question I work for a bespoke software development company and I've been doing a lot of reading about the GDPR before it comes into force next year. A lot of it makes sense, however I'm really struggling to find out what effect this has on us - specifically the impact when we write software that another company uses to process their customers' data. Are we a data controller, processor or neither in this case? If we had direct access to customer data for testing the software I'm pretty sure we'd be a data processor, but does this still apply if we don't have access to (nor host) the data? Could some kind soul please help me understand? Sources For reference here are the main sources I've consulted (plus lots of fruitless searching...): https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/ https://ico.org.uk/media/for-organisations/documents/1546/data-controllers-and-data-processors-dp-guidance.pdf Unfortunately most of what I've read deals with companies providing a service (building and running the software themselves) rather than just building the software.
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
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).
The scope of the GDPR is entered when personal data is being processed in a structured manner. Personal data is any information relating to identifiable data subjects (definition in Art 4(1)). &quot;Peter attended the meeting on the 14th&quot; is personal data. &quot;That woman with the blue handbag said she wanted to return on the 25th&quot; is personal data. However, aggregate statistics do not relate to individuals, and are typically not personal data. &quot;On the 14th, we had 25 attendees&quot; is not personal data. Not all use of personal data is within the scope of the GDPR. For example, the GDPR would not apply if two organizers talk about who attended the meeting. However, Art 2(1) says the GDPR applies when personal data is processed wholly or partially with automated means (e.g. computers, smartphones), or forms a filing system or is intended for a filing system (e.g. keeping notes on attendees, keeping attendance lists) If GDPR applies, the organization would be responsible for ensuring compliance with its rules and principles, summarized in Art 5. Primarily, this means: having a clear purpose for processing selecting a suitable Art 6 legal basis for that purpose (e.g. consent or a legitimate interest) only processing the minimum data necessary for achieving that purpose determining and implementing appropriate technical and organizational measures to ensure compliance and security of the processing activities preparing for data subject rights, in particular by providing an Art 13 privacy notice when collecting data from the data subjects There are of course some complexities in the details. When the legal basis is &quot;consent&quot; (opt-in), the organization would have to ensure that this consent was freely given and sufficiently informed. Per Art 7(4), consent would not be freely given if that consent was a condition for access to the meeting. Using &quot;legitimate interest&quot; (opt-out) can be more flexible, but it requires performing a balancing test to show that the legitimate interest isn't outweighed by the data subjects' interests, rights, and freedoms. Roughly, relying on a legitimate interest is appropriate when the data subjects can reasonably expect the processing activity to occur. Regarding point 1, keeping general counts and aggregate statistics about attendees is probably OK since it wouldn't be personal data. If you are very conscientious about this, you could round all counts and use categories like &quot;0-4 attendees, 5-9 attendees&quot; for each facet, which makes it more difficult to make inferences about individuals. But the fundamental point is that all your data should relate to attendees as a whole, never to individuals. Regarding point 2 and 3, this is a question of legal basis. Since you gather names through informal conversations, I think that attendees would be weirded out if they learned that you kept detailed records on their attendance. So I think that you probably wouldn't have a legitimate interest here. However, being upfront with this and offering an opt-out could change this. On the aspect of keeping detailed notes on data from informal conversations, I'd like to point out H&amp;M's EUR 35 million fine back in 2020 (summary on GDPRHub.eu). In a callcenter, managers used to have conversations with employees. These conversations touched on anything from vacation experiences to health problems, marriage problems, and religious beliefs. All of that is fine. What was not fine is that the managers went full Stasi and kept detailed notes about all of this on a shared drive and used that information for management decisions. This went on until a configuration error made those files accessible to all employees. This violated all the points in the basic compliance process outlined above: the records had no clear purpose, no suitable legal basis, contained way more data than necessary (and even Art 9 special categories of data like information on health or religious beliefs which have extra protection), did not have appropriate measures to prevent unauthorized access, and did not fulfill data subject rights like the Art 13 right to be informed. In case this non-profit is a church or religious organization that had its own comprehensive data protection rules before the GDPR came into force in 2018, those can continue to apply per Art 91. This could probably address some issues of legal basis, but cannot circumvent the GDPR's general principles.
These are only tangentially related to the GDPR A government entity processing data in accordance with a member state law is ipso facto in compliance with the GDPR. That’s because lawful government data processing is a legitimate reason for processing data under the GDPR. If Germany, for example, passes a law saying German police can record every phone call in Germany, then that would be a lawful basis for processing under the GDPR. There may be constitutional or other legal limitations on such a law but as far as the GDPR is concerned, they’re fine.
The university has a legal obligation to collect certain data from attendees, including employees an visitors. It has decided to keep these records in digital form, and offers a smartphone app as a convenience. The university has outsourced the data processing activity to a third party. This is perfectly legal under the GDPR, if that third party is contractually bound to only process the data as instructed, and not for their own purposes. Whereas the university acts as a data controller (Verantwortlicher), the third party would be a data processor (Auftragsverarbeiter). I have some doubts though whether an app or a website is indeed the solution that offers the best data protection, especially taking into account the GDPR's data minimization principle. Requiring updates when entering or leaving any room is potentially excessive. Given the sensitivity of the data, the university should have performed a data protection impact assessment to weigh the consequences of this measure. At least for employees, the measure would likely have to be approved by the union (Personalrat) as well.
Yes, you could do this be means of the EULA, provided you are not in the EU yourself. You only have to comply with the GDPR if you are offering a product or service to people that are in the EU. If you are making it clear that whatever you offer is not available to Europeans, you make your site exempt from the GDPR.
If the lawyer has legitimate concerns, his first port of call would be the ICO https://ico.org.uk/. Before the ICO will take his complaint further he'll have had write to you expressing his concerns and received a written response that presumably he is unhappy with, and wants to take the issue further. Most companies have a data compliance team who will have policies and procedures to log breaches like this and decide what course of action to take in response. Not every breach needs to be brought to the attention of the ICO, and they have a handy self assessment tool to see if you should report the breach. https://ico.org.uk/for-organisations/report-a-breach/ In your situation, I don't think this constitutes a serious breach which will require investigating. It's simply an admin error. If it is unlikely to pose a risk to any of the individuals they will say something like: You should keep an internal record of the breach as detailed in Article 33 (5) of the GDPR, including what happened, the effects of the breach and remedial actions taken. The definition of risk according to the ICO is: "This risk exists when the breach may lead to physical, material or non-material damage for the individuals whose data have been breached". So in this case I'd assume a simple apology (Bcc'd :) ) and a record of what happened, how it happened, and the action taken to prevent it happening again should suffice.
[I'm not so well-versed on US and Russian law, thus I will limit my answer to EU law.] Your specific use of a user identifier, as I understood from your question, can be classified as personal data, so in your case, the GDPR seems to apply. This means that you need to have a) legitimate purposes to process that personal data (e.g. crash reporting) and b) a legal justification for each purpose of processing: it could be based on consent or another legitimate purpose (inc. your own legitimate interests). Consent might not be the best option for you, but it's up to you to decide. In any case, you need to assess the risks to the data subjects (your users) before you decide. How likely is it that you will get breached, and what potential harm will that cause to your users? These are some guidelines; my recommendation is that you read the law and the guidelines by the Article 29 Working Group and European Data Protection Board, or hire some good experts on this. There is no easy answer, or one size fits all solution. The GDPR isn't so hard to understand or implement, but it does require some change in mindset. With the new law, processing personal data carries a higher risk of penalties, so you should do it only when it's absolutely necessary, and with respect to the rights of your users.