Data Processing Agreement

At a glance

Hosting & data location

App databases, hosting and error monitoring: Germany. Cloudflare KV (Parent App): EU. Technical e-mail (Brevo): hosting in France/Germany (OVH), storage in Belgium (Google Cloud). E-mail mailbox: Netherlands. Core data exclusively in the EU. Exceptions with a non-EU connection: Apple/Android push, wallet cards, the optional AI image generation (global endpoint, see Annex C) and the public websites of the Kitas (Cloudflare Pages, worldwide delivery).

Encryption

TLS 1.2/1.3 for every transmission. HTTPS only. No unencrypted interfaces.

Separation & pseudonymity

The data of each Kita (day-care centre) is technically separated from that of all other Kitas. Access is limited to authorised users of the own Kita. The Parent App works without user accounts: parents use only a pseudonymous child code. On request, the entire software runs with codes instead of real names; the AI functions can be limited to identifiers or switched off, and the Träger (operator) can set an upper limit for this (Annex C). Technical details: §5.

Changes to the contract

The contracting party is the Träger (operator) as soon as the Kita is assigned to a Träger account; the contractual confirmation then takes place only there (desktop, not the check-in terminal). Assigned Kitas can take note of the documents once, later they only see a notice. Without a Träger assignment, the Kita confirms itself. Material changes: e-mail on the day of deployment, a reminder after two weeks, display in the dashboard; the new processing remains technically blocked until confirmed. The software remains usable in the meantime. Clarifications of the description and TOMs without new data points on the same infrastructure: immediately. New sub-processors: technically blocked until confirmed (§5, §9, §12).

between

[Customer / Träger / Kita] ("Controller")

and

997 Ventures UG (haftungsbeschränkt)
Sonnenhof 13, 67677 Enkenbach-Alsenborn
(hereinafter: "Processor")

§1 Subject matter and duration of the processing

(1) The Processor processes personal data on behalf of the Controller within the scope of providing the Kita management software app.bienenstock-kita.de.

(2) The processing begins upon conclusion of the software usage agreement and applies for the duration of the Controller's use of the software. The software usage agreement is concluded by the contracting person ticking the checkbox confirming the legal documents (terms and conditions, this DPA, privacy notices) (details in §12). The software usage agreement expressly also covers the free package.

§2 Nature and purpose of the processing

The processing comprises the following specific operations:

• Real-time check-in and check-out of children via QR code and of staff via identifier/pseudonym
• Automatic capacity calculation based on the recorded attendance data (database triggers)
• Real-time synchronisation of the attendance data via WebSocket connection (Supabase Realtime)
• Management of master data, group assignments and care models
• Receipt and processing of absence notices, meal cancellations and pick-up notices via the Parent API
• Receipt and processing of reports from staff via the Staff App (working hours, home-office check-in, absence and sick notices, team communication; Annex 2B)
• Provision of an internal staff chat (accessible via the Staff App, also on private devices; Annex 2B) with automatic deletion after the period in §3
• AI-supported functions under Annex C: individually switchable; what the AI learns about persons is governed by the AI data protection level, which the Träger (operator) may cap at an upper limit
• Publication of the facility's website, created with the website builder, at kitas.bienenstock-kita.de via Cloudflare Pages (worldwide delivery network, as it is publicly accessible). The content and images, including photos uploaded by the Kita, are determined solely by the Controller; for the publication of photos of persons, in particular of children, the Controller obtains the required consents
• Sending of push notifications to legal guardians (Parent App) and to staff (Staff App) via Expo and the Cloudflare push worker; details in Annex 2A §2 and Annex 2B §2
• Sending of documents to legal guardians by e-mail (address stored on the child record), including a dispatch log (which document was sent when and to which address)
• Optional meal billing per child: creation of a receipt for a period and sending by e-mail to the address of the legal guardians stored on the child record, triggerable in the Träger account and in the Kita administration; storage of billing characteristics and of the dispatch log
• Optional parent payments (to be enabled by the Controller): payment occasions and payment items per child with a payment reference code, display of the amount, recipient account and GiroCode in the Parent App, recording of cash payments with the initials of the accepting person (visible on the receipt for the legal guardians), confirmation "transferred" by the legal guardians, notification "payment received" by push, insofar as the Parent App is used and push is permitted on the device; optional membership fees with payment profiles per family and an optional invoice recipient
• Bank connection (optional): retrieval of account transactions of the Kita's account at the bank chosen by the Controller (e.g. Qonto; future banks likewise), read-only and by means of access authorisation granted by the Controller (OAuth), for the matching of incoming parent payments; alternatively, import of an account statement (CAMT.053). The bank is a contractual partner of the Controller and not a sub-processor. For each transaction, the name, IBAN, payment reference, amount and booking date are retrieved. Only the amount, booking date, payment reference and the bank's transaction identifier are stored, and only for matched or plausibly matchable incoming payments and for outgoing payments that the Controller assigns to an occasion; name and IBAN are never stored. Outgoing payments of the last 60 days are only shown for selection (name and shortened IBAN of the recipient), not stored. All other transactions are discarded. Access data for the bank is stored encrypted and deleted when the connection is disconnected.
• Obtaining of consents and authorisations from the legal guardians by means of a confirmed e-mail to the address stored by the Kita (releases, pick-up authorisation, recording of a parent meeting) via a public confirmation page; storage of the confirmed text and of the time as evidence
• Management of releases per child (for example photos, sun cream) with evidence of every grant and every withdrawal; display in the Parent App without the possibility of change
• Optional photo of the child for recognition by staff, only with an active release "photo of the child on the Kita's devices"; without AI; deletion upon withdrawal
• Management of authorised pick-up persons per child, notification of the person collecting the child for one day via the Parent App, pick-up authorisation for new persons by means of a confirmed e-mail, marking of newly registered persons until identity verification, and proof of handover in the group view (Annex 5 §3)
• Parent meeting requests between legal guardians and the facility with proposed dates, confirmation e-mails and reminders; staff appointments for the participants
• Recording of a parent meeting only with a previously stored consent; evaluation in accordance with Annex C
• Calendar with appointments for the facility, groups or care models, acceptances and declines per child, optional costs per child and optional publication of date and title on the facility's website
• Reservation of rooms of the facility
• Sending of a child's QR letter by e-mail to the stored parent address, including the parent password of the facility depending on the setting of the Controller
• Messages from the facility to its Träger and replies from the Träger; optional e-mail copy to a distribution list set by the facility; forwarding of individual messages by the Träger by e-mail to recipients chosen by it, with a log
• Optional application portal of a Träger for Kita places: applications by the legal guardians with confirmation of the e-mail address, processing exclusively by the Träger, automatic deletion after the periods named in §8
• Sending and receipt of technical e-mails via Brevo (Sendinblue) in software functions (e.g. invitations, system messages); e-mail mailbox with Zoho (Netherlands)
• Technical error monitoring via Sentry (EU region Frankfurt), including session replay of the web application (masked; details §5 No. 9); additionally, application-specific error logs in the Kita database, which may contain a person ID in the context
• Preparation of evaluations and reports including Excel export
• Preparation of staff time evaluations for the facility management and the Träger (per facility and across the Träger) including export, and inspection by employees of their own times
• Provision of Träger accounts: inspection of the data of the Kitas assigned to the Träger; invitation of further users to the Träger account, who, after accepting the invitation, receive inspection and editing rights for these Kita data
• Sending of group messages within the software
• Optional supplier access: the catering supplier named by the Controller can view meal notes (including allergy and dietary information); the supplier is a recipient on the instructions of the Controller, not a sub-processor of the Processor
• Polls in the Parent App: storage of the vote with a device ID, so that only one vote per device is counted
• Storage of discarded check-in actions which, after deletion of the data subject concerned, are deliberately retained (documented retention)

Purposes of the processing:

• Organisation and documentation of Kita operations by means of the software
• Real-time recording and legal documentation of capacity to fulfil statutory obligations (under the national law of the Controller's Member State)
• Communication with legal guardians via the app, push notifications and sending of documents by e-mail
• Notices to staff via the Staff App (chat, traffic light, working hours), insofar as push is activated
• Staff planning, working time recording and staff time reporting (per facility and across the Träger)
• Catering management including optional information to the catering supplier named by the Controller, as well as optional meal billing with receipt dispatch to legal guardians
• Handling of parent payments and membership fees, including the matching of incoming payments
• Obtaining and documentation of consents, authorisations and their withdrawal (Annex 5)
• Support of the facility in documenting pick-up authorisations and handovers (Annex 5); the decision on the handover is taken by the facility
• Organisation of appointments, parent meetings and rooms
• Communication between the facility and the Träger
• Allocation of care places by the Träger (application portal)
• AI support: purposes under Annex C §2 (in accordance with the level and the switches)
• Technical troubleshooting and quality assurance
• Opinion survey of legal guardians via polls (one vote per device)

§3 Type of data and data subjects

Types of data processed, differentiated by groups of data subjects:

Principle of data minimisation - mandatory and optional fields (Art. 5(1)(c) GDPR)

The child's real name is not mandatory; if it is left empty, "Kein Name" (no name) is displayed. Operation with a code or nickname is provided for. The mandatory details in the tables are required for check-in, capacity and the care contract. Optional details are only processed if the Controller records them or activates the associated function (Art. 5(1)(c) GDPR).

Children

Statistical fields and special categories under Art. 9 GDPR are in the Optional column and are only collected insofar as the facility records them (official statistics under the national law of the Controller's Member State, or operationally allergies/meal notes). Art. 9 data is processed separately and with an increased level of protection. The Controller ensures the legal basis under Art. 9(2) GDPR. If supplier access is activated, allergies and meal notes go to the catering supplier named by the Controller (recipient on instructions, not a sub-processor).

Staff

Statistical fields for staff are in the Optional column and are only collected insofar as required for an official statistic. Chat and notice board: see Messages below.

Reasons for staff absence. Absences (including those from sick notices, leaving early at the terminal and the weekly question) are stored with a reason from a fixed catalogue and an optional note: illness, child ill, doctor's appointment, prohibition of employment, maternity protection, parental leave, care leave, termination, longer-term absence, strike, holiday, special leave, unpaid leave, further training, compensation for overtime, release, regeneration/conversion day, part-time (free day), official errand, business trip, as well as free text; for individual shifts additionally "unentschuldigt" (unexcused) and "entfallen" (cancelled). Illness, child ill, doctor's appointment, prohibition of employment and maternity protection are health data; strike may indicate trade union membership (Art. 9 GDPR); care leave and termination are especially worthy of protection.

Who sees the reasons. The person concerned sees their own reasons in the Staff App and when checking out at the terminal. Reasons of other persons appear only in the facility administration (staff planning with the admin password; notices and reports with the staff password), in the Träger area, and in reports, exports and printouts (daily report, shift plan, weekly poster). Check-in and group tablets and the Staff App show absences of other persons without reason. The Controller decides who has access to these areas and printouts.

Parents/legal guardians (via Parent App and API):

• Pseudonymised child ID (child code)
• Absence notices (child, date; without reason), meal cancellations, pick-up notices including the person collecting the child, date and time
• E-mail addresses and telephone number of the legal guardians on the child record (Träger address for documents and meal billing receipts; address and telephone number of the facility for the QR letter, consents and meeting confirmations), as well as the dispatch log
• Language of the legal guardians for each child (stored by the facility or selected in the Parent App) for translations under Annex C §3 No. 17
• Consents by means of a confirmed e-mail: confirmed text, time, origin; recipient address and check value of the link in the request only until confirmation; the link is valid for one hour, after which both are deleted within a further hour (§8(8)); for release and recording requests additionally an entry in the dispatch log (child, address, type, time, triggering account)
• Meeting requests (topic, recipient, selected date), acceptances and declines of appointments, participation confirmations and notices "transferred" for payment items
• With an active bank connection: payment reference, amount and booking date of matched incoming payments and of outgoing payments assigned by the Controller; name and IBAN of the payer or recipient only on retrieval, not stored (§2)
• For the recording of a parent meeting: name and role of the consenting person, image of the signature or confirmed e-mail, text of the consent
• Poll votes with device ID (one vote per device)
• Push reception in the Parent App, insofar as permitted on the device and used by the facility: group messages, traffic light status changes, appointment reminders, meeting appointments, new diary entries and payment receipts; details in Annex 2A §2

Staff (additionally via Staff App; Annex 2B):

• Time reports, check-in/check-out reports, sick notices
• Chat messages of the internal staff chat (content, timestamp, sender name or code)
• Push reception in the Staff App (only with consent on the device and only for switched-on functions): traffic light status changes, team chat, calls, automatic notices on working time and appointment reminders; details in Annex 2A §2 and Annex 2B §2

User accounts (all roles):

• E-mail address, authentication data (Supabase Auth JWT), role flags
• DPA/terms confirmation: name, e-mail and role of the confirming person, timestamp, version number of the respective document including annexes, previously confirmed version; contract confirmation in the Träger account or, without Träger assignment, in the Kita admin. Additionally a one-time acknowledgement by the Kita management of an assigned facility (no second contracting party, §12)
• Träger account: assignment to facilities; invitations of further users (inviting person, invited person, timestamp, status). After acceptance of the invitation, these users receive inspection and editing rights for the data of the Kitas assigned to the Träger
• Exchange between facility and Träger: messages, replies, processing status; e-mail distribution list of the facility (at most ten addresses); log of each forwarding by the Träger (recipient, note), visible only to the Träger

Log data (logs):

• Every check-in/check-out with timestamp, person type, calculated capacity; for children additionally the care factor; for staff additionally the work location indicator (home office, outing, off-site)
• Discarded check-in actions (discarded_actions): deliberately retained after deletion of the person concerned (documented retention for traceability of terminal actions). Deletion or return together with the rest of the contract stock in accordance with §8
• Application-specific error logs (error_logs), insofar as a person ID is contained in the error context; storage on German servers, separate from error monitoring via Sentry (Annex 1, including session replay)
• Dispatch log to legal guardians (parent_mail_log): which document, which meal billing receipt or which message was sent to a family, when and to which address
• Replies of the legal guardians to messages to a family: selected action and time (Annex 4 §5(7))
• Time corrections: reason (category and mandatory free text), correcting person with e-mail address, as well as values before and after the correction; the daily overview to the Träger contains only pseudonyms or codes and the basic category, no names and no free text
• Protection against password guessing: for each failed attempt, an encrypted check value (HMAC) of the network and of the wrong value, never the address or the value itself; automatic deletion after one hour
• Evidence of consents of the legal guardians (type, text, time, origin)

Messages:

• Group messages (content, timestamp, group assignment)
• Internal staff chat: content, timestamp, sender (name or code); automatic deletion after a period of one to seven days chosen by the Controller (default: one day, deletion at midnight in the time zone of the facility); notice board messages remain stored permanently until removed manually or the contractual relationship ends; according to the usage rules not intended for sensitive data or special categories of personal data (Art. 9 GDPR)

Group reports, daily reports and notices:

• Group reports (daily report of a group), notes on individual children (child diary) and notices as free text, typed or dictated; storage on German servers. Legal guardians see an entry only if the Controller switches on the display in the Parent App (default: off) and the staff expressly releases the entry; they then receive a push notification without content. Dictation can be switched off (default: on). Free texts may contain special categories under Art. 9 GDPR (Annex 4).

Kita metadata (optional, insofar as configured):

• Thresholds (buffer, yellow/red traffic light), deadlines for meal cancellations, opening hours, closing days, facility slug, page locks of the facility (admin, staff, parent and supplier password: shared passwords which lock individual areas of the software, not personal access data; stored in plain text so that the facility can view and pass them on, checked by a constant-time comparison and throttled against trial and error), Träger specifications (management allowance, practical supervision), mandatory break configuration, supplier password (opt-in)

Other data subjects (insofar as the respective function is used):

• Authorised pick-up persons: name, relationship to the child, origin of the information (facility or legal guardians), authorisation text and time of confirmation, time of identity check (no ID number)
• Applicants for a care place (application portal of the Träger): first name and date of birth of the child, name, e-mail address and optionally telephone number of the legal guardians, desired facilities and ranking, scope of care, desired start, processing status, internal note of the Träger
• Invoice recipients of membership fees: name, address, e-mail address
• Payers of transfers to the facility and recipients of transfers of the facility (only with an active bank connection): name and IBAN only on retrieval; only the payment reference, amount and booking date of matched incoming payments and of outgoing payments assigned by the Controller are stored
• Participants in recorded parent meetings: name, role, time and form of the consent (signature or e-mail confirmation), as well as what was said in the meeting (Annex C §3 No. 11)
• Recipients of e-mail copies and forwarding in the exchange between facility and Träger: e-mail address

AI functions (in accordance with the default settings and switches; details in Annex C):

The AI functions can be switched on and off individually; with a function switched off, the associated data categories also cease. The Träger can lock functions and cap the AI data protection level at an upper limit. Depending on the setting, the following data is processed:

• Free-text entries of the users, as written (the interface asks not to enter health data; details on free-text fields in Annex 4)
• Organisational designations: name of the facility, names of groups and care models
• Key figures (traffic light, capacity, attendance by category, planned/actual, thresholds, opening hours)
• Records per person (attendance, events, shift and break plans, contractual hours, hours accounts, days of absence), depending on the AI data protection level with identifiers, with the names of the staff, or with the names of staff and children; reasons for absence only as a count
• Voice recordings (dictation, e-mail assistant, parent meeting) exclusively for processing; audio is never stored permanently
• Results of parent meetings (report, tasks, version for the parents) and of the e-mail assistant (sample e-mails, instruction, draft)
• Consents to meeting recordings (name, role, time, text version, signature or e-mail confirmation)
• Photos for the floor plan, handbook draft and hazard topics, as well as the management's own style images for the website (image understanding on the EU endpoint); only an image description without personal reference is sent to the image generation
• Website information of the management (texts, contact, legal notice)
• Stored results under Annex C (daily course, confirmed actions, change packages of the shift-planning AI, daily analyses, monthly reports)
• Account-related storage of the AI consent (timestamp and text version)

§4 Obligations of the Processor

The Processor undertakes to comply with the following obligations pursuant to Art. 28(3) GDPR:

(1) Processing only on instructions (Art. 28(3)(a) GDPR)

The Processor processes personal data exclusively on documented instructions from the Controller - including with regard to transfers of personal data to a third country or an international organisation - unless it is required to do so by Union or Member State law to which the Processor is subject. In such a case, the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. The Processor informs the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or other data protection provisions of the Union or of the Member States.

(2) Confidentiality (Art. 28(3)(b) GDPR)

The Processor ensures that the persons authorised to process the personal data have committed themselves to confidentiality or are subject to an appropriate statutory duty of confidentiality. The confidentiality obligation continues after the end of the engagement.

(3) Technical and organisational measures (Art. 28(3)(c) in conjunction with Art. 32 GDPR)

The Processor takes all measures required under Art. 32 GDPR. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing as well as the varying likelihood and severity of the risk to the rights and freedoms of natural persons, the Processor ensures a level of protection appropriate to the risk. The specific measures are described in §5 of this Agreement.

(4) Sub-processors (Art. 28(3)(d) in conjunction with Art. 28 paras. 2 and 4 GDPR)

The Processor does not engage any further processor without the prior written authorisation of the Controller. The sub-processors named in Annex 1 and Annex 2A are deemed authorised upon conclusion of the Agreement; any further engagement or replacement remains technically blocked until confirmed (§9).

(5) Assistance with data subject rights (Art. 28(3)(e) GDPR)

The Processor assists the Controller, insofar as possible, by appropriate technical and organisational measures in fulfilling the Controller's obligation to respond to requests for exercising the rights of data subjects laid down in Arts. 15 to 22 GDPR. These include in particular the right of access (Art. 15), the right to rectification (Art. 16), the right to erasure (Art. 17), the right to restriction of processing (Art. 18), the notification obligation (Art. 19), the right to data portability (Art. 20), the right to object (Art. 21) and the right not to be subject to automated individual decision-making (Art. 22).

(6) Assistance with security obligations (Art. 28(3)(f) GDPR)

Taking into account the nature of the processing and the information available to it, the Processor assists the Controller in complying with the obligations under Arts. 32 to 36 GDPR. This includes in particular assistance with:

• the security of processing (Art. 32 GDPR)
• the notification of personal data breaches to the supervisory authority (Art. 33 GDPR)
• the communication of a personal data breach to the data subjects (Art. 34 GDPR)
• the data protection impact assessment (Art. 35 GDPR)
• the prior consultation of the supervisory authority (Art. 36 GDPR)

(7) Notification of personal data breaches (Art. 33(2) GDPR)

The Processor notifies the Controller of a personal data breach without undue delay, and in any event within 24 hours of becoming aware of it, so that the Controller can meet its notification obligation under Art. 33(1) GDPR (72-hour deadline towards the supervisory authority). The notification contains at least:

• a description of the nature of the breach
• where possible, the categories and the approximate number of data subjects and data records concerned
• a description of the likely consequences
• a description of the measures taken or proposed

(8) Erasure and return (Art. 28(3)(g) GDPR)

After the provision of the processing services has ended, the Processor deletes all personal data or returns it, at the choice of the Controller, and deletes existing copies, unless Union or Member State law requires storage of the personal data. The details are governed by §8 of this Agreement.

(9) Demonstration of compliance (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 and allows for and contributes to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller. The details are governed by §7 of this Agreement.

(10) Record of processing activities (Art. 30(2) GDPR)

The Processor maintains a record of all categories of processing activities carried out on behalf of the Controller, which contains the information referred to in Art. 30(2) points (a) to (d) GDPR.

§5 Technical and organisational measures

The Processor has implemented the following measures pursuant to Art. 32(1) points (a) to (d) GDPR. Pursuant to Art. 32(1) GDPR, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing as well as the varying likelihood and severity of the risk to the rights and freedoms of natural persons, appropriate technical and organisational measures must be implemented to ensure a level of security appropriate to the risk. The measures include in particular:

• the pseudonymisation and encryption of personal data (Art. 32(1)(a) GDPR)
• the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services (Art. 32(1)(b) GDPR)
• the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident (Art. 32(1)(c) GDPR)
• a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing (Art. 32(1)(d) GDPR)

In assessing the appropriate level of security, account shall be taken in particular of the risks that are presented by processing, in particular from destruction, loss, alteration or unauthorised disclosure of, or unauthorised access to, personal data (Art. 32(2) GDPR).

The measures are oriented towards the following protection objectives:

1. Admission control
2. Data media control
3. Storage control
4. User control
5. Access control
6. Transmission control
7. Input control
8. Transport control
9. Recoverability
10. Reliability
11. Data integrity
12. Order control
13. Availability control
14. Separability

The following presentation describes the concrete implementation of these protection objectives. The measures are reviewed regularly and adapted to the state of the art (Art. 32(1)(d) GDPR).

Changes to the TOMs are distinguished as follows:

• Effective immediately, without a new checkbox: exclusively adjustments that do not collect new personal data and run on the same infrastructure already named in Annex 1 or Annex 2A (such as patches, hardening, configuration, replacement of measures of the same kind). The Processor documents these changes. No separate consent or prior information is required for these.
• Not effective immediately (material change): any TOM change that collects new personal data, introduces a new function with data collection or uses infrastructure other than that already authorised. For these, the procedure under §12(3) applies (notice, e-mail, technical block until confirmed).

1. Entry control (logical)

Supabase Auth with JWT and automatic token refresh; Row-Level Security (RLS) on all database tables; Column-Level Security on the Kita table.

2. Admission control

Client side: separate passwords for each role (admin, staff, parents, supplier); admin password with an additional, short-lived server token for sensitive actions; personal password for each person in the Staff App; API key authentication for the Parent API; server-side limitation of failed attempts per network and per facility; second factor at login (one-time code by e-mail) for Träger and facility accounts.

Operator side: access to production systems, databases and infrastructure is limited to authorised personnel and secured by individual authentication.

3. Access control

Client side: RLS policies at database level; role-based authorisation concept with the levels Träger manager, Kita admin and staff. Kita admin and staff access exclusively the data of their own facility. A Träger account sees the data of the Kitas assigned to the Träger; users invited from the Träger account likewise receive inspection and editing rights for this Kita data upon acceptance of the invitation. There is no inspection of data of other Träger.

Operator side: access to personal data exclusively according to the need-to-know principle, limited to maintenance, support and troubleshooting.

4. Transfer control

TLS 1.2/1.3 for all data transmissions; HTTPS-only configuration (Vercel); no unencrypted interfaces.

5. Input control

Client-side validation (Formik + Yup); server-side validation; logging of all check-in/check-out operations with timestamp.

6. Availability control

Supabase managed database (Frankfurt) with automated backups and point-in-time recovery; Vercel edge network with failure resilience; reconnection logic with exponential backoff (2 s → 30 s), followed by retries at 60-second intervals.

7. Separation control

Database level: tenant separation via Row-Level Security (RLS) on all tables - each policy checks the membership to the respective facility (kita_id). Column-Level Security (CLS) on sensitive columns (e.g. passwords). Blanket denial as baseline (REVOKE ALL for unauthenticated access). Storage buckets are likewise protected by RLS.

Application level: the frontend uses exclusively restricted API keys (no service-role key); the service-role key only server-side in API routes. Realtime subscriptions are filtered by RLS. Facilities can view exclusively their own data. Träger accounts (including invited users) see and edit the data of the Kitas assigned to the Träger; there is no inspection across Träger.

8. Pseudonymisation

Optionally configurable: codes instead of real names in the display; pseudonymised child IDs (child codes) in the Parent App.

9. Error monitoring

Technical error events are transmitted to Sentry (Functional Software, Inc.) in the EU region Frankfurt (FRA). Stack traces and technical metadata without chat, prompt or audio payloads; for dictation errors at most byte size and MIME type. Session replay records screen sequences of the web application to reproduce errors, including on the check-in tablets and the public pages for legal guardians; texts and inputs are masked, images and media are not recorded; insofar as the masking does not apply in an individual case, visible names may be contained.

10. Offline operation of the check-in tablets

So that check-in continues in the event of a network outage, the tablet stores a working copy in the local browser storage (IndexedDB): children (name, code or PIN, group, type of care, care factor, meal characteristic), staff (name, code or PIN, group, staff type) as well as the status reports of the current day; bookings not yet transmitted are cached until synchronisation. The copy exists only on the respective device and is deleted upon sign-out or change of account. The Controller secures the devices by device lock and device encryption.

11. Consents and evidence

A consent with origin "parents" arises only via a link to the address stored by the facility; the facility may additionally enter releases itself (origin "facility", Annex 5 §2(3)). The link contains a one-time token, which is stored only as a check value, is valid for one hour and is removed from error logs. Viewing and confirming are separated, so that an automatic retrieval of the link does not trigger a consent. The confirmed wording is stored; a changed release invalidates open links. Consents given cannot be changed retrospectively; a consent given by parents can only be written by the server. Signatures are held in private storage without access from the browser.

12. Bank connection

Read-only access to the account of the facility; access tokens encrypted with AES-256-GCM, readable only server-side and deleted upon disconnection; only information on matched incoming payments and outgoing payments assigned by the Controller is stored, never the name or IBAN of payers or recipients.

As of: October 2026. Immediately effective TOM adjustments are documented and made available to the Controller upon request. All other TOM changes follow §12(3).

§6 Rights and obligations of the Controller

(1) The Controller is, pursuant to Art. 4 No. 7 GDPR, the natural or legal person which, alone or jointly with others, determines the purposes and means of the processing of personal data. It remains responsible for the lawfulness of the processing (Art. 24(1) GDPR).

(2) The Controller ensures that the processing complies with the principles of Art. 5(1) GDPR, in particular:

• lawfulness, fairness and transparency (Art. 5(1)(a) GDPR)
• purpose limitation (Art. 5(1)(b) GDPR)
• data minimisation (Art. 5(1)(c) GDPR)
• accuracy (Art. 5(1)(d) GDPR)
• storage limitation (Art. 5(1)(e) GDPR)
• integrity and confidentiality (Art. 5(1)(f) GDPR)

(3) The Controller is in particular responsible for:

• fulfilling the information obligations when personal data is collected from the data subject (Art. 13 GDPR) and where it is obtained from a third party (Art. 14 GDPR)
• obtaining consents where required, observing the requirements of Art. 7 GDPR
• maintaining a record of processing activities pursuant to Art. 30(1) GDPR
• carrying out a data protection impact assessment pursuant to Art. 35 GDPR, insofar as the processing is likely to result in a high risk to the rights and freedoms of natural persons
• ensuring a legal basis pursuant to Art. 6(1) GDPR for each processing (statutory authority and/or consent)
• inviting further users to the Träger account and the associated granting of inspection and editing rights to the data of assigned Kitas; the Controller ensures that only persons authorised for this purpose are invited
• instructing its users on the content of free-text fields and reviewing texts before their release to legal guardians or their publication (Annex 4 §3)
• the obligations under Annex 5 §6 in respect of releases, consents by e-mail, authorised pick-up persons and handovers, in particular the verification of the identity of persons collecting children, of custody rights and of the accuracy of the e-mail addresses stored

(4) The Controller has the right to issue instructions to the Processor concerning the type, scope and procedure of the data processing. Instructions shall be given in writing or in an electronic format. Oral instructions shall be confirmed in writing without undue delay.

(5) The Controller shall inform the Processor without undue delay if it identifies errors or irregularities when reviewing the results of the processing.

(6) Not applicable outside Germany.

(7) Not applicable outside Germany.

(8) Access. Träger accounts and the account of the facility are login accounts with e-mail address and password. In the Träger area, each account may invite further personal accounts; all accounts have the same rights (inspection and editing of all assigned facilities). Graded roles do not currently exist; the Processor removes an account upon request. The management shares the account of the facility; individual areas are additionally protected by the page locks (§3). The Controller

• a) sets up in the Träger area a separate, invited account for each person, rather than sharing one access;
• b) keeps the circle of persons who know a shared password small (account of the facility, page locks);
• c) changes shared passwords regularly and immediately when a person leaves or a device is lost: the login password via "Forgot password" on the login page, the page locks in the settings;
• d) reports persons who have left and have their own Träger account for removal.

With shared access, it cannot be traced which person acted; this also affects the evidence of the contract confirmation under §12, which records the name and account of the confirming person.

§7 Control and evidence

(1) The Controller has the right to verify compliance with this Agreement and with the data protection requirements (Art. 28(3)(h) GDPR). The verification may be carried out by:

• obtaining information and evidence
• written answering of a questionnaire by the Processor
• remote audits after prior agreement; on-site inspections are made possible insofar as this is appropriate given the purely cloud-based infrastructure

(2) On request, the Processor provides the Controller with current evidence of compliance with the technical and organisational measures. This includes in particular the certifications and audit reports of the sub-processors used.

(3) Effort that goes beyond one audit per calendar year and beyond the support owed by law is remunerated on a time basis at customary market rates.

§8 Return or erasure of data

(1) Statutory retention obligations for the data processed on behalf, in particular under the national law of the Controller's Member State as well as under budgetary, grant or tax provisions, rest solely with the Controller. The Processor stores the data only for the duration of this Agreement and on the instructions of the Controller; an independent statutory retention obligation of the Processor within the meaning of Art. 28(3)(g) GDPR does not exist.

(2) During the term of the contract, erasure periods follow the instructions of the Controller (retention period configurable in the software). The Processor does not erase data before the period set by the Controller has expired, unless the Controller instructs it to do so. Individual persons (children, staff) are archived in the software and not erased immediately, so that the Controller can meet its retention obligations; archived records are removed from ongoing use. The Processor implements erasure requests from data subjects (Art. 17 GDPR) on the instructions of the Controller by permanently deleting the records concerned, insofar as no retention obligation of the Controller stands in the way.

(3) The Controller may at any time, and at the latest by the end of the contract, retrieve a complete export in machine-readable format (CSV) as well as attendance records as PDF; this constitutes the return within the meaning of Art. 28(3)(g) GDPR. The Processor supports the Controller in all exports and data transfers and, on request, makes the export available via a secure transmission channel.

(4) The Processor erases all personal data in production systems 30 days after the end of the contract or, if earlier, 7 days after an export confirmed by the Controller. Copies in backups are overwritten by rotation no later than 30 days after the end of the contract and are not restored until then, except for restoration on instructions. Discarded check-in actions (discarded_actions) are deliberately retained after the erasure of an individual person (documented retention, §3); nevertheless, they are erased together with the rest of the data stock under sentence 1. Upon completion, the Controller receives an erasure confirmation (date, scope, systems).

(5) The Controller is itself responsible for keeping the exported documents for the duration of its statutory retention periods.

(6) Free package: if use of the free package ends, para. 3 and para. 4 apply to export and erasure.

(7) A loan device (tablet) provided by the Processor must be freed of all data and reset to factory settings before it is returned. The Processor checks the reset after receipt of the device and, where necessary, carries it out again.

(8) Automatic erasure periods of individual functions (independent of para. 4):

• E-mail consent requests: recipient address and check value of the link are deleted upon confirmation, upon replacement by a new request or at the latest about one hour after expiry of the one-hour link; unconfirmed requests after 30 days; confirmed requests remain as evidence. The dispatch log of release and recording requests remains until deletion by the Controller, at the latest until the end of the contract.
• Consents to the recording of a parent meeting that no recording has used: after 30 days, together with the image of the signature; used ones remain with the meeting until the Controller deletes it.
• Audio file of a parent meeting: immediately after the evaluation.
• Photo of a child: upon withdrawal of the release, at the latest at the daily reconciliation.
• Applications in the application portal: unconfirmed ones after seven days; rejected or withdrawn ones twelve months after conclusion.
• Check values of failed password attempts: after one hour.
• Invoice recipients of membership fees and messages between the facility and the Träger: until deletion by the Controller, at the latest under para. 4.

§9 Sub-processors

(1) Upon conclusion of the Agreement, the Controller authorises the use of the sub-processors named in Annex 1 and Annex 2A (Art. 28(2) GDPR).

(2) Any engagement or replacement of a sub-processor is technically blocked until the contracting person has read the updated agreement (including the amended annex) and confirmed it by checkbox. Before this confirmation, no personal data flows to the new or replaced provider. A 14-day objection period without a block does not apply. Until confirmation, only the previously authorised sub-processors remain in use.

(3) For the request for confirmation, e-mail and reminder, §12 paras. 1 and 2 apply.

(4) In accordance with Art. 28(4) GDPR, the Processor ensures that a contract is concluded with each sub-processor which imposes on it at least the same data protection obligations as set out in this DPA.

§10 International transfer of data

(1) Storage locations: Personal data is stored exclusively within the European Union; the exceptions are exhaustively governed by para. 2. As of the date of this Agreement, the sub-processors are configured as follows:

• Supabase: Frankfurt (AWS) - database, authentication, storage; main location of all core data
• Vercel: Frankfurt - hosting, serverless functions and data storage
• Cloudflare: EU data residency (Frankfurt / Cloudflare Regional Services) - API mediation of the Parent App and push delivery for both apps, as well as permanent storage in Cloudflare KV (parent password of the facility, name of the facility, push tokens, device IDs with group assignment, the child identifiers stored on the device (at most 20, so that child-related notifications reach only the devices of that child) and, where applicable, staff ID; wallet passes with child name for up to 5 minutes); no access to the Supabase database
• Brevo (Sendinblue): technical e-mails as well as sending and receipt in software functions - hosting OVH (France and Germany), data storage Google Cloud (Belgium)
• Sentry: Frankfurt - error monitoring and session replay of the web application (masked)
• Zoho: Netherlands - e-mail mailbox
• Google Cloud (Vertex AI / Gemini Enterprise Agent Platform): EU multi-region endpoint (aiplatform.eu.rep.googleapis.com) - all AI data flows except image generation, only when AI functions are activated (Annex C)

The Staff App sends its requests directly to the application (Vercel, Frankfurt). Messages from both apps (absence notices, meal cancellations, pick-up notices, times, check-in/check-out, sick notices, chat messages) are passed to Supabase exclusively within Germany.

(2) Exceptions: The following data flows may, due to the system, run over infrastructure outside the EU:

• Push notifications of the Parent App and the Staff App - via the Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM) and the orchestration layer Expo, triggered via the Cloudflare push worker. Mandatorily prescribed by the platforms Apple/iOS and Google/Android; delivery exclusively via EU infrastructure is not possible. Message content runs there only in transit and is not stored permanently; the push tokens are stored by the services for the duration of their validity (Annex 2A §4). The application data remains in Supabase Frankfurt. Push types and content: Annex 2A §2 and Annex 2B §2
• Wallet cards (digital pick-up cards iOS/Android) - insofar as the wallet services of Apple/Google are involved in the display; likewise prescribed by the platforms (Annex 2A)
• Optional AI image generation (website images, terminal logo, preview images of hazard topics) - global Vertex endpoint, because Google does not offer image models on the EU multi-region; for this flow there is therefore no EU residency commitment. Only image descriptions without personal reference are transmitted (style and design specifications, name of the facility, description of objects); photos, names, identifiers and descriptions of persons are not transmitted. For the image generator with a non-EU model, the user's free text and reference images additionally go there, which must not contain personal data (Annex C §3 No. 19). Transfer basis: standard contractual clauses towards Google; the EU-U.S. Data Privacy Framework applies insofar as the processing takes place in the USA. Individually switchable; details in Annex C
• Websites of the facilities (Cloudflare Pages) - publicly accessible content is delivered worldwide; the content is determined by the Controller

The core product does not require any of these flows. The Controller may deactivate them, as well as the other AI functions, at any time or not use them.

(3) No transfer to third countries otherwise: At the time of conclusion of the contract - apart from para. 2 - there is no active transfer of data to third countries within the meaning of Art. 44 GDPR aiming at permanent storage outside the EU. The DPF and SCC bases under paras. 4 and 5 safeguard against the US parent companies of the cloud providers used and against potential access under US law (in particular the CLOUD Act); for image generation, also the processing on the global endpoint.

(4) Monitoring of the transfer basis: The Processor continuously monitors the validity of the EU-U.S. Data Privacy Framework (Implementing Decision (EU) 2023/1795). Data transfers or potential access possibilities into the USA are currently safeguarded (also) on the basis of the DPF at the following sub-processors:

• Vercel Inc. (hosting / serverless functions - Annex 1)
• Google Ireland Ltd. / Google LLC (Firebase Cloud Messaging - Annex 2A; Vertex AI / Gemini Enterprise Agent Platform when AI functions are activated, including image generation on the global endpoint - Annex 1 and Annex C; storage of technical e-mails at Google Cloud Belgium via Brevo - Annex 1)
• Cloudflare Inc. (API transit and Cloudflare KV of the Parent App, EU data residency - Annex 2A)
• Functional Software, Inc. (Sentry, error monitoring and session replay, EU region Frankfurt - Annex 1)
• Apple Inc. (Apple Push Notification service, transit only, Annex 2A): DPF certification of Apple Inc.; no Art. 28 contract and no APNs-specific SCCs, see Annex 2A §4 and §5

(5) Fallback to standard contractual clauses: For the aforementioned services, with the exception of Apple (APNs), standard contractual clauses (SCCs) pursuant to Implementing Decision (EU) 2021/914 additionally exist as an independent transfer basis pursuant to Art. 46(2)(c) GDPR. Upon lapse, suspension or invalidation of the EU-U.S. DPF, the Processor switches the transfer basis for these services to the SCCs without interruption of the service and informs the Controller of this without undue delay, at the latest within 30 days of becoming aware of it. For APNs, Apple does not offer SCCs; in this case iOS push may be deactivated without impairing the core product. For Supabase Inc., standard contractual clauses (2021/914) apply.

(6) Supplementary protection measures (Transfer Impact Assessment): In line with EDPB Recommendations 01/2020, the following additional technical and organisational protection measures are applied:

• transport encryption (TLS 1.2/1.3) for all data transmissions
• no storage of core personal data outside the EU (storage locations under para. 1, exceptions under para. 2)
• pseudonymisation, insofar as technically possible (e.g. child codes instead of real names in the Parent App)
• data minimisation to the extent strictly necessary for the respective purpose; AI image prompts without personal reference (for the image generator, an obligation of the users under Annex C §3 No. 19); for the other AI functions, identifiers instead of names according to the chosen AI data protection level (Annex C)
• push payload depending on type (Annex 2A §2 and Annex 2B §2). As intended, free text must not contain sensitive data about children, but organisational details and, for staff, working time details. Only messages to groups and to a family from the web app, direct messages to a staff member and, if switched on, team chat messages from the Staff App are checked by the AI data guard (Annex C §3 No. 18); otherwise no technical filtering takes place
• error events without chat/prompt/audio payloads and masked session replay in the EU region Frankfurt (§5 No. 9)

(7) Escalation if the SCCs also lapse: Should the standard contractual clauses also be found insufficient by a judgment of the CJEU or a binding decision of a supervisory authority, the Processor shall take at least one of the following measures and inform the Controller with at least 14 days' notice:

• migration to an EU-based replacement provider, insofar as technically and economically available
• deactivation of the affected service, insofar as technically reasonable - concerns in particular optional functions of the Parent App (push notifications, wallet items) as well as individual AI data flows including image generation (kill switch, Annex C)
• implementation of further protection measures (e.g. client-side encryption), insofar as this keeps the service functional

(8) Effects on the core product: The data localisation of the core product is not affected by a lapse of the EU-U.S. DPF - all core personal data remains at its storage location under para. 1. Affected is exclusively the legal transfer basis for those service providers whose parent company is based in the USA (specifically: Vercel Inc., Supabase Inc., Functional Software, Inc. and Google). For these, the SCCs would apply as the transfer basis (see para. 5), without interruption of the physical storage location or of the service operation. Should the SCCs also be found insufficient by judgment or administrative decision, the Processor would migrate to EU-based replacement providers without a US parent company. The push functionality of the Parent App and the Staff App (FCM, APNs, Expo) and the optional AI image generation can in such a scenario be deactivated without impairing the core product.

§11 Liability

The liability of the parties is governed by the statutory provisions of the GDPR, in particular Art. 82 GDPR. Each party is liable for damage caused by an infringement of the GDPR attributable to it. The Processor is liable for the fault of its employees and of the sub-processors it engages as for its own fault.

§12 Conclusion of contract and confirmation

(1) The contract is concluded by an active confirmation (checkbox) in the authenticated account of the contracting person. The contracting person is the person logged in to the respective account who acts for the Controller. Who is the contracting party depends on the assignment of the facility:

• Facility assigned to a Träger: solely the Träger is the contracting party and Controller within the meaning of Art. 4 No. 7 GDPR. The person logged in to the Träger account confirms by a checkbox in the administration interface (desktop) that cannot be bypassed. Check-in terminals do not show this dialogue. The Kita management of the assigned facility may be asked once to take note of the documents; this is not a second contracting party and not an acceptance of this DPA. Later document updates appear there only as a notice, without a block.
• Facility without Träger assignment: the Kita management confirms in the admin area for the Controller. The acceptance dialogue appears in the Kita admin only in this case, likewise not on check-in terminals.

Every contract confirmation and every acknowledgement is stored with name, e-mail, role (Träger account or Kita management), type of act (contract or acknowledgement), timestamp, the version number of this DPA including its annexes (Annex 1, Annex 2A, Annex 2B, Annex 3, Annex 4, Annex 5, Annex 6, Annex C) and the previously confirmed version.

(2) On the day a new version is made available and with each confirmation under para. 1, the contracting person receives the complete documents by e-mail: this DPA including all annexes in the respective version number and, after confirmation, the confirmation records (name, e-mail, role, timestamp). The e-mails additionally contain download links to the same versions. The same version can be downloaded, viewed and saved at any time on the website (print function). No separate postal return is made. Outstanding confirmations and amended versions are displayed in the dashboard of the contracting person (Träger dashboard where a Träger is assigned, otherwise Kita admin) and presented at the next login in the administration interface. If confirmation is still outstanding after two weeks, a reminder is sent by e-mail. No further reminder e-mails are sent. Assigned facilities remain usable in the meantime.

(3) Material changes to this DPA including its annexes (new data points, new function with data collection, infrastructure other than that already authorised, and other changes not falling under para. 4) are displayed to the contracting person in the dashboard and sent by e-mail on the day of deployment, as a rule at least 14 days before the intended start. The affected function or the changed processing remains technically blocked until the contracting person has consented by checkbox. The remaining software remains usable; personal data flows into the new processing only after this confirmation. Until then, the previously confirmed version remains decisive. If the change concerns a new or replaced sub-processor, the technical block under §9(2) additionally applies.

(4) No update procedure (no checkbox, no e-mail, decisive immediately) applies to:

• Clarifications of the description in this DPA and its annexes: wordings that describe in more detail an already agreed processing (such as naming concrete fields, storage locations or procedures that are already the subject of the agreement), as well as the correction of spelling errors and cross-references. Clarifications change neither the subject matter, purpose, type of data or circle of data subjects, nor sub-processors, storage locations, the level of protection of the TOMs, or the rights and obligations of the parties. Each clarification is documented with a date; the version in force is available at /eu/dpa.
• TOM adjustments under §5 that do not collect new personal data and run on the same infrastructure already authorised

As soon as a clarification or TOM adjustment concerns new data points, a new function with data collection or other infrastructure, para. 3 applies.

(5) The checkbox in the system is the standard procedure for para. 1 and para. 3. A handwritten signature is not required (Art. 28(9) GDPR). The electronic confirmation, including the e-mail under para. 2, satisfies the written form under §13(1).

§13 Final provisions

(1) Amendments and supplements to this Agreement require written form; it is satisfied in accordance with §12(5). The procedure and exceptions are governed by §12 paras. 3 and 4.

(2) Should any provision of this Agreement be invalid, the Agreement remains valid in all other respects. The invalid provision shall be replaced by a valid provision that comes as close as possible to the economic purpose of the invalid provision.

(3) German law applies. The place of jurisdiction is Kaiserslautern.

(4) In the event of conflicts between this Agreement and the terms of use, the provisions of this Agreement prevail for questions of the processing of personal data.

(5) The English version is binding; translations into other languages are provided for understanding only.

Annex 1: Sub-processors

The Processor engages the following sub-processors. A separate data processing agreement (DPA) exists with each of them. Core personal data is not stored permanently outside the EU. For the exception of the optional AI image generation (global endpoint), see Annex C §1(2).

Banks whose accounts the Controller connects for the retrieval of account transactions (§2, bank connection) are contractual partners of the Controller and not sub-processors. The payment of the usage fee by credit card is handled by Stripe Payments Europe, Ltd. (Ireland); Stripe receives only contract and payment data of the Customer in this process, no data processed on behalf, and is not a sub-processor.

As of: October 2026. New or replaced sub-processors are deployed only after the Agreement has been read and a checkbox has been ticked by the contracting person, in accordance with §9(2).

Note on the selection of sub-processors (Art. 32 GDPR - risk assessment)

The choice of Supabase (database, authentication, storage) and Vercel (hosting, serverless functions) as central infrastructure providers - both technically set up on AWS Frankfurt (eu-central-1) - is the result of a careful weighing of data protection requirements against operational security in accordance with Art. 32(1) GDPR. The following criteria were decisive:

• Availability and uptime: several AWS availability zones within the Frankfurt region; SLA commitments of the providers in the 99.9 % range; automated failover without manual intervention
• Support: 24/7 availability for critical incidents; established incident response processes; documented escalation paths
• Security: SOC 2 Type II, ISO 27001, continuous patch management, regular penetration tests, Row-Level Security as a native database function (Supabase), edge-side DDoS protection (Vercel)
• Proven use: long-standing, broad production use; continuous further development; stable release and security update cycles

Alternatives assessed and reasons for rejection:

• Self-hosting on own hardware or at specialised German data centres: increases operational risk (patch latency, lack of a 24/7 operations team, patchy failure resilience); formally GDPR-compliant, but in practice inferior to the level of protection of the AWS Frankfurt stack, not superior to it
• Smaller German/European hosters: offer EU localisation, but not the same level of managed services (auth, Realtime, edge functions). In-house development of these components would increase the security risk, not reduce it
• Open Telekom Cloud / T-Systems: technically viable, but without the complete managed service stack; migration and operating effort disproportionate to the already legally safeguarded status quo

The chosen combination ensures a level of protection appropriate to the risk under Art. 32 GDPR (protection against loss, destruction, unauthorised disclosure) while maintaining EU localisation (Frankfurt). The residual risk exposure towards the US parent companies is safeguarded legally by DPF/SCCs (§10 paras. 4-5) and technically by the measures described in §5.

Annex 2A: Supplement - Parent App (iOS/Android)

The following supplement governs the processing within the scope of the optional Parent App (iOS/Android). It applies insofar as the Controller uses the Parent App as an extension of the core product; the app is not a prerequisite for using the core product. Within the Parent App, the Processor provides a consent query on the privacy notice and terms of use of the app. Ensuring any further effective consent pursuant to Art. 6(1)(a), Art. 7 GDPR lies within the responsibility and discretion of the Controller. §4 and §5 of this annex (push services, wallet, sub-processors, international transfer) also apply to the Staff App (Annex 2B).

§1 Voluntariness and legal basis

(1) Use of the Parent App is voluntary and is not a prerequisite for receiving care services. Non-use has no effects whatsoever on the care contract or the quality of care.

(2) All information provided via the app is also available by other means (e.g. notice board, personal conversation).

(3) The Controller determines the legal basis of the processing via the Parent App (for example a consent pursuant to Art. 6(1)(a), Art. 7 GDPR). If it relies on a consent, its withdrawal is possible at any time without disadvantage. Independently of this, legal guardians consent in the app to its privacy notices and terms of use; they receive push notifications only after their own consent on the device.

§2 Nature and purpose of the processing

The processing comprises:

• Push notifications via iOS/Android (types see below)
• Absence notices, meal cancellations, pick-up notices
• Poll votes (one vote per device; device ID exclusively to prevent multiple voting)
• Display of the child diary and the group report
• Wallet item (digital pick-up card)
• Display of the authorised pick-up persons (name, relationship) on each device on which the child code is stored, and notification of a person collecting the child (also a new person, who is stored only after confirmation by e-mail; Annex 5 §3)
• Parent meeting requests and selection of a proposed date
• Appointments of the facility with acceptance or decline per child
• Display of the releases of one's own child (without possibility of change)
• Display of open payment items with recipient account and GiroCode, confirmation of participation, notice "transferred"; reminders as local notification of the device
• Blog posts of the facility

Not processed: check-in/check-out times of children. These are recorded exclusively at the terminal in the Kita.

Data minimisation: The Parent App is designed for as little data as possible. Parents do not create a user account and do not enter their own names or contact details. If a parent enters a new authorised pick-up person, the name and relationship to the child are transmitted. The app does not collect location data, does not access photos, contacts or the microphone and contains no analytics or tracking tools; the camera serves only to scan the child code. Specialist data is not stored on the device but loaded from the EU database on each call. Only the access to the facility, the child codes and one's own responses remain on the device, as well as, for the offline display of the calendar, the closing days and closures of the facility and its messages dated from the current month onwards (title, text, group). If legal guardians use the app in another language, the content of the facility (messages, blog, diary entries, meal plan) is translated on the device (Apple Translation or Google ML Kit, without transmission to third parties) and the translations are stored on the device (at most 500 entries). The web view of the Parent App shows only the traffic light, messages of the facility and the Kita status; it is provided by the application (Vercel, Frankfurt, Annex 1).

Push notifications: All types run as Expo push via the Cloudflare push worker. The specialist data remains stored in Supabase Frankfurt. Without transit via APNs, FCM and Expo, delivery on iOS and Android is not possible. Message content is not stored permanently by the push services (transit of delivery only). No technical filtering of free texts takes place.

(1) Group message. Recipients: devices of the Parent App of the facility, filtered according to the groups stored at registration. Facility-wide messages go to all registered devices of the facility. Content: title = message title, text = message text, each as written by the staff; the name of the facility is prefixed to the title. As intended, organisational details, no sensitive data about children.

(2) Traffic light status change. Recipients: devices of the Parent App and the Staff App. Only on change to yellow (fixed text: "Kita nah am Limit" (Kita close to the limit)) or red (fixed text: "Kita voll ausgelastet" (Kita fully utilised)). No push for green. Suppressed on closing days and outside opening hours. The facility can switch off yellow and red individually for the Parent App (default: on); devices of the Staff App always receive both.

(3) Appointment reminder. Recipients: devices of the group or of the facility. Content: "Termin: <title>" or "Heute: <title>" and date/time; no names of children or groups.

(4) Meeting appointment. Recipients: devices on which the child concerned is stored. Fixed texts without child, group, time or person.

(5) New diary entry. Recipients as in (4). Fixed title "Neue Notiz" (New note) or "Neuer Gruppenbericht" (New group report), no text.

(6) Payment received. Only if the facility uses parent payments and the Parent App. Recipients as in (4). Content: amount and designation of the occasion; no name of the child.

(7) Message to a family. Recipients as in (4). Fixed title "Neue Nachricht" (New message) with the name of the facility, no text; the app retrieves the content from the EU database. The reply actions (Annex 4 §5(7)) go via the encrypted API, not via push.

Absence notices, meal cancellations and pick-up notices run via the encrypted API (Cloudflare worker in the EU to Supabase Frankfurt), not via the push payloads. The push notification is the trigger; the app retrieves the content from the EU database.

Onward use by legal guardians. Content which the Parent App displays to a parent is passed on to that parent upon display. Legal guardians may use it freely, including with their own programs or AI services; they are themselves responsible for this onward use; the chosen service is neither a sub-processor nor a recipient of the Controller. The Controller takes this into account for content addressed to legal guardians (Annex 4 §3(4) and §5).

§3 Types of data processed

• Pseudonymised child ID (child code), Kita ID
• Absence notices (child, date; the app does not ask for a reason)
• Meal cancellations, pick-up notices (with optional note)
• Poll votes with device ID (purpose: one vote per device)
• Child diary entries concerning one's own child and group reports (display only)
• Wallet pick-up card: name or nickname of the child, child code, facility, address, group
• Push tokens of the devices (pseudonymous) with group assignment and stored child identifiers
• Push payloads according to types (1) to (7) in §2
• Authorised pick-up persons (name, relationship), meeting requests (topic, selection of date), appointment responses, participation and payment notices, releases (display only)

§4 Sub-processors (Parent App and Staff App)

For the Parent App and the Staff App, the following additional sub-processors are engaged. A separate data processing agreement (DPA) exists with each of Cloudflare, Expo and Google (Firebase Cloud Messaging). With Apple there is no DPA for the Apple Push Notification service; the Apple Developer Program License Agreement including Attachment 1 applies.

Note on Apple (APNs): For the Apple Push Notification service, Apple does not offer a data processing agreement pursuant to Art. 28 GDPR nor APNs-specific standard contractual clauses. The contractual basis is the Apple Developer Program License Agreement including Attachment 1 (Additional Terms for Apple Push Notification Service and Local Notifications). A Schedule 4 with data protection content does not exist in the current DPLA. Apple Inc. is certified under the EU-U.S. Data Privacy Framework. APNs is platform infrastructure of iOS; without this route, iOS push is not possible.

APNs, FCM and Expo have no contact with the Supabase database of the main application. Message content is not stored permanently there. What Cloudflare stores in Cloudflare KV (EU data residency) is stated in §10(1); Cloudflare has no access to the Supabase database. Insofar as the Controller or the legal guardians do not activate push notifications and wallet items, the use of Expo (650 Industries Inc.), Firebase Cloud Messaging (Android) and the Apple Push Notification service (iOS) as sub-processors does not apply. The precondition for this is that the permission request for push services (iOS/Android) is declined on the device. The KV storage of the parent password remains in place for as long as the Parent App is activated for the facility.

Clarification of the "transit only" statement in the table: The property "transit only" noted for the Apple Push Notification Service (APNs), Firebase Cloud Messaging (FCM) and Expo refers to the message content (push payload, wallet content) - this is not stored permanently by the push services, but processed exclusively for the duration of delivery (in memory or queue structures, not in databases). The device tokens themselves (APNs device tokens, FCM registration tokens, ExpoPushTokens) are processed and stored by the respective push services for the duration of the token's validity, since otherwise delivery would be impossible for systemic reasons. This token storage is part of the platform infrastructure and not content of the actual processing of the Kita data on behalf.

No technical alternatives: An exclusively EU-based or provider-independent push infrastructure for iOS and Android does not exist at platform level. APNs is the only authorised delivery route for iOS push, FCM the only authorised delivery route for Android push. A relocation of these services to EU infrastructure, or avoidance of token storage at the push services, is neither configurable nor preventable at application level. Expo is used merely as an orchestration layer between the app and APNs/FCM, in order to enable a platform-independent implementation.

Manual consent of the user (opt-in): The processing by APNs, FCM and Expo takes place exclusively on the basis of an express, manual activation of the push permission by the respective user via the permission request of the operating system (iOS/Android). This applies to legal guardians in the Parent App and to staff in the Staff App. Anyone who downloads the Staff App and grants the permission on the device thereby consents again to delivery to this device. If the user declines the permission or later withdraws it in the device settings, any further token generation and transmission to the named sub-processors ceases. The storage of the specialist data remains in Supabase Frankfurt; transit via APNs, FCM and Expo is technically not otherwise possible for delivery on iOS and Android.

Note on the role of Cloudflare: Cloudflare mediates API requests of the Parent App and the push delivery of both apps (edge routing, TLS termination, DDoS protection) and stores in Cloudflare KV with EU data residency the data named in §10(1). The child diary and group report are passed through Cloudflare to the Parent App and are not stored there. Cloudflare has no access to the Supabase database of the Processor. API transit and KV are configured for the EU (Cloudflare Regional Services / Frankfurt).

§5 International transfer of data

(1) The transfer to Cloudflare, Expo and Google (Firebase Cloud Messaging) takes place on the basis of the adequacy decision of the European Commission pursuant to Art. 45 GDPR (EU-U.S. Data Privacy Framework, Implementing Decision (EU) 2023/1795), insofar as the respective provider is certified. Additionally, standard contractual clauses pursuant to Art. 46(2)(c) GDPR (Implementing Decision (EU) 2021/914) have been concluded with these providers.

(2) For APNs, the EU-U.S. Data Privacy Framework applies, insofar as Apple Inc. is certified. Apple does not conclude standard contractual clauses for APNs. The Developer Program License Agreement including Attachment 1 applies.

(3) The Processor regularly checks the validity of the EU-U.S. Data Privacy Framework. Upon its lapse, it switches the transfer basis at the providers with agreed standard contractual clauses without undue delay to these clauses as the sole transfer basis. For APNs, the DPF basis then ceases; iOS push may then be deactivated without impairing the core product (§10(8)).

§6 Reference

Otherwise, the provisions of the data processing agreement apply.

As of: October 2026.

Annex 2B: Supplement - Staff App (iOS/Android)

The following supplement governs the processing within the scope of the optional Staff App for employees of the facility. It applies insofar as the Controller uses the Staff App. For push services, wallet, sub-processors and international transfer, §4 and §5 of Annex 2A apply.

§1 Legal basis and voluntariness

(1) The processing takes place within the scope of the employment relationship between the Controller and its employees. The Controller ensures the legal basis, in particular pursuant to Art. 6(1) points (b) and (c) GDPR, Art. 9(2)(b) GDPR for sick notices, a works or service agreement pursuant to Art. 88 GDPR or the national law of the Controller's Member State.

(2) Use of the Staff App is voluntary for employees. Working time in the facility is recorded at the terminal; absences and notices are also possible without the app. No disadvantages may arise from non-use.

§2 Nature and purpose of the processing

• Own working times and overtime account; home-office check-in with work category; adjustment requests
• Absence and sick notices
• Daily plan of the team
• Internal staff chat, notice board and polls; messages to parents (after renewed password entry)
• Mailbox: direct messages from the management to an individual person, replies to queries on working time and own upcoming staff appointments
• Wallet staff ID card
• Push notifications: traffic light (Annex 2A §2) as well as team chat, calls, automatic notices, appointment reminders, mailbox, working-time confirmation and end of care time (see below)

Data minimisation: The Staff App is designed for as little data as possible. It does not collect location data, does not access photos, contacts or the microphone and contains no analytics or tracking tools; the camera serves only to scan one's own QR code at login. What the app shows about children depends on the data protection mode (§4(1)a): in the mode "Private Telefone" (private phones) it shows no master data of children, about children only counts; in the mode "Dienstgeräte" (work devices) it may show names of children of one's own group, insofar as a function needs them. It shows child codes in no mode. Free texts from colleagues or the management and the topic of a parent meeting stated by parents may contain information about children in both modes. Specialist data is not stored on the device but loaded from the EU database on each call; only the session tokens remain on the device in protected device storage. A session lasts at most 30 days.

Data route: Requests of the Staff App go encrypted directly to the application (Vercel, Frankfurt, Annex 1) and from there to Supabase Frankfurt, not via Cloudflare. Push messages run via the Cloudflare push worker (Annex 2A).

Team chat, calls and notices. Recipients are exclusively devices of the Staff App. The Controller may switch off the team chat in the Staff App (default: on).

• Chat push: title = name of the writing person, text = chat text (shortened). Recipients depending on the marking: the entire team, the staff of a group or the persons mentioned; without a marking no push. This includes contributions which the management confirms via the Autopilot.
• Time corrections from the Staff App go as an adjustment request to the management, not into the team chat; the function exists only if clocking in and out in the app is switched on.
• Calls: push "<name> ruft Sie" (<name> calls you) with reason, only to the called person who is checked in.
• Automatic notices (sender "Automatischer Hinweis" (automatic notice)), switchable per rule in the chat settings. Defaults: mandatory break off, "Tages-Arbeitszeit erreicht" (daily working time reached) on, "geplant, aber nicht da" (planned, but not present) on (only with active staff planning). "Nicht ausgecheckt" (not checked out) serves the complete documentation of attendance and cannot be switched off. The notices name the person concerned and are visible in the team chat. The push goes for mandatory break, "Tages-Arbeitszeit erreicht" and "Nicht ausgecheckt" only to the person concerned; for "geplant, aber nicht da" to the staff of the group.
• Appointment reminders name only type, time and group.
• Mailbox: the management writes in the web app a direct message to an individual person; only this person reads it in the Staff App. Sending and deleting require the admin password. No reply function, no sending by e-mail. The messages remain stored until the Controller deletes them; there is no automatic deletion. Push "Neue Nachricht im Postfach" (new message in the mailbox) without sender and without content.
• Working-time confirmation: push to the person themselves after a clock-in, clock-out or change of status in the app, with event and time, without names.
• End of care time: from 1 November 2026, once a day shortly after the end of opening hours, to the persons who are still checked in for care (not to housekeeping staff), with a fixed text without names.

As intended, the content contains organisational and working-time details, no sensitive data about children. Team chat messages from the Staff App are checked before sending only by the AI data guard, if the Controller has switched it on for the team chat (§4(1)a, Annex C §3 No. 18); other free texts are not technically filtered.

Staff who install the Staff App grant the push permission themselves on the device and may withdraw it at any time in the device settings. The storage of the specialist data remains in Supabase Frankfurt.

§3 Types of data processed

• Name or code, staff ID, login data (QR code and personal password, session tokens)
• Own working times and overtime account, home-office check-in, adjustment requests
• Absence and sick notices (reason and optional note; health data under Art. 9 GDPR), also the reason for leaving early and for the weekly question on negative hours; catalogue and visibility according to §3 of this Agreement
• Daily plan of the team: names, shifts, breaks and current attendance of the colleagues; reasons for absence only for one's own person, others appear as "abwesend" (absent)
• Chat messages (content, sender name or code), notice board contributions, poll votes, messages to parents
• Mailbox: direct messages from the management (recipient, title, text, time)
• In the mode "Dienstgeräte": names of children of one's own group, only for display in functions which need them; no storage on the device, no disclosure to AI functions
• Wallet staff ID card: name, staff ID, group
• Push tokens of the devices (pseudonymous, linked with the staff ID); push content according to §2
• Calls (calling and called person, reason, response and time), @mentions
• Hazards: notes with the writing person, warning triangles and "thumbs up" per person; preview image of a topic under Annex C §3 No. 15
• Room reservations with booking person
• Calendar: appointments of the facility and own staff appointments
• Questions to the AI assistant, if switched on (transmission only, no storage; Annex C §3 No. 4)

§4 Settings, end devices and obligations of the Controller

(1) Settings. In the settings, the Controller determines which functions of the Staff App are used. Defaults: Staff App, team chat, clocking in and out in the app and messages to parents switched on, each switchable off; daily plan and team week only with active staff planning (default: off); retention of the team chat 1 day (selectable 1 to 7); automatic notices according to §2; AI assistant off (Annex C §3 No. 4); data protection mode "Private Telefone"; AI data guard in the team chat off. The settings are instructions within the meaning of this Agreement.

(1a) Data protection mode. The Controller selects for the facility one of two modes; the mode applies to all devices on which the Staff App is logged in.

• a) Private Telefone (private phones; default): the app shows no data of children, only counts; functions which need names of children are locked. Free texts shall contain no names or recognisable descriptions of children. The Processor recommends switching on the AI data guard in the team chat.
• b) Dienstgeräte (work devices): the Controller thereby declares that the app is operated exclusively on its devices, and selects this mode only then. The app may show names of children of one's own group, insofar as a function needs them; as at the date of this Agreement, no function does so yet, the first planned is the request for a parent meeting. In the team chat, children may be named insofar as required for the daily routine; health information and information on child protection or custody do not belong here either. The Processor recommends the AI data guard in the team chat also in this mode.

The AI data guard in the team chat works in the same way in both modes (Annex C §3 No. 18). Which rules apply to free texts is specified by the Controller to employees under para. 4.

(2) End devices. The Staff App may be used on work devices of the Controller and, insofar as the Controller permits this, on private devices of employees. The Processor recommends operation exclusively on facility-owned work devices. The app does not access private content of the device (§2). The Processor provides no device management (MDM) and cannot view devices or delete them remotely.

(3) Private devices. If the Controller permits private devices, it defines the conditions in advance (service instruction or works or service agreement). It ensures that use is voluntary, that an equivalent alternative exists (terminal, work device or notice to the management), and that no disadvantages arise from non-use. Use on private phones is thus an option which the Controller may choose.

(4) Information. The Controller informs employees before first use (Art. 13 GDPR), including the settings selected, and points out the duties of care: screen lock, no disclosure of password and ID, logging out on shared devices, reporting loss without undue delay, no health data in free texts and information about children only under para. 1a, no screenshots and no disclosure.

(5) Shared work devices. Login is personal and lasts up to 30 days; there is no automatic logout. The Controller regulates logging out after use.

(6) Co-determination. Individual functions are suitable for monitoring behaviour or performance, in particular recorded working times and hours account, daily plan with current attendance, switched-on automatic notices, calls with response, polls with personal vote, a switched-on AI assistant with names for management, as well as time recording, shift-planning AI, daily analysis, Träger Autopilot and the attendance patterns of the AI functions (Annex C §1(14)). If the Controller introduces the Staff App or any of these functions, it observes the participation rights of the employee representation (under the national law of the Controller's Member State, country notes in Annex 6), concludes a works or service agreement where necessary and sets the switches under para. 1 accordingly.

(7) Leaving. If the Controller archives a person, the software ends all their sessions (an access token already issued continues for at most 15 minutes), deletes their app password and deregisters their devices from push delivery; their staff ID card is no longer accepted at the terminal.

(8) Loss of a device. The Controller replaces the QR badge of the person in the administration; this has the effect of para. 7. The Processor supports this on request.

(9) Lock screen. Push content may be visible on the lock screen and remain in the notification centre; employees may switch off the preview in the device settings.

§5 Reference

Otherwise, Annex 2A §4 and §5 as well as the provisions of the data processing agreement apply.

As of: October 2026.

Annex C: Supplement - AI functions

This supplement governs the processing within the scope of the AI functions. They are available in the administration interface (web app), in the Träger area, at the group tablet (voice dictation) and, only if the facility switches it on, as an AI assistant in the Staff App; if someone creates a hazard topic in the Staff App, its preview image arises under §3 No. 15. There are no AI functions at the check-in terminals; in the Parent App only the AI translation (§3 No. 17), and only if the facility has selected the level "Alle" (all). The AI functions can be switched on and off individually; with a function switched off, the associated data flows cease. How much the AI learns about persons is governed by the AI data protection level (§1(5)). A Träger may lock functions for all the facilities assigned to it and cap the level at an upper limit; the facilities cannot lift this. The software is fully usable without AI functions.

§1 Common findings

The following findings apply to all data flows named in §3, insofar as nothing deviating is specified there. They are made here once and not repeated in the individual flows.

(1) Sub-processor: Google Ireland Ltd. / Google Cloud (Vertex AI / Gemini Enterprise Agent Platform). The contractual basis is the Vertex AI Data Processing Addendum. Authentication takes place without API keys via Workload Identity Federation (Vercel OIDC); local development via Application Default Credentials (ADC). Hosting of the calling application: Vercel (Annex 1). Transfer basis, or safeguard against potential access: EU-U.S. Data Privacy Framework, supplemented by standard contractual clauses.

(2) Data residency: All data flows except image generation run via the EU multi-region jurisdictional endpoint (aiplatform.eu.rep.googleapis.com). Processing is contractually restricted to the EU geography (no single-region pinning to Germany). Exception for image generation: image models are not provided by Google on the EU multi-region. This data flow uses the global endpoint; for it there is no EU residency commitment. Only image descriptions without personal reference go to the global endpoint (style, colour and design specifications including the name of the facility, as well as a description of objects without persons previously generated on the EU endpoint); photos, free text of the facility, names, identifiers and descriptions of persons do not go to the global endpoint. Deviating from this, for the image generator with the non-EU model, free text and reference images of the user go to the global endpoint (§3 No. 19). The exception is also named in §10 of the DPA.

(3) Models (as of 19.10.2026), all via Google Cloud (Vertex AI): text/understanding gemini-3.8-flash (EU); quick tasks such as dictation, translation and checks gemini-3.5-flash-lite and gemini-3.1-flash-lite (EU); Claude Haiku 5.5 from Anthropic (claude-haiku-5-5, in the Model Garden of Google Cloud on the European multi-region endpoint, processing in Europe; the contracting party remains Google); image generation gemini-3.1-flash-image and gemini-3.1-flash-lite-image (global). A change to another model of the same sub-processor on the same endpoint is documented as a clarification under §12(4).

(4) No training: Inputs are not used to train AI models (Vertex contractual terms). Storage at Google: Google does not, in principle, store inputs permanently. If automatic safety filters detect a suspicion of misuse, Google may store the prompts concerned solely for the purpose of the misuse review for up to 90 days, namely in the EU multi-region selected for the project.

(5) AI data protection level: How much the AI learns about persons is determined by a level with three values: a) "Aus" (off): Autopilot (including shift-planning AI, "Eigener Export" (own export) and daily analysis) and the AI assistant of the Staff App are switched off; b) "Pseudonymisiert" (pseudonymised): children and educators appear only as identifiers (for example "Kind 7F3A", "Erzieher:in K2QM"); c) "Alle" (all): real names of the educators and of the children. The facility selects its level in the settings; the default is "Alle". Anyone who changes from a lower level to "Alle" confirms this separately. Before use, the Controller checks whether the default corresponds to its requirements (Art. 25(2) GDPR), and otherwise selects a lower level. The Träger may set a maximum level for all the facilities assigned to it; the lower of the two levels always takes effect. Without a set maximum level, no limitation applies. If the software cannot read a Träger's maximum level, it works with "Pseudonymisiert". Irrespective of the level, reasons for absence and other health information never go to the AI related to a person, but at most as a count.

(6) Scope of the level: The level applies to the functions which read the operating data of the software: Autopilot chat, "Eigener Export", shift-planning AI, daily analysis, AI assistant of the Staff App as well as, for each facility, the Träger Autopilot and the monthly report. The shift-planning AI and the AI assistant for the management run only at level "Alle"; the AI assistant for educators always works with identifiers at every level except "Aus". The level does not apply to functions which exclusively process what users themselves enter, speak or upload (such as dictation, e-mail assistant, parent meeting, text drafts, floor plan, website); these are controlled by their own switches (para. 8). What the team itself writes (in particular team chat, notice boards, notes and appointments) is read by the AI at every level except "Aus" as it was written, including names contained therein.

(7) Pseudonymisation and control: The Processor forms identifiers from the internal identifier of the person with a secret key before transmission. The same person permanently carries the same identifier; Google cannot infer the person from it. Only the Processor knows the assignment of identifiers to names; it is stored with the daily history (para. 12), so that authorised users see the answer with names. Pseudonymised data remains personal data. Google sees the inputs only transitorily, subject to the misuse review under para. 4. The users control the free text and uploads; the interface asks not to enter health data, yet whatever is entered or uploaded is transmitted. The Controller instructs its users accordingly. Buttons which trigger an AI function are uniformly marked in the administration interface (purple with a sparkle symbol).

(8) Switches: In addition to the level, the facility may switch off individually: the website builder, voice dictation (and with it the e-mail assistant, parent meeting, parent letters and AI text drafts), the floor plan from photo, the AI translation (§3 No. 17) and the AI data guard (§3 No. 18). Image generation and the AI assistant of the Staff App run only after the facility has switched them on. The Träger may lock individual functions for all the facilities assigned to it, lock all functions with processing outside the EU (currently image generation, including the preview images for hazard topics and the non-EU model in the image generator) and switch off the monthly report. If the software cannot read a Träger lock, it is deemed to be set. A Träger maximum level "Aus" switches off the functions under para. 6 sentence 1, not the functions controlled by their own switches. The help chat and the DPA chat, which process no operating data, cannot be switched off. Functions which operate only on the explicit call of a user transmit nothing as long as they are not used. The hazard AI and the handbook draft currently have no switch of their own. The Processor may switch off individual AI functions at any time for security or operational reasons.

(9) Implementation of results: AI results are suggestions and drafts. Actions proposed by the Autopilot (for example a message to parents, a contribution in the team chat, a break plan or a check-out) are executed by the software only when the management confirms them individually and has previously identified itself with the admin password. Exception shift-planning AI: on the instruction of the planning person, it changes the shift plan directly; every change is marked, logged and can be reversed. No AI result is sent without an act of a user; excepted are the daily analysis and the monthly report, which go by e-mail to the management or the Träger users respectively.

(10) Automatic processes: In principle, a call takes place only on an act of a user. Exceptions: the daily analysis, the monthly report and the preview image of a newly created hazard topic.

(11) Notice dialogue: Before the first use of Autopilot chat, shift-planning AI, "Eigener Export", help chat, Träger Autopilot and DPA chat, an account-related notice dialogue appears; the confirmation is stored in versioned form in the user account. The dialogue serves transparency and is not a consent under Art. 6(1)(a) GDPR.

(12) Storage at the Processor (servers in Germany): a) History of Autopilot chat and shift-planning AI: per user, facility and day, at most 60 entries; automatic deletion after a period of one to seven days chosen by the facility (default: after the end of the calendar day, in the time zone of the facility). "Eigener Export", help chat, DPA chat, Träger Autopilot and the AI assistant of the Staff App are not stored. b) Confirmed Autopilot actions and change packages of the shift-planning AI (with the state before the change): until deletion under §8 of the DPA. c) Daily analyses and monthly reports: until deletion under §8 of the DPA. d) E-mail assistant (sample e-mails, instruction, result), parent meetings (report, tasks, version for the parents) and consents to recordings including signature: until the facility deletes them, at the latest under §8 of the DPA. e) For each AI call, a usage record without content (facility, Träger, function, model, quantity details) for billing the AI credit. f) Translations under §3 No. 17 with a check value of the original, without the original: at most 30 days. Whether entries under a) to c) contain names or identifiers depends on the effective level (para. 5). Audio is never stored permanently: dictations go directly to the AI; recordings of parent meetings remain in protected storage only until the end of the evaluation and are deleted thereafter, even if the evaluation fails. Photos for the floor plan and handbook draft, as well as images and reference images of the image generator and documents uploaded and letters generated for the parent letters, are not stored; cleaned letter templates remain stored until the facility deletes them (§3 No. 20). Technical errors go to Sentry (Annex 1) without chat, prompt, audio or image content.

(13) AI credit: AI functions consume a monthly or one-time credit of the facility or of the Träger. If it is used up, the software refuses further calls; help chat and DPA chat are free of charge and excluded from this; automatic processes (para. 10) are not blocked.

(14) Purpose limitation for data relating to employees: The software processes attendance, working time and shift plan data of staff for three purposes: compliance with supervisory duties and the staffing ratio for the protection of children, working time recording and payroll, and compliance with working time law. For the planning of staffing, the AI functions may describe attendance patterns, also relating to individual employees (for example usual arrival times or an accumulation of absences on particular weekdays). In doing so, they assess neither performance nor behaviour: no judgments, no rankings, no comparisons between persons, no assumptions about reasons or health. The shift-planning AI plans from contracts, absences, qualifications and demand. The participation rights of the employee representation (under the national law of the Controller's Member State, country notes in Annex 6) remain unaffected; the Controller may regulate the use of these functions in a works or service agreement and set the AI data protection level accordingly.

(15) Protection with inputs: What users enter into AI functions is the responsibility of the Controller and its staff (Annex 4 §3). As an additional technical protection measure, the AI is instructed not to process inputs which contain certain information. Instead, it points out the error and aborts the operation, without repeating the information, without calling tools and without proposing actions:

• a) always: health data of children or staff and the other special categories under Art. 9 GDPR, suspected cases concerning child protection, information on custody, court decisions, contact bans and family conflicts, access data (passwords, PINs, QR and child codes), bank, identity document, tax and social insurance numbers, as well as assessments of individual employees (para. 14);
• b) depending on the effective AI data protection level: at "Pseudonymisiert" names of employees and children; in the AI assistant of the Staff App for educators always names;
• c) depending on the function: in the help and DPA chat any information about real persons; for website and release drafts names and descriptions of individual children.

Excepted are voice dictation (literal conversion into text) and the evaluation of recorded parent meetings. An aborted input is not stored. However, it has by then already reached the AI and, like all inputs, was processed exclusively on the EU endpoint (para. 2), not used there for training and not stored permanently at the sub-processor (para. 4). The recognition is based on the AI and is not complete; it does not replace the obligations of the Controller under Annex 4 §3.

(16) Internet research: In the Autopilot chat, in the Träger Autopilot, in the chat "Mit KI schreiben" (write with AI) of the feedback to the Träger and with "KI destillieren" (distil with AI) (hazards), the AI may research a general question on the internet (Google search) and display the answer with sources. The question contains no names, addresses or information about children, legal guardians or employees; a question with a name from the current request is rejected by the software. Google may store search queries for up to three days; this cannot be switched off. The Processor may switch the function off centrally.

§2 Purposes

Advice and evaluation for the facility (Autopilot chat, "Eigener Export", daily analysis), shift planning (shift-planning AI), information for employees (AI assistant of the Staff App), evaluations for the Träger (Träger Autopilot, monthly report), product help and explanation of the contract (help chat, DPA chat), conversion of speech into text (dictation), drafting of texts (e-mail assistant, AI text drafts, website), documentation of parent meetings, risk assessment and handbooks (hazard AI, handbook draft), illustration (image generation) and room planning (floor plan from photo), in each case in accordance with the level and the switches under §1.

§3 The data flows

1. Autopilot chat and "Eigener Export" (administration interface, only after the admin password). Inputs: questions of the management, page path and tool outputs, thus key figures (traffic light, capacity, attendance by category, understaffing, planned/actual, opening hours, thresholds, care models), records per person (attendance, events, shift and break plans) according to the level, names of groups and care models, as well as free text of the team (§1(6)). For the "Eigener Export", the AI formulates a calculation path which the Processor executes on the data of the facility in a sealed-off environment; the AI does not see the data over which the calculation path runs. Actions under §1(9). Level: as set.

2. Shift-planning AI (staff planning). Inputs: shift plan of the visible period, persons with contractual hours, planned minutes and absence without reason, staffing demand per 15 minutes, children only as totals. Changes the shift plan directly (§1(9)). Level: only "Alle".

3. Daily analysis (automatically shortly before closing time on days with high utilisation; the first without query, each further one only after approval of the management; omitted at level "Aus"). Inputs as in No. 1. Recipient: management by e-mail. Storage under §1(12) c.

4. AI assistant of the Staff App (only after the facility has switched it on). Answers questions about what the app already displays to the logged-in person (own working time, shift plan, utilisation, team chat, notice boards, hazards, handbooks); read-only. For educators always with identifiers, for the management with names of staff at level "Alle". Free text under §1(6). No storage at the Processor.

5. Träger Autopilot (Träger area, only users with a Träger role). Inputs: questions of the Träger users and tool outputs across the assigned facilities, thus key figures, planned hours, shifts, hours accounts and days of absence per person with approval status; reasons for absence only as a count. Names of staff and event texts (which may contain children's names) only from facilities at level "Alle", otherwise identifiers. For each facility the lower level applies from its own setting and the maximum level of the Träger; facilities at level "Aus" are not included. No storage.

6. Monthly report (automatically on the first of the month; can be switched off by the Träger). Inputs: aggregated monthly key figures without personal names, names of the facilities and designations of closing days. Recipients: Träger users by e-mail. Storage under §1(12) c.

7. Help chat. Inputs: freely formulated questions, page path and product documentation; no operating data. No storage.

8. DPA chat (Träger area). Inputs: freely formulated questions and the text of this Agreement; no operating data. The AI explains exclusively the contract text and gives no legal advice. No storage.

9. Voice dictation (group tablet: daily report, report on a child). Input: voice recording; it may contain children's voices, names and observations. Only conversion into text; the text is stored in the daily report, the recording never.

10. E-mail assistant. Inputs: sample e-mails inserted by the facility (they may contain names and contents of parent correspondence) and the typed or spoken instruction. Result: a draft which is not sent. Storage under §1(12) d.

11. Parent meeting (only after the admin password). Input: recording of a conversation of at most 30 minutes; it contains everything said, including names and, where applicable, information on the health and development of the child. Names or other data of the child from the software do not go to the AI. The software evaluates a recording only if consents stored in advance for the meeting are present, including at least that of one parent; consents are signed on the screen or given by confirmed e-mail and apply to exactly one recording. Result: internal report with tasks and a version for the parents, which are not sent. Storage under §1(12) d.

12. AI text drafts (release texts; feedback to the Träger). Inputs: title and key words, as the facility enters them. The result fills the form; no storage before it is adopted.

13. Website builder. Inputs: answers of the management in the setup assistant (texts, contact and legal notice details) and, where applicable, two own style images; the AI describes the style images on the EU endpoint, and only this description goes to the image generation. Design and texts on the EU endpoint; images under No. 14.

14. Image generation for the website and terminal logo (only after the facility has switched it on; lockable by the Träger). Inputs: style, colour and design specifications and the name of the facility; no personal data, no photos. Global endpoint (§1(2)).

15. Preview image of a hazard topic (automatically after creation, also from the Staff App; excluded by the Träger's non-EU lock). Step 1 (EU endpoint): the photo or the text of the topic; the AI describes only objects and the hazard, no persons, and discards photos which mainly show persons. Step 2 (global endpoint): only this description. The preview image is stored with the topic.

16. Floor plan from photo, hazard AI and handbook draft. Floor plan: a photo of a room sketch (it may show persons if they are in the picture), not stored. Hazard AI: topic and notes of the team, as they were written; results are suggestions which only the management adopts. Handbook draft: up to five photos of a printed guide or a description by the management; photos are not stored.

17. AI translation (switch "Übersetzung" (translation), default on; effective only at level "Alle", insofar as the Träger's maximum level permits it). Translation takes place into the language of the legal guardians which the facility has stored for the child or, as long as none is stored there, which the legal guardians have selected in the Parent App (German, English, Turkish, Arabic, Ukrainian, Russian, Polish, Romanian): a) e-mails of the facility to legal guardians (consent requests, pick-up authorisation, QR letter, appointment confirmation); names, data, links and codes are replaced beforehand by placeholders and do not go to the AI; the AI reads the free text of the facility as it was written; b) contents in the Parent App (messages, appointments, blog, group reports, diary notes, notes on meeting requests); the AI reads the entire text as it was written, including names and, in diary notes, where applicable health information about the child; c) the topic of a meeting request of the legal guardians, back into the language of the facility at the push of a button by the management. Processing on the EU endpoint (§1(2)). Only the translation is stored, with a check value of the original, not the original (§1(12) f). Push notifications are not translated. Without AI translation, the translation remains on the device of the legal guardians (Annex 2A).

18. AI data guard (switch "KI-Datenwächter" (AI data guard), default on and always displayed). The AI data guard runs only at level "Alle", because the AI must read the full text for it; at the other levels it is off, and the interface shows this. Without AI credit, only the name comparison runs without AI. Before a text written in the web app goes to legal guardians or to the public (messages and notice board including polls, messages to a family, appointments, released group reports and diary notes, blog, website texts and legal notice), it is checked. First the server compares it without AI with the names of the children of the facility; the list of names does not leave the server. Thereafter the AI (with credit) checks for the information under §1(15) a) as well as for names or recognisable descriptions of individual children and adult private persons; first names and full names of the children are replaced by placeholders in this process, other names go as they were written. For a message to a family, the name of the selected child does not count as a finding. The AI delivers only a judgment and the category and does not change the text. A critical text may be sent only by the management after re-entering the admin password. If the check is not possible, the text is sent and a notice is displayed. Texts are not stored; only the process is counted, without text and without person. A direct message from the management to an individual person is likewise checked (mailbox of the Staff App, Annex 2B §2). In the team chat, the data guard checks only if the Controller additionally switches on the switch "KI-Datenwächter im Team-Chat" (AI data guard in the team chat; default off); then also messages from the Staff App. There only the check by the AI runs, without name comparison, and without AI credit there is no check. In the event of a finding, the message is not sent; the writing person may change it or send it anyway. Other texts from the Staff App, including calls and messages to parents, are not checked. The check is not complete and changes nothing under Annex 4 §5(5).

19. Image generator (only after activation by the Träger, default off, and switching on by the facility; marked as an AI function). Users describe an image in free text and may upload a reference image, only after confirming that it shows no persons or children; without this confirmation the server does not accept it. They select a model; the software indicates for each whether it processes in the EU or outside the EU (global endpoint, §1(2), no EU residency commitment). Free text and reference images go unchanged to the selected model. Reference images must not show persons or any other personal data (permissible are, for example, freely usable images from the internet or own images without persons); the free text contains no names and no descriptions of real persons. This obligation rests with the users (Annex 4 §3); the software does not check reference images. Generated images are downloaded to the device of the user; generated images and reference images are not stored at the Processor. The Träger's lock "Bild-KI außerhalb der EU sperren" (lock image AI outside the EU) switches off all models outside the EU.

20. Parent letters (via the switch of voice dictation; sending only with the admin password). a) Template: The facility uploads an existing letter (PDF, Word file or photo). The AI receives the document in full, as it is, and replaces personal details by placeholders (such as "{Kind}" (child), "{Eltern}" (parents)); remaining e-mail addresses and telephone numbers the software additionally removes. Only the cleaned template is stored, until the facility deletes it, with the number of removed details per category, never their values; the uploaded document is not stored. The Controller is responsible for the content of the uploaded document (Annex 4 §3). b) Letter: On a request for changes, the AI writes a letter with placeholders; names and information about children never reach the AI in the process. The software inserts the values per child (name, pseudonym, birthday, age, group, care model, admission and school entry date; for "Eltern" (parents) "Eltern von" (parents of) appears with the first name of the child). If the facility has stored the language of the legal guardians, the AI translates the placeholder version (No. 17). c) Output: for each child a PDF for download (ZIP) or an e-mail with letter text and PDF to the address of the legal guardians stored for the child (sender "[Name der Einrichtung] via Bienenstock", dispatch via Brevo, Annex 1), at most once per child and dispatch. Every dispatched e-mail is recorded in the dispatch log; e-mails which could not be delivered appear without address and without error text as a notice for the facility until it resolves the notice. The AI data guard does not check the letter text. Processing on the EU endpoint (§1(2)).

§4 Legal basis and obligations of the Controller

(1) The processing takes place on behalf of and on the instructions of the Controller; the choice of level and the switching on and off of functions under §1 are instructions.

(2) Insofar as special categories of personal data may be affected (in particular dictation, parent meeting and free text of the team), the Controller ensures a legal basis under Art. 9(2) GDPR.

(3) Recordings of conversations (§3 No. 11) presuppose the consent of all conversation participants (under the national law of the Controller's Member State). The software checks only whether stored consents under §3 No. 11 are present; obtaining the consent of all those present, including the staff, is the responsibility of the Controller.

(4) The notice dialogue under §1(11) is not a consent under Art. 6(1)(a) GDPR.

§5 Reference

Otherwise, the provisions of the data processing agreement apply.

As of: October 2026.

Annex 3: Supplementary provisions for church and public Träger

Not applicable outside Germany.

Annex 4: Free-text fields

§1 Definition

Free-text fields are input fields into which users can write or dictate any text, such as notes, messages, reasons, descriptions and chat contributions. Which personal data appears in a free-text field is determined solely by whoever writes it. The Processor can neither limit the content in advance nor recognise it afterwards.

§2 Overview by risk

(1) High risk (content about individual children, health or the conduct of employees is likely, or the text reaches parents, the AI or the Träger):

• Notes on the child in the master data and in the child diary, daily reports of the group, in each case also dictated (dictation can be switched off, default on); legal guardians receive notes and daily reports only if the Controller switches on the display in the Parent App (default off) and the staff releases the individual entry
• Parent meetings: recording, report and version for the parents; reasons for meetings and meeting requests of the legal guardians
• Messages and notice-board contributions to legal guardians, as well as messages to a family (also as push notification)
• Internal staff chat including notice board and calls; adjustment requests regarding working time
• Notes on absences and sick notices of staff
• Notes in the hazards area
• Event notes of the management, which enter reports and evaluations for the Träger
• Inputs to the e-mail assistant
• Notes on collections and meal cancellations, other reasons for absence of staff

(2) Medium risk (personal reference likely, circle of recipients limited): reasons for time corrections, shift and report notes; appointments for parents and staff; authorised pick-up persons and exceptional handovers; notes on payments; feedback to the Träger and replies, internal notes of the Träger on applications; texts of the own website and of the blog (public); inputs to AI functions.

(3) Low risk (organisational details): designations of groups, rooms, models and occasions; room reservations, reasons for closing days, handbook articles and release descriptions.

The Processor provides the current list of the fields with recipients and erasure on request in text form.

§3 Obligations of the Controller

(1) The Controller decides whether and for what its staff use free-text fields, and instructs the users to record only what is necessary for the purpose (Art. 5(1)(c) GDPR).

(2) Special categories (Art. 9 GDPR), in particular diagnoses, suspicions of illness, medication and injuries, as well as details on custody, family conflicts and contact bans are entered only insofar as a legal basis exists for this and the field is designated for it; never in the internal staff chat, in messages to legal guardians, in hazard notes and in inputs to AI functions.

(3) Assessments of the performance or conduct of individual employees do not belong in the staff chat or in hazard notes. The Controller observes the rules on employee data and, where present, the co-determination of the employee representation.

(4) Before releasing a text to legal guardians or publishing it on the website, the Controller checks whether the text contains data of third parties, in particular of other children.

(5) The Controller deletes free texts which it no longer needs; the software provides deletion functions for this.

§4 Services of the Processor

(1) The Processor does not evaluate free texts for its own purposes, does not analyse their content and does not use them to train AI models.

(2) Free texts go to AI functions only under Annex C and depending on the settings of the Controller (level and switches, Annex C §1 paras. 5 to 8). Functions which a user triggers in the individual case (such as e-mail assistant, parent meeting, hazard AI, text and handbook drafts) transmit the selected text in full; where AI translation is switched on (Annex C §3 No. 17), this applies to the translated contents.

(3) Free texts are not technically filtered. Exceptions are the rejection of AI inputs (para. 5) and the AI data guard for texts to legal guardians and the public (Annex C §3 No. 18).

(4) Erasure periods: the internal staff chat under §3 of the DPA (notice-board contributions excepted); the history of the Autopilot chat under Annex C §1(12); recordings of meetings immediately after the evaluation; applications under §8(8). All other free texts remain stored until the Controller deletes them or the contract ends (§8).

(5) To support the Controller, the AI rejects inputs with impermissible information (Annex C §1(15)).

§5 Texts to legal guardians

(1) Some free-text fields pass their content on to legal guardians or to the public. The software marks these fields visibly for the staff and shows who receives the text.

(2) Circles of recipients:

• All: all legal guardians of the facility
• Group or care model: the legal guardians of the children of the selected groups or care models
• Child: only the devices on which this child is stored
• Public: any person, insofar as the Controller publishes content on its website. For the website, its legal notice and its privacy notice, the Controller alone is responsible (terms of use Section 9c); the Processor merely delivers them technically.

(3) Formats:

• Messages and notice-board contributions, also with poll: to all or to groups
• Message to a family (free text of the management): to the child, in the Parent App and, on request, additionally by e-mail (para. 7)
• Appointments with title, description and, where applicable, costs, also with acceptance and decline: to all or to groups or care models; on request date and title also on the website
• Closing days and closures with reason: to all
• Meal plan: to all
• Group report (daily report of a group): to the group, only after release by the staff
• Note in the child diary: to the child, only after release by the staff
• Payment items and meeting appointments: to the child
• Parent letters: per child to the stored e-mail address of the legal guardians (Annex C §3 No. 20)
• Blog posts: to all in the Parent App and to the public on the website

Push notifications relating to these follow Annex 2A §2.

(4) Upon display, the contents are passed on to the recipients; legal guardians may freely reuse them, also with their own programs and AI services (Annex 2A).

(5) The Controller instructs its staff to be extremely restrained with texts to all, to groups and to the public: no names or recognisable descriptions of other children, no health data, no information on families, conflicts or incidents concerning individual persons. Texts about one child also contain no information about other children. Messages to a family contain only what concerns that family; health information about one's own child only insofar as required for the purpose. Before sending, the Controller checks the selected child, since sending to the wrong family is a personal data breach (Art. 33 GDPR).

(6) The AI data guard (Annex C §3 No. 18) supports this; the obligations under para. 5 remain with the Controller.

(7) Message to a family. a) Dispatch: The management selects a child and writes a text; before sending, the software clearly displays the selected child. The message appears in the Parent App on the devices of this child (push under Annex 2A §2 (7)). On request of the management, it additionally goes by e-mail to the address of the legal guardians stored for the child (sender "[Name der Einrichtung] via Bienenstock", dispatch via Brevo, Annex 1; only after re-entering the admin password; entry in the dispatch log; delivery as in Annex 5 §4(2)). b) Replies: Legal guardians do not reply with free text, but only with an action specified by the management, in the app or via a time-limited link in the e-mail: "OK" (acknowledgement), "Annehmen" (accept), "Termin" (selection of a proposed date) or "Beitreten" (acceptance of an appointment of the facility). The action and its time are stored for the child. If "Annehmen" concerns a release, the grant runs exclusively via the e-mail consent under Annex 5; a reply in the app is not a grant. The software does not check beyond the knowledge of the link or access to the Parent App who has replied. c) Storage: the message and replies remain stored until the Controller deletes them or the contract ends (§4(4)).

As of: October 2026.

Annex 5: Consents, releases and authorised pick-up persons

§1 Subject matter and role of the software

(1) This annex describes the functions "Releases" (Freigaben), "Consent by e-mail" (Einwilligung per E-Mail), "Authorised pick-up persons" (Abholberechtigte), "Register pick-up person" (Abholperson anmelden) (Parent App) and "Handover record" (Übergabe-Nachweis) (group view).

(2) The software is in this respect a tool for documentation and communication. It records what the facility enters and what is confirmed via the confirmation page, and it displays notices to the staff. It makes no decision as to whether a consent is effective or whether a child is handed over to a person. These decisions are taken solely by the Controller through its staff.

§2 Releases

(1) The Controller creates releases (title and description) and determines their content alone. The software does not distinguish between consents under the GDPR, consents to measures concerning the child and other permissions. Drafts of the AI function "Mit KI formulieren" (formulate with AI) are not legal advice (Annex C).

(2) Each facility has a fixed release "Foto des Kindes auf den Geräten der KiTa" (photo of the child on the Kita's devices) with a predefined text which the Controller cannot change. Without an active grant, no photo of the child can be stored or displayed; upon withdrawal, the photo is deleted, at the latest at the daily reconciliation.

(3) A release arises by one of two routes:

a) Entry by the facility. The staff sets the tick box at the child in the administration. Stored are the time, the origin "Einrichtung" (facility) as well as the title and description in their wording at that time. A record, such as a signed declaration, is not stored; the Controller itself keeps this.

b) Confirmation by e-mail. For each child and release, the facility triggers an e-mail to the address it has stored for the child (§4). The e-mail contains the title and description and a link to the confirmation page. The link is valid for one hour and only once. Opening the page does nothing; only the click on "Freigabe erteilen" (grant release) stores the grant with the origin "Eltern" (parents), the time and the wording sent by e-mail.

(4) The confirmation fails if, until then, the title or description has been changed, the release has been archived or withdrawn, the stored address has been changed or the child has been archived. Consent is always given to the wording sent by e-mail.

(5) Upon confirmation, neither the name nor the IP address nor the device of the person who clicks is stored. The confirmation proves that confirmation was made via the stored mailbox, not which person confirmed.

(6) The legal guardians declare the withdrawal to the facility; the staff records it in the administration. Grants and withdrawals are not changed or deleted, but supplemented. If the Controller deletes a child instead of archiving it, its grants are deleted as well.

(7) Legal guardians see the releases of their child in the Parent App without possibility of change. The staff sees releases in the administration; they are not displayed in the group view and the Staff App, except for the effect of the photo release.

§3 Authorised pick-up persons and handover

(1) The facility maintains for each child a list of authorised pick-up persons (name, relationship). Persons are deactivated, not deleted.

(2) If the function "Abholperson in der App anmelden" (register pick-up person in the app) is switched on (default off), the following can be done in the Parent App:

a) a person already stored may be reported as the person collecting for one day. The facility's parent password and the child code suffice for this; no e-mail confirmation takes place;

b) a new person may be specified with name and relationship. This person is stored only when the pick-up authorisation has been confirmed via the address stored for the child in the procedure under §2(3)(b) (link valid for one hour). The authorisation reads: "Ich/Wir als Sorgeberechtigte bevollmächtigen [Name] ([Beziehung]), [Vorname des Kindes] in der Einrichtung [Name] abzuholen. Die Vollmacht gilt bis zum Widerruf gegenüber der KiTa. Die abholende Person weist sich bei der Abholung aus." (We, as legal guardians, authorise [name] ([relationship]) to collect [first name of the child] at the facility [name]. The authorisation remains valid until withdrawn vis-à-vis the Kita. The person collecting the child identifies themselves at the collection.) Stored are name, relationship, authorisation text and time of confirmation.

(3) A person so registered carries the notice "Neu – Ausweis prüfen" (new, check ID) until the staff enters "Ausweis geprüft" (ID checked) in the administration. Only the time is stored, no identity document data and not who checked.

(4) The staff learns of a reported collection without names: through an automatic notice in the internal staff chat (deleted with the chat) and on the day of collection through a notice in the group view. Name, relationship and check notice appear in the handover dialogue. No push notifications are sent for this.

(5) In the handover record, the staff documents to whom the child was handed over or who brought it, exceptionally to a person not stored, with a reason, and who confirms the handover. The entry "Bestätigt von" (confirmed by) is documentation; it is not secured by a personal login. The record is voluntary, separate from check-in and check-out, and cannot be changed or deleted.

(6) The software does not prevent a handover or a check-out, not even to a person without an identity check or without an entry in the list.

§4 E-mails to legal guardians

(1) The e-mails under §§2 and 3 go to the one address which the facility stores in the child record for the facility. They are sent in the name of the facility (sender "[Name der Einrichtung] via Bienenstock") via the e-mail service named in Annex 1.

(2) An e-mail counts as sent when the mail server has accepted it. Whether it is delivered, sorted as spam or read, the software does not learn; returned messages are not evaluated. For releases, the administration shows "wartet auf Bestätigung" (awaiting confirmation) and, after expiry, "nicht bestätigt" (not confirmed); for pick-up authorisations it shows only the confirmed person.

(3) Release requests are recorded in the dispatch log with the recipient address (§8(8)).

§5 What the software does not check

The software does not check:

a) who triggers a confirmation, and whether the mailbox belongs to a legal guardian or is accessible to third parties;

b) whether the stored address is correct;

c) the existence and scope of custody, court decisions, visitation or contact bans;

d) whether both legal guardians consent, insofar as this is required;

e) the identity of the person collecting the child;

f) the content, effectiveness and legal basis of a release, as well as the accuracy of entries by the facility;

g) who reports a collection in the Parent App and who is selected as the confirming person in the handover record.

§6 Obligations of the Controller

The Controller ensures, in particular through the organisation and instruction of its staff, that

a) release texts are legally reviewed, name purpose, scope, recipients, duration and withdrawal, and that a legal basis exists for the respective release;

b) the e-mail address stored for the child is correct, belongs to a legal guardian and is updated upon changes;

c) it checks whether the consent of both legal guardians is required for a release or pick-up authorisation, and in that case obtains it, for example by a second declaration on paper;

d) details on custody, court decisions and contact bans are taken into account outside the software or in a field designated for this purpose (Annex 4 §3(2));

e) the staff, upon every collection by a person unknown to it, checks that person's identity on the basis of an official identity document before handing over the child, and records the check in the administration;

f) the staff decides on every handover on site, independently of entries and notices of the software, and that notices of the software (chat, group view, reports) are actually read in operation;

g) entries by tick box are made only where the release is actually granted, and the evidence thereof is kept outside the software;

h) withdrawals are recorded without undue delay and authorised pick-up persons are deactivated as soon as the authorisation ends;

i) the staff knows which releases apply to a child before acting accordingly;

j) legal guardians who do not wish or are unable to use e-mail have an equivalent option on paper;

k) the parents are informed about these functions (sample notice on request);

l) children are archived rather than deleted for as long as the evidence of consents is required.

§7 Services of the Processor

(1) The Processor stores grants, withdrawals, authorisations and handover records in such a way that they cannot subsequently be changed; a grant with the origin "Eltern" (parents) can arise only via the confirmation page.

(2) It provides confirmation links with a one-time token, which is stored only as a check value and is valid for one hour, and deletes the recipient address and check value under §8(8).

(3) The Processor does not owe further services, in particular the checking of identity, custody or effectiveness, the delivery of e-mails or the prevention of handovers.

As of: October 2026.

Annex 6: Country notes

This annex names, for the Member States in which the Processor offers the software outside Germany, the bodies and provisions to which this Agreement refers as "national law of the Member State of the Controller". It creates no additional obligations. Entries marked [verifiziert] have been checked against the source named; entries marked [verify] are still open and are to be checked against the source before use.

§1 France

• Data protection supervisory authority: Commission nationale de l'informatique et des libertés (CNIL). [verifiziert]
• National implementing act: Loi n° 78-17 du 6 janvier 1978 (Informatique et Libertés). [verifiziert] Source: https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000037822923/
• Involvement of the employee representation: The comité social et économique (CSE) is informed and consulted before the introduction of means or techniques that enable monitoring of the activity of employees (information-consultation, Code du travail Art. L2312-38). [verifiziert] Source: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000035610275/
• Information of employees: No collection of data via a means that has not been made known to the employees in advance (Code du travail Art. L1222-4). [verify]
• Language: Documents which establish obligations for employees are to be drafted in the French language (Code du travail Art. L1321-6); Loi Toubon n° 94-665. [verify]

§2 Netherlands

• Data protection supervisory authority: Autoriteit Persoonsgegevens (AP). [verifiziert]
• National implementing act: Uitvoeringswet AVG (UAVG). [verify]
• Involvement of the employee representation: ondernemingsraad (OR) with instemmingsrecht (right of consent) or personeelsvertegenwoordiging (PVT) under the Wet op de ondernemingsraden (WOR). [verifiziert] Source: https://wetten.overheid.nl/BWBR0002747/
• Right of consent for systems for monitoring personnel: Art. 27(1)(l) WOR. [verify]

As of: October 2026.