I'd like to update you on upcoming changes to Jomres to help you to ensure that your sites are GDPR compliant.
Over the last few weeks I have been making changes to Jomres which are designed to address the various requirements of the GDPR.There are a number of areas where the GDPR applies to booking portals and I will describe those areas and what the changes are in more detail.
Let me make one thing very clear. I am of the opinion that the GDPR is good legislation. It forces website owners to be transparent about what data they hold about you and what they might do with it. My belief is that this is a good thing.
Who needs to be GDPR compliant?
Everybody that uses Jomres needs to abide by this new legislation if they expect to deal with either property managers or guests from the EU. Even if you are not in the EU and will not be dealing with EU citizens this is still good legislation to follow as it promotes best data handling practices.
For users in the EU, you absolutely must be compliant as the penalties for non-compliance are severe.
What areas of the GDPR affect Jomres?
Virtually all. The specific areas I have focussed on include
- The requirement to report hacks of websites within 72 hours to those data subjects (users, aka guests) affected.
- The requirement to allow data subjects to opt into having their Personally Identifiable Information (PII) stored on the website.
- The requirement that data should only be stored for as long as it is needed.
- The requirement to allow users to download all information about them that the website has about them.
- The requirement to allow users to delete their information where required. (Right to be Forgotten)
Where are we up to now?
To date the first three of those requirements have been met and I will talk a little bit about those changes in a moment. The fourth and fifth items will be done in the next while, but they required the first two items to be completed first.
Reporting of hacks
Data controllers are required to report a personal data breach to the competent Supervisory Authority (SA) without undue delay and, where feasible, not later than 72 hours after becoming aware of it
There is, however, no requirement to make a notification to the data subject where any of the following conditions have been met:
technical and organisational measures have been applied to the personal data which will render it unintelligible to unauthorised persons (such as encryption);
Whilst I believe that Jomres is secure and that property managers can only access the data that they are specifically allowed to access, as a plugin Jomres remains at the mercy of other software in the Joomla or WordPress CMS. This means that if an insecure or badly written plugin has been installed on the server which is then compromised to allow access to the database, all of your manager and guest data will be in the hands of the hackers. This is because in most databases the guest and manager data such as names, email addresses and real addresses are stored in plain text in rows.
Consider another possible scenario : You hire Designer A to setup your site, but you do not have a maintenance contract with them. A few years down the road, you now need to hire Designer B to make some changes to your site. You got him from an online agency and you might not know if they are to be trusted. It would be quite possible for them to download the contents of your database, including all those lovely guest and user details.
To that end, and to harden Jomres as much as possible, the system has been updated to encrypt all guest and manager data. This means that even if the database is compromised the data is useless to the hacker/thief without the encryption key. By default that key is stored in the root of your Jomres directory but it is possible to move the key file to a more secure area of the site where nobody but you and the webserver itself can access it.
Personally Identifiable Information opt-in
Jomres is a big system, probably one of the very largest plugins for Joomla and WordPress and it needs to do a lot of work to make the site visitor's experience as pleasant as possible. Even non-registered users normally have their IP number and country location stored as part of their user data setup process. Once they start making bookings on your site then even more information is stored and you as the data controllers have to get the user's explicit approval before you can capture that information.
Now when a visitor arrives on any page with a Jomres element (including any page with asamodule widgets or shortcode data) then the visitor is presented with a form where they must give their approval to have their data stored. Whether or not they have given their approval is then stored in a special table with a copy of that form's data as it was shown to them at that time. This is another legal requirement of the GDPR.
If they confirm that their data can be stored then it is business as usual, however if they deny consent then they are somewhat more limited as to what they can do on the Jomres pages. For example they cannot login or register using the Jomres menu links, direct links to the CMS's login and registration forms would still work and it's outside the sphere of Jomres' juristiction to affect that functionality. As the website administrator you would need to decide if and when you will show them.
They also cannot make bookings. This is because when making a booking, they must enter at least an email address (I'll get to that later) to create a booking. In most implementations other information such as name, address and even passport numbers may need to be stored. As a result, consent to have their data stored must be given before they can proceed to the booking form.
Data Storage policies
Under GDPR, the specific purposes for processing personal data must be identified and subsequently documented. Such a purpose must ensure that personal data Is collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes. Organisations must also make sure to implement measures to restrict further processing beyond the specified purpose.
In Jomres it is necessary to store information about bookings, invoices and inevitably PII about guests and managers. For example, when a booking is made the booking's temporary data is stored in a table called the booking data archive. This has proven valuable in the past as a means to analyse bookings to ensure that guest requirements have been met, however for the most part this data is not used. Bookings themselves historically were not deleted as they allowed property managers to understand their relationship with specific guests.
In the next version of Jomres this temporary booking data will be removed after 60 days. It cannot be removed before that because it is required by the system if the booking was subject to approval by a property manager. Managers should be encouraged to approve bookings within 30 days. The 60 day threshold then allows managers to stray over that 30 day timescale somewhat but eventually it will be gone and they will not be able to accept the booking.
I have also added new policies that determine how long this information is retained after a booking is completed (the guest has been booked out) or cancelled. Once a booking has gone over the specific time period allowed then it and it's invoice are removed from the database. Similarly, despite being encrypted PII data associated with those invoices is also removed after the Booking Retention Period has expired them.
Data download requirements
This is yet to be imlemented, however it's the reason that whenever a guest makes a booking, then if they were not logged in when they booked, a user is created for them in the system. Previously in Jomres it was optional whether or not a user would be created at booking time, now it is mandatory. This then allows the site administrator to offer guests and managers access to their personal data without making that data freely available to anybody who guesses a secret key.
Right to be Forgotten
Again, this is yet to be implemented, however the previously described functionality has set the groundwork to allow this to be done. Because all guests will have a user in the system associated with them it will be possible for them to log in and trigger an automatic deletion of their data if they wish. This, naturally is subject to some limitations. For example if they have any outstanding bookings they will not be able to delete their data as it is required for normal operation and this is allowed for in the GDPR. Once they do not have any outstanding bookings then they will be able to delete their data.
Similarly, property managers will not be able to have their data automatically deleted. They would need to contact the site managers (that's you) to get any properties that they manage assigned to another manager. Once that has been done and the site manager has set them to no longer be a property manager then they would effectively have the same status as a guest and would be able to delete their data.
As you can see, there are a lot of changes coming up in the next version of Jomres. These changes are significant and they may, by necessity, affect how you do things. I would ask all Jomres users to get involved in the testing process, which was described in my previous blog post. This will help me to iron out any inconsistencies or bugs before the version is released and before you're forced to update to be compliant.
If you are not using Jomres and are using another system I would strongly advise you to contact the developers and ask them if their software is GDPR compliant and if so, to make it clear to you the specifics of that compliance. The penalties for failure to comply are very very high.
Up to €20 million, or 4% of the worldwide annual revenue of the prior financial year, whichever is higher
As you can see, GDPR compliance is not optional, it absolutely has to be adhered to and failure to comply to the best of your abilities could cost you more than your business can afford.
- Created on .