Data Processing Addendum

1. What this addendum covers

In this addendum:

• “you” means the organiser, and “we” means Bazm Ltd;
• “data protection law” means the UK GDPR and the Data Protection Act 2018 and, where it applies to you, the EU GDPR;
• “your participants’ data” means the personal data that we process on your behalf in providing the Service: the data described in Annex 1.

It does not cover personal data for which we are the controller, such as people’s Bazm accounts and our own security logs. Our Privacy Policy covers those.

2. Your role and ours

You are the controller of your participants’ data and we are your processor. You are responsible for:

• having a lawful basis for collecting and using the data;
• telling participants how you use it, in your own privacy notice;
• asking only for what you need, and having a lawful condition for any special category data you ask for, such as dietary or access requirements;
• giving us only instructions that comply with the law.

3. We act on your instructions

We process your participants’ data only on your documented instructions. Your instructions are the Terms of Service, this addendum, and the way you and your team set up and use the Service. We may also process the data where the law requires us to; if so, we tell you first unless the law forbids it. If we think an instruction breaks data protection law, we tell you.

4. Our people

Everyone at Bazm who can access your participants’ data is bound by a duty of confidentiality and may access it only as far as their work requires. Access to your account for support requires a recorded reason, ends automatically after an hour, and the changes made are written to your audit log. The engineers who run the Service can reach its servers and database when that is needed to keep it working or to fix a fault.

5. Security

We keep in place the technical and organisational measures in Annex 2 to protect your participants’ data. We may change them as the Service develops, but not in a way that lowers the overall level of protection.

6. Other companies we use

You give us general permission to use other companies (sub-processors) to help provide the Service. The current list is on the sub-processors page.

• We have a written contract with each sub-processor that requires it to protect the data to the standard this addendum requires of us.
• We remain responsible to you for what our sub-processors do.
• Before a new sub-processor starts processing your participants’ data, we update that page and email organisation owners at least 30 days in advance.
• You may object within those 30 days on reasonable data protection grounds. We will discuss your objection in good faith. If we cannot resolve it, you may stop using the part of the Service that depends on the new sub-processor and we will refund any fees paid in advance for it.

7. Requests from participants

The Service lets you find your participants’ records, and export, correct or delete some of them yourself. Where it does not, for example to erase or correct one attendee’s registration, write to us and we will do it for you without undue delay. If a participant sends a request about your conference’s data to us, we pass it to you without undue delay and do not answer it ourselves, other than to say that we have passed it on. We give you reasonable help to answer it.

8. Helping you comply

Taking into account what we do and the information we have, we give you reasonable help with data protection impact assessments, with consulting a regulator, and with showing that you meet your own security and breach-notification duties.

9. If something goes wrong

If we become aware of a personal data breach affecting your participants’ data, we tell the owners of your organisation without undue delay, and in any case within 72 hours. We tell you what happened, what data and roughly how many people are affected, what we are doing about it, and who to contact, adding to this as we learn more. We take reasonable steps to contain the breach and limit its effects.

10. Where the data is processed

Our servers and database are in the United Kingdom. Some sub-processors process data elsewhere, as the sub-processors page shows. Where your participants’ data goes to a country that the UK has not recognised as giving adequate protection, we make sure a safeguard the law allows is in place: the UK’s adequacy regulations, or the International Data Transfer Agreement or Addendum approved by the UK Information Commissioner.

If you are established in the European Economic Area and the transfer of your participants’ data to us is not covered by an adequacy decision, the European Commission’s Standard Contractual Clauses for transfers from a controller to a processor apply between you and us and are incorporated here, with Annex 1 and Annex 2 of this addendum as their annexes.

11. When the agreement ends

While you use the Service you can export and delete some of your participants’ data yourself, and we do the rest when you ask (section 7). You can set a retention period after which attendees’ registration and booking answers, the documents uploaded with them and issued certificates are removed.

When you close your organisation, your participants’ data is deleted after a 30-day period in which you can change your mind. Within 90 days of closure we delete or irreversibly anonymise the rest of the data we hold on your behalf, except:

• payment and invoice records, which the law requires us to keep for 6 years;
• signed contracts and the evidence of signing, kept for 6 years after the contract ends;
• copies in our encrypted backups, which are deleted within 30 days.

12. Showing that we comply

On request we give you the information reasonably needed to show that we meet this addendum. If that is not enough, you or an independent auditor you appoint may audit our processing of your participants’ data once in any 12 months, on at least 30 days’ written notice, during business hours, at your cost, under a duty of confidentiality, and without access to other customers’ data.

13. Liability and law

Each party’s liability under this addendum is subject to the limits in the Terms of Service. This addendum lasts for as long as we process your participants’ data, and is governed by the same law as the Terms of Service. Questions: contact@bazm.io.

14. Annex 1: details of the processing

15. Annex 2: security measures

• Hosting. The application and database run in a data centre in the United Kingdom. Uploaded files are held in object storage that encrypts data at rest.
• Encryption in transit. All connections to the Service use TLS.
• Separation of customers. Each organiser’s data is kept apart by row-level security rules enforced in the database on every table that holds organisers’ data.
• Access control. Team roles (owner, admin, manager, viewer) limit what each member of your team can do, for the whole organisation or one conference.
• Sign-in. Passwords are stored only as salted hashes. Email addresses must be verified. Sessions use short-lived tokens.
• Files. Private files are served only through signed links that expire after minutes. Location and camera metadata is removed from uploaded photos of people.
• Payments. Card numbers and security codes are entered with and held by Stripe. They never reach our servers. The record of a payment that Stripe sends us can include the card type, its last four digits and its expiry date.
• Backups. The database is backed up nightly. Backups are encrypted before leaving the server, the decryption key is kept offline, and backups are deleted after 30 days.
• Logging. Actions in your account are recorded in an audit log kept for 13 months. Application logs are kept for 14 days. The server’s own system log, which records some requests at the web server, is kept until its oldest entries are overwritten, about 4 months. Sign-in links and access tokens are removed from application logs and error reports.
• Staff access. Named Bazm administrators open a customer’s account only through a support session that requires a recorded reason, expires after an hour and is logged. They can also look up an account and, on request, reset its password; a reset made in the admin console is logged with its reason. A small number of engineers can reach the servers and database to run the Service.
• Monitoring. Errors and failed scheduled jobs raise alerts to our engineers.
• Development. We run automated tests, type checks and static analysis before publishing a release. Secrets are kept on the server and not in source code.
• Email hygiene. Addresses that bounce or complain are suppressed, and sending is paused for an organiser whose emails draw too many complaints.