GDPR Statement

[bencurthoys]

I just wrote this… @Tickettattle, is this broadly speaking accurate?

I would put it as “The system helps you comply with GDPR”. GDPR isn’t just a tick box or something we can solve through software, it’s about all your processes. We can’t stop you from using the system in non-complaint ways - you could download a list of customer details, print it out, and leave it on a bus - but we try to make it easy for you to comply.

In terms of the GDPR, you’re the data controller - you own the data - and we’re a data processor, processing it on your behalf. We don’t use the data for anything on our own account, we can’t analyze it or send it to a 3rd party without your permission.

For security - the data lives on a server in Amazon’s EC2 cloud, at the hosting center based in Ireland, so it’s physically very secure: we don’t have physical access to the hardware the virtual machine is on. The database server is inside a virtual private cloud, and not directly accessible from the internet: access requires a secure VPN connection. The database is backed up onto a non-Amazon server (hosted by Bytemark) for disaster recovery which has a minimal exposed surface area, and may be downloaded onto a development machine if that is required to diagnose and fix a problem you are having with the system. It is company policy to remove client database from developer laptops as soon as the problem they are required for has been fixed, to minimise the possibility of data being lost if the laptop is lost or stolen.

I don’t believe that you require tick box consent for opening an account. One of the key tests in the GDPR is about reasonable expectations. If a customer creates an account on your website, they expect you to store that data. But what you do with it must match what they reasonably expect, so you need the data to sell them a ticket and that’s fine, but you can’t pass that data on to a 3rd party marketing company trying to flog them widgets.

See second 5 of https://ico.org.uk/media/about-the-ico/consultations/2013551/draft-gdpr-consent-guidance-for-consultation-201703.pdf

Consent is ONE lawful basis for processing data. The other 5 are:

A contract with the individual: for example, to supply goods or services they have requested, or to fulfil your obligations under an employment contract. This also includes steps taken at their request before entering into a contract.

Compliance with a legal obligation:if you are required by UK or EU law to process the data for a particular purpose, you can

Vital interests: you can process personal data if it’s necessary to protect someone’s life. This could be the life of the data subject or someone else.

A public task: if you need to process personal data to carry out your official functions or a task in the public interest – and you have a legal basis for the processing under UK law – you can. If you are a
UK public authority, our view is that this is likely to give you a lawful basis for many if not all of your activities.

Legitimate interests: if you are a private-sector organisation, you can process personal data without consent if you have a genuine and legitimate reason (including commercial benefit), unless this is outweighed by harm to the individual’s rights and interests.

So basically under “Contract” and “Legitimate Interest” you’re fine.

You do require consent for using their data to send marketing communications - I can show you how this works. We capture marketing permissions in a granular, auditable, compliant way. For example, you are not allowed to require marketing consent as a condition for the fulfillment of a contract, and the system won’t let you do that because the marketing consent screen is after the purchase is complete. We don’t allow you to change marketing consent questions after people have agreed to them, in order to keep a history of what people have agreed to - instead, you have to create a new permission with the new text, which replaces the old one, and people have to agree to that separately.

[bencurthoys]

Response to another question:

“Is it possible to permanently delete personal details (names, addresses, emails, phone numbers, bank card details etc) of previous attendees of our events?”

Yes.

• There isn’t a button in the system you can press that will delete customers, but we will do it for you with scripts once we have identified the customers you want to delete and agreed the rules.

• We certainly don’t delete data on a schedule without a specific request: it’s your data, you’re the data controller, we are merely your data processor.

• There are a number of possible approaches that differ by the state they leave the database in for historical reporting and marketing queries:

1. Leave the customer account and order history intact, but delete all personal information (names, addresses, emails, phone number, login credentials, etc). This leaves us with a record that person X bought a ticket for show Y, and even that the same person X bought tickets for shows Y and Z and therefore that people who liked Y are likely to like Z. This also leaves us with consistent financial reporting of past shows Y and Z. Anonymisation is a complicated subject. It may also be permissible to just retain the postcode of an address; I don’t know about that.

https://ico.org.uk/for-organisations/guide-to-data-protection/anonymisation/

2. Delete the customer account and its order history, but leave the shows. This would prevent you from running marketing queries about people’s purchase habits, and put the show data in an inconsistent state: records of orders from users who were still active would still be present but orders from inactive users would be gone, so the total sales figures would inaccurate. This is a terrible idea and we probably wouldn’t do this even if you asked us to.

3. Delete old shows with all their order histories, so that the show is completely gone from the database, and then completely delete the records of customers who have not been active in a long time and who have no purchase histories (because the only orders they had ever placed were for shows which have been expunged). This at least leaves the database consistent, and has advantages for us (smaller database!) so we would do this if you were sure that option 1 wasn’t enough.