With GDPR having come into force in May, the development team at Tribal Systems have been busy for some months improving Zenario's personal data protection measures. If your site is in the EU, or you store data about EU citizens, your process is covered by the General Data Protection Regulations.

Is there a good CMS for complying with GDPR? I think the following are key features you need to look for in any CMS.


If you're transferring any kind of personal data, especially sensitive data, your site really needs to run on SSL. I think these days it is essential.

Having the "green padlock" on your site not only protects data in transit; it also gives customers the message that you care about protecting their data, and it gives a small search engine advantage.

Zenario supports SSL, and can be made to enforce only SSL connections. It doesn't just cover the initial sending of data by a visitor to the site; it also means that administrator passwords, and the viewing of all data through Organizer, are encrypted.

Users and Contacts

Your site may have an extranet, with password-protected private data; that means "Users".

Zenario performs 1-way encryption of user passwords, so that passwords are not stored in plaintext in the database or anywhere at all on the server.

Data is also stored about Contacts - people whom you may email, or store like in a CRM - but they cannot log in.

Form handling and Consent

If you've used the Forms system in Zenario 8.0 onwards, you'll have seen that they have become quite powerful. Zenario lets you drag and drop to build anything from a simple contact form to a complex multi-step, conditional-flow form, with save-and-resume features, arithmetic features, and more!

When a Zenario Form is submitted, a number of things can happen, all of which are optional:

  • Zenario can send an email to the visitor
  • It can send the form data to an administrator or other recipient
  • It can log the emailed data in the email log
  • It can log the form response in that form's response log
  • It can send the data to an external CRM with an API, such as MailChimp
  • It can create a User or Contact database record
  • For advanced users, it can send a signal to register the data with other Zenario modules.

Among the various form field is a system of Consent fields. The default field is "accepts terms and conditions", but for the granular data permissions required of GDPR, it is easy to make additional such fields.

Consent fields are usually mandatory (though not always); under GDPR there may be a mandatory checkbox to "allow data storage", but there may be a non-mandatory checkbox to "send email marketing".

When a visitor checks a Consent checkbox and submits the form, Zenario stores the time, their name, their IP address and the actual wording beside the checkbox that they ticked. This log is stored as a proof that the user gave permission for their data to be stored. This happens even if the data is pushed immediately out to a third party CRM like MailChimp, which has a secure API.

Automatic data deletion

Some data is logged when forms are submitted. It's typical for form responses to be logged in the response log, and similarly it's common for sent emails to be stored in the email log; these things are handy in case of suspected lost form submission.

Similarly in the case of an extranet Zenario can log the last login time of each extranet user, and which pages the user accessed.

This data has a lifetime, and should not normally be kept indefinitely. So Zenario 8 has controls over:

  • How long form responses are saved
  • How long sent-email logs are saved
  • How long the sign-in log is saved
  • How long the content item access log is saved.

It's typical to set these to delete after 1 week or 1 month. That should be long enough to give reassurance that customer enquiries are not being lost in email transit, but not so long as to constitute unnecessary data storage.


Fields in the users/contacts data area can now be encrypted, or encrypted+hashed.

(This feature is presently still undergoing system testing, so is available on request to hosted customers, but not yet an accessible feature of Zenario.)

In this system, there are a pair of encryption keys for each database on the server. The keys are stored on the web server, and they are used to encrypt or decrypt data from the database. 

The system works best when a separate server is used to host the MySQL database. In the event of unauthorised access to the database server, the data would not be readable without the keys.

This also improves the security around backups. Whether a Zenario backup is used, or a direct mysqldump file, the SQL file that is saved or downloaded will contain field-level encrypted data. So in the event of even a local data breach on the part of an administrator, the data would be unreadable without access to the keys.

Tougher administrator logins

By adding a couple of options in the zenario_custom/site_description.yaml file it is possible to enable two new security features:

  • 2FA, or two-factor authentication
  • capthca.

2FA appears if the administrator makes a successful login, but he doesn't have a cookie from an earlier login, or if he is at a new IP address. When the condition is detected, Zenario sends a temporary code to the administrator via their email address, which must be entered in order to complete the login.

A captcha is now available on the administrator login screen, to combat bots making repetitive login attempts. 

If you have an earlier copy of Zenario, your site_description file will be lacking the required options. Have a look at the standard file template at zenario/api/sample_site_descriptions/probusiness/site_description.yaml and copy the relevant lines into zenario_custom, enabling the "2fa" and "captcha" options you require.

Expired administrator accounts

Ever had an employee leave, and you didn't remember to delete their access to company data?

Zenario now warns you if there are administrator accounts that have not logged in for more than a few weeks. So it's now rather harder to forget to remove accounts of people who have left, and who no longer should have access to data.