Between the Customer who accepts this agreement on the platform, with the details from the master data of its customer account – hereinafter “controller” –
and Einlasshelden.de – owner: Sebastian Reinhardt sole proprietorship Peperkamp 2 25451 Quickborn, Germany – hereinafter “processor” –
– controller and processor individually also “party”, together “parties” –
Preamble
The processor provides the controller with the software-as-a-service platform “Einlasshelden” (also under the brand “GateHeroes”) for managing events (including registration of guests, issuing and checking admission entitlements/tickets, admission control, communication with guests by e-mail and related evaluations). In doing so, the processor processes personal data on behalf of and on the instructions of the controller.
This agreement specifies the data protection rights and obligations of the parties in connection with this processing on behalf (Art. 28 GDPR). It applies to all activities that the processor performs for the controller under the underlying main contract (contract for the use of and services on the platform, hereinafter the “Main Contract”) and in which personal data is processed.
§ 1 Subject matter, nature and purpose, duration of the processing
(1) The subject matter of the processing is the provision of the platform services agreed in the Main Contract. Details of the subject matter, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out exhaustively in Annex 1.
(2) The nature of the processing comprises in particular the collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, transmission (sending of e-mails), restriction, erasure and destruction of personal data by means of the platform.
(3) The purpose of the processing is the organisation and management of events of the controller (registration, admission, communication). Insofar as the processor processes data for its own purposes (billing, review of published content under the Terms of Use), it is itself a controller for this; this is governed by the privacy policy.
(4) Duration. The processing on behalf begins when the Main Contract takes effect and is limited to its term. This agreement ends with the termination of the Main Contract, but not before the erasure or return under § 9 has been completed (30 days of read access with export, then erasure); the obligations regarding erasure/return (§ 9) and continuing confidentiality obligations remain unaffected.
(5) Place of processing. The processing takes place in a member state of the EU / the EEA; exceptions are listed in Annex 3 (see § 4 para. 10). A relocation to a third country requires the conditions of § 4 para. 10 to be met.
§ 2 Instructions and rights of the controller
(1) Within the scope of this agreement, the controller is solely responsible for assessing the lawfulness of the processing and for safeguarding the rights of data subjects (Art. 4 no. 7, Art. 24 GDPR).
(2) The processor processes the data exclusively on documented instructions from the controller (Art. 28(3)(a), Art. 29 GDPR), unless it is required to do so by Union or member state law; in such a case, it informs the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
(3) The specific instructions result first from this agreement and the Main Contract. The controller usually gives instructions by using the functions and configuration settings of the platform (e.g. creating/deleting events and guests, defining form fields and legal texts, triggering the sending of e-mails). Individual instructions beyond this are given in text form (e.g. e-mail) to the point of contact named in § 8. Consumers may also give instructions via the standard functions provided by the platform (e.g. delete buttons in the dashboard).
(4) The processor informs the controller without undue delay if, in its opinion, an instruction infringes data protection provisions (Art. 28(3) sentence 3 GDPR). The processor is entitled to suspend the execution of the instruction concerned until it is confirmed or changed by the controller.
(5) The controller confirms oral instructions in text form without undue delay.
(6) Own security reviews of the processor. Without prejudice to its being bound by the controller's instructions, the controller acknowledges that the processor, on the basis of its own legal obligations (including Regulation (EU) 2022/2065, Digital Services Act) and its own legitimate interests (Art. 6(1)(f) GDPR, ensuring network and information security), uses automated systems including AI services and malware checks to review published content (landing pages including the controller's legal texts, notices and their targets as well as uploaded files before their publication) for unlawful content, phishing and malware; it checks files that guests upload for malware before making them available. E-mails and mailings are not reviewed. To prevent abuse, the processor throttles requests to public forms and uploads and in doing so logs IP addresses, which it deletes after 14 days. These reviews and logs are not part of the processing on behalf; the processor carries them out for its own purposes (Art. 6(1)(c) GDPR in conjunction with Regulation (EU) 2022/2065, Art. 6(1)(f) GDPR). They serve to secure its own service systems and are necessary for the secure operation of the platform. To this extent, the processor is a controller in its own right; the details are described in § 8 para. 3 of the Terms of Use and in the privacy policy.
(7) Guest files. The processor may block or remove an individual file uploaded by a guest under § 5 para. 4 and § 9 para. 1 letter a of the Terms of Use; the controller gives the instruction for this with this agreement. The processor informs the controller of the measure.
(8) Customer as processor of a third party. If the controller itself acts as a processor of a third party (e.g. an agency for its end customer), this agreement is deemed an agreement with another processor under Art. 28(4) GDPR. The controller warrants that it passes on the instructions of the third party and has obtained the third party's authorisation of the sub-processors under Annex 3; it passes on notifications under § 5 to the third party.
§ 3 Type of data and categories of data subjects
The subject matter of the processing is the types of personal data and categories of data subjects described exhaustively in Annex 1. The controller ensures that the data entered into the platform by it or by the data subjects is necessary for the purpose of the processing. If the controller collects special categories of personal data (Art. 9 GDPR), it marks the fields concerned as such on the platform and ensures, on its own responsibility, that the conditions of Art. 9 GDPR are met. Upload fields can carry the same marking; the controller may collect health data and other special categories via an upload field only with a marked field.
§ 4 Obligations of the processor
(1) Processing only on instructions. The processor processes personal data only within the scope of the processing on behalf and on the instructions of the controller in accordance with § 2.
(2) Confidentiality (Art. 28(3)(b), Art. 29, Art. 32(4) GDPR). For the processing, the processor only uses persons who have committed themselves to confidentiality and have been familiarised with the relevant data protection provisions. The confidentiality obligation continues after the end of their activity.
(3) Technical and organisational measures (Art. 32 GDPR). The processor takes the technical and organisational measures described in Annex 2 and maintains them during the term of the agreement. The measures are subject to technical progress; the processor may develop them further as long as the agreed level of protection is not undercut. It documents material changes and communicates them to the controller on request.
(4) Support with data subject rights (Art. 28(3)(e), Art. 12–23 GDPR). Within what is technically possible, the processor supports the controller by appropriate technical and organisational measures in fulfilling its obligation to respond to requests from data subjects (access, rectification, erasure, restriction, data portability, objection). If a data subject contacts the processor directly, the processor forwards the request to the controller without undue delay and does not answer it itself.
(4a) Blocks under the Order Terms. In the event of a block under the Order Terms (in particular because of a chargeback, § 8 para. 3 of the Order Terms), the data remains fully viewable, and access per guest and erasure remain possible; only collective exports and new data are blocked. The processor also provides an export for fulfilling data subject rights or at the request of the controller in text form during the block without undue delay, at the latest within 3 working days.
(5) Support with security, notification obligations and DPIA (Art. 28(3)(f), Art. 32–36 GDPR). Taking into account the nature of the processing and the information available to it, the processor supports the controller in complying with the obligations under Art. 32 to 36 GDPR (security of processing, notification of breaches, communication to data subjects, data protection impact assessment, prior consultation).
(6) Notification of personal data breaches (Art. 33 GDPR). The processor notifies the controller of every personal data breach that has come to its knowledge concerning data processed under this processing on behalf without undue delay, but no later than within 24 hours of becoming aware of it, in text form to the point of contact named in § 8. The notification contains at least the information required under Art. 33(3) GDPR, as far as available. The processor takes the necessary measures to secure the data and to mitigate possible adverse consequences without undue delay and coordinates with the controller.
(7) Data protection officer / contact person. The processor designates a point of contact responsible for data protection (§ 8). A data protection officer is not mandatorily appointed under Art. 37 GDPR.
(8) Evidence (Art. 28(3)(h) GDPR). The processor makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR.
(9) Rectification, restriction, erasure. The processor rectifies, erases or restricts the processing of the data processed on behalf only on the instructions of the controller. Insofar as a data subject contacts the processor directly in this respect, para. 4 applies.
(10) Place of processing / transfer to third countries. The processing takes place within the EU/the EEA; exceptions are listed in Annex 3. A transfer to a third country or to an international organisation takes place only if the conditions of Art. 44 et seq. GDPR are met (in particular an adequacy decision or appropriate safeguards such as EU standard contractual clauses) and the controller has consented. For the transfers named in Annex 3, consent is deemed given upon conclusion of this agreement.
§ 5 Sub-processing (Art. 28(2) and (4) GDPR)
(1) General authorisation. The controller grants the processor the general written authorisation to engage further processors (sub-processors). The sub-processors engaged at the time of conclusion of the agreement are determined exhaustively by Annex 3 and are hereby authorised.
(2) Changes. If the processor intends to engage an additional sub-processor or to replace an existing one, it informs the controller of this in advance in text form with a notice period of 30 days. It may deviate from this period if the change a) is exclusively advantageous to the controller, b) follows from mandatory law or an enforceable order of an authority or a court and the period cannot be observed for that reason, or c) is required immediately because of unforeseeable security risks. If a sub-processor drops out unforeseeably (for instance through insolvency, a personal data breach at the sub-processor or a complete failure of its service), the processor may replace it immediately with a sub-processor named as a reserve in Annex 3; it informs the controller without undue delay afterwards. The controller may object to the change in text form within 30 days of being informed for objectively justified reasons of data protection law. In the event of a justified objection, the controller may terminate the Main Contract as a whole for cause (special right of termination), at its choice with effect upon receipt of the termination or as of a later date named by it, at the latest as of the day before the change; if the sub-processor has already been replaced because it dropped out unforeseeably (sentence 3), the termination takes effect upon its receipt. The processor refunds the price pro rata in accordance with § 12 para. 3 of the Terms of Use. The processor publishes the current list of sub-processors with its history of changes at a fixed address on its website that is publicly accessible without signing in (for Einlasshelden on einlasshelden.de, for GateHeroes on gateheroes.events); a change under this paragraph is information and does not require acceptance of a new version of this agreement (§ 11 para. 5).
(3) Passing on the obligations (flow-down). The processor imposes on every sub-processor by contract data protection obligations that are essentially equivalent to those laid down in this agreement, in particular sufficient guarantees for appropriate technical and organisational measures (Art. 28(4) GDPR).
(4) Liability. If the sub-processor fails to fulfil its data protection obligations, the processor is liable to the controller for the performance of the sub-processor's obligations as for its own conduct.
(5) Not sub-processing are ancillary services that the processor uses purely as third-party services (e.g. telecommunications, pure maintenance), provided that the processor takes appropriate measures to ensure data protection.
§ 6 Audit rights of the controller (Art. 28(3)(h) GDPR)
(1) The processor enables the controller to verify compliance with the obligations laid down in this agreement and makes the information necessary for this available on request. It allows for and contributes to audits — including inspections — conducted by the controller or an auditor mandated by the controller.
(2) The evidence may be provided by: presenting the current documentation of the technical and organisational measures (Annex 2), presenting suitable certificates/attestations of the sub-processors (e.g. ISO 27001 of the data centre operator) and supplementary information.
(3) Evidence under paragraph 2 takes priority. On-site audits are to be carried out with 30 days' advance notice, during normal business hours, without disrupting operations and at most once a year (and at any time on a specific occasion in the event of a concrete suspicion). The confidentiality of other customers of the processor is to be preserved.
(4) Remuneration. If the controller carries out an on-site audit under paragraph 3, it remunerates the processor for the resulting effort at 120 euros per hour net plus statutory VAT. This cost obligation applies exclusively towards traders, legal entities under public law and special funds under public law. Towards consumers, the necessary cooperation in audits is free of charge. The cost obligation does not apply if the audit was prompted by an infringement of data protection law by the processor. The support under § 4 para. 4 and 5 and the provision of evidence are free of charge.
§ 7 Notification and support obligations in the event of supervisory measures
The processor informs the controller without undue delay of inspections and measures of the supervisory authority insofar as they relate to the processing on behalf. This also applies insofar as a competent authority investigates at the processor in the course of administrative offence or criminal proceedings relating to the processing of personal data.
§ 8 Points of contact
For the controller: the contact e-mail address from the master data of the customer account
For the processor: Sebastian Reinhardt, owner, datenschutz@einlasshelden.de
Instructions, notifications and communications under this agreement are made in text form to the above points of contact. Changes to the points of contact are to be communicated to the other party.
§ 9 Erasure and return after termination (Art. 28(3)(g) GDPR)
(1) After the end of the provision of the processing services, the processor, at the choice of the controller, erases all personal data or returns it and deletes existing copies, unless Union or member state law requires storage. The guests' records (consents, acceptances of legal texts) are part of the export under paragraph 3. On the instruction of the controller, which it gives with this agreement, the processor additionally retains them until the end of the third year after the year in which the agreement ended, exclusively for handing them over to the controller and blocked for any other processing; this agreement continues to apply to this data.
(2) The controller communicates the desired option (erasure or return) in text form no later than 30 days after the end of the agreement. Without such communication, the processor is entitled to erasure after this period has expired.
(3) The return takes place in a common, structured, machine-readable format. The export of the customer account, which the controller can retrieve itself within the period under paragraph 2, is the return under paragraph 1. The confirmation of the termination names both options, the day of erasure and the way to the export; seven days before the erasure, the processor sends a reminder of it. A block because of a chargeback does not restrict the return under paragraph 1.
(4) The erasure also covers the backups. On the server, the processor keeps each backup for 14 days, after that one backup per week for up to eight weeks, and then deletes them. The backup copies outside the server are encrypted; the processor renews the keys every six months and destroys a key as soon as the next but one is put into use. With the destruction of the key, the copies encrypted with it can no longer be read, at the latest 18 months after their creation. Until then, the backup copies are blocked, and the processing remains limited to mere storage for restoration.
(5) The processor demonstrates the erasure in a suitable manner on request (erasure log of the customer account).
§ 10 Liability
(1) Art. 82 GDPR applies to the liability of the parties. In the relationship between the parties, the liability provisions of the Main Contract (Terms of Use § 11) apply in addition, insofar as they do not contradict mandatory law.
(2) The controller and the processor are liable to data subjects in accordance with Art. 82 GDPR.
§ 11 Final provisions
(1) Order of precedence. In the event of contradictions between this agreement and provisions of the Main Contract, the provisions of this agreement take precedence in matters of data protection law. The annexes form part of this agreement; in the event of contradictions between the text of the agreement and the annexes, the text of the agreement takes precedence unless the annex expressly claims precedence.
(2) Written form/text form. Amendments and additions to this agreement and its annexes require text form. This also applies to the waiver of this text form requirement.
(3) Severability clause. Should individual provisions be or become invalid, the validity of the remaining provisions remains unaffected. The parties replace the invalid provision with a valid one that comes closest to the economic and data protection purpose.
(4) Applicable law. The law of the Federal Republic of Germany applies, taking into account the GDPR. If the controller is a merchant, a legal entity under public law or a special fund under public law, the place of jurisdiction is the place of business of the processor.
(5) Changes. The processor announces a new version of this agreement in text form at least 30 days before it takes effect. It may deviate from this period if the change a) is exclusively advantageous to the controller, b) follows from mandatory law or an enforceable order of an authority or a court and the period cannot be observed for that reason, or c) is required immediately because of unforeseeable security risks. The new version applies once the controller accepts it; until then, the previous version applies, and the platform remains usable for the controller; from the time the new version takes effect, the controller can only purchase new services once it has accepted it. What it has purchased, its events and admission continue unchanged. There is no acceptance by silence. If the controller does not accept, it may terminate the Main Contract at any time with immediate effect or as of the end of its active services (§ 12 para. 2 of the Terms of Use). The processor merely notifies new sub-processors and editorial changes without effect on rights and obligations; they do not require acceptance (§ 5 para. 2).
(6) Language. Towards customers who are not consumers, the German version of this agreement is authoritative. Towards consumers, the version in the language in which they accepted applies; the processor records the language at the time of acceptance. All language versions are identical in content.
(7) Entry into force. This agreement enters into force when the controller accepts it on the platform, at the earliest when the Main Contract takes effect.
Annex 1 — Subject matter of the processing, types of data, categories of data subjects
1. Subject matter and purpose
Management of events of the controller via the platform “Einlasshelden”: registration of guests, issuing and checking admission entitlements/tickets, admission control (also offline via devices running Gatekeeper, the platform's admission app), communication with guests by e-mail. The management of the contractual relationship with the controller (customer account, sign-in, invitations, billing) is not processing on behalf; it is described in the privacy policy.
2. Nature of the processing
Collection, recording, storage, organisation, retrieval, use, transmission (sending of e-mails to guests as well as operational/transactional e-mails), restriction, erasure. Automated processing in a database; semi-automated offline synchronisation on admission devices.
3. Categories of data subjects
– Event guests / participants (including persons who register themselves). – Users of the controller (employees/agents who operate the platform: organisers, admission staff). – Where applicable, other natural persons whose data the controller records in free-text/custom fields.
4. Types of personal data
a) Guest data
– Name (mandatory) – E-mail address (as delivery/“mailbox” attribute) – Values of freely definable custom fields (text, selection, number, date, telephone, file upload, etc.) — content determined by the controller – File uploads (files uploaded by the guest; content determined by the controller) – Admission/status data: pseudonymous admission codes, assignment to checkpoints/groups, block/retrieval/check status – Admission/scan log data: time, result (admission/repeat/invalid), checkpoint, operator carrying it out – Marketing consents and their records (status, origin, verbatim consent text, time) – Records of the acceptance of legal texts (verbatim text version, language, e-mail)
b) Data of the users of the controller, insofar as it is linked to guest data
– Operator in the admission/scan log and in the history of a guest file (identifier of the user or device)
c) Special categories of personal data (Art. 9 GDPR) — possible
Special categories can be collected via freely definable form fields (text/textarea) and freely worded legal texts; marking them is the responsibility of the controller (§ 3).
d) Content of the controller
– Content of landing pages, the media library and notices, insofar as it shows or names persons (images, videos, audio, texts); file uploads by guests also as video and audio
5. Duration of storage
For the duration of the Main Contract or until erasure by the controller in accordance with its instructions. The platform automatically deletes guest data 90 days after the end of the date of the event or its declared completion, never earlier than 90 days after the last activity; beforehand it warns the controller by e-mail, unless the controller has completed the event itself. Anyone who has to retain the data for longer exports it beforehand. This period is part of the service description; with the conclusion of the agreement, the controller instructs the erasure. Files uploaded by guests are deleted together with the guest; e-mails to guests in the dispatch store after 30 days, an account export after 7 days; files in the media storage after three years without an event, after two advance warnings. After the end of the agreement, the customer account remains readable with export for 30 days, after which the erasure follows; in the backups on the server, deleted data remains for up to eight weeks (each backup 14 days, after that one per week up to eight weeks), the encrypted backup copies outside the server become unreadable with the destruction of their key, at the latest 18 months after their creation (§ 9 para. 4). The processor retains the guests' records (consents, acceptances of legal texts) on the instruction of the controller for the controller's evidential purposes. It retains records of the controller's acceptance of this agreement for its own evidential purposes until the end of the third year after the year in which the agreement ended (Terms of Use § 13 para. 2).
Annex 2 — Technical and organisational measures (Art. 32 GDPR)
Division of responsibility: The physical and infrastructural security (data centre, servers, network, availability) is provided by the sub-processor Hetzner and evidenced by its certifications/data processing agreement. The processor provides the application-side measures (access control, separation of clients, logging, data minimisation) itself. Only both together constitute the level of protection under Art. 32 GDPR.
1. Confidentiality (Art. 32(1)(b) GDPR)
1.1 Physical access control — provided by Hetzner (data centres in Germany/EU): access security, video surveillance, access logging according to the certified standards of the data centre operator (evidence via Hetzner certificates, see Annex 3).
1.2 System access control — application system: – Password-based sign-in; passwords are stored only as a hash (scrypt with random salt), comparison in constant time. – Protection against rapid sign-in attempts: sign-in attempts are throttled per network and per address; the same check also runs for unknown addresses, so that the response time does not reveal whether an account exists. – Password policy: at least 12 characters, block list of common/weak patterns, context block (no parts of the e-mail address and no words from the name of the account). – Server-side session management with a random, opaque session ID and expiry (time-to-live 7 days); invalid/expired sessions are rejected fail-closed. When the password is changed, all existing sessions are ended. – Two-factor authentication (TOTP): optional for customers, mandatory for the internal operator access; the TOTP secret is stored AES-256-GCM-encrypted; recovery codes are hashed and can be used once; a one-time code that has already been used is not accepted a second time. – Enforced password change for administratively assigned passwords (every action is blocked until the change). – Session cookies carry HttpOnly, SameSite=Lax and, in production, the Secure flag; in production the administration interface sends the HSTS header (180 days, including subdomains). TLS/HTTPS is provided via the reverse proxy (Caddy).
1.3 Data access control (permissions) — application system: – Fixed role and permission model (including account administration, workspace management, read-only, guest management) with a central action→permission matrix; authorisation fail-closed (unknown action/role is refused). – In addition, special permissions that can be granted individually and are deactivated by default (e.g. mailing, ticket creation) according to the principle of least privilege. – Central access gate with origin check (CSRF protection), session check and block gate; form actions of the interface check the origin via the framework used.
1.4 Separation control (separation of clients) — application system: – Structural separation of clients: guest data is read and written exclusively through a central access layer whose operations are bound to exactly one account or workspace, or to an access key (the link of an admission device, of a guest mailbox or of a confirmation e-mail to a guest) that unlocks exactly one event or group. Registrations via a public registration page are bound to the event of that page. Exempt are individually named processes (retention deletion, completion of events, e-mail sending, checking and storage management of uploaded files, export and handover of the data, operator tools); an automated test rejects every access outside the access layer that does not belong to these processes. Foreign identifiers are rejected with a non-revealing “not found” (no information leak) (protection against unauthorised object access/IDOR). – Internal support/operator access is a separate permission space with its own sign-in store; a support context cannot assume a customer context “from within” (see no. 5).
2. Integrity (Art. 32(1)(b) GDPR)
2.1 Transfer control (transmission): – Transport encryption (TLS) for access to the platform (via reverse proxy, see 1.2). – Sending of e-mails to guests via the service provider named in Annex 3; the transmission to it is transport-encrypted (TLS). – Admission codes are pseudonymous, signed bearer tokens (Ed25519 signature, integrity/authenticity protection); they contain no plain-text personal data, only opaque identifiers.
2.2 Input control (logging) — application system: – Logs that the program only appends to (the application has no way of changing an entry; an additional technical lock in the database is not set up; records are deleted as planned after their retention period) for security- and evidence-relevant operations: actions of the internal operator (interventions in accounts, content and access with mandatory justification; payment and billing-document operations without discretion with an entry but without justification), openings of the support view, admission/scan operations and changes to events, consent events (with verbatim text version), acceptances of legal texts, acceptances of this agreement, of the Terms of Use and of the Order Terms, ticket, billing-document and account exports, the history of uploaded files and the erasure at the end of the agreement. – Operating logs of the servers (containing IP addresses, for instance for rejected sign-in attempts) are deleted after 14 days. – Sign-in log: for every person with access, successful and failed sign-ins, two-factor checks, sign-outs as well as changes and resets of the password and of the two-factor sign-in are logged with time, IP address and browser; these entries are visible only to the person themselves and to internal support during a support view. For every account, it is logged who opened it and when, and who reset a person's two-factor sign-in there as account administrator; these entries are visible to the account administrators of that account. Entries are deleted after 90 days.
2.3 Protection against malware (file uploads) — application system: – All uploaded files are checked with a virus scanner (ClamAV) that runs on the processor's own server; the files are not transmitted to any third party for this (hence no entry in Annex 3). – Files uploaded by the controller for notices are checked before they are stored. Files with a finding, files that cannot be checked completely, and uploads while the virus scanner is unavailable are rejected and not stored. – Files uploaded by guests and media for landing pages are uploaded directly to the object storage and checked in the background afterwards. Until the result of the check, the file is blocked: it cannot be retrieved and is not published. In the event of a finding or if the file cannot be checked completely, the processor deletes the file; the guest is notified by e-mail in the case of an upload from the registration form. If the virus scanner is unavailable, the file remains blocked until the check succeeds. – The virus signatures are updated automatically (several times a day).
3. Availability and resilience (Art. 32(1)(b) and (c) GDPR)
– Resilience in the application system: outbox with retry/backoff for sending e-mails; idempotent repetition of admission scans; offline-first operation of the admission devices. – Data backup and recoverability — server operation: The database and the uploaded files (local storage and object storage) are backed up automatically every day; each run checks the integrity of its backup. A daily check reports by e-mail if a run fails or no usable backup has been created. Retention on the server: each backup 14 days, after that one backup per week for up to eight weeks. The backups on the server itself are not encrypted and can be read only by the system administrator. A copy outside the server is kept at Hetzner (Storage Box, Helsinki, Finland); it is encrypted asymmetrically before transfer (age). The keys are renewed every six months; a key is destroyed as soon as the next but one is put into use, and the copies encrypted with it can no longer be read from then on (at the latest 18 months after their creation, § 9 para. 4). Excepted are the copies of the processor's accounting records, which are re-encrypted under each new key because of the statutory retention obligation. Restoration of the database is checked with a repeatable test run that restores a backup completely into a separate test database. Nothing is deleted on the Storage Box; the copies become unreadable because their key is destroyed.
4. Pseudonymisation and data minimisation (Art. 25, Art. 32(1)(a) GDPR)
– Pseudonymous admission codes (see 2.1); the link code↔person exists only on the server side. – Data minimisation by design: conditionally visible form fields discard invisible input on the server side; master data is “nullable at rest” (mandatory only at the processing gate); data minimisation on admission devices with retention TTL and best-effort remote wipe. The guest list on an admission device is kept in the browser's storage and is protected there only by the device itself, not additionally encrypted. – Masking of special categories: field values marked as “special category” are displayed masked in the internal support view. – Data at rest and backups: the database and the file storage are stored unencrypted on servers of Hetzner Online GmbH in Germany (servers in Falkenstein, file storage in Nuremberg) with the physical access control of the data centre. Backups are encrypted asymmetrically (age) before they leave the server and are stored as a copy at Hetzner in Finland (no. 3); they are not deleted there but become unreadable because their key is destroyed at the latest 18 months after their creation (except the accounting records, no. 3). Beyond this, only the access credentials of the object storage and the secrets of the two-factor sign-in are stored encrypted (AES-256-GCM); signing keys of the events, access tokens of the admission devices and contents of e-mails in the dispatch queue are stored unencrypted in the database.
5. Internal support access (break-glass)
– The support view into customer data is read-only and only possible after express activation (grant) with mandatory justification and expiry time (60 minutes); no standing access. – Interventions by the operator (for instance blocking an account, resetting the two-factor sign-in, removing content) are separate functions, each with a log and, where discretion is involved, with mandatory justification. – Every opening is logged; special categories are masked; sign-in data (password hash, TOTP secret) is never loaded in the process. – The customer can view the history of support views in its account (time and justification, without the name of the employee).
6. Procedure for regular testing, assessment and evaluation (Art. 32(1)(d) GDPR)
– Separate permission spaces, principle of least privilege, fail-closed stance as a design principle. – Changes to security-relevant measures are documented.
Annex 3 — Authorised sub-processors
With the conclusion of this agreement, the controller authorises the sub-processors named in the processor's public list under § 5 para. 2 in the version in force at the time the agreement is concluded (§ 5). Each version of the list bears the date from which it applies; the history of changes remains available there. When this version of the agreement was drawn up, the list named the following sub-processors:
1. Hetzner Online GmbH, Gunzenhausen (DE) Service / data processed: hosting/server operation (cloud VPS, object storage, backup storage). Processes all personal data stored in the database/file storage. Place of processing: Germany (servers, file storage); Finland (encrypted backups); both EU. Basis: Hetzner data processing agreement (server location EU: processing only in the EU; Hetzner Finland Oy as sub-processor there)
2. Mailjet (Mailjet SAS, part of the Sinch AB group, France) Service / data processed: sending of guest e-mails (invitations/confirmations). Receives: recipient e-mail, subject, full message text (may contain names). Place of processing: EU; transfer to the USA possible (sub-processors of the Sinch group), based on EU standard contractual clauses (Art. 46(2)(c) GDPR) and the EU-US Data Privacy Framework (adequacy decision, Art. 45 GDPR). Basis: Sinch data processing agreement.
2a. Reserve (only if row 2 fails): Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg (Amazon Simple Email Service) Service / data processed: sending of guest e-mails (as row 2), only if Mailjet drops out unforeseeably (§ 5 para. 2 sentence 3). Place of processing: processing in the EU (Frankfurt region, eu-central-1); access from the USA possible, safeguarded by the EU-US Data Privacy Framework and standard contractual clauses (as row 2)
The processor concludes a data processing agreement pursuant to Art. 28(4) GDPR with each sub-processor and, upon justified request, makes copies of these agreements available to the controller (where applicable with commercial details redacted).