Data Processing Agreement

At a glance

• Hosting and data location: databases, hosting and error monitoring run in Germany (Frankfurt); Cloudflare KV (Parent App) in the EU; technical email (Brevo) hosted in France and Germany with storage in Belgium; the email mailbox in the Netherlands. Core data stays in the EU. Exceptions with a link outside the EU: Apple and Android push notifications, wallet passes, optional AI image generation (global endpoint, Annex 3) and the public centre websites (Cloudflare Pages, worldwide delivery). Section 10.
• Encryption: TLS 1.2/1.3 for every transfer. HTTPS only. No unencrypted interfaces.
• Separation and pseudonyms: each centre's data is technically separated from every other centre's. Only authorised users of the centre 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.
• Role: the Customer is the controller, Beenest its processor. Beenest uses centre data only on the Customer's instructions, not for its own purposes, not for advertising and not to train AI models (Sections 4 and 6, Annex 4).
• Changes: when a centre belongs to an operator account, the operator is the contracting party and confirms in the operator account (desktop, not the check-in terminal). Assigned centres can acknowledge the documents once and later see only a notice. Without an operator, the centre confirms itself. 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. Clarifications of the description and security changes without new data points on the same infrastructure: immediately. New sub-processors: locked until confirmed (Sections 5, 9 and 12).

Parties

This Data Processing Agreement ("DPA") is entered into between the nursery, childcare setting, operator or other organisation that accepts it (the "Customer", the controller) and Triple Peak Software Systems, a [legal form, e.g. LLC] organised under the laws of [state of formation], [registered address] ("Beenest", the processor, "we", "us").

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

In this DPA, "UK GDPR" means the General Data Protection Regulation as it forms part of the law of the United Kingdom, and "Data Protection Legislation" means the UK GDPR, the Data Protection Act 2018 and the other data protection law of the United Kingdom that applies, each as amended from time to time. "Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "special category data" have the meanings given in the UK GDPR. "Centre data" means the personal data Beenest processes on the Customer's behalf when it provides the software.

This DPA sets out the subject matter and duration, nature and purpose of processing, types of personal data, categories of data subjects and the obligations and rights of the controller, as Article 28(3) UK GDPR requires.

1. Subject matter and duration

(1) Beenest processes centre data on behalf of the Customer to provide the Beenest childcare management software at [OPEN: app domain for UK customers], 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 12). 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 synchronisation 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 centre website created with the website builder at [OPEN: domain for published centre websites of UK customers] 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, enrolment 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 UK, and to which authorities?]
• 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 centre 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: are parent payments available in the UK? GiroCode is a euro (SEPA) transfer format.]
• Bank connection (optional): reading the transactions of the centre's bank account at the bank chosen by the Customer, read-only and under an access authorisation 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: is the bank connection available in the UK? Which banks? The DE version names Qonto and the CAMT.053 statement format.]
• Collecting consents and authorisations from parents by confirmed email to the address stored by the centre (permissions, pickup authorisation, 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 recognise the child, only while the permission "Photo of the child on the centre's devices" is active; no AI; deleted on withdrawal
• Managing authorised pickup persons per child, reporting the person picking up on a given day through the Parent App, pickup authorisation 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 centre 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 centre, groups or care models, RSVPs per child, optional costs per child and optional publication of date and title on the centre website
• Booking rooms of the centre
• Emailing a child's QR letter to the stored parent address, depending on the Customer's settings with the centre's parent password
• Messages from the centre to its operator and the operator's replies; an optional email copy to a distribution list set by the centre; forwarding of individual messages by the operator by email to recipients it chooses, with a log
• An optional enrolment 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 (Netherlands)
• Technical error monitoring through Sentry (EU region, Frankfurt), including session replay of the web app (masked; details in Section 5, item 9); in addition, the application's own error logs in the centre database, which may contain a person ID in context
• Reports and analyses, including spreadsheet export
• Staff time reports for managers and operators (per centre and across the operator) with export, and staff access to their own hours
• Operator accounts: access to the data of the centres assigned to the operator; inviting further users to the operator account, who receive access to view and edit those centres' 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:

• Organising and documenting the operation of the centre with software
• Real-time recording and documentation of attendance and capacity, which the Customer can use for its safety, regulatory (for example the daily attendance record under the EYFS) 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 centre 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, authorisations and their withdrawal (Annex 5)
• Supporting the centre in documenting pickup authorisations and handovers (Annex 5); the centre decides every handover
• Organising events, parent meetings and rooms
• Communication between centre and operator
• Allocation of childcare places by the operator (enrolment 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 minimisation: required and optional fields. The child's real name is not required; if it is left empty, the software shows "No name". Running the centre 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 (data minimisation, Article 5(1)(c) UK GDPR).

Children

Children are data subjects, not users. They do not use the software or the apps; data about children is entered by the centre or by parents.

Statistics and reporting fields and special category data (Article 9 UK GDPR, for example health data such as allergies or disability-related support) are optional and collected only if the centre records them. Special category data is processed separately and with a higher level of protection. The Customer ensures a lawful basis and a condition under Article 9(2) UK GDPR and, where required, Schedule 1 to the Data Protection Act 2018. 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.

Staff absence reasons. Absences (also from sick notices, leaving early at the terminal and the weekly question about minus hours) are stored with a reason from a fixed catalogue and an optional note. The DE catalogue contains: illness, child sick, medical appointment, employment ban (German maternity protection), maternity protection, parental leave, carer's leave, notice of termination, long-term absence, strike, holiday, special leave, unpaid leave, training, time off in lieu, release from duties, regeneration or conversion day, part-time day off, work errand, business trip and free text; for individual shifts also "unexcused" and "cancelled". [OPEN: catalogue in the UK build; several DE reasons are German-specific.] Illness, child sick, medical appointment, employment ban and maternity protection are health data; strike can reveal trade union membership (both special category data, Article 9 UK GDPR); carer's leave and notice of termination are particularly sensitive.

Who sees the reasons. The person sees their own reasons in the Staff App and when checking out at the terminal. Other people's reasons appear only in the centre's admin (staff planning with the admin password; notices and reports with the staff password), in the operator area and in reports, exports and printouts (daily report, rota, weekly poster). Check-in and group tablets and the Staff App show other people's absences without a reason. The Customer decides who gets access to these areas and printouts.

Parents and carers (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; centre address and phone for the QR letter, consents and meeting confirmations) and the send log
• Parents' language per child (stored by the centre 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 centre: 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 centre admin. In addition, a one-time acknowledgment by the manager of an assigned centre (not a second contracting party, Section 12)
• Operator account: assignment to centres; invitations of further users (inviting person, invited person, timestamps, status). After accepting, these users can view and edit the data of the centres assigned to the operator
• Exchange between centre and operator: messages, replies, status; the centre'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 centre data under Section 8
• The application's own error logs, where a person ID appears in the error context; stored in the centre database on servers in Germany, 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 centre's time zone); pinboard messages stay until removed manually or the agreement ends; under the usage rules, not intended for special category data

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 centre database on servers in Germany. 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 special category data (Annex 4).

Centre metadata (optional, where configured)

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

Other data subjects (where the feature is used)

• Authorised pickup persons: name, relationship to the child, source of the entry (centre or parents), authorisation text and time of confirmation, time of the ID check (no ID number)
• Applicants for a childcare place (operator's enrolment portal): child's first name and date of birth, parent name, email address and optional phone number, preferred centres 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 centre and recipients of transfers from the centre (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 centre 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)
• Organisation names: name of the centre, 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 manager's own style images for the website (image understanding on the EU multi-region endpoint); image generation receives only an image description without personal data
• Website details entered by the manager (texts, contact details, legal information)
• 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

Beenest undertakes the following obligations under Article 28(3) UK GDPR:

(1) Instructions (Article 28(3)(a)). Beenest processes centre data only on the Customer's documented instructions, including the settings the Customer chooses in the software and with regard to transfers of personal data to a third country or an international organisation, unless required to do so by domestic law to which Beenest is subject. In that case Beenest informs the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest. Beenest informs the Customer without undue delay if, in its opinion, an instruction infringes the Data Protection Legislation. [OPEN: Beenest is established outside the UK. How to treat a disclosure demand under the law of the country where Beenest is established (for example a US authority request); see Section 10, paragraph 3.]

(2) Confidentiality (Article 28(3)(b)). Beenest ensures that persons authorised to process centre data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. The duty continues after the engagement ends.

(3) Security (Article 28(3)(c) and Article 32). Beenest takes all measures required under Article 32 UK GDPR. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, Beenest ensures a level of security appropriate to the risk. The measures are described in Section 5.

(4) Sub-processors (Article 28(3)(d), (2) and (4)). Beenest engages no further processor without the Customer's prior written authorisation. The sub-processors in Annex 1 and Annex 2A are authorised when this DPA is concluded; any addition or replacement stays technically locked until confirmed (Section 9).

(5) Data subject rights (Article 28(3)(e)). Taking into account the nature of the processing, Beenest assists the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling its obligation to respond to requests from data subjects exercising their rights under Chapter III UK GDPR, in particular the rights of access (Article 15), rectification (Article 16), erasure (Article 17), restriction of processing (Article 18), the notification obligation (Article 19), data portability (Article 20), objection (Article 21) and the rights relating to automated decision-making. If Beenest receives such a request directly, it forwards it to the Customer without undue delay 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 (Article 28(3)(f)). Taking into account the nature of the processing and the information available to it, Beenest assists the Customer in ensuring compliance with the obligations under Articles 32 to 36 UK GDPR, in particular:

• security of processing (Article 32)
• notification of a personal data breach to the Information Commissioner (Article 33)
• communication of a personal data breach to the data subject (Article 34)
• data protection impact assessments (Article 35)
• prior consultation with the Information Commissioner (Article 36)

(7) Personal data breaches (Article 33(2)). Beenest notifies the Customer of a personal data breach affecting centre data without undue delay and no later than 24 hours after becoming aware of it, so the Customer can meet its own duty to notify the Information Commissioner within 72 hours where Article 33(1) UK GDPR requires it. The notice contains at least, as far as known:

• a description of the nature of the breach
• where possible, the categories and approximate number of data subjects and records concerned
• 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 breach, and does not notify affected individuals or the Information Commissioner on the Customer's behalf unless the Customer instructs it to or the law requires it.

(8) Deletion and return (Article 28(3)(g)). At the end of the provision of services, Beenest deletes or, at the Customer's choice, returns all centre data and deletes existing copies, unless domestic law requires storage of the personal data. Details are in Section 8.

(9) Evidence (Article 28(3)(h)). Beenest makes available to the Customer all information necessary to demonstrate compliance with the obligations in Article 28 UK GDPR and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates. Details are in Section 7.

(10) Records of processing (Article 30(2)). Beenest keeps a record of all categories of processing activities carried out on behalf of the Customer, containing the information in Article 30(2) UK GDPR.

5. Technical and organisational security measures

Beenest has implemented the measures below under Article 32(1) UK GDPR. They are reviewed regularly and adapted to the state of the art. They include in particular: the pseudonymisation and encryption of personal data (Article 32(1)(a)); the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services (Article 32(1)(b)); the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident (Article 32(1)(c)); and a process for regularly testing, assessing and evaluating the effectiveness of the measures (Article 32(1)(d)).

In assessing the appropriate level of security, account is taken in particular of the risks presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data (Article 32(2) UK GDPR).

Changes to the measures fall into two groups:

• Effective immediately, without a new checkbox: only changes that collect no new personal data and run on the same infrastructure already listed in Annex 1 or Annex 2A (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 data, introduces a new feature that collects data, or uses infrastructure other than that already authorised. These follow the procedure in Section 12, 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 centre 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 centre; a second factor at sign-in (one-time code by email) for operator and centre accounts.

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

3. Authorisation

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

Beenest side: access to personal data 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 (Frankfurt) 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 centre (centre 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. Centres can see only their own data. Operator accounts (including invited users) see and edit the data of the centres assigned to the operator; there is no access across operators.

8. Pseudonymisation

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 EU region Frankfurt (FRA). Stack traces and technical metadata without chat, prompt or audio payloads; for dictation errors at most byte size and MIME type. Session replay records screen 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 synchronisation. 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 centre; the centre can also enter permissions itself (source "centre", 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 centre'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 12, paragraph 3.

6. Customer's rights and obligations

(1) The Customer is the controller: it determines the purposes and means of processing centre data and remains responsible for the lawfulness of the processing (Article 24 UK GDPR). It decides what data is entered into the software.

(2) The Customer ensures that the processing complies with the principles in Article 5(1) UK GDPR: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality. It is responsible in particular for:

• giving parents, staff and other individuals the information required by Articles 13 and 14 UK GDPR, including the information about the Parent App and Staff App (Beenest provides notices that the Customer can use: Parent App Privacy Notice and Staff App Privacy Notice)
• a lawful basis under Article 6(1) UK GDPR for each processing operation, and consents where required, meeting Article 7 UK GDPR
• for special category data (for example health data, allergies, sick notices), a condition under Article 9(2) UK GDPR and, where the Data Protection Act 2018 requires it, a condition in Schedule 1 to that Act and an appropriate policy document
• its own record of processing activities (Article 30(1) UK GDPR)
• a data protection impact assessment under Article 35 UK GDPR where the processing is likely to result in a high risk to the rights and freedoms of individuals
• when it uses features that monitor staff (Annex 2B, Section 4, paragraph 6): identifying a lawful basis, telling staff about the monitoring and carrying out a data protection impact assessment where the monitoring is likely to be high risk, as the ICO's guidance on monitoring workers describes
• paying the data protection fee to the Information Commissioner, unless it is exempt (Data Protection (Charges and Information) Regulations 2018)
• inviting further users to the operator account and the resulting grant of view and edit access to the data of assigned centres; the Customer ensures that only authorised 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, authorised pickup persons and handovers, in particular checking the identity of persons picking up, parental responsibility, 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 centre 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 centres). There are currently no graded roles; Beenest removes an account on request. The management team shares the centre 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 (centre 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 12, which captures the name and account of the confirming person.

7. Audits and evidence

(1) The Customer may verify compliance with this DPA and the Data Protection Legislation (Article 28(3)(h) UK GDPR). 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 centre data rest solely with the Customer, in particular under the requirements of its regulator (for example the EYFS statutory framework in England, which leaves the retention period for children's records to the provider, or the standards of the Care Inspectorate, Care Inspectorate Wales or the HSC Trust), health and safety reporting rules (for example RIDDOR) and tax, employment or funding rules. Beenest stores the data only for the term of this DPA and as the Customer instructs; Beenest has no legal obligation of its own to store centre data within the meaning of Article 28(3)(g) UK GDPR.

(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 erasure requests from individuals (Article 17 UK GDPR) 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 under Article 28(3)(g) UK GDPR. Beenest assists with all exports and data handovers and provides the export through a secure transfer method on request.

(4) Beenest deletes all centre 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 devices for UK customers 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 enrolment 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 centre and operator: until the Customer deletes them, at the latest under paragraph 4.

9. Sub-processors

(1) By concluding this DPA, the Customer gives its general written authorisation for the sub-processors listed in Annex 1 and Annex 2A (Article 28(2) UK GDPR).

(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 data 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 authorised sub-processors are used.

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

(4) Beenest ensures, under Article 28(4) UK GDPR, that each sub-processor is bound by a written contract that imposes the same data protection obligations as set out in this DPA, in particular sufficient guarantees for appropriate technical and organisational measures. Beenest remains fully liable to the Customer for the performance of its sub-processors' obligations. [OPEN: the DE sub-processor contracts are held by 997 Ventures UG. Which entity holds the contracts for UK customers (Triple Peak directly, or 997 Ventures as Triple Peak's processor)? If 997 Ventures, it must be listed as a sub-processor.]

10. Data location and international transfers

(1) Storage locations: centre data is stored only in the European Union(UK customers run on the same EU infrastructure as Beenest's German product); paragraph 2 lists the exceptions exhaustively. As of this DPA, the sub-processors are configured as follows:

• Supabase: Frankfurt (AWS): database, authentication, storage; main location of all core data
• Vercel: Frankfurt: hosting, serverless functions and data storage
• Cloudflare: EU data residency (Frankfurt, Cloudflare Regional Services): API relay for the Parent App and push dispatch for both apps, and storage in Cloudflare KV (the centre's parent password, centre 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
• Brevo (Sendinblue): technical emails and emails sent and received in software features: hosting OVH (France and Germany), storage Google Cloud (Belgium)
• Sentry: Frankfurt: error monitoring and session replay of the web app (masked)
• Zoho: Netherlands: email mailbox
• Google Cloud (Vertex AI / Gemini Enterprise Agent Platform): EU multi-region endpoint (aiplatform.eu.rep.googleapis.com): all AI data flows except image generation, only with AI features switched on (Annex 3)

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

(2) Exceptions: the following data flows can run through infrastructure outside the EU 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; delivery only through EU infrastructure is not possible. 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). Centre data stays in Supabase Frankfurt. 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 EU multi-region; there is therefore no EU residency commitment for this flow. Only image descriptions without personal data are sent (style and design details, centre name, descriptions of objects); photos, names, IDs and descriptions of people are not sent. With an image generator model outside the EU, the user's free text and reference images also go there; they must not contain personal data (Annex 3, Section 3, item 19). Can be switched off individually; details in Annex 3
• Centre 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.

(3) Restricted transfers. Storing centre data in the EU is a transfer from the United Kingdom to the European Economic Area, which is covered by the UK's adequacy regulations for the EEA states. Apart from paragraph 2, there is no transfer aimed at permanent storage outside the UK and the EEA. Several sub-processors have US parent companies; the safeguards in paragraph 4 also cover possible access by those parent companies and under US law (in particular the CLOUD Act) and, for image generation, processing on the global endpoint. Access by Beenest itself: Beenest is established outside the UK and the EEA. Where Beenest personnel access centre data from outside the UK and the EEA (for support and troubleshooting, Section 5, item 3), this is a restricted transfer to Beenest. [OPEN: transfer mechanism for Beenest itself: UK Extension to the EU-US Data Privacy Framework if Triple Peak self-certifies, otherwise the IDTA or the UK Addendum to the EU SCCs, to be attached to this DPA with its tables completed.]

(4) Transfer mechanisms per provider. Where a recipient in the United States has self-certified to the EU-US Data Privacy Framework and its UK Extension, transfers rely on the UK Extension (the UK-US data bridge). Otherwise, or in addition, they rely on the International Data Transfer Agreement (IDTA) or the International Data Transfer Addendum to the EU Standard Contractual Clauses (UK Addendum). In the German contract, the providers are covered as follows; the UK equivalent applies as stated:

• Vercel Inc., Cloudflare Inc., Functional Software, Inc. (Sentry) and Google (Vertex AI including image generation on the global endpoint, Firebase Cloud Messaging, Google Wallet, and Google Cloud storage in Belgium used by Brevo): EU-US Data Privacy Framework and EU SCCs; for the UK, the UK Extension where certified and the UK Addendum. [OPEN: confirm each provider's UK Extension certification and that its DPA includes the UK Addendum or IDTA.]
• Supabase Inc. and 650 Industries, Inc. (Expo): EU SCCs; for the UK, the UK Addendum. [OPEN: confirm the UK Addendum or IDTA in the Supabase and Expo DPAs.]
• Apple (Apple Push Notification service, transit only): Apple Inc. is certified under the EU-US Data Privacy Framework; Apple offers no Article 28 contract and no APNs-specific SCCs (Annex 2A, Section 4). For the UK, only the UK Extension, if Apple Inc. participates. [OPEN: confirm Apple Inc.'s UK Extension participation.]
• Zoho Corporation B.V. (Netherlands) and Brevo (France, Germany): within the EEA, covered by the UK's adequacy regulations.

(5) Monitoring and fallback. Beenest monitors the validity of the EU-US Data Privacy Framework and its UK Extension. If the UK Extension ceases to be available, Beenest switches the providers concerned to the IDTA or the UK Addendum without interrupting the service and informs the Customer without undue delay, at the latest within 30 days of becoming aware. Apple offers no SCCs for APNs; iOS push can then be switched off without affecting the core product.

(6) Supplementary measures. Beenest applies the following measures, which it takes into account in its transfer risk assessment:

• transport encryption (TLS 1.2/1.3) for every transfer
• no storage of core personal data outside the EU (storage locations under paragraph 1, exceptions under paragraph 2)
• pseudonymisation where technically possible (for example, child codes instead of real names in the Parent App)
• data minimisation to what each purpose strictly requires; AI image prompts without personal data (for the image generator under Annex 3, Section 3, item 19 a duty of the users); for the other AI features codes instead of names according to the chosen AI privacy level (Annex 3)
• push payloads by type (Annex 2A, Section 2 and Annex 2B, Section 2). As intended, free text contains no sensitive data about children, only organisational information and, for staff, working-time information. Only messages to groups and to a family from the web app, direct messages to a staff member and, if switched on, team chat messages from the Staff App are checked by the AI data guard (Annex 3, Section 3, item 18); otherwise there is no technical filtering
• error events without chat, prompt or audio payloads and masked session replay in the EU region Frankfurt (Section 5, item 9)

(7) Escalation. If the IDTA or UK Addendum is also held insufficient for a provider by a court or a binding decision of the Information Commissioner, Beenest takes at least one of the following measures and informs the Customer at least 14 days in advance: migration to a replacement provider established in the UK or the EEA, where technically and commercially available; switching off the service concerned where technically reasonable (in particular optional Parent App features such as push and wallet, and individual AI data flows including image generation); further safeguards (for example client-side encryption) where the service stays functional.

(8) Effect on the core product. The location of core data is not affected if the UK Extension falls away; all core personal data stays where paragraph 1 says. Only the legal transfer mechanism for providers with a US parent company (Vercel, Supabase, Functional Software and Google) is affected, and paragraph 5 then applies. Push for the Parent App and the Staff App (FCM, APNs, Expo) and optional AI image generation can be switched off without affecting the core product.

11. Liability

Liability of the parties follows the Data Protection Legislation, in particular Article 82 UK GDPR. Each party is liable for damage caused by its own breach of this DPA or of the Data Protection Legislation. Beenest is liable for the acts and omissions of its personnel and of the sub-processors it engages as for its own. Nothing in this DPA limits or excludes liability for death or personal injury caused by negligence, or any other liability that cannot be limited or excluded by law. [OPEN: should DPA liability be subject to the limitation of liability in the Terms (which must meet the reasonableness test of the Unfair Contract Terms Act 1977), carved out, or subject to a separate cap?]

12. 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 centre is assigned:

• Centre assigned to an operator: the operator alone is the contracting party, the Customer and the controller. 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 manager of the assigned centre 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.
• Centre without an operator: the centre manager confirms in the admin for the Customer. The acceptance dialog appears in the centre 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 centre manager), 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 centre 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 centres 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 authorised, 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 data 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 /uk/dpa.
• Changes to the security measures under Section 5 that collect no new personal data and run on the same, already authorised 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 electronic confirmation together with the email under paragraph 2 meets the requirement in Article 28(9) UK GDPR that this contract be in writing, including in electronic form, and the written form in Section 13, paragraph 1.

13. Final provisions

(1) Changes and additions to this DPA must be made in writing; Section 12, paragraph 5 satisfies this. Procedure and exceptions are in Section 12, 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 law, e.g. England and Wales]. The courts of [courts, e.g. of England and Wales] have exclusive jurisdiction. This does not affect the rights of data subjects or the powers of the Information Commissioner. [OPEN: customers in Scotland and Northern Ireland; keep one governing law and forum for all UK customers?]

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

(5) UK representative. Where Article 27 UK GDPR requires Beenest to designate a representative in the United Kingdom: [OPEN: UK representative name and address].

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

Annex 1: Sub-processors

Beenest uses the following sub-processors. A separate data processing agreement is in place with each. Core personal data is not stored permanently outside the EU. For the exception of optional AI image generation (global endpoint) see Annex 3, Section 1, paragraph 2. The additional sub-processors of the Parent App and the Staff App are listed in Annex 2A, Section 4. Transfer mechanisms: Section 10, paragraph 4.

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 [OPEN: Stripe contracting entity for UK customers]; Stripe receives only the Customer's contract and payment data, no centre 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 (Articles 6(1)(a) and 7 UK GDPR) is the Customer's responsibility and decision. Sections 4 and 5 of this annex (push services, wallet, sub-processors, international transfers) also apply to the Staff App (Annex 2B).

1. Voluntary use and lawful basis

(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 determines the lawful basis for processing through the Parent App (for example consent under Articles 6(1)(a) and 7 UK GDPR). 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 authorised 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
• Centre 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 UK?]
• Blog posts of the centre

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

Data minimisation: 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 authorised 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. Centre data is not stored on the device but loaded from the EU database on each request. Only the access to the centre, the child codes and the parent's own responses remain on the device, and for the offline calendar the centre'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, centre 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, centre messages and centre status; it is served by the application (Vercel, Frankfurt, Annex 1).

Push notifications: all types are sent as Expo push through the Cloudflare push worker. Centre data stays in Supabase Frankfurt. 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 centre, filtered by the groups stored at registration. Centre-wide messages go to all registered devices of the centre. Content: title = message title, text = message text, each as written by staff; the centre name is placed before the title. Intended for organisational 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: "Centre close to its limit") or red (fixed text: "Centre at full capacity"). No push for green. Suppressed on closure days and outside opening hours. The centre can switch off yellow and red for the Parent App individually (default on); Staff App devices always receive both. [OPEN: confirm the English push texts in the UK build (DE "Kita nah am Limit", "Kita voll ausgelastet").]

(3) Event reminder. Recipients: devices of the group or the centre. 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 centre 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 centre name, no text; the app loads the content from the EU 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 in the EU to Supabase Frankfurt), not through push payloads. The push notification is the trigger; the app loads content from the EU 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), centre 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, centre, 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 the following additional sub-processors. A separate data processing agreement is in place with Cloudflare, Expo and Google. For Apple Push Notification service there is no data processing agreement; the Apple Developer Program License Agreement including Attachment 1 applies.

Note on Apple (APNs): Apple does not offer a data processing agreement under Article 28 for the Apple Push Notification service and no APNs-specific standard contractual clauses. The contractual basis is the Apple Developer Program License Agreement, including Attachment 1 (Additional Terms for Apple Push Notification Service and Local Notifications). Apple Inc. is certified under the EU-US Data Privacy Framework. 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 centre.

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 centre data itself.

No technical alternatives: no EU-only or 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. Centre data stays in Supabase Frankfurt; 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 with EU data residency. 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 EU (Cloudflare Regional Services, Frankfurt).

5. International transfers

(1) Transfers to Expo, Google (Firebase Cloud Messaging, Google Wallet) and Apple (APNs), and possible access by Cloudflare's US parent company, are covered by the mechanisms in Section 10, paragraph 4 of this DPA: the UK Extension to the EU-US Data Privacy Framework where the recipient is certified, and otherwise or in addition the IDTA or the UK Addendum.

(2) Apple concludes no standard contractual clauses for APNs; only the UK Extension is available, if Apple Inc. participates. If that basis falls away, iOS push can be switched off without affecting the core product (Section 10, paragraph 8).

6. 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 centre's staff. It applies if the Customer uses the Staff App. Sections 4 and 5 of Annex 2A apply to push services, wallet, sub-processors and international transfers. Staff are informed in the Staff App Privacy Notice.

1. Lawful basis and voluntary use

(1) Processing takes place within the employment relationship between the Customer and its staff. The Customer ensures the lawful basis, in particular under Article 6(1)(b) and (c) UK GDPR, and for sick notices and other health data a condition under Article 9(2)(b) UK GDPR together with the employment condition in Schedule 1 to the Data Protection Act 2018. It is responsible for informing staff (Articles 13 and 14 UK GDPR), including about monitoring (Section 4, paragraph 6 of this annex).

(2) Use of the Staff App is voluntary for staff. Working time in the centre 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 manager 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 minimisation: 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 "Centre 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 manager and the topic of a meeting named by parents may contain information about children in both modes. Centre data is not stored on the device but loaded from the EU 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, Frankfurt, 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 manager confirms through the Autopilot.
• Time corrections from the Staff App go to the manager 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 manager 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 1 November 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 organisational 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. Centre 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 data, special category data), also the reason when leaving early and in the weekly question about minus hours; catalogue and visibility under Section 3 of this DPA
• 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 manager (recipient, title, text, time)
• In "Centre 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: centre 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 centre; 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 recognisable descriptions of children. Beenest recommends switching on the AI data guard in the team chat.

b) Centre 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 parental responsibility 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 centre-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, centre device or report to the manager), and that not using the app leads to no disadvantage.

(4) Information. The Customer informs staff before first use (Article 13 UK GDPR), 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 centre 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 behaviour 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 managers, 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 follows the ICO's guidance on monitoring workers: it identifies a lawful basis, tells staff about the monitoring before it starts (covert monitoring only in exceptional cases), carries out a data protection impact assessment where the monitoring is likely to be high risk, and, as the guidance recommends, seeks and documents the views of staff or their representatives. It observes any agreement with a recognised trade union or employee representatives that applies to it, 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 centre; 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 centre 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 centre 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 centres and cap the level; the centres 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 Ireland Ltd. / Google Cloud (Vertex AI / Gemini Enterprise Agent Platform). 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). Transfer mechanism, also covering possible access: Section 10, paragraph 4.

(2) Data residency: all data flows except image generation run through the EU multi-region jurisdictional endpoint (aiplatform.eu.rep.googleapis.com). Processing is contractually limited to the EU geography (no single-region pinning to Germany). Exception image generation: Google does not provide image models on the EU multi-region. This flow uses the global endpoint; there is no EU residency commitment for it. The global endpoint receives only image descriptions without personal data (style, colour and design details including the centre name, and a description of objects without people created beforehand on the EU endpoint); photos, the centre'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 EU 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 19 October 2026), all through Google Cloud (Vertex AI): text and understanding gemini-3.8-flash (EU); fast tasks such as dictation, translation and checks gemini-3.5-flash-lite and gemini-3.1-flash-lite (EU); Claude Haiku 5.5 by Anthropic (claude-haiku-5-5, in Google Cloud's Model Garden on the Europe multi-region endpoint, processing in Europe; Google remains the contractual partner); image generation gemini-3.1-flash-image and gemini-3.1-flash-lite-image (global). A switch to another model of the same sub-processor on the same endpoint is documented as a clarification under Section 12, 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 (EU).

(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) "Pseudonymised": children and practitioners appear only as codes (for example, "Child 7F3A", "Practitioner K2QM"); c) "All": real names of practitioners and children. The centre 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, including data protection by default (Article 25(2) UK GDPR), and otherwise chooses a lower level. The operator can set a maximum level for all its centres; 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 "Pseudonymised". 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 centre, operator Autopilot and monthly report. Schedule AI and the AI helper for managers run only at the level "All"; the AI helper for practitioners 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) Pseudonymisation 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 authorised users see the answer with names. Pseudonymised data remains personal data. 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 centre 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 centre switches them on. The operator can lock individual features for all its centres, lock all features with processing outside the EU (currently image generation including preview images for hazard topics and the image generator models outside the EU 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 manager 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 manager 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 under Article 6(1)(a) UK GDPR.

(12) Storage at Beenest (servers in Germany): a) history of Autopilot chat and Schedule AI: per user, centre and day, at most 60 entries; deleted automatically after a period chosen by the centre of one to seven days (default: at the end of the calendar day, in the centre'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 centre deletes them, at the latest under Section 8. e) For each AI call, a usage record without content (centre, 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 centre 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 centre 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 behaviour: no judgements, 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 informing staff and for its obligations under the ICO's guidance on monitoring workers (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 special category data, suspected child protection cases, information about parental responsibility, court orders, protective orders and family conflicts, credentials (passwords, PINs, QR and child codes), bank, ID, tax and National Insurance numbers, and assessments of individual employees (paragraph 14);

b) depending on the effective AI privacy level: at "Pseudonymised", names of employees and children; in the Staff App AI helper for practitioners, 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 EU 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 centre (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: manager'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 centre'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 manager's agreement; not at level "Off"). Inputs as item 1. Recipient: manager by email. Storage under Section 1, paragraph 12 c.

4. Staff App AI helper (only after the centre 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 practitioners always with codes, for managers 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 centres, 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 centres at "All", otherwise codes. For each centre, the lower of its own setting and the operator's maximum level applies; centres 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, centre 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 centre (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 centre enters them. The result fills the form; no storage before it is accepted.

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

14. Image generation for website and terminal logo (only after the centre switches it on; can be locked by the operator). Inputs: style, colour and design details and the centre name; no personal data, 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-EU lock). Step 1 (EU 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 manager must accept. Handbook draft: up to five photos of a printed guide or a description by the manager; 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 centre 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 UK build]): a) emails from the centre to parents (consent requests, pickup authorisation, QR letter, meeting confirmation); names, dates, links and codes are replaced by placeholders beforehand and do not go to the AI, the centre'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 manager's click back into the centre's language. Processing on the EU 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 centre'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 recognisable 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 manager 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 manager 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 centre 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 EU multi-region or outside it (global endpoint, Section 1, paragraph 2, no EU residency commitment). Free text and reference images go unchanged to the chosen model. Reference images must not show people or any other personal data (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 EU switches off all models outside the EU multi-region.

20. Parent letters (under the voice dictation switch; sending only with admin password). a) Template: the centre 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 centre 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, enrolment and school start date; "Parents" appears as "Parents of" with the child's first name). If the centre 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 "[Centre 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 centre until it resolves it. The AI data guard does not check the letter text. Processing on the EU 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 special category data may be involved (in particular dictation, parent meeting and team free text), the Customer ensures a condition under Article 9(2) UK GDPR and, where required, Schedule 1 to the Data Protection Act 2018.

(3) Under this DPA, 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 under Article 6(1)(a) UK GDPR.

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 data 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 behaviour 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 manager 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; authorised pickup persons and exceptional handovers; notes on payments; feedback to the operator and replies, the operator's internal notes on applications; texts of the centre's own website and blog (public); input into AI features.

(3) Low risk (organisational 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 (Article 5(1)(c) UK GDPR).

(2) Special category data (Article 9 UK GDPR), in particular diagnoses, assumptions about illness, medication and injuries, as well as information about parental responsibility, family conflicts and protective orders, is entered only where there is a lawful basis 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 behaviour 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, including the ICO's guidance on monitoring workers.

(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 analyse 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 centre
• 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 (manager'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 recognisable 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 is a personal data breach (Article 33 UK GDPR).

(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 manager 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 manager wishes, it also goes by email to the parent address stored for the child (sender "[Centre 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 manager, 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 centre 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 authorised pickup persons

1. Subject matter and role of the software

(1) This annex describes the features "Permissions", "Consent by email", "Authorised 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 centre 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 centre has a fixed permission "Photo of the child on the centre'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 centre. Staff tick the box for the child in the admin. The time, the source "centre" 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 centre 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 centre; 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. Authorised pickup persons and handover

(1) The centre keeps a list of authorised 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 centre'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 authorisation 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 authorisation reads: "I/We, as parents or carers with parental responsibility, authorise [name] ([relationship]) to pick up [child's first name] at [centre name]. This authorisation is valid until withdrawn with the centre. The person picking up will show ID at pickup." [OPEN: confirm the English wording used in the UK build.] Name, relationship, authorisation 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 centre stores for the centre in the child record. They are sent in the centre's name (sender "[Centre 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 authorisations 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 parental responsibility, 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 centre'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 organisation 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 carer with parental responsibility and is updated when it changes;

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

d) information about parental responsibility, 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 official 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 authorised pickup persons are deactivated as soon as the authorisation 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, authorisations 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, parental responsibility or validity, delivering emails or preventing handovers.