Data Processing Addendum

At a glance

• Hosting and data location: Australian customers run on their own Australian infrastructure (region [OPEN: AU region, e.g. Sydney]). Databases, servers and the AI features (with one exception) are configured for Australia, subject to the Australian region of each provider being confirmed (Section 10). Email: [OPEN: does email stay in the EU for Australia?] (Section 11). Push notifications, wallet passes, optional AI image generation and the public centre websites use global infrastructure. The countries to which centre data may go are listed in Section 13.
• 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.
• Only to provide the service: the Customer is the APP entity that collected the information. Beenest handles it on the Customer's behalf, uses it only to provide the service, does not sell it and does not use it for its own purposes, advertising, direct marketing or training AI models (Section 13).
• Data breaches: Beenest notifies the Customer of a security incident affecting centre data within 24 hours so the Customer can assess it under the Notifiable Data Breaches scheme (Part IIIC of the Privacy Act) (Section 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). Material changes: email on the day they are published, one reminder after two weeks, a notice in the dashboard; the new processing stays technically locked until confirmed, and the rest of the software keeps working. New sub-processors: locked until confirmed (Sections 5, 9 and 15).

Parties

This Data Processing Addendum ("DPA") is entered into between the approved provider, operator or other organisation that operates one or more education and care services in Australia and accepts it (the "Customer") and Triple Peak Software Systems, a [legal form, e.g. LLC] organised under the laws of [state of formation], [registered address] ("Beenest", "we", "us").

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

In this DPA, "Privacy Act" means the Privacy Act 1988 (Cth), and "APPs" means the Australian Privacy Principles in Schedule 1 to the Privacy Act. "Personal information" and "sensitive information" have the meaning given in the Privacy Act; health information, such as allergies or disability-related support, is sensitive information. "Centre" means an education and care service the Customer operates (for example a centre-based service). "Centre data" means the personal information Beenest handles on the Customer's behalf when it provides the software.

1. Subject matter and duration

(1) Beenest handles centre data on behalf of the Customer to provide the Beenest childcare management software at [OPEN: AU app domain], including the Parent App and the Staff App.

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

2. Nature and purpose of processing

Processing covers the following operations:

• Real-time check-in and check-out of children by QR code and of staff by ID or pseudonym
• Automatic capacity calculation from the recorded attendance (database trigger)
• Real-time 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: AU domain for published centre websites] through Cloudflare Pages (global delivery network, because the site is public). The Customer alone decides content and images, including photos it uploads; it obtains any consent required to publish photos of people, in particular children.
• Transmitting aggregated counts to public authorities, 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 Australia, 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: available in Australia? GiroCode is an EU bank 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: available in Australia? 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 (Section 11)
• Technical error monitoring through Sentry, including session replay of the web app (masked; details in Section 5, item 9); in addition, the application's own error logs in the centre database, which may contain a person ID in context
• Reports and analyses, including spreadsheet export
• Staff time reports for directors 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 records as an approved provider, its safety, risk and insurance documentation and its quality work (Section 14)
• 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 rostering, 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.

Children

Children do not use the software. Data about children is entered by the centre or by parents.

Statistics and reporting fields and sensitive information (for example, health information such as allergies or disability-related support) are optional and collected only if the centre records them. Sensitive information is processed separately and with a higher level of protection. Obtaining any consent the APPs require for collecting sensitive information (APP 3), and giving the related notice, is the Customer's responsibility. 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 (including from sick notices, leaving early at the terminal and the weekly question about negative hours) are stored with a reason from a fixed list and an optional note: illness, child sick, medical appointment, pregnancy-related work ban, maternity protection, parental leave, carer's leave, resignation or termination, long-term absence, strike, annual leave, special leave, unpaid leave, training, time off in lieu, release from duty, regeneration or conversion day, part-time day off, work errand, business trip and free text; for single shifts also "unexcused" and "cancelled". [OPEN: the list mirrors the German catalogue; confirm the reasons and English labels in the Australian build.] Illness, child sick, medical appointment, pregnancy-related work ban and maternity protection are health information; strike can indicate trade union membership; both are sensitive information. Carer's leave and termination also deserve particular care.

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 area (staff planning with the admin password; reports with the staff password), in the operator area and in reports, exports and printouts (daily report, roster, weekly poster). Check-in and group tablets and the Staff App show other people's absences without a reason. The Customer decides who has access to these areas and printouts.

Parents and guardians (through the Parent App and API)

• Pseudonymous child ID (child code)
• Absence notices (child, date; without reason), meal cancellations, pickup notices including the person picking up, date and time
• Parent email addresses and phone number on the child record (operator address for documents and meal billing receipts; 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 director of an assigned centre (not a second contracting party, Section 15)
• 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, excursion, 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, 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 sensitive information

Group reports, daily reports and notes

• Group reports (daily report of a group), notes on individual children (child journal) and reports as free text, typed or dictated; stored in the centre database. Parents see an entry only if the Customer switches on display in the Parent App (default: off) and staff expressly release the entry; parents then receive a push notification without content. Dictation can be switched off (default: on). Free text may contain sensitive information (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, director 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 director's own style images for the website (image understanding on the Australian endpoint); image generation receives only an image description without personal information
• Website details entered by the director (texts, contact details, legal notices)
• Stored results under Annex 3 (history, confirmed actions, Schedule AI change sets, daily analyses, monthly reports)
• Account-level record of the AI notice confirmation (timestamp and text version)

4. Beenest's obligations

(1) Instructions. Beenest handles centre data only on the Customer's documented instructions, including the settings the Customer chooses in the software, unless a law Beenest is subject to requires otherwise. In that case Beenest tells the Customer about the legal requirement before processing, unless that law prohibits it. Beenest tells the Customer without undue delay if it believes an instruction would breach the Privacy Act or another privacy law that applies.

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

(3) Security. Beenest takes reasonable steps to protect centre data from misuse, interference and loss, and from unauthorised access, modification or disclosure, so the Customer can meet APP 11. The measures take into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing, and are described in Section 5.

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

(5) Access, correction and complaints. Taking into account the nature of the processing, Beenest assists the Customer with appropriate technical and organisational measures in responding to requests from individuals to access their personal information (APP 12) or to correct it (APP 13), and in handling privacy complaints. The software provides exports and correction functions for this. If Beenest receives such a request or complaint directly, it passes it to the Customer without undue delay and does not respond on its own, except to tell the person that it has been passed on.

(6) Assistance with security and assessments. Taking into account the nature of the processing and the information available to it, Beenest assists the Customer with its obligations regarding the security of centre data, the assessment and notification of data breaches under Part IIIC of the Privacy Act, and any privacy impact assessment the Customer carries out.

(7) Security incidents and eligible data breaches. Beenest notifies the Customer of a security incident affecting centre data without undue delay and no later than 24 hours after becoming aware of it, so the Customer can promptly assess whether it is an eligible data breach under Part IIIC of the Privacy Act and, if so, notify the Office of the Australian Information Commissioner (OAIC) and the individuals concerned. A "security incident" is any unauthorised access to or unauthorised disclosure of centre data, any loss of centre data, or any other breach of security affecting centre data, whether or not it turns out to be an eligible data breach. The notice contains at least, as far as known:

• a description of the nature of the incident
• where possible, the kinds of information and the approximate number of people and records affected
• a description of the likely consequences, including the risk of serious harm as far as Beenest can judge it
• a description of the measures taken or proposed, including steps to contain the incident and reduce harm

Beenest provides further information as it becomes available, takes reasonable steps to contain the incident and to reduce the risk of harm, and cooperates with the Customer's assessment. Whether an incident is an eligible data breach is decided by the Customer. Beenest does not notify the OAIC or affected individuals on the Customer's behalf unless the Customer instructs it to or the law requires it.

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

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

5. Technical and organisational security measures

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

Changes to the measures fall into two groups:

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

1. Logical access control

Supabase Auth with JWT and automatic token refresh; row-level security (RLS) on all database tables; column-level security on the 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 information only on a need-to-know basis, limited to maintenance, support and troubleshooting.

4. Transmission control

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

5. Input control

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

6. Availability

Supabase managed database (Australia, [OPEN: AU region, e.g. Sydney]) 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.), location [OPEN: confirm AU region for Sentry; if none, name the region used]. 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 15, paragraph 3.

6. Customer's rights and obligations

(1) The Customer is the APP entity that collects centre data and holds it within the meaning of the Privacy Act. It decides the purposes and means of processing, remains responsible for complying with the APPs and decides what data is entered into the software.

(2) The Customer is responsible in particular for:

• its privacy policy under APP 1 and the collection notices under APP 5 to parents, staff and other individuals. The Parent App and Staff App notices Beenest provides describe the apps; they do not replace the Customer's own notice, which gives the Customer's identity and contact details, its purposes and how to complain to it
• obtaining consent where APP 3 requires it for collecting sensitive information, for example health information about children or sick notices of staff
• its overseas disclosures under APP 8; the Customer remains accountable for them (Privacy Act, s 16C). The countries in Section 13 are listed so the Customer can name them in its notices and privacy policy
• assessing suspected eligible data breaches and notifying the OAIC and individuals under Part IIIC of the Privacy Act
• giving staff any notice of workplace surveillance that state or territory law requires of employers, and consulting them where required. In the Australian Capital Territory, for example, an employer must give workers written notice at least 14 days before surveillance starts and consult them in good faith during that period (Workplace Privacy Act 2011 (ACT), s 13 to 16). Other states and territories may have their own rules [OPEN: which state and territory workplace surveillance laws apply, and whether the Staff App, time tracking or check-in counts as surveillance under them]
• deciding whether it can rely on the employee records exemption of the Privacy Act for staff data. The exemption covers a private sector employer's handling of an employee record directly related to a current or former employment relationship; it does not cover contractors, subcontractors or volunteers. Beenest handles all staff data under this DPA regardless
• complying with any state or territory health records law that applies to health information it holds (for example in Victoria or New South Wales) [OPEN: confirm which state health records laws apply to private centres and whether this DPA needs clauses for them]
• carrying out any privacy impact assessment it chooses or is required to carry out
• 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, parenting orders and other custody arrangements, 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 director 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 15, which captures the name and account of the confirming person.

7. Audits and evidence

(1) The Customer may verify compliance with this DPA and the Privacy Act. 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-keeping obligations for centre data, in particular under the Education and Care Services National Law and National Regulations (for example the storage and retention periods in r 183 for the records listed in r 177, which include the attendance record) and under tax or funding rules, rest solely with the Customer. Beenest stores the data only for the term of this DPA and as the Customer instructs; Beenest has no legal retention obligation of its own for centre data. When the Customer no longer needs information, it decides whether it is destroyed or de-identified (APP 11.2); Beenest carries out that decision.

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

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

(4) Beenest deletes all 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 Australian devices loaned or sold? If sold, drop this paragraph.]

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

• Consent requests by email: recipient address and the link's check value are deleted on confirmation, when replaced by a new request, or at the latest about one hour after the one-hour link expires; unconfirmed requests after 30 days; confirmed requests stay as evidence. The send log of permission and recording requests stays until the Customer deletes it, at the latest until the agreement ends.
• Consents to recording a parent meeting that no recording used: after 30 days, with the signature image; used consents stay with the meeting until the Customer deletes it.
• Audio file of a parent meeting: immediately after evaluation.
• Photo of a child: on withdrawal of the permission, at the latest at the daily reconciliation.
• Applications in the 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 authorises the sub-processors listed in Annex 1.

(2) Any addition or replacement of a sub-processor is technically locked until the contracting person has read the updated agreement (including the changed annex) and confirmed it by checkbox. No personal information flows to the new or replacement provider before that confirmation. There is no 14-day objection period without a lock. Until confirmation, only the previously authorised sub-processors are used. The same applies if a sub-processor's location changes to a country not yet listed in Section 13.

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

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

10. Data location

(1) Storage locations: centre data is stored in Australia, with the exceptions in paragraph 2 and Section 11. As of this DPA, the sub-processors are configured as follows; the Australian region of each is still to be confirmed where marked:

• Supabase: Australia (AWS, [OPEN: AU region, e.g. Sydney]): database, authentication, realtime, storage, backend functions; main location of all core data
• Vercel: Australia [OPEN: confirm AU region]: hosting, serverless functions
• Cloudflare: Australia [OPEN: confirm AU region for the API relay and for Cloudflare KV]: 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
• Sentry: [OPEN: confirm AU region]: error monitoring and session replay of the web app (masked)
• Google Cloud (Vertex AI / Gemini): Australian region [OPEN: Vertex AI region or endpoint for Australia]: all AI data flows except image generation, only with AI features switched on (Annex 3)
• Zoho and Brevo: email, see Section 11

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

(2) Global infrastructure: the following data flows can run through infrastructure outside Australia 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 Australian 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. 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 the image models in the Australian region [OPEN: confirm for the Australian region]; there is therefore no Australian residency commitment for this flow. Only image descriptions without personal information 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 Australian region, the user's free text and reference images also go there; they must not contain personal information (Annex 3, Section 3, item 19). Can be switched off individually; details in Annex 3
• 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.

11. Email

Two providers handle email. [OPEN: does email stay in the EU for Australia?] If it does, the locations are those of the German product:

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

The data involved is email addresses and the content of those emails. Centre data otherwise stays in Australia (Section 10). If email moves to Australian regions instead, this Section and Annex 1 are updated under Section 15 [OPEN: confirm AU region for Brevo and Zoho, if any].

12. Liability

Each party is liable for damage caused by its own breach of this DPA or of the Privacy Act. Beenest is responsible for the acts and omissions of its personnel and of the sub-processors it engages as for its own. Liability under this DPA is subject to the limitations of liability in the Terms. Nothing in this DPA excludes, restricts or modifies any right or remedy under the Australian Consumer Law that cannot lawfully be excluded, restricted or modified. [OPEN: should DPA liability be capped by the Terms, carved out, or subject to a separate cap?]

13. Privacy Act: Beenest's commitments and overseas disclosure

(1) Role. For centre data, the Customer is the APP entity that collected the information. Beenest handles it only on the Customer's behalf, as its contracted service provider. Beenest complies with the APPs in handling centre data, to the extent they are relevant to that role, whether or not it is itself bound by them. [OPEN: does Triple Peak rely on or opt out of the small business exemption?]

(2) Limited purposes. Beenest uses centre data only to provide, secure, maintain and troubleshoot the software for the Customer, as described in Sections 1 and 2 and Annexes 2A to 5.

(3) Restrictions. Beenest will not:

a) sell centre data or give it to third parties for their own purposes;

b) use centre data for advertising or direct marketing, or to train AI models;

c) use or disclose centre data for any purpose of its own or other than those in paragraph 2;

d) disclose centre data to anyone except its sub-processors under Annex 1, recipients the Customer instructs, or where the law requires it; in the last case Beenest tells the Customer first, unless the law prohibits it;

e) combine centre data with personal information it receives from or on behalf of another customer, or collects from its own interaction with an individual, except where needed to provide the software to the Customer.

(4) Notice if Beenest can no longer comply. Beenest notifies the Customer without undue delay if it determines that it can no longer meet its obligations under this Section.

(5) Overseas recipients and likely countries (APP 8). Centre data is stored in Australia (Section 10). It may be disclosed to or accessed from the following countries:

(6) Steps Beenest takes. To support the Customer in taking reasonable steps to ensure that overseas recipients do not breach the APPs (APP 8.1), Beenest:

• has a written contract with each sub-processor under Section 9, paragraph 4; Apple offers no such contract for APNs, and the basis is the Apple Developer Program License Agreement, Attachment 1 (Annex 2A, Section 4)
• uses transport encryption (TLS 1.2/1.3) for all transfers
• stores no core centre data outside Australia (storage locations in Section 10, paragraph 1, exceptions in paragraph 2 and Section 11)
• pseudonymises where technically possible (for example child codes instead of names in the Parent App)
• minimises data to what each purpose needs: AI image prompts without personal information (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 AI privacy level (Annex 3)
• limits push payloads by type (Annex 2A, Section 2 and Annex 2B, Section 2); free text is intended to contain organisational and, for staff, working-time information, not sensitive information about children. 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
• sends error events without chat, prompt or audio payloads and masks session replay (Section 5, item 9)

(7) If an overseas recipient can no longer be used lawfully, Beenest takes at least one of the following measures and informs the Customer at least 14 days in advance: migration to a replacement provider in Australia, where technically and economically available; switching off the service concerned where technically reasonable, in particular optional Parent App features (push notifications, wallet passes) and individual AI data flows including image generation; or further safeguards (for example client-side encryption) that keep the service working. Push notifications (FCM, APNs, Expo) and optional AI image generation can be switched off without affecting the core product.

(8) Customer's decision. The Customer remains accountable for overseas disclosures of centre data under the Privacy Act. It decides whether to use the optional flows in Section 10, paragraph 2, and parents and staff decide on their device whether to allow push notifications.

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

14. Australian sector rules

(1) Education and care services. Where the Customer is an approved provider under the Education and Care Services National Law, its duties under the National Law and the National Regulations stay with it, in particular the children's attendance record (r 158), the storage and retention of records (r 183), notifying the Regulatory Authority of serious incidents (r 176) and notifying parents of incidents, injuries, trauma and illness (r 86). The software helps the Customer document attendance and handovers. It does not notify the Regulatory Authority or parents of incidents on the Customer's behalf. Whether records kept in the software meet these requirements (for example the signature requirement of r 158) is for the Customer to decide.

(2) Coverage of centres. The OAIC lists childcare centres as health service providers, so the APPs apply to a centre whatever its annual turnover. A centre run by a state or territory government body may be subject to a public sector privacy law instead [OPEN: does this DPA need a clause for government-run services?].

(3) Children. The software is not directed at children, and children do not use it. Information about children is entered by the centre or by parents.

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

15. Conclusion and acceptance

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

• Centre assigned to an operator: the operator alone is the contracting party and the Customer. The person signed in to the operator account confirms with a checkbox that cannot be bypassed in the admin interface (desktop). Check-in terminals do not show this dialog. The director of the assigned 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 director 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 director), type of action (contract or acknowledgment), timestamp, the version number of this DPA including its annexes (Annexes 1, 2A, 2B, 3, 4 and 5) and the previously confirmed version.

(2) On the day a new version is published and with every confirmation under paragraph 1, the contracting person receives the complete documents by email: this DPA with all annexes in the relevant version and, after confirmation, the confirmation records (name, email, role, timestamp). The emails also contain download links to the same versions. The same version can be downloaded, viewed and saved on the website at any time (print function). No separate paper copy is mailed. Pending confirmations and changed versions are shown in the dashboard of the contracting person (operator dashboard if assigned to an operator, otherwise the 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 information flows into the new processing only after this confirmation. Until then the previously confirmed version applies. If the change concerns a new or replacement sub-processor, the technical lock under Section 9, paragraph 2 also applies.

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

• Clarifications of the description in this DPA and its annexes: wording that describes an already agreed processing more precisely (for example, naming specific fields, storage locations or flows that are already part of the agreement), and corrections of typos and cross-references. Clarifications change neither subject matter, purpose, type of data or data subjects, nor sub-processors, storage locations, the level of protection of the security measures or the rights and obligations of the parties. Each clarification is documented with its date; the current version is available at /au/dpa.
• Changes to the security measures under Section 5 that collect no new personal information 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 parties agree that the electronic confirmation together with the email under paragraph 2 satisfies any requirement that this DPA be signed or in writing, to the extent the law allows [OPEN: confirm under the Electronic Transactions Act 1999 (Cth) and the state and territory equivalents].

16. Final provisions

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

(2) If any provision of this DPA is held invalid or unenforceable, the rest of the DPA remains in effect. The invalid provision is read down or severed to the extent necessary, and the parties replace it with a valid one that comes closest to its intended purpose.

(3) This DPA is governed by the laws of [governing law, state or territory]. The parties submit to the courts of [courts of that state or territory]. [OPEN: exclusive or non-exclusive jurisdiction?]

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

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

Annex 1: Sub-processors

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

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]; 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 that the APPs require (in particular the Customer's own APP 5 notice) is the Customer's responsibility and decision. Sections 4 and 5 of this annex (push services, wallet, sub-processors) also apply to the Staff App (Annex 2B).

1. Voluntary use

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

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

(3) The Customer decides whether it relies on parental consent for handling information through the Parent App, and obtains consent where APP 3 requires it. 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 Australia?]
• 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 Australian 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, Australia, Annex 1).

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

(1) Group message. Recipients: Parent App devices of the 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.

(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 Australian database. Response actions (Annex 4, Section 5, paragraph 7) go through the encrypted API, not through push.

Absence notices, meal cancellations and pickup notices go through the encrypted API (Cloudflare worker to Supabase), not through push payloads. The push notification is the trigger; the app loads content from the Australian 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 Cloudflare, Expo, Google (Firebase Cloud Messaging, Google Wallet) and Apple (APNs), listed in Annex 1. A separate data processing agreement is in place with Cloudflare, Expo and Google.

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

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

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

Overseas recipients: Expo, Firebase Cloud Messaging, Apple Push Notification service and Google Wallet operate outside Australia (Section 13, paragraph 5). If one of them can no longer be used lawfully, push notifications or wallet passes can be switched off without affecting the core product (Section 13, paragraph 7).

5. Reference

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

Annex 2B: Staff App (iOS and Android)

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

1. Basis and voluntary use

(1) Processing takes place within the employment relationship between the Customer and its staff. The Customer is responsible for the notices to staff that the law requires, including any workplace surveillance notice and consultation (Section 6, paragraph 2), for deciding whether the employee records exemption applies, and for the handling of sick notices and other health information, which is sensitive information. Contractors, subcontractors and volunteers who use the Staff App are not covered by the employee records exemption.

(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 director to an individual person, replies to working-time requests and own upcoming staff appointments
• Wallet staff badge
• Push notifications: capacity light (Annex 2A, Section 2) and team chat, calls, automatic notices, event reminders, inbox, working-time confirmation and end of care hours (see below)

Data 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 "Work devices" mode it may show names of children in the person's own group where a feature needs them. It shows child codes in neither mode. Free text from colleagues or the director and the topic of a meeting named by parents may contain information about children in both modes. Centre data is not stored on the device but loaded from the Australian 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, Australia, Annex 1) and from there to Supabase, not through Cloudflare. Push notifications go through the Cloudflare push worker (Annex 2A).

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

• Chat push: title = name of the author, text = chat text (shortened). Recipients depending on the tag: the whole team, the staff of a group or the persons mentioned; no push without a tag. This includes posts the director confirms through the Autopilot.
• Time corrections from the Staff App go to the director as an adjustment request, not into the team chat; the feature exists only if clocking in and out in the app is switched on.
• Calls: push "[name] is calling you" with a reason, only to the person called, who must be checked in.
• Automatic notices (sender "Automatic notice"), each rule switchable in the chat settings. Defaults: required break off, "daily working time reached" on, "scheduled but not here" on (only with staff scheduling active). "Not checked out" serves complete attendance documentation and cannot be switched off. The notices name the person concerned and are visible in the team chat. The push for required break, "daily working time reached" and "not checked out" goes only to the person concerned; for "scheduled but not here" to the staff of the group.
• Event reminders name only type, time and group.
• Inbox: the director writes a direct message to an individual person in the web app; only that person reads it in the Staff App. Sending and deleting require the admin password. No reply function, no email. Messages stay stored until the Customer deletes them; there is no automatic deletion. Push "New message in your inbox" without sender and without content.
• Working-time confirmation: push to the person after clocking in, out or switching in the app, with event and time, without names.
• End of care hours: from 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 information)
• Team daily plan: names, shifts, breaks and current attendance of colleagues; absence reasons only for the person's own absences
• Chat messages (content, sender name or initials), pinboard posts, poll votes, messages to parents
• Inbox: direct messages from the director (recipient, title, text, time)
• In "Work 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) Work devices: by choosing this mode, the Customer declares that the app runs only on its own devices, and chooses it only in that case. The app may show names of children in the person's own group where a feature needs them; as of this DPA no feature does so yet, the first planned is requesting a parent meeting. In the team chat, children may be named where needed for the daily routine; health information, information about child protection cases or custody does not belong there either. Beenest recommends the AI data guard in the team chat in this mode too.

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

(2) Devices. The Staff App can be used on the Customer's devices and, where the Customer allows it, on staff members' personal devices. Beenest recommends using it only on 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 director), and that not using the app leads to no disadvantage.

(4) Information. The Customer informs staff before first use (APP 5), 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 directors, and time tracking, Schedule AI, daily analysis, operator Autopilot and the attendance patterns of the AI features (Annex 3, Section 1, paragraph 14). If the Customer introduces the Staff App or any of these features, it gives any workplace surveillance notice and carries out any consultation that state or territory law requires (Section 6, paragraph 2), meets any consultation duty under an applicable award or enterprise agreement [OPEN: confirm consultation duties under the Fair Work Act 2009 and the relevant award or enterprise agreement], and sets the switches under paragraph 1 accordingly.

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

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

(9) Lock screen. Push content may be visible on the lock screen and remain in the notification 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 Cloud (Vertex AI / Gemini) [OPEN: Google contracting entity for Australia]. The contractual basis is the Vertex AI data processing addendum. Authentication is without API keys, through Workload Identity Federation (Vercel OIDC); local development through Application Default Credentials (ADC). Hosting of the calling application: Vercel (Annex 1).

(2) Data residency: all data flows except image generation run in the Australian region [OPEN: Vertex AI region or endpoint for Australia, and whether Google contractually limits processing to Australia].Exception image generation: Google does not provide the image models in the Australian region [OPEN: confirm for the Australian region]. This flow uses the global endpoint; there is no Australian residency commitment for it. The global endpoint receives only image descriptions without personal information (style, colour and design details including the centre name, and a description of objects without people created beforehand on the Australian 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 an image generator model outside the Australian 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; fast tasks such as dictation, translation and checks gemini-3.5-flash-lite and gemini-3.1-flash-lite; Claude Haiku 5.5 by Anthropic (claude-haiku-5-5, in Google Cloud's Model Garden; Google remains the contractual partner); image generation gemini-3.1-flash-image and gemini-3.1-flash-lite-image (global). [OPEN: confirm each text model, including Claude Haiku 5.5 in Model Garden, is available in the Australian region.] A switch to another model of the same sub-processor on the same endpoint is documented as a clarification under Section 15, paragraph 4.

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

(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 educators appear only as codes (for example, "Child 7F3A", "Educator K2QM"); c) "All": real names of educators 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 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 directors run only at the level "All"; the AI helper for educators 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 information. Google sees inputs only transiently, subject to abuse review under paragraph 4. Users control free text and uploads; the interface asks them not to enter health information, but whatever is entered or uploaded is transmitted. The Customer instructs its users accordingly. Buttons that trigger an AI feature are marked consistently in the admin interface (purple with a sparkle icon).

(8) Switches: in addition to the level, the 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 Australia (currently image generation including preview images for hazard topics and the image generator models outside the Australian region) and switch off the monthly report. If the software cannot read an operator lock, the lock is treated as set. An operator maximum level of "Off" switches off the features in paragraph 6, first sentence, not the features controlled by their own switches. The help chat and the DPA chat, which process no operating data, cannot be switched off. Features that work only when a user expressly calls them transmit nothing while unused. The hazard AI and the handbook draft currently have no switch of their own. Beenest can switch off individual AI features at any time for security or operational reasons.

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

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

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

(12) Storage at Beenest (servers in Australia): 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 educator-to-child ratios to protect the children, time tracking and payroll, and compliance with workplace laws on working time. 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 judgments, no rankings, no comparisons between people, no assumptions about reasons or health. Schedule AI plans from contracts, absences, qualifications and need. The Customer remains responsible for notices and consultation towards its staff (Annex 2B, Section 4, paragraph 6) and can set the AI privacy level accordingly.

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

a) always: health information about children or staff and other sensitive information, suspected child protection cases, information about parental responsibility, parenting orders and other court orders, protection orders and family conflicts, credentials (passwords, PINs, QR and child codes), bank, ID, tax and social security numbers, and assessments of individual employees (paragraph 14);

b) depending on the effective AI privacy level: at "Pseudonymised", names of employees and children; in the Staff App AI helper for educators, 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 Australian 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: director's questions, page path and tool outputs, that is key figures (capacity light, capacity, attendance by category, understaffing, planned vs. actual, opening hours, thresholds, care models), records per person (attendance, events, shift and break plans) according to level, group and care model names, and team free text (Section 1, paragraph 6). With "Custom export", the AI writes a calculation that Beenest runs in an isolated environment on the 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 director's agreement; not at level "Off"). Inputs as item 1. Recipient: director by email. Storage under Section 1, paragraph 12 c.

4. Staff App AI helper (only after the 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 educators always with codes, for directors with staff names at the level "All". Free text under Section 1, paragraph 6. No storage at Beenest.

5. Operator Autopilot (operator area, only users with operator role). Inputs: operator users' questions and tool outputs about the assigned 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 director'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 Australian endpoint, and only this description goes to image generation. Design and texts on the Australian 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 information, no photos. Global endpoint (Section 1, paragraph 2).

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

16. Floor plan from photo, hazard AI and handbook draft. Floor plan: a photo of a room sketch (it may show people if they are in the picture), not stored. Hazard AI: topic and team notes as written; the result is suggestions that the director must accept. Handbook draft: up to five photos of a printed guide or a description by the director; photos are not stored.

17. AI translation (switch "Translation", default on; effective only at the level "All" and where the operator's maximum level allows it). Content is translated into the parents' language stored by the 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 Australian 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 director's click back into the centre's language. Processing on the Australian 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 director can send a flagged text, after entering the admin password again. If the check is not possible, the text is sent and a notice is shown. Texts are not stored; only the event is counted, without text and without person. A direct message from the director to an individual person (Staff App inbox, Annex 2B, Section 2) is checked as well. In the team chat, the data guard checks only if the Customer also switches on "AI data guard in team chat" (default off); then also messages from the Staff App. There only the AI check runs, without the name check, and without AI credits there is no check. On a finding, the message is not sent; the author can change it or send it anyway. Other texts from the Staff App, including calls and messages to parents, are not checked. The check is not complete and does not change Annex 4, Section 5, paragraph 5.

19. Image generator (only after the operator enables it, default off, and the 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 Australian region or outside it (global endpoint, Section 1, paragraph 2, no Australian residency commitment). Free text and reference images go unchanged to the chosen model. Reference images must not show people or any other personal information (allowed are, for example, freely usable images from the internet or own images without people); the free text contains no names and no descriptions of real people. This duty lies with the users (Annex 4, Section 3); the software does not check reference images. Generated images are downloaded to the user's device; generated images and reference images are not stored at Beenest. The operator's lock on image AI outside Australia switches off all models outside the Australian 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 Australian endpoint (Section 1, paragraph 2).

4. Customer obligations

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

(2) Where sensitive information may be involved (in particular dictation, parent meeting and team free text), the Customer is responsible for any notice or consent the APPs require (APP 3 and APP 5).

(3) State and territory laws on listening and surveillance devices regulate recording private conversations [OPEN: confirm the consent rules per state and territory]. Recordings of meetings (Section 3, item 11) require the consent of all participants. The software checks only whether stored consents under Section 3, item 11 exist; obtaining the consent of everyone present, including staff, is the Customer's responsibility.

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

5. Reference

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

Annex 4: Free-text fields

1. Definition

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

2. Overview by risk

(1) High risk (content about individual children, health or employee 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 director that feed into reports and analyses for the operator
• Input into the email helper
• Notes on pickups and meal cancellations, other staff absence reasons

(2) Medium risk (personal reference likely, limited audience): reasons for time corrections, shift and report notes; events for parents and staff; 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.

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

(3) Assessments of the performance or 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.

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

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

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

(5) The Customer instructs its staff to be extremely restrained in texts to all, to groups and to the public: no names or 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 may be a security incident and an eligible data breach under Part IIIC of the Privacy Act.

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

(7) Family message. a) Sending: the director chooses a child and writes a text; before sending, the software clearly shows the chosen child. The message appears in the Parent App on that child's devices (push under Annex 2A, Section 2 (7)). If the director wishes, it also goes by email to the parent address stored for the child (sender "[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 director, in the app or through a time-limited link in the email: "OK" (acknowledged), "Accept", "Appointment" (choosing a proposed time) or "Join" (RSVP to a 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 guardians, 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 Australian 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) parental responsibility, parenting orders and other court orders, or protection orders, and their scope;

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 guardian 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, parenting orders and other court orders, and protection orders is taken into account outside the software or in a field intended for it (Annex 4, Section 3, paragraph 2);

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

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

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

h) withdrawals are entered without delay and 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.