[[DataProtectionActReport/GDPR679|Regulation (EU) 2016/679]]  --- '''[[Privacy/EU-EEA-DataProtectionDeclaration/EN|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:
 * Community driven. The Community controls the data by strong Security Policies and internal dispute resolution.
 * CAcert Inc. is based in Australia, data resides in a country within the EU: the Netherlands. The data might get distributed under distributed remote control in the future.
 * For the DPA a contact or responsible party needs to be resident under local law: dutch entity or dutch resident.
 * Risk assessment for the (dutch) contact is unclear.
 * It is unclear if the contact needs to have access to the data, which is in contradiction to the CAcert security policy.
 * The DPA is not written with the consent of a CA and it's service provision.
 * CAcert is non-profit with no employees.
 * CAcert Inc. is an Australian association owning the CA but not fully controlling the CA service.
 * The data is not particularly sensitive in comparison to other DPA (all commercial) registered entities.
 * Foundations, associations, etc. are excepted from DPA registration (subscription administration).

The EU DPA [[http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm|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 [[http://www.dutchdpa.nl/indexen/en_ind_cbp.shtml|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. 
 . He does not share the view that the DPA can force CAcert representatives to make available data which CAcert does not have control over. In case of trouble dutch DPA will just approach the director. CAcert.nl entity does not help in that. An option I didn't see is to pro actively open discussions with the Dutch DPA with a view to establishing a code of conduct for CAs. The law explicitly provides for this. With a code of conduct specific rules can be established for the CA community that better fit the way-of-working of CAcert. The main advantage would be that you can push for the security model of CAcert as the recommended standard. A disadvantage of this option however is that a representative sample of the CA community needs to be on board during the discussion.

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.
 . For last sentence see also the remark of Arnoud: no access control for responsible party is probably needed. Question is what control should the responsible party have and how will this effect the current security measurements and policies of CAcert (and Oophaga).

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 [[http://www.ico.gov.uk/upload/documents/library/data_protection/detailed_specialist_guides/review_of_eu_dp_directive.pdf|review report]] of the EU DPA. Arnoud will elaborate on the legal arguments underwritten by Koops, Buitelaar and Engelfriet (all legal experts).
 . ''Conclusion'': Stichting Oophaga Foundation can act as proxy for CAcert Inc. to the dutch DPA regulator without breaking the current security arrangements. Data is highly protected with the current split of access and control arrangements.
 . ''Actions'': Arnoud informs CAcert about the legal issues and arguments. CAcert Inc. (Rasika) completes the form. Form is sent by Oophaga (Robert) to dutch regulator.

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.
 . ''Actions'':
 1. Review of legal assesment by Prof Bert-Jaap Koops
 1. Notification form completion
 1. Update on text of the Privacy Statement of CAcert (which private data is collected and jurisdiction the Netherlands and EU DPA)