krileonThe implementation date for GDPR is quickly approaching (May 25th 2018), but it's not too late to become compliant as possible using Community Builder. Below are some recommendations to ease the process for subscribers and free users alike.
First and foremost for full disclosure I am not a lawyer. I have not consulted a lawyer. All the recommendations below are based off my understanding of GDPR regulations. If you have any doubts please contact a lawyer familiar with GDPR regulations. We take no responsibility for any GDPR violations your site may or may not have. Please understand that GDPR compliance needs to be evaluated on a per-site bases based off what you collect, what for, for how long, and from whom.
Please note we will be developing, for free, an optional integration plugin for Joomla 3.9 privacy component. Such component is meant to centralize GDPR compliance and easy the process. This will be the best solution as it allows all extension to easily meet compliance in a centralized location.
Ok, with that out of the way I strongly believe GDPR is fantastic for the industry. Accountability for users data should've always been the forefront of good website design. Everyone should be taking measure to ensure their users data is kept safe and that their users are well informed as to the purpose of collecting that data.
Short version
Add a terms and conditions field to registration (or use existing terms and conditions field) for your privacy policy that clearly states what data will be used for that adheres to GDPR requirements. Great example can be found below. This field should be marked required as consent is required to even collect data. As for log of consent the registration date is sufficient otherwise you can use CB Profile Update Logger to keep track of profile changes.
https://www.pipedrive.com/en/privacy
Create a Joomla contact form for users to request deletion of their account and comply with any delete requests within 30 days by deleting the user in CB > User Management. Can automate this using CB Privacy.
Create a Joomla contact form for users to request a data export of their account and comply with any export requests within 30 days by exporting their profile data using CB Juice or phpmyadmin directly. We do not have a means of automating this at this time, but we will using CB Privacy.
Disclose what data is being used. For example if you're using email address for marketing purposes state as such in the fields description. This can also be done using a Custom HTML field display on registration. Data disclosure can also just be a part of your privacy policy.
Inform EU authorities within 72 hours of any data breach followed by informing all users affected by the breach. You can easily notify your users of a breach using CBs build in Mass Mailer within CB > User Management.
This covers the vast majority of sites. There are several with more specific data requirements that need to be assessed on a site by site basis. If you are in doubt about compliance please contact a lawyer.
Long version
Lets start off with the basic principles of GDPR as follows.
Consent
This is the absolute most vital aspect of the regulation. It is extremely important to understand personal data can not be collected or processed without obtaining explicit consent from the user. It is also one of the easiest parts of the regulation to implement. The simplest way to do this is use the built in Terms and Conditions fieldtype within Community Builder. My recommendation is to have a strong privacy policy as a Joomla article and simply link to it from your Terms and Conditions field.
Breach Notification
This one is pretty straight forward. If for any reason your site is hacked, unauthorized data extraction, etc.. you must notify EU authorities within 72 hours then notify all affected parties. When doing so it should be clear what data was breached. You can notify your users of a breach quickly and easily using CBs built in Mass Mailer within CB > User Management. This is a game changer for a lot of Joomla sites which tend to "fire and forget"; as in they're built and not truly maintained causing things to go out of date leaving potential vulnerabilities. It will be vital for your to secure your Joomla site as best as possible. My recommendation at the very least is to be strict with all permission and access control settings to mitigate backend access and switch over to always using HTTPS.
Right to Access
In short, users have the right to access the information you've collected on them. This is pretty simple as this is easily made available through profile edit, which satisfies this requirement. If you are collecting additional information from the user and would like to display it centralized in profile edit you can use CB Query Field or CB Code Field to grab and display that information to them as needed using database queries or PHP. There are several subsections to this regulation as well. You will need to be clear on why you're collecting the data to begin with, which you can add these disclosures directly to a fields description or using Custom HTML fields to satisfy this requirement.
Right to be Forgotten
Have you ever registered on a site and no longer wanted your account, but couldn't delete it? That frustration is felt across the web. The purpose of this regulation is to ensure sites provide a means of purging your data from their site. That same requirement applies to your site. However, this does not need to be automated. A simple contact form to easily communicate with you asking to be deleted and then manually deleting the user within Community Builder is sufficient in most cases to satisfy this requirement (please note it is subjective to what data you are collecting, there is no guarantee all data will be purged by a delete operation; please be diligent in checking all data has been deleted). There are a few exceptions for this as well. For example if your local laws and regulations require financial data to be kept for several years then you do not have to delete for example CB Paid Subscriptions payment records of a user until deemed allowable by your local laws and regulations. Be careful with this one and I highly recommend consulting a lawyer depending on what data you are collecting! To automate this process you can use CB Privacy and its Delete Me field.
Data Portability
This one is tricky. The idea is to allow a user to export all the personal data you have on them in a portable format. CSV, XML, and JSON are all acceptable portable formats. Community Builder however does not provide a means of exporting user data. The best approach for handling this is CB Juice to export their profile data or a direct database export using phpmyadmin. CB Privacy will eventually also have a means of exporting a users data automatically. Please note this also does not have to be automated. A simple form on your site to request data is sufficient and gives you 30 days to comply. My recommendation is to simply handle these requests manually as realistically you are unlikely to ever receive such a request.
Privacy by Design
This can be confusing as Privacy by Design is actually Data Security and isn't what you may think it means. Essentially what this means is you need to design for GDPR going forward from the beginning instead of an afterthought (e.g. plain storage of passwords without encrypt is bad!). You should minimize the data you collect to only what is actually necessary. Don't collect more personal data than necessary as it does increase your risk factor. Additionally users data should be accessed only by those needing it (the need depends on the purpose of your site!), which shouldn't be an issue as you can control who can see what using ACL in Joomla in addition to user controlled privacy using CB Privacy. You should limit backed access as much as possible to avoid unnecessary administrative access to users personal data. It is also very important the user knows what data will be publicly visible, which the visible on profile icon helps establish. This does not mean you need to lock everything behind ACL and privacy access. The amount of control given should be entirely based off the need of your site. If it is meant to be used as a public activity stream site then all posts can and should remain public without privacy controls. You should be clear in your disclosures within your privacy policy about this as well.
Data Protection Officers
I don't believe this will apply to anyone here. It's meant for extremely large sites collecting massive amounts of user data. Basically you'd have to hire someone specifically for controlling data. You can read up on this a bit more here.
Now lets get started on getting some of this implemented. First and foremost you need a privacy policy. The simplest way to present this to your users is to use a Terms and Conditions fieldtype. These fields can have their label adjusted to clearly state it's for a privacy policy then link to or even directly display the policy on your registration page. Your privacy policy should be clear and easy to understand. This policy would include data classification (what you're collecting, why, and whom will see it), instruction detection (how you plan to monitor for intrusions), incident responsive (how you plan to handle an intrusion), and GDPR compliance statement (should clarify your site adheres to GDPR compliance and explain to them their rights under GDPR). Next up is optional, but recommended, to have a site terms and conditions; this generally would outline what is and is not permitted on your site for added protection. Community Builder allows you to make as many terms and condition fields as you like as well so feel free to have as many clear and easy understand policies as you need. You can break up the privacy policy basically into 4-5 terms and condition fields if you like, but maybe overwhelming for the design of your registration form. Example of a good privacy policy can be found below.
https://www.pipedrive.com/en/privacy
It's important to note data disclosure (what you're using a field for) can be done in the fields actual description as well or using Custom HTML field. For example if you use their email address for marketing purposes then state as such in the email fields description.
Now the first step covers a BIG portion of GDPR. That's informing the user and obtaining consent from the user. Obtaining consent also has to include a record of consent (when they consented). For most sites this is always at time of registration and they can't register without consenting (as without consent you've no right to collect their data), which means their registration date is their record of consent. However, you can expand on this and utilize CB Profile Update Logger to keep track of their terms acceptance and profile changes (this can help with intrusion detection).
Next users need to be allowed to remove themselves from your site completely. This doesn't have to be automated so a simple Joomla contact us form for them to submit a deletion request is sufficient. You've 30 days to comply with these requests, which is plenty of time to clear a user from Joomla. Please be sure to always delete users from CB > User Management for plugin clean processes to take affect as most (soon all) our plugins clear out user data when a user is deleted; this will not happen if you delete them from Joomla user manager and you will have to manually clear any remaining date. CB Privacy does include a Delete Me field to allow users to delete themselves without having to bother administration.
Below is a wonderful article that helps explain some of this AND shows you some design examples. It is not as overwhelming as my above wall of text may seam.
https://termsfeed.com/blog/gdpr-privacy-policy/
Q&A
1. Does this affect me even if I'm not in the EU?
A. Yes. Several countries in fact are also complying with this law. For example Canada fully complies. The US partially complies with a treaty (financial institutes are exempt). With that said don't let this create fear. That's not what this is all about. Complying is not complex or complicated for the vast majority of sites.
2. What do I do about users who already registered? How do I obtain consent?
A. Did you have a terms and conditions policy in place that follows GDPR? If not my recommendation is first do that. Next reset in your database the acceptedterms field to 0 and email every user that your policy has changed and that they need to review and accept the new terms. If they do not do so within for example 30 days their account will be removed. This ensures you are no longer holding data for someone that didn't consent. This covers risk assessment and good-faith compliance reducing your risk factor significantly for keeping non-consented data.
3. What about data time limits? How do I manage timed consent?
A. This would be a per-site implementation that we don't cover. Since registration date would be their initial consent date you'd need some other means of tracking capturing of new consent. This could be CB Profile Update Logger for example after the acceptedterms field has been reset. After that though if a user doesn't provide consent it would be up to you to delete those users manually, which you should be able to do from CB > User Management. At this time however we do not have plans to specifically implement functionality for timed consent, but Joomla 3.9 privacy component is planning to have this and CB will integrate with it where possible.
4. Will CB delete all of a users data when their user is deleted?
A. We can not guarantee all of their data will be deleted. Especially when it comes to 3rd party extensions or CB plugins. Most of our plugins will properly delete all of a users plugin data when a user is deleted, but for example if you install a plugin that logs data, use it, then uninstall it that data still exists but the plugin no longer does so it's not able to clean that data. So be sure to manually delete plugin database tables as needed. Making sure everything is properly deleted is something you'll need to carefully evaluate. We will do the best we can to ease this process, but again there is no guarantee.
5. What about users IP Addresses in plugins and server logs? Can I keep those?
A. Yes and no. It's important to understand what is and is not PII (personal identifiable information). This is information that can identify a user specifically. This includes, but not limited to, the following: name, email address, physical address, social security number, drivers license number, passport number, credit card numbers, date of birth, telephone number, and login credentials (e.g. username). You then have what's called "linkable information". This is information that doesn't directly identify users, but COULD and is a bit of a gray area. Some examples are gender, race, age range, job position, etc.. You then have non-PII which can't really identify someone personally. Some examples of non-PII are device id, ip address, and cookies. All 3 however are still personal data in some cases. They just are not identifiable on their own. In short it's a bit of a gray area. My recommendation is to disclose that you collection IP Addresses and for what purpose (e.g. maintaining adequate security as required by law).
6. Do I have to keep a record of all user data processing activity?
A. This highly depends on the size of your company. Companies with fewer than 250 employees are not subject to the data recording aspect of the regulation (see Article 30 Section 5) unless said company is processing significant amounts of user data (e.g. analytic companies, ad companies, etc..). I'm confident this shouldn't apply to the vast majority here. If it does however CB Profile Update Logger satisfies this requirement.
7. Do I have to make everything private?
A. No. This is a large misunderstanding of Privacy by Design, which has absolutely zero implementation restrictions. Privacy by Design is actually pertaining to Data Security. It literally means nothing more than "data protection through technology design". In short sites that were storing plain text passwords and other very personal data with no encrypt are in violation of this. You should however still implement privacy controls and ACL restrictions where necessary based off the need of your site. If you intend on CB Activity posts being public by design then leave them public as it fits the business need of your site. This also only applies to PII (personally identifiable information) of which activity posts are not along with a significant amount of other data.
I hope this helps answer some of the questions about GDPR compliance with CB. Again I'm not a lawyer and this is all my recommendations based off my understanding of GDPR. If you have any doubts, I can not stress this enough, please consult with a lawyer. We can not be held liable for any damages caused by non-compliance. There is no 1-button solution for compliance and need to evaluate this carefully based off the needs of your site. Below are some additional resources you may want to read up on.
https://gdpr-info.eu/ - I highly recommend visiting this one as it outlines clearly the entire law. Check out Key Issues for a clear summary.
