We are a software supplier. Via our application a lot of data is stored in our databases, but we're not the ones processing the data. The input and output of data will be done by our customers. When I look at the 01.1 document a lot of questions are about processes to take care of personal data like adding, removing or anonymize. How does a software supplier normally integrate these standards? We cannot force each customer to ask permission to their professionals before they enter data. And if we could it is almost unverifiable.
According to article 4 of the EU GDPR processing of personal data means “ any operation or set of operations performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction”. So, if the company you are representing is storing personal data that means it is processing pe rsonal data even if it is doing it on behalf of its customers. For theses processing activities the company is acting as a data processor (https://advisera.com/gdpr/definitions/).
When acting as processor, you should only process personal data based on the instructions of the data controllers, usually these instructions are found in data protection related articles in the contract with the controllers or in Data Processing Agreements signed with the controllers. These documents constitute your legal basis for processing personal data on their behalf, so I am not sure about what other permissions you are referring to.
Coming back, to the document 1.01 EU GDPR READINESS ASSESSMENT, this is based on the requirements of the EU GDPR and at the end of each question is mentioned the EU GDPR article to which the question refers to.
You're absolutely right to say that we are a data processor. All data storage and processing is done on behalf of the customers (via a software interface or b2b connections).
So yes, we do need to invest time in setting up a better or newer version of a Data Processing Agreement than the current one we use.
What I'm referring to is what is the best approach, having the toolkit, for us as data processor. I'm a little bit confused which articles are important for our software, which are important for the data agreement and which are important for the customer (who we can only inform about the regulations).
E.g. the first couple of questions are about the activities regarding data processing. We could document why we are storing data form our point of view.
But question 3 is about using data for other purposes. We won't do that but we can't guarantee a customer won't.
And even more complex is question 4. We CAN supply in tools for giving permissions but if the customer doesn't use them should we force them to use it or should we document the options we provide.
And another one: If we receive data which we import from a 3rd party (of the same customer) and someone has a request to remove all personal data, this will be undone by the data import. So who is responsible? Should the customer request the removal because they are the data owner and should we only provide in the tools to do so?
This question came to me by this phrase:
Thus, a software vendor or SaaS provider could state that he believes he is following the SbD and PbD principles. But that does not make him GDPR compliant. It just builds the foundation for a customer, enabling that organization becoming GDPR compliant. But to put it clearly: An organization dealing with PII can be GDPR compliant. A service provider that acts as “data processor” in the context of GDPR can be GDPR compliant (for its part of the system). But a software application or a SaaS service only can provide the foundation for others to become GDPR compliant. There just is no such thing as GDPR compliant software.
This seems like we can prepare our SAAS application to BE ABLE TO follow all regulations. However, as long as a customer doesn't use this or doesn't change the process it makes no sense.
Since you are the data processor, the controllers are the ones giving you instructions on how to process the data thus, it would quite strange that a controller would ask you to point out to him which are the processing activities you are providing that are not compliant with the EU GDPR. And even if they did you, most likely, won't be able to provide an accurate answer since you don`t have the full picture of the processing activity.
The controllers however, must have a full picture of their processing activities and they must make sure that compliance with the EU GDPR is achieved.
Some controllers may ask you to implement certain features in your software that would make their processing activities EU GDPR compliant. If this is the case, these instructions should come in a legally binding form such as a contract or a Data Processing Agreement
Thanks for the answer. So if I'm correct we should focus on the software and can basically put a 'no' to all processing activities because we won't do them ourselves.
The only thing we need to make sure is that our software is GDPR compliant, regardless if the customer is using it that way.