Regulation (EU) 2016/679 --- Data Protection Declaration for Users in EU & EEA

Data Protection Act (DPA) compliance

Most countries have a Data Protection Act. These acts differ country to country. The European Union DPA is probably the strongest in protection of individual's private data. CAcert wants to be fully compliant with the EU DPA, as expressed by the CAcert Board at the end of 2007. However, CAcert is not the conventional service for which the EU DPA was devised:

The EU DPA Article 29 Data protection Working Party WP43 Febr. 2001.

Much reason to investigate and explore the possibilities.

chronological report of exploration

Spring 2007

One person who was approached for board membership of Oophaga had to cancel board membership due to membership of the CBP committee.

October 2008

The dutch DPA form and requirements have been translated to English (nowadays they are available in English from the dutch DPA or College Bescherming Persoonsgegevens (CBP)). Start with completion of the form. Requirements are comparable with CAcert Policies in draft. CAcert Security Policy (Draft in March 2009) are in many points stronger as the conditions of the DPA.

December 2008

Stichting Oophaga has been informed and asked via their president Bert-Jaap Koops (professor in law at University of Tilburg) to look into the EU DPA issue. The CAcert data resides on computer equipment belonging to Oophaga. Oophaga mission is free digital certificates in Holland and beyond.

March 2009

The feeling exists that CAcert needs more support from dutch IT law experts. Arnoud Engelfriet (IT specialist and lawyer on Open Source) and Alex van der Walk (Open Source lawyer) have been contacted for support.

After meeting in Vienna Rasika sends draft of proposal/report to Ian, Philipp D., Arnoud, Alex, Teus and Stichting Oophaga (threat, country analysis, options strength and weaknesses, conclusions). Report recommends looking for special board member CAcert, a responsible body (eg Oophaga), or a setup for CAcert foundation for this in Holland. Explore also other countries within the EU. CAcert should clearly mention that CAcert follows EU DPA and not transfer private data to third country/person that does not have an adequate level of protection to prevent someone claiming that it is possible (legally) to transfer personal data held by CAcert since CAcert Inc. is established in Australia.

Arnoud suggest not to hurry too much (give it a good thought) and suggests as responsible body Oophaga. President CAcert asks president of Oophaga to look into this idea. Oophaga president explores possibilities with colleges.

Rasika is confident that EU DPA applies. CAcert is then fully covered by dutch DPA. No other countries in EU are more suitable. If CAcert is accepted is not clear. Registering with Dutch DPA has no negative consequences. Steps: who can be responsible party, and notify DPA.

CAcert Board meeting end of March requires roadmap and some board members state that CAcert is not compliant with the DPA so they feel very uncomfortable with the fact that no notice to Dutch DPA has been given yet.

Arnoud does not see this problem.

End of March: Stichting Oopaha president is asked to look into taking up responsible party for CAcert Community with dutch DPA.

End of March, Arnoud: Nevertheless, it is important to work out how the privacy officer should work in view of the international situation. I have initiated contact with the Dutch DPA to find out what CAcert and Oophaga need to do. I will get back to you as soon as I have more information.

April 2009

End of March / start of April board decision made: Teus got a mandate from the Board for DPA negotiations and can act on this on behalf of CAcert Inc.

May 2009

Rasika send notice to Oophaga with cc to Arnoud and Alex to get more progress: The question is who the responsible party should be. Some possible answers are organizations (such as Oophaga) and individuals (like Teus). Teus can be the responsible party at the moment since he is the president of CAcert board, but this is only a short term solution. Oophaga can not take the responsibility since it does not have access to CAcert data.

No feedback on initiation of contact with dutch DPA has been received yet.

13th of May prof Bert-Jaap Koops discusses DPA issues with collegues experienced with privacy issues and DPA law.

25th of May meeting with Prof Bert-Jaap Koops (University of Tilburg, Faculty of Law), Arnoud Engelbertink (IT laywer) and Teus Hagen (president CAcert Inc.) in Tilburg. Prof Koops has been assited by Hans Buitelaar researcher at Tilburg university on the topic of privacy. A practical and sufficient solution has been devised: Oophaga acts as proxy for CAcert Inc.There is no requirement from the regulator that Oophaga engineers need to have access to the data. So it is not breaking the CAcert security model. CAcert Inc should state that CAcert Inc. is compliant with EU DPA. Rasika will send completed DPA form to Oophaga, from Oophaga the dutch regulator will be informed. DPA legal measurements and penalties are surprisingly quite limited. See also a good review report of the EU DPA. Arnoud will elaborate on the legal arguments underwritten by Koops, Buitelaar and Engelfriet (all legal experts).

7th of June 2009: meeting Rasika, Arnoud and Teus for talk on Lawyers DPA letter explaining legal background of the Oophaga proxy solution. Letter from ICTRECHT (Arnoud Engelfriet lawyer) is reviewed and completed. This DPA "legal assesment of CAcert/Oophaga" needs to get final review of prof Bert-Jaap Koops. Conclusion: Oophaga is the right vehicle to notify for CAcert with Dutch Private Data Controller and Oophaga does not and in the case of CA operations should not have direct access to private data, as well dutch private data controller does not have legal right to get access to private data and can only order stopping the data processing. The form for notification is prepared in second week of June to be readied for CAcert board and completion by Oophaga. Rasika will prepare the needed update on the (old) privacy statement of CAcert.

DataProtectionActReport (last edited 2019-02-06 14:50:39 by EtienneRuedin)