Data Processing Addendum

At a glance

• Hosting and data location: databases, servers, error monitoring and the AI features (with one exception) run in the United States. Email is the one service that stays in the European Union (Section 11). Push notifications, wallet passes, optional AI image generation and the public center websites use global infrastructure (Section 10).
• Encryption: TLS 1.2/1.3 for every transfer. HTTPS only. No unencrypted interfaces.
• Separation and pseudonyms: each center's data is technically separated from every other center's. Only authorized users of the center can access it. The Parent App works without user accounts; parents use only a pseudonymous child code. On request, the whole software runs with short codes instead of real names. The AI features can be limited to codes or switched off, and an operator can set a ceiling for them (Annex 3). Technical details: Section 5.
• No selling or sharing: Beenest acts as your service provider and processor. It does not sell or share personal information and does not use it for advertising (Section 13).
• Changes: when a center belongs to an operator account, the operator is the contracting party and confirms in the operator account (desktop, not the check-in terminal). Material changes: email on the day they are published, one reminder after two weeks, a notice in the dashboard; the new processing stays technically locked until confirmed, and the rest of the software keeps working. New sub-processors: locked until confirmed (Sections 5, 9 and 15).

Parties

This Data Processing Addendum ("DPA") is entered into between the child care center, operator or other organization that accepts it (the "Customer") and Triple Peak Software Systems, a [legal form, e.g. LLC] organized under the laws of [state of formation], [registered address] ("Beenest", "we", "us").

It forms part of the agreement for the Beenest software described in the Terms of Service (the "Terms"). How Beenest handles personal information for its own purposes (for example, Customer account and billing data) is described in the Privacy Policy.

In this DPA, "personal information" means information that identifies, relates to, or could reasonably be linked with a particular person or household, as defined in applicable US state privacy laws. "Center data" means the personal information Beenest processes on the Customer's behalf when it provides the software.

1. Subject matter and duration

(1) Beenest processes center data on behalf of the Customer to provide the Beenest child care management software at [OPEN: US app domain], including the Parent App and the Staff App.

(2) Processing begins when the software agreement is concluded and lasts as long as the Customer uses the software. The software agreement is concluded when the contracting person confirms the legal documents (the Terms, this DPA and the Privacy Policy) by checkbox (details in Section 15). The software agreement expressly includes the free use option.

2. Nature and purpose of processing

Processing covers the following operations:

• Real-time check-in and check-out of children by QR code and of staff by ID or pseudonym
• Automatic capacity calculation from the recorded attendance (database trigger)
• Real-time synchronization of attendance over a WebSocket connection (Supabase Realtime)
• Management of master data, group assignments and care models
• Receiving and processing absence notices, meal cancellations and pickup notices through the Parent App API
• Receiving and processing staff reports through the Staff App (working hours, remote-work check-in, absence and sick notices, team communication; Annex 2B)
• An internal staff chat (available in the Staff App, also on personal devices; Annex 2B) with automatic deletion after the period in Section 3
• AI-supported features under Annex 3: each can be switched on and off; what the AI learns about people is set by the AI privacy level, which an operator can cap
• Publishing the center website created with the website builder at [OPEN: US domain for published center websites] through Cloudflare Pages (global delivery network, because the site is public). The Customer alone decides content and images, including photos it uploads; it obtains any consent required to publish photos of people, in particular children.
• Transmitting aggregated counts to public authorities (for example, enrollment by age group), only on the Customer's instruction; names, IDs and dates of birth are not transmitted. Very small counts can in some cases allow conclusions about individuals; the Customer decides whether to transmit. [OPEN: is authority reporting available in the US?]
• Push notifications to parents (Parent App) and staff (Staff App) through Expo and the Cloudflare push worker; details in Annex 2A, Section 2 and Annex 2B, Section 2
• Sending documents to parents by email (address stored on the child record), with a send log (which document was sent to which address and when)
• Optional meal billing per child: creating a receipt for a period and emailing it to the parent address on the child record, triggered from the operator account or the center admin; storing billing attributes and the send log
• Optional parent payments (switched on by the Customer): payment occasions and payment items per child with a reference code; display of amount, recipient account and payment QR code (GiroCode) in the Parent App; recording cash payments with the initials of the person who received them (visible on the parent's receipt); parent confirmation "transferred"; a "payment received" push where the Parent App is used and push is allowed on the device; optional membership fees with payment profiles per family and an optional invoice recipient. [OPEN: available in the US? GiroCode is an EU bank transfer format.]
• Bank connection (optional): reading the transactions of the center's bank account at the bank chosen by the Customer, read-only and under an access authorization the Customer grants (OAuth), to match incoming parent payments; alternatively, importing a bank statement file. The bank is the Customer's contractual partner and not a sub-processor. For each transaction, Beenest reads name, account number, reference, amount and booking date. It stores only amount, booking date, reference and the bank's transaction ID, and only for incoming payments that are matched or plausibly matchable and for outgoing payments the Customer assigns to an occasion; never name or account number. Outgoing payments of the last 60 days are only displayed for selection (recipient name and shortened account number), not stored. All other transactions are discarded. Bank access credentials are stored encrypted and deleted when the connection is removed. [OPEN: available in the US? Which banks? The DE version names Qonto and the CAMT.053 statement format.]
• Collecting consents and authorizations from parents by confirmed email to the address stored by the center (permissions, pickup authorization, recording of a parent meeting) through a public confirmation page; storing the confirmed text and the time as evidence
• Managing permissions per child (for example, photos, sunscreen) with a record of every grant and every withdrawal; display in the Parent App without the option to change them
• An optional photo of the child so staff can recognize the child, only while the permission "Photo of the child on the center's devices" is active; no AI; deleted on withdrawal
• Managing authorized pickup persons per child, reporting the person picking up on a given day through the Parent App, pickup authorization for new persons by confirmed email, flagging newly reported persons until their ID has been checked, and a handover record in the group view (Annex 5, Section 3)
• Meeting requests between parents and the center with proposed times, confirmation email and reminders; staff appointments for participants
• Recording a parent meeting only with consent stored in advance; evaluation under Annex 3
• Calendar with events for the center, groups or care models, RSVPs per child, optional costs per child and optional publication of date and title on the center website
• Booking rooms of the center
• Emailing a child's QR letter to the stored parent address, depending on the Customer's settings with the center's parent password
• Messages from the center to its operator and the operator's replies; an optional email copy to a distribution list set by the center; forwarding of individual messages by the operator by email to recipients it chooses, with a log
• An optional enrollment portal of an operator: applications from parents with email confirmation, handled only by the operator, automatic deletion after the periods in Section 8
• Sending and receiving technical emails through Brevo in software features (for example, invitations, system notices); email mailbox at Zoho (Section 11)
• Technical error monitoring through Sentry, including session replay of the web app (masked; details in Section 5, item 9); in addition, the application's own error logs in the center database, which may contain a person ID in context
• Reports and analyses, including spreadsheet export
• Staff time reports for directors and operators (per center and across the operator) with export, and staff access to their own hours
• Operator accounts: access to the data of the centers assigned to the operator; inviting further users to the operator account, who receive access to view and edit those centers' data after accepting the invitation
• Group messages inside the software
• Optional vendor access: the meal vendor named by the Customer can view meal notes (including allergy and diet information); the vendor is a recipient on the Customer's instruction, not a sub-processor of Beenest
• Polls in the Parent App: storing the vote with a device ID so that each device is counted once
• Storing discarded check-in actions, which are deliberately kept after the person concerned is deleted (documented retention)

Purposes of processing:

• Organizing and documenting the operation of the center with software
• Real-time recording and documentation of attendance and capacity, which the Customer can use for its safety, licensing and insurance documentation
• Communicating with parents through the app, push notifications and documents by email
• Notices to staff through the Staff App (chat, capacity light, working hours), where push is enabled
• Staff scheduling, time tracking and staff time reporting (per center and across the operator)
• Meal management, including optional information to the meal vendor named by the Customer and optional meal billing with receipts sent to parents
• Handling parent payments and membership fees, including matching incoming payments
• Collecting and documenting consents, authorizations and their withdrawal (Annex 5)
• Supporting the center in documenting pickup authorizations and handovers (Annex 5); the center decides every handover
• Organizing events, parent meetings and rooms
• Communication between center and operator
• Allocation of child care places by the operator (enrollment portal)
• AI support: purposes under Annex 3, Section 2 (subject to the level and the switches)
• Technical troubleshooting and quality assurance
• Gathering parents' views through polls (one vote per device)

3. Categories of data and data subjects

Data minimization: required and optional fields. The child's real name is not required; if it is left empty, the software shows "No name". Running the center with initials or a nickname is supported. The required fields below are needed for check-in, capacity and the care agreement. Optional fields are processed only if the Customer records them or switches on the feature they belong to.

Children

Children do not use the software. Data about children is entered by the center or by parents. Beenest does not knowingly collect personal information directly from children under 13.

Statistics and reporting fields and sensitive categories (for example, health information such as allergies or disability-related support) are optional and collected only if the center records them. Such sensitive personal information is processed separately and with a higher level of protection. The Customer is responsible for any notice or consent that applicable law requires for it. With vendor access switched on, allergies and meal notes go to the meal vendor named by the Customer (a recipient on the Customer's instruction, not a sub-processor).

Staff

Staff statistics and reporting fields are optional. Chat and pinboard: see Messages below.

Parents and guardians (through the Parent App and API)

• Pseudonymous child ID (child code)
• Absence notices (child, date; without reason), meal cancellations, pickup notices including the person picking up, date and time
• Parent email addresses and phone number on the child record (operator address for documents and meal billing receipts; center address and phone for the QR letter, consents and meeting confirmations) and the send log
• Parents' language per child (stored by the center or chosen in the Parent App) for translations under Annex 3, Section 3, item 17
• Consents by confirmed email: confirmed text, time, source; recipient address and the link's check value in the request only until confirmation; the link is valid for one hour, after which both are deleted within another hour (Section 8, paragraph 8); for permission and recording requests also an entry in the send log (child, address, type, time, triggering account)
• Meeting requests (topic, recipient, chosen time), event RSVPs, participation confirmations and "transferred" notices for payment items
• With an active bank connection: reference, amount and booking date of matched incoming payments and of outgoing payments the Customer assigns; name and account number of the payer or recipient only when read, never stored (Section 2)
• For recording a parent meeting: name and role of the consenting person, image of the signature or confirmed email, consent text
• Poll votes with device ID (one vote per device)
• Push notifications in the Parent App, where allowed on the device and used by the center: group messages, capacity light changes, event reminders, meeting times, new journal entries and payments received; details in Annex 2A, Section 2

Staff (additionally through the Staff App; Annex 2B)

• Time reports, check-in and check-out reports, sick notices
• Messages in the internal staff chat (content, timestamp, sender name or initials)
• Push notifications in the Staff App (only with permission on the device and only for features that are switched on): capacity light changes, team chat, calls, automatic working-time notices and event reminders; details in Annex 2A, Section 2 and Annex 2B, Section 2

User accounts (all roles)

• Email address, authentication data (Supabase Auth JWT), role flags
• Acceptance of this DPA and the Terms: name, email and role of the confirming person, timestamp, version number of each document including annexes, previously confirmed version; contract confirmation in the operator account or, without an operator, in the center admin. In addition, a one-time acknowledgment by the director of an assigned center (not a second contracting party, Section 15)
• Operator account: assignment to centers; invitations of further users (inviting person, invited person, timestamps, status). After accepting, these users can view and edit the data of the centers assigned to the operator
• Exchange between center and operator: messages, replies, status; the center's email distribution list (at most ten addresses); a log of every forward by the operator (recipient, note), visible only to the operator

Log data

• Every check-in and check-out with timestamp, person type and calculated capacity; for children also the care factor; for staff also the work location flag (remote, field trip, off site)
• Discarded check-in actions: deliberately kept after the person concerned is deleted (documented retention so terminal actions can be traced). Deleted or returned with the rest of the center data under Section 8
• The application's own error logs, where a person ID appears in the error context; stored in the center database, separate from error monitoring through Sentry (Annex 1, including session replay)
• Send log to parents: which document, meal billing receipt or family message was sent to which address and when
• Parents' responses to family messages: chosen action and time (Annex 4, Section 5, paragraph 7)
• Time corrections: reason (category and required free text), correcting person with email address, and values before and after; the daily summary to the operator contains only pseudonyms or initials and the reason category, no names and no free text
• Protection against password guessing: for each failed attempt a keyed hash (HMAC) of the network and the wrong value, never the address or the value itself; deleted automatically after one hour
• Evidence of parent consents (type, text, time, source)

Messages

• Group messages (content, timestamp, group)
• Internal staff chat: content, timestamp, sender (name or initials); deleted automatically after a period chosen by the Customer between one and seven days (default: one day, deleted at midnight in the center's time zone); pinboard messages stay until removed manually or the agreement ends; under the usage rules, not intended for sensitive personal information

Group reports, daily reports and notes

• Group reports (daily report of a group), notes on individual children (child journal) and reports as free text, typed or dictated; stored in the center database. Parents see an entry only if the Customer switches on display in the Parent App (default: off) and staff expressly release the entry; parents then receive a push notification without content. Dictation can be switched off (default: on). Free text may contain sensitive personal information (Annex 4).

Center metadata (optional, where configured)

• Thresholds (buffer, yellow and red capacity light), meal cancellation deadlines, opening hours, closure days, center slug, page locks of the center (admin, staff, parent and vendor passwords: shared passwords that lock individual areas of the software, not personal credentials; stored in plain text so the center can view and pass them on, checked by constant-time comparison and rate-limited against guessing), operator settings (required weekly hours, director time allowance, mentoring), required break configuration, vendor password (opt-in)

Other data subjects (where the feature is used)

• Authorized pickup persons: name, relationship to the child, source of the entry (center or parents), authorization text and time of confirmation, time of the ID check (no ID number)
• Applicants for a child care place (operator's enrollment portal): child's first name and date of birth, parent name, email address and optional phone number, preferred centers and ranking, care hours, desired start, status, operator's internal note
• Invoice recipients of membership fees: name, address, email address
• Payers of transfers to the center and recipients of transfers from the center (only with an active bank connection): name and account number only when read; only reference, amount and booking date of matched incoming payments and of outgoing payments the Customer assigns are stored
• Participants in recorded parent meetings: name, role, time and form of consent (signature or email confirmation) and what was said in the meeting (Annex 3, Section 3, item 11)
• Recipients of email copies and forwards in the exchange between center and operator: email address

AI features (depending on defaults and switches; details in Annex 3)

The AI features can be switched on and off one by one; when a feature is off, its data categories are not processed. An operator can lock features and cap the AI privacy level. Depending on the settings, the following data is processed:

• Users' free-text input as written (the interface asks users not to enter health information; free-text fields: Annex 4)
• Organization names: name of the center, group and care model names
• Key figures (capacity light, capacity, attendance by category, planned vs. actual, thresholds, opening hours)
• Records per person (attendance, events, shift and break plans, contract hours, hours balances, absence days), depending on the AI privacy level with codes, with staff names, or with staff and child names; absence reasons only as counts
• Voice recordings (dictation, email helper, parent meeting) for processing only; audio is never stored permanently
• Results of parent meetings (report, tasks, version for parents) and of the email helper (sample emails, instruction, draft)
• Consents to meeting recordings (name, role, time, text version, signature or email confirmation)
• Photos for floor plans, handbook drafts and hazard topics, and the director's own style images for the website (image understanding on the US multi-region endpoint); image generation receives only an image description without personal information
• Website details entered by the director (texts, contact details, legal notices)
• Stored results under Annex 3 (history, confirmed actions, Schedule AI change sets, daily analyses, monthly reports)
• Account-level record of the AI notice confirmation (timestamp and text version)

4. Beenest's obligations

(1) Instructions. Beenest processes center data only on the Customer's documented instructions, including the settings the Customer chooses in the software, unless the law Beenest is subject to requires otherwise. In that case Beenest tells the Customer about the legal requirement before processing, unless that law prohibits it. Beenest tells the Customer without undue delay if it believes an instruction violates applicable privacy law.

(2) Confidentiality. Beenest ensures that every person authorized to process center data is bound by a duty of confidentiality, by contract or by law. The duty continues after the engagement ends.

(3) Security. Beenest maintains technical and organizational measures that provide a level of security appropriate to the risk, taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing. The measures are described in Section 5.

(4) Sub-processors. Beenest engages no further sub-processor without the Customer's prior authorization. The sub-processors in Annex 1 are authorized when this DPA is concluded; any addition or replacement stays technically locked until confirmed (Section 9).

(5) Consumer requests. Taking into account the nature of the processing, Beenest assists the Customer with appropriate technical and organizational measures in responding to requests from individuals exercising their rights under applicable privacy laws, in particular the rights to know or access, to correct, to delete, to data portability and to opt out. If Beenest receives such a request directly, it forwards it to the Customer and does not respond on its own, except to tell the person that the request has been passed on.

(6) Assistance with security and assessments. Taking into account the nature of the processing and the information available to it, Beenest assists the Customer with its obligations regarding the security of processing, notice of security breaches to authorities and individuals, and risk or data protection assessments where applicable law requires them.

(7) Security incidents. Beenest notifies the Customer of a security incident affecting center data without undue delay and no later than 24 hours after becoming aware of it, so the Customer can meet its notice obligations under state breach notification laws. A "security incident" is a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of or access to center data. The notice contains at least, as far as known:

• a description of the nature of the incident
• where possible, the categories and approximate number of people and records affected
• a description of the likely consequences
• a description of the measures taken or proposed

Beenest provides further information as it becomes available, takes reasonable steps to contain the incident, and does not notify affected individuals or authorities on the Customer's behalf unless the Customer instructs it to or the law requires it.

(8) Deletion and return. When the services end, Beenest deletes or, at the Customer's choice, returns all center data and deletes existing copies. Details are in Section 8.

(9) Evidence. Beenest makes available to the Customer the information necessary to demonstrate compliance with this DPA and allows and contributes to reviews, including inspections, by the Customer or an auditor it appoints. Details are in Section 7.

5. Technical and organizational security measures

Beenest has implemented the measures below. They are reviewed regularly and adapted to the state of the art. They include in particular: pseudonymization and encryption; the ability to ensure the ongoing confidentiality, integrity, availability and resilience of the systems; the ability to restore availability of and access to data promptly after a physical or technical incident; and a process for regularly testing and evaluating the effectiveness of the measures.

Changes to the measures fall into two groups:

• Effective immediately, without a new checkbox: only changes that collect no new personal information and run on the same infrastructure already listed in Annex 1 (for example, patches, hardening, configuration, replacing a safeguard with an equivalent one). Beenest documents these changes. No separate consent or advance notice is required.
• Not effective immediately (material change): any change that collects new personal information, introduces a new feature that collects data, or uses infrastructure other than that already authorized. These follow the procedure in Section 15, paragraph 3 (notice, email, technical lock until confirmed).

1. Logical access control

Supabase Auth with JWT and automatic token refresh; row-level security (RLS) on all database tables; column-level security on the center table.

2. Authentication

Customer side: separate passwords per role (admin, staff, parent, vendor); the admin password with an additional short-lived server token for sensitive actions; a personal password per person in the Staff App; API key authentication for the Parent App API; server-side limits on failed attempts per network and per center.

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

3. Authorization

Customer side: RLS policies at the database level; role-based permissions with the levels operator manager, center admin and staff. Center admins and staff access only their own center's data. An operator account sees the data of the centers assigned to the operator; users invited by the operator account also get view and edit access to those centers' data after accepting the invitation. There is no access to other operators' data.

Beenest side: access to personal information only on a need-to-know basis, limited to maintenance, support and troubleshooting.

4. Transmission control

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

5. Input control

Client-side validation (Formik and Yup); server-side validation; logging of every check-in and check-out with timestamp.

6. Availability

Supabase managed database (United States, [AWS region]) with automated backups and point-in-time recovery; Vercel edge network with failover; reconnection logic with exponential backoff (2 seconds rising to 30 seconds), then retries every 60 seconds.

7. Separation

Database level: tenant separation through row-level security on all tables; each policy checks membership of the center (center ID). Column-level security on sensitive columns (for example, passwords). Blanket denial as the baseline (REVOKE ALL for unauthenticated access). Storage buckets are also protected by RLS.

Application level: the frontend uses only restricted API keys (no service role key); the service role key is used only server-side in API routes. Realtime subscriptions are filtered by RLS. Centers can see only their own data. Operator accounts (including invited users) see and edit the data of the centers assigned to the operator; there is no access across operators.

8. Pseudonymization

Optional: initials instead of real names in the display; pseudonymous child IDs (child codes) in the Parent App.

9. Error monitoring

Technical error events go to Sentry (Functional Software, Inc.) in the United States. 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 flows of the web app to reproduce errors, also on check-in tablets and the public pages for parents; text and input are masked, images and media are not recorded; where masking fails in an individual case, visible names may be included.

10. Offline operation of check-in tablets

So check-in keeps working during a network outage, the tablet keeps a working copy in local browser storage (IndexedDB): children (name, initials or PIN, group, type of care, care factor, meal attribute), staff (name, initials or PIN, group, staff type) and the status reports of the current day; bookings not yet transmitted are held until synchronization. The copy exists only on that device and is deleted on sign-out or account change. The Customer secures the devices with a device lock and device encryption.

11. Consents and evidence

A consent with source "parents" is created only through a link sent to the address stored by the center; the center can also enter permissions itself (source "center", Annex 5, Section 2, paragraph 3). The link contains a one-time token, stored only as a check value, valid for one hour and removed from error logs. Opening and confirming are separate steps, so an automatic link preview does not create a consent. The confirmed wording is stored; a changed permission invalidates open links. Granted consents cannot be changed afterwards; a consent given by parents can be written only by the server. Signatures are kept in private storage with no browser access.

12. Bank connection

Read-only access to the center's account; access tokens encrypted with AES-256-GCM, readable only server-side and deleted on disconnection; only details of matched incoming payments and of outgoing payments the Customer assigns are stored, never the name or account number of payers or recipients.

Measures that take effect immediately are documented and made available to the Customer on request. All other changes to the measures follow Section 15, paragraph 3.

6. Customer's rights and obligations

(1) The Customer decides the purposes and means of processing center data and remains responsible for the lawfulness of the processing. It decides what data is entered into the software.

(2) The Customer is responsible in particular for:

• giving parents, staff and other individuals the notices that applicable state law and its licensing rules require, and obtaining any consents required, including for sensitive personal information
• giving employees any notice of electronic monitoring that state law requires of employers (for example, N.Y. Civ. Rights Law § 52-c, Conn. Gen. Stat. § 31-48d, Del. Code tit. 19, § 705)
• carrying out any risk or data protection assessment that applicable law requires of it
• inviting further users to the operator account and the resulting grant of view and edit access to the data of assigned centers; the Customer ensures that only authorized persons are invited
• instructing its users on the content of free-text fields and checking texts before they are released to parents or published (Annex 4, Section 3)
• the obligations in Annex 5, Section 6 for permissions, consents by email, authorized pickup persons and handovers, in particular checking the identity of persons picking up, custody, and the accuracy of stored email addresses

(3) The Customer may give Beenest instructions on the type, scope and procedure of processing. Instructions are given in writing or in an electronic format. Oral instructions are confirmed in writing without undue delay.

(4) The Customer informs Beenest without undue delay if it finds errors or irregularities when checking the results of processing.

(5) Access accounts. Operator accounts and the center account are sign-in accounts with email and password. In the operator area, each account can invite further personal accounts; all accounts have the same rights (view and edit all assigned centers). There are currently no graded roles; Beenest removes an account on request. The director team shares the center account; page locks protect individual areas in addition (Section 3). The Customer:

a) sets up a separate invited account for each person in the operator area instead of sharing access;

b) keeps the circle of people who know a shared password small (center account, page locks);

c) changes shared passwords regularly, and immediately when a person leaves or a device is lost: the sign-in password through "Forgot password" on the sign-in page, the page locks in the settings;

d) reports departed persons with their own operator account for removal.

With shared access, it cannot be traced which person acted; this also affects the record of contract confirmation under Section 15, which captures the name and account of the confirming person.

7. Audits and evidence

(1) The Customer may verify compliance with this DPA and applicable privacy law. Verification can take the form of:

• requesting information and evidence
• a written questionnaire answered by Beenest
• remote audits after prior arrangement; on-site inspections are allowed where useful given the purely cloud-based infrastructure

(2) On request, Beenest provides current evidence of compliance with the security measures, in particular the certifications and audit reports of the sub-processors it uses.

(3) Effort beyond one audit per calendar year and the assistance owed by law is compensated by time spent at customary market rates.

8. Return or deletion of data

(1) Record retention obligations for center data, in particular under the Customer's licensing rules, state law, and tax or funding rules, rest solely with the Customer. Beenest stores the data only for the term of this DPA and as the Customer instructs; Beenest has no legal retention obligation of its own for center data.

(2) During the term, deletion periods follow the Customer's instructions (retention periods configurable in the software). Beenest does not delete data before the period set by the Customer ends, unless the Customer instructs it to. Individual persons (children, staff) are archived in the software rather than deleted immediately, so the Customer can meet its retention obligations; archived records are removed from day-to-day use. Beenest carries out deletion requests from individuals on the Customer's instruction by permanently deleting the records concerned, unless a retention obligation of the Customer stands in the way.

(3) The Customer can at any time, and at the latest until the agreement ends, download a complete export in a machine-readable format (CSV) and attendance records as PDF; this is the return of data. Beenest assists with all exports and data handovers and provides the export through a secure transfer method on request.

(4) Beenest deletes all center data in production systems 30 days after the agreement ends or, if earlier, 7 days after an export confirmed by the Customer. Copies in backups are overwritten by rotation no later than 30 days after the agreement ends and are not restored before then, except for restoration on instruction. Discarded check-in actions stay after an individual person is deleted (documented retention, Section 3); they are nevertheless deleted with the rest of the data under the first sentence. When deletion is complete, the Customer receives a deletion confirmation (date, scope, systems).

(5) The Customer is responsible for keeping the exported records itself for the length of its retention periods.

(6) Free use option: when use of the free option ends, paragraphs 3 and 4 apply to export and deletion.

(7) A device that Beenest provides to the Customer (for example, a tablet under the hardware policy) must be cleared of all data and reset to factory settings before it is returned. Beenest checks the reset after receiving the device and repeats it if necessary. [OPEN: the entrance tablet is not included at any price and devices are quoted separately. Are US devices loaned or sold? If sold, drop this paragraph.]

(8) Automatic deletion periods of individual features (independent of paragraph 4):

• Consent requests by email: recipient address and the link's check value are deleted on confirmation, when replaced by a new request, or at the latest about one hour after the one-hour link expires; unconfirmed requests after 30 days; confirmed requests stay as evidence. The send log of permission and recording requests stays until the Customer deletes it, at the latest until the agreement ends.
• Consents to recording a parent meeting that no recording used: after 30 days, with the signature image; used consents stay with the meeting until the Customer deletes it.
• Audio file of a parent meeting: immediately after evaluation.
• Photo of a child: on withdrawal of the permission, at the latest at the daily reconciliation.
• Applications in the enrollment portal: unconfirmed after seven days; rejected or withdrawn twelve months after closing.
• Keyed hashes of failed password attempts: after one hour.
• Invoice recipients of membership fees and messages between center and operator: until the Customer deletes them, at the latest under paragraph 4.

9. Sub-processors

(1) By concluding this DPA, the Customer authorizes the sub-processors listed in Annex 1.

(2) Any addition or replacement of a sub-processor is technically locked until the contracting person has read the updated agreement (including the changed annex) and confirmed it by checkbox. No personal information flows to the new or replacement provider before that confirmation. There is no 14-day objection period without a lock. Until confirmation, only the previously authorized sub-processors are used.

(3) Section 15, paragraphs 1 and 2 apply to the request for confirmation, the email and the reminder.

(4) Beenest ensures that each sub-processor is bound by a written contract that imposes data protection obligations at least as protective as those in this DPA, including the service provider restrictions in Section 13. Beenest remains responsible to the Customer for the performance of its sub-processors.

10. Data location

(1) Storage locations: center data is stored in the United States, with the exceptions in paragraph 2 and Section 11. As of this DPA, the sub-processors are configured as follows:

• Supabase: United States (AWS, [AWS region]): database, authentication, realtime, storage, backend functions; main location of all core data
• Vercel: United States: hosting, serverless functions
• Cloudflare: United States: API relay for the Parent App and push dispatch for both apps, and storage in Cloudflare KV (the center's parent password, center name, push tokens, device IDs with group assignment, the child IDs stored on the device (at most 20, so that child-specific notices reach only that child's devices) and, where applicable, staff ID, kept permanently; wallet passes with the child's name for up to 5 minutes); no access to the Supabase database
• Sentry: United States: error monitoring and session replay of the web app (masked)
• Google Cloud (Vertex AI / Gemini): US multi-region endpoint [OPEN: endpoint name]: all AI data flows except image generation, only with AI features switched on (Annex 3)
• Zoho and Brevo: European Union, see Section 11

The Staff App sends its requests directly to the application (Vercel, United States). Reports from both apps (absence notices, meal cancellations, pickup notices, times, check-in and check-out, sick notices, chat messages) are passed to Supabase within the United States.

(2) Global infrastructure: the following data flows can run through infrastructure outside the United States by design:

• Push notifications of the Parent App and the Staff App: through Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM) and the orchestration layer Expo, triggered by the Cloudflare push worker. Required by the Apple and Google platforms. Message content passes through only in transit and is not stored permanently; the services keep push tokens for as long as they are valid (Annex 2A, Section 4). Center data stays in Supabase. Push types and content: Annex 2A, Section 2 and Annex 2B, Section 2
• Wallet passes (digital pickup cards and staff badges, iOS and Android): to the extent Apple's and Google's wallet services are involved in displaying them; also required 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 US multi-region endpoint [OPEN: confirm for the US multi-region]; there is therefore no US residency commitment for this flow. Only image descriptions without personal information are sent (style and design details, center name, descriptions of objects); photos, names, IDs and descriptions of people are not sent. With an image generator model outside the US multi-region, the user's free text and reference images also go there; they must not contain personal information (Annex 3, Section 3, item 19). Can be switched off individually; details in Annex 3
• Center websites (Cloudflare Pages): public content is delivered worldwide; the Customer decides the content

The core product needs none of these flows. The Customer can switch them off, or not use them, at any time, as with the other AI features.

11. Email processing in the European Union

All Beenest services for US customers are configured for US regions except email. Two providers handle email in the European Union:

• Brevo sends and receives the emails the software produces: invitations and system notices, consent and pickup authorization requests, QR letters, documents and meal billing receipts, parent letters, email copies of family messages, meeting confirmations, daily analyses and monthly reports, copies and forwards in the exchange between center and operator, and the contract documents under Section 15. Hosting in France and Germany, storage at Google Cloud in Belgium.
• Zoho (Netherlands) hosts Beenest's mailbox, which receives and stores email correspondence, for example replies and support requests from Customers.

The data involved is email addresses and the content of those emails. Center data otherwise stays in the United States. [OPEN: state the reason email stays in the EU, if you want one in the text.] [OPEN: confirm Brevo stays in the EU as part of "mail".]

12. Liability

Each party is liable for damage caused by its own breach of this DPA or of applicable privacy law. Beenest is responsible for the acts and omissions of its personnel and of the sub-processors it engages as for its own. Liability under this DPA is subject to the limitations of liability in the Terms. [OPEN: should DPA liability be capped by the Terms, carved out, or subject to a separate cap?]

13. US state privacy laws: service provider and processor terms

(1) Role. For center data, the Customer is the business or controller and Beenest is its service provider or processor within the meaning of the California Consumer Privacy Act as amended by the California Privacy Rights Act (Cal. Civ. Code § 1798.100 et seq., "CCPA") and comparable applicable US state privacy laws. This Section sets out the contract terms those laws require (in particular Cal. Civ. Code § 1798.100(d), § 1798.140(ag) and 11 CCR § 7051).

(2) Limited purposes. The Customer discloses center data to Beenest only for the limited and specified business purposes described in Sections 1 and 2 and Annexes 2A to 5: providing, securing, maintaining and troubleshooting the software for the Customer.

(3) Restrictions. Beenest will not:

a) sell or share center data, as "sell" and "share" are defined in the CCPA;

b) use center data for targeted advertising or cross-context behavioral advertising;

c) retain, use or disclose center data for any purpose other than the business purposes in paragraph 2, including any commercial purpose, or as otherwise permitted by the CCPA and its regulations;

d) retain, use or disclose center data outside the direct business relationship between Beenest and the Customer;

e) combine center data with personal information it receives from or on behalf of another person, or collects from its own interaction with an individual, except as permitted by the CCPA and its regulations (for example, to perform the business purposes for the Customer).

(4) Compliance and equal protection. Beenest complies with the obligations that applicable US state privacy laws impose on service providers and processors and provides the same level of privacy protection to center data that those laws require of the Customer.

(5) Notice if Beenest can no longer comply. Beenest notifies the Customer without undue delay if it determines that it can no longer meet its obligations under applicable US state privacy laws.

(6) Customer's right to stop unauthorized use. The Customer may take reasonable and appropriate steps to ensure that Beenest uses center data in a manner consistent with the Customer's obligations, and, upon notice, to stop and remediate any unauthorized use of center data, including under Section 7.

(7) Processor duties under other state laws. In addition to Section 4, Beenest:

• assists the Customer in responding to consumer rights requests and in carrying out data protection assessments (Section 4, paragraphs 5 and 6);
• ensures that each person processing center data is subject to a duty of confidentiality (Section 4, paragraph 2);
• engages sub-processors only under a written contract that requires them to meet Beenest's obligations for center data, and only after the Customer's confirmation (Section 9);
• deletes or returns all center data at the end of the services, unless retention is required by law (Section 8);
• makes available the information necessary to demonstrate compliance and allows reasonable assessments (Section 7).

(8) De-identified data. Beenest does not attempt to re-identify de-identified data it receives from the Customer. [OPEN: does Beenest create or use de-identified or aggregated data from center data for its own purposes (for example, product statistics)? If yes, describe it here with the required commitments.]

(9) Certification. Beenest certifies that it understands the restrictions in this Section and will comply with them.

14. Specific US laws

(1) FERPA. FERPA generally does not apply to child care centers. If the Customer is an educational agency or institution subject to the Family Educational Rights and Privacy Act, then for education records Beenest acts as a "school official" with a legitimate educational interest within the meaning of 34 CFR § 99.31(a)(1)(i)(B): it performs a service the Customer would otherwise use its own employees for, is under the Customer's direct control with respect to the use and maintenance of education records, and uses personally identifiable information from education records only for the purposes of this DPA and does not re-disclose it except as FERPA permits or the Customer instructs.

(2) Children. The software is not directed to children, and children do not use it. Beenest does not knowingly collect personal information directly from children under 13.

(3) HIPAA. Beenest is not a business associate and does not sign business associate agreements. The Customer does not use the software to process protected health information on behalf of a covered entity. [OPEN: confirm]

(4) Biometrics. Beenest does not collect biometric identifiers such as face geometry or fingerprints. The optional child photo is shown to staff for recognition only and is not processed by AI or face recognition. [OPEN: confirm, matters for Illinois BIPA]

15. Conclusion and acceptance

(1) This DPA is concluded by an active confirmation (checkbox) in the authenticated account of the contracting person. The contracting person is the person signed in to the account who acts for the Customer. Who the contracting party is depends on how the center is assigned:

• Center assigned to an operator: the operator alone is the contracting party and the Customer. The person signed in to the operator account confirms with a checkbox that cannot be bypassed in the admin interface (desktop). Check-in terminals do not show this dialog. The director of the assigned center may be asked once to acknowledge 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 lock.
• Center without an operator: the center director confirms in the admin for the Customer. The acceptance dialog appears in the center admin only in this case, again not on check-in terminals.

Every contract confirmation and every acknowledgment is stored with name, email, role (operator account or center director), type of action (contract or acknowledgment), timestamp, the version number of this DPA including its annexes (Annexes 1, 2A, 2B, 3, 4 and 5) and the previously confirmed version.

(2) On the day a new version is published and with every confirmation under paragraph 1, the contracting person receives the complete documents by email: this DPA with all annexes in the relevant version and, after confirmation, the confirmation records (name, email, role, timestamp). The emails also contain download links to the same versions. The same version can be downloaded, viewed and saved on the website at any time (print function). No separate paper copy is mailed. Pending confirmations and changed versions are shown in the dashboard of the contracting person (operator dashboard if assigned to an operator, otherwise the center admin) and presented at the next sign-in to the admin interface. If confirmation is still pending after two weeks, one reminder follows by email. No further reminder emails are sent. Assigned centers remain usable in the meantime.

(3) Material changes to this DPA including its annexes (new data points, a new feature that collects data, infrastructure other than that already authorized, and any other change not covered by paragraph 4) are shown to the contracting person in the dashboard and sent by email on the day they are published, as a rule at least 14 days before the intended start. The feature or changed processing concerned stays technically locked until the contracting person has agreed by checkbox. The rest of the software remains usable; personal information flows into the new processing only after this confirmation. Until then the previously confirmed version applies. If the change concerns a new or replacement sub-processor, the technical lock under Section 9, paragraph 2 also applies.

(4) No update procedure (no checkbox, no email, effective immediately) applies to:

• Clarifications of the description in this DPA and its annexes: wording that describes an already agreed processing more precisely (for example, naming specific fields, storage locations or flows that are already part of the agreement), and corrections of typos and cross-references. Clarifications change neither subject matter, purpose, type of data or data subjects, nor sub-processors, storage locations, the level of protection of the security measures or the rights and obligations of the parties. Each clarification is documented with its date; the current version is available at /dpa.
• Changes to the security measures under Section 5 that collect no new personal information and run on the same, already authorized infrastructure

As soon as a clarification or a change to the measures concerns new data points, a new feature that collects data or other infrastructure, paragraph 3 applies.

(5) The checkbox in the system is the standard procedure for paragraphs 1 and 3. A handwritten signature is not required. The parties agree that the electronic confirmation is an electronic signature under the Electronic Signatures in Global and National Commerce Act (15 U.S.C. § 7001 et seq.) and applicable state electronic signature laws, and that the electronic confirmation together with the email under paragraph 2 satisfies any requirement that this DPA be in writing.

16. Final provisions

(1) Changes and additions to this DPA must be made in writing; Section 15, paragraph 5 satisfies this. Procedure and exceptions are in Section 15, paragraphs 3 and 4.

(2) If any provision of this DPA is held invalid or unenforceable, the rest of the DPA remains in effect. The invalid provision is replaced by a valid one that comes closest to its intended purpose.

(3) This DPA is governed by the laws of [governing state]. The courts of [county and state of the courts] have exclusive jurisdiction. [OPEN: arbitration?]

(4) Order of precedence. If this DPA and the Terms conflict on any matter relating to the processing or protection of personal information, this DPA prevails.

(5) Questions about this DPA: [privacy contact email] or hello@beenest.co.

Annex 1: Sub-processors

Beenest uses the following sub-processors, including those for the Parent App and the Staff App. A separate data processing agreement is in place with each, except Apple (see the note below). Center data is stored in the United States; the exceptions are email (Section 11) and the global flows in Section 10, paragraph 2, including optional AI image generation (Annex 3, Section 1, paragraph 2).

Banks whose accounts the Customer connects to read transactions (Section 2, bank connection) are the Customer's contractual partners and not sub-processors. Payment of subscription fees by card is handled by Stripe, Inc. (United States); Stripe receives only the Customer's contract and payment data, no center data, and is not a sub-processor.

New or replacement sub-processors are used only after the contracting person has read the agreement and confirmed it by checkbox (Section 9, paragraph 2).

Annex 2A: Parent App (iOS and Android)

This annex governs processing in the optional Parent App (iOS and Android). It applies if the Customer uses the Parent App as an extension of the core product; the app is not required to use the core product. Beenest provides a prompt in the Parent App for parents to accept the app's privacy notice (Parent App Privacy Notice) and terms of use. Any further notice or consent that applicable law requires is the Customer's responsibility and decision. Sections 4 and 5 of this annex (push services, wallet, sub-processors) also apply to the Staff App (Annex 2B).

1. Voluntary use

(1) Use of the Parent App is voluntary and not a condition for receiving care. Not using it has no effect on the care agreement or the quality of care.

(2) All information provided through the app is also available in other ways (for example, a notice board or in person).

(3) The Customer decides whether it relies on parental consent or another basis for processing through the Parent App. If it relies on consent, consent can be withdrawn at any time without disadvantage. Independently, parents accept the app's privacy notice and terms of use in the app; they receive push notifications only after granting permission on their device.

2. Nature and purpose of processing

Processing covers:

• Push notifications on iOS and Android (types below)
• Absence notices, meal cancellations, pickup notices
• Poll votes (one vote per device; device ID used only to prevent duplicate votes)
• Display of the child journal and group report
• Wallet pass (digital pickup card)
• Display of authorized pickup persons (name, relationship) on every device on which the child code is stored, and reporting a person picking up (including a new person, who is stored only after confirmation by email; Annex 5, Section 3)
• Meeting requests and choosing a proposed time
• Center events with RSVP per child
• Display of the own child's permissions (no option to change them)
• Display of open payment items with recipient account and payment QR code (GiroCode), participation confirmation, "transferred" notice; reminders as local device notifications [OPEN: available in the US?]
• Blog posts of the center

Not processed: check-in and check-out times of children. These are recorded only at the terminal in the center.

Data minimization: the Parent App is designed to use 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 adds a new authorized pickup person, that person's name and relationship to the child are transmitted. The app collects no location data, does not access photos, contacts or microphone, and contains no analytics or tracking tools; the camera is used only to scan the child code. Center data is not stored on the device but loaded from the US database on each request. Only the access to the center, the child codes and the parent's own responses remain on the device, and for the offline calendar the center's closure days and closures and its dated messages from the current month on (title, text, group). If parents use the app in another language, center content (messages, blog, journal 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 capacity light, center messages and center status; it is served by the application (Vercel, United States, Annex 1).

Push notifications: all types are sent as Expo push through the Cloudflare push worker. Center data stays in Supabase. Delivery on iOS and Android is not possible without transit through APNs, FCM and Expo. The push services do not store message content permanently (transit for delivery only). Free text is not technically filtered.

(1) Group message. Recipients: Parent App devices of the center, filtered by the groups stored at registration. Center-wide messages go to all registered devices of the center. Content: title = message title, text = message text, each as written by staff; the center name is placed before the title. Intended for organizational information, not sensitive information about children.

(2) Capacity light change. Recipients: Parent App and Staff App devices. Only on a change to yellow (fixed text: "Center close to its limit") or red (fixed text: "Center at full capacity"). No push for green. Suppressed on closure days and outside opening hours. The center can switch off yellow and red for the Parent App individually (default on); Staff App devices always receive both.

(3) Event reminder. Recipients: devices of the group or the center. Content: "Event: [title]" or "Today: [title]" and date and time; no names of children or groups.

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

(5) New journal entry. Recipients as in (4). Fixed title "New note" or "New group report", no text.

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

(7) Family message. Recipients as in (4). Fixed title "New message" with the center name, no text; the app loads the content from the US database. Response actions (Annex 4, Section 5, paragraph 7) go through the encrypted API, not through push.

Absence notices, meal cancellations and pickup notices go through the encrypted API (Cloudflare worker to Supabase), not through push payloads. The push notification is the trigger; the app loads content from the US database.

Further use by parents. Content the Parent App shows to a parent is disclosed to that parent by the display. Parents may use it freely, including with their own programs or AI services; they are responsible for that further use, and the service they choose is neither a sub-processor nor a recipient of the Customer. The Customer takes this into account for content sent to parents (Annex 4, Section 3, paragraph 4 and Section 5).

3. Categories of data

• Pseudonymous child ID (child code), center ID
• Absence notices (child, date; the app does not ask for a reason)
• Meal cancellations, pickup notices (with optional note)
• Poll votes with device ID (purpose: one vote per device)
• Child journal entries about the own child and group reports (display only)
• Wallet pickup card: name or nickname of the child, child code, center, address, group
• Device push tokens (pseudonymous) with group assignment and stored child IDs
• Push payloads of types (1) to (7) in Section 2
• Pickup persons (name, relationship), meeting requests (topic, chosen time), event RSVPs, participation and payment notices, permissions (display only)

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

The Parent App and the Staff App use Cloudflare, Expo, Google (Firebase Cloud Messaging, Google Wallet) and Apple (APNs), listed in Annex 1. A separate data processing agreement is in place with Cloudflare, Expo and Google.

Note on Apple (APNs): Apple does not offer a data processing agreement for the Apple Push Notification service. The contractual basis is the Apple Developer Program License Agreement, including Attachment 1 (Additional Terms for Apple Push Notification Service and Local Notifications). APNs is iOS platform infrastructure; iOS push is not possible without it.

APNs, FCM and Expo have no contact with the Supabase database of the main application. Message content is not stored there permanently. What Cloudflare stores in Cloudflare KV is listed in Section 10, paragraph 1; Cloudflare has no access to the Supabase database. If the Customer or the parents do not enable push notifications and wallet passes, Expo, Firebase Cloud Messaging (Android) and Apple Push Notification service (iOS) are not used as sub-processors. The prerequisite is that the push permission request (iOS or Android) is declined on the device. KV storage of the parent password remains as long as the Parent App is enabled for the center.

What "transit only" means: for APNs, FCM and Expo, "transit only" refers to the message content (push payload, wallet content). The push services do not store it permanently; they process it only for the duration of delivery (in memory or queue structures, not in databases). The device tokens themselves (APNs device tokens, FCM registration tokens, Expo push tokens) are processed and stored by the push services for as long as the token is valid, because delivery is otherwise not possible. This token storage is part of the platform infrastructure and not part of the processing of center data itself.

No technical alternatives: no provider-independent push infrastructure for iOS and Android exists at the platform level. APNs is the only permitted delivery route for iOS push, FCM the only permitted route for Android push. Relocating these services or avoiding token storage at the push services cannot be configured or prevented at the application level. Expo is used only as an orchestration layer between the app and APNs/FCM, to allow a platform-independent implementation.

User opt-in: APNs, FCM and Expo process data only after the user expressly enables push permission through the operating system's permission prompt (iOS or Android). This applies to parents in the Parent App and staff in the Staff App. Anyone who downloads the Staff App and grants the permission on the device thereby agrees again to delivery on that device. If the user declines the permission or withdraws it later in the device settings, no further tokens are created or sent to these sub-processors. Center data stays in Supabase; transit through APNs, FCM and Expo is technically the only way to deliver on iOS and Android.

Role of Cloudflare: Cloudflare relays API requests of the Parent App and push dispatch of both apps (edge routing, TLS termination, DDoS protection) and stores the data listed in Section 10, paragraph 1 in Cloudflare KV. The child journal and group report are passed through Cloudflare to the Parent App and not stored there. Cloudflare has no access to Beenest's Supabase database. API transit and KV are configured for the United States.

5. Reference

In all other respects, the provisions of this DPA apply.

Annex 2B: Staff App (iOS and Android)

This annex governs processing in the optional Staff App for the center's staff. It applies if the Customer uses the Staff App. Sections 4 and 5 of Annex 2A apply to push services, wallet and sub-processors. Staff are informed in the Staff App Privacy Notice.

1. Basis and voluntary use

(1) Processing takes place within the employment relationship between the Customer and its staff. The Customer is responsible for the notices to employees that applicable law requires, including notices of electronic monitoring (Section 6, paragraph 2), and for the handling of sick notices and other health information under applicable law.

(2) Use of the Staff App is voluntary for staff. Working time in the center is recorded at the terminal; absences and messages are also possible without the app. Not using the app must not lead to any disadvantage.

2. Nature and purpose of processing

• Own working hours and overtime balance; remote-work check-in with work category; adjustment requests
• Absence and sick notices
• Team daily plan
• Internal staff chat, pinboard and polls; messages to parents (after entering the password again)
• Inbox: direct messages from the director to an individual person, replies to working-time requests and own upcoming staff appointments
• Wallet staff badge
• Push notifications: capacity light (Annex 2A, Section 2) and team chat, calls, automatic notices, event reminders, inbox, working-time confirmation and end of care hours (see below)

Data minimization: the Staff App is designed to use as little data as possible. It collects no location data, does not access photos, contacts or microphone, and contains no analytics or tracking tools; the camera is used only to scan one's own QR code at sign-in. What the app shows about children depends on the privacy mode (Section 4, paragraph 1a): in "Personal phones" mode it shows no master data of children, only counts; in "Center devices" mode it may show names of children in the person's own group where a feature needs them. It shows child codes in neither mode. Free text from colleagues or the director and the topic of a meeting named by parents may contain information about children in both modes. Center data is not stored on the device but loaded from the US database on each request; only the session tokens remain on the device, in protected device storage. A session is valid for at most 30 days.

Data path: Staff App requests go encrypted directly to the application (Vercel, United States, Annex 1) and from there to Supabase, not through Cloudflare. Push notifications go through the Cloudflare push worker (Annex 2A).

Team chat, calls and notices. Recipients are only Staff App devices. The Customer can switch off the team chat in the Staff App (default on).

• Chat push: title = name of the author, text = chat text (shortened). Recipients depending on the tag: the whole team, the staff of a group or the persons mentioned; no push without a tag. This includes posts the director confirms through the Autopilot.
• Time corrections from the Staff App go to the director as an adjustment request, not into the team chat; the feature exists only if clocking in and out in the app is switched on.
• Calls: push "[name] is calling you" with a reason, only to the person called, who must be checked in.
• Automatic notices (sender "Automatic notice"), each rule switchable in the chat settings. Defaults: required break off, "daily working time reached" on, "scheduled but not here" on (only with staff scheduling active). "Not checked out" serves complete attendance documentation and cannot be switched off. The notices name the person concerned and are visible in the team chat. The push for required break, "daily working time reached" and "not checked out" goes only to the person concerned; for "scheduled but not here" to the staff of the group.
• Event reminders name only type, time and group.
• Inbox: the director writes a direct message to an individual person in the web app; only that person reads it in the Staff App. Sending and deleting require the admin password. No reply function, no email. Messages stay stored until the Customer deletes them; there is no automatic deletion. Push "New message in your inbox" without sender and without content.
• Working-time confirmation: push to the person after clocking in, out or switching in the app, with event and time, without names.
• End of care hours: from November 1, 2026, once a day shortly after closing time, to the persons still checked in to care (not to housekeeping staff), with a fixed text without names.

The content is intended for organizational and working-time information, not sensitive information about children. Team chat messages from the Staff App are checked before sending only by the AI data guard, if the Customer has switched it on for the team chat (Section 4, paragraph 1a; Annex 3, Section 3, item 18); other free text is not technically filtered.

Staff who install the Staff App grant push permission themselves on the device and can withdraw it at any time in the device settings. Center data stays in Supabase.

3. Categories of data

• Name or initials, staff ID, sign-in data (QR code and personal password, session tokens)
• Own working hours and overtime balance, remote-work check-in, adjustment requests
• Absence and sick notices (reason and optional note; health information)
• Team daily plan: names, shifts, breaks and current attendance of colleagues; absence reasons only for the person's own absences
• Chat messages (content, sender name or initials), pinboard posts, poll votes, messages to parents
• Inbox: direct messages from the director (recipient, title, text, time)
• In "Center devices" mode: names of children in the person's own group, only for display in features that need them; not stored on the device, not passed to AI features
• Wallet staff badge: name, staff ID, group
• Device push tokens (pseudonymous, linked to the staff ID); push content under Section 2
• Calls (calling and called person, reason, answer and time), @mentions
• Hazards: notes with author, warning triangles and "thumbs up" per person; preview image of a topic under Annex 3, Section 3, item 15
• Room bookings with the booking person
• Calendar: center events and own staff appointments
• Questions to the AI helper, if switched on (transmission only, no storage; Annex 3, Section 3, item 4)

4. Settings, devices and Customer obligations

(1) Settings. The Customer decides in the settings which Staff App features are used. Defaults: Staff App, team chat, clocking in and out in the app and messages to parents on, each can be switched off; daily plan and team week only with staff scheduling active (default off); team chat retention 1 day (selectable 1 to 7); automatic notices under Section 2; AI helper off (Annex 3, Section 3, item 4); privacy mode "Personal phones"; AI data guard in team chat off. The settings are instructions within the meaning of this DPA.

(1a) Privacy mode. The Customer chooses one of two modes for the center; the mode applies to all devices signed in to the Staff App.

a) Personal phones (default): the app shows no data about children, only counts; features that need children's names are locked. Free text must not contain names or recognizable descriptions of children. Beenest recommends switching on the AI data guard in the team chat.

b) Center devices: by choosing this mode, the Customer declares that the app runs only on its own devices, and chooses it only in that case. The app may show names of children in the person's own group where a feature needs them; as of this DPA no feature does so yet, the first planned is requesting a parent meeting. In the team chat, children may be named where needed for the daily routine; health information, information about child protection cases or custody does not belong there either. Beenest recommends the AI data guard in the team chat in this mode too.

The AI data guard in the team chat works the same in both modes (Annex 3, Section 3, item 18). The Customer gives staff the rules for free text under paragraph 4.

(2) Devices. The Staff App can be used on the Customer's devices and, where the Customer allows it, on staff members' personal devices. Beenest recommends using it only on center-owned devices. The app does not access private content on the device (Section 2). Beenest provides no device management (MDM) and can neither see devices nor wipe them remotely.

(3) Personal devices. If the Customer allows personal devices, it sets the conditions in advance (for example, a written policy). It ensures that use is voluntary, that an equivalent alternative exists (terminal, center device or report to the director), and that not using the app leads to no disadvantage.

(4) Information. The Customer informs staff before first use, including the chosen settings, and points out their duties of care: screen lock, not sharing password and badge, signing out on shared devices, reporting loss without delay, no health information in free text and information about children only under paragraph 1a, no screenshots and no passing on of content.

(5) Shared center devices. Sign-in is personal and valid for up to 30 days; there is no automatic sign-out. The Customer sets rules for signing out after use.

(6) Employee monitoring. Some features are capable of monitoring behavior or performance, in particular recorded working hours and hours balance, the daily plan with current attendance, switched-on automatic notices, calls with answers, polls with personal votes, a switched-on AI helper with names for directors, and time tracking, Schedule AI, daily analysis, operator Autopilot and the attendance patterns of the AI features (Annex 3, Section 1, paragraph 14). If the Customer introduces the Staff App or any of these features, it gives any notice of electronic monitoring that state law requires (Section 6, paragraph 2), observes any applicable collective bargaining agreement, and sets the switches under paragraph 1 accordingly.

(7) Departure. When the Customer archives a person, the software ends all of that person's sessions (an access token already issued remains valid for at most 15 minutes), deletes their app password and unregisters their devices from push; their staff badge is no longer accepted at the terminal.

(8) Lost device. The Customer replaces the person's QR badge in the admin; this has the same effect as paragraph 7. Beenest assists on request.

(9) Lock screen. Push content may be visible on the lock screen and remain in the notification center; staff can switch off previews in the device settings.

5. Reference

In all other respects, Annex 2A, Sections 4 and 5 and the provisions of this DPA apply.

Annex 3: AI features

This annex governs processing in the AI features. They are available in the admin interface (web app), the operator area, on the group tablet (voice dictation) and, only if the center switches it on, as the AI helper in the Staff App; if someone creates a hazard topic in the Staff App, its preview image is created under Section 3, item 15. There are no AI features at the check-in terminals; in the Parent App only AI translation (Section 3, item 17), and only if the center has chosen the level "All". The AI features can be switched on and off one by one; when a feature is off, its data flows stop. How much the AI learns about people is set by the AI privacy level (Section 1, paragraph 5). An operator can lock features for all its centers and cap the level; the centers cannot override this. The software is fully usable without AI features. [OPEN: confirm the English UI names of the levels, switches and features named in this annex.]

1. Common terms

The following terms apply to all data flows in Section 3 unless stated otherwise there. They are set out here once and not repeated for each flow.

(1) Sub-processor: Google LLC / Google Cloud (Vertex AI / Gemini). The contractual basis is the Vertex AI data processing addendum. Authentication is without API keys, through Workload Identity Federation (Vercel OIDC); local development through Application Default Credentials (ADC). Hosting of the calling application: Vercel (Annex 1).

(2) Data residency: all data flows except image generation run through the US multi-region endpoint [OPEN: endpoint name]. Processing is contractually limited to the US geography (no single-region pinning). Exception image generation: Google does not provide image models on the US multi-region [OPEN: confirm for the US multi-region]. This flow uses the global endpoint; there is no US residency commitment for it. The global endpoint receives only image descriptions without personal information (style, color and design details including the center name, and a description of objects without people created beforehand on the US endpoint); photos, the center's free text, names, IDs and descriptions of people do not go to the global endpoint. By way of exception, with the image generator model outside the US multi-region, the user's free text and reference images go to the global endpoint (Section 3, item 19). The exception is also named in Section 10 of this DPA.

(3) Models (as of October 19, 2026), all through Google Cloud (Vertex AI): text and understanding gemini-3.8-flash; fast tasks such as dictation, translation and checks gemini-3.5-flash-lite and gemini-3.1-flash-lite; Claude Haiku 5.5 by Anthropic (claude-haiku-5-5, in Google Cloud's Model Garden; Google remains the contractual partner); image generation gemini-3.1-flash-image and gemini-3.1-flash-lite-image (global). [OPEN: confirm each text model is available on the US multi-region endpoint.] A switch to another model of the same sub-processor on the same endpoint is documented as a clarification under Section 15, paragraph 4.

(4) No training: inputs are not used to train AI models (Vertex contract terms). Storage at Google: Google generally does not store inputs permanently. If automated safety filters detect suspected abuse, Google may store the prompts concerned solely for abuse review for up to 90 days, in the multi-region chosen for the project (United States).

(5) AI privacy level: how much the AI learns about people is set by a level with three values: a) "Off": Autopilot (including Schedule AI, "Custom export" and daily analysis) and the Staff App AI helper are switched off; b) "Pseudonymized": children and teachers appear only as codes (for example, "Child 7F3A", "Teacher K2QM"); c) "All": real names of teachers and children. The center chooses its level in the settings; the default is "All". Anyone switching from a lower level to "All" confirms this separately. The Customer checks before use whether the default meets its requirements and otherwise chooses a lower level. The operator can set a maximum level for all its centers; the lower of the two levels always applies. Without a maximum level, there is no cap. If the software cannot read an operator's maximum level, it works with "Pseudonymized". Regardless of the level, absence reasons and other health information never go to the AI linked to a person, only as counts.

(6) Scope of the level: the level applies to the features that read the software's operating data: Autopilot chat, "Custom export", Schedule AI, daily analysis, Staff App AI helper and, per center, operator Autopilot and monthly report. Schedule AI and the AI helper for directors run only at the level "All"; the AI helper for teachers always works with codes at every level except "Off". The level does not apply to features that process only what users themselves type, say or upload (for example, dictation, email helper, parent meeting, text drafts, floor plan, website); these are controlled by their own switches (paragraph 8). What the team writes itself (in particular team chat, pinboards, notes and events) is read by the AI as written, including any names in it, at every level except "Off".

(7) Pseudonymization and control: Beenest creates codes before transmission from the person's internal ID with a secret key. The same person always has the same code; Google cannot infer the person from it. Only Beenest knows the mapping of codes to names; it is stored with the history (paragraph 12) so that authorized users see the answer with names. Pseudonymized data remains personal information. Google sees inputs only transiently, subject to abuse review under paragraph 4. Users control free text and uploads; the interface asks them not to enter health information, but whatever is entered or uploaded is transmitted. The Customer instructs its users accordingly. Buttons that trigger an AI feature are marked consistently in the admin interface (purple with a sparkle icon).

(8) Switches: in addition to the level, the center can switch off individually: the website builder, voice dictation (and with it the email helper, parent meeting, parent letters and AI text drafts), floor plan from photo, AI translation (Section 3, item 17) and the AI data guard (Section 3, item 18). Image generation and the Staff App AI helper run only after the center switches them on. The operator can lock individual features for all its centers, lock all features with processing outside the US (currently image generation including preview images for hazard topics and the image generator models outside the US multi-region) and switch off the monthly report. If the software cannot read an operator lock, the lock is treated as set. An operator maximum level of "Off" switches off the features in paragraph 6, first sentence, not the features controlled by their own switches. The help chat and the DPA chat, which process no operating data, cannot be switched off. Features that work only when a user expressly calls them transmit nothing while unused. The hazard AI and the handbook draft currently have no switch of their own. Beenest can switch off individual AI features at any time for security or operational reasons.

(9) Carrying out results: AI results are suggestions and drafts. Actions proposed by the Autopilot (for example, a message to parents, a team chat post, break planning or a check-out) are carried out only when the director confirms each one individually after authenticating with the admin password. Exception Schedule AI: on the instruction of the person planning, it changes the schedule directly; every change is marked, logged and can be undone. No AI result is sent without a user action; the exceptions are the daily analysis and the monthly report, which go by email to the director or the operator users.

(10) Automatic processes: as a rule, a call happens only on a user action. Exceptions: the daily analysis, the monthly report and the preview image of a newly created hazard topic.

(11) Notice dialog: before first use of Autopilot chat, Schedule AI, "Custom export", help chat, operator Autopilot and DPA chat, an account-level notice dialog appears; the confirmation is stored with its version in the user account. The dialog serves transparency and is not a consent.

(12) Storage at Beenest (servers in the United States): a) history of Autopilot chat and Schedule AI: per user, center and day, at most 60 entries; deleted automatically after a period chosen by the center of one to seven days (default: at the end of the calendar day, in the center's time zone). "Custom export", help chat, DPA chat, operator Autopilot and the Staff App AI helper are not stored. b) Confirmed Autopilot actions and Schedule AI change sets (with the state before the change): until deletion under Section 8. c) Daily analyses and monthly reports: until deletion under Section 8. d) Email helper (sample emails, instruction, result), parent meetings (report, tasks, version for parents) and consents to recordings including signature: until the center deletes them, at the latest under Section 8. e) For each AI call, a usage record without content (center, operator, feature, model, quantities) to account for AI credits. f) Translations under Section 3, item 17 with a check value of the original, without the original: at most 30 days. Whether entries under a) to c) contain names or codes depends on the effective level (paragraph 5). Audio is never stored permanently: dictations go directly to the AI; recordings of parent meetings are kept in protected storage only until evaluation is complete and then deleted, even if evaluation fails. Photos for floor plans and handbook drafts, images and reference images of the image generator, and uploaded documents and generated letters of the parent letters feature are not stored; cleaned letter templates stay stored until the center deletes them (Section 3, item 20). Technical errors go to Sentry (Annex 1) without chat, prompt, audio or image content.

(13) AI credits: AI features use monthly or one-time AI credits of the center or operator. AI credits are not money; one-time credits do not expire. When the credits run out, AI pauses and the software refuses further calls; more credits are available only after the Customer agrees and are never billed automatically. The help chat and DPA chat are free and exempt; automatic processes (paragraph 10) are not blocked.

(14) Purpose limitation for employee data: the software processes staff attendance, working-time and schedule data for three purposes: meeting supervision duties and staff-to-child ratios to protect the children, time tracking and payroll, and compliance with working-time law. For staffing plans, the AI features can describe attendance patterns, including for individual employees (for example, usual arrival times or frequent absences on certain weekdays). They do not assess performance or behavior: no judgments, no rankings, no comparisons between people, no assumptions about reasons or health. Schedule AI plans from contracts, absences, qualifications and need. The Customer remains responsible for employee notices and any collective bargaining obligations (Annex 2B, Section 4, paragraph 6) and can set the AI privacy level accordingly.

(15) Protection for inputs: what users enter into AI features is the responsibility of the Customer and its staff (Annex 4, Section 3). As an additional technical safeguard, the AI is instructed not to process inputs containing certain information. Instead, it points out the error and stops, without repeating the information, calling tools or proposing actions:

a) always: health information about children or staff and other sensitive personal information, suspected child protection cases, information about custody, court orders, protective orders and family conflicts, credentials (passwords, PINs, QR and child codes), bank, ID, tax and Social Security numbers, and assessments of individual employees (paragraph 14);

b) depending on the effective AI privacy level: at "Pseudonymized", names of employees and children; in the Staff App AI helper for teachers, always names;

c) depending on the feature: in the help chat and DPA chat, any information about real people; in website and permission drafts, names and descriptions of individual children.

Voice dictation (literal conversion into text) and the evaluation of recorded parent meetings are excluded. A stopped input is not stored. It has, however, already reached the AI at that point and was, like all inputs, processed only on the US endpoint (paragraph 2), not used for training there and not stored permanently at the sub-processor (paragraph 4). Detection relies on the AI and is not complete; it does not replace the Customer's obligations under Annex 4, Section 3.

(16) Web research: in Autopilot chat, operator Autopilot, the "Write with AI" chat of the feedback to the operator and in "AI distill" (hazards), the AI can research a general question on the internet (Google Search) and show the answer with sources. The question contains no names, addresses or information about children, parents or employees; the software rejects a question containing a name from the current request. Google may store search queries for up to three days; this cannot be switched off. Beenest can switch the feature off centrally.

2. Purposes

Advice and analysis for the center (Autopilot chat, "Custom export", daily analysis), staff scheduling (Schedule AI), information for employees (Staff App AI helper), analyses for the operator (operator Autopilot, monthly report), product help and explanation of this DPA (help chat, DPA chat), converting speech into text (dictation), drafting texts (email helper, AI text drafts, website), documenting parent meetings, hazard assessment and handbooks (hazard AI, handbook draft), illustration (image generation) and room planning (floor plan from photo), each subject to the level and the switches in Section 1.

3. The data flows

1. Autopilot chat and "Custom export" (admin interface, only after admin password). Inputs: director's questions, page path and tool outputs, that is key figures (capacity light, capacity, attendance by category, understaffing, planned vs. actual, opening hours, thresholds, care models), records per person (attendance, events, shift and break plans) according to level, group and care model names, and team free text (Section 1, paragraph 6). With "Custom export", the AI writes a calculation that Beenest runs in an isolated environment on the center's data; the AI does not see the data the calculation runs over. Actions under Section 1, paragraph 9. Level: as set.

2. Schedule AI (staff scheduling). Inputs: schedule of the visible period, persons with contract hours, planned minutes and absence without reason, staffing need per 15 minutes, children only as totals. Changes the schedule directly (Section 1, paragraph 9). Level: "All" only.

3. Daily analysis (automatically shortly before closing on high-occupancy days; the first without asking, each further one only with the director's agreement; not at level "Off"). Inputs as item 1. Recipient: director by email. Storage under Section 1, paragraph 12 c.

4. Staff App AI helper (only after the center switches it on). Answers questions about what the app already shows the signed-in person (own working time, schedule, occupancy, team chat, pinboards, hazards, handbooks); read-only. For teachers always with codes, for directors with staff names at the level "All". Free text under Section 1, paragraph 6. No storage at Beenest.

5. Operator Autopilot (operator area, only users with operator role). Inputs: operator users' questions and tool outputs about the assigned centers, that is key figures, planned hours, shifts, hours balances and absence days per person with approval status; absence reasons only as counts. Staff names and event texts (which may contain children's names) only from centers at "All", otherwise codes. For each center, the lower of its own setting and the operator's maximum level applies; centers at "Off" are not included. No storage.

6. Monthly report (automatically on the first of the month; can be switched off by the operator). Inputs: aggregated monthly figures without personal names, center names and names of closure days. Recipient: operator users by email. Storage under Section 1, paragraph 12 c.

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

8. DPA chat (operator area). Inputs: freely worded questions and the text of this DPA; no operating data. The AI only explains 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. Conversion into text only; the text is stored in the daily report, the recording never.

10. Email helper. Inputs: sample emails pasted by the center (they may contain names and content of correspondence with parents) and the typed or spoken instruction. Result: a draft that is not sent. Storage under Section 1, paragraph 12 d.

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

12. AI text drafts (permission texts; feedback to the operator). Inputs: title and keywords as the center enters them. The result fills the form; no storage before it is accepted.

13. Website builder. Inputs: the director's answers in the center assistant (texts, contact details and legal notices) and possibly two style images of their own; the AI describes the style images on the US endpoint, and only this description goes to image generation. Design and texts on the US endpoint; images under item 14.

14. Image generation for website and terminal logo (only after the center switches it on; can be locked by the operator). Inputs: style, color and design details and the center name; no personal information, no photos. Global endpoint (Section 1, paragraph 2).

15. Preview image of a hazard topic (automatically after creation, also from the Staff App; excluded by the operator's outside-US lock). Step 1 (US endpoint): the photo or text of the topic; the AI describes only objects and the hazard, no people, and discards photos that mainly show people. 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 people if they are in the picture), not stored. Hazard AI: topic and team notes as written; the result is suggestions that the director must accept. Handbook draft: up to five photos of a printed guide or a description by the director; photos are not stored.

17. AI translation (switch "Translation", default on; effective only at the level "All" and where the operator's maximum level allows it). Content is translated into the parents' language stored by the center for the child or, as long as none is stored there, chosen by the parents in the Parent App (German, English, Turkish, Arabic, Ukrainian, Russian, Polish, Romanian [OPEN: language list for the US build, for example Spanish]): a) emails from the center to parents (consent requests, pickup authorization, QR letter, meeting confirmation); names, dates, links and codes are replaced by placeholders beforehand and do not go to the AI, the center's free text is read by the AI as written; b) content in the Parent App (messages, events, blog, group reports, journal notes, notes on meeting requests); the AI reads the whole text as written, including names and, in journal notes, possibly health information about the child; c) the topic of a parent's meeting request, at the director's click back into the center's language. Processing on the US endpoint (Section 1, paragraph 2). Only the translation is stored, with a check value of the original, not the original (Section 1, paragraph 12 f). Push notifications are not translated. Without AI translation, translation stays on the parent's device (Annex 2A).

18. AI data guard (switch "AI data guard", default on and always displayed). The AI data guard runs only at the level "All", because the AI must read the full text; at the other levels it is off, and the interface shows this. Without AI credits, only the name check without AI runs. Before a text written in the web app goes to parents or the public (messages and pinboard including polls, family messages, events, released group reports and journal notes, blog, website texts and legal notices), it is checked. First, the server compares it with the names of the center's children without AI; the name list does not leave the server. Then the AI (with credits) checks for the information in Section 1, paragraph 15 a) and for names or recognizable descriptions of individual children and adult private persons; children's first names and full names are replaced by placeholders, other names go as written. For a family message, the name of the chosen child does not count as a finding. The AI returns only a verdict and the category and does not change the text. Only the director can send a flagged text, after entering the admin password again. If the check is not possible, the text is sent and a notice is shown. Texts are not stored; only the event is counted, without text and without person. A direct message from the director to an individual person (Staff App inbox, Annex 2B, Section 2) is checked as well. In the team chat, the data guard checks only if the Customer also switches on "AI data guard in team chat" (default off); then also messages from the Staff App. There only the AI check runs, without the name check, and without AI credits there is no check. On a finding, the message is not sent; the author can 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 does not change Annex 4, Section 5, paragraph 5.

19. Image generator (only after the operator enables it, default off, and the center switches it on; marked as an AI feature). Users describe an image in free text and can upload a reference image, only after confirming that it shows no people or children; without this confirmation the server does not accept it. They choose a model; the software shows for each whether it processes within the US multi-region or outside it (global endpoint, Section 1, paragraph 2, no US residency commitment). Free text and reference images go unchanged to the chosen model. Reference images must not show people or any other personal information (allowed are, for example, freely usable images from the internet or own images without people); the free text contains no names and no descriptions of real people. This duty lies with the users (Annex 4, Section 3); the software does not check reference images. Generated images are downloaded to the user's device; generated images and reference images are not stored at Beenest. The operator's lock on image AI outside the US switches off all models outside the US multi-region.

20. Parent letters (under the voice dictation switch; sending only with admin password). a) Template: the center uploads an existing letter (PDF, Word file or photo). The AI receives the whole document as it is and replaces personal details with placeholders (for example, "{Child}", "{Parents}"); the software also removes any remaining email addresses and phone numbers. Only the cleaned template is stored, until the center deletes it, with the number of removed details per category, never their values; the uploaded document is not stored. The Customer is responsible for the content of the uploaded document (Annex 4, Section 3). b) Letter: on a change request, the AI writes a letter with placeholders; names and details of children never reach the AI. The software fills in the values per child (name, pseudonym, birthday, age, group, care model, enrollment and school start date; "Parents" appears as "Parents of" with the child's first name). If the center has stored the parents' language, the AI translates the placeholder version (item 17). c) Output: one PDF per child to download (ZIP) or an email with letter text and PDF to the parent address stored for the child (sender "[Center name] via Beenest", sent through Brevo, Annex 1), at most once per child and sending. Every sent email is in the send log; emails that could not be delivered appear without address and without error text as a notice for the center until it resolves it. The AI data guard does not check the letter text. Processing on the US endpoint (Section 1, paragraph 2).

4. Customer obligations

(1) Processing takes place on behalf of and on the instructions of the Customer; choosing the level and switching features on and off under Section 1 are instructions.

(2) Where sensitive personal information may be involved (in particular dictation, parent meeting and team free text), the Customer is responsible for any notice or consent that applicable law requires.

(3) Some states require the consent of all parties to record a conversation. Recordings of meetings (Section 3, item 11) require the consent of all participants. The software checks only whether stored consents under Section 3, item 11 exist; obtaining the consent of everyone present, including staff, is the Customer's responsibility.

(4) The notice dialog under Section 1, paragraph 11 is not a consent.

5. Reference

In all other respects, the provisions of this DPA apply.

Annex 4: Free-text fields

1. Definition

Free-text fields are input fields in which users can write or dictate any text, such as notes, messages, reasons, descriptions and chat posts. Which personal information appears in a free-text field is decided solely by the person writing. Beenest can neither limit the content in advance nor detect it afterwards.

2. Overview by risk

(1) High risk (content about individual children, health or employee behavior is likely, or the text reaches parents, the AI or the operator):

• Notes on the child in master data and in the child journal, daily group reports, each also dictated (dictation can be switched off, default on); parents receive notes and daily reports only if the Customer switches on display in the Parent App (default off) and staff release the individual entry
• Parent meetings: recording, report and version for parents; meeting reasons and parents' meeting requests
• Messages and pinboard posts to parents and family messages (also as push notifications)
• Internal staff chat including pinboard and calls; working-time adjustment requests
• Notes on staff absences and sick notices
• Notes in the hazards area
• Event notes by the director that feed into reports and analyses for the operator
• Input into the email helper
• Notes on pickups and meal cancellations, other staff absence reasons

(2) Medium risk (personal reference likely, limited audience): reasons for time corrections, shift and report notes; events for parents and staff; authorized pickup persons and exceptional handovers; notes on payments; feedback to the operator and replies, the operator's internal notes on applications; texts of the center's own website and blog (public); input into AI features.

(3) Low risk (organizational information): names of groups, rooms, models and occasions; room bookings, closure-day reasons, handbook articles and permission descriptions.

Beenest provides the current list of fields with recipients and deletion in writing on request.

3. Customer obligations

(1) The Customer decides whether and for what its staff use free-text fields and instructs users to include only what is necessary for the purpose.

(2) Sensitive information, in particular diagnoses, assumptions about illness, medication and injuries, as well as information about custody, family conflicts and protective orders, is entered only where there is a legitimate need and the field is intended for it; never in the internal staff chat, messages to parents, hazard notes or input into AI features.

(3) Assessments of the performance or behavior of individual employees do not belong in the staff chat or in hazard notes. The Customer observes the rules on employee data that apply to it.

(4) Before releasing a text to parents or publishing it on the website, the Customer checks whether the text contains data about third parties, in particular other children.

(5) The Customer deletes free text it no longer needs; the software provides deletion functions.

4. Beenest's commitments

(1) Beenest does not evaluate free text for its own purposes, does not analyze its content and does not use it to train AI models.

(2) Free text goes to AI features only under Annex 3 and depending on the Customer's settings (level and switches, Annex 3, Section 1, paragraphs 5 to 8). Features a user triggers in an individual case (for example, email helper, parent meeting, hazard AI, text and handbook drafts) transmit the selected text in full; with AI translation switched on (Annex 3, Section 3, item 17), this applies to the translated content.

(3) Free text is not technically filtered. The exceptions are the rejection of AI inputs (paragraph 5) and the AI data guard for texts to parents and the public (Annex 3, Section 3, item 18).

(4) Deletion periods: the internal staff chat under Section 3 of this DPA (pinboard posts excepted); the Autopilot chat history under Annex 3, Section 1, paragraph 12; meeting recordings immediately after evaluation; applications under Section 8, paragraph 8. All other free text stays stored until the Customer deletes it or the agreement ends (Section 8).

(5) To support the Customer, the AI rejects inputs with prohibited information (Annex 3, Section 1, paragraph 15).

5. Texts to parents

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

(2) Audiences:

• All: all parents of the center
• Group or care model: the parents of the children in the chosen groups or care models
• Child: only the devices on which this child is stored
• Public: anyone, where the Customer publishes content on its website. The Customer alone is responsible for the website, its legal notices and its privacy policy (see the Terms [OPEN: section reference]); Beenest only delivers it technically.

(3) Formats:

• Messages and pinboard posts, also with a poll: to all or to groups
• Family message (director's free text): to the child, in the Parent App and, if desired, also by email (paragraph 7)
• Events with title, description and possibly costs, also with RSVP: to all or to groups or care models; if desired, date and title also on the website
• Closure 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 staff
• Child journal note: to the child, only after release by staff
• Payment items and meeting times: to the child
• Parent letters: per child to the parent email address stored (Annex 3, Section 3, item 20)
• Blog posts: to all in the Parent App and to the public on the website

Push notifications for these follow Annex 2A, Section 2.

(4) By the display, the content is disclosed to the recipients; parents may use it freely, including with their own programs and AI services (Annex 2A).

(5) The Customer instructs its staff to be extremely restrained in texts to all, to groups and to the public: no names or recognizable descriptions of other children, no health information, no information about families, conflicts or incidents involving individuals. Texts about one child also contain no information about other children. Family messages contain only what concerns that family; health information about the own child only where necessary for the purpose. The Customer checks the chosen child before sending, because sending to the wrong family may be a security incident or a breach under applicable law.

(6) The AI data guard (Annex 3, Section 3, item 18) supports this; the obligations under paragraph 5 remain with the Customer.

(7) Family message. a) Sending: the director chooses a child and writes a text; before sending, the software clearly shows the chosen child. The message appears in the Parent App on that child's devices (push under Annex 2A, Section 2 (7)). If the director wishes, it also goes by email to the parent address stored for the child (sender "[Center name] via Beenest", sent through Brevo, Annex 1; only after entering the admin password again; entry in the send log; delivery as in Annex 5, Section 4, paragraph 2). b) Responses: parents do not reply with free text, only with an action set by the director, in the app or through a time-limited link in the email: "OK" (acknowledged), "Accept", "Appointment" (choosing a proposed time) or "Join" (RSVP to a center event). The action and its time are stored with the child. If "Accept" concerns a permission, granting happens only through consent by email under Annex 5; a response in the app is not a grant. The software does not verify who responded beyond knowledge of the link or access to the Parent App. c) Storage: the message and responses stay stored until the Customer deletes them or the agreement ends (Section 4, paragraph 4).

Annex 5: Consents, permissions and authorized pickup persons

1. Subject matter and role of the software

(1) This annex describes the features "Permissions", "Consent by email", "Authorized pickup persons", "Report pickup person" (Parent App) and "Handover record" (group view).

(2) The software is a tool for documentation and communication. It records what the center enters and what is confirmed through the confirmation page, and it shows notices to staff. It does not decide whether a consent is valid or whether a child is handed over to a person. Those decisions are made solely by the Customer through its staff.

2. Permissions

(1) The Customer creates permissions (title and description) and alone decides their content. The software does not distinguish between privacy consents, consents to measures concerning the child and other permissions. Drafts from the AI feature "Write with AI" are not legal advice (Annex 3).

(2) Each center has a fixed permission "Photo of the child on the center's devices" with a preset text that the Customer cannot change. Without an active grant, no photo of the child can be stored or shown; on withdrawal, the photo is deleted, at the latest at the daily reconciliation.

(3) A permission is created in one of two ways:

a) Entry by the center. Staff tick the box for the child in the admin. The time, the source "center" and the title and description in their wording at that time are stored. Supporting evidence, such as a signed form, is not stored; the Customer keeps it itself.

b) Confirmation by email. The center triggers, per child and permission, an email to the address it has stored for the child (Section 4). The email 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 clicking "Grant permission" stores the grant with source "parents", time and the emailed wording.

(4) Confirmation fails if, in the meantime, the title or description was changed, the permission was archived or withdrawn, the stored address was changed or the child was archived. Consent is always given to the emailed wording.

(5) No name, IP address or device of the person clicking is stored with the confirmation. The confirmation shows that confirmation was made through the stored mailbox, not which person confirmed.

(6) Parents declare withdrawal to the center; staff enter it in the admin. Grants and withdrawals are not changed or deleted but added to. If the Customer deletes a child instead of archiving it, the child's grants are deleted too.

(7) Parents see their child's permissions in the Parent App without the option to change them. Staff see permissions in the admin; they are not shown in the group view or the Staff App, except for the effect of the photo permission.

3. Authorized pickup persons and handover

(1) The center keeps a list of authorized pickup persons per child (name, relationship). Persons are deactivated, not deleted.

(2) If the feature "Report pickup person in the app" is switched on (default off), the Parent App can be used to

a) report a person already on file as the person picking up on a given day. The center's parent password and the child code are enough; there is no email confirmation;

b) add a new person with name and relationship. The person is stored only once the pickup authorization has been confirmed through the address stored for the child in the procedure under Section 2, paragraph 3 b (link valid for one hour). The authorization reads: "I/We, as parents or guardians, authorize [name] ([relationship]) to pick up [child's first name] at [center name]. This authorization is valid until withdrawn with the center. The person picking up will show ID at pickup." [OPEN: confirm the English wording used in the US build.] Name, relationship, authorization text and time of confirmation are stored.

(3) A person added this way carries the flag "New: check ID" until staff enter "ID checked" in the admin. Only the time is stored, no ID data and not who checked.

(4) Staff learn about a reported pickup without names: through an automatic notice in the staff chat (deleted with the chat) and, on the day of pickup, through a notice in the group view. Name, relationship and the ID check flag appear in the handover dialog. No push notifications are sent for this.

(5) In the handover record, staff document to whom the child was handed over or who brought the child, exceptionally to a person not on file with a reason, and who confirms the handover. "Confirmed by" is documentation; it is not secured by a personal sign-in. The record is voluntary, separate from check-in and check-out, and cannot be changed or deleted.

(6) The software does not prevent any handover or check-out, including to a person without an ID check or not on the list.

4. Emails to parents

(1) The emails under Sections 2 and 3 go to the one address the center stores for the center in the child record. They are sent in the center's name (sender "[Center name] via Beenest") through the email service listed in Annex 1.

(2) An email counts as sent when the mail server has accepted it. The software does not learn whether it is delivered, sorted as spam or read; bounces are not evaluated. For permissions, the admin shows "waiting for confirmation" and after expiry "not confirmed"; for pickup authorizations it shows only the confirmed person.

(3) Permission requests are recorded in the send log with the recipient address (Section 8, paragraph 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 parent or is accessible to third parties;

b) whether the stored address is correct;

c) the existence and scope of custody, court orders, visitation restrictions or protective orders;

d) whether both parents agree, where that is required;

e) the identity of the person picking up;

f) the content, validity and basis of a permission, or the accuracy of the center's entries;

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

6. Customer obligations

Through organization and instruction of its staff, the Customer ensures in particular that

a) permission texts are legally reviewed, state purpose, scope, recipients, duration and withdrawal, and that there is a valid basis for each permission;

b) the email address stored for the child is correct, belongs to a parent or guardian and is updated when it changes;

c) it checks whether a permission or pickup authorization requires the agreement of both parents and, if so, obtains it, for example through a second statement on paper;

d) information about custody, court orders and protective orders is taken into account outside the software or in a field intended for it (Annex 4, Section 3, paragraph 2);

e) staff check the identity of any person picking up whom they do not know, using a government-issued photo ID, before handing over the child, and enter the check in the admin;

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

g) boxes are ticked only if the permission has actually been granted, and the evidence for it is kept outside the software;

h) withdrawals are entered without delay and authorized pickup persons are deactivated as soon as the authorization ends;

i) staff know which permissions apply to a child before acting on them;

j) parents who do not want to or cannot use email have an equivalent option on paper;

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

l) children are archived rather than deleted as long as evidence of consents is needed.

7. Beenest's commitments

(1) Beenest stores grants, withdrawals, authorizations and handover records so that they cannot be changed afterwards; a grant with source "parents" can only be created through the confirmation page.

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

(3) Beenest does not owe further services, in particular checking identity, custody or validity, delivering emails or preventing handovers.