Data processing agreement

1. Parties, and when this agreement applies

This agreement applies between two parties:

• The processor: ICT Basis, Ooievaarlaan 7, BE-9800 Deinze, company and VAT number BE 0830.568.042, publisher of Prezentix. Contact for everything in this document: [email protected].
• The controller: the organisation that takes out a Prezentix subscription, with the details as they appear in the customer portal and on the invoices.

It takes effect as soon as we start processing for you — at the start of your trial or of your subscription — and runs for as long as that is the case. No signature is needed for that; we will provide one on request.

2. What we process, and what for

The subject matter of the processing is the delivery of Prezentix: visitors sign in at a kiosk or in advance through an invitation, the right employee is notified, the visit is closed off, and you are left with an overview and reporting.

The nature of the processing is therefore: collecting, organising, storing, consulting, forwarding to the recipients you designate, anonymising and deleting. The categories of data subjects and data are set out in full in Annex 1.

The duration runs with your subscription, extended by the periods in §13. Within that duration, your own retention policy determines how long a registration is kept; without a choice of your own that is 90 days.

3. We process only on your instruction

We process your personal data solely on your documented instruction (article 28.3.a GDPR). The following counts as an instruction:

• this agreement and the agreement it belongs to;
• the configuration you make yourself in the customer portal — which fields appear on the screen, which text a visitor reads, who gets notified, which reports go to whom, and which retention periods apply;
• the API keys you create yourself in the customer portal, with the access rights you choose per key: what a key may read or create is your instruction;
• an express request from your administrator to our support, for instance to correct or delete a registration.

Outside those instructions we never use your visitors’ data for our own purposes. We do not sell it, do not use it for advertising and do not train models on it — not even in anonymised form. We never bring the registrations of different customers together into one list or file.

What we do keep are counts: how many registrations, pre-registrations and call minutes there have been per customer environment. We use those to invoice, to follow the platform’s capacity and to see that the service works. Such counts contain no visitor data at all — no name, no e-mail address, no company — and cannot be traced back to a person. For our own monitoring and for public figures about Prezentix we sometimes add them up across customers; what comes out is a single number per country or per period, in which no individual customer and no individual person can be distinguished.

Where Union or Belgian law nevertheless requires us to process, we inform you beforehand, unless that law prohibits it on important grounds of public interest.

If we believe an instruction infringes the GDPR or other data protection rules, we tell you immediately. We may suspend the execution of that instruction until it has been adjusted or confirmed.

4. What you do as controller

The division is simple: you determine why and how the processing takes place, we carry it out and secure it. Concretely, the following is yours:

• Making sure there is a valid legal basis for registering your visitors and that your use of Prezentix is lawful.
• Informing your visitors. The text on the screen, the house rules and the reference to your own privacy statement are yours; we provide the place where that text goes, not the text itself.
• Asking only for the fields you genuinely need, and setting retention periods that fit your policy.
• Managing who has access: which users you create in the portal, with which role, and deactivating leavers in good time. Signing in runs through your own Microsoft environment, so your policy on multi-factor authentication and conditional access applies in full.
• Securing the kiosk physically: placement, supervision and the kiosk mode of the device are your domain.
• Answering requests from data subjects — we help you with that, see §9.

If you switch on the AI reception assistant

That feature is off by default. If you switch it on, the AI Act — Regulation (EU) 2024/1689 — comes into play alongside the GDPR. The division of roles runs parallel to the GDPR one: we are the provider of the AI system, you are the deployer.

We stand behind the following: the screen shows the visitor that they are talking to an AI assistant (Article 50); the assistant recognises no faces, measures no emotions and takes no decisions about people; and the processing takes place at the sub-processor in the European Union named in Annex 2.

We also stand behind this: the assistant makes nothing up. It answers only from what you have given it - your instructions, your knowledge items and your employee directory. Where the answer is not in there, it tells the visitor that it does not know and that it will find out, and passes the question to the member of staff you nominate. You choose that address yourself per organisation, location or screen; leave it empty and the question goes to your portal administrators.

Of you the regulation asks little more than what you already do: the staff who work with the assistant, or explain it to visitors, need to know what it does and where its limits lie (Article 4). We will send you a short description of how it works on request. If you use the assistant for anything other than receiving visitors, tell us: that may change the classification.

5. Confidentiality

Everyone on our side who can gain access to your data is bound to confidentiality, either by a statutory duty of confidentiality or by a contractual undertaking that survives this agreement (article 28.3.b GDPR).

That access remains limited to those who need it for support, maintenance or resolving an incident, and to what is needed for that. We do not take copies of your data outside the environment in which the service runs.

6. Security

We take appropriate technical and organisational measures (article 32 GDPR). They are set out in full in Annex 3. The main lines:

• Every customer has its own, separated part of the database — visitor data of different organisations is never in the same tables.
• Signing in runs through Microsoft Entra ID, or with a one-time six-digit code by e-mail. In neither case do we store a password; the code is kept only as an irreversible hash and expires once used.
• All traffic is encrypted over TLS; access tokens are stored encrypted in the database (AES-256-GCM).
• The servers have no inbound ports open to the internet; the connection is established from the inside out.
• What your retention policy no longer needs is cleaned up automatically, and that clean-up is recorded.

We may adjust those measures to new insights or new technology, as long as the level of protection does not drop. The current version is always on this page.

7. Sub-processors

You give us general written authorisation to engage the sub-processors listed in Annex 2 (article 28.2 GDPR). We engage no one beyond that list.

• We impose on every sub-processor, by contract, the same obligations as those set out here, in so far as they apply to it.
• We remain fully liable towards you for what a sub-processor does or fails to do.
• If we want to add or replace one, we let you know at least 30 days in advance, by e-mail to the administrators listed in your customer portal.
• You may object within that period on reasonable grounds relating to data protection. If we cannot resolve it together, you may discontinue the part of the service concerned without any charge for the remaining period.

Stripe (payment of your subscription) and one.com (hosting of our marketing site) are deliberately not in Annex 2: they never come into contact with your visitor data. They process data for which we are the controller ourselves — that is covered in our privacy policy.

8. Where the data is kept

The application and the database holding your visitor data run on ICT Basis’s own hardware in Belgium. That hardware is not directly reachable from the internet: traffic runs through an outbound, encrypted tunnel.

The Microsoft services in Annex 2 are chosen so that the processing takes place in the European Union. Cloudflare provides secure access to the application and may, as part of routing that traffic, process data outside the European Economic Area.

That transfer is covered by the European Commission’s standard contractual clauses, supplemented by the EU-US Data Privacy Framework for parties certified under it. We make no other transfers outside the EEA without informing you beforehand and without a valid transfer mechanism.

Where you retrieve data yourself through our API, it ends up in a system you choose — your reporting, your planning. You decide where that system is; we do not know. If it sits outside the European Economic Area, that transfer is yours and not ours, and it is for you to have a valid transfer mechanism in place. We are not a party to what happens to the data after that.

9. Assistance with data subject requests

A visitor who wants to access, correct or delete their data turns to you — it is your processing. We make sure you can answer (article 28.3.e GDPR):

• In the customer portal you see the registrations, search and filter them, and export them to CSV. That covers most access and portability requests.
• What you cannot do yourself, we do on your written request within 10 working days: correct, anonymise or delete an individual registration, or provide a targeted extract.
• If a request reaches us by mistake, we do not answer it ourselves. We forward it to you immediately and let the person know where they should be.

That assistance is included in the price. Only where requests are excessive or systematically repeated may we charge the actual cost — and then we say so beforehand, with an estimate.

10. Assistance with security, impact assessment and supervision

We help you meet your obligations under articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to us. In practice:

• We provide what you need for a data protection impact assessment (DPIA): what is processed, where it is kept, who gets to see it and how it is secured. The annexes to this document can serve as the source for that.
• We cooperate with a prior consultation of the supervisory authority where your assessment calls for one.
• We help you assess and report an incident (see §11) and answer questions from the data protection authority that concern our processing.

11. Personal data breaches

If we establish a personal data breach, we notify you without undue delay and at the latest within 48 hours after becoming aware of it (article 33.2 GDPR). We notify the administrators listed in your customer portal.

That notification contains what we know at that moment:

• the nature of the breach and, as far as possible, the categories and number of data subjects and records concerned;
• the likely consequences;
• the measures we have taken or propose to limit those consequences;
• who to contact at our end for more information.

If we do not know everything yet, we first report what we do know and supplement it as soon as more becomes clear. We keep a record of the incidents that affect your environment and how they were handled.

12. Information and audit

We make available all information necessary to demonstrate compliance with the obligations of article 28 GDPR, and we allow for audits (article 28.3.h).

• On simple request we provide our security overview, the current list of sub-processors, the measures in Annex 3 and the evidence that your retention policy has been executed.
• If that is not enough, you may have an audit carried out once per calendar year — by yourself or by an independent auditor who is not a competitor of ours and is bound to confidentiality.
• You announce it at least 30 days in advance; it takes place during office hours and does not disrupt the service.
• The auditor gets no access to other customers’ data. Where that cannot be separated, we present the information in summarised or anonymised form.
• You bear the cost of an audit, except where it reveals a material shortcoming on our side: then we bear the cost and remedy it at our expense.

On reasonable suspicion of a breach, or after an incident that affected your environment, an audit may also take place in between, without that yearly limit.

13. End of the agreement

At the end of the service you choose what happens to the data: return or deletion (article 28.3.g GDPR). If you tell us nothing, we delete it.

• For as long as your subscription runs, you export to CSV yourself at any moment.
• After the end, your environment stays available for 30 days so you can export. If you ask us for the export, we provide it within that period in a common format.
• After that we delete your entire environment within 30 days: the database schema with the visitor, pre-registration and call data, the synchronised employee data, the generated sign-in pages, the linked devices and the portal users.
• Backups still containing your data roll out of the cycle within 35 days. For as long as they exist they stay encrypted and are no longer used, other than to recover from an outage.
• On request we confirm the deletion in writing.

What we are legally required to keep, we keep: our invoices and accounts for 7 years. They contain no visitor data — only your organisation, your subscription and the amounts.

14. Liability

The liability arrangement in the agreement to which this data processing agreement belongs applies here too. Article 82 GDPR continues to apply in full: towards a data subject, each party remains liable for the damage caused by its own failure.

If one of the parties pays more than its share of the damage or of a fine, it may recover the excess from the other party, in proportion to each party’s share in the cause.

15. Duration, changes and applicable law

• This agreement runs for as long as we process personal data for you. What by its nature continues to apply — confidentiality, deletion, assistance with an ongoing investigation — remains in force after the end.
• If we change something substantive, we announce it at least 30 days in advance by e-mail to the administrators in your customer portal, with a new date at the top of this page. If you do not accept the change, you may terminate the agreement as of the effective date.
• This agreement is governed by Belgian law. Disputes fall within the jurisdiction of the Ghent enterprise court, Ghent division, unless mandatory law designates another court.
• If a provision is void, the rest stays in force and we replace it with a valid provision that comes as close to it as possible.

The current version is always at https://www.prezentix.com/dpa/.

Annex 1 — Processing operations, data subjects and data

What exactly is processed depends on what you configure and on the features you switch on. This is the full list of what the platform can record.

Retention: according to the policy you set per organisation and per site — anonymise after X days, delete after Y days. Without a choice of your own, 90 days applies. A daily job carries that out and records what was cleaned up.

Visitor data only leaves the platform towards the recipients you designate yourself: the employee being notified, the recipients of your scheduled reports, the invitees in pre-registration, and — if you switch that on — the systems you connect yourself with an API key, and the addresses you have us notify with a webhook.

If you send data to an address of your own with a webhook, or fetch it with an API key, you choose that destination yourself. That choice is your instruction under article 3 and falls under your responsibility: if the receiving system sits outside the EEA, that is a transfer you arrange, not us. We are not an intermediary in it, and the receiving system is not a sub-processor of ours — it is your own system.

A visitor’s e-mail address and phone number are only included through the API when you expressly grant a key the right to read them. Without that right, those two fields are left out. For a visit that your retention policy has anonymised, they are left out even with that right.

Annex 2 — Sub-processors

These are all the sub-processors that may be involved in processing your data, with the reason why and the place where they process.

We host the application and the database ourselves; no external hosting party is involved. Beyond this list we engage no one.

A change to this list is announced at least 30 days in advance, as agreed in §7.

Annex 3 — Technical and organisational measures

The measures with which we achieve the level of protection article 32 GDPR requires, grouped by subject.

Access and identity

• Administrators sign in with their own Microsoft account (Entra ID, OAuth 2.0), or with a one-time six-digit code by e-mail where you do not use a Microsoft connection. In neither case do we store a password. On the Microsoft route your policy on multi-factor authentication and conditional access keeps applying; on the e-mail route the code allows five attempts, is valid for ten minutes and expires once used.
• After a successful sign-in we additionally check that the Microsoft environment is known as a customer and that the user belongs to that customer.
• Sessions live on the server; the cookie is not readable by JavaScript, travels only over HTTPS and expires after 24 hours.
• Sensitive administrative actions require the administrator role. Every request reads the customer from the server session, not from what the browser sends along.
• We do not keep an API key: only a SHA-256 fingerprint of it. It is therefore visible once, at the moment you create it. Each key carries only the access rights you choose, revoking takes effect immediately, and there is a limit on the number of requests and on the number of active keys.
• If you switch webhooks on, a message sits briefly in a queue with us until it has been delivered. By default such a message contains no names — only the visit number, the timestamps, the site and whether consent was given. If you explicitly opt for the full contents, name, company, host and badge number travel along too, and we record who made that choice and when. We clear the contents of the queue as soon as every attempt is finished, and in any case within 48 hours; the delivery log itself keeps only timestamps, status codes and a fingerprint of the message, never its contents.
• Our own access to your environment stays limited to support, maintenance and faults, and to those who need it. Alongside that we follow the service in counts; that monitoring opens no visitor record.
• If a question or a fault does require us to look inside your environment, we ask you beforehand. An administrator of your organisation approves, the access is limited in time and expires by itself, and the visitor list stays closed unless you explicitly approve that as well. Everything that happens during that access is recorded, and afterwards we send you the overview of it.

Separation between customers

• Every customer has its own database schema with its own tables. Visitor data of different organisations is never in the same table.
• Which schema is used follows from the server session or from the subdomain of the request — never from anything the browser sends along. Unknown subdomains are refused.
• All values travel as parameters in database statements, including in search, export and reporting.
• One exception: our own management console counts across the environments how many registrations, pre-registrations and call minutes there have been. In doing so it reads counts only and opens no visitor record.

Encryption

• Traffic between visitor, administrator and the platform: TLS/HTTPS.
• Access tokens for calling and the Microsoft token cache of paired devices: AES-256-GCM in the database, with a key that lives in the environment, outside the code.
• Tokens, secrets and password fields are kept out of the logs.

Network and hosting

• No inbound ports: the connection outwards is established from the inside, through an encrypted tunnel.
• Protection against attacks and TLS termination at the edge, with a fixed number of trusted proxy hops so a client cannot spoof its IP address.
• The web application and the background jobs run as separate processes: a problem in a job does not affect the kiosks.
• In production, the application may not create databases or schema changes itself.

Kiosk

• A screen is bound to a subscription with a one-time pairing code and proves on every request that it is the paired screen, with a signed session validated on the server.
• A kiosk has no administrator session: the portal and the settings cannot be reached from it.
• Kiosk responses are not cached, so a revoked or expired status does not linger.
• The number of calls per device is limited, to counter misuse of an unattended kiosk.

Retention and deletion

• Your retention policy runs as a daily job: anonymise, delete or both, per organisation and per site.
• What was cleaned up is recorded per customer: which action, which period, how many registrations and when.
• A single command removes an entire customer environment: schema, administrative data, generated sign-in pages and paired devices.

Backup and recovery

• The database is backed up daily. Backups are stored encrypted and separately from the running environment, and are accessible only to those who administer that environment.
• Backups exist for at most 35 days and then roll out of the cycle.
• There is a written recovery procedure that rebuilds the environment and the database schema.

Organisation

• Everyone with access is bound to confidentiality; access is granted according to what the task requires and withdrawn when it is no longer needed.
• Changes to the application are tested before they go into production; secrets live outside the source code.
• We keep a record of which incidents affect your environment and how they were handled.

Contact and signature

Questions about this document, a signed copy, or your own template you would like to put forward: [email protected].

• Company: ICT Basis
• Address: Ooievaarlaan 7, BE-9800 Deinze
• Company and VAT number: BE 0830.568.042
• E-mail: [email protected]

This agreement applies without a signature as soon as we process on your behalf. If your organisation needs a signed copy for its own records, we provide one within five working days.

How we handle the data for which we are the controller ourselves — your contact details, your subscription, your administrator accounts — is set out in our privacy policy.