2. Data processing agreement (art. 28 GDPR)

2.1Parties and scope

1. Parties: the practice that uses LatinoSoft and has enabled one or more hosted services of Stardent B.V. ("the Practice", controller) and Stardent B.V., Europalaan 1E, 9551 DA Stadskanaal, the Netherlands, KvK 97830941 ("Stardent", processor).
2. This agreement applies to the hosted services in which Stardent processes personal data on behalf of the Practice: the managed mail rail and the online booking connector with its patient portal. It applies from the moment the Practice enables or pairs such a service in the software.
3. For the patient data in the desktop software itself there is no processor: that data never reaches Stardent (document 1, clause 1.3). For the update check, the code activation and the licence check Stardent is itself the controller (document 1, clause 1.2); those fall outside this agreement and are listed in Annex A for information only.
4. Where the processing of personal data is concerned, this agreement prevails over the licence terms and the general terms.

2.2Subject matter, duration, nature and purpose

1. Subject matter: hosting and relaying the data named in Annex A.
2. Duration: for as long as the service concerned is enabled, and thereafter until the deletion or return of clause 2.10 has been completed.
3. Nature: storage, transmission and deletion, automated, without any review of content by Stardent.
4. Purpose: solely rendering the service the Practice has enabled — delivering e-mail the Practice sends, and bringing appointments booked online to the Practice. Stardent uses the data for nothing else, not in anonymised form either, and not for statistics.

2.3Categories of data subjects and of data

See Annex A. In short: patients and contacts of the Practice; identifying data and contact data; and, because the Practice is a dental or medical practice, the fact that a person is a patient there or books an appointment, which is data concerning health within the meaning of art. 9 GDPR. The Practice processes that data on the basis of art. 9(2)(h) GDPR; Stardent processes it only on the instruction of the Practice.

2.4Documented instructions

1. Stardent processes the data only on documented instructions from the Practice. The instructions are: this agreement, the settings the Practice makes in the software (pairing the booking module, switching on its patient portal, the books, time windows and cancellation terms it publishes, enabling the mail rail and the automatic messages of document 1, clause 1.8(4)), and later written instructions sent to dentalsoft@godentalplace.com.
2. Stardent does not transfer data to a country outside the European Economic Area unless the Practice instructs so in writing or Union or Dutch law requires it; in the latter case Stardent informs the Practice beforehand, unless that law prohibits such information.
3. If Stardent considers that an instruction infringes the GDPR or other law, it informs the Practice immediately and suspends that instruction until the Practice has decided.

2.5Confidentiality

1. Stardent keeps the data confidential. Only the persons who administer the service have access, and only to the extent administration requires.
2. Those persons are bound to confidentiality, by contract or by law.
3. Stardent does not look at the content of e-mail or bookings, except where that is necessary to resolve a fault the Practice has reported, and then as narrowly as possible.

2.6Security (art. 32 GDPR)

1. Stardent takes the technical and organisational measures of Annex C, part 1. They are the measures actually in place on the date at the top; nothing is promised that has not been set up.
2. The Practice takes the measures of Annex C, part 2. The software runs on hardware of the Practice and adds no encryption of its own; what protects the data there is arranged by the Practice.
3. Stardent holds no certification, no ISO registration and no external audit report for these services, and claims none.

2.7Sub-processors

1. The Practice gives general authorisation for the sub-processors in Annex B. On the date at the top that is, for the hosted services, Hetzner Online GmbH as hosting provider only.
2. If Stardent wishes to add or replace a sub-processor, it notifies the Practice at least 30 days in advance by e-mail and on https://latinosoft.godentalplace.com, stating name, country and role.
3. The Practice may object in writing within those 30 days. If the parties cannot resolve the objection, the Practice may terminate the service concerned as of the effective date of the change without cost; prepaid fees for the remaining period of that service are refunded pro rata.
4. Stardent imposes on every sub-processor the same obligations as in this agreement and remains fully liable to the Practice for that sub-processor's performance.

2.8Assistance with data subject rights and with a DPIA

1. If Stardent receives a request from a data subject concerning data of the Practice, it forwards it to the Practice within five working days and does not handle it itself.
2. Stardent assists the Practice, with the means it has, in answering requests under Chapter III GDPR. In practice that assistance is limited: the booking server holds the name and contact details of a booking only until import and otherwise holds hashes, appointment times and booking references, and the mail rail relays messages the Practice itself composed or had the software compose from its own templates.
3. Stardent provides the information in this canon and, on request, further technical information the Practice needs for a data protection impact assessment (art. 35 GDPR) or a prior consultation (art. 36 GDPR). Whether a DPIA is required is for the Practice to assess.

2.9Personal data breaches

1. If Stardent discovers a personal data breach concerning data it processes for the Practice, it informs the Practice without undue delay and at the latest within 24 hours after becoming aware of it, by e-mail to the address the Practice has configured in the software and, where known, to the contact person of the Practice.
2. The notice contains what is known at that moment: the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, the measures taken and proposed, and a point of contact. What is not yet known follows as soon as it becomes known.
3. The Practice decides on notification to the supervisory authority and to data subjects. Stardent does not notify on behalf of the Practice unless the Practice instructs so in writing.
4. Stardent keeps a register of breaches and gives the Practice, on request, access to the entries that concern it.

2.10Deletion and return at the end

1. When a service ends, Stardent deletes within 30 days all personal data it still holds for the Practice for that service, unless Union or Dutch law requires storage. For the booking module that means: bookings not yet imported, the published time windows, the HMAC hashes of patients and of personal links, the cancellation terms, the booking states, the record of the patients' own cancellations and rebookings, and the pairing data. For the mail rail: the queue and the delivery logs, where present.
2. If the Practice wants a copy of bookings not yet imported beforehand, it requests it within those 30 days through dentalsoft@godentalplace.com and receives it in a common, machine-readable format.
3. For the practice database itself there is nothing to return: it sits with the Practice (document 5).
4. Stardent confirms deletion in writing on request.

2.11Audit and accountability

1. Stardent makes available to the Practice the information necessary to demonstrate compliance with this agreement: this canon, Annex C, and on request written answers to specific questions within 20 working days.
2. If that does not suffice, the Practice or an auditor it designates who is bound to confidentiality may, once a year, on at least 30 days' notice, during office hours, conduct an audit limited to the processing for the Practice. The Practice bears its own costs and compensates Stardent's reasonable time, unless the audit reveals a material breach.
3. An audit that would expose data of other practices is arranged so that this does not happen.

2.12Liability

1. Each party is liable for the damage caused by its own non-compliance with the GDPR or with this agreement, having regard to art. 82 GDPR.
2. For the rest, the limitation of liability in document 4, clause 4.10, applies to this agreement as well. An administrative fine imposed on a party for its own infringement is borne by that party.

2.13Term and termination

1. This agreement lasts for as long as Stardent processes personal data for the Practice under a hosted service and ends after the deletion of clause 2.10.
2. If the Practice disables the service or unpairs the module, that counts as termination of the processing for that service.

2.14Final provisions

1. Dutch law applies. Disputes are brought before the District Court of the Northern Netherlands (rechtbank Noord-Nederland), Groningen location, without prejudice to the right of a data subject or a supervisory authority to act elsewhere.
2. Changes to this agreement are agreed in writing; a revised canon version takes effect after 30 days' notice unless the Practice objects within that period, in which case clause 2.7(3) applies accordingly.

Annex A — Processing details

A.1 Online booking connector (Stardent = processor, where the booking server is Stardent's)

• Data subjects: patients and prospective patients of the Practice who book an appointment online.
• Data the Practice publishes: open time windows (book, date, start time, duration, the treatments allowed, booking step, minimum notice, how far ahead) with the Practice's time zone and its list of treatments offered online (number, name, duration); HMAC-SHA256 hashes of (patient number | date of birth) of active, living patients, keyed with the Practice's own secret; where the patient portal is on, HMAC-SHA256 hashes of the patients' personal links, keyed with the same secret; the Practice's cancellation terms (deadline in hours, no-show text and web address); for each appointment booked online, its reference, date, start time, duration, book, treatment and status (confirmed or cancelled). See document 1, clause 1.9(1).
• Data the booking server receives from the patient: for a new patient first name, name prefix, last name, date of birth, telephone number, e-mail address and, only if the patient gives it, sex (F or M); for an existing patient the patient number and the date of birth the patient types, which the server checks against the hashes, and of which only the patient number is passed on to the Practice; for a patient using the personal link only the link, which the server checks against the hashes; the chosen time window and treatment; the patient's own cancellations and rebookings, with their time. No citizen service number.
• Special category: the fact of an appointment at this practice and the treatment booked (data concerning health, art. 9 GDPR).
• Retention on the server: the name and contact details of a booking until import into the practice database is acknowledged (ack); deleted thereafter. Maximum period for bookings never imported: unknown, still to be set. Time windows, hash lists and cancellation terms: until the Practice publishes the next version, or until the end of the service (clause 2.10). Booking states and the record of the patients' own changes: period unknown, still to be set.
• Location: rented server at Hetzner Online GmbH, Helsinki, Finland.

A.2 Managed mail rail (Stardent = processor)

• Data subjects: recipients of e-mail the Practice sends from the software (patients, contacts).
• Data: e-mail address and the content of the message as the Practice composes it, or as the software composes it from the Practice's templates (appointment confirmation, appointment reminder, recall, invoice, payment reminder with the invoice attached as a PDF that names the treatments, invitation to the patient portal, newsletter). See document 1, clauses 1.8 and 1.9(4).
• Retention: the queue until delivery; delivery logs: period unknown, still to be set.
• Location: Stardent's own mail server (Stalwart) on the rented infrastructure at Hetzner Online GmbH, Helsinki, Finland, reached through the managed SMTP preset or the SoftlexMail service. Third-party e-mail service: none.

A.3 For information — traffic for which Stardent is itself the controller (outside this agreement)

• Update check: the IP address and time of the request to https://latinosoft.godentalplace.com/updates.json.
• Code activation: the code, the machine hash and the product key, to https://pay.stardentlab.com/api/activate, only when a code is redeemed.
• Licence check: licence number, machine hash, software version, and the Installation's role and number within the practice's Licences, only when SOFTLEX_LICENSE_HUB names a hub; with such a hub, a request to move a Licence to another computer, carrying the licence number, only when a user asks for it.
• See document 1, clauses 1.5, 1.6 and 1.12.

Annex B — Sub-processors

Reference of the data processing agreement between Stardent and Hetzner: unknown; still to be recorded by Stardent. Other sub-processors: none.

Annex C — Security measures

Part 1 — Taken by Stardent

1. Servers exclusively within the European Union (Helsinki, Finland).
2. Data minimisation in the booking module: the server holds no patient file; existing patients are recognised through HMAC hashes, and personal links only as HMAC hashes; hashes are published only for active, living patients; the personal data of a booking is deleted as soon as import is acknowledged.
3. Transport security: the addresses for the update check and the code activation are served over HTTPS. The software pairs the booking module only with an HTTPS address (plain HTTP only for a server on the same computer) and refuses any other address before a connection is opened, so the practice key and the booking data do not cross a network in clear text. For the mail service the address entered in the settings applies.
4. Own mail server (Stalwart) on own rented infrastructure; an external e-mail service never sees the messages.
5. Administrative access to the server limited to the persons who administer it.
6. Access log with IP address and time, for fault analysis and abuse detection; retention period unknown, still to be set.
7. In the software: user passwords as PBKDF2-SHA256, 100,000 iterations, salt per user.
8. Breach notification procedure: 24 hours (clause 2.9).

Part 2 — To be taken by the Practice

1. Disk encryption (for example BitLocker) on the main server and on every workstation.
2. A separate Windows account per staff member, with password or PIN, and automatic locking.
3. The database server (MariaDB/MySQL) reachable only inside the practice's own network or over VPN; the database port never exposed directly to the internet; a strong, unique database password.
4. Operating system and database kept current with security updates; an active firewall and virus scanner.
5. A separate user account in LatinoSoft per staff member; accounts of departed staff disabled immediately.
6. Backups according to document 5, kept off the machine and tested for restore periodically.
7. Physical security of the main server (locked room or cabinet).
8. An internal breach procedure, so that the 72-hour notification to the supervisory authority is met.