In this article, I would like to present what impact the GDPR has on providers in the IT industry. The GDPR expands the obligations of principals and data processors when processing personal data, compared to the data protection laws in force today.

The GDPR defines the term “processor” very broadly. In general, the principle that any form of processing can also be processing applies to processing on behalf of third parties (= processing).

Preliminary remark: We are always dealing with personal data here! This is sometimes forgotten in practical discussions. In addition, a distinction must be made between B2B and B2C relationships. This is important because in a normal B2B relationship, the provider is also the controller: the controller is the person who directly collects and processes personal data from individuals.

I will not go into detail about this constellation here. B2B relationships are of particular interest, in which data controllers pass on personal data to (contractual) partners so that they can carry out processing. Here are a few possible examples of processing of personal data by third parties (contractors):

• RZ and Platform Outsourcing (PaaS)
• Infrastructure Outsourcing (IaaS)
• Cloud computing such as AWS, Azure, Google Cloud
• Purchase of services and applications (SaaS) of any kind
• Removal of files
• Destruction of data carriers
• Web presences with the integration of marketing tools, trackers, cookies, analytic tools, web browser fingerprinting
• Social Media Widgets
• Remote maintenance
• Communication services
• Big Data Services and Data Optimization / Data Clean up Services

There are no limits to the imagination! Unfortunately, neither is the creativity of the authorities when it comes to interpretation. Does processing already exist when data is sent via a communications network? Is remote maintenance, in which personal data could possibly be accessed, processing? Can fully encrypted data, where the key is only held by the client, be processed? The purists among the data protectionists would answer all this in the affirmative, because the GDPR interprets the term processing very broadly. Since deletion is also processing, one could always argue that this would also constitute an interference with the personal rights of the data subject. The examples show that it will not be clear for a long time what will really fall under commissioned processing. Practice will have to find a feasible way here, and it will take years before such questions are comprehensively clarified.

Summarizing the requirements of Art. 28 GDPR for the practitioner, one can list a list of essential skills that apply to principals/processors:

Cornerstone 1 – Risk Analysis: Conduct a risk analysis IN YOUR OWN INTEREST before any award or acquisition. It is not the risks of their organization that are relevant, but those that could arise for the person concerned!

Pillar 2 – Privacy by Design and Information Security: Even in the case of information security (which we will not go into here), it is still not common practice for projects to include a risk analysis and a security concept. This already refers to the selection of possible processors. As providers, however, they are now forced to establish “privacy by design.” If you also need to perform a data protection impact assessment, that’s almost done too.

Pillar 3 – Transparency: The biggest challenge for the processor is transparency towards those responsible and thus those affected. In principle, the processor must make transparent everything that serves to protect personal data. At the same time, it must specify how it can fulfill the procedural requirements (e.g. obligations to provide information, obligations to delete data). On the other hand, the client is obliged to check these measures. Again, we are in a field of speculative interpretation: what is the disclosure obligation to a contractor? Do I have to disclose trade secrets? What is enough to create transparency?

Pillar 4 – Documentation: The transparency obligations mentioned above can only be fulfilled if the necessary documentation is available. Anyone who knows how “good” the quality of IT documentation usually is suspects bad things. In our view, this is the second biggest challenge for both controllers and processors. Which brings us to the biggest challenge:

Pillar 5 – Information Governance: Mastering the information life cycles of personal data is the most important key discipline for the performance of all obligations of both the controller and the processor. Far too little value is placed on this aspect in the public discussion, because it simply does not appear to be known by most companies! This is because deletion obligations in particular have never been part of a data retention concept (with exceptions, of course). In other words, storing data for too long becomes a bigger risk than storing it indefinitely! Order processing has a few sticking points to resolve here. This is because the familiar requirements of transparency and the obligation to provide information apply, but now also “digital death” and data portability, i.e. the right of a data subject to have his or her data transferred at any time.

Foundation Pillar 6 – Contracts: If you follow the discussion in the trade media, you get the impression that it is all about contracts. If you have the right contracts, then the biggest GDPR challenges are solved. This is simply eyewash! Contracts are important and there must be clear agreements between the parties, but they cannot compensate for core data protection capabilities. Or to put it another way: There is no way I can compensate for the lack of life cycle management with contracts!

Pillar 7 – And test who binds himself (forever): Every processor must be audited, even if he has drawn up such great terms and conditions and contracts! The U.S. providers in particular have employed armies of lawyers to make their contracts as polished as possible. The Europeans are lagging far behind here. Every now and then you see emails asking you to re-register or do something else. The handling of cookies also seems to be of existential importance (yes, there is a cookie policy, but it has nothing to do with the GDPR). This is all smoke and mirrors and may calm the legal department, but it hardly achieves anything.

Pillar 8 – Short processing chains: The GDPR knows no limit to the processing chain. All processors in the chain are subject to the same requirements under the letter of the law. Of course, this is more than unpleasant, but at the same time it is also an opportunity. Today, data is passed on thoughtlessly or interfaces are opened where it is completely unclear what data is being passed on. In many cases, it is also completely open what happens with this data (Facebook … sic!). This hustle and bustle must be put a stop to! From our point of view, this is the important message of the GDPR: Check your contractors. Do they have a myriad of subcontractors on board, some of whom are neither in the EU nor in Switzerland? Hands off! Even if the large provider assures that your data is appropriately secured, what happens in a third country with government surveillance (e.g. India, China) is also beyond its control, even if it is called Microsoft, Google, Amazon and Co.

This brings us back to the first principle: RISK – RISK – RISK. As the responsible party, it is your responsibility to know and disclose the risks to the data subject. If you had to provide this evidence as part of a regulatory investigation, it will be easy if they have few processors. The GDPR does not allow you to mindlessly rely on certificates from third parties; if you have doubts, you must take action yourself. In the case of interlinked systems (=complex systems), the required transparency and thus risk assessment is not possible. In the future, solutions are expected to be audited and certified by data protection authorities. This will reduce the uncertainty somewhat, but it cannot be taken as a carte blanche either, because the type and manner of use must necessarily match the certification configuration.

The KRM is holding a GDPR event for processors on June 20. For more information, please see the event section on our website: www.informationgovernance.ch