Privacy Policy

1. Who we are and what this policy covers

Beenest is software for education and care services ("centres"). It is provided by Triple Peak Software Systems, [legal form, e.g. LLC] organised in [state of formation], [registered address] ("Beenest", "we", "us"). We are not an Australian company. Privacy contact: [privacy contact email]. General contact: hello@beenest.co.

This policy explains how we manage personal information under the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs): the kinds of personal information we collect and hold, how we collect and hold it, why we collect, hold, use and disclose it, how you can access and correct it, how you can complain, and whether we disclose it overseas. We apply the APPs to the information described here. [OPEN: does Triple Peak rely on or opt out of the small business exemption?]

We handle personal information in two different roles:

• Beenest decides. For visits to beenest.co, contact and sales inquiries, customer accounts, billing and support, we decide why and how the information is used. This policy is our notice for that information.
• Beenest acts for the centre. When an approved provider, centre or operator (the "Customer") uses Beenest, the information the centre and its staff, parents and other users enter about children, families and staff ("Centre Data") is the Customer's. We hold and handle Centre Data only to provide the platform to the Customer and on its instructions, as its service provider. The Customer decides what is entered and is responsible for its own collection, use and disclosure under the Privacy Act, and its own privacy policy and collection notices apply to Centre Data. Our obligations to the Customer are in the Data Processing Agreement (DPA) and the Terms of Service.

The Customer is responsible for the collection notices (APP 5) and consents that the law and its regulatory requirements require toward parents and staff, including consent to collect sensitive information such as health information (APP 3). Sections 2.4 to 2.10 describe what the platform does with Centre Data so that centres, parents and staff can understand it; they do not replace the centre's own notice. We provide a template for the centre's privacy information on the platform [OPEN: is the DE template available and adapted for Australia?]; the centre remains responsible for its completeness and accuracy.

2. Kinds of personal information we collect and hold

2.1 Visits to beenest.co

beenest.co is hosted by Netlify, Inc. (United States). When you open a page, Netlify automatically records server log data:

• IP address
• Date and time of access
• Requested URL and referrer URL
• Browser type, operating system and device information
• HTTP status code and amount of data transferred

We use this to deliver the site, keep it secure and stable, and detect abuse.

The website's fonts are served from our own host, so your browser does not contact a font provider.

Analytics and marketing, only with your consent. The home page, the pricing page and some product pages show a cookie banner. Nothing beyond the necessary storage of your choice runs until you agree. If you accept analytics, we load Google Analytics (Google LLC), which collects pages visited and navigation paths, session duration, approximate location (country or city level, derived from the IP address), device type, browser and screen resolution. If you accept marketing, we load the Meta Pixel (Meta Platforms, Inc.), which collects page views, interactions, referral source and device information to measure ad campaigns and deliver relevant ads. See Sections 8 and 9. Pages without the banner load neither service.

2.2 Contact and sales inquiries

The contact form on beenest.co asks for your name, email address, organisation, country or region and your message. It also sends the site version you used (market and language) and contains a hidden anti-spam field that people do not fill in. Submissions are received and stored by Netlify Forms (Netlify, Inc.). If you email us, we receive your email address, name and whatever you write.

We use this information to answer your inquiry, give you information about Beenest and prepare a consultation you asked for. We do not use it for marketing without your separate consent.

2.3 Customer accounts and billing

• Name, email address, password (stored in hashed form), and where provided phone number and organisation
• Account information such as role and the centres an account belongs to
• Subscription, order and AI credit information, and billing history

Operator accounts. An operator account can see the data of the centres assigned to that operator. Account holders can invite more users by email; after accepting, those users have the same access and can view and edit the data of those centres. Nobody can see another operator's data. Inviting users and assigning access is the Customer's responsibility.

Card payments. If a Customer pays its subscription fees by card, Stripe [OPEN: Stripe contracting entity] processes the payment. Stripe receives the name, email address, billing details and card data; only Stripe receives the card data, we do not. Stripe receives only the Customer's contract and payment data, never data about children, parents or staff, and it is not a sub-processor of Centre Data.

2.4 Centre Data we hold for centres

Which fields are required and which are optional is set out in the DPA. A child's full name is not required; if it is left empty, the software shows "No name". The age group follows from the date of birth. For each staff member, a name or initials, an identifier or pseudonym, check-in and check-out timestamps and, where configured, the staff type are required. Centre and configuration data (for example thresholds, opening hours, meal cancellation deadlines, operator rules) is optional. Depending on what the centre uses, Centre Data can include:

• Child records: names, date of birth, type and mode of care, group membership; optional identifiers the operator uses and the care period (start and end of enrolment)
• Further child details: gender, booked care hours, lunch participation, school attendance, weekend care, admission, exit and archiving dates; optionally email addresses and phone number of parents or guardians on the child record (for documents and meal billing receipts, the QR letter, consent requests and confirmations of meeting appointments)
• Attendance times (drop-off and pick-up via the sign-in terminal)
• Discarded check-in actions, which are deliberately kept after the person is deleted (see Section 10)
• Staff working and attendance times (terminal, remote check-in and time reports in the staff app), including a work location flag per timestamp (remote, excursion, off site)
• Staff time reports for directors and operators (per centre and across centres, including export); staff can see their own times
• Staff records and planning: staff type, employee number, contract data (start date, fixed term, end date, third-party employment, mentoring, work areas), daily, weekly and monthly working hours, planned shifts, absences, roster templates, hours balance, staff app session data (stored hashed)
• Optional free-text notes about a child, also visible to staff in the group view; what they contain depends on what is entered
• Optional photo of a child so staff can recognise the child, only if the parents have given the permission "Photo of the child on the centre's devices"; it is not processed with AI and is deleted if the permission is withdrawn
• Allergies and intolerances (health information, which is sensitive information under the Privacy Act) and an optional meal note in free text (in practice allergy and diet information); if the operator activates supplier access, these go to the meal supplier the operator names
• Email addresses of parents or guardians and a send log (which document was sent to which address and when)
• Group reports, daily reports and incident notes in free text. Parents see daily reports and child notes in the parent app only if staff explicitly choose "Share with parents" and the centre has turned on display in the parent app (off by default)
• Permissions per child with when and how they were given (by the centre or the parents, with the wording) and withdrawn; parent consents confirmed by email. Confirming stores neither name, IP address nor device; the confirmation is proven by the stored address, not the person
• Authorised pickup persons (name, relationship, source; if reported by parents, the authorisation text and time of confirmation; the time an ID was checked, without ID data), reported pickups and handover records (person picking up, reason for an exception, confirming staff member, time)
• Events with acceptances and declines per child; meeting requests and staff appointments; room bookings
• Poll votes with a device ID (one vote per device, to prevent multiple votes)
• Application error logs of the software, where the context contains a person ID (in addition to Sentry, see 2.8)
• Interactions within the app, timestamps
• Optional: parent payments and membership fees (payment items, reference code, cash payments with the name or initials of the person who took them, invoice recipient) and, with a bank connection, amount, booking date and reference of transactions that are or should be matched to a parent payment (the payer's name and account number are processed only while fetching, not stored) [OPEN: available in Australia?]
• Optional: recording of a parent meeting with prior consent (name, role, signature or confirmed email); the recording is deleted after it has been analysed
• Optional (operator): applications for a place through the enrolment portal

The platform processes this data to run the centre's daily operations, document attendance and capacity, communicate with parents (including documents and meal billing receipts) and manage meals, as the Customer instructs.

2.5 Communications

• Messages between the centre and parents, including to a single family (in the parent app and, if the centre chooses, by email in the centre's name). Parents reply only with a set action ("OK", "Accept", "Appointment", "Join") with a timestamp, not free text. Parents give permissions only by confirmed email.
• Meal cancellations and other notices through the parent app
• Documents sent to parents by email (address on the child record), with a send log
• Internal staff chat (content, timestamp, sender name or initials). It is not meant for sensitive content. It is deleted automatically after the retention the centre chooses (1 to 7 days, default 1 day) at midnight in the centre's time zone; pinboard messages are exempt. Per rule, the centre decides whether the system posts automatic working time notices to the chat (mandatory break off by default; "planned but not here" and "daily working time reached" on by default; "not checked out" always on). These notices name the person and are visible to the team. Time corrections from the staff app go to the director as an adjustment request, not to the team chat.
• Emails to parents in the centre's name: QR letter (with or without the parent password, as the centre sets), consent requests, confirmation of an agreed meeting. They are sent as "[centre name] via Beenest" to the one address the centre stored for the child. The software does not track whether they are delivered. Permission and recording requests are logged with the recipient address.
• Messages between the centre and the operator, including email copies to the centre's distribution list and forwarding by the operator
• Contact requests and support messages
• Uploaded files (for example documentation)

Free-text fields. In many places users can type freely: notes, messages, reasons, chat. The content depends only on what is written and can in some cases include health information or information about other people. Next to fields the AI assistant can read, the interface asks users not to enter health information; the text is transmitted and stored as written. The centre instructs its users what belongs in free text. We do not analyse free text for our own purposes. Who can read it and when it is deleted depends on the feature (see the DPA). Free text appears to parents or on the centre's website only after the centre explicitly releases or publishes it.

2.6 Device and session data

• Browser type, operating system, device identifier
• Device ID for poll votes (only to ensure one vote per device)
• Session IDs
• Pseudonymous push tokens (when notifications are enabled); in the parent app linked to groups and the child identifiers stored on the device

To protect against password guessing, after a failed attempt we store for about one hour a one-way hash of the network and of the wrong value entered, not the IP address or the value itself.

2.7 AI features

Beenest offers AI features in the admin interface, the operator area, on the group tablet (voice dictation) and, only if the centre turns it on, in the staff app. The sign-in terminals have no AI features; the parent app has only AI translation, and only at the "All" level. Each feature can be switched on and off.

What the AI learns about people is set by the centre's AI privacy level: "Off", "Pseudonymised" (children and staff only as labels such as "Child 7F3A") or "All" (real names of staff and children; the default, and a later switch back to "All" must be confirmed separately). The operator can set a maximum level; the lower level applies. The level governs the features that read operating data (Autopilot, roster AI, daily analysis, staff app AI helper, operator Autopilot, monthly report). What the team writes itself (team chat, pinboards, notes, events) is read by the AI at every level except "Off", as written, including names in it. Absence reasons are never sent to the AI linked to a person.

Features that only process what you type, say or upload (dictation, email helper, parent meeting, AI text drafts, website builder, floor plan, hazard AI, handbook draft, help and DPA chat) do not depend on the level: data goes to the AI only when you call the feature yourself; if you do not use it, nothing is sent. The website builder, voice dictation (and with it the email helper, parent meeting and AI text drafts) and floor plan can also be switched off; image generation and the staff app AI helper run only after being switched on. AI features are marked the same way throughout the software (purple buttons with a sparkle icon).

Protection for inputs. You or your centre are responsible for what you enter into AI features. In addition, the AI rejects inputs containing health information, other sensitive information, login credentials or, depending on the centre's level, names, and stops. Such inputs are not stored; until then they were processed only on the AI endpoint used for Australian customers, without training.

The AI provider is Google (Google Cloud Vertex AI / Gemini), under Google's Cloud data processing terms. Inputs are not used to train AI models. Google generally does not store inputs; only if automated filters flag suspected abuse, for up to 90 days for abuse review [OPEN: confirm where Google keeps abuse-review data in the AU setup]. Text, voice and image content is processed in Australia [OPEN: confirm Vertex AI region and model availability in Australia]. The exception is image generation (website images, terminal logo, preview images for hazard topics) on Google's global endpoint; only image descriptions without personal information go there, and with the image generator's non-Australian model also your free text and reference images.

The data flows in short:

• Autopilot chat and "custom export" (director, after admin password): questions, key figures, per-person logs according to the level, group names, the team's free text. Suggested actions run only after the director confirms.
• Roster AI: roster, people with contract hours, demand; runs only at the "All" level; changes the roster directly, every change is marked and can be undone.
• Daily analysis (automatically before closing on days with high occupancy, email to the director): the first without asking, further ones only after consent.
• Staff app AI helper (only when switched on): answers questions about what the app already shows the person; for staff always with labels.
• Operator Autopilot: key figures of the centres, staff data according to each centre's level, absence reasons only as counts; centres at "Off" are excluded. Monthly report: aggregated monthly figures without names; the operator can switch it off.
• Help chat and DPA chat: your questions and product documentation or the DPA text; no operating data; not stored.
• Voice dictation (group tablet): recording only to convert it to text; it can contain children's voices, names and observations. The recording is never stored, the text is stored in the daily report.
• Email helper: your sample emails (which can contain correspondence with parents) and your request; the draft is stored until you delete it and is never sent.
• Parent meeting: recording up to 30 minutes only with consents saved beforehand, including at least one parent's. The AI writes an internal report and a version for the parents; the report stays stored until you delete it; the recording is deleted after analysis. The child's name and child data from the software are not sent to the AI.
• AI text drafts (permission texts, feedback to the operator): only your keywords.
• Website builder and image generation: your entries in the assistant (Australian endpoint [OPEN: confirm AU region]) and style descriptions for images (global endpoint).
• Hazard AI, preview image, handbook draft, floor plan: topics and notes of the team, photos (floor plan and handbook photos are not stored). A hazard topic's preview image is created automatically and can be switched off with the operator's "outside the region" lock.
• AI translation (only at the "All" level): the centre's emails to parents (the software first replaces names, dates, links and codes with placeholders), parent app content (messages, events, blog, group reports, diary notes, with everything in them) and, when the director clicks, the topic of a meeting request back into the centre's language. Only the translation is stored, for at most 30 days, not the original. Push notifications are not translated.
• Internet research (Autopilot, operator Autopilot, feedback to the operator, hazards): the AI can research a general question without names or personal details via Google Search and shows the sources. Google may store these search queries for up to three days.
• Image generator (only after the operator unlocks it and it is switched on): you describe an image and can upload reference images; you choose between models, and the software shows for each where it processes [OPEN: model choice and labels for the AU setup]. Reference images and text must not contain people or personal information. You download the images; we store neither them nor the reference images.
• Parent letters: an uploaded letter goes in full to the AI, which replaces personal details with placeholders; only the cleaned template is stored. When writing and translating, the AI sees only placeholders, never names or details of children; the software fills in the values. Sending by email requires the admin password and is logged; undelivered emails show as a notice without the address.
• AI data guard (on by default): checks texts to parents and the public before sending, first without AI against the children's names, then with AI (children's names replaced by placeholders). It runs only at the "All" level; without AI credits only the name check without AI runs. The AI does not change the text; only the director can send a flagged text, with the admin password. None of this is stored.

The notice shown before first use of some AI features is for transparency; it is not a consent request. Details are in the AI annex of the DPA.

2.8 Error monitoring

To detect and fix technical errors we use Sentry (Functional Software, Inc.) [OPEN: confirm AU region; Sentry region for Australian customers]. It receives error messages, stack traces and technical metadata. Chat content, prompts, audio and form data are not sent; for dictation errors at most the byte size and file type. Session replay is also active: it records screen sequences of the web app to reproduce errors, including on tablets and on public pages for parents (for example the enrolment portal and the confirmation page). Text and inputs are masked, images and media are not recorded. Where masking fails in an individual case, visible names can be included.

Separate from this are the software's own error logs in the centre database. They can contain a person ID in the error context so that a technical incident can be linked to the check-in or record action concerned. They stay in the centre database and are not sent to Sentry.

2.9 Camera and microphone

Sign-in terminal: the camera is used only to read QR codes. Although it may stay on, it is not video surveillance: no images are recorded or stored, no people or surroundings are observed or analysed, nothing is passed on, and recognition happens locally on the device.

Photo of a child (optional): in the group view, staff can take a photo of a child with the camera or choose a file, only if the parents have given the permission "Photo of the child on the centre's devices". The photo is reduced in size and stripped of location data on the device before it is stored.

Other photos (optional): for hazard topics, the floor plan and handbook drafts, photos can be taken or uploaded (see 2.7).

Microphone (optional): voice dictation records only while the user actively starts it; the recording is only converted to text and never stored. The director can record a parent meeting only with consent of at least one parent saved beforehand; the recording is deleted after analysis.

2.10 Parent app and staff app

The parent app is a separate app without user accounts; parents use it with a pseudonymous child code. It offers optional push notifications and digital wallet cards. Its requests (for example meal cancellations, absence notices, early pickup, general messages, centre status, poll votes) are relayed through Cloudflare Workers to the centre database (Supabase), with pseudonymised child and centre IDs. Cloudflare KV stores per centre the centre's parent password, the centre name, push tokens and device IDs with their group and the child identifiers stored on the device (so that messages about a child reach only that child's devices); wallet passes with the child's name are kept there for up to 5 minutes. Poll votes are linked to a device ID so each device counts once; the device ID is used only for that. Children's check-in and check-out times are not processed through Cloudflare. Parents enter names or contact details only if the centre turns on the related features (for example reporting a new pickup person or requesting a meeting; both off by default). Pseudonymised information can still be personal information. Using the parent app is voluntary.

The staff app (separate store app for phones) sends its requests directly to the application. Staff see their working times and the team's daily plan and can submit remote check-in, absence and sick notices and internal chat messages; a wallet staff badge is optional. Time corrections go to the director as an adjustment request. The centre can turn off the app and single features (team chat, clocking in and out, messages to parents) in its settings (on by default). In the privacy mode "Private phones" (default) the app shows no child records, only numbers about children; in the mode "Work devices", which the centre chooses only for its own devices, it may show names of children in the person's own group where a feature needs them. It never shows child codes. Free text from colleagues or the director and the topic a parent gave for a meeting can contain details about children. The director can send one person a message to their inbox in the app. The centre can turn on an AI helper for the staff app (off by default; see 2.7). Only people who allow push notifications on their own device receive them. We recommend running the staff app on centre-owned work devices.

Users of both apps accept the app's privacy notice and terms in the app; without accepting, the app cannot be used. Push notifications are explained there and can be turned off in the device settings at any time. Full notices: Parent App Privacy Notice and Staff App Privacy Notice.

2.11 Support via WhatsApp

[OPEN: is WhatsApp support offered in Australia?] If we offer support via WhatsApp (a service of Meta Platforms, Inc.), please do not send personal or sensitive information there (for example children's names, dates of birth, health information, photos or documents with personal content). The channel is only for general questions and technical support. WhatsApp messages are processed and stored on Meta's servers, which may be outside Australia, under Meta's terms. For anything involving personal information, use email (hello@beenest.co) or the communication features in Beenest.

2.12 Whose information the platform may contain

• Children at the centre
• Parents and guardians
• Centre staff
• Users of operator accounts, including invited users
• Authorised pickup persons
• Applicants for a place (children and parents)
• Invoice recipients for membership fees; payers of parent payments (only with a bank connection)
• Participants in recorded parent meetings
• Recipients of email copies and forwarded messages

3. How we collect personal information

• From you directly, when you use the contact form, email us, sign up, use your account or contact support.
• From your organisation, when an account holder invites you or sets up your access.
• Automatically from your browser or device, through server logs, session data and, only with your consent, the analytics and marketing tools on beenest.co.
• For centres, Centre Data is entered by the centre's staff, by parents through the parent app and confirmation pages, and by staff through the staff app. We collect it on the centre's behalf.
• From Stripe, confirmation of payments and the payment status of a Customer.

If we receive personal information we did not ask for, we check whether we could have collected it under the APPs and, if not, destroy or de-identify it where lawful and reasonable.

4. Why we collect, hold, use and disclose personal information

For information we decide about (Section 1), we use it to:

• deliver, secure and keep beenest.co stable, and detect abuse
• answer inquiries, give information about Beenest and prepare consultations you ask for
• create and manage customer accounts, authenticate users and provide support
• bill subscription fees and AI credits and keep business records
• detect and fix errors and keep the platform secure
• understand website use and measure ad campaigns, only if you consented in the cookie banner
• comply with law and protect our rights

We use or disclose personal information for another purpose only where you have consented or the APPs otherwise allow it (for example where the law requires it).

Centre Data we use only to provide the platform to the Customer as described in Section 2 and in the DPA, as the Customer instructs. We do not use Centre Data for our own purposes, we do not combine it with other data for our own purposes, and we do not use it to train AI models.

If you do not give us information. You can browse beenest.co without telling us who you are. We cannot answer an inquiry without a way to contact you, and we cannot provide an account without the account data in Section 2.3.

5. Anonymity and pseudonymity

You may deal with us anonymously or under a pseudonym where that is lawful and practicable, for example when you browse the website or ask a general question. For accounts, billing and support we need to know who you are. In the platform, the parent app works with pseudonymous child codes instead of names, and the web app can be run with pseudonyms (initials instead of full names) for children and staff. For more options, contact hello@beenest.co.

6. Who we disclose information to

We disclose personal information only:

• to service providers who help us run the website and the platform, under contracts that limit their use of the information
• to recipients the Customer chooses (for example the meal supplier, see below)
• when the law requires or authorises it, or to protect rights, safety and security
• with your consent
• to a successor in a merger, acquisition or sale of assets, subject to this policy [OPEN: keep this clause?]

The full list of sub-processors for Centre Data is in Annex 1 of the DPA.

For the web app we use Vercel's web analytics: aggregated page statistics, without cookies. We do not use tracking or advertising tools in the platform.

Meal supplier. If the optional supplier access is turned on, the meal supplier named by the operator can see meal notes (including allergy and diet information). The supplier is a recipient on the Customer's instructions, not our sub-processor.

Bank connection (optional). [OPEN: available in Australia? DE provider is Qonto] If a centre connects its own bank account, Beenest reads transactions there, read-only and on the centre's instructions, to match parent payments. The bank is the centre's contracting party, not our sub-processor. The payer's name and account number are fetched but not stored; only the reference, amount and booking date of incoming payments that are or should be matched, and of outgoing payments the centre assigns to an occasion, are stored. All other transactions are discarded.

7. Overseas disclosure

For Australian customers, the platform's databases and servers are in Australia [OPEN: AU region, e.g. Sydney], and the services are configured for Australian regions where the provider offers one. Some information still leaves Australia:

• Email. Our mailbox (Zoho) and the service for technical emails and emails sent and received in software features (Brevo), including emails the software sends to parents in the centre's name. [OPEN: does email stay in the EU for Australia? If yes: Netherlands, France, Germany and Belgium.]
• Push notifications and wallet passes. Expo (United States), Firebase Cloud Messaging and Apple Push Notification service (global, including the United States) and Google Wallet (global). The platforms require these services; message content only passes through them and is not stored there permanently.
• AI image generation on Google's global endpoint (Section 2.7), and AI abuse-review data at Google where flagged [OPEN: location].
• Providers without a confirmed Australian region. Sentry, Cloudflare KV and the Cloudflare API relay, and any other provider in Section 6 marked as not yet confirmed. Published centre websites are delivered through Cloudflare's global network.
• Website and business data. beenest.co and contact form submissions (Netlify, United States); Google Analytics and the Meta Pixel (United States), only with consent; card payments (Stripe, [OPEN: country]).
• Our own access. Beenest is not an Australian company. Our staff may access information for support and operations from [OPEN: countries from which Triple Peak staff access data].

The countries in which recipients are likely to be located are therefore: the United States, [OPEN: the Netherlands, France, Germany and Belgium if email stays in the EU; Stripe's country; countries of our own access], and, for services that run on global networks, other countries in which those networks operate.

Before we disclose personal information overseas, we take reasonable steps to ensure the recipient does not breach the APPs in relation to it, in particular through contracts with our service providers. [OPEN: confirm the contractual basis per provider (data processing terms) for APP 8]

8. Direct marketing and the Meta Pixel

We do not use contact form or account data for direct marketing without your separate consent. If you have agreed to receive marketing from us, you can opt out at any time by using the unsubscribe link in the message or by emailing hello@beenest.co. We do not sell personal information, and we do not use Centre Data or platform data for advertising.

If you accept marketing cookies on beenest.co, the Meta Pixel sends Meta information about your visit (Section 2.1), which Meta uses to measure our campaigns and show relevant ads. Meta handles this information under its own terms and privacy policy. [OPEN: beenest.co currently offers an opt-in Meta Pixel ("personalised ads") and Google Analytics in the cookie banner. Decide whether to keep them for Australia; if removed, delete this paragraph and the related rows.]

9. Cookies and similar technologies

Website. Your cookie choice is stored in your browser's local storage (necessary, always active). Analytics and marketing cookies are set only after you agree. You can change your choice at any time with the "Cookie Settings" button on the pages that show the banner; withdrawing consent deletes the related cookies and reloads the page.

Platform. The web app uses only technically necessary cookies and similar storage (for example session management and authentication). It uses no tracking or marketing cookies.

10. How we hold information and how long we keep it

We hold personal information electronically with the service providers in Section 6. When we no longer need personal information for a purpose allowed under the APPs and are not required by law or by the Customer's instructions to keep it, we take reasonable steps to destroy or de-identify it.

Website and business data

• Website server logs: up to 30 days.
• Contact form and inquiry data: as long as needed to handle your request, then deleted, unless law requires longer retention or you become a customer.
• Google Analytics data: 14 months, then deleted automatically.
• Meta Pixel data: under Meta's retention policies.
• Cookie choice: in your browser's local storage until you clear it or change your settings.
• Account (registration) data: for the term of the contract plus 30 days after termination (data export period).
• Billing records: [OPEN: retention period for billing and tax records]

Centre Data

We keep Centre Data only as long as needed for the purposes or as long as the Customer instructs. In particular:

• Attendance data (drop-off and pick-up times): the Education and Care Services National Regulations require the approved provider to keep a children's attendance record (regulation 158) and to store records for set periods (regulation 183); that duty is the Customer's. We store the data on its behalf as long as it decides and at most until the contract ends. Before that, the Customer can export all data; afterwards we delete it (see the DPA).
• Discarded check-in actions: deliberately kept after the person concerned is deleted or archived (documented retention so terminal actions can be traced). They are deleted or returned with the rest of the contract data.
• Platform server logs: at most 90 days, unless there is a security incident.
• Internal staff chat: deleted automatically after the retention the centre chooses (1 to 7 days, default 1 day), at midnight in the centre's time zone; this includes automatic notices in the chat. Pinboard messages are exempt and stay until removed manually or the contract ends.
• Group reports, daily reports and incident notes (free text): as long as the Customer keeps them or the contract lasts.
• Child notes, child photo, parent contact details on the child record: as long as the child record exists or the contract lasts; the child photo is deleted when the permission is withdrawn.
• Consent requests by email: recipient address and link hash 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 remain as proof. The send log of permission and recording requests stays until the centre deletes it, at most until the contract ends.
• Consents to recording a parent meeting: unused ones after 30 days, with the image of the signature; used ones stay with the meeting until the centre deletes it.
• Enrolment portal applications: unconfirmed after seven days; rejected or withdrawn ones twelve months after closing.
• Failed password attempts: hashes after about one hour.
• Bank transactions (with a bank connection): reference, amount and booking date of stored transactions as long as the Customer keeps them or the contract lasts; name and account number never. Incoming payments the centre sets aside keep only the transaction ID and amount, so they are not imported again.
• Send log to parents: as long as the Customer keeps it or the contract lasts.
• Poll votes: with device ID, as long as the poll or the contract lasts.
• The software's own error logs: including a person ID in the error context, as long as needed to fix the error or the contract lasts.
• AI features: Autopilot and roster AI history after the period the centre chooses (1 to 7 days, default until the end of the calendar day), then deleted automatically; translations at most 30 days (only the translation, not the original); help chat, DPA chat, operator Autopilot and staff app AI helper are not stored. Confirmed Autopilot actions, roster AI changes, daily analyses and monthly reports as long as the Customer keeps them or the contract lasts. Email drafts, parent meeting reports and recording consents until the centre deletes them, at the latest when the contract ends. A usage record without content per AI call (for AI credits) until the contract ends. Voice recordings never permanently. At Google only on suspected abuse, up to 90 days (see 2.7).
• Dictation audio: used only for transcription and never stored; only the transcribed text in the daily report, as long as the Customer keeps it.
• Error reports (Sentry): technical events without chat, prompt or audio content and masked session replays, limited to the retention configured at Sentry.

After the contract ends, Centre Data is deleted or returned, as the Customer chooses, within 30 days (see the DPA). Some records must be kept by the approved provider for longer than the contract, some until a child turns 25 (regulation 183). The Customer is responsible for meeting its own record-keeping duties before deletion.

11. Security

• Encryption: TLS 1.2/1.3 for every transfer (HTTPS only, no unencrypted interfaces), AES-256 at rest.
• Access control: role-based access and authentication; tenant separation at database level through row-level security on every table. Operator accounts (including invited users) see and edit the data of the centres assigned to that operator, not of other operators.
• Availability: regular backups, redundant infrastructure, DDoS protection.
• Pseudonymisation: child codes instead of names in the parent app; the web app can optionally be run with pseudonyms for children and staff (Section 5).
• Review: regular security audits and evaluation of the measures.
• Website: HTTPS only, restricted and authenticated administrative access, collecting only what is needed, and no tracking scripts before consent.

Detailed security measures are available to Customers on request.

12. Data breaches

Centre Data. If a security incident affects Centre Data, we notify the Customer without undue delay and at the latest within 24 hours after we become aware of it, and support it, so that it can assess the incident and meet its obligations under the Notifiable Data Breaches scheme (Part IIIC of the Privacy Act 1988 (Cth)). [OPEN: who notifies the OAIC and individuals where both Beenest and the Customer hold the information]

Our own data. If a data breach affects information we decide about and is likely to result in serious harm, we notify the affected individuals and the Office of the Australian Information Commissioner (OAIC) as the Notifiable Data Breaches scheme requires.

13. Children

Beenest is not directed to children, and children do not use it. Information about children is entered by the centre or by parents, as part of the care relationship between the centre and the family. We do not knowingly collect personal information directly from children. If you believe a child has given us personal information directly, contact us and we will delete it.

Photo and video documentation of children is not a core feature of Beenest. A photo of a child for recognition exists only with the parents' permission "Photo of the child on the centre's devices", and it is not processed with AI. Meeting recordings exist only with prior consent and only until they are analysed. We do not collect biometric information or biometric templates (such as face geometry or fingerprints) [OPEN: confirm].

14. Staff of centres

A private sector employer's handling of an employee record directly related to a current or former employment relationship is exempt from the APPs. Whether that exemption applies to staff data in Beenest is a question for the centre as employer; it does not cover contractors or volunteers. We handle staff data in the platform as described in this policy and the Staff App Privacy Notice either way.

Some states and territories regulate workplace surveillance and require employers to give notice beforehand (for example the Workplace Privacy Act 2011 (ACT)). Giving that notice is the duty of the centre as employer.

15. Access and correction

You can ask for access to the personal information we hold about you as a business (Section 1) and ask us to correct it if it is inaccurate, out of date, incomplete, irrelevant or misleading. Email [privacy contact email] or hello@beenest.co.

• We respond within a reasonable period [OPEN: response time commitment, e.g. 30 days].
• We do not charge for making a request or for correcting information. [OPEN: any charge for giving access?]
• We verify your identity before we act, for example by confirming a request sent from the email address of your account or inquiry. We use the information you give for verification only for that purpose.
• If we refuse access or correction, we tell you why in writing and how to complain. If we refuse a correction, you can ask us to attach a statement to the information that you believe it is inaccurate.

Requests about Centre Data. If you are a parent, staff member or other person whose data a centre entered in Beenest, the centre decides about that data. Please send your request to the centre. If you send it to us, we forward it to the centre and support the centre in answering it, as the DPA requires.

16. Complaints

If you think we have breached the APPs, please contact us first at [privacy contact email] or hello@beenest.co and describe the issue. We will acknowledge your complaint, look into it and give you a written response within a reasonable period [OPEN: response time commitment, e.g. 30 days].

If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.

Complaints about how a centre handles Centre Data go to the centre first. State or territory health records laws may also give you rights against the centre [OPEN: which state and territory health records laws to name, if any].

17. Changes to this policy

We may update this policy from time to time. The current version is always available at beenest.co/au/privacy. We will announce material changes on the website and, for Customers, by email or in the software [OPEN: confirm notice method for Customers].

18. Contact

Triple Peak Software Systems, [registered address]
Privacy requests and complaints: [privacy contact email]
General questions: hello@beenest.co

Related documents: Terms of Service, Data Processing Agreement, Parent App Privacy Notice, Staff App Privacy Notice.