Data processing agreement

1. Parties, and why this agreement exists

This agreement applies between the organisation using Passavo — the CONTROLLER — and Fades Management EOOD, Legis Center, Blvd. 6-ti Septemvri 152, Office 3-8B, 4000 Plovdiv, Bulgarije, company number 208607050 — the PROCESSOR.

Article 28 GDPR requires a controller to set down in writing with every processor what that processor may do with the data. This page is that document.

It forms part of the terms and conditions. If you need your own model for a grant file or a tender, write to us at info@passavo.eu: we will sign it.

Where this agreement and the terms and conditions contradict each other about the processing of personal data, this agreement prevails.

2. Subject matter, nature and purpose

SUBJECT MATTER: processing personal data of the visitors and buyers of the organisation, in so far as that is needed to make the platform work.

NATURE OF THE PROCESSING: collecting, storing, consulting, organising, forwarding to the services the organisation connected itself, and erasing.

PURPOSE: the sale of tickets, their delivery and checking, the till on site, communication with the buyer about their order, and reporting to the organisation. Nothing else.

We do not use this data for our own purposes. We build no profiles with it, we train nothing on it, we do not sell it and we do not use it to serve other customers.

3. Duration

This agreement takes effect as soon as the organisation starts using the platform and runs for as long as the main agreement runs.

Whatever by its nature has to continue to apply — confidentiality, and the arrangements on return and erasure — continues to apply after the end as well.

4. Types of data and data subjects

DATA SUBJECTS: visitors and buyers of the organisation, and the people the organisation itself gives access to its account.

TYPES OF DATA:

• identification: name and email address, and whatever else the organisation adds to its order form;
• order data: which tickets, which time slot, amount and payment status;
• ticket data: the ticket number, the wallet pass where the buyer chooses one, and the moment of scanning at the door;
• the number of a social tariff pass, where the organisation works with the social tariff;
• technical data: IP address and time in the logs.

NO SPECIAL CATEGORIES. The platform is not intended for data about health, religion, political opinion, sexual orientation or ethnic origin, and the organisation makes sure it does not put any such data into it — not in a free text field either, nor in a note on an order.

A social tariff number is not in itself a special category, but it does say something about a visitor's financial situation. We therefore treat it with the same care: it is only visible to whoever needs it at the till.

5. Instructions

We process the data solely on documented instructions from the organisation. Those instructions consist of: this agreement, the terms and conditions, and the settings the organisation makes in its account. What it sets there is what we carry out.

If European Union or member state law obliges us to carry out a processing operation for which there is no instruction, we inform the organisation in advance, unless that law forbids it.

If we think an instruction breaches the GDPR, we say so, and we do not carry it out blindly.

6. Confidentiality

Only the people who need the data to do their work get access to it. With us that is a small circle.

Everyone with access is bound to confidentiality, and that obligation continues after the cooperation ends.

Access for support purposes happens at the request of the organisation, and is logged.

7. Security

We take appropriate technical and organisational measures (Art. 32 GDPR). Specifically:

• ENCRYPTION IN TRANSIT: all traffic to and from the platform runs over TLS. That goes for the scanning app and for the connections with payment providers too.
• ENCRYPTION AT REST: passwords are hashed with a modern, slow hashing function. Secrets such as the keys of a payment provider are stored encrypted in the database, with a key that is not in the database.
• ROLE-BASED ACCESS CONTROL: who may see or do what depends on their role within their own organisation. Every query is moreover tied to that organisation, so that the data of two customers cannot touch.
• APPEND-ONLY JOURNAL: the till journal can only be added to. A booked sale can no longer be changed or erased afterwards; a mistake is corrected with a new line that refers to the old one. For German customers every transaction is also signed technically.
• BACK-UPS: daily, kept encrypted, and we test whether they can be restored.
• SEPARATION OF ENVIRONMENTS: development and testing do not run on real customer data.
• MONITORING: we keep up with updates to the system and to the components it runs on, and we keep logs for 90 days so that an incident can be investigated.

We review these measures regularly and may replace them with measures that are at least equivalent.

8. Sub-processors

The organisation gives us general authorisation to engage the sub-processors below. A data processing agreement has been concluded with each of them that imposes at least the same obligations as this one.

• Contabo GmbH (DE) — servers and back-ups, in a data centre in Germany
• Wattify B.V. (BE) — sending and receiving our email
• Mollie B.V. (NL) — payments by visitors, straight into the account of the organisation (only where this applies)
• Stripe Payments Europe Ltd. (IE) — payments by visitors, straight into the account of the organisation (only where this applies)
• Payconiq International S.A. (LU) — payments by visitors, straight into the account of the organisation (only where this applies)
• Apple Inc. (US) — the ticket as a pass in Apple Wallet (only where this applies)
• Google Ireland Ltd. (IE) — the ticket as a pass in Google Wallet (only where this applies)
• publiq vzw (BE) — the social tariff: checking the pass number and registering the sale (only where this applies)
• fiskaly GmbH (DE) — the legally required signature under the till journal for German customers (only where this applies)
• Apple Inc. / Google Ireland Ltd. (US/IE) — distributing and updating the scanning app (only where this applies)

If we want to add or replace one, we say so by email at least 30 days in advance. If the organisation has a reasoned objection to that, we look for a solution together; if we do not reach one, it may cancel at no cost with effect from the date the change takes effect.

We remain fully liable towards the organisation for what a sub-processor does.

9. Assistance with data subject requests

If a visitor asks for access to, rectification, erasure, restriction or transfer of their data, the organisation decides on it — it is the controller, not us.

We assist it with appropriate technical means: it looks up, exports and erases a visitor's data itself in the system, by email address — on an order or under Settings → Export data. What it must keep by law, such as issued invoices, stays in place. If that does not work, we do it for them.

If such a request reaches us by mistake, we do not answer it ourselves. We forward it to the organisation within five working days and let the visitor know who to turn to.

This assistance is included in the price of the subscription. Only where the number or the size of requests is excessive may we charge the actual costs, and then we say so in advance.

10. Assistance with data protection impact assessments

If the organisation has to carry out a data protection impact assessment (Art. 35 GDPR) or consult its supervisory authority (Art. 36 GDPR), we provide the information only we have: which data is where, how it is secured and who else sees it.

We also assist with compliance with Articles 32 to 36 GDPR, in proportion to the nature of the processing and to what we can reasonably be expected to know.

11. Personal data breaches

If we establish a personal data breach, we inform the organisation concerned within 48 hours of establishing it. Not within 72 hours: those 72 hours are the period within which THEY have to inform their supervisory authority, and they only make it if they hear it from us earlier.

Our notification contains what we know at that moment: what happened, which types of data and roughly how many data subjects are involved, what the likely consequences are, and what we have done or are going to do about it. What we do not know yet, we honestly say so, and we add it as soon as we do know.

We do not notify the supervisory authority on behalf of the organisation and we do not inform its visitors ourselves: that is its decision. We do help it with it.

12. Return and erasure at the end

When the agreement ends, the organisation chooses: return or erasure.

• RETURN: it can export its data itself in a common file format: CSV, per list or everything together in one zip, under Settings → Export data. That option stays open for 30 days after the end.
• ERASURE: after that we delete the data from the active systems, and from the back-ups as soon as those expire on the normal schedule.

What we are legally required to keep — invoices, and the signed till journal of a German customer — stays until that period has run out, and is used for nothing else in that time.

If the organisation asks for it, we confirm the erasure in writing.

13. Audit

The organisation may check whether we do what is set out here. At its request we provide the information needed to demonstrate compliance with Article 28 GDPR.

If it wants an audit on site or by an independent auditor, that is possible, with reasonable notice, during office hours, at most once a year — and more often where there is a concrete reason, such as a data breach.

The auditor may not be a competitor of ours and is bound to confidentiality. The data of other customers stays outside the audit.

The organisation bears the costs of an audit, unless it shows that we fell short.

14. Changes

If the law changes, or the way the platform works changes, we amend this agreement. We announce that by email at least 30 days in advance.

If the organisation does not agree, it can cancel at no cost with effect from the date the change takes effect.

The version date at the top tells you which version you are reading. The version accepted at registration is kept with the organisation.