software data-protection gdpr
How does the GDPR apply to software developed by one company and used by another?
<p><strong>Question</strong></p>

<p>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.</p>

<p>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?</p>

<p>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?</p>

<p>Could some kind soul please help me understand?</p>

<p><strong>Sources</strong></p>

<p>For reference here are the main sources I've consulted (plus lots of fruitless searching...):</p>

<ul>
<li><a href="https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/" rel="noreferrer">https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/</a></li>
<li><a href="https://ico.org.uk/media/for-organisations/documents/1546/data-controllers-and-data-processors-dp-guidance.pdf" rel="noreferrer">https://ico.org.uk/media/for-organisations/documents/1546/data-controllers-and-data-processors-dp-guidance.pdf</a></li>
</ul>

<p>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.</p>

<p>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.</p>

<p>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:</p>

<ol>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>

<p>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.</p>

<p>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.</p>

<hr>

<p>Further clarification as requested:</p>

<p>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. </p>

<p>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 <a href="https://ec.europa.eu/info/law/law-topic/data-protection/data-transfers-outside-eu/model-contracts-transfer-personal-data-third-countries_en" rel="nofollow noreferrer">Model Contract Clauses</a> 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 <a href="https://ec.europa.eu/info/law/law-topic/data-protection/data-transfers-outside-eu_en" rel="nofollow noreferrer">Data Transfers outside the EU</a> page.</p>

<p>Ref: <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679" rel="nofollow noreferrer">GDPR</a></p>
